1. 10:34 06/08/2026
Khi xây dựng ứng dụng dùng mô hình ngôn ngữ lớn, nhiều đội thường quản lý code khá chặt nhưng lại xem prompt như một đoạn văn bản có thể sửa nhanh trong dashboard, file cấu hình hoặc thậm chí trực tiếp trong cơ sở dữ liệu. Vấn đề là chỉ cần đổi một câu hướng dẫn, thêm một ví dụ hoặc thay thứ tự yêu cầu, hành vi của hệ thống có thể thay đổi đáng kể.
Vì vậy, prompt cũng cần được quản lý phiên bản giống như code, dữ liệu và mô hình.
Một ví dụ thực tế: bạn có chatbot hỗ trợ chăm sóc khách hàng. Prompt ban đầu yêu cầu “trả lời ngắn gọn, lịch sự”. Sau đó nhóm sản phẩm sửa thành “trả lời chi tiết, thân thiện, đề xuất thêm sản phẩm liên quan nếu phù hợp”. Nghe có vẻ hợp lý, nhưng sau khi triển khai, chatbot bắt đầu trả lời dài hơn, đôi khi gợi ý sản phẩm trong tình huống khách đang khiếu nại. Nếu không biết chính xác prompt nào đã chạy ở thời điểm nào, việc điều tra lỗi sẽ rất khó.
Những thành phần nên được lưu phiên bản gồm:
- System prompt: vai trò, giới hạn, phong cách trả lời, quy tắc an toàn.
- Prompt template: các biến đầu vào như tên khách hàng, lịch sử hội thoại, thông tin đơn hàng.
- Few-shot examples: ví dụ mẫu đưa vào prompt, vì chúng ảnh hưởng mạnh đến cách mô hình trả lời.
- Cấu hình mô hình: tên model, temperature, top_p, max tokens, công cụ được phép gọi.
- Ngữ cảnh truy xuất: phiên bản tài liệu, bộ lọc tìm kiếm, số lượng đoạn văn được đưa vào prompt.
Một cách làm đơn giản là lưu mỗi phiên bản prompt dưới dạng file trong Git, ví dụ prompts/support_agent/v3.yaml. Khi triển khai, ứng dụng ghi lại prompt_version cùng với request_id, model_name và thời gian gọi. Nhờ vậy, nếu người dùng báo lỗi, bạn có thể tái hiện gần đúng điều kiện đã sinh ra câu trả lời đó.
Ngoài việc lưu phiên bản, nên có quy trình thử nghiệm trước khi thay prompt. Đừng chỉ đọc vài câu trả lời mẫu. Hãy chuẩn bị một bộ câu hỏi cố định gồm các tình huống phổ biến, tình huống khó và tình huống nhạy cảm. Mỗi lần sửa prompt, chạy lại bộ này để so sánh: câu trả lời có đúng hơn không, có dài quá không, có vi phạm quy tắc nghiệp vụ không, có bịa thông tin không.
Nếu ứng dụng đã có người dùng thật, có thể triển khai theo từng phần. Ví dụ, chỉ cho 5% lưu lượng dùng prompt mới, theo dõi tỷ lệ người dùng hài lòng, số lần phải chuyển cho nhân viên, chi phí token và các lỗi nghiêm trọng. Cách này giúp tránh tình trạng một thay đổi nhỏ làm ảnh hưởng toàn bộ hệ thống.
Một số lời khuyên có thể áp dụng ngay:
- Đặt tên phiên bản rõ ràng, không dùng “final”, “final2”, “new_prompt”.
- Mỗi thay đổi prompt nên có ghi chú: sửa gì, vì sao sửa, kỳ vọng cải thiện điều gì.
- Không trộn quá nhiều mục tiêu trong một lần chỉnh sửa, vì sẽ khó biết yếu tố nào tạo ra kết quả tốt hoặc xấu.
- Lưu lại cả đầu vào, đầu ra và phiên bản prompt cho các trường hợp lỗi đáng chú ý.
- Tách prompt theo nhiệm vụ: phân loại, tóm tắt, trả lời khách hàng, trích xuất dữ liệu; đừng dùng một prompt khổng lồ cho mọi việc.
Trong ứng dụng LLM, prompt không chỉ là “câu lệnh cho AI” mà là một phần của logic sản phẩm. Khi prompt được quản lý có kỷ luật, nhóm phát triển dễ kiểm soát chất lượng hơn, điều tra lỗi nhanh hơn và cải tiến hệ thống một cách có cơ sở hơn.