Domain 4: Prompt Engineering & Structured Output — Ôn thi CCA-F

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

#Knowledge of (Kiến thức về)

• 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ể.
• 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.

#Skills in (Kỹ năng về)

• 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ộ).
• 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.
• 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.

#🧠 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

#Knowledge of (Kiến thức về)

• 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ê.
• 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).

#Skills in (Kỹ năng về)

• 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.
• 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.
• 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

#Knowledge of (Kiến thức về)

• 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).
• Thiết kế Schema mềm dẻo: Thiết kế trường required vs optional, enum kèm pattern "other" + chuỗi chi tiết đi kèm.

#Skills in (Kỹ năng về)

• 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).

// 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

#Knowledge of (Kiến thức về)

• 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).

#Skills in (Kỹ năng về)

• 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ả

#Knowledge of (Kiến thức về)

• 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.
• custom_id: Sử dụng trường custom_id để đối chiếu cặp request/response trong batch.

#Skills in (Kỹ năng về)

• 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).
• 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ồ.

#🧠 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

#Knowledge of (Kiến thức về)

• 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.

#Skills in (Kỹ năng về)

• 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.