Prompt Chaining và vòng lặp Validation-Retry

Những điều bạn cần biết

Các hệ thống trích xuất trong production sẽ gặp lỗi. Tài liệu có định dạng bất ngờ, giá trị số không cộng khớp, và các trường dữ liệu bị đặt sai chỗ. Câu hỏi không phải là liệu lỗi có xảy ra hay không, mà là hệ thống của bạn phản ứng thế nào khi chúng xảy ra. Task statement này trình bày mẫu validation-retry, biến các lần trích xuất thất bại thành những quy trình tự sửa lỗi.

Retry kèm phản hồi lỗi (retry-with-error-feedback)

Mẫu retry đúng cách sẽ gửi lại cho model ba thông tin sau:

1. Tài liệu gốc — để model có nguồn dữ liệu để xem xét lại
2. Kết quả trích xuất thất bại — để model thấy nó đã tạo ra cái gì
3. Lỗi validation cụ thể — để model biết chính xác điều gì đã sai

typescriptCopy

// Retry with error feedback
const retryMessages = [
  {
    role: "user",
    content: `Original document:\n${originalDocument}\n\n` +
      `Your extraction:\n${JSON.stringify(failedExtraction)}\n\n` +
      `Validation error: Line items sum to £450 but stated_total is £500. ` +
      `Please re-extract, ensuring all line items are captured.`
  }
];

Cách làm này hiệu quả hơn hẳn so với retry đơn giản. Nếu không có lỗi cụ thể, model không có bất kỳ hướng dẫn nào về việc cần sửa gì và thường lặp lại đúng sai lầm cũ. Khi có lỗi cụ thể, model có thể nhắm đúng mục tiêu để tự sửa — xem lại tài liệu để tìm các dòng chi tiết bị bỏ sót, kiểm tra việc đặt trường, hoặc tính lại tổng.

Ranh giới hiệu quả của retry

Đây là khái niệm mà đề thi kiểm tra gắt gao nhất trong task statement này. Retry có một ranh giới hiệu quả rất rõ ràng:

Retry CÓ hiệu quả với:

• Sai lệch định dạng (sai định dạng ngày tháng, ký hiệu tiền tệ không nhất quán)
• Lỗi output về cấu trúc (giá trị nằm sai trường, lồng nhau sai)
• Giá trị đặt sai chỗ (dữ liệu có tồn tại trong tài liệu nhưng bị trích xuất vào sai trường)
• Lỗi toán học (model bỏ sót một dòng chi tiết ảnh hưởng đến tổng)

Retry KHÔNG hiệu quả với:

• Thông tin thực sự không có trong tài liệu nguồn
• Dữ liệu chỉ tồn tại trong một tài liệu bên ngoài không được cung cấp cho model
• Các trường đòi hỏi kiến thức mà model không có

Đề thi đưa ra cả hai loại tình huống và mong bạn xác định được cái nào có thể sửa được. Nếu một tài liệu thực sự không chứa tên phòng ban, dù retry bao nhiêu lần cũng không thể tạo ra giá trị đúng. Hành động đúng là gắn cờ kết quả trích xuất đó để con người review, hoặc trả về null (nếu schema cho phép).

Thiết kế luồng tự sửa lỗi

Thay vì chỉ dựa vào logic validation bên ngoài, bạn có thể xây dựng khả năng tự sửa lỗi ngay trong chính schema trích xuất:

calculated_total so với stated_total: Trích xuất cả tổng mà model tự tính từ các dòng chi tiết riêng lẻ lẫn tổng được nêu trong tài liệu. Khi hai giá trị này khác nhau, bạn có ngay một cờ báo sai lệch tự động mà không cần logic bên ngoài.

jsonCopy

{
  "line_items": [
    { "description": "Widget A", "amount": 150.00 },
    { "description": "Widget B", "amount": 300.00 }
  ],
  "calculated_total": 450.00,
  "stated_total": 500.00,
  "total_discrepancy": true
}

Boolean conflict_detected: Thêm các trường boolean để gắn cờ khi tài liệu nguồn chứa thông tin mâu thuẫn. Ví dụ, nếu một tài liệu ghi "hạn thanh toán: 30 ngày" ở một mục nhưng "điều khoản thanh toán: net 60" ở mục khác, model nên trích xuất cả hai và đặt conflict_detected: true thay vì âm thầm chọn một trong hai.

Trường detected_pattern

Với các pipeline review và phân tích code, hãy thêm trường detected_pattern vào các kết quả có cấu trúc. Trường này ghi lại chính xác cấu trúc code nào đã kích hoạt mỗi phát hiện.

jsonCopy

{
  "finding": "Potential SQL injection vulnerability",
  "severity": "critical",
  "detected_pattern": "string concatenation in SQL query",
  "file": "user_service.py",
  "line": 42
}

Khi developer bác bỏ (dismiss) các phát hiện, bạn có thể phân tích các mẫu bác bỏ theo detected_pattern. Nếu developer liên tục bác bỏ các phát hiện được kích hoạt bởi "biến bị che khuất (shadowing) trong scope lồng nhau", mẫu đó nhiều khả năng cần được tinh chỉnh lại trong prompt. Điều này tạo ra một vòng lặp cải thiện có hệ thống: trích xuất, xác thực, thu thập dữ liệu bác bỏ, tinh chỉnh prompt, rồi lặp lại.

Lỗi cú pháp schema so với lỗi xác thực ngữ nghĩa

Đề thi phân biệt hai loại lỗi sau:

Lỗi cú pháp schema — JSON sai định dạng, thiếu trường bắt buộc, sai kiểu dữ liệu. Bị loại bỏ hoàn toàn bởi tool_use với JSON schema (đã trình bày ở Task Statement 4.2).

Lỗi xác thực ngữ nghĩa — Cấu trúc JSON đúng nhưng giá trị sai. Các dòng chi tiết không cộng khớp, ngày tháng có thứ tự sai lệch nhau, giá trị nằm sai trường. Những lỗi này cần logic xác thực nằm ngoài schema và là trọng tâm của các vòng lặp retry.

Sự chồng lấn giữa các task statement này là có chủ đích. Đề thi kiểm tra xem bạn có hiểu rằng tool_use giải quyết được loại lỗi thứ nhất nhưng không giải quyết được loại thứ hai hay không.

Bẫy thi

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

Không tìm thấy câu hỏi luyện tập "q-4-4-001".

Bài tập thực hành

Nguồn tham khảo

• Claude Certified Architect Foundations Exam Guide — Task Statement 4.4 — Anthropic
• Tool Use (Function Calling) — Anthropic
• Building with Claude API (Skilljar) — Anthropic