CCA-F Domain 4: Prompt Engineering & Structured Output

#Task 4.1: Thiết kế prompt với tiêu chí tường minh để tăng precision, giảm false positive

#Kiến thức cần nắm

• Tiêu chí hay few-shot? Quy tắc chọn: viết được ranh giới thành một câu kiểm chứng được thì dùng tiêu chí; ranh giới có thật nhưng "nhìn thì biết, tả thì khó" và đổi hình đổi dạng theo từng tài liệu thì dùng few-shot (Task 4.2). VD: "báo lỗi comment chỉ khi hành vi nó mô tả mâu thuẫn với code" — viết ra được → tiêu chí. Còn "affiliation lúc nằm inline, lúc trong bibliography, lúc trong footnote" — tả không xuể → few-shot.
• Tiêu chí cụ thể: Tiêu chí tường minh tốt hơn hẳn chỉ dẫn mơ hồ (VD: "chỉ báo lỗi comment khi hành vi mô tả mâu thuẫn với code thực tế" thay vì "kiểm tra xem comment có chính xác không").
• Vô hiệu hóa bộ lọc tự tin: Chỉ dẫn chung chung kiểu "be conservative" hay "chỉ báo finding độ tin cậy cao" không cải thiện precision bằng việc phân loại danh mục cụ thể. Đây là confidence directive, không phải tiêu chí — nó không định nghĩa cái gì đủ điều kiện được báo, nên precision không nhúc nhích.
• Định nghĩa thuận mạnh hơn định nghĩa nghịch: Nói rõ cái gì tính là lỗi (chọn-vào) cho kết quả tốt hơn liệt kê cái gì cần bỏ qua (lọc-ra) — model chọn-vào theo một định nghĩa dương, thay vì phải suy ra phần bù của một danh sách loại trừ.
• Phạm vi (remit) cũng là một phần của tiêu chí: Nêu rõ cái gì ngoài lề — VD reviewer chỉ xét hành vi mà diff này tạo ra hoặc thay đổi, code có sẵn từ trước là out-of-scope; hoặc reviewer bắt lỗi trong hành vi được viết, không bàn sản phẩm nên làm gì.
• False positive bằng 0 là mục tiêu sai: Đòi tuyệt đối không có báo động giả sẽ làm reviewer câm lặng luôn. Đặt tỷ lệ FP chấp nhận được cho từng category để tinh chỉnh, thay vì bóp cho hết.
• Tác động của báo động giả (False Positive): Tỷ lệ false positive cao làm mất lòng tin của dev vào cả các phát hiện chính xác khác.

#Kỹ năng cần làm được

• Quy định tiêu chí rõ ràng: Viết tiêu chí review cụ thể: lỗi nào cần báo (bug logic, security) vs lỗi nào bỏ qua (style code, naming cục bộ).
• Bắt finding kèm bằng chứng: Yêu cầu mỗi finding trích đúng dòng nó nói tới và nêu input nào sẽ kích hoạt lỗi; finding nào không nêu được thì bỏ. Đây là bộ lọc precision mạnh hơn mọi chỉ dẫn "hãy cẩn thận".
• Finding phải nêu hành động: Bắt output nói sửa gì, ở đâu chứ không phải phát biểu một nỗi lo. Một finding không quy được ra hành động thì với dev nó là nhiễu.
• Gộp theo vấn đề, không theo lần xuất hiện: Một vấn đề = một finding, liệt kê mọi vị trí nó ảnh hưởng — thay vì mỗi chỗ xuất hiện đẻ ra một finding riêng làm ngập báo cáo.
• Rút category từ lịch sử incident: Lấy chính các sự cố đã xảy ra (phân trang, idempotency, xử lý múi giờ) làm danh mục kiểm, kèm ví dụ cụ thể cho từng loại — thay vì bê một danh sách chung chung ở đâu về.
• Đo trước và sau khi sửa prompt: Dựng tập đã gán nhãn từ các review cũ (finding nào đúng, finding nào là báo động giả) rồi chấm prompt hiện tại trên đó — trước và sau mỗi lần chỉnh. Không đo thì "cải thiện" chỉ là cảm giác.
• Quản lý nhóm lỗi: Tạm tắt các category có false positive cao để khôi phục lòng tin của dev trong lúc tinh chỉnh prompt. Khi bật lại thì bật từng category một kèm đo, không bật cả loạt.
• Tiêu chí theo ngữ cảnh: Định nghĩa tiêu chí riêng cho từng ngôn ngữ/khu vực code, rồi chọn đúng bộ tiêu chí khớp với các file bị thay đổi trong diff.
• Phân loại mức độ nghiêm trọng (Severity): Định nghĩa tiêu chí severity tường minh kèm ví dụ code cụ thể cho từng mức độ để phân loại nhất quán. Neo severity vào hậu quả — nếu cái này lên production thì chuyện gì xảy ra, với ai — kèm ví dụ mẫu cho từng mức.

#🧠 Phân tích & Thực tế từ Delivery Manager:

Nếu hệ thống CI/CD liên tục bắn ra hàng trăm cảnh báo bảo mật giả cho dev mỗi ngày, họ sẽ bắt đầu "phớt lờ" mọi cảnh báo (alert fatigue), kể cả các lỗi nghiêm trọng thật sự. Là DM, tôi luôn yêu cầu tech lead định nghĩa rõ ràng thế nào là một "lỗi chặn release" (blocker) và loại bỏ hoàn toàn các rule lặt vặt khỏi workflow của dev.

#Task 4.2: Áp dụng few-shot prompting để tăng độ nhất quán và chất lượng output

#Kiến thức cần nắm

• Few-shot hay tiêu chí? Mặt còn lại của quy tắc ở Task 4.1: few-shot dùng khi ranh giới tả bằng văn xuôi không xuể — cùng một thông tin nhưng xuất hiện dưới nhiều hình dạng bề mặt khác nhau, hoặc vấn đề nằm ở hình dạng output. Nếu ranh giới viết được thành một câu kiểm chứng được thì tiêu chí rẻ hơn và ổn định hơn.
• Vai trò của Few-shot: Few-shot examples là kỹ thuật hiệu quả nhất để định dạng output nhất quán, vượt trội hơn việc chỉ dùng chỉ dẫn bằng văn xuôi.
• Giải quyết ca mơ hồ: Few-shot giúp minh họa cách xử lý các ca mơ hồ (VD: chọn tool cho request mơ hồ, gap coverage test mức branch).
• Khái quát hóa: Giúp model khái quát hoá phán đoán sang các pattern mới, không chỉ khớp với các ca đã liệt kê.
• Lợi ích bão hoà rất nhanh: Một nhúm ví dụ chọn khéo mang gần hết giá trị; phần thêm vào sau đó chủ yếu là dư thừa trả tiền mỗi request. 200 ví dụ không giỏi hơn 4 ví dụ đúng chỗ, nhưng đốt token ở mọi lời gọi.
• Tập ví dụ lệch sẽ thành prior: Nếu ví dụ nghiêng hẳn về một nhãn, model tái tạo đúng độ lệch đó như một phân bố tiên nghiệm. Cân tập ví dụ theo thực tế, đừng chỉ gom những ca "đẹp".
• Ví dụ mâu thuẫn còn tệ hơn không có ví dụ: Bốn ví dụ dùng bốn quy ước khác nhau cho giá trị thiếu (bỏ trường / chuỗi rỗng / null / "N/A") thì thứ được minh hoạ là sự tuỳ tiện.
• Giảm thiểu ảo tưởng: Giảm hallucination hiệu quả khi trích xuất dữ liệu phi cấu trúc (VD: xử lý đơn vị đo lường đa dạng, văn bản hành chính).

#Kỹ năng cần làm được

• Thiết kế ví dụ chất lượng: Tạo 2-4 few-shot ví dụ nhắm vào scenario mơ hồ, nêu rõ lý do tại sao lại chọn hành động đó thay vì hướng đi khác.
• Lấy ví dụ từ ca mơ hồ, không phải ca rõ ràng: Ví dụ rõ ràng không dạy được gì vì model vốn đã làm đúng chúng. Thay chúng bằng chính các ca đang sai — và ghép cặp hai loại dễ nhầm cạnh nhau để mệnh đề phân biệt lộ ra.
• Ví dụ phải khớp schema hiện hành: Schema đổi thì bộ ví dụ cũ quay ra chống lại schema mới — phải viết lại theo hình dạng mới, coi đó là một phần của việc đổi schema.
• Ví dụ phải giống tài liệu thật: Dựng ví dụ từ tài liệu production nguyên trạng, kể cả nhiễu OCR và artifact. Nếu buộc phải thay bằng dữ liệu giả thì giữ nguyên layout, vị trí trường và các quirk định dạng — đó mới là thứ ví dụ đang dạy.
• Chọn ví dụ động theo từng request: Với tài liệu đa dạng, thay vì một bộ ví dụ cố định thì truy hồi 2–3 tài liệu quá khứ giống nhất với đầu vào hiện tại và đưa chính chúng vào prompt.
• Nhất quán format: Kèm few-shot minh hoạ cấu trúc output mong muốn (vị trí lỗi, mô tả, mức độ nghiêm trọng, hướng xử lý).
• Hạn chế false positive: Cung cấp ví dụ phân biệt pattern code chấp nhận được vs bug thật để Claude học cách phân loại đúng. Quan trọng: ví dụ phải kèm lý do tách hai loại, không chỉ cho thấy kết quả — thiếu phần lý do thì model không khái quát được sang ca mới.
• Xử lý đa dạng cấu trúc tài liệu qua few-shot: Sử dụng few-shot để hướng dẫn mô hình cách xử lý các cấu trúc tài liệu nguồn đa dạng (VD: phân biệt khi nào trích xuất inline citations vs bibliographies, hoặc methodology vs embedded details).
• Giải quyết lỗi trích xuất rỗng (empty/null): Bổ sung các ví dụ few-shot chỉ rõ cách trích xuất dữ liệu từ các tài liệu có định dạng bất nhất để khắc phục triệt để lỗi mô hình trả về giá trị rỗng/null cho các trường bắt buộc (required fields).

#🧠 Phân tích & Thực tế từ Delivery Manager:

Khi viết prompt trích xuất thông tin hợp đồng cho bộ phận pháp chế, mô tả dài 2 trang giấy cũng không hiệu quả bằng việc đưa ra 3 ví dụ hợp đồng mẫu có cấu trúc khác nhau. Few-shot chính là phao cứu sinh giúp Claude hiểu rõ khi nào một điều khoản phạt được coi là có hiệu lực pháp lý mà không cần viết prompt siêu dài.

#Task 4.3: Ép structured output bằng tool use và JSON schema

#Kiến thức cần nắm

• Tool Use cho cấu trúc: Tool use kết hợp JSON schema là cách đáng tin nhất để ép định dạng đầu ra sạch, loại bỏ lỗi cú pháp JSON (JSON syntax errors).
• Tham số tool_choice: Sự khác biệt giữa "auto", "any", và ép chọn tool cụ thể.
• Hạn chế của Schema: Schema loại bỏ lỗi cú pháp nhưng không chặn được lỗi ngữ nghĩa (semantic errors, VD: tổng các mặt hàng không bằng stated_total).
• Schema mềm dẻo: Cách chia trường bắt buộc (required) và tuỳ chọn (optional), cùng mẫu enum có thêm giá trị "other" kèm một chuỗi mô tả chi tiết cho trường hợp ngoài danh sách.

#Kỹ năng cần làm được

• Thiết kế tool trích xuất: Định nghĩa extraction tool với tham số đầu vào là JSON schema để lấy kết quả có cấu trúc từ response tool_use.
• Chọn tool_choice phù hợp:
  • Đặt tool_choice: "any" khi có nhiều schema trích xuất khác nhau và chưa rõ loại tài liệu nguồn.
  • Đặt forced tool choice khi bắt buộc quy trình trích xuất metadata phải chạy trước các bước làm giàu dữ liệu khác.
• Nullable fields chống bịa dữ liệu: Định nghĩa trường là optional hoặc nullable ("type": ["string", "null"]) đối với thông tin nguồn có thể bị thiếu, ngăn Claude tự bịa ra giá trị để đáp ứng schema.
• Áp dụng enum an toàn và mở rộng: Định nghĩa enum chứa các giá trị mở rộng như "unclear" cho các trường hợp dữ liệu nguồn nhập nhằng và "other" đi kèm trường nhập text chi tiết để xử lý phân loại linh hoạt.
• Tích hợp normalization rules vào prompt: Đưa quy tắc chuẩn hóa định dạng (format normalization rules) vào prompt song song với JSON Schema nghiêm ngặt để xử lý các tài liệu nguồn có định dạng lộn xộn (VD: chuẩn hóa số điện thoại, định dạng ngày tháng).

⚠️ Đính chính (docs 08/2026) — chỉ khai input_schema KHÔNG bảo đảm được schema. Chữ "guaranteed schema-compliant" trong Exam Guide thiếu mất một điều kiện, và đây là chỗ dễ nhớ sai nhất của Task 4.3.

Không bật strict mode thì model vẫn có thể trả sai kiểu ("2" thay vì 2) hoặc thiếu hẳn trường required — schema chỉ là mô tả, không phải ràng buộc. Thứ biến nó thành bảo đảm thật là strict: true đặt cùng cấp với name / description / input_schema: API biên dịch schema thành grammar rồi ràng buộc quá trình sampling (grammar-constrained sampling), nên tool_use.input luôn hợp schema và tên tool luôn hợp lệ.

Phân biệt cho rõ hai thứ hay bị gộp: strict: true lo hình dạng (kiểu dữ liệu, đủ trường required); tool_choice lo có gọi tool hay không. Cần cả hai bảo đảm thì khai cả hai — tool_choice một mình không làm input hợp schema, và strict một mình không ép model phải gọi tool.

Và mức bảo đảm dừng ở đó: strict chỉ bảo đảm hình dạng, không bảo đảm nội dung. Một PO number bịa nhưng đúng định dạng vẫn lọt qua sạch sẽ. Nullable, enum "unclear" và chặn placeholder "N/A" ở tầng validation chỉ giảm áp lực bịa chứ không phải bảo đảm tất định. Muốn tiến gần "không bao giờ bịa" thì phải thiết kế provenance: mỗi giá trị kèm source span, validator đối chiếu ngược vào tài liệu, trường không đối chiếu được thì để null hoặc đẩy sang human review.

// Ví dụ Schema trích xuất hóa đơn an toàn chống bịa dữ liệu
{
  "name": "extract_invoice",
  "description": "Trích xuất thông tin từ hóa đơn thô.",
  "input_schema": {
    "type": "object",
    "properties": {
      "invoice_number": { "type": "string" },
      "total": { "type": "number" },
      "due_date": { 
        "type": ["string", "null"],
        "description": "Để null nếu tài liệu không ghi ngày hạn — tuyệt đối không suy đoán"
      },
      "category": { "enum": ["hardware", "software", "service", "unclear", "other"] },
      "category_detail": { 
        "type": ["string", "null"],
        "description": "Bắt buộc điền chi tiết khi category = other"
      }
    },
    "required": ["invoice_number", "total"]
  }
}

#🧠 Phân tích & Thực tế từ Delivery Manager:

Nếu không đưa giá trị "unclear" vào enum của schema, Claude sẽ bị ép buộc phải chọn một trong các danh mục có sẵn ngay cả khi tài liệu nguồn bị rách hoặc mờ. Điều này làm tăng tỷ lệ dữ liệu sai lệch đi vào database. Thiết kế schema thông minh là phải luôn có "van xả" an toàn cho mô hình.

#Task 4.4: Triển khai validation, retry và feedback loop cho chất lượng trích xuất

#Kiến thức cần nắm

• Retry kèm feedback: Nối lỗi validation cụ thể vào prompt lượt sau để mô hình tự sửa (self-correct).
• Hạn chế của retry: Retry vô ích khi thông tin thực sự không có trong tài liệu nguồn (khác với lỗi định dạng).
• Feedback loop vận hành: Theo dõi các pattern lỗi bị dev từ chối (dismiss) để liên tục cải tiến hệ thống.
• Lỗi ngữ nghĩa (Semantic errors): Phân biệt lỗi validation ngữ nghĩa (logic nghiệp vụ sai) vs lỗi cú pháp (đã được lọc bởi tool use).

#Kỹ năng cần làm được

• Xây dựng follow-up sửa lỗi: Gửi request gồm tài liệu gốc + bản trích xuất lỗi + thông báo lỗi validation chi tiết.
• Thiết kế tự kiểm chứng: Thiết kế trích xuất trường calculated_total song song với stated_total để so sánh chênh lệch; thêm boolean conflict_detected nếu dữ liệu nguồn mâu thuẫn.
• Nhận diện khả năng phục hồi của retry: Phân biệt rõ khi nào cuộc gọi retry sẽ thành công (lỗi cấu trúc, sai định dạng JSON) và khi nào retry sẽ hoàn toàn vô ích (thông tin thực sự không tồn tại trong tài liệu nguồn) để chuyển tiếp thẳng sang duyệt tay, tiết kiệm chi phí API.
• Thu thập pattern lỗi thông qua feedback loop: Bổ sung trường detected_pattern hoặc false_positive_reason vào các kết quả trích xuất bị nhà phát triển hoặc kiểm duyệt viên từ chối để thu thập dữ liệu phục vụ tinh chỉnh prompt định kỳ.

#🧠 Phân tích & Thực tế từ Delivery Manager:

Một vòng lặp retry vô hạn khi tài liệu nguồn thiếu thông tin là cách nhanh nhất để đốt sạch ngân sách dự án. Lập trình viên của tôi phải code logic kiểm tra: nếu lỗi validation thuộc dạng "thiếu thông tin nguồn", hệ thống lập tức ngắt luồng và route sang cho người duyệt thay vì cố bắt Claude chạy lại 3 lần.

#Task 4.5: Thiết kế chiến lược batch processing hiệu quả

#Kiến thức cần nắm

• Message Batches API: Tiết kiệm 50% chi phí, thời gian xử lý cửa sổ lên tới 24 giờ, không có SLA về độ trễ tức thời.
• Workload phù hợp: Phù hợp với tác vụ không chặn, chịu trễ (báo cáo qua đêm, audit tuần). Không phù hợp với merge check chặn dev.
• Giới hạn tính năng: Không hỗ trợ gọi tool tương tác qua lại nhiều lượt (multi-turn tool calling) trong một request — đúng với client tool, không đúng với server tool; xem đính chính cuối mục.
• custom_id: Sử dụng trường custom_id để đối chiếu cặp request/response trong batch.
• Vòng đời một batch (polling for completion): Batch là bất đồng bộ, không có callback — nộp xong không ai gọi lại cho bạn. Chu trình là tạo batch → lưu lại batch id trả về → định kỳ hỏi lại trạng thái (poll) → khi processing_status chuyển sang ended thì tải kết quả về → ghép từng dòng kết quả với request gốc bằng custom_id. Kết quả trả theo dòng, mỗi dòng mang một result.type riêng (succeeded / errored / canceled / expired), nên phải duyệt từng dòng chứ không thể coi "batch ended" là "mọi request đều thành công".

#Kỹ năng cần làm được

• Khớp API với Latency SLA: Chọn API đồng bộ cho tác vụ tức thời, Batch API cho tác vụ định kỳ.
• Xử lý lỗi Batch: Chỉ resubmit các request bị lỗi (nhận diện qua custom_id) kèm theo sửa đổi (VD: cắt nhỏ file quá dung lượng context).
• Thiết kế bước lấy kết quả: Vì không có callback, phía consumer phải là một job chủ động poll theo chu kỳ hợp lý rồi mới đọc kết quả — không phải một endpoint ngồi chờ. Đây cũng là lý do Batch không lắp được vào luồng chặn người dùng: bạn chỉ điều khiển được tần suất hỏi, không điều khiển được thời điểm xong.
• Tính toán tần suất gửi Batch theo SLA: Thiết kế tần suất gửi batch dựa trên cam kết SLA của sản phẩm (VD: cấu hình gửi batch mỗi 4 giờ một lần để đảm bảo hoàn thành tổng cam kết SLA 30 giờ với khách hàng, trong bối cảnh Batch API xử lý mất tối đa 24 giờ).
• Chạy thử nghiệm trên tập mẫu (Prompt Refinement): Thực hiện chạy thử và tinh chỉnh prompt trên một tập mẫu nhỏ (sample set) trước khi ném toàn bộ dữ liệu lớn vào Batch API nhằm tối đa hóa tỷ lệ thành công ngay lần chạy đầu tiên, tránh chi phí chạy lại khổng lồ.

⚠️ Đính chính (docs 08/2026) — "Batch không chạy được tool" là nói quá. Gạch đầu dòng "Giới hạn tính năng" ở trên đúng với client tool, nhưng sai nếu hiểu thành mọi loại tool, và đề thi rất hay khai thác đúng khoảng mờ này.

Server tool (web search, web fetch, code execution, MCP connector, advisor, tool search) do Anthropic thực thi ngay trong request. Docs ghi rõ: trong batch, agentic loop chạy y như request đồng bộ, chỉ khác là trần số vòng lặp mỗi lượt cao hơn; chạm trần thì response kết thúc bằng stop_reason: "pause_turn" và bạn nộp tiếp một request nữa để đi tiếp.

Client tool — tool do chính bạn host — mới là thứ batch không làm được trong một request. Vòng đời của nó là tool_use → ứng dụng của bạn chạy tool → gửi lại tool_result, mà một batch request đã nộp thì không có đường quay lại để nhận tool_result.

Hai con số hay bị hỏi kèm, tra ngày 26/08/2026: một batch giới hạn 100.000 request hoặc 256 MB, chạm cái nào trước tính cái đó; và request rơi vào errored / canceled / expired thì không bị tính tiền — chỉ request chạy xong mới tính.

#🧠 Phân tích & Thực tế từ Delivery Manager:

Dưới góc độ chi phí, Batch API là một món hời lớn. Tuy nhiên, nếu bạn gửi một batch 10.000 tài liệu mà prompt chưa được tối ưu, bạn sẽ nhận về 10.000 kết quả lỗi và vẫn phải trả 50% tiền. Quy trình chuẩn của tôi là bắt buộc chạy thử nghiệm và đạt độ chính xác >95% trên tập 100 tài liệu mẫu trước khi nhấn nút chạy batch lớn.

#Task 4.6: Thiết kế kiến trúc review đa instance và đa pass

#Kiến thức cần nắm

• Giới hạn của self-review: Mô hình giữ nguyên ngữ cảnh suy luận khi sinh code nên rất khó tự phát hiện lỗi logic của chính mình trong cùng một session.
• Review độc lập: Instance thứ hai hoàn toàn độc lập (không mang theo context sinh code) bắt lỗi logic tinh vi tốt hơn hẳn.
• Multi-pass review: Tách PR lớn thành pass đọc từng file (lỗi cục bộ) và pass tích hợp (lỗi cross-file), tránh loãng attention của mô hình.

#Kỹ năng cần làm được

• Triển khai review chéo: Cấu hình instance Claude thứ hai thực hiện review độc lập.
• Phân rã pass review: Chia PR thành các luồng kiểm tra độc lập để tăng độ sâu phân tích.
• Tự đánh giá độ tự tin (Confidence self-reporting): Yêu cầu mô hình tự báo cáo điểm tự tin (confidence score) kèm theo mỗi lỗi phát hiện được để hệ thống phân loại và định tuyến thông minh (VD: chỉ đẩy các phát hiện có confidence thấp sang luồng người duyệt kiểm tra lại).

#🧠 Phân tích & Thực tế từ Delivery Manager:

Khi xây dựng hệ thống kiểm tra bảo mật tự động cho PR, chúng tôi tích hợp bước check chéo: Agent 1 quét lỗi và Agent 2 (chạy độc lập) đánh giá lại lỗi đó kèm điểm tự tin. Nếu Agent 2 đánh giá lỗi này có độ tự tin thấp, hệ thống sẽ tự động gạt bỏ để tránh làm phiền dev, giữ cho pipeline luôn sạch sẽ và có giá trị cao.

Quay lại Trang Hub ôn thi CCA-F.

Nguồn: Claude Certified Architect – Foundations Certification Exam Guide (Anthropic, Version 1.0 — hiệu lực 07/2026) — Copyright Anthropic. Phần đề thi thử cho kỳ thi này nằm ở tab "Đề thi thử" trên trang hub ôn thi.