Xây Evaluation Harness #26

Trả lời ngắn: Evaluation harness là bộ case/fixture, runner, scorer, threshold và report để chạy cùng một evaluation lặp lại trên baseline và candidate. Harness tốt giữ dataset/version/provenance, xem failure slice và high-impact floor, rồi trả quyết định pass, hold hoặc block có evidence thay vì một điểm average.

Đọc xong, bạn sẽ hiểu:

• Vì sao vài output mẫu không phải là evaluation harness.
• Cách thiết kế fixture, runner, scorer, threshold và report.
• Cách phân tích regression theo slice thay vì chỉ xem average.
• Khi nào case flaky, label stale hoặc provenance thiếu phải chuyển thành NOT_VERIFIED.

Lưu ý giáo dục: Case, output, ID và metric đều synthetic. Không đưa customer transcript, private prompt, secret hoặc production token vào harness thử nghiệm. Dataset, judge và threshold thật cần owner, privacy review và kiểm tra bias phù hợp.

1. Evaluation harness là gì?

Một prompt chạy bốn câu hỏi bằng tay rồi chọn câu trả lời mình thích là demo, không phải harness. Harness là bộ runner, case, scorer, threshold và report để đo lặp lại. Fixture là case/input cố định; runner chạy system trên fixture; scorer biến output thành điểm hoặc label; threshold quyết định pass/hold/fail.

Case support copilot EVAL-26 có flow:

Hình 1 — Harness biến case thành run, score, report và release decision; mỗi chặng cần ID và evidence.

Harness không bảo đảm output đúng tuyệt đối. Nó làm cách đo rõ hơn, repeatable hơn và dễ thấy regression hơn. Nếu model có stochastic behavior, ghi config, sample policy, seed nếu có, provider/model version và trạng thái NOT_STABLE khi chưa đủ consistency.

2. Thiết kế case và dataset

Dataset evaluation không chỉ là nhiều dòng. Mỗi fixture cần input synthetic, expected behavior, category, risk, source/version, label policy, owner và last-reviewed date. Case CASE-001 clear request; CASE-002 mixed-language; CASE-003 policy conflict; CASE-004 high-impact cần human handoff.

Giữ golden và holdout riêng. Golden giúp kiểm behavior đã biết; holdout giữ lại để xem candidate ngoài data tuning. Nếu người viết prompt nhìn holdout rồi chỉnh cho pass, benchmark bị leakage. Version dataset, label và evaluator; khi policy thay đổi, report cũ phải nói dùng version nào.

Hình 2 — Slice matrix giữ high-impact floor và cho thấy average không thể che một nhóm fail.

Privacy boundary cũng là một phần dataset design. Dùng synthetic input, redaction và least-privilege access. Không cần lưu raw transcript để prove case đã chạy; giữ case ID, hash giả, expected label và evidence cần thiết. Nếu label conflict, ghi disagreement và adjudication, không chọn một nhãn vì nó làm điểm đẹp hơn.

3. Runner, scorer và report

Runner nhận immutable case set và version bundle, gọi system, ghi trace, sau đó đưa output cho scorer. Scorer deterministic phù hợp cho schema, required field, exact label, policy flag hoặc tool permission. Bounded judge có thể hỗ trợ helpfulness/clarity nhưng cần rubric, calibration sample, judge version và reviewer spot-check.

Pipeline giả:

1. Load DATASET-26-04 và bundle baseline/candidate.
2. Validate schema, provenance, labels và no-leakage rule.
3. Run fixture, ghi RUN-26-A, trace, latency, error và output class.
4. Score deterministic checks trước; judge chỉ chấm dimension có rubric.
5. Aggregate theo overall và slice; tạo report với failure examples.
6. Compare baseline/candidate, mở triage và trả gate decision.

Report tối thiểu có run ID, code/harness version, dataset/evaluator version, bundle, timestamp, overall/slice metrics, cost/latency, failure taxonomy, unknowns, owner và decision. Nếu runner timeout, không lặng lẽ bỏ case; ghi RUN_ERROR và cập nhật denominator minh bạch.

Hãy tách ba tầng kết quả. Tầng execution nói runner có chạy xong không; tầng behavior nói output có khớp schema, label, source hoặc rubric không; tầng decision nói report có đủ điều kiện pass/hold/fail không. Một case execution pass nhưng behavior fail là failure thật. Một behavior pass nhưng execution log thiếu bundle hoặc dataset version vẫn chưa đủ release evidence. Tách tầng giúp triage đúng chỗ và tránh sửa scorer để che runner lỗi.

Với judge dùng model, lưu rubric và vài ví dụ calibration cùng report. Nếu judge đổi, cùng output có thể nhận điểm khác; đó là evaluator version change cần re-run baseline. Với scorer rule, test chính scorer bằng output synthetic trước khi tin kết quả harness. Khi một metric là proxy, ghi rõ proxy đang đại diện cho behavior nào và hành động nào sẽ xảy ra nếu proxy lệch. Harness không nên tự động biến điểm thành claim “người dùng hài lòng” nếu chưa có evidence tương ứng.

Regression là behavior hoặc metric xấu đi sau change. Một candidate average tốt hơn nhưng mixed slice thấp hơn floor vẫn là regression cần block. Flaky test lúc pass lúc fail dù input/config không đổi; gắn NOT_STABLE, điều tra seed/provider/time dependency, không biến lần pass ngẫu nhiên thành release evidence.

Azure RAG evaluation mô tả việc đánh giá chất lượng retrieval/generation và các chiều đo cần theo context; link chính thức giúp chọn câu hỏi, nhưng harness vẫn phải có fixture, scorer và threshold phù hợp use case. Azure RAG evaluation

4. Threshold, regression và release gate

Baseline B-26 có clear 0,91, mixed 0,86, high-impact handoff 100%, tool schema error 1% và p95 2,4 giây. Candidate C-26 clear 0,93, mixed 0,87, handoff 100%, error 1,2%, p95 2,1 giây. Nếu floor mixed ≥0,84 và schema error ≤2%, candidate có thể vào canary. Nếu mixed xuống 0,80 hoặc handoff 99%, average đẹp cũng không cứu được.

Threshold cần context: sample size, confidence, slice risk, cost và action khi fail. “Tăng 2 điểm” không tự nói là meaningful; sample nhỏ có thể noise. Đặt error budget và minimum coverage cho high-impact. Nếu dataset chưa đủ đại diện, ghi coverage gap và giữ HOLD.

Gate sequence:

1. Data gate: case, label, provenance, split và privacy pass.
2. Run gate: runner complete, trace/report đầy đủ, error phân loại.
3. Score gate: deterministic checks, judge rubric và slice metrics pass.
4. Risk gate: high-impact, policy, tool permission và fallback pass.
5. Release gate: reviewer approve, candidate canary, rollback artifact tồn tại.

Hình 3 — Regression triage không chỉ sửa output; nó quyết định hold/rollback, cập nhật case và tạo test tiếp theo.

NIST AI RMF Core đặt risk management trong vòng đời; harness là một measurement control, không phải bằng chứng duy nhất cho governance. NIST AI RMF Core

5. Sai lầm, giới hạn và fallback

• Benchmark gaming: chỉnh prompt theo test set rồi báo pass. Fallback: holdout, frozen slice và reviewer.
• Leakage: cùng case xuất hiện train/tune và evaluation. Fallback: provenance, split audit và quarantine.
• Judge bias: judge thích style hơn correctness. Fallback: rubric, calibration, deterministic checks và human sample.
• Average-only: slice rủi ro bị che. Fallback: per-slice floor và coverage gate.
• Flaky case: pass/fail ngẫu nhiên. Fallback: NOT_STABLE, reproduce và triage.
• Stale label: policy đổi nhưng expected answer cũ. Fallback: label version/date và re-adjudication.
• False precision: điểm 0,873 được trình bày như sự thật tuyệt đối. Fallback: interval, sample và uncertainty.
• Missing denominator: bỏ case lỗi khỏi report. Fallback: report all outcomes và explain exclusions.
• Cost blindness: run quá lớn khiến team không chạy lại. Fallback: tiered suite, smoke/full run và budget.

Harness cũng có giới hạn: scorer có thể đo proxy thay vì user outcome; synthetic case thiếu edge case; model provider drift; human label không đồng nhất; eval loop chậm hơn release. Vì vậy report phải ghi limitation, open question và next evidence. Harness tốt làm uncertainty dễ nhìn, không xóa uncertainty.

6. Practice Bridge 15 phút

Mở Google Sheets hoặc Notes miễn phí. Tạo cột case_id, slice, expected, runner, scorer, baseline, candidate, threshold, failure, decision, owner. Dùng bốn fixture synthetic.

Mẫu đối chiếu đã điền

Trong 15 phút, thêm một scorer deterministic, một threshold, một failure label và một owner. Stop condition: nếu không biết dataset version, denominator, high-impact floor hoặc reason fail, ghi NOT_VERIFIED và chưa dùng row đó làm release evidence.

Ghi thêm ngày chạy và người review để lần sau biết report nào còn đáng tin.

7. Tổng kết: harness làm measurement lặp lại được

a. Năm ý chính

• Harness nối fixture, runner, scorer, threshold và report để evaluation lặp lại.
• Dataset cần slice, golden/holdout, provenance, labels, privacy và version.
• Runner phải ghi mọi outcome; scorer deterministic và judge có rubric/giới hạn khác nhau.
• Threshold theo slice, high-impact floor và coverage quan trọng hơn average đơn độc.
• Leakage, flaky test, stale label hoặc missing denominator là lý do hold/NOT_VERIFIED.

b. Câu hỏi tự kiểm tra

• Harness khác một bảng output mẫu ở đâu?
• Vì sao cần holdout?
• Khi nào judge score cần human calibration?
• Vì sao high-impact floor có thể override average?

c. Gợi ý đáp án

Xem gợi ý câu 1

Harness có runner, scorer, threshold, report và provenance để chạy/so sánh lặp lại; bảng output mẫu thì không. Xem lại mục 1 và mục 3.

Xem gợi ý câu 2

Holdout cho thấy candidate ngoài data đã dùng để tuning, giúp giảm leakage và benchmark gaming. Xem lại mục 2.

Xem gợi ý câu 3

Judge subjective nên có rubric, calibration sample, judge version và spot-check để hiểu bias. Xem lại mục 3 và mục 5.

Xem gợi ý câu 4

High-impact failure có risk lớn dù average đẹp; floor bảo vệ nhóm không được hy sinh. Xem lại mục 4.

d. Thuật ngữ cần nhớ

e. Nguồn tham khảo

• Azure RAG evaluation — evaluation dimensions và failure analysis.
• OpenAI Agents guide — tools, guardrails, state và tracing.
• NIST AI RMF Core — measurement và risk lifecycle.

Bài trước là Viết AI System Design Document #25. Bài tiếp theo là Xây Safety và Failure-mode Register #27.

Lưu ý giáo dục: Một report pass chỉ có giá trị khi case, dataset, runner, scorer, threshold và denominator rõ. Nếu slice high-impact hoặc provenance chưa đủ, giữ HOLD/NOT_VERIFIED.