Con số 3.2% xuất hiện đầu tiên trong báo cáo kiểm toán —3,200 payload JSON sai định dạng trong mỗi 100,000 lần gọi API, mỗi payload là một lỗi logic nghiệp vụ thầm lặng.
Một thay đổi chuỗi model duy nhất đã gây ra điều đó. Không dashboard nào bắt được nó. HTTP vẫn xanh trong khi output có cấu trúc âm thầm suy giảm, và bạn lần theo đống đổ nát ba sprint về trước.
Eval tích hợp CI bắt regression ngữ nghĩa ngay tại pull request —cùng lực như unit test chặn null pointer.
Pipeline này trải từ các kiểm tra xác định đến chấm điểm bằng LLM-as-Judge, với một closed loop biến lỗi hôm nay thành test case CI cho ngày mai.
Vì sao “Trông ổn” chỉ mở rộng đến khoảng 50 lượt review —rồi thất bại
Vì sao “Trông ổn không?” không mở rộng được
Một reviewer là người nhìn chằm chằm vào output LLM không đáng tin cậy theo ba cách cụ thể, đo lường được:
- Mệt mỏi. Độ chính xác tụt mạnh sau ~50 lượt review liên tiếp. Nhận định thứ 51 của bạn tệ hơn đáng kể so với nhận định thứ 5 —và bạn sẽ không nhận ra sự suy giảm đó.
- Không nhất quán. Độ tin cậy giữa hai reviewer (inter-rater reliability) trên cùng một tập output LLM thường xuống dưới 0.6 —nghĩa là hai người đủ năng lực không đồng ý với nhau về “cái này có đúng không?” 40% số lần.
- Chi phí và độ trễ. 1,000 output với 90 giây mỗi lượt review = 25 giờ công người. Đó là $750-2,500 cho mỗi lần chạy eval —và mất nhiều ngày để lên lịch.
Đánh giá bằng máy nhất quán, tức thì và gần như miễn phí. Nhưng “đánh giá bằng máy” không phải một thứ duy nhất —đó là một chồng ba nguyên thủy (primitive) mà bạn kết hợp tùy theo thứ bạn đang kiểm thử.
Ba primitive đánh giá
Lớp 1: Kiểm tra xác định (Deterministic Checks). Micro giây. Chi phí API bằng không. Xác thực JSON Schema. Khớp chuỗi chính xác. Đếm thành công/thất bại của tool call. Kiểm tra sự tồn tại của trích dẫn. Khớp regex của refusal. Các kiểm tra này bắt khoảng 50% lỗi thực tế —và chúng là lớp duy nhất có thể chạy trên mọi request mà không lo về ngân sách. Bắt đầu từ đây.
Lớp 2: Embedding-Based Metrics. Mili giây. ~$0.001 mỗi lần kiểm tra. BERTScore. Độ tương tự cosine với câu trả lời tham chiếu. Hữu ích khi bạn có câu trả lời “gold” và cần đánh giá tương tự chấp nhận diễn giải lại. Không hữu ích cho sinh văn bản mở, nơi tồn tại nhiều câu trả lời hợp lệ.
Lớp 3: LLM-as-Judge. Hàng trăm mili giây. $0.01-0.10 mỗi lần kiểm tra. Một LLM đủ mạnh chấm output theo rubric bằng suy luận chain-of-thought. Bắt các lỗi ngữ nghĩa mà kiểm tra xác định bỏ sót —tóm tắt không trung thực, phản hồi vô ích, refusal sai. Yêu cầu hiệu chuẩn với nhãn do con người gán và chủ động giảm thiểu bias (bias vị trí, bias dài dòng, bias tự nâng cao).
Stack đánh giá production 6 lớp
Dataset —Metrics/Rubrics —Judge —CI Gate —Production Observation —Closed LoopPhá vỡ bất kỳ mắt xích nào, đánh giá biến thành một báo cáo offline không ai đọc. Dataset lấy mẫu từ production, nghiêng về các lỗi. Rubric định nghĩa “đúng” theo các điều kiện đo lường được. Judge chấm điểm nhất quán và ở quy mô lớn. CI gate chặn regression trước khi merge. Quan sát production bắt những gì CI bỏ sót. Closed loop biến lỗi production hôm nay thành test case CI cho ngày mai. Sáu lớp. Một pipeline. Không khoảng trống.
Vì sao kiểm thử có hệ thống thay đổi mọi thứ
Chi phí ẩn của regression
3.2% response JSON sai định dạng thầm lặng nghĩa là 3,200 output hỏng trong mỗi 100,000 lần gọi API. Nếu các output đó thúc đẩy hành động ở phía sau, bạn có 3,200 lỗi logic nghiệp vụ —và bạn sẽ không phát hiện ra cho đến khi đối soát tài chính không khớp, có thể là nhiều tuần sau.
Một pipeline eval bắt được con số 3.2% ngay trong CI, trước khi thay đổi chuỗi model kịp đến production. Chi phí dựng pipeline thấp hơn chi phí của một sự cố duy nhất.
Phát hiện drift prompt
Những bản nâng cấp nhỏ về phiên bản model —gpt-5.5-2026-07-01 lên gpt-5.5-2026-07-15 —không kèm ghi chú về thay đổi hành vi. Changelog ghi “cải thiện khả năng làm theo chỉ dẫn”. Độ chính xác trích xuất có cấu trúc của bạn tụt 4 điểm. Bạn sẽ không biết trừ khi bạn chạy cùng một eval suite với mọi phiên bản model.
Vấn đề đánh giá đa nhà cung cấp
Nếu bạn định tuyến giữa các model —và bạn nên làm vậy, vì chi phí và độ tin cậy —bạn cần kết quả eval cho mọi model trong pool định tuyến của mình. Không chỉ model chính. Một API endpoint thống nhất cho phép bạn chạy cùng một eval suite trên tất cả model qua một tích hợp duy nhất. Cùng định dạng request. Cùng test case. Cùng judge model. Biến duy nhất thay đổi là model: "...".
Trước khi xây dựng eval suite, hãy hiểu hồ sơ hiệu suất và chi phí của từng model trong pool định tuyến của bạn. So sánh benchmark giữa các nhà cung cấp của chúng tôi cung cấp dữ liệu theo từng model để làm căn cứ cho ưu tiên kiểm thử của bạn.
Cách xây dựng pipeline đánh giá của bạn
Bước 1: Xây dựng eval dataset của bạn
Dataset là bước khó nhất và là nơi hầu hết đội ngũ đầu tư ít nhất. Một dataset tồi cho bạn điểm số chính xác trên những thứ sai. Một dataset tốt được lấy mẫu từ production, nghiêng về lỗi và được làm mới hàng tuần.
Quy trình xây dựng:
- Lấy mẫu ngẫu nhiên 200-500 request từ log production. Không phải từ môi trường test của bạn. Người dùng thật đặt những câu hỏi mà tác giả test không bao giờ nghĩ tới.
- Gán nhãn thủ công từng cái: câu trả lời đúng là gì? Điều gì khiến response sai? Model nên xử lý những edge case nào?
- Phân tầng theo độ khó: một phần ba dễ, một phần ba trung bình, một phần ba khó. Nếu eval set của bạn toàn query dễ, điểm số của bạn sẽ bị thổi phồng.
- Làm mới hàng tuần: lấy mẫu dữ liệu mới từ 7 ngày log production gần nhất. Thay 20% cũ nhất của eval set. Điều này giữ eval của bạn khớp với những gì người dùng thực sự hỏi —vốn drift theo thời gian.
Quy tắc ngăn chặn sai lầm phổ biến nhất: ít nhất 20% eval set của bạn phải đến từ các lỗi lịch sử. Nếu eval set chỉ chứa query happy-path, bạn đang kiểm thử xem model có hoạt động trong điều kiện lý tưởng —chứ không phải liệu nó có thất bại một cách trang nhã trong các điều kiện thực sự xảy ra ở production.
Bước 2: Định nghĩa rubric, không chỉ “nó có tốt không?”
Bốn rubric được hiệu chuẩn tốt đánh bại 15 rubric nhiễu. Mỗi rubric cần:
- Định nghĩa chính xác: “faithfulness = mọi khẳng định thực tế trong response đều được hỗ trợ bởi context đã truy xuất”
- Thang điểm: 1-5 hoặc 0-1
- Ngưỡng đạt: “faithfulness ≥ 0.85”
- Hai đến ba ví dụ đã chấm điểm làm tham chiếu hiệu chuẩn cho judge model của bạn
Bộ rubric lõi cho hầu hết ứng dụng LLM API: faithfulness (sự thật có đúng không?), answer relevance (response có trả lời đúng query không?), context precision (các chunk truy xuất có thực sự liên quan không?), task completion (model có làm đúng điều được yêu cầu không?), refusal correctness (model có từ chối khi cần —và không từ chối khi không cần?).
Bước 3: Chọn và hiệu chuẩn judge của bạn
GPT-4 là LLM judge được dùng rộng rãi nhất —mức đồng thuận với người gán nhãn vượt 80% trên MT-Bench và 85%+ trên G-Eval. Nhưng một judge chưa hiệu chuẩn cho bạn những con số trông có vẻ chính xác nhưng sai một cách có hệ thống.
Quy trình hiệu chuẩn: lấy 50 ví dụ do con người gán nhãn. Chạy chúng qua judge model. Tính tương quan giữa điểm của judge và điểm của con người. Nếu tương quan dưới 0.75 cho bất kỳ rubric nào, prompt judge của rubric đó cần được chỉnh sửa —hoặc bạn cần một judge model khác.
Ba bias phải được giảm thiểu:
- Bias vị trí. Judge thích response xuất hiện trước hơn. Sửa: ngẫu nhiên hóa thứ tự response trong từng lần đánh giá.
- Bias dài dòng. Judge chấm response dài hơn cao hơn bất kể chất lượng. Sửa: chấm độ liên quan và mức đầy đủ thành các chiều riêng biệt.
- Bias tự nâng cao. Judge thổi phồng điểm cho output do cùng model family sinh ra. Sửa: dùng một model family khác làm judge so với model dùng trong production. Nếu production chạy Claude, hãy dùng GPT-4 để chấm. Hoặc dùng một judge model chuyên dụng. Về việc cô lập API key và kiểm soát truy cập giúp tách biệt an toàn judge và model production, xem hướng dẫn thực hành bảo mật tốt nhất.
Quy tắc dễ bị bỏ qua nhất: khóa chặt phiên bản judge model của bạn. Khi bạn nâng judge từ GPT-4 lên GPT-4o, mọi điểm lịch sử trở nên không thể so sánh. Bạn không thể biết model production của mình cải thiện hay judge trở nên nghiêm khắc hơn. Hoặc giữ phiên bản judge cố định, hoặc hiệu chuẩn lại với 50 ví dụ do con người gán nhãn sau mỗi lần nâng cấp judge và thiết lập ánh xạ điểm giữa judge cũ và mới.
Bước 4: Thiết lập CI gating
Hai công cụ, hai triết lý:
- Promptfoo. Mã nguồn mở. Tích hợp Git. Cấu hình khai báo bằng YAML. Tốt nhất cho đội ngũ muốn eval như code, sống cạnh prompt trong cùng một repo.
- DeepEval. Thuần Python. Hơn 30 metric tích hợp sẵn. Tích hợp CI/CD dựa trên decorator. Tốt nhất cho đội ngũ muốn eval tích hợp sâu vào bộ test Python.
Logic của CI gate, bất kể công cụ nào:
tests:
- path: eval_dataset.jsonl
asserts:
- type: python
value: |
def check_regression(output, context):
baseline = context['baseline_scores']
current = compute_scores(output)
for rubric, score in current.items():
if baseline[rubric] - score > 2:
return False, f"{rubric} dropped {baseline[rubric] - score:.1f} points"
return True, "All rubrics within threshold"Bất kỳ rubric nào tụt hơn 2 điểm so với baseline —CI thất bại —merge bị chặn. Điều này không phải tùy chọn. Một thay đổi prompt làm giảm chất lượng 3 điểm trên một rubric quan trọng không bao giờ được đến production. Unit test của bạn chặn ngoại lệ null pointer. Eval gate của bạn nên chặn regression ngữ nghĩa với cùng lực đó. Quy trình tối ưu hóa prompt cấp dữ liệu cho CI gating được trình bày trong hướng dẫn production prompt engineering của chúng tôi.
Bước 5: Quan sát production + Closed Loop
Đánh giá trong CI bắt regression trước khi deploy. Nó không bắt được sự dịch chuyển phân phối (distribution shift), input đối nghịch, hay edge case mà eval set của bạn không phủ. Với những thứ đó, bạn cần đánh giá liên tục trên trace production.
Gắn điểm eval vào span OTel của bạn. Bất kỳ rubric nào duy trì mức tụt 2-5 điểm trong một cửa sổ trượt sẽ kích hoạt cảnh báo. Phương pháp hiệu chuẩn judge và quy trình tối ưu hóa prompt cấp dữ liệu cho CI gating đều được trình bày ở các bước trước trong hướng dẫn này. Phương pháp đánh giá chain-of-thought được nhắc đến ở đây được thiết lập bởi bài báo G-Eval (Liu et al., 2023). Các trace thất bại được tự động phân cụm theo loại lỗi, phiên bản prompt và model. Các vấn đề được đặt tên với lỗi đại diện được đưa trở lại eval dataset offline của bạn —lần này được gán nhãn thủ công, với mẫu lỗi cụ thể được ghi lại.
Closed loop này là khác biệt giữa một điểm eval có xu hướng đi xuống theo thời gian và một điểm không ngừng cải thiện. Không có nó, eval set của bạn trở nên cũ kỹ, model drift, và CI gate trở thành hình thức lọt qua trong khi chất lượng production suy giảm.
Các mẫu kiểm thử cho tình huống API cụ thể
Kiểm thử structured output
Riêng xác thực JSON Schema đã bắt ~70% lỗi structured output. Thêm các kiểm tra quy tắc nghiệp vụ cho 30% còn lại: “giá không thể âm”, “email phải khớp regex”, “tổng phải bằng tổng phụ cộng thuế”. Kiểm tra nhất quán giữa các trường: “nếu payment_method là ‘credit_card’, last_four không được null”.
Bẫy theo nhà cung cấp: OpenAI trả về function.arguments dưới dạng chuỗi JSON. Anthropic trả về tool_use.input dưới dạng đối tượng JSON. Parser của bạn phải xử lý cả hai —và eval suite của bạn phải kiểm thử cả hai. Mock cả hai định dạng response trong CI.
Để có tài liệu tham khảo đầy đủ về định dạng request và response giữa các nhà cung cấp —bao gồm structured output, tool call và streaming —xem tài liệu chat completions API.
Kiểm thử tool calling
Bốn kiểm tra, xếp theo tần suất lỗi: (1) Tên tool khớp schema. (2) Các đối số bắt buộc có mặt và đúng kiểu. (3) Các tool call song song không can thiệp lẫn nhau. (4) Sau lỗi tool, model thử lại với đối số đã sửa —hoặc leo thang —không lặp vòng.
Đặt giới hạn vòng lặp cứng trong kiểm thử: cùng một tool bị gọi quá ba lần liên tiếp —test thất bại. Model nên nhận ra mẫu, không lặp lại nó.
Kiểm thử chất lượng RAG
Ba chiều: mức liên quan của context (các chunk truy xuất có đúng chủ đề người dùng hỏi không?), độ trung thực của câu trả lời (mọi khẳng định trong câu trả lời có được một chunk truy xuất hỗ trợ không?), độ chính xác của trích dẫn (mỗi trích dẫn có trỏ đến một chunk thực sự chứa thông tin được trích dẫn không?). Ngưỡng tối thiểu: độ chính xác trích dẫn top-1 —90%. Dưới mức đó, người dùng sẽ mất niềm tin —nhanh chóng.
Vì sao hầu hết pipeline eval LLM thất bại trong vòng 3 tháng
Chỉ kiểm thử happy path
Eval set của bạn chứa “Chính sách hoàn trả là gì?” và “Làm sao để đặt lại mật khẩu?” —những query sạch sẽ, thân thiện, đúng chuẩn. Production chứa “i cant log in wtf???” và “URGENT: my refund still hasn’t processed and it’s been TWO WEEKS” —với lỗi chính tả, sự giận dữ và thiếu ngữ cảnh. Nếu eval set của bạn không bao gồm các edge case giống production, điểm eval 95% của bạn chẳng nghĩa lý gì.
Sửa: lấy mẫu từ log production. Đảm bảo ít nhất 20% eval set của bạn đến từ các lỗi lịch sử —các query trước đây tạo ra câu trả lời sai, refusal hoặc hallucination.
Không khóa phiên bản judge model
Bạn nâng judge từ GPT-4 lên GPT-4o. Mọi điểm eval dịch lên 3 điểm. Đội ngũ ăn mừng “cải thiện chất lượng”. Không gì thay đổi trong production. Chỉ là judge trở nên dễ tính hơn.
Sửa: khóa chặt phiên bản judge model. Nếu buộc phải nâng cấp, hiệu chuẩn lại với 50 ví dụ do con người gán nhãn của bạn và thiết lập ánh xạ điểm. Không có nó, lịch sử điểm eval của bạn chỉ là nhiễu.
Tối ưu hóa trên eval set
Bạn tinh chỉnh prompt của mình dựa trên eval set. 95% độ chính xác. Đã phát hành. Độ chính xác production: 68%. Eval set chứa những mẫu bạn tối ưu hóa cho. Production chứa mọi thứ còn lại.
Sửa: tách train/eval/test (70/15/15). Trình tối ưu hóa nhìn thấy tập huấn luyện. CI chạy trên eval set. Test set được giữ riêng —bạn chạy nó một lần trước khi phát hành, và điểm nó báo cáo là ước lượng gần nhất về hiệu suất production mà bạn có được trước khi deploy.
Một khi eval gate của bạn vượt qua trong CI, các mẫu deploy như canary rollout và chuỗi fallback bảo vệ bạn khỏi sự dịch chuyển phân phối trong production. Xem hướng dẫn tối ưu hóa production về chiến lược rollout và cấu hình failover model.
Đọc thêm. Mở rộng phần structured output của bộ test với so sánh JSON mode và structured output của chúng tôi, bài này bao quát cách xử lý định dạng theo nhà cung cấp mà pipeline CI của bạn cần xác thực. Về phương pháp tối ưu hóa prompt, xem Bước 4; về chiến lược rollout và cấu hình failover model, xem hướng dẫn tối ưu hóa production ở trên.
Câu hỏi thường gặp
Tôi cần bao nhiêu test case để bắt đầu?
Năm mươi là mức tối thiểu cho phản hồi định hướng —đủ để biết một thay đổi làm mọi thứ tốt hơn hay tệ hơn, nhưng quá nhiễu để làm CI gating. Từ một trăm đến 500 case mang lại ý nghĩa thống kê —một lỗi edge case đơn lẻ không thể làm điểm của bạn dao động hơn vài điểm. Bắt đầu với 50. Thêm 20-30 case mới mỗi tuần từ log production. Nếu bạn mới làm quen với kiểm thử LLM lập trình và muốn nắm nền tảng API trước, hướng dẫn LLM API cho người mới bắt đầu của chúng tôi bao quát cấu trúc request trước khi bạn xây eval suite.
LLM-as-Judge so với đánh giá của con người —khoảng cách lớn đến đâu?
Judge GPT-4 đồng thuận với người gán nhãn hơn 80% số lần trong các tác vụ kiểm tra thực tế và làm theo chỉ dẫn. Khoảng cách lớn nhất nằm ở các chiều chủ quan (sáng tạo, chất lượng văn phong). Với các chiều khách quan —faithfulness, tuân thủ định dạng, hoàn thành tác vụ —LLM judge ngang bằng hoặc vượt từng người gán nhãn, vì chúng loại bỏ sự mệt mỏi và không nhất quán.
Tôi có nên dùng cùng model làm judge với model production không?
Không. Bias tự nâng cao là có thật và đo lường được —model thổi phồng điểm cho output cùng model family từ 5-10%. Dùng một model family khác hoặc một judge model chuyên dụng. Nếu stack production chạy Claude, hãy đánh giá bằng GPT-4.
Tôi đánh giá response streaming như thế nào?
Đánh giá response đã nối hoàn chỉnh, không phải từng token riêng lẻ. Thêm các assertion hiệu suất: TTFT (thời gian đến token đầu tiên) dưới ngưỡng mục tiêu, độ trễ giữa các token P95 trong ngân sách. Các lỗi đặc thù streaming —như ký tự xuống dòng chưa escape trong dữ liệu sự kiện SSE làm hỏng parser —cần các kiểm tra xác định chuyên dụng.
Làm sao chạy cùng một eval suite trên ba nhà cung cấp mà không viết ba adapter?
Gửi các test case giống hệt qua một base URL duy nhất, chỉ đổi tham số model giữa gpt-5.5, claude-sonnet-4-20250514 và gemini-3.1-pro. Một định dạng request. Một pipeline eval. Biến duy nhất thay đổi là model nào xử lý prompt —đó chính xác là thứ eval suite của bạn được thiết kế để đo. Cho request eval thống nhất đầu tiên của bạn qua một base URL duy nhất, hãy làm theo hướng dẫn khởi động nhanh.
Đánh giá LLM không phải một giai đoạn bạn hoàn thành. Đó là hạ tầng bạn duy trì. Stack 6 lớp —dataset, rubric, judge, CI gate, quan sát production, closed loop —là hệ thống tối thiểu khả thi để biết các tính năng do LLM cung cấp của bạn đang tốt hơn hay tệ hơn.
Bắt đầu với 50 test case và các kiểm tra xác định. Chạy chúng trong CI tuần này. Thêm 20 case mỗi tuần từ log production. Sau một tháng, bạn sẽ có một eval set có ý nghĩa thống kê và một CI gate bắt regression trước cả người dùng.
Eval suite của bạn không nên cần một adapter theo nhà cung cấp cho từng model bạn kiểm thử. Bắt đầu kiểm thử trên TokSpan —chạy cùng 50 test case với GPT, Claude và Gemini qua một điểm tích hợp duy nhất.