Bạn muốn AI đọc phản hồi của khách hàng và tạo một bản nháp ticket. Model trả về JSON hợp lệ, giao diện hiển thị được, nhưng ticket lại có độ ưu tiên do model tự đoán và dẫn tới một tin nhắn không tồn tại. Parse thành công mới giải quyết được bước đầu của bài toán.
Bài này xây một cổng kiểm tra nhỏ cho dữ liệu trích xuất. Mục tiêu là giữ lại trường chưa biết, phát hiện dữ liệu ngoài hợp đồng và đưa ca thiếu bằng chứng về hàng chờ rà soát. Ví dụ không phụ thuộc nhà cung cấp model. Tài liệu JSON Schema được đối chiếu ngày 23/10/2026; đoạn Python dùng thư viện chuẩn, cần kiểm tra trên phiên bản Python đang được hỗ trợ của dự án.
Tách ba lớp kiểm tra
Lớp cú pháp trả lời câu hỏi chuỗi có phải JSON hay không. Lớp schema kiểm tra tên trường, kiểu dữ liệu và tập giá trị cho phép. Lớp nghiệp vụ kiểm tra dữ liệu có phù hợp với ngữ cảnh mà ứng dụng đã cung cấp không.
Một chuỗi evidenceIds đúng kiểu vẫn có thể chứa ID do model tự nghĩ ra. Ngược lại, priority: null có thể là kết quả đúng khi phản hồi chưa đủ thông tin. Đừng tự đổi mọi giá trị thiếu thành normal, vì cách sửa đó che mất sự không chắc chắn.
Giả sử đầu vào chỉ có tin nhắn msg-17 nói rằng đăng nhập lỗi trên Android. Đầu ra mong muốn là một đề xuất để người xử lý kiểm tra, chưa phải ticket được tự động phân công hay đóng dấu đã xác nhận.
Đặt hợp đồng dữ liệu rõ ràng
Đây là schema minh họa theo JSON Schema Draft 2020-12. required yêu cầu trường phải xuất hiện; additionalProperties kiểm soát trường ngoài hợp đồng. Hai việc này độc lập với khai báo properties.
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"required": ["summary", "priority", "evidenceIds"],
"additionalProperties": false,
"properties": {
"summary": {"type": "string", "minLength": 1, "maxLength": 200},
"priority": {"enum": ["low", "normal", "high", null]},
"evidenceIds": {
"type": "array", "minItems": 1, "maxItems": 10,
"uniqueItems": true, "items": {"type": "string"}
}
}
}Giới hạn 200 ký tự và 10 nguồn là lựa chọn của ví dụ, không phải ngưỡng chung cho mọi sản phẩm. Nếu API model chỉ hỗ trợ một phần JSON Schema, cần đối chiếu tập keyword của API đó. Dù dùng cơ chế sinh đầu ra có cấu trúc, backend vẫn phải kiểm tra lại dữ liệu nhận được.
Kiểm tra bằng chứng bằng ngữ cảnh đáng tin
Đoạn sau minh họa kiểm tra ứng dụng bằng Python; nó không phải một thư viện thực thi toàn bộ JSON Schema. Trong sản phẩm có nhiều schema, nên dùng validator tương thích draft đã chọn và kiểm thử cấu hình của validator đó.
def validate_ticket(data, allowed_ids):
if not isinstance(data, dict):
raise ValueError("Ticket must be an object")
if set(data) != {"summary", "priority", "evidenceIds"}:
raise ValueError("Unexpected or missing fields")
summary = data["summary"]
if not isinstance(summary, str) or not 1 <= len(summary) <= 200:
raise ValueError("Invalid summary")
if not summary.strip():
raise ValueError("Blank summary")
if data["priority"] not in [None, "low", "normal", "high"]:
raise ValueError("Invalid priority")
ids = data["evidenceIds"]
if not isinstance(ids, list) or not 1 <= len(ids) <= 10:
raise ValueError("Invalid evidence list")
if not all(isinstance(item, str) for item in ids):
raise ValueError("Evidence IDs must be strings")
if len(set(ids)) != len(ids) or not set(ids) <= set(allowed_ids):
raise ValueError("Unknown or repeated evidence")
return {"needs_review": data["priority"] is None}allowed_ids do ứng dụng lấy từ các tin nhắn thực sự gửi vào lượt trích xuất, không lấy từ lời khẳng định của model. Nguồn tồn tại vẫn chưa chứng minh câu tóm tắt đúng; người rà soát cần mở lại đoạn gốc. Với dữ liệu dài, giữ thêm vị trí đoạn và phiên bản tài liệu để việc kiểm tra không phụ thuộc một URL thay đổi theo thời gian.
Bộ ca kiểm tra trước khi nối luồng lưu
Thử một đề xuất hợp lệ với priority bằng null: hàm phải chấp nhận cấu trúc và giữ cờ cần rà soát. Sau đó lần lượt thêm trường lạ, bỏ trường bắt buộc, dùng ưu tiên urgent, lặp ID, đưa ID ngoài đầu vào và dùng chuỗi chỉ gồm khoảng trắng. Những ca này phải bị từ chối bằng lỗi có thể xử lý.
Các fixture chỉ kiểm tra cổng dữ liệu, không đo chất lượng model. Muốn đánh giá model, cần một tập phản hồi riêng với đáp án được người có trách nhiệm rà soát. Tách tỷ lệ sai schema khỏi tỷ lệ diễn giải sai nội dung để biết nên sửa hợp đồng, prompt hay quy trình duyệt.
Lỗi dễ gặp trong luồng thực tế
Đừng dùng biểu thức chính quy để cắt đại phần nằm giữa hai dấu ngoặc rồi coi đó là hợp lệ. Giới hạn kích thước phản hồi trước khi parse và xử lý lỗi cú pháp riêng. Cũng không tự thực thi lệnh, mở URL hay quyết định quyền truy cập từ trường do model sinh.
Nếu phải thử lại, giới hạn số lần và ghi lý do từ chối đã loại thông tin riêng tư. Không đưa toàn bộ phản hồi khách hàng vào log lỗi. Khi hết lượt thử, giữ bản nháp và yêu cầu bổ sung thông tin thay vì lặng lẽ đổi dữ liệu cho qua kiểm tra.
Kết luận
Hợp đồng JSON giúp ứng dụng hiểu hình dạng đầu ra. Kiểm tra bằng chứng và quy tắc nghiệp vụ giúp xác định dữ liệu có đáng đưa sang bước tiếp theo hay không. Một giá trị thiếu được biểu diễn rõ thường hữu ích hơn một giá trị được model đoán cho đầy đủ.
