Trong nhiều dự án AI, đặc biệt là các ứng dụng dùng mô hình ngôn ngữ lớn, nhóm phát triển thường quản lý mã nguồn khá tốt nhưng lại để prompt, cấu hình mô hình và bộ dữ liệu kiểm thử nằm rải rác trong notebook, tài liệu chat hoặc file tạm. Khi ứng dụng còn thử nghiệm thì không sao, nhưng đến lúc có người dùng thật, một thay đổi nhỏ trong prompt cũng có thể làm chất lượng trả lời thay đổi đáng kể. Bài viết này chia sẻ một cách thực tế để quản lý phiên bản cho prompt, mô hình và cấu hình suy luận, giúp nhóm dễ kiểm soát chất lượng hơn. Vì sao cần quản lý phiên bản prompt? Prompt không chỉ là vài dòng hướng dẫn. Trong ứng dụng AI hiện đại, prompt thường đóng vai trò như một phần của logic nghiệp vụ. Ví dụ: - Chatbot chăm sóc khách hàng cần trả lời đúng giọng thương hiệu. - Hệ thống tóm tắt văn bản pháp lý phải tránh diễn giải quá mức. - Công cụ phân loại phản hồi người dùng cần xuất kết quả đúng định dạng JSON. - Ứng dụng RAG cần biết khi nào nên nói “không đủ thông tin” thay vì đoán. Nếu prompt bị sửa mà không ghi lại, bạn sẽ rất khó trả lời các câu hỏi như: phiên bản nào đang chạy trên production, vì sao tuần trước trả lời đúng nhưng tuần này lại sai, hay thay đổi nào khiến tỷ lệ lỗi định dạng tăng lên. Những thứ nên được đưa vào quản lý phiên bản Không chỉ prompt chính, bạn nên lưu lại đầy đủ các thành phần ảnh hưởng đến đầu ra của hệ thống: 1. Prompt hệ thống và prompt người dùng mẫu Ví dụ, với chatbot nội bộ, nên lưu: - System prompt: vai trò, giới hạn, phong cách trả lời. - Template prompt: cách chèn câu hỏi, lịch sử hội thoại, tài liệu truy xuất. - Quy tắc định dạng đầu ra: JSON, bảng, danh sách, câu ngắn. 2. Thông tin mô hình Cần ghi rõ mô hình nào đang dùng, chẳng hạn tên model, nhà cung cấp, hoặc phiên bản mô hình nội bộ. Nếu có nhiều lựa chọn, ví dụ model nhanh cho câu hỏi đơn giản và model mạnh cho câu hỏi khó, cũng nên thể hiện rõ trong cấu hình. 3. Tham số suy luận Các tham số như temperature, top_p, max_tokens, số lượng tài liệu đưa vào context, ngưỡng similarity trong RAG đều có thể làm kết quả thay đổi. Đừng chỉ lưu prompt mà bỏ qua phần này. 4. Bộ câu hỏi kiểm thử Mỗi lần đổi prompt, nên chạy lại một bộ câu hỏi đại diện. Bộ này không cần quá lớn lúc ban đầu, nhưng nên có các nhóm tình huống rõ ràng: - Câu hỏi phổ biến của người dùng. - Câu hỏi dễ gây nhầm lẫn. - Câu hỏi ngoài phạm vi. - Câu hỏi yêu cầu định dạng nghiêm ngặt. - Câu hỏi có dữ liệu thiếu hoặc mâu thuẫn. Một cách tổ chức thư mục đơn giản Với dự án nhỏ hoặc vừa, bạn có thể bắt đầu bằng cấu trúc như sau: - prompts/customer_support/v1/system.txt - prompts/customer_support/v1/template.txt - prompts/customer_support/v1/config.yaml - eval_sets/customer_support/basic_cases.jsonl - eval_results/customer_support/v1/result_2026_08_05.json Không nhất thiết phải dùng công cụ phức tạp ngay từ đầu. Điều quan trọng là mỗi thay đổi có thể truy vết được: ai sửa, sửa gì, vì sao sửa, kết quả kiểm thử trước và sau thế nào. Ví dụ thực tế: sửa prompt để giảm trả lời bịa Giả sử bạn xây dựng trợ lý hỏi đáp chính sách công ty. Phiên bản đầu có system prompt như sau: “Bạn là trợ lý nhân sự. Hãy trả lời câu hỏi của nhân viên dựa trên tài liệu được cung cấp.” Sau khi kiểm thử, bạn thấy mô hình đôi khi trả lời cả những nội dung không có trong tài liệu. Nhóm sửa prompt thành: “Bạn là trợ lý nhân sự. Chỉ trả lời dựa trên tài liệu được cung cấp trong phần ngữ cảnh. Nếu tài liệu không có thông tin đủ rõ, hãy nói: ‘Tôi chưa tìm thấy thông tin này trong tài liệu hiện có.’ Không tự suy đoán chính sách.” Đây là một thay đổi nhỏ nhưng quan trọng. Nếu không lưu phiên bản, vài tuần sau khi có lỗi phát sinh, nhóm sẽ không biết hành vi của hệ thống thay đổi từ đâu. Nếu có quản lý phiên bản, bạn có thể so sánh v1 và v2, xem bộ kiểm thử nào được cải thiện, trường hợp nào bị ảnh hưởng xấu. Quy trình đề xuất khi thay đổi prompt Một quy trình nhẹ nhưng hữu ích có thể gồm 5 bước: 1. Tạo nhánh hoặc bản nháp cho prompt mới Không sửa trực tiếp prompt đang chạy production. Hãy tạo phiên bản mới, ví dụ v1.1 hoặc v2-draft. 2. Ghi rõ mục tiêu thay đổi Ví dụ: “Giảm tình trạng trả lời ngoài tài liệu”, “Ép đầu ra luôn là JSON hợp lệ”, “Làm câu trả lời ngắn hơn cho giao diện mobile”. 3. Chạy bộ kiểm thử cố định So sánh prompt mới với prompt cũ trên cùng một tập câu hỏi. Nếu có thể, lưu cả câu trả lời để xem lại thủ công. 4. Đánh giá theo tiêu chí cụ thể Đừng chỉ cảm nhận “có vẻ tốt hơn”. Hãy dùng tiêu chí rõ ràng như: - Có đúng thông tin không? - Có bịa thêm không? - Có tuân thủ định dạng không? - Có từ chối đúng khi thiếu dữ liệu không? - Câu trả lời có quá dài hoặc quá ngắn không? 5. Triển khai có kiểm soát Nếu ứng dụng có nhiều người dùng, nên triển khai dần hoặc bật cho một nhóm nhỏ trước. Sau đó theo dõi log và phản hồi trước khi thay thế hoàn toàn phiên bản cũ. Một vài lỗi thường gặp - Chỉ lưu prompt trong giao diện web của nhà cung cấp model, không đưa vào repository. - Đổi model nhưng quên ghi lại, dẫn đến không tái hiện được kết quả cũ. - Tối ưu prompt theo vài ví dụ đẹp nhưng không kiểm tra các tình huống xấu. - Không lưu output khi đánh giá, khiến việc so sánh sau này mất nhiều thời gian. - Trộn lẫn thay đổi prompt, thay đổi model và thay đổi dữ liệu truy xuất trong cùng một lần, làm khó xác định nguyên nhân cải thiện hoặc suy giảm. Lời khuyên áp dụng ngay Nếu nhóm của bạn đang làm ứng dụng AI, hãy bắt đầu bằng ba việc đơn giản: - Đưa toàn bộ prompt quan trọng vào Git hoặc hệ thống quản lý phiên bản tương đương. - Tạo một bộ kiểm thử nhỏ khoảng vài chục câu hỏi thật, có gắn nhãn kỳ vọng. - Mỗi lần sửa prompt hoặc đổi model, ghi lại lý do và chạy lại bộ kiểm thử đó. Quản lý phiên bản prompt không phải việc hào nhoáng, nhưng nó giúp dự án AI trưởng thành hơn rất nhiều. Khi hệ thống bắt đầu phục vụ người dùng thật, khả năng truy vết, so sánh và khôi phục phiên bản cũ đôi khi quan trọng không kém việc chọn một mô hình mạnh hơn.