Vì sao ứng dụng AI cần đầu ra có cấu trúc?
Ứng dụng AI cần đầu ra có cấu trúc vì phần mềm không thể đọc một đoạn văn thân thiện một cách đáng tin cậy; lần nào phần mềm cũng cần các trường giống nhau, với cùng tên và kiểu dữ liệu. Chỉ một câu thừa hoặc một trường bị thiếu cũng có thể khiến bước tiếp theo trong ứng dụng của bạn bị lỗi.
Hãy hình dung một công ty khởi nghiệp logistics giả định có 12 người, Parcelwise. Lập trình viên Sana đang xây dựng công cụ đọc email khách hàng rồi điền vào biểu mẫu thay đổi giao hàng: mã đơn hàng, ngày được yêu cầu, địa chỉ mới và khách hàng có yêu cầu hoàn tiền hay không. Một email điển hình như sau: 'Chào bạn, đơn hàng PW-88213, thứ Năm tôi không ở nhà, giao vào thứ Bảy được không? Hoặc gửi ở nhà số 14. Nếu không được thì hủy và hoàn tiền giúp tôi nhé.' Phiên bản đầu tiên của cô yêu cầu mô hình 'trả lời bằng JSON'. Hầu hết câu trả lời đều phân tích cú pháp được, nhưng một số bắt đầu bằng 'Được, đây là JSON', một số đặt tên trường là 'date' thay vì 'requested_date', và có câu trả về ngày là 'thứ Bảy'.
Lược đồ JSON là gì và vì sao nó hữu ích?
Lược đồ JSON là bản mô tả chính thức về dữ liệu bạn mong đợi: có những trường nào, trường nào bắt buộc, mỗi trường thuộc kiểu dữ liệu gì và được phép nhận những giá trị nào. Cung cấp lược đồ cho mô hình biến yêu cầu 'vui lòng trả lời bằng JSON' thành một thỏa thuận mà mã của bạn có thể kiểm tra.
Với Sana, lược đồ quy định: order_reference là chuỗi bắt buộc; requested_date là chuỗi bắt buộc ở định dạng ngày tháng, hoặc null nếu không có ngày nào được cung cấp; new_address là chuỗi hoặc null; refund_requested là giá trị luận lý bắt buộc; và không cho phép bất kỳ trường nào khác. Quy tắc cuối cùng ngăn mô hình thêm các trường bình luận.
API của mô hình hỗ trợ đầu ra có cấu trúc như thế nào?
Các giao diện lập trình ứng dụng của những mô hình lớn cho phép bạn gửi kèm lược đồ JSON trong yêu cầu, và đầu ra của mô hình bị ràng buộc phải tuân theo lược đồ đó.
OpenAI
Tính năng đầu ra có cấu trúc của OpenAI giới hạn câu trả lời theo lược đồ JSON được cung cấp khi bật chế độ nghiêm ngặt. Tài liệu phân biệt tính năng này với chế độ JSON cũ, vốn chỉ đảm bảo JSON hợp lệ chứ không đảm bảo tuân thủ lược đồ của bạn, và khuyến nghị dùng đầu ra có cấu trúc khi có hỗ trợ.
Anthropic
API của Claude cung cấp đầu ra JSON khớp với lược đồ bạn đưa ra, cùng tùy chọn nghiêm ngặt trong phần định nghĩa công cụ để dữ liệu đầu vào của công cụ được kiểm tra theo lược đồ của công cụ đó. Tài liệu của Claude liệt kê những tính năng lược đồ được hỗ trợ và những tính năng sẽ trả về lỗi.
API của Gemini chấp nhận lược đồ JSON cho phản hồi và hỗ trợ một tập con được xác định rõ của các từ khóa lược đồ. Tài liệu hướng dẫn nêu rằng dù đầu ra là JSON đúng cú pháp, bạn vẫn nên kiểm tra tính hợp lệ của các giá trị trong ứng dụng.
Vì sao bạn vẫn cần kiểm tra tính hợp lệ và thử lại?
Bạn vẫn cần xác thực vì lược đồ chỉ kiểm soát cấu trúc dữ liệu, chứ không đảm bảo các giá trị là đúng. Một câu trả lời có cấu trúc hoàn toàn chính xác vẫn có thể chứa ngày sai, mã tham chiếu đơn hàng bịa đặt hoặc dấu hiệu yêu cầu hoàn tiền mà khách hàng chưa từng đưa ra.
Kiểm tra tính hợp lệ theo hai lớp. Trước tiên, kiểm tra cấu trúc bằng thư viện lược đồ, chẳng hạn Pydantic trong Python hoặc Zod trong JavaScript; tài liệu của OpenAI, Anthropic và Google đều có ví dụ minh họa. Tiếp theo, kiểm tra các quy tắc nghiệp vụ: mã tham chiếu đơn hàng có đúng mẫu và tồn tại trong hệ thống không, ngày có nằm trong tương lai và là ngày giao hàng không, địa chỉ có thuộc khu vực giao hàng không? Đồng thời xử lý các trường hợp mà nhà cung cấp đã nêu trong tài liệu: phản hồi từ chối có thể không tuân theo lược đồ của bạn, và phản hồi bị cắt do đạt giới hạn token tối đa sẽ để lại JSON không hoàn chỉnh.
Thử lại một cách thận trọng. Nếu một bước kiểm tra không đạt, gửi một yêu cầu thử lại có nêu lỗi cụ thể, chẳng hạn 'requested_date phải là ngày; email ghi thứ Bảy, còn ngày đặt hàng là 14 October'. Giới hạn số lần thử lại ở một hoặc hai lần, sau đó chuyển email cho người xử lý.
Đầu ra có cấu trúc thiếu chặt chẽ và chặt chẽ khác nhau như thế nào?
Phiên bản yếu: câu lệnh ghi 'Trích xuất thông tin chi tiết và trả về dưới dạng JSON.' Ứng dụng đọc bất cứ nội dung nào được trả về. Với email ở trên, ứng dụng nhận được các trường tên là order và date, giá trị ngày là 'Thứ Bảy' và giá trị hoàn tiền là true, vì mô hình đã coi 'nếu không thì cứ hủy' là một yêu cầu dứt khoát. Biểu mẫu được điền sai và khách hàng nhận được khoản hoàn tiền mà họ không muốn.
Phiên bản chặt chẽ: yêu cầu bao gồm lược đồ của Sana với chế độ nghiêm ngặt, và câu lệnh giải thích từng trường, bao gồm 'refund_requested chỉ là true nếu khách hàng yêu cầu hoàn tiền vô điều kiện'. Mô hình trả về order_reference là PW-88213, requested_date là ngày thứ Bảy tiếp theo, new_address là null, refund_requested là false và conditional_request, trường Sana đã thêm vào lược đồ dành riêng cho trường hợp này, được đặt là 'hoàn tiền nếu không thể giao vào thứ Bảy hoặc giao cho hàng xóm'. Bước xác thực xác nhận đơn hàng tồn tại và thứ Bảy là ngày có giao hàng. Vì email chứa yêu cầu có điều kiện, các quy tắc sẽ chuyển email cho người đưa ra quyết định cuối cùng.
Những sai lầm thường gặp với đầu ra có cấu trúc là gì?
Sai lầm phổ biến nhất là tin rằng JSON hợp lệ đồng nghĩa với dữ liệu chính xác. Những sai lầm khác gồm: chỉ dựa vào chỉ dẫn trong câu lệnh khi API có hỗ trợ bắt buộc tuân theo lược đồ, dùng tên trường mơ hồ mà không có mô tả, ép phải có một giá trị khi câu trả lời trung thực là null, bỏ qua phản hồi từ chối và phản hồi bị cắt ngắn, và thử lại mà không cho mô hình biết sai ở đâu.
Đầu ra có cấu trúc nằm ở đâu trong danh mục khóa học của Tosheo.ai?
Đầu ra có cấu trúc là một bài học lập trình trong khóa học xây dựng ứng dụng AI, thuộc danh mục Xây dựng ứng dụng AI. Phiên bản thực hành đầy đủ có mã nguồn, trong đó bạn định nghĩa lược đồ, gọi API, kiểm tra tính hợp lệ của phản hồi và thêm cơ chế thử lại, nằm trong lộ trình lập trình sau khi đăng ký, với phản hồi theo tiêu chí chấm điểm ở từng bước.