Blog / AI / Deep Article
Giải thích cách constrained decoding và JSON Schema giúp AI xuất dữ liệu có cấu trúc, vì sao đúng định dạng chưa đồng nghĩa đúng sự thật và cách kiểm soát rủi ro.
Một hệ thống AI có thể trả lời bằng một đoạn văn rất thuyết phục, nhưng phần mềm nhận kết quả lại không đọc được. Chỉ cần thiếu dấu ngoặc kép, đặt sai tên trường hoặc trả về chữ giải thích ngoài JSON, cả quy trình xử lý tự động có thể thất bại. Đó là lý do Structured Outputs — đầu ra có cấu trúc — trở thành một thành phần quan trọng khi đưa mô hình ngôn ngữ vào ứng dụng thực tế. Tuy nhiên, cần phân biệt hai lời hứa rất khác nhau: tạo dữ liệu đúng cấu trúc và tạo thông tin đúng sự thật.
Tài liệu Microsoft Learn mô tả khả năng yêu cầu phản hồi tuân theo JSON Schema được khai báo. Tài liệu Guidance của Hugging Face giải thích một cách triển khai ở tầng sinh token: sử dụng ngữ pháp để hạn chế những token được phép chọn. Hai tài liệu giúp nhìn thấy cả trải nghiệm lập trình lẫn cơ chế kỹ thuật bên dưới. Chúng không chứng minh rằng mọi kết quả hợp lệ về định dạng đều chính xác về nội dung.
Giả sử một cơ quan muốn trích xuất thông tin từ công văn thành các trường: số văn bản, ngày ban hành, cơ quan ban hành và thời hạn phản hồi. Khi chỉ yêu cầu “hãy trả về JSON”, mô hình có thể tạo một đối tượng gần đúng, nhưng cũng có thể thêm lời dẫn, bỏ trường chưa tìm thấy hoặc dùng một tên trường khác. Con người vẫn hiểu, còn chương trình xử lý dữ liệu thì không nhất thiết.
Một hợp đồng dữ liệu rõ ràng định nghĩa tên trường, kiểu dữ liệu, giá trị được chấp nhận và quy tắc trường bắt buộc. Chẳng hạn, trường ngay_ban_hanh có kiểu chuỗi; trang_thai chỉ được nhận một trong ba giá trị xác định; so_van_ban có thể là chuỗi hoặc null nếu không có bằng chứng. Hợp đồng đó không phải một đoạn văn gợi ý, mà là một cấu trúc để phần mềm kiểm tra.
JSON Schema là một ngôn ngữ phổ biến để mô tả những ràng buộc như vậy. Với đầu ra có cấu trúc, ứng dụng có thể thiết kế trước dạng dữ liệu cần nhận thay vì cố đoán ý định của một câu trả lời tự do. AI trở thành một thành phần có giao diện xác định.
Nhưng cần nói chính xác: JSON Schema mô tả hình dạng dữ liệu, không phải sự thật của dữ liệu. Một ngày tháng có định dạng hợp lệ vẫn có thể là ngày tháng sai. Một mã đơn vị đúng kiểu chuỗi vẫn có thể không tồn tại trong cơ sở dữ liệu.
Mô hình ngôn ngữ tạo văn bản bằng cách dự đoán token tiếp theo từ ngữ cảnh. Khi chỉ dùng lời nhắc, mô hình có thể ưu tiên câu chữ tự nhiên, tự bổ sung giải thích hoặc tạo ký tự không phù hợp. Dù tỷ lệ lỗi nhỏ, khi chạy hàng nghìn lượt mỗi ngày, lỗi định dạng có thể tạo ra nhiều bản ghi cần sửa.
Một chiến lược đơn giản là tạo xong rồi kiểm tra. Nếu JSON sai, ứng dụng yêu cầu mô hình tạo lại. Cách này dễ triển khai nhưng có chi phí: thêm lượt suy luận, tăng độ trễ và vẫn không bảo đảm lần sau thành công. Với một chuỗi công việc có nhiều bước, mỗi lần tạo lại có thể kéo theo các tác vụ phía sau bị trì hoãn.
Structured Outputs xử lý vấn đề sớm hơn. Thay vì chỉ phát hiện lỗi sau khi toàn bộ câu trả lời đã được tạo, hệ thống có thể giới hạn lựa chọn trong lúc sinh. Điều này thường được gọi là constrained decoding — giải mã có ràng buộc. Ý tưởng cốt lõi là không cho mô hình chọn token khiến kết quả đi vào một trạng thái trái với cấu trúc đã khai báo.
Theo tài liệu Guidance của Hugging Face, ngữ pháp đầu ra được biên dịch thành một cơ chế theo dõi trạng thái. Mỗi lần mô hình tính xác suất cho các token tiếp theo, một bộ lọc sẽ che những token không hợp lệ theo ngữ pháp. Sau khi chọn token, trạng thái ngữ pháp được cập nhật để chuẩn bị cho bước tiếp theo.
Hãy tưởng tượng hệ thống đang tạo đối tượng có trường "approved" chỉ nhận true hoặc false. Sau khi sinh tên trường và dấu hai chấm, những chuỗi tùy ý không còn là lựa chọn hợp lệ ở vị trí đó. Khi đóng đối tượng, hệ thống cũng có thể ngăn xuất hiện một dấu phẩy thừa hoặc một trường không được phép, tùy tập ràng buộc đang hỗ trợ.
Cách mô tả này là mô hình khái niệm, không phải cam kết rằng mọi nhà cung cấp dùng cùng thuật toán. Một số hệ thống dùng bộ máy trạng thái hữu hạn, một số dùng kỹ thuật biên dịch ngữ pháp hoặc những biến thể khác. Điểm chung là ràng buộc được đưa vào đường sinh token, thay vì hoàn toàn phó mặc cho câu chữ của lời nhắc.
Với các ứng dụng sử dụng công cụ, cấu trúc cũng đặc biệt hữu ích. Một lời gọi công cụ cần tên hàm và các tham số có kiểu rõ ràng. Nếu AI tạo sai tên tham số hoặc thiếu trường bắt buộc, công cụ có thể từ chối ngay. Tuy nhiên, gọi đúng tên công cụ không đồng nghĩa thao tác được cấp quyền hay kết quả đáng tin: hệ thống thực thi vẫn phải kiểm tra quyền, điều kiện nghiệp vụ và hậu quả của hành động.
Giả sử một doanh nghiệp nhận hàng trăm hóa đơn điện tử. Mục tiêu là trích xuất mã số thuế, ngày lập, tổng tiền trước thuế, thuế suất và số tiền thanh toán. Đầu ra có cấu trúc giúp các trường luôn xuất hiện theo định nghĩa, đồng thời hạn chế tình trạng mô hình chèn thêm lời bình không cần thiết.
Nhưng hãy xét một hóa đơn có phần chữ mờ hoặc bảng hàng hóa bị cắt. Hệ thống có thể tạo ra một số tiền hoàn toàn hợp lệ về kiểu dữ liệu, trong khi con số đó không đọc được từ tài liệu. Nếu ứng dụng ghi thẳng vào sổ sách chỉ vì JSON hợp lệ, rủi ro nghiệp vụ vẫn tồn tại.
Thiết kế tốt hơn phải tách ba lớp. Lớp thứ nhất bảo đảm cấu trúc: các trường đúng kiểu, đúng tên. Lớp thứ hai xác minh nội dung: tổng tiền có khớp chi tiết, mã số thuế có đúng quy tắc và nguồn gốc từng trường có thể truy vết không. Lớp thứ ba quyết định hành động: bản ghi nào được nhập tự động, bản ghi nào cần người kiểm tra.
Đặc biệt, một giá trị null có chủ đích thường tốt hơn một con số được suy đoán. Nếu không có chứng cứ cho ngày lập, hệ thống nên biểu diễn sự thiếu thông tin thay vì tự điền một ngày có vẻ hợp lý. Đây là quy tắc thiết kế ứng dụng, không phải thuộc tính tự phát của mọi mô hình.
Hai khái niệm thường bị gộp làm một. JSON mode tập trung vào việc tạo một chuỗi có thể phân tích thành JSON hợp lệ. Structured Outputs đi xa hơn: kết quả phải phù hợp với một schema cụ thể trong phạm vi tính năng được hỗ trợ.
Ví dụ, đối tượng {"status":"maybe"} là JSON hợp lệ. Nhưng nếu schema chỉ chấp nhận "pending", "approved" hoặc "rejected", giá trị "maybe" không hợp lệ. Tương tự, một đối tượng có đủ dấu ngoặc nhưng thiếu trường document_id vẫn có thể bị từ chối nếu trường này bắt buộc.
Các triển khai Structured Outputs có giới hạn về tập JSON Schema được hỗ trợ, vì vậy cần kiểm tra danh sách tính năng của dịch vụ cụ thể. Điều đó có nghĩa nhà phát triển cần kiểm tra những từ khóa và giới hạn cụ thể trước khi thiết kế schema. Một schema hợp lệ ở thư viện kiểm tra độc lập chưa chắc được mọi dịch vụ sinh có ràng buộc chấp nhận nguyên trạng.
Ngoài ra, những trường hợp đặc biệt như mô hình từ chối trả lời hoặc đầu ra bị ngắt vì giới hạn độ dài cần được xử lý riêng. Ứng dụng không nên giả định rằng cứ có yêu cầu schema thì luôn nhận được một đối tượng nghiệp vụ hoàn chỉnh trong mọi tình huống.
Hiểu lầm đầu tiên là “đúng schema nghĩa là đúng dữ liệu”. Thực tế, schema chỉ chứng minh các ràng buộc hình thức đã được đáp ứng. Nó không xác nhận một trích dẫn tồn tại, một địa chỉ đúng hay một phép tính đã được đối chiếu. Những bước xác minh nghiệp vụ vẫn là trách nhiệm của hệ thống bên ngoài.
Hiểu lầm thứ hai là “schema càng chặt càng tốt”. Schema quá rộng khiến dữ liệu thiếu nhất quán, nhưng schema quá chặt có thể buộc mô hình lựa chọn trong một tập giá trị không phản ánh thực tế. Nếu tài liệu không cho biết tình trạng phê duyệt, việc bắt buộc chọn một trong hai giá trị approved và rejected có thể khuyến khích suy đoán. Thiết kế thêm unknown hoặc null có thể phù hợp hơn.
Hiểu lầm thứ ba là “đầu ra có cấu trúc thay thế kiểm soát bảo mật”. Một đối tượng JSON hoàn hảo vẫn có thể chứa nội dung do nguồn không đáng tin thao túng. Nếu mô hình đọc văn bản bên ngoài rồi đề xuất lệnh chuyển dữ liệu, việc lệnh được đóng gói đúng schema không làm cho nó trở nên an toàn. Cần phân quyền công cụ, xác nhận các hành động nhạy cảm và phân biệt dữ liệu nguồn với chỉ dẫn hệ thống.
Những hiểu lầm này đều xuất phát từ việc dùng một công cụ giải quyết lỗi định dạng để thay thế những tầng kiểm soát khác. Mỗi tầng có nhiệm vụ riêng và cần được đánh giá độc lập.
Lợi ích rõ nhất của đầu ra có cấu trúc là giảm công việc xử lý những phản hồi sai định dạng. Khi một hệ thống phụ thuộc vào dữ liệu máy đọc được, tính nhất quán của trường và kiểu dữ liệu có giá trị lớn. Nó giúp giảm số tình huống phải viết bộ phân tích văn bản tùy biến hoặc yêu cầu mô hình sửa lại câu trả lời.
Tuy nhiên, không nên suy ra rằng constrained decoding luôn làm mọi tác vụ nhanh hơn. Quá trình biên dịch schema, theo dõi trạng thái và lọc token cũng có chi phí. Tác động cuối cùng phụ thuộc độ phức tạp schema, kích thước đầu ra, hạ tầng suy luận và số lượt tạo lại được tránh. Hai tài liệu được đối chiếu ở đây mô tả cơ chế và tính năng, không cung cấp một mức cải thiện hiệu năng phổ quát cho mọi ứng dụng.
Nên đo trên dữ liệu thực tế: tỷ lệ phản hồi phân tích được, tỷ lệ đúng schema, tỷ lệ đúng nội dung sau đối chiếu, độ trễ ở các phân vị, số lượt retry và chi phí trên một bản ghi được chấp nhận. Nếu chỉ đo tỷ lệ JSON hợp lệ, hệ thống có thể trông rất tốt trong khi vẫn sai thông tin quan trọng.
Đối với nghiệp vụ có hậu quả tài chính hoặc pháp lý, nên theo dõi riêng số bản ghi bị người kiểm tra sửa và lý do sửa. Đây mới là chỉ báo cho thấy tự động hóa có giảm công việc thực sự hay chỉ chuyển lỗi sang một bước khác.
Trước tiên, chọn những trường tối thiểu phục vụ nghiệp vụ, định nghĩa kiểu dữ liệu và cách biểu diễn thông tin không biết. Tiếp theo, tách trích xuất khỏi quyết định: mô hình đưa ra các trường có cấu trúc, bộ kiểm tra độc lập xác minh quy tắc khách quan, còn hệ thống đích chỉ chấp nhận khi các điều kiện đã đạt. Mỗi giá trị quan trọng nên có dấu vết để đối chiếu.
Đường lỗi cũng cần minh bạch. Schema không được hỗ trợ phải báo lỗi cấu hình; đầu ra bị từ chối hoặc cắt ngắn không được xem là bản ghi hợp lệ; nguồn thiếu thì ghi nhận thiếu, không tự đoán. Cuối cùng, thử nghiệm với văn bản mâu thuẫn, bảng đứt trang và dữ liệu chứa chỉ dẫn không đáng tin. Đó là những tình huống phản ánh độ tin cậy thực tế.
Structured Outputs không tự giải quyết tính đúng đắn của suy luận, độ mới của dữ liệu hay tính trung thực của trích dẫn. Nó cũng không bảo đảm mọi JSON Schema đều được hỗ trợ giống nhau giữa các nhà cung cấp. Khi thay đổi mô hình hoặc dịch vụ, ứng dụng cần kiểm tra lại cả tương thích schema lẫn chất lượng dữ liệu.
Một câu hỏi kỹ thuật còn mở trong từng hệ thống cụ thể là ràng buộc cấu trúc ảnh hưởng thế nào đến chất lượng nội dung khi schema phức tạp. Ràng buộc có thể ngăn cú pháp sai, nhưng cũng có thể khiến ứng dụng khó biểu diễn những trường hợp không nằm trong danh mục thiết kế. Không thể kết luận điều này chỉ bằng việc đầu ra phân tích được.
Bài học quan trọng là đầu ra có cấu trúc tạo ra một hợp đồng giữa mô hình và phần mềm, không tạo ra hợp đồng với sự thật. Khi hiểu đúng ranh giới đó, nhà phát triển có thể tận dụng AI để xử lý dữ liệu ổn định hơn mà vẫn giữ những kiểm soát cần thiết cho thông tin, quyền hạn và quyết định thực tế.