Kiểm tra, thử lại và vòng phản hồi cho trích xuất

Ở bài 4.3, schema chặt đã loại hết lỗi cú pháp. Nhưng kết quả đúng schema vẫn có thể sai: các dòng không cộng ra tổng, ngày ghi sai định dạng, giá trị nằm nhầm trường. Bạn cần một bước kiểm tra, và một cách cho Claude sửa lại khi kiểm tra không đạt.

Bài này giúp bạn trả lời: khi kết quả trích xuất sai, nên thử lại thế nào, và khi nào thử lại cũng vô ích?

Ví dụ xuyên suốt: hoá đơn nhà cung cấp của chuỗi cà phê

Một chuỗi cà phê nhận mỗi ngày vài trăm hoá đơn từ nhà cung cấp hạt cà phê, sữa, ly giấy. Hệ thống dùng Claude trích từng dòng hàng, tổng tiền, ngày hoá đơn, mã số thuế người bán, rồi kiểm tra trước khi đưa vào phần mềm kế toán. Bạn gặp:

1. Ngày hoá đơn có lúc ra "15/10" (thiếu năm), không qua được bước kiểm định dạng YYYY-MM-DD. Thử lại y nguyên thì vẫn ra như cũ.
2. Tổng các dòng hàng là 4.350.000 đồng, nhưng tổng tiền trích ra là 4.530.000 đồng. Không rõ Claude đọc sai hay hoá đơn bị viết sai.
3. Một số hoá đơn chỉ ghi "MST: theo hợp đồng số 12/2026". Mã số thuế nằm trong hợp đồng, mà hợp đồng không được gửi kèm. Hệ thống thử lại năm lần, lần nào cũng thất bại.

Thử lại kèm lỗi cụ thể

Thử lại y nguyên thì Claude không có thông tin gì mới, nên thường ra đúng kết quả cũ. Cách đúng là thử lại kèm lỗi kiểm tra (retry-with-error-feedback): gửi lại một yêu cầu mới gồm ba thứ:

1. Tài liệu gốc.
2. Kết quả trích xuất bị lỗi.
3. Lỗi kiểm tra cụ thể.

Hoá đơn gốc: (nội dung hoá đơn)
Kết quả lần trước: {"ngayHoaDon": "15/10", ...}
Lỗi: ngayHoaDon phải có dạng YYYY-MM-DD. Năm in ở góc phải trên cùng của hoá đơn.
Hãy trích lại.

Biết chính xác sai ở đâu, Claude sửa đúng chỗ đó: tìm năm trên hoá đơn và trả "2026-10-15". Tài liệu prompt của Anthropic mô tả mẫu tương tự là chuỗi tự sửa (self-correction): tạo bản nháp, cho Claude xem lại theo tiêu chí, rồi sửa; mỗi bước là một lần gọi API riêng để bạn ghi log, đánh giá hay rẽ nhánh được.

Khi nào thử lại vô ích

Vấn đề 3 khác hẳn vấn đề 1. Mã số thuế không có trong hoá đơn. Thử lại bao nhiêu lần, kèm lỗi cụ thể đến đâu, Claude cũng không thể trích ra một thông tin không có trong tài liệu. Ép quá thì còn có nguy cơ Claude bịa ra một mã số trông hợp lý.

Với loại cuối, đúng là để trường đó null, đánh dấu cần bổ sung, và chuyển cho người lấy hợp đồng ra tra, hoặc gửi kèm hợp đồng ở lần sau.

Lỗi về nghĩa và trường tự kiểm

Cần phân biệt hai loại lỗi:

• Lỗi cú pháp schema: JSON hỏng, thiếu trường, sai kiểu. Tool use với schema chặt đã loại bỏ loại này (bài 4.3).
• Lỗi về nghĩa (semantic validation errors): các số không cộng ra tổng, giá trị nằm nhầm trường. Schema không bắt được.

Vấn đề 2 là lỗi về nghĩa. Bạn có thể thiết kế schema để Claude tự lộ ra chỗ lệch:

{
  "dongHang": [ ... ],
  "stated_total": 4530000,
  "calculated_total": 4350000,
  "conflict_detected": true
}

• stated_total: tổng tiền in trên hoá đơn.
• calculated_total: tổng do Claude tự cộng từ các dòng hàng đã trích.
• conflict_detected: true khi dữ liệu trong tài liệu tự mâu thuẫn.

Hai tổng khác nhau thì hoá đơn đó được đánh dấu cho người kiểm. Nhờ vậy bạn không lặng lẽ nhập một con số sai vào sổ, mà cũng không phải kiểm tay mọi hoá đơn.

Vòng phản hồi: vì sao phát hiện bị bỏ qua

Cùng chuỗi cà phê có một bot review code cho phần mềm bán hàng. Dev thường bấm "bỏ qua" một số phát hiện, nhưng nhóm không biết vì sao. Cách làm là thêm trường detected_pattern vào mỗi phát hiện: ghi lại kiểu code nào đã khiến bot báo.

{ "file": "src/don-hang.ts", "dong": 57, "detected_pattern": "try_catch_rong", "moTa": "..." }

Sau vài tuần, bạn thống kê: phát hiện có detected_pattern là try_catch_rong bị bỏ qua 80%, vì nhóm cố ý nuốt lỗi ở chỗ ghi log. Giờ bạn biết chính xác phải sửa tiêu chí nào trong prompt, thay vì đoán mò.