Đầu ra có cấu trúc của LLM trong sản xuất: Làm thế nào để ngăn JSON làm hỏng quy trình làm việc AI của bạn

Đầu ra có cấu trúc của LLM trong sản xuất. Chế độ JSON không phải là một kiến trúc sản xuất. Nếu một hệ thống AI cung cấp dữ liệu cho cơ sở dữ liệu, hàng đợi, API, công cụ hoặc tác nhân, thì đầu ra có cấu trúc cần có hợp đồng, xác thực, sửa chữa, kiểm thử và khả năng hiển thị hoạt động. Một quy trình làm việc AI đáng tin cậy coi đầu ra của mô hình là một hợp đồng, không phải là một gợi ý lịch sự. Lần đầu tiên một LLM trả về JSON hoàn hảo, có vẻ như vấn đề đã được giải quyết. Lần thứ mười nó gói đối tượng trong các dấu Markdown, bỏ qua một trường bắt buộc, thay đổi một chuỗi thành một mảng hoặc cắt cụt giữa chừng một đối tượng lồng nhau, bài học thực sự xuất hiện: đầu ra có cấu trúc không phải là một tính năng. Đó là một lớp tin cậy. Điều này quan trọng hơn vào năm 2026 vì các hệ thống AI đang chuyển từ hộp trò chuyện sang quy trình làm việc. Các tác nhân gọi công cụ. Trợ lý mã hóa chỉnh sửa kho lưu trữ. Các tự động hóa back-office di chuyển dữ liệu qua các nền tảng SaaS. Các hệ thống đa bước chuyển đầu ra của một mô hình sang một mô hình khác, một hàng đợi, một trình phân tích cú pháp hoặc một API. Trong thế giới đó, JSON "chủ yếu hợp lệ" không phải là một lỗi định dạng vô hại. Đó là một sự chuyển giao thất bại. Cuộc trò chuyện của nhà phát triển hiện tại phản ánh sự thay đổi đó. Tài liệu về Đầu ra có cấu trúc của OpenAI nhấn mạnh sự tuân thủ chặt chẽ của lược đồ và các công cụ hỗ trợ SDK. Tài liệu về đầu ra có cấu trúc Gemini của Google cũng mô tả hỗ trợ JSON Schema thông qua các SDK của họ. Tài liệu sử dụng công cụ của Anthropic dựa vào các định nghĩa đầu vào kiểu JSON Schema cho các công cụ. Đồng thời, các diễn đàn nhà phát triển đầy rẫy các câu hỏi thực tế về JSON bị lỗi, sự khác biệt giữa các nhà cung cấp, các tập con lược đồ, thử lại, độ chính xác của giá trị và khả năng di chuyển. Khoảng cách không phải là nhận thức. Các nhà phát triển biết họ cần đầu ra có cấu trúc. Khoảng cách là kế hoạch sản xuất: cách thiết kế lược đồ, cách kiểm tra xem nhà cung cấp có thực sự thực thi các ràng buộc mà bạn tin cậy hay không, cách khôi phục khi đầu ra hợp lệ về mặt cú pháp nhưng sai về mặt ngữ nghĩa và cách ngăn chặn các hệ thống hạ nguồn trở thành tuyến phòng thủ đầu tiên. Trong sản xuất, câu hỏi không phải là "Mô hình có thể trả về JSON không?" Câu hỏi là "Quy trình làm việc này có thể tồn tại đầu ra xấu mà không làm hỏng trạng thái, che giấu lỗi hoặc lãng phí tiền bạc không?" Tại sao đầu ra có cấu trúc đột nhiên trở thành một vấn đề lớn hơn. Đầu ra có cấu trúc từng là một tính năng tiện lợi. Một chatbot có thể tóm tắt văn bản thành một vài trường, và một lỗi phân tích cú pháp có thể chỉ có nghĩa là hỏi lại mô hình. Điều đó đã thay đổi khi đầu ra AI trở thành đầu vào cho các hệ thống thực. Các nền tảng quy trình làm việc doanh nghiệp, công cụ dành cho nhà phát triển và khung tác nhân hiện đang được xây dựng xung quanh việc điều phối, thực thi công cụ, quản trị và chuyển giao tự động. Các thông báo sản phẩm gần đây từ các công ty tự động hóa và nền tảng dành cho nhà phát triển đều chỉ ra cùng một hướng: AI đang được yêu cầu thực hiện công việc trên các API, tệp, vé, cơ sở dữ liệu, trình duyệt và hệ thống nội bộ. Các quy trình làm việc đó cần dữ liệu được định kiểu. Điều đó làm cho đầu ra có cấu trúc trở thành một vấn đề ranh giới. Mọi ranh giới đều cần một hợp đồng. Ranh giới mô hình không khác gì ranh giới API công khai, ngoại trừ nó có tính xác suất cao hơn, nhạy cảm hơn với ngữ cảnh và có nhiều khả năng thất bại theo những cách có vẻ hợp lý. Các nhà phát triển thường phát hiện ra vấn đề thông qua một trong năm chế độ lỗi: Phản hồi là JSON hợp lệ nhưng không khớp với lược đồ dự kiến. Lược đồ hoạt động với một nhà cung cấp nhưng thất bại, yếu đi hoặc hoạt động khác với nhà cung cấp khác. Mô hình trả về một trường trông có vẻ đúng nhưng không dựa trên đầu vào. Một quy trình làm việc tác nhân dài gây ra sự trôi dạt lược đồ sau nhiều bước. Logic thử lại lặp lại cùng một đầu ra bị hỏng hoặc thay đổi các trường đã đúng. Nếu bạn đang trích xuất hóa đơn. các trường băng, phân loại phiếu hỗ trợ, định tuyến cuộc gọi công cụ, tạo bộ lọc cơ sở dữ liệu hoặc xây dựng chuyển giao tác nhân-tác nhân, đây không phải là các trường hợp ngoại lệ. Chúng là các điều kiện hoạt động bình thường. Sử dụng Mô hình Tư duy Hợp đồng-Đầu tiên Quy trình làm việc đầu ra có cấu trúc đáng tin cậy bắt đầu trước lời nhắc. Bắt đầu với hợp đồng mà ứng dụng của bạn thực sự cần. Sau đó, làm cho mô hình phù hợp với hợp đồng, chứ không phải ngược lại. Điều đó có nghĩa là xác định một mô hình miền chuẩn trong mã ứng dụng của bạn. Trong Python, điều này thường có nghĩa là Pydantic. Trong TypeScript, điều này thường có nghĩa là Zod hoặc TypeBox. Điều quan trọng là mô hình này thuộc về ứng dụng của bạn. Nó không nên được sao chép từ một ví dụ của nhà cung cấp và được coi là một nguồn chân lý vĩnh viễn. Một hợp đồng tốt phân tách ba lớp: Mô hình chuẩn: đối tượng được gõ mà ứng dụng của bạn tin cậy. Lược đồ hướng nhà cung cấp: tập hợp con của hợp đồng mà một API mô hình cụ thể có thể chấp nhận. Quy tắc xác thực: các kiểm tra xác định chạy sau khi tạo, bao gồm các bất biến nghiệp vụ mà mô hình không thể thực thi. Sự phân tách này quan trọng vì hỗ trợ đầu ra có cấu trúc không giống nhau giữa các API. Một nhà cung cấp có thể hỗ trợ một từ khóa JSON Schema mà nhà cung cấp khác từ chối. Một SDK có thể chuyển đổi mô hình được gõ của bạn thành một lược đồ đơn giản hóa. Một mô hình có thể tuân thủ tốt các ràng buộc enum nhưng vẫn tạo ra các giá trị sai cho tài liệu nguồn. Một lược đồ "phổ quát" duy nhất nghe có vẻ thanh lịch cho đến khi nó trở thành lý do mọi tích hợp nhà cung cấp đều dễ vỡ. Một ví dụ nhỏ Giả sử bạn đang xây dựng một bộ phân loại hỗ trợ khách hàng. Lược đồ hấp dẫn là rộng và thân thiện với con người: { "type": "object", "properties": { "category": { "type": "string" }, "priority": { "type": "string" }, "summary": { "type": "string" }, "suggested_action": { "type": "string" } }, "required": ["category", "priority", "summary", "suggested_action"] } Điều đó tốt hơn văn bản tự do, nhưng nó vẫn để lại quá nhiều chỗ trống. Danh mục có thể là “Billing”, “billing”, “payment issue” hay “refund”? Mức độ ưu tiên có thể là “urgent” hay “P0”? Hành động được đề xuất có thể tạo ra một chính sách không? Một hợp đồng sản xuất nên làm cho các trường định tuyến hẹp và có thể kiểm toán được: { "type": "object", "properties": { "category": { "type": "string", "enum": ["billing", "technical", "account", "security", "other"] }, "priority": { "type": "string", "enum": ["low", "normal", "high", "critical"] }, "confidence": { "type": "number", "minimum": 0, "maximum": 1 }, "evidence": { "type": "array", "items": { "type": "string" }, "maxItems": 3 } },