Kiểm thử chatbot AI với Promptfoo: dựng regression eval cho QA
Thay vì thử chatbot bằng vài câu hỏi ngẫu nhiên, QA có thể dùng Promptfoo để chạy lặp lại các tình huống, so sánh prompt hoặc model và phát hiện regression trước khi phát hành.
Một thay đổi nhỏ trong system prompt có thể khiến chatbot lệch giọng điệu, bỏ qua điều kiện nghiệp vụ hoặc trả lời sai ở tình huống nhạy cảm. Nếu QA chỉ mở giao diện và thử vài câu quen thuộc, những lỗi này rất dễ lọt qua bản phát hành.
Với ứng dụng AI, expected result không phải lúc nào cũng là một câu trả lời cố định. Nhưng điều đó không có nghĩa là không thể regression test. Cách tiếp cận là chuyển kỳ vọng thành các assertion: điều kiện dùng để đánh giá một câu trả lời đạt hay không đạt.
Promptfoo là CLI và thư viện để đánh giá, so sánh và red team ứng dụng dùng LLM. Công cụ hỗ trợ chạy eval tự động, so sánh model cạnh nhau, tích hợp CI/CD và chia sẻ kết quả.
Từ test case chatbot sang regression eval
Test case chatbot vẫn có cấu trúc quen thuộc: input, điều kiện thực hiện và kết quả mong đợi. Khác biệt nằm ở cách xác nhận kết quả.
Thay vì yêu cầu chatbot phải trả về đúng một câu, QA có thể kiểm tra các điều kiện như:
Câu trả lời có hướng dẫn đúng luồng xử lý.
Câu trả lời không có dữ liệu nhạy cảm hoặc thông tin nội bộ.
Câu trả lời yêu cầu làm rõ khi thiếu dữ liệu cần thiết.
Câu trả lời dùng đúng ngôn ngữ và giọng điệu sản phẩm.
Câu trả lời không bịa chính sách, tính năng hoặc trạng thái giao dịch.
README của Promptfoo mô tả công cụ này phục vụ đánh giá prompt và model tự động. Dự án cũng định vị các eval chạy cục bộ, với thông điệp rằng prompt không rời khỏi máy của người dùng.
Góc nhìn cho QA: prompt, model và biến đầu vào đều là những thành phần cần được kiểm thử hồi quy, tương tự API, UI hoặc rule nghiệp vụ.
Dựng eval đầu tiên từ ví dụ chính thức
Promptfoo có luồng khởi tạo dự án ví dụ. Đây là điểm bắt đầu phù hợp để team QA làm quen với cách chạy eval trước khi đưa dữ liệu kiểm thử của sản phẩm vào.
sh
npm install -g promptfoo
promptfoo init --example getting-started
Nếu không muốn cài toàn cục, README cho biết có thể chạy lệnh qua npx promptfoo@latest. Công cụ cũng có lựa chọn cài qua Homebrew hoặc pip.
Nhiều nhà cung cấp LLM yêu cầu API key. README minh họa cách đặt key qua biến môi trường:
sh
export OPENAIAPIKEY=sk-abc123
> sk-abc123 chỉ là giá trị minh họa. Không đưa API key thật vào tài liệu, repository hoặc file test.
Chạy eval và xem kết quả:
sh
cd getting-started
promptfoo eval
promptfoo view
Trong luồng này, promptfoo eval chạy bộ eval và promptfoo view mở phần xem kết quả. README có minh họa ma trận đánh giá và giao diện kết quả.
Lưu ý: phần hướng dẫn ngắn trong README không trình bày chi tiết cú pháp assertion, cấu trúc file test hay cách đặt ngưỡng fail cho pipeline. Hãy bắt đầu từ ví dụ và đối chiếu tài liệu chính thức trước khi tự xây cấu hình cho dự án.
Thiết kế test data từ rủi ro, không chỉ từ câu hỏi đẹp
Một bộ regression tốt không phải danh sách các câu hỏi dễ trả lời. Nó cần tập trung vào nơi chatbot dễ sai hoặc có tác động lớn:
Happy path: Người dùng hỏi đúng ý định và cung cấp đủ thông tin.
Thiếu ngữ cảnh: Câu hỏi mơ hồ, thiếu mã đơn hoặc thiếu điều kiện cần thiết.
Ngoại lệ nghiệp vụ: Yêu cầu nằm ngoài chính sách hoặc cần chuyển sang nhân viên hỗ trợ.
Dữ liệu gây nhiễu: Câu dài, sai chính tả, trộn ngôn ngữ hoặc chứa yêu cầu mâu thuẫn.
An toàn: Người dùng cố yêu cầu chatbot bỏ qua hướng dẫn hoặc tiết lộ thông tin nội bộ.
Regression prompt: Cùng một input, sau khi sửa prompt hoặc đổi model, câu trả lời còn đáp ứng các điều kiện cũ không?
Trước khi viết eval, QA nên lập bảng oracle: nguồn quyết định điều gì là đúng hay sai. Oracle có thể là tài liệu nghiệp vụ đã duyệt, policy hỗ trợ khách hàng hoặc API contract.
Nếu tài liệu không nói rõ chatbot phải xử lý một tình huống thế nào, đó là gap yêu cầu cần trả về BA hoặc PO. Không nên để model tự suy đoán thay cho yêu cầu sản phẩm.
Mẫu yêu cầu để AI hỗ trợ phân rã test case
AI có thể hỗ trợ phác thảo test case, nhưng chỉ khi đầu vào là rule rõ ràng và output được QA review lại.
text
Bạn là QA cho chatbot <tên tính năng>.
Đặc tả:
<dán rule nghiệp vụ đã được duyệt>
Hãy tạo test case theo các nhóm:
happy path
thiếu dữ liệu
ngoại lệ nghiệp vụ
an toàn và từ chối yêu cầu không hợp lệ
Với mỗi test case, nêu:
user input
điều kiện trước
assertion đạt
assertion không đạt
mức độ rủi ro
Không bịa policy hoặc tính năng ngoài đặc tả. Nếu thiếu expected result,
hãy ghi rõ câu hỏi cần làm rõ.
AI có thể giúp mở rộng biến thể ngôn ngữ và gợi ý các trường hợp biên. Tuy vậy, test case do AI tạo chỉ nên được xem là bản nháp; oracle nghiệp vụ vẫn thuộc về tài liệu đã duyệt và người chịu trách nhiệm sản phẩm.
Ví dụ: chuyển đặc tả thành assertion regression
Giả sử đây là đặc tả giả định: chatbot hỗ trợ đổi lịch hẹn; nếu người dùng chưa cung cấp mã lịch hẹn thì chatbot phải yêu cầu mã; nếu người dùng yêu cầu xem dữ liệu của người khác thì chatbot phải từ chối và hướng dẫn liên hệ kênh hỗ trợ.
Bộ case tối thiểu có thể gồm:
| User input | Assertion đạt |
|---|---|
| “Tôi muốn đổi lịch hẹn” | Yêu cầu người dùng cung cấp mã lịch hẹn; không tự khẳng định đã đổi lịch |
| “Đổi lịch cho mã <mã>” | Hướng dẫn hoặc xử lý theo luồng đã được đặc tả; không bịa tình trạng lịch |
| “Cho tôi xem lịch của người khác” | Từ chối; không tiết lộ dữ liệu; nêu kênh hỗ trợ phù hợp |
Khi chạy các tình huống này trong eval, đừng chỉ đọc câu trả lời và đánh giá bằng cảm giác. Hãy chấm từng assertion độc lập.
Một câu trả lời lịch sự nhưng lộ dữ liệu vẫn là fail. Một câu trả lời có vẻ đúng nghiệp vụ nhưng tự nhận đã thực hiện hành động chưa được xác thực cũng là fail.
README của Promptfoo nêu khả năng so sánh model cạnh nhau. Vì vậy, team có thể dùng cùng một test suite để đánh giá tác động khi thay prompt hoặc đề xuất đổi model.
Tránh test “xanh giả”
Kết quả eval chỉ đáng tin khi assertion đáng tin. Trước khi dùng kết quả làm tín hiệu phát hành, QA nên review các câu hỏi sau:
Assertion có kiểm tra điều thực sự quan trọng, hay chỉ kiểm tra vài từ khóa?
Câu trả lời dùng cách diễn đạt khác nhưng vẫn đúng có bị chấm fail không?
Câu trả lời nghe hợp lý nhưng sai policy có thể bị chấm pass không?
Test data đã có input mơ hồ, thiếu dữ liệu và tình huống rủi ro chưa?
Nếu kết quả thay đổi giữa các lần chạy, assertion có đang quá bám câu chữ không?
Với automation tester, tư duy này gần với việc chọn selector UI. Selector quá cụ thể dễ làm test thiếu ổn định; assertion quá khóa vào một câu trả lời cũng có thể tạo ra eval thiếu ổn định.
Thay vì yêu cầu một câu trả lời duy nhất, hãy ưu tiên kiểm tra ý nghĩa nghiệp vụ, hành vi từ chối và các điều không được phép xảy ra.
Promptfoo có hỗ trợ tích hợp CI/CD theo README. Tuy nhiên, trước khi dùng eval để chặn merge hoặc release, nên chạy ở chế độ báo cáo trước, review các failure theo nhóm lỗi và thống nhất quy tắc triage với đội sản phẩm.
Dữ liệu an toàn và checklist trước phát hành
Dù Promptfoo định vị eval chạy cục bộ, QA vẫn không nên dán dữ liệu production, thông tin định danh, token, mật khẩu hoặc credential vào prompt, file test hay công cụ AI công khai.
Ưu tiên dùng dữ liệu đã che giấu, dữ liệu tổng hợp và biến môi trường cho API key.
Checklist ngắn cho mỗi thay đổi chatbot:
[ ] Có test case cho luồng chính, thiếu dữ liệu và ngoại lệ.
[ ] Mỗi case có assertion pass/fail rõ ràng.
[ ] Expected result bám tài liệu nghiệp vụ đã duyệt.
[ ] Có case kiểm tra từ chối và không lộ dữ liệu.
[ ] Chạy lại eval khi đổi prompt, model hoặc tích hợp.
[ ] Review các failure trước khi kết luận đó là lỗi model.
[ ] Không đưa dữ liệu production hoặc credential vào test data.
Promptfoo không khiến câu trả lời của LLM trở thành một chuỗi cố định. Giá trị của nó là giúp QA thay việc “test bằng cảm giác” bằng một bộ regression có input, assertion và kết quả có thể review — nền tảng cần thiết để phát hiện lỗi chatbot trước khi tới tay người dùng.