4.2 Few-Shot Prompting

Những gì cần nắm

Few-shot example là kỹ thuật hiệu quả nhất để có output nhất quán, đúng định dạng từ Claude. Không phải thêm chỉ dẫn. Không phải ngưỡng confidence. Không phải chỉnh temperature. Khi output không nhất quán, few-shot example là thứ nên với tới đầu tiên.

Đây là nguyên tắc đề thi hỏi thẳng. Đề thi dựng tình huống trong đó chỉ dẫn đã rất chi tiết nhưng kết quả vẫn lộn xộn, rồi kiểm tra xem bạn chọn “thêm chỉ dẫn” hay “thêm few-shot example”. Đáp án gần như luôn là vế sau.

Khi nào cần few-shot example

Có ba dấu hiệu cụ thể cho biết đã đến lúc dùng few-shot:

1. Chỉ dẫn chi tiết mà định dạng output vẫn không nhất quán. Bạn đã viết prompt kỹ càng, chỉ rõ định dạng output, nhưng model vẫn trả về cấu trúc khác nhau qua từng lần gọi — lúc bullet list, lúc bảng, lúc văn xuôi. Thêm chỉ dẫn không sửa được. Vài ví dụ cho thấy đúng định dạng bạn muốn thì sửa được.

2. Model phán đoán không nhất quán ở các trường hợp mơ hồ. Với công cụ code review, model gán variable shadowing là “critical” ở file này nhưng “minor” ở file khác. Với agent chọn tool, nó route “check my order” tới các tool khác nhau tùy cách người dùng diễn đạt. Những ca mơ hồ này cần ví dụ minh họa phán đoán đúng, kèm lập luận.

3. Tác vụ extraction trả về field rỗng/null cho thông tin thật sự có trong tài liệu. Thông tin nằm đó, nhưng ở định dạng không ngờ tới — nhúng trong văn xuôi thay vì trong bảng có cấu trúc, hoặc rải qua nhiều đoạn. Few-shot example minh họa extraction từ nhiều kiểu cấu trúc tài liệu sẽ giải quyết chuyện này.

Xây ví dụ cho hiệu quả

Quy tắc khá chặt:

Dùng 2–4 ví dụ nhắm đúng đích. Dưới 2 thì chưa thành pattern. Trên 4 thì tốn token mà lợi ích không tăng tương ứng. Nhắm ví dụ vào đúng những tình huống mơ hồ đang gây lỗi.

Mỗi ví dụ phải có lập luận. Đừng chỉ đưa cặp input–output. Hãy cho thấy vì sao chọn hành động này thay vì các phương án hợp lý khác. Đó là cách dạy model tổng quát hóa phán đoán sang pattern mới, thay vì chỉ khớp đúng những ca có trong ví dụ.

Example: Tool selection for "check my order #12345"
Input: "check my order #12345"
Selected tool: lookup_order
Reasoning: The user provides an order number (#12345), indicating
they want order-specific information. Even though this could be
interpreted as a general customer query, the specific order
identifier makes lookup_order the correct choice over get_customer.

Không có phần lập luận, model chỉ học được “câu nào nhắc số đơn hàng thì đẩy sang lookup_order”. Có lập luận, model học được nguyên tắc chung: định danh cụ thể thì route sang tool tra cứu cụ thể.

Phủ đúng tình huống đang hỏng. Nếu extraction chạy tốt trên bảng nhưng hỏng trên văn xuôi, ví dụ của bạn phải minh họa extraction đúng từ văn xuôi. Nếu code review không nhất quán ở variable shadowing, ví dụ phải xếp các ca variable shadowing vào những mức severity khác nhau kèm lập luận.

Tác dụng phụ: giảm hallucination

Few-shot example có một tác dụng phụ đáng giá: nó giảm hallucination trong tác vụ extraction. Khi model thấy ví dụ extraction đúng từ nhiều kiểu cấu trúc tài liệu — trích dẫn nội dòng so với mục tài liệu tham khảo, mô tả bằng văn xuôi so với bảng có cấu trúc, tiêu đề so với chữ nhúng trong đoạn — nó học được cách xử lý sự đa dạng cấu trúc mà không bịa dữ liệu.

Điểm này quan trọng nhất với tài liệu có định dạng thiếu nhất quán. Một báo cáo tài chính có thể liệt kê chi phí bằng bảng ở trang này rồi chôn chúng trong một đoạn văn ở trang sau. Không có ví dụ, model thường lấy đúng phần bảng nhưng trả field rỗng cho phần văn xuôi, hoặc tệ hơn là bịa số. Cho nó thấy cả hai kiểu cấu trúc thì chất lượng extraction lên hẳn.

Few-shot để giảm false positive

Trong code review và phân tích, few-shot example làm hai việc cùng lúc: cho thấy cái gì cần flag và cái gì nên bỏ qua. Ví dụ tách bạch pattern code chấp nhận được với vấn đề thật sẽ giảm false positive mà vẫn bắt được lỗi thật.

Example: Variable shadowing assessment
Code: function process(items) {
  const result = items.map(item => {
    const result = transform(item);  // shadows outer 'result'
    return result;
  });
  return result;
}
Severity: minor
Reasoning: The inner 'result' shadows the outer variable but
within a limited scope (arrow function). The code is still readable
and the shadow does not cause a bug. This is a style preference,
not a defect. Flag as minor only if style consistency is in scope.

Ví dụ này dạy model phân biệt bug thật với pattern vô hại, giảm false positive mà vẫn giữ được khả năng tổng quát hóa sang những ca shadowing thực sự có vấn đề.

Few-shot so với các kỹ thuật khác

Đề thi kiểm tra xem bạn có phân biệt được khi nào few-shot là lời giải đúng và khi nào phải dùng kỹ thuật khác:

Vấn đề	Kỹ thuật đúng
Định dạng output không nhất quán	Few-shot example
JSON output bị hỏng cú pháp	tool_use kèm JSON schema
Bịa giá trị cho field thiếu dữ liệu	Field optional/nullable trong schema
Chọn sai tool	Mô tả tool tốt hơn (trước), rồi mới tới few-shot
Model bỏ sót thông tin nằm trong văn xuôi	Few-shot example minh họa extraction từ văn xuôi
Tổng extraction không khớp với tổng ghi trong tài liệu	Validation-retry loop

Bẫy thi

Tình huống luyện tập

Pipeline extraction của bạn nhận đúng dữ liệu nghiên cứu trong bảng có cấu trúc nhưng trả field rỗng khi cùng thông tin đó nằm trong các đoạn văn xuôi. Chỉ dẫn chi tiết đã nêu đủ mọi field bắt buộc và định dạng của chúng. Nên thử gì trước?

A. Thêm few-shot example minh họa extraction đúng từ cả bảng có cấu trúc lẫn đoạn văn xuôi
B. Tăng context window của model để xử lý được nhiều nội dung hơn trong mỗi tài liệu
C. Thêm bước tiền xử lý chuyển toàn bộ văn xuôi thành bảng có cấu trúc trước khi extraction
D. Thêm bước hậu xử lý retry, extract lại mọi field trả về rỗng

Đáp án & giải thích

Đúng: A

A — Few-shot example minh họa extraction đúng từ nhiều kiểu cấu trúc tài liệu chạm thẳng vào sự thiếu nhất quán. Model cần thấy extraction đúng từ văn xuôi trông ra sao.
B — Model đã tìm được dữ liệu trong bảng, nên kích thước context không phải vấn đề. Vấn đề là xử lý các cấu trúc tài liệu khác nhau không nhất quán, và context lớn hơn không sửa được chuyện đó.
C — Cách này thêm hạ tầng phức tạp không cần thiết. Model xử lý được nhiều định dạng khi được cho ví dụ. Tiền xử lý tạo gánh nặng bảo trì và có nguy cơ mất dữ liệu.
D — Retry mà không có hướng dẫn tốt hơn thì vẫn ra đúng kết quả rỗng đó. Model cần ví dụ extraction đúng từ văn xuôi, không phải thêm lượt thử với cùng một prompt.

Nguồn

Claude Certified Architect Foundations Exam Guide — Task Statement 4.2 — Anthropic
Prompt Engineering Overview — Anthropic
Building with Claude API (Skilljar) — Anthropic

Exam Simulator

Sáu câu trắc nghiệm theo format đề thi về Few-Shot Prompting. Chọn đáp án trước, rồi mở phần giải thích.

Câu 1

A. Tăng context window của model để xử lý được nhiều nội dung hơn trong mỗi tài liệu
B. Thêm few-shot example minh họa extraction đúng từ cả bảng có cấu trúc lẫn đoạn văn xuôi
C. Thêm bước tiền xử lý chuyển toàn bộ văn xuôi thành bảng có cấu trúc trước khi extraction
D. Thêm bước hậu xử lý retry, extract lại mọi field trả về rỗng

Đáp án & giải thích

Đúng: B

A sai vì model đã tìm được dữ liệu trong bảng — kích thước context không phải vấn đề. Vấn đề là xử lý các cấu trúc tài liệu khác nhau không nhất quán.
B đúng vì few-shot example minh họa extraction đúng từ nhiều kiểu cấu trúc tài liệu chạm thẳng vào sự thiếu nhất quán.
C sai vì cách này thêm hạ tầng phức tạp không cần thiết. Model xử lý được nhiều định dạng khi được cho ví dụ.
D sai vì retry mà không có hướng dẫn tốt hơn thì vẫn ra kết quả rỗng. Model cần ví dụ extraction đúng từ văn xuôi.

Câu 2

Công cụ code review của bạn gán variable shadowing là “critical” ở file này nhưng “minor” ở file khác. Chỉ dẫn review đã chi tiết và có nêu tiêu chí severity. Cách sửa hiệu quả nhất là gì?

A. Thêm tiêu chí severity chi tiết hơn với mô tả dài hơn
B. Thêm ngưỡng confidence và chỉ báo phát hiện trên 0.8
C. Tăng temperature để có output đa dạng hơn rồi lấy theo đa số
D. Thêm 2–3 few-shot example về variable shadowing ở các mức severity khác nhau

Đáp án & giải thích

Đúng: D

A sai vì chỉ dẫn chi tiết đã có sẵn. Thêm chỉ dẫn nữa không sửa được phán đoán thiếu nhất quán — model cần thấy ví dụ phân loại đúng.
B sai vì ngưỡng confidence được calibrate tệ và không chạm tới nguyên nhân gốc của phân loại thiếu nhất quán.
C sai vì temperature làm tăng độ ngẫu nhiên, còn bỏ phiếu đa số thêm phức tạp mà không sửa được sự thiếu nhất quán trong phán đoán.
D đúng vì few-shot example kèm lập luận dạy model phán đoán nhất quán cho các ca mơ hồ. Phần lập luận giúp tổng quát hóa sang những ca shadowing mới.

Câu 3

Với một tác vụ phân loại có nhiều ca mơ hồ, thường nên dùng bao nhiêu few-shot example?

A. 2–4 ví dụ nhắm đúng đích, chỉ phủ các tình huống mơ hồ
B. 1 ví dụ để giữ mức tiêu thụ token tối thiểu
C. 8–10 ví dụ để phủ toàn diện mọi trường hợp có thể xảy ra
D. Càng nhiều càng tốt, miễn còn vừa context window, để phủ tối đa

Đáp án & giải thích

Đúng: A

A đúng vì 2–4 ví dụ đủ để hình thành pattern mà không phí token. Hãy nhắm chúng vào đúng những tình huống mơ hồ đang gây lỗi.
B sai vì một ví dụ đơn lẻ chưa thành pattern. Model không tổng quát hóa được từ một ca.
C sai vì trên 4 ví dụ là tốn token mà lợi ích không tăng tương ứng. Hiệu suất giảm dần rất nhanh.
D sai vì nhồi context bằng ví dụ sẽ chèn ép chính tác vụ cần làm và làm giảm chất lượng output.

Câu 4

Khác biệt then chốt giữa few-shot example dạy khớp pattern và few-shot example dạy tổng quát hóa là gì?

A. Ví dụ khớp pattern dùng dữ liệu có cấu trúc; ví dụ tổng quát hóa dùng văn bản phi cấu trúc
B. Ví dụ khớp pattern dùng 2 ví dụ; ví dụ tổng quát hóa dùng từ 4 trở lên
C. Ví dụ khớp pattern chỉ có cặp input–output, còn ví dụ tổng quát hóa có thêm phần lập luận
D. Ví dụ khớp pattern dành cho tác vụ extraction; ví dụ tổng quát hóa dành cho tác vụ phân loại

Đáp án & giải thích

Đúng: C

A sai vì định dạng dữ liệu không quyết định việc model có học được cách tổng quát hóa hay không.
B sai vì số lượng ví dụ không quyết định khả năng tổng quát hóa — sự có mặt của phần lập luận mới quyết định.
C đúng vì ví dụ không có lập luận chỉ dạy model khớp pattern cụ thể (“câu nhắc số đơn hàng thì sang lookup_order”). Ví dụ có lập luận dạy nguyên tắc chung (“định danh cụ thể thì route sang tool tra cứu cụ thể”), nhờ đó tổng quát hóa được sang pattern mới.
D sai vì cả tác vụ extraction lẫn phân loại đều hưởng lợi từ cả hai cách.

Câu 5

Hệ thống extraction của bạn tạo ra JSON hỏng (thiếu ngoặc, thừa dấu phẩy) ở khoảng 5% số response. Nên áp kỹ thuật nào?

A. Thêm few-shot example minh họa output JSON đúng định dạng
B. Dùng tool_use kèm JSON schema để loại bỏ hoàn toàn lỗi cú pháp
C. Thêm bước validate JSON và retry khi output hỏng
D. Tăng max_tokens để model có đủ chỗ cho JSON hoàn chỉnh

Đáp án & giải thích

Đúng: B

A sai vì few-shot example xử lý tính nhất quán, không phải tuân thủ cấu trúc. Chúng giảm chứ không loại bỏ lỗi cú pháp JSON.
B đúng vì tool_use kèm JSON schema loại bỏ hoàn toàn lỗi cú pháp JSON ngay ở tầng API. Đây là thứ tự độ tin cậy: tool_use cho cấu trúc, few-shot cho tính nhất quán.
C sai vì retry làm tăng độ trễ và chi phí. Chặn lỗi ngay ở tầng API tốt hơn.
D sai vì cắt cụt output có thể góp phần gây hỏng JSON, nhưng tool_use mới là cách sửa dứt điểm lỗi cú pháp.

Câu 6

Một báo cáo tài chính trình bày chi phí bằng bảng ở trang 1 và bằng đoạn văn xuôi ở trang 3. Không có few-shot example, model extract đúng từ bảng nhưng bịa số từ phần văn xuôi. Điều gì giải thích hành vi này?

A. Context window của model không với tới trang 3
B. Model thiếu dữ liệu huấn luyện cho extraction văn xuôi tài chính
C. Model mặc định ưu tiên dữ liệu dạng bảng và bỏ qua văn xuôi
D. Nó bịa giá trị thay vì để field rỗng

Đáp án & giải thích

Đúng: D

A sai vì trang 3 thường vẫn nằm trong giới hạn context window với tài liệu thông thường.
B sai vì model có dữ liệu huấn luyện rất rộng. Vấn đề là thiếu hướng dẫn riêng cho tác vụ, không phải năng lực chung.
C sai vì model không có thiên hướng bẩm sinh ưu tiên bảng. Sự thiếu nhất quán đến từ việc chưa được minh họa extraction đúng từ văn xuôi.
D đúng vì few-shot example minh họa extraction đúng từ văn xuôi dạy model cách xử lý sự đa dạng cấu trúc. Không có chúng, model có thể bịa giá trị thay vì extract đúng từ định dạng lạ.