4.4 Validation, Retry, and Feedback Loops

Những gì cần nắm

Hệ thống extraction chạy production thì sẽ hỏng. Tài liệu về ở định dạng không lường trước, số liệu cộng không khớp, dữ liệu rơi vào sai field. Câu hỏi không phải là có hỏng hay không, mà là hệ thống phản ứng thế nào. Pattern validation-retry biến những lần hỏng đó thành quy trình tự sửa.

Retry-with-error-feedback

Pattern retry đúng gửi lại cho model ba thứ:

Tài liệu gốc — để model có nguồn mà soi lại
Kết quả extraction đã hỏng — để model thấy chính nó đã tạo ra cái gì
Lỗi validation cụ thể — để model biết chính xác sai ở đâu

// 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 này hơn hẳn retry ngây thơ. Không có lỗi cụ thể, model không biết phải sửa gì và thường lặp lại đúng sai lầm cũ. Có lỗi cụ thể, model nhắm được vào việc tự sửa: soi lại tài liệu tìm line item bị bỏ sót, kiểm tra vị trí field, tính lại tổng.

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

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

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

Lệch định dạng (sai format ngày tháng, ký hiệu tiền tệ không nhất quán)
Lỗi cấu trúc output (giá trị nằm sai field, lồng sai cấp)
Giá trị đặt nhầm chỗ (dữ liệu có trong tài liệu nhưng bị extract vào sai field)
Lỗi tính toán (model bỏ sót một line item làm lệch tổng)

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

Thông tin thật sự không có trong tài liệu gốc
Dữ liệu chỉ tồn tại ở một tài liệu khác không được đưa cho model
Field đòi hỏi kiến thức mà model không có

Đề thi đưa cả hai loại tình huống và bắt bạn chỉ ra cái nào sửa được. Nếu tài liệu thật sự không có tên phòng ban thì retry bao nhiêu lần cũng không ra giá trị đúng. Hãy đánh dấu bản extraction đó cho human review, hoặc trả về null nếu schema cho phép.

Thiết kế luồng tự sửa

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

calculated_total và stated_total: Extract cả tổng do model tự cộng từ từng line item lẫn tổng ghi trong tài liệu. Khi hai con số lệch nhau, bạn có ngay một cờ phát hiện mâu thuẫn mà không cần logic bên ngoài.

{
  "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 field boolean báo hiệu khi tài liệu gốc chứa thông tin mâu thuẫn. Ví dụ nếu một tài liệu ghi “payment due: 30 days” ở mục này nhưng “payment terms: net 60” ở mục khác, model nên extract cả hai và set conflict_detected: true thay vì lặng lẽ chọn một.

Field detected_pattern

Với pipeline code review và phân tích, hãy thêm field detected_pattern vào các phát hiện có cấu trúc. Field 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.

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

Khi developer bỏ qua các phát hiện, bạn phân tích được pattern bị bỏ qua theo detected_pattern. Nếu developer liên tục bỏ qua những phát hiện kích hoạt bởi “variable shadowing in nested scope”, pattern đó nhiều khả năng cần chỉnh lại prompt. Cách này tạo ra một vòng cải thiện có hệ thống: extract, validate, thu thập dữ liệu về phát hiện bị bỏ qua, chỉnh prompt, lặp lại.

Lỗi cú pháp schema và lỗi validation ngữ nghĩa

Đề thi phân biệt rõ hai nhóm lỗi này:

Lỗi cú pháp schema — JSON hỏng, thiếu field bắt buộc, sai kiểu dữ liệu. Bị loại bỏ hoàn toàn bởi tool_use kèm JSON schema (xem Task Statement 4.3).

Lỗi validation ngữ nghĩa — Cấu trúc JSON đúng nhưng giá trị sai. Line item cộng không khớp, ngày tháng sai thứ tự, giá trị nằm sai field. Nhóm này cần logic validation nằm ngoài schema và là trọng tâm của retry loop.

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

Pydantic làm tầng validation

Exam guide nhắc Pydantic song song với JSON Schema trong bài thực hành của task statement này: “when Pydantic or JSON schema validation fails, send a follow-up request including the document, the failed extraction, and the specific validation error.” Trong một pipeline Python, Pydantic là tầng biến “validation failed” thành đúng những thông báo lỗi cụ thể theo từng field mà retry loop cần.

Một model Pydantic làm hai việc cùng lúc. Khâu parsing cưỡng chế cấu trúc — kiểu dữ liệu, field bắt buộc, enum. Các validator cưỡng chế ngữ nghĩa — những quy tắc mà JSON schema không diễn đạt nổi, như tính toán liên field hay thứ tự ngày tháng. Cả hai loại lỗi đều lộ ra qua cùng một ValidationError, kèm các lỗi đọc được bằng máy, nói rõ field nào và quy tắc nào bị vi phạm:

import json
from pydantic import BaseModel, ValidationError, model_validator

class LineItem(BaseModel):
    description: str
    amount: float

class Invoice(BaseModel):
    line_items: list[LineItem]
    stated_total: float

    @model_validator(mode="after")
    def totals_must_match(self):
        calculated = round(sum(i.amount for i in self.line_items), 2)
        if abs(calculated - self.stated_total) > 0.01:
            raise ValueError(
                f"line items sum to {calculated} but stated_total is {self.stated_total}"
            )
        return self

try:
    invoice = Invoice.model_validate(tool_input)  # the tool_use input from the response
except ValidationError as e:
    errors = "\n".join(
        f"{'.'.join(map(str, err['loc'])) or 'invoice'}: {err['msg']}" for err in e.errors()
    )
    retry_message = (
        f"Original document:\n{original_document}\n\n"
        f"Your extraction:\n{json.dumps(tool_input)}\n\n"
        f"Validation errors:\n{errors}\n\n"
        f"Please re-extract, fixing the identified errors."
    )

Nhánh except chính là pattern retry-with-error-feedback ở đầu bài — Pydantic chỉ cung cấp thành phần thứ ba (lỗi cụ thể) ở dạng bạn format thẳng vào prompt được. Ranh giới hiệu quả của retry vẫn nguyên: một validator fail vì thông tin không có trong tài liệu gốc thì vẫn là ca cho human review, không phải retry.

Bẫy thi

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

Pipeline extraction của bạn kiểm tra rằng tổng các line item khớp với tổng ghi trong tài liệu. Với Tài liệu A, tổng tính được là £450 nhưng tổng ghi là £500. Với Tài liệu B, field ‘department’ hoàn toàn không có trong văn bản gốc. Chiến lược retry nào là đúng?

A. Retry cả hai tài liệu kèm lỗi validation, yêu cầu model extract lại toàn bộ field
B. Bỏ retry cho cả hai và đẩy hết sang human review cho chắc chắn chính xác
C. Retry cả hai với cùng prompt cũ, vì extraction không tất định nên lần thứ hai có thể thành công
D. Retry Tài liệu A kèm lỗi lệch tổng; đẩy Tài liệu B sang human review vì thông tin không có trong nguồn

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

Đúng: D

A — Tài liệu B không thể sửa bằng retry — thông tin phòng ban không tồn tại trong nguồn. Retry vừa tốn token vừa dễ tạo ra một giá trị bịa.
B — Tài liệu A có một lệch tổng nhiều khả năng sửa được. Bỏ retry là lãng phí khả năng tự sửa của model với đúng loại lỗi mà nó sửa được.
C — Tính không tất định không tạo ra được thông tin vốn không tồn tại. Tài liệu A có thể hưởng lợi từ retry có định hướng; Tài liệu B thì thử bao nhiêu lần cũng vậy.
D — Tài liệu A có lệch tổng sửa được — model nhiều khả năng bỏ sót một line item. Tài liệu B thiếu thông tin thật sự nên retry vô ích. Hãy đẩy sang human review hoặc chấp nhận null.

Nguồn

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

Exam Simulator

Sáu câu trắc nghiệm theo format đề thi về Validation, Retry, and Feedback Loops. Chọn đáp án trước, rồi mở phần giải thích.

Câu 1

Pipeline extraction của bạn kiểm tra rằng tổng các line item khớp với tổng ghi trong tài liệu. Với Tài liệu A, tổng tính được là £450 nhưng tổng ghi là £500. Với Tài liệu B, field “department” hoàn toàn không có trong văn bản gốc. Chiến lược retry nào là đúng?

A. Retry Tài liệu A kèm lỗi lệch tổng, và đẩy Tài liệu B sang human review vì dữ liệu không có trong nguồn
B. Retry cả hai tài liệu kèm lỗi validation, yêu cầu model extract lại toàn bộ field
C. Retry cả hai với cùng prompt cũ, vì extraction không tất định nên lần thứ hai có thể thành công
D. Bỏ retry cho cả hai và đẩy hết sang human review cho chắc chắn chính xác

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

Đúng: A

A đúng vì Tài liệu A có lệch tổng sửa được (model nhiều khả năng bỏ sót một line item), còn Tài liệu B thiếu thông tin thật sự nên retry vô ích.
B sai vì Tài liệu B không thể sửa bằng retry — thông tin phòng ban không tồn tại trong nguồn. Retry vừa tốn token vừa dễ tạo ra giá trị bịa.
C sai vì tính không tất định không tạo ra được thông tin vốn không tồn tại. Tài liệu A có thể hưởng lợi từ retry có định hướng; Tài liệu B thì không.
D sai vì Tài liệu A có lệch tổng nhiều khả năng sửa được. Bỏ retry là lãng phí khả năng tự sửa của model.

Câu 2

Một message retry nên chứa ba thứ nào để khả năng tự sửa đạt mức cao nhất?

A. Prompt gốc, confidence score của model, và một yêu cầu thử lại
B. Tài liệu gốc, bản extraction đã hỏng, và lỗi validation cụ thể
C. Bản extraction đã hỏng, một ví dụ đã sửa đúng, và chỉ dẫn bám theo ví dụ đó
D. Tài liệu gốc, danh sách mọi lỗi có thể xảy ra, và một mức temperature cao hơn

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

Đúng: B

A sai vì confidence score được calibrate tệ, còn prompt gốc một mình không cho model thấy cái gì đã sai.
B đúng vì model cần nguồn để soi lại, output hỏng của chính nó để thấy đã tạo ra cái gì, và lỗi cụ thể để biết chính xác phải sửa gì.
C sai vì đưa sẵn một ví dụ đã sửa làm mất nhu cầu tự sửa của model, và còn gieo thêm lỗi nếu ví dụ của bạn sai.
D sai vì liệt kê mọi lỗi có thể xảy ra thay vì lỗi cụ thể thì không cho model định hướng nào, còn temperature không cải thiện độ chính xác.

Câu 3

Schema extraction của bạn có hai field riêng calculated_total và stated_total. Model extract các line item cộng lại thành £720 và tài liệu cũng ghi tổng là £720. Field total_discrepancy được set thành true. Điều này cho thấy gì?

A. Extraction đúng nhưng model sai ở chỗ set cờ discrepancy
B. Model đã phát hiện đúng một sự lệch giữa line item và tổng
C. Schema cấu hình sai và hai field tổng nên gộp thành một
D. Có lỗi ngữ nghĩa — hai tổng khớp nhau nên total_discrepancy phải là false

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

Đúng: D

A sai vì đây không phải lỗi extraction mà là lỗi set cờ, và bản thân lỗi set cờ cũng là một lỗi ngữ nghĩa.
B sai vì không hề có lệch nào — hai tổng khớp nhau. Model đã set cờ sai.
C sai vì tách riêng hai field là điều kiện cần cho việc tự phát hiện lệch. Gộp lại là mất khả năng đó.
D đúng vì calculated_total và stated_total khớp nhau (đều £720), nên total_discrepancy phải là false. Đây là lỗi validation ngữ nghĩa, cần retry kèm lỗi cụ thể: “total_discrepancy set to true but calculated_total equals stated_total.”

Câu 4

Developer liên tục bỏ qua những phát hiện code review kích hoạt bởi pattern “variable shadowing in nested scope”. Phản ứng đúng là gì?

A. Gỡ hẳn phần phát hiện variable shadowing khỏi hệ thống review
B. Thêm ngưỡng confidence để lọc bỏ các phát hiện shadowing confidence thấp
C. Tinh chỉnh tiêu chí cho shadowing và thêm ví dụ phân biệt
D. Bắt developer phải nêu lý do cho mỗi lần bỏ qua

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

Đúng: C

A sai vì có những ca variable shadowing là bug thật. Gỡ cả hạng mục là mất luôn các phát hiện hợp lệ.
B sai vì ngưỡng confidence được calibrate tệ và không chạm tới nguyên nhân gốc của false positive.
C đúng vì việc theo dõi detected_pattern cho phép phân tích có hệ thống xem ca nào gây false positive, và tinh chỉnh tiêu chí bằng ví dụ code sẽ cải thiện precision cho đúng pattern đó.
D sai vì thêm ma sát vào quy trình của developer không cải thiện chất lượng phát hiện.

Câu 5

Loại lỗi nào sau đây sửa được bằng retry-with-error-feedback loop?

A. Một tài liệu thật sự không có mã số thuế của nhà cung cấp
B. Thông tin chỉ tồn tại ở một tài liệu khác không được đưa cho model
C. Một field cần tra cứu database bên ngoài mà model không truy cập được
D. Các line item cộng lại thành £450 trong khi tổng ghi là £500

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

Đúng: D

A sai vì thông tin thật sự không có trong nguồn thì retry không tạo ra được.
B sai vì dữ liệu ở một tài liệu khác không truy cập được, nên retry vô ích.
C sai vì dữ liệu bên ngoài mà model không với tới thì retry không sinh ra được.
D đúng vì lệch tổng gợi ý rằng model bỏ sót một line item vốn có trong tài liệu. Retry kèm lỗi lệch cụ thể hướng model soi lại nguồn.

Câu 6

Trong ngữ cảnh extraction bằng tool_use, lỗi cú pháp schema và lỗi validation ngữ nghĩa khác nhau ở chỗ nào?

A. Lỗi cú pháp schema bắt được lúc compile; lỗi ngữ nghĩa bắt được lúc runtime
B. tool_use loại bỏ lỗi cú pháp, nhưng không loại bỏ lỗi ngữ nghĩa
C. Cả hai loại lỗi đều bị tool_use kèm JSON schema chặt loại bỏ
D. Lỗi cú pháp schema là lỗi nhẹ; lỗi ngữ nghĩa là lỗi nghiêm trọng

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

Đúng: B

A sai vì đây không phải chuyện compile với runtime. tool_use chặn lỗi cú pháp ngay ở tầng API.
B đúng vì tool_use đảm bảo cấu trúc đúng schema (không có JSON hỏng) nhưng không kiểm chứng được tính đúng về ngữ nghĩa (giá trị có chính xác không, tổng có đúng không, dữ liệu có bị bịa không).
C sai vì tool_use chỉ loại bỏ lỗi cú pháp. Lỗi ngữ nghĩa vẫn còn và cần validation riêng.
D sai vì sự phân biệt nằm ở cơ chế phòng lỗi, không phải mức độ nghiêm trọng. Cả hai đều có thể nghiêm trọng.