Bỏ qua để vào nội dung chính
Eval harness 50 dòng chặn prompt regression trước khi ship

Eval harness 50 dòng chặn prompt regression trước khi ship

Bởi Grace Sullivan
28 thg 9, 20263 phút đọc

Sửa prompt xong ship luôn rồi vỡ ba thứ khác? Một eval harness chỉ dùng stdlib Python biến prompt thành thứ test được và chặn regression ngay ở CI.

Bạn sửa một system prompt để chữa một câu trả lời tệ, thấy ổn nên ship luôn. Hai ngày sau có người phát hiện output JSON mất một field, case từ chối giờ lại trả lời, còn bản tóm tắt thì dài gấp đôi. Không có gì crash và không test nào đỏ, vì chẳng có gì đang test cái prompt cả.

Một bài viết trên Dev.to tuần này mô tả cách bịt lỗ hổng đó bằng một eval harness chỉ dùng thư viện chuẩn của Python — không LLM-as-judge, không framework, không dashboard. Ý tưởng gói trong một câu: giữ một file các cặp input → checks, chạy mọi case qua model, chấm điểm từng check một cách tất định, so tỷ lệ pass với lần chạy trước, và từ chối ship nếu tỷ lệ tụt.

Ba mảnh ghép

Case viết dạng JSONL. Mỗi dòng một case với id, input và danh sách checks. Tác giả khuyên bắt đầu với 10–20 case, và lấy chúng từ chính những lỗi thật bạn đã gặp — mỗi bug được sửa trở thành một case, nên bug đó không quay lại mà không bị bắt.

Năm loại check tất định. Hàm kiểm tra gọn trong một khối, hỗ trợ contains_any, not_contains, max_words, regex và json_keys. Theo bài viết, năm loại này phủ gần hết những thứ vỡ khi prompt đổi: định dạng output, độ dài, hành vi từ chối, rò rỉ system prompt, và các cụm từ bắt buộc phải có.

Runner so với lần chạy trước. Runner đọc case, gọi call_model (bất kỳ hàm nào nhận string trả string — client OpenAI, Anthropic, Ollama cục bộ, hay một stub), tính tỷ lệ pass, rồi đối chiếu với last_run.json. Con số thực sự quan trọng không phải tỷ lệ pass mà là danh sách regressed: những case lần trước pass mà lần này fail. Như tác giả chỉ ra, tỷ lệ pass tổng có thể đứng yên trong khi một case quan trọng vỡ và một case vô thưởng vô phạt được sửa.

Chặn ở CI

Runner trả về mã thoát khác 0 khi có regression, nên chỉ cần gọi nó trong một step workflow là PR chuyển đỏ. Thay đổi prompt từ đó được review đúng như thay đổi code.

Bốn lưu ý vận hành đáng chép lại nguyên văn từ bài:

  • Bất định. Đặt temperature=0 cho các lần chạy eval. Case nào vẫn flaky thì chạy 3 lần và yêu cầu 2/3 pass, thay vì xóa case đi.
  • Chi phí. Tác giả ước tính 20 case nhân một model nhỏ tốn vài cent mỗi lần chạy. Chỉ chạy full suite khi prompt hoặc phiên bản model đổi, không phải mỗi commit.
  • Check quá chặt. contains_any với 3 từ đồng nghĩa tốt hơn so khớp chuỗi chính xác — bạn đang test hành vi, không test câu chữ.
  • Nâng cấp model. Chạy suite trước khi đổi phiên bản model. "Model mới tốt hơn" là một tuyên bố, và harness này là cách bạn kiểm chứng nó.

Với đội Việt Nam đang đưa LLM vào sản phẩm mà chưa có ngân sách cho nền tảng eval thương mại, đây là mức khởi đầu hợp lý: vài cent mỗi lần chạy theo ước tính của tác giả, không thêm dependency, và nó biến prompt thành thứ có thể review. Việc cần làm tuần này là dựng cases.jsonl từ đúng những lỗi prompt đã làm bạn mất thời gian tháng vừa rồi.

Không spam, hủy đăng ký bất kỳ lúc nào.

Bài viết liên quan