4.1 System Prompts with Explicit Criteria

Những gì cần nắm

Sai lầm lớn nhất khi làm prompt engineering cho production là dựa vào chỉ dẫn mơ hồ. “Hãy dè dặt.” “Chỉ báo những phát hiện có độ tin cậy cao.” “Dùng phán đoán tốt nhất của bạn.” Không câu nào cho model một đường ranh quyết định có thể hành động được. Chúng nghe rất hợp lý — và đó chính là lý do đề thi lấy chúng làm đáp án nhiễu.

Cách đúng là tiêu chí phân loại rõ ràng, định nghĩa chính xác cái gì cần flag và cái gì bỏ qua. So sánh hai system prompt cho một pipeline code review chạy trong CI/CD:

Cách sai:

Review this code. Be conservative. Only report high-confidence findings.

Cách đúng:

Flag comments only when claimed behaviour contradicts actual code behaviour.
Report bugs and security vulnerabilities.
Skip minor style preferences and local patterns.

Cái đầu không cho model tiêu chí nào để áp. “Conservative” mang nghĩa khác nhau tùy ngữ cảnh, còn “high-confidence” là ngưỡng chủ quan mà model không tự calibrate được. Cái sau đưa ra hạng mục cụ thể: báo cái gì (bug, security), bỏ cái gì (style, quy ước nội bộ), và điều kiện kích hoạt rõ ràng cho phần comment (hành vi được mô tả mâu thuẫn với hành vi thật của code).

Vấn đề niềm tin do false positive

Tỷ lệ false positive cao ở một hạng mục sẽ phá niềm tin vào tất cả hạng mục còn lại. Đề thi khai thác điểm này rất mạnh. Nếu phát hiện “documentation mismatch” sai 40% số lần, developer sẽ bỏ luôn cả những phát hiện “security vulnerability” của bạn, kể cả khi hạng mục đó đạt 98% chính xác. Niềm tin không tách theo hạng mục. Nó lây sang toàn bộ output.

Cách sửa nghe hơi ngược: tạm tắt hạng mục có false positive cao trong lúc bạn làm lại prompt cho nó. Niềm tin vào những hạng mục đang chạy tốt quay lại ngay lập tức. Sau đó bạn lặp trên hạng mục hỏng bằng ví dụ code cụ thể, chỉ bật lại khi precision đã cải thiện.

Bạn không bỏ hạng mục đó. Bạn đặt niềm tin vào cả hệ thống lên trước sự đầy đủ của từng hạng mục.

Calibrate severity bằng ví dụ code

Muốn định nghĩa mức severity thì phải dùng ví dụ code cụ thể, không phải mô tả bằng văn xuôi. So sánh:

Mô tả văn xuôi (không đủ):

Critical: Issues that could cause system failures or data loss
Minor: Issues that affect code readability but not functionality

Dùng ví dụ code (đúng):

Critical — Unsanitised user input in SQL query:
  query = f"SELECT * FROM users WHERE id = {user_input}"

Minor — Inconsistent variable naming:
  userName vs user_name in the same module

Mô tả văn xuôi buộc model tự diễn giải “could cause system failures” nghĩa là gì. Ví dụ code xóa sạch phần mơ hồ đó. Khi model thấy pattern code thật đã được gán vào từng mức severity, nó phân loại nhất quán qua các lần gọi.

Vì sao lọc theo confidence không ăn thua

Đề thi rất hay đưa “only report high-confidence findings” làm đáp án hấp dẫn. Nghe như kỹ thuật tốt: lọc theo confidence, giữ lại tín hiệu mạnh. Nhưng confidence do LLM tự báo được calibrate rất tệ. Model thường chắc chắn về phát hiện sai và lưỡng lự về phát hiện đúng. Confidence score có chỗ đứng của nó ở khâu routing (đẩy phát hiện confidence thấp sang human review, xem Task Statement 4.6), nhưng nó không thay được tiêu chí rõ ràng định nghĩa thế nào là một phát hiện hợp lệ ngay từ đầu.

Thứ tự ưu tiên là: tiêu chí rõ ràng trước, routing theo confidence sau. Đừng bao giờ bỏ qua bước đầu.

Bẫy thi

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

Pipeline code review trong CI/CD của bạn có tỷ lệ false positive 40% ở nhóm ‘documentation mismatch’, khiến developer bỏ qua TẤT CẢ hạng mục review, kể cả những phát hiện security chính xác. Cách sửa hiệu quả nhất là gì?

A. Thêm “only report high-confidence documentation issues” vào system prompt để model tự lọc bớt phát hiện yếu
B. Thêm một lượt model thứ hai xem lại từng phát hiện documentation và loại bỏ những cái nó không kiểm chứng được, trước khi báo cáo tới developer
C. Tăng temperature để có nhiều lần review đa dạng hơn, rồi lọc bỏ những phát hiện chỉ xuất hiện một lần
D. Tạm tắt hạng mục documentation mismatch trong lúc làm lại prompt bằng tiêu chí rõ ràng và ví dụ code

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

Đúng: D

A — Chỉ dẫn confidence mơ hồ không cải thiện precision. Model không có tiêu chí cụ thể nào cho “high-confidence” trong ngữ cảnh này.
B — Lượt thứ hai mà không có tiêu chí tốt hơn thì vẫn dính đúng vấn đề false positive. Sửa gốc — tức là tiêu chí — trước khi thêm lớp kiểm chứng.
C — Temperature ảnh hưởng độ ngẫu nhiên, không phải precision. Temperature cao còn dễ làm false positive tăng thêm.
D — Cách này khôi phục ngay niềm tin vào mọi hạng mục khác, trong khi bạn lặp trên hạng mục có vấn đề bằng tiêu chí cụ thể. Ưu tiên là lấy lại niềm tin trên toàn bộ hạng mục.

Nguồn

Claude Certified Architect Foundations Exam Guide — Task Statement 4.1 — 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ề System Prompts with Explicit Criteria. Chọn đáp án trước, rồi mở phần giải thích.

Câu 1

Pipeline code review trong CI/CD của bạn có tỷ lệ false positive 40% ở nhóm “documentation mismatch”, khiến developer bỏ qua TẤT CẢ hạng mục review, kể cả những phát hiện security chính xác. Cách sửa hiệu quả nhất là gì?

A. Thêm “only report high-confidence documentation issues” vào system prompt
B. Tăng temperature để có kết quả đa dạng hơn rồi lọc bỏ ngoại lệ
C. Tắt hạng mục documentation mismatch trong lúc làm lại prompt cho nó
D. Thêm một lượt model thứ hai để kiểm chứng từng phát hiện documentation trước khi báo cáo

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

Đúng: C

A sai vì chỉ dẫn confidence mơ hồ không cải thiện precision. Model không có tiêu chí cụ thể nào cho “high-confidence”.
B sai vì temperature ảnh hưởng độ ngẫu nhiên, không phải precision. Temperature cao sẽ làm false positive tăng lên.
C đúng vì nó khôi phục ngay niềm tin vào mọi hạng mục khác, trong khi bạn lặp trên hạng mục có vấn đề bằng tiêu chí cụ thể. Ưu tiên là lấy lại niềm tin trên toàn bộ hạng mục.
D sai vì lượt thứ hai mà không có tiêu chí tốt hơn thì vẫn dính đúng vấn đề false positive. Sửa tiêu chí trước.

Câu 2

Chỉ dẫn nào trong system prompt cho model đường ranh quyết định hành động được nhất cho tác vụ code review?

A. “Flag only where claimed behaviour contradicts the code.”
B. “Use your best judgement to identify important code issues”
C. “Be conservative and only flag issues you are highly confident about”
D. “Try to minimise false positives while maintaining good coverage of real issues”

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

Đúng: A

A đúng vì nó định nghĩa điều kiện kích hoạt cụ thể (hành vi được mô tả mâu thuẫn với hành vi thật), hạng mục cần báo (bug, security) và hạng mục bỏ qua (style, quy ước nội bộ).
B sai vì “best judgement” và “important” không cho tiêu chí cụ thể nào.
C sai vì “conservative” và “highly confident” là ngưỡng chủ quan, không diễn giải thành hành động được.
D sai vì nó mô tả kết quả mong muốn mà không nói tiêu chí để đạt được kết quả đó.

Câu 3

Team bạn định nghĩa các mức severity cho hệ thống code review. Cách nào cho phân loại nhất quán nhất qua các lần gọi?

A. “Critical: issues that could cause system failures or data loss. Minor: issues that affect code readability.”
B. Một decision tree phân loại theo loại file trước, rồi mới theo loại vấn đề
C. Ngưỡng confidence: trên 0.9 là critical, dưới 0.5 là minor
D. Ví dụ code cụ thể cho từng mức severity, từ critical xuống minor

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

Đúng: D

A sai vì mô tả văn xuôi kiểu “could cause system failures” buộc model diễn giải ngôn ngữ mơ hồ, dẫn tới phân loại không nhất quán.
B sai vì loại file không phải chỉ dấu đáng tin cho severity. Một lỗi SQL injection critical có thể nằm trong bất kỳ loại file nào.
C sai vì confidence score được calibrate tệ và không tương quan đáng tin với severity thật.
D đúng vì ví dụ code cụ thể xóa sạch phần mơ hồ. Khi model thấy pattern code thật đã gán vào từng mức severity, nó cho kết quả nhất quán.

Câu 4

Một developer lập luận rằng thêm “only report findings with confidence above 0.85” vào system prompt sẽ giảm false positive. Vì sao cách này không đủ?

A. 0.85 là ngưỡng quá cao; 0.70 sẽ hợp lý hơn
B. Confidence do LLM tự báo được calibrate tệ và không đáng tin
C. Lọc theo confidence chỉ chạy được với Batches API, không chạy với call đồng bộ
D. Model bỏ qua các chỉ dẫn về ngưỡng confidence trong system prompt

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

Đúng: B

A sai vì vấn đề không nằm ở giá trị ngưỡng, mà ở chỗ bản thân confidence score không đáng tin cho mục đích này.
B đúng vì confidence do LLM tự báo được calibrate tệ. Tiêu chí phân loại rõ ràng, nói rõ cái gì flag và cái gì bỏ qua, mới là bước đầu tiên đúng; routing theo confidence là kỹ thuật phụ trợ.
C sai vì lọc theo confidence không phụ thuộc API. Vấn đề là chất lượng calibration.
D sai vì model không bỏ qua các chỉ dẫn này; nó áp dụng không nhất quán vì confidence được calibrate tệ.

Câu 5

Hệ thống code review của bạn có năm hạng mục. “Unused imports” có tỷ lệ false positive 45%, bốn hạng mục còn lại trung bình 8%. Developer đã ngừng đọc mọi output review. Việc đầu tiên nên làm là gì?

A. Tắt “unused imports” trong lúc làm lại tiêu chí cho nó bằng ví dụ code thật
B. Thêm ngưỡng confidence để lọc phát hiện confidence thấp trên tất cả hạng mục
C. Huấn luyện lại hệ thống trên nhiều ví dụ code hơn để tăng độ chính xác tổng thể
D. Cắt vĩnh viễn số hạng mục xuống còn ba cái đáng tin nhất

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

Đúng: A

A đúng vì false positive cao ở một hạng mục phá niềm tin vào TẤT CẢ hạng mục. Tắt hạng mục có vấn đề khôi phục ngay niềm tin vào bốn hạng mục đang chạy tốt, trong lúc bạn lặp trên tiêu chí của “unused imports”.
B sai vì ngưỡng confidence được calibrate tệ và sẽ chặn luôn cả những phát hiện hợp lệ ở các hạng mục đang tốt.
C sai vì vấn đề là một hạng mục nhiễu phá niềm tin, không phải năng lực tổng thể của model.
D sai vì bỏ hạng mục vĩnh viễn là mất chức năng. Chiến lược là tạm tắt, cải thiện, rồi bật lại.

Câu 6

Thứ tự ưu tiên để cải thiện precision trong một hệ thống code review production là gì?

A. Ngưỡng confidence trước, rồi tới tiêu chí rõ ràng nếu ngưỡng chưa đủ
B. Ví dụ few-shot trước, rồi tiêu chí rõ ràng, rồi ngưỡng confidence
C. Tiêu chí phân loại rõ ràng trước, rồi routing theo confidence như kỹ thuật phụ trợ
D. Chỉnh temperature trước, rồi tinh chỉnh tiêu chí, rồi routing theo confidence

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

Đúng: C

A sai vì nó đảo ngược thứ tự. Ngưỡng confidence mà không có tiêu chí rõ ràng thì được calibrate tệ.
B sai vì ví dụ few-shot giải quyết tính nhất quán, không phải tiêu chí precision. Tiêu chí rõ ràng đi trước khi nói về precision.
C đúng vì tiêu chí rõ ràng định nghĩa thế nào là một phát hiện hợp lệ. Routing theo confidence có ích, nhưng chỉ sau khi đã có tiêu chí.
D sai vì temperature ảnh hưởng độ ngẫu nhiên, không phải precision. Nó không nằm trong thứ tự ưu tiên cải thiện precision.