Giới thiệu
Mô hình ngôn ngữ lớn có tính linh hoạt mặc định — chúng có thể trả lời bằng bất kỳ định dạng nào, bất kỳ độ dài nào, bất kỳ phong cách nào. Đối với sử dụng thực tế trong các ứng dụng web, sự linh hoạt đó trở thành vấn đề. Bạn cần đầu ra có thể dự đoán và dễ phân tích. Bài học này trình bày bốn kỹ thuật cốt lõi để kiểm soát những gì LLM tạo ra: prompts hệ thống để thiết lập hành vi bền vững, ví dụ few-shot để dạy khuôn mẫu đầu ra bằng minh họa, enforcement định dạng để đảm bảo cấu trúc, và xử lý trường hợp biên khi mô hình cố gắng đi lệch khỏi kịch bản.
Prompts hệ thống so với prompts người dùng
Prompts hệ thống được gửi như một tin nhắn riêng với mức ưu tiên cao hơn so với tin nhắn người dùng. Chúng định rõ vai trò, giới hạn và giọng điệu của mô hình cho toàn bộ cuộc trò chuyện. Prompts người dùng là bài toán hoặc câu hỏi thực tế. Giữ prompts hệ thống tập trung vào các quy tắc ổn định và prompts người dùng tập trung vào nhiệm vụ biến đổi.
Chú ý `temperature: 0` — khi bạn cần đầu ra có cấu trúc, khóa ngẫu nhiên về bằng 0. Nhiệt độ cao hơn sẽ dẫn đến lệch định dạng ngay cả với prompts hệ thống mạnh.
Ví dụ few-shot
Prompting kiểu few-shot có nghĩa là cho mô hình 2-4 ví dụ về ánh xạ đầu vào-đầu ra chính xác mà bạn muốn, thay vì mô tả nó. Mô hình học theo mẫu bằng cách đối sánh mẫu. Đưa các ví dụ vào prompts người dùng hoặc dưới dạng các cặp tin nhắn người dùng/ trợ lý luân phiên.
Tin nhắn người dùng thứ ba không có trả lời trợ lý — mô hình sẽ điền vào. Vì nó đã thấy hai ví dụ nhất quán, nó sẽ hầu như luôn theo cùng một dạng JSON.
Các chiến lược thực thi định dạng
Khi mô hình bướng bỉnh và phớt lờ các chỉ dẫn định dạng của bạn, hãy chồng lên các lớp phòng thủ này theo thứ tự: thứ nhất, cải thiện prompt hệ thống bằng các ví dụ tiêu cực rõ ràng ("KHÔNG viết 'Here is your JSON:'"). Thứ hai, chuyển sang một mô hình hỗ trợ chế độ đầu ra có cấu trúc (chế độ JSON hoặc gọi công cụ/ hàm) nơi API đảm bảo được JSON hợp lệ. Thứ ba, thêm một bước xử lý sau trong mã của bạn để xác thực đầu ra với một schema và retry khi gặp lỗi.
Schema Zod đóng vai trò như một hợp đồng — nếu LLM trả về một số thay vì chuỗi, hoặc trả về 4 màu thay vì 3, quá trình phân tích sẽ ném lỗi và fallback của bạn sẽ được kích hoạt. Tuyệt đối không tin output thô từ LLM trong mã production.
Xử lý các trường hợp biên
Ba trường hợp biên thường xuyên xuất hiện. Thứ nhất, mô hình từ chối và trả lời xin lỗi thay vì dữ liệu — xử lý bằng cách nhận diện các cụm từ từ chối và thử lại bằng prompt rõ ràng hơn. Thứ hai, mô hình tưởng tượng một trường không tồn tại trong schema của bạn — xử lý bằng cách xác thực với schema, chứ không chỉ bằng JSON.parse. Thứ ba, mô hình trả về đầu ra bị cắt bớt vì giới hạn token — xử lý bằng cách đặt max_tokens rõ ràng và chia các yêu cầu dài thành phần, hoặc yêu cầu mô hình tóm gọn.
Tóm tắt
Kiểm soát đầu ra của LLM không phải chỉ bằng một thủ thuật — đó là một hệ stack các lớp phòng thủ. Bắt đầu với prompt hệ thống rõ ràng, thêm vài ví dụ khi định dạng còn mơ hồ, ép buộc cấu trúc bằng schemas và xác thực, và luôn có một fallback cho từ chối, ảo tưởng và truncation. Ở bài học tiếp theo chúng ta sẽ xem cách gọi hàm, cho phép mô hình chọn giữa các công cụ thay vì生成 văn bản tự do.
Bài kiểm tra cuối bài
Ôn lại kiến thức, thử sức và nhận góp ý cho bài làm.