JSON Hợp Lệ Nhưng Dữ Liệu Sai: Năm Lỗi Nghiêm Trọng Mà LLM Structured Outputs Không Bao Giờ Phát Hiện

01 tháng 9, 2026·7 phút đọc

Constrained decoding đã giải quyết bài toán cú pháp JSON, nhưng lại tạo ra một điểm mù nguy hiểm: schema validation không thể đảm bảo dữ liệu đúng về mặt ngữ nghĩa. Bài viết phân tích năm lỗi phổ biến khiến pipeline AI vẫn trả về kết quả sai dù JSON hoàn toàn hợp lệ, đồng thời đề xuất chiến lược ba lớp phòng thủ để phát hiện chúng.

JSON Hợp Lệ Nhưng Dữ Liệu Sai: Năm Lỗi Nghiêm Trọng Mà LLM Structured Outputs Không Bao Giờ Phát Hiện

JSON Hợp Lệ Nhưng Dữ Liệu Sai: Năm Lỗi Nghiêm Trọng Mà LLM Structured Outputs Không Bao Giờ Phát Hiện

Constrained decoding đã giải quyết một vấn đề thực sự. Trước các phương pháp dựa trên ngữ pháp như Outlines và SGLang, việc lấy JSON hợp lệ từ mô hình ngôn ngữ là một vòng lặp thử-sai đầy khó chịu. Bạn phải prompt, parse, vấp phải dấu phẩy thừa, rồi prompt lại. Constrained decoding đã chấm dứt điều đó bằng cách ép buộc lựa chọn token qua một finite-state machine, đảm bảo mọi đầu ra đều parse được.

Các đội ngũ phát triển nhanh chóng áp dụng kỹ thuật này. Tỷ lệ tuân thủ schema đạt gần 100%. Và rồi, một giả định thầm lặng len lỏi vào các codebase sản xuất: nếu JSON xác thực với schema, thì dữ liệu là chính xác.

Nhưng các benchmark từ BAML lại cho thấy điều ngược lại. Trong các tác vụ function-calling, generation không ràng buộc với post-hoc parsing đạt độ chính xác 93,63%; constrained decoding trên cùng mô hình chỉ đạt 91,37%. JSON luôn hợp lệ lại kém chính xác hơn so với JSON đôi khi hỏng.

Tôi bắt đầu theo dõi vấn đề này sau khi một pipeline phân loại tôi xây dựng bắt đầu trả về các giá trị có vẻ hợp lý nhưng hoàn toàn bịa đặt, với tần suất khoảng 1 trên 12 lần chạy. JSON luôn parse thành công, Pydantic không bao giờ phàn nàn, và phải mất nhiều tuần tôi mới nhận ra, vì mọi kiểm tra downstream đều mang tính cấu trúc.

Mô tả các lỗi thường gặp trong structured outputsMô tả các lỗi thường gặp trong structured outputs

Năm lỗi nghiêm trọng vẫn tồn tại

Chúng đều tạo ra đầu ra hợp lệ về schema nhưng làm hỏng pipeline của bạn một cách âm thầm:

Ảo giác enum (Enum hallucination): Mô hình chọn một giá trị enum hợp lệ nhưng sai nghĩa. Ví dụ, với enum ưu tiên ["low", "normal", "high", "urgent"], ngữ pháp đảm bảo một trong bốn giá trị đó, nhưng không đảm bảo trọng số theo ngữ cảnh đầu vào. Mô hình có thể trả về "urgent" cho yêu cầu thông thường, và schema vẫn chấp nhận.

Bịa đặt tự tin (Confident fabrication): Các trường văn bản tự do trả về dữ liệu hợp lý nhưng không có thật. BAML đã chứng minh điều này bằng cách đưa ảnh một con voi làm hóa đơn: constrained decoding trả về một báo cáo chi tiêu đầy đủ, hợp lệ thay vì từ chối. Ràng buộc này loại bỏ khả năng mô hình từ chối hoặc bày tỏ sự không chắc chắn.

Mâu thuẫn giữa các trường (Cross-field contradiction): Schema validation kiểm tra từng trường riêng lẻ, không kiểm tra sự đồng nhất giữa chúng. Một extractor cảm xúc có thể trả về {"sentiment": "positive", "score": 0.1} — nhãn tích cực nhưng điểm gần bằng 0. Một parser ngày tháng có thể trả về {"start": "2026-03-15", "end": "2026-03-10"} với ngày kết thúc trước ngày bắt đầu. Cả hai đều vượt qua mọi kiểm tra từng trường, nhưng không có ý nghĩa khi nhìn ở mức bản ghi.

Sụp đổ phân phối (Distributional collapse): Mô hình hội tụ về các giá trị an toàn, chung chung trên nhiều đầu vào khác nhau. Constrained decoding thiên về các token có xác suất cao trong tập hợp hợp lệ, và các giá trị "mặc định an toàn" (như 0.95, "medium", "general") thường có xác suất cơ sở cao hơn. Tôi từng phát hiện điều này khi điểm tin cậy trong pipeline phân loại của mình nằm im ở 0.98 suốt ba tuần.

Ảo giác mảng (Array hallucination): Mô hình chống lại việc trả về mảng rỗng. [] là chuỗi token có xác suất thấp dưới constrained decoding vì ngữ pháp ưu tiên các đường dẫn tạo object. Khi schema yêu cầu trường items dạng mảng, mô hình sẽ bịa ra các phần tử thay vì trả về rỗng — dẫn đến kết quả "tìm thấy 3 kết quả" khi câu trả lời đúng là 0.

Schema validation giống như ổ khóa trên tủ hồ sơ: nó giữ cho các ngăn kéo ngăn nắp, nhưng không nói gì về việc giấy tờ bên trong có chính xác hay không.

Cái bẫy validation: Tại sao thêm nhiều quy tắc không giải quyết được vấn đề

Phản ứng đầu tiên là viết thêm quy tắc validation. Điều đó hiệu quả với các pattern đã biết: model_validator trong Pydantic bắt được start_date > end_date. Vấn đề nằm ở những lỗi bạn chưa thấy. Tính đúng đắn về cấu trúc là hữu hạn — bạn có thể liệt kê mọi hình dạng JSON hợp lệ. Nhưng tính đúng đắn về ngữ nghĩa là vô hạn — bạn không thể viết quy tắc cho một đáp án sai mà bạn chưa gặp bao giờ.

Một hướng tiếp cận đáng cân nhắc là resampling: để mô hình viết tự do, sau đó mới kiểm tra format. BAML cho thấy parse-and-retry vượt trội constrained decoding hơn 2 điểm phần trăm trên cùng mô hình. Bạn đánh đổi xác suất parse thành công ở lượt đầu để lấy độ chính xác cao hơn khi đầu ra parse được — dù latency từ các lần retry vẫn là câu hỏi mở ở quy mô lớn.

Ba lớp phòng thủ: Schema, Ngữ nghĩa, Không chắc chắn

Lớp 1 — Schema và kiểm tra cấu trúc: Thứ bạn đang có: Pydantic, JSON Schema, Zod. Bắt các lỗi kiểu dữ liệu, thiếu trường, enum sai cú pháp. Giữ lại — nó giải quyết tốt vấn đề cú pháp.

Lớp 2 — Bộ kiểm tra ngữ nghĩa: Các hàm ràng buộc liên trường mã hóa logic kinh doanh, ví dụ "nếu sentiment là positive thì score phải > 0.5". Bộ giám sát phân phối theo dõi entropy của giá trị theo thời gian — khi entropy tụt dưới ngưỡng, bạn phát hiện sụp đổ phân phối trước khi các chỉ số downstream lệch chuẩn.

Lớp 3 — Làm lộ sự không chắc chắn: Thêm trường confidence tùy chọn bên cạnh mỗi giá trị được trích xuất để mô hình thể hiện điều nó không biết. Benchmark CONSTRUCT của Cleanlab chỉ ra rằng chấm điểm độ tin cậy theo từng trường phát hiện lỗi trong structured outputs từ GPT-5 và Gemini chính xác hơn ước lượng confidence ở mức prompt. Với các trường nhạy cảm, hãy dùng LLM-as-judge: gọi mô hình thứ hai để đánh giá xem giá trị trích xuất có được hỗ trợ bởi đầu vào hay không.

Kiến trúc ba lớp phòng thủ cho pipeline AIKiến trúc ba lớp phòng thủ cho pipeline AI

Ba tín hiệu cho thấy pipeline của bạn đang thất bại âm thầm

Bạn không thể bắt những lỗi này bằng cách kiểm tra từng đầu ra. Các tín hiệu mang tính thống kê:

  • Entropy đầu ra giảm dần. Nếu một trường lẽ ra phải biến thiên giữa các đầu vào lại cụm về một hoặc hai giá trị, mô hình đang sụp đổ về các mặc định an toàn.
  • Không bao giờ có đầu ra rỗng. Nếu một trường mảng đôi khi nên rỗng nhưng không bao giờ trả về [], mô hình đang bịa đặt. So sánh tỷ lệ mảng rỗng với tỷ lệ cơ sở dự kiến.
  • Chỉ số downstream lệch mà không có thay đổi upstream. Nếu chỉ số kinh doanh thay đổi nhưng phiên bản mô hình, prompt và schema không đổi, độ chính xác ngữ nghĩa có thể đã suy giảm trong khi tuân thủ cấu trúc vẫn hoàn hảo. Đây là tín hiệu khó quy kết nhất, và thường là tín hiệu xuất hiện đầu tiên.

Kết luận: Schema là sàn nhà, không phải trần nhà

Hãy mặc định dùng constrained decoding để đảm bảo parse thành công. Nhưng hãy xây dựng các lớp kiểm tra ngữ nghĩa mà nó không bao giờ được thiết kế để cung cấp.

Schema validation sẽ không bao giờ cho bạn biết dữ liệu là đúng. Nó chỉ cho biết dữ liệu được định dạng đúng. Khoảng cách giữa hai khẳng định đó chính là nơi năm lỗi nghiêm trọng này sinh sống — và là nơi bạn cần đặt sự chú ý nếu muốn hệ thống AI của mình đáng tin cậy trong sản xuất.

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗