Một mô hình ngôn ngữ lớn có thể tạo ra câu trả lời rất tự nhiên, nhưng tự nhiên không đồng nghĩa với dễ tích hợp. Khi đầu ra được đưa vào cơ sở dữ liệu, hệ thống bán hàng hoặc một API khác, chỉ cần thêm một câu giải thích ngoài dự kiến cũng có thể làm hỏng toàn bộ luồng xử lý. Vì vậy, thay vì chỉ tối ưu prompt, nên thiết kế một hợp đồng đầu ra rõ ràng và kiểm chứng nó như với bất kỳ dữ liệu đến từ bên ngoài nào. 1. Xác định hợp đồng đầu ra trước khi viết prompt Hãy liệt kê các trường mà ứng dụng thực sự cần, kiểu dữ liệu của từng trường và những giá trị được phép. Ví dụ, với hệ thống phân loại yêu cầu hỗ trợ khách hàng, đầu ra có thể gồm: - intent: một trong các giá trị billing, technical_support hoặc account. - urgency: low, medium hoặc high. - summary: bản tóm tắt tối đa 200 ký tự. - next_action: hành động đề xuất cho nhân viên. Không nên yêu cầu mô hình trả về quá nhiều trường chỉ vì chúng có vẻ hữu ích. Mỗi trường bổ sung đều làm tăng khả năng mâu thuẫn hoặc khó kiểm thử. Những thông tin không cần cho bước tiếp theo nên để ngoài hợp đồng. 2. Tách hướng dẫn khỏi dữ liệu người dùng Prompt nên nói rõ đâu là chỉ dẫn của hệ thống và đâu là nội dung cần phân tích. Dữ liệu đầu vào có thể chứa câu như bỏ qua yêu cầu trước đó hoặc hãy xuất thông tin bí mật. Mô hình cần được hướng dẫn xem phần này là dữ liệu, không phải mệnh lệnh. Việc đặt nội dung người dùng trong một vùng phân cách rõ ràng giúp giảm nhầm lẫn, nhưng không nên xem đó là biện pháp bảo mật tuyệt đối. Một prompt thực dụng thường gồm bốn phần: nhiệm vụ, định nghĩa các trường, quy tắc xử lý trường hợp thiếu thông tin và định dạng đầu ra. Nếu có thể, hãy đưa một vài ví dụ đại diện cho cả trường hợp bình thường lẫn trường hợp mơ hồ. Ví dụ phải phản ánh đúng quy tắc mà hệ thống sẽ áp dụng, tránh ví dụ quá hoàn hảo. 3. Kiểm tra bằng mã, không chỉ tin vào lời hứa trong prompt Sau khi nhận phản hồi, ứng dụng nên thực hiện ít nhất các bước sau: - Kiểm tra phản hồi có phải JSON hợp lệ hay không. - Kiểm tra đủ trường bắt buộc và đúng kiểu dữ liệu. - Kiểm tra giá trị thuộc tập cho phép. - Kiểm tra giới hạn độ dài, số lượng phần tử và các quy tắc nghiệp vụ. - Loại bỏ hoặc cách ly những trường không nằm trong hợp đồng. Có thể dùng thư viện kiểm tra schema của ngôn ngữ lập trình đang sử dụng. Chẳng hạn, một schema có thể quy định urgency chỉ nhận ba giá trị và summary không vượt quá 200 ký tự. Nếu thư viện báo lỗi, hệ thống không nên đưa dữ liệu chưa kiểm chứng vào cơ sở dữ liệu. 4. Thiết kế đường lui khi đầu ra sai Một lần thử lại có hướng dẫn cụ thể thường hữu ích: gửi lại lỗi schema, yêu cầu mô hình chỉ sửa định dạng và không thay đổi nội dung hợp lệ. Tuy nhiên, không nên lặp vô hạn vì sẽ làm tăng chi phí và độ trễ. Sau số lần thử lại giới hạn, hệ thống có thể chuyển sang một trong các phương án sau: - Đưa yêu cầu vào hàng đợi để nhân viên xử lý. - Dùng bộ quy tắc đơn giản cho các trường hợp phổ biến. - Trả về trạng thái cần làm rõ thay vì tự đoán. - Sử dụng mô hình hoặc quy trình dự phòng đã được kiểm thử. Đặc biệt, không nên coi trường confidence do mô hình tự sinh là xác suất đáng tin nếu chưa có quy trình hiệu chỉnh và đánh giá riêng. 5. Ghi log những gì cần thiết Để tìm lỗi, hãy lưu phiên bản prompt, phiên bản mô hình, schema, thời gian xử lý, trạng thái kiểm tra và lý do thất bại. Với dữ liệu cá nhân hoặc nội dung nhạy cảm, cần che giấu hoặc băm trước khi ghi log. Việc quan sát tỷ lệ lỗi schema theo từng loại yêu cầu thường giúp phát hiện prompt mơ hồ, trường dữ liệu thiết kế kém hoặc một nhóm đầu vào bất thường. Cuối cùng, hãy xây dựng bộ mẫu kiểm thử gồm câu ngắn, câu dài, lỗi chính tả, nhiều ý trong một yêu cầu, thông tin bị thiếu và nội dung cố tình chèn chỉ dẫn. Đầu ra có cấu trúc không biến LLM thành hệ thống luôn đúng, nhưng nó tạo ra ranh giới rõ ràng giữa phần sáng tạo của mô hình và phần logic phải được phần mềm kiểm soát.