Xử lý đầu ra - structured outputs, kiểm tra, đọc phòng thủ, hoài nghi câu trả lời tự tin

Đầu ra của Claude thường không dừng ở màn hình: nó được đổ vào database, dashboard, hệ thống khác. Ở đó một trường thiếu có thể làm sập cả pipeline, và một con số sai nhưng viết rất tự tin có thể được coi là sự thật.

Bài này giúp bạn trả lời: làm sao lấy được đầu ra đúng khuôn, kiểm nó thế nào trước khi chuyển đi, và khi nào không nên tin câu trả lời dù nó nghe rất chắc chắn?

Ví dụ xuyên suốt: công ty khảo sát thị trường

Một công ty khảo sát thị trường nhận khoảng 2.000 câu trả lời mở mỗi ngày ("Bạn nghĩ gì về bao bì mới?"). Claude đọc từng câu, trả về JSON: chủ đề, cảm xúc (tích cực, trung tính, tiêu cực), và một câu trích nguyên văn. Kết quả đổ thẳng vào dashboard của khách hàng.

Vấn đề tháng trước: thỉnh thoảng JSON hỏng làm job đêm dừng giữa chừng; dashboard có lúc hiện câu trích dẫn mà người trả lời không hề viết; và trong bản tóm tắt tuần, Claude viết rất chắc "62% người trả lời khen màu sắc" dù con số đó không có trong dữ liệu.

Vì sao JSON xin bằng prompt vẫn hỏng

Docs structured outputs nói: không có tính năng này, kể cả prompt kỹ, Claude vẫn có thể trả JSON sai cú pháp, thiếu trường bắt buộc, sai kiểu dữ liệu. Có hai cách bảo đảm đúng schema bằng giải mã có ràng buộc (constrained decoding), tức là chỉ cho model sinh những token hợp với schema:

Đề thi gọi nhóm kỹ thuật này là các mẫu đầu ra có cấu trúc (structured output patterns).

Vẫn phải kiểm trước khi chuyển đi

Structured outputs bảo đảm đúng schema trong hầu hết trường hợp, nhưng docs liệt kê vài lúc đầu ra vẫn có thể lệch:

• Từ chối (stop_reason: "refusal"): API vẫn trả 200, vẫn tính tiền, và lời từ chối được ưu tiên hơn schema.
• Hết token (stop_reason: "max_tokens"): đầu ra bị cắt, có thể không đủ schema. Thử lại với max_tokens lớn hơn.
• Chữ hoa chữ thường của giá trị enum không được bảo đảm: có thể nhận "Tich_cuc" thay vì "tich_cuc".

Ngoài ra schema chỉ kiểm hình dạng, không kiểm nghĩa. Một câu trích dẫn đúng kiểu chuỗi vẫn có thể không có trong câu trả lời gốc. Vì vậy cần một bước kiểm đầu ra (response validation) đặt ngay sau lời gọi, nơi còn sửa hay gọi lại được: kiểm stop_reason, kiểm schema, rồi kiểm luật nghiệp vụ (câu trích phải xuất hiện nguyên văn trong câu trả lời gốc).

Đọc phòng thủ

Đề thi gọi đây là đọc phòng thủ (defensive parsing): code nhận đầu ra phải chịu được ba kiểu lệch hay gặp, trường lạ, thiếu giá trị, sai kiểu, thay vì sập.

def doc_ket_qua(raw: dict) -> dict | None:
    cam_xuc = str(raw.get("cam_xuc", "")).lower()          # chuẩn hoá chữ hoa
    if cam_xuc not in {"tich_cuc", "trung_tinh", "tieu_cuc"}:
        return None                                       # sang nhánh thử lại / người duyệt
    trich = raw.get("trich_dan") or ""
    if trich and trich not in cau_tra_loi_goc:
        trich = ""                                        # bỏ trích dẫn không có trong nguồn
    return {"chu_de": raw.get("chu_de", "khac"), "cam_xuc": cam_xuc, "trich_dan": trich}

Đọc phòng thủ không có nghĩa là lặng lẽ vứt đầu ra hỏng. Bản ghi không đọc được phải đi vào một nhánh có xử lý (thử lại, dự phòng, người duyệt) và được đếm, để biết tỉ lệ hỏng đang tăng hay giảm.

Hoài nghi câu trả lời nghe chắc chắn

Model sinh câu trôi chảy và tự tin kể cả khi sai (bài 5.1). Giọng văn chắc chắn không nói gì về độ đúng. Đề thi gọi thái độ cần có là hoài nghi đầu ra tự tin (skepticism toward confident output). Docs về giảm bịa đặt đưa ra các cách:

Con số phần trăm thì tốt nhất là đừng để Claude tự ước: code đếm từ dữ liệu đã phân loại, Claude chỉ viết lời.

1. stop_reason là refusal hay max_tokens?Xử lý riêng, không đọc như đầu ra bình thường
2. Không đúng schema sau khi đọc phòng thủ?Thử lại có giới hạn, rồi dự phòng hoặc người duyệt
3. Đúng schema nhưng sai luật nghiệp vụ?Sửa tại chỗ hoặc gửi người duyệt
4. Có nhận định, con số không có dẫn chứng?Rút lại hoặc để code tính
5. Còn lạiChuyển cho hệ thống phía sau