Promptfoo: một file YAML để eval và red team ứng dụng LLM của khách

Ba prompt, hai model, hai mươi câu hỏi mẫu. Với Promptfoo, một lệnh duy nhất chạy hết 120 tổ hợp đó và đặt kết quả cạnh nhau trong một bảng.

Khi khách hỏi “prompt mới có tốt hơn prompt cũ không”, bảng ấy cho phép FDE trả lời bằng số đếm cụ thể thay vì bằng ấn tượng sau vài lần thử tay trong buổi demo.

Theo trang tài liệu chính thức, Promptfoo là CLI và thư viện mã nguồn mở để eval và red team ứng dụng LLM. Hai việc này gần như luôn xuất hiện trong một deployment LLM thật: khách muốn biết hệ thống trả lời đúng tới đâu, và đội bảo mật của họ muốn biết nó bị phá dễ tới đâu.

Promptfoo gom cả hai vào một file cấu hình, nên bạn chỉ cần học một công cụ cho hai câu hỏi mà khách gần như chắc chắn sẽ đặt ra.

Vì sao FDE nên chọn eval khai báo?

Promptfoo nhấn mạnh rằng bạn khai báo eval chứ không phải viết code hay mở những notebook nặng nề. Với FDE, lợi ích nằm ở người đọc file: YAML đủ ngắn để product owner của khách đọc được, và đủ rõ để kỹ sư của họ tự sửa sau khi bạn rời dự án.

Điểm cộng tiếp theo là Promptfoo chạy hoàn toàn trên máy local và gọi thẳng tới LLM. Khi bộ test là ticket hỗ trợ thật hay hợp đồng thật của khách, bạn không phải giải thích vì sao dữ liệu phải đi qua thêm một dịch vụ bên thứ ba.

Repo GitHub cũng mô tả công cụ là cấu hình khai báo đơn giản, có tích hợp CLI và CI/CD, và có thể so sánh nhiều nhà cung cấp model cạnh nhau.

Một file YAML tối thiểu trông thế nào?

Lệnh promptfoo init mở một CLI tương tác để sinh file cấu hình ban đầu, thường tên là promptfooconfig.yaml.

File này có ba phần chính: prompts (các phiên bản prompt cần so), providers (các model) và tests (các test case). assert là tùy chọn, nhưng nó giúp tự động đánh trượt những output sai, ví dụ output không phải JSON hợp lệ.

Bộ khung dưới đây minh họa đủ bốn phần; bạn chỉ cần thay hai dòng provider placeholder bằng model thật:

prompts:
  - "Trích xuất mã đơn hàng và lý do khiếu nại từ email sau, trả về JSON: {{email}}"
providers:
  - <model-hiện-tại-của-khách>
  - <model-ứng-viên>
tests:
  - vars:
      email: "Đơn 4821 giao thiếu 2 hộp, tôi muốn hoàn tiền."
    assert:
      - type: is-json

Sau đó promptfoo eval chạy mọi prompt với mọi model trên mọi test case. Khi bộ test lớn lên, thuộc tính tests có thể nhận danh sách đường dẫn tới file hoặc thư mục, nên khách có thể tự đóng góp test case vào một thư mục chung thay vì nhét hết vào một file.

Từ “chất lượng chung chung” đến bốn email trượt

Thử hình dung một công ty logistics muốn chuyển sang model rẻ hơn để phân loại email khiếu nại. Bạn lấy 20 email thật, giữ assert bắt buộc output là JSON và chạy với cả hai model. Bảng dưới đây là kết quả giả định, chỉ để minh họa cách đọc:

Test case	Model hiện tại	Model ứng viên
Email 1: giao thiếu hàng	Đạt	Đạt
Email 7: email dài, nhiều đơn	Đạt	Trượt, output không phải JSON
Email 12: khách viết lẫn tiếng Anh	Đạt	Trượt, output không phải JSON
Tổng 20 email	20/20 đạt	16/20 đạt

Đọc bảng này, cuộc họp tiếp theo sẽ bàn về 4 email trượt chứ không còn là cuộc tranh luận chung chung về “chất lượng”. Có thể khách chấp nhận đổi model và thêm bước xử lý cho email dài; cũng có thể họ giữ model cũ, nhưng giờ quyết định dựa trên dòng cụ thể.

Red team: tìm lỗ hổng trước khi khách tìm ra

Phần thứ hai của Promptfoo là red team, theo tài liệu là cách tìm lỗ hổng trong hệ thống AI trước khi triển khai và có được thước đo rủi ro định lượng. Promptfoo chia các kiểu lỗi của LLM thành “plugin”, mỗi plugin là một bộ kiểm thử đối kháng.

Cấu hình red team cũng nằm trong promptfooconfig.yaml. Bộ khung dưới đây chỉ để hình dung cấu trúc; tên plugin cụ thể bạn chọn từ danh sách trong tài liệu red team, ứng với kiểu lỗi khách lo nhất:

providers:
  - <chatbot-của-khách>
redteam:
  plugins:
    - <plugin-cho-kiểu-lỗi-1>
    - <plugin-cho-kiểu-lỗi-2>

Quy trình gồm ba bước. Bạn lưu cấu hình, chạy promptfoo redteam run để sinh vài trăm input đối kháng vào file redteam.yaml rồi bắn vào hệ thống, sau đó mở promptfoo redteam report để xem kết quả. Nếu không muốn dùng giao diện web để khởi tạo, bạn có thể dùng lệnh init.

Với FDE, giá trị nằm ở chỗ rủi ro được đo bằng con số thay vì cảm nhận. Lời khuyên thực tế: khi trình bày với đội bảo mật của khách, hãy mang theo cả file redteam.yaml lẫn báo cáo, để họ tự chạy lại và đối chiếu thước đo rủi ro thay vì chỉ nghe bạn kể đã thử những gì.

Khi nào eval phải chạy lại trong CI/CD?

Vì Promptfoo tích hợp CLI và CI/CD, câu hỏi thực tế không phải là có đưa vào pipeline hay không, mà là gắn nó vào những thay đổi nào. Có ba thời điểm nên bắt buộc chạy lại promptfoo eval.

Thời điểm đầu tiên là mỗi lần ai đó sửa prompt, kể cả sửa một câu chỉ dẫn tưởng vô hại. Kế đến là khi đổi model hoặc thêm model ứng viên vào providers, như kịch bản logistics ở trên. Cuối cùng là khi khách nối thêm một nguồn dữ liệu mới: lấy vài mẫu thật từ nguồn đó, thả vào thư mục tests, rồi mới cho lên production.

Với red team, nhịp hợp lý là chạy lại trước mỗi lần phát hành lớn thay vì mỗi commit, vì mỗi lượt sinh vài trăm input đối kháng. Đây là gợi ý vận hành, bạn nên thống nhất tần suất với đội bảo mật của khách.

Bảng số chỉ đáng tin khi bộ test sát thực tế

Kết quả của Promptfoo chỉ có ý nghĩa khi bộ test phản ánh đúng dữ liệu của khách. Nếu 20 câu hỏi mẫu do bạn tự nghĩ ra thay vì lấy từ log thật, bảng kết quả sẽ đẹp nhưng không nói lên điều gì. Phần khó nhất của eval vẫn là customer discovery: ngồi với người dùng để biết thế nào là một câu trả lời đúng.

Cũng cần biết bối cảnh sở hữu. Ngày 9/3/2026, hai nhà sáng lập Ian Webster và Michael D’Angelo thông báo Promptfoo đã đồng ý để OpenAI mua lại, kèm cam kết dự án vẫn mã nguồn mở và tiếp tục phục vụ người dùng.

Giấy phép MIT là một lớp bảo đảm, nhưng nếu khách đang dùng model của nhà cung cấp khác, bạn nên chủ động nêu chi tiết này trong buổi đánh giá công cụ thay vì để họ tự phát hiện.

Học gì trước, và ghi vào CV thế nào?

Nên học eval trước, red team sau. Thành thạo cấu trúc prompts, providers, tests và assert, tập viết test case từ dữ liệu thật, rồi mới chuyển sang plugin đối kháng và cuối cùng là gắn cả hai vào CI/CD.

Khi đọc JD các vị trí FDE hay AI engineer, hãy để ý các cụm như “LLM evaluation”, “red teaming”, “guardrails”. Trong CV, một dòng như “dựng bộ eval 200 test case bằng Promptfoo, chạy trong CI, phát hiện lỗi định dạng trước khi đổi model” có sức nặng hơn nhiều so với “có kinh nghiệm prompt engineering”.

Nhà tuyển dụng FDE muốn thấy bạn biến câu hỏi mơ hồ của khách thành một con số kiểm chứng được.