Trong bài viết này
Từ được đánh dấu có giải thích. Di chuột hoặc chạm để xem, hay mở từ điển AI.
Email ghi: “Mình là Lan, muốn tham gia buổi chiều; chưa chốt ngày”. Công cụ đăng ký trả về một JSON có tên Lan, ca chiều và một ngày cụ thể. JSON đọc được, biểu mẫu lưu thành công, nhưng hệ thống đã biến thông tin thiếu thành một lời xác nhận.
Structured output giúp phần mềm nhận dữ liệu theo cấu trúc dự kiến. Để dùng được trong sản phẩm, bạn còn phải định nghĩa ý nghĩa của từng trường và cách biểu diễn điều chưa biết.
Viết hợp đồng trước khi viết prompt
Với tình huống giả định trên, đầu ra hợp lý có thể là:
{
"name": "Lan",
"session": "afternoon",
"date": null,
"needs_clarification": true
}Quy định session chỉ nhận các giá trị đã liệt kê; date nhận chuỗi ngày hoặc null; tên giữ nguyên dấu. Đừng dùng chuỗi rỗng cho mọi kiểu thiếu dữ liệu: người đọc mã sẽ không biết đó là không có thông tin hay lỗi xử lý.
Trong tài liệu JSON Schema về object, khai báo properties không tự khiến thuộc tính trở thành bắt buộc. Bạn cần required để yêu cầu chúng xuất hiện và có thể dùng additionalProperties để kiểm soát trường ngoài hợp đồng. Đây là khác biệt dễ bỏ sót khi schema trông đầy đủ nhưng vẫn chấp nhận đối tượng rỗng.
Kiểm tra theo các lớp khác nhau
Lớp đầu kiểm tra kết quả có đọc được hay không. Lớp tiếp theo xác nhận kiểu dữ liệu và trường bắt buộc. Sau đó mới tới quy tắc nghiệp vụ: ngày được chọn có thuộc lịch mở đăng ký, buổi chiều có tổ chức vào ngày đó, và người gửi có thật sự chọn ngày hay chưa.
Một ngày hợp lệ theo định dạng vẫn có thể không tồn tại trong lịch chương trình. Ngược lại, null có thể là kết quả đúng nhất khi nguồn chưa cung cấp dữ liệu. Nếu mọi giá trị thiếu đều bị tính thành lỗi, bạn đang khuyến khích hệ thống đoán.
Lưu bằng chứng nguồn cho trường quan trọng, chẳng hạn đoạn “chưa chốt ngày”. Phần giao diện có thể dùng bằng chứng này để giải thích vì sao hồ sơ cần hỏi lại. Không cần yêu cầu mô hình kể toàn bộ quá trình suy nghĩ; đoạn nguồn và quy tắc áp dụng đã đủ phục vụ kiểm tra.
Một prompt dễ kiểm tra nêu nhiệm vụ, cung cấp ngữ cảnh, đặt giới hạn và quy định đầu ra. Sau đó thử trên các ví dụ thật để xem mô hình có đáp ứng hay không.
↔ Vuốt ngang để xem toàn bộ sơ đồ.
01 / Nhiệm vụ
Nêu công việc cụ thể: chẳng hạn viết lại thông báo kỹ thuật cho người dùng phổ thông.
02 / Ngữ cảnh
Cung cấp thông báo gốc và nói rõ ai sẽ đọc, họ cần biết điều gì.
03 / Giới hạn
Yêu cầu giữ nguyên mốc giờ, tên tính năng và con số; không tự thêm thông tin thiếu căn cứ.
04 / Định dạng đầu ra
Quy định tiếng Việt, tối đa 120 từ, nêu hành động cần làm và đánh dấu phần còn thiếu.
Đây là khung soạn yêu cầu, không phải công thức bảo đảm đầu ra đúng. Các giới hạn về quyền và bảo mật phải được thực thi trong ứng dụng.
Sửa lỗi có giới hạn
Giả sử mô hình trả session: "chiều" trong khi hợp đồng yêu cầu afternoon. Bạn có thể ánh xạ bằng mã nếu quy tắc rõ ràng, hoặc gọi lại với thông báo lỗi cụ thể. Nhưng không nên biến mọi dữ liệu gần giống thành hợp lệ một cách âm thầm.
Phân biệt lỗi có thể sửa với thiếu dữ liệu. Sai nhãn có thể chuẩn hóa; ngày không được nêu phải hỏi người dùng. Một vòng “hãy sửa JSON” không tạo thêm bằng chứng về ngày tham dự.
Trong quy trình giả định, hệ thống chỉ cho phép một lần sửa cấu trúc rồi chuyển sang kiểm tra thủ công. Giới hạn ấy là lựa chọn của bài tập, không phải chuẩn chung. Mục tiêu là tránh vòng lặp tốn tiền mà vẫn giữ nguyên lỗi ngữ nghĩa.
Đánh đổi khi schema thay đổi
Schema chặt giúp phát hiện lệch hợp đồng sớm, nhưng thay đổi trường có thể làm khách hàng cũ không đọc được kết quả. Khi bổ sung nhu cầu hỗ trợ, hãy quyết định trường mới có bắt buộc ngay hay cần giai đoạn chuyển tiếp.
Ghi phiên bản schema cùng kết quả và prompt. Tránh để hệ thống nhận dữ liệu cũ nhưng áp dụng ngầm quy tắc mới. Với tác vụ trích xuất, tách dữ liệu nguyên bản khỏi dữ liệu đã chuẩn hóa cũng giúp sửa quy tắc mà không phải gọi mô hình lại.
Lỗi thường gặp là kiểm tra schema xong rồi ghi thẳng vào dữ liệu chính. Nên có trạng thái đã trích xuất, đã xác minh và đã xác nhận; mỗi trạng thái cho phép một tập hành động khác nhau.
Bài tập: hồ sơ có thông tin mâu thuẫn
Tạo email giả định: “Đăng ký sáng thứ Bảy. À, đổi sang chiều; ngày cụ thể mình báo sau”. Viết schema và đầu ra mong muốn trước khi thử mô hình. Thêm một email không nêu tên để kiểm tra quy tắc dữ liệu thiếu.
Tự kiểm bằng ba câu: hệ thống có giữ lựa chọn cuối cùng, có để ngày chưa biết là null, và có chặn bước xác nhận khi thiếu ngày? Nếu chỉ JSON parser chạy thành công, bài tập chưa đạt. Đọc tiếp đánh giá mô hình theo công việc thực tế.