TROISINH
Harness EngineeringFeedback Loops & Quality Gates

Evaluation & Scoring: Đánh giá output của agent

Chuyển từ 'vibe check' sang đánh giá hệ thống cho AI agent — từ regex đơn giản đến evaluator agent với Playwright, đảm bảo output đạt chuẩn trước khi vào pro...

Định nghĩa

Evaluation & Scoring là tập hợp các phương pháp đo lường chất lượng output của agent một cách có cấu trúc, chuyển từ đánh giá chủ quan ("có vẻ đúng") sang các tiêu chí khách quan, có thể tự động hóa và reproduce. Đây là cơ sở để xây dựng quality gatesfeedback loops mà Hashimoto đề cập: mỗi lần agent sai, ta xây dựng cơ chế scoring để nó không bao giờ mắc lỗi đó nữa.

Giải thích chi tiết

Vấn đề với "vibe check"

Hầu hết team mới bắt đầu với AI agent đều rơi vào bẫy "vibe check" — developer nhìn output và nói "trông ổn đấy". Điều này không scale: bạn không thể ngồi review từng response của agent lúc 3 giờ sáng, và "trông ổn" của người này khác người kia.

Evaluation & Scoring giải quyết bằng cách định nghĩa rõ ràng what good looks like — thành các rubric có thể đo lường. Không phải "code sạch" mà là "pass ESLint với zero warning", không phải "UI đẹp" mà là "render không lỗi layout trên viewport 375px với Playwright screenshot comparison".

Ba cấp độ evaluation

Trong thực chiến, bạn sẽ dùng ba lớp evaluation với độ sâu tăng dần:

1. Rule-based (Regex & Pattern matching) Nhanh, rẻ, deterministic. Phù hợp kiểm tra format, cấu trúc cơ bản, hoặc các lỗi known-issue. Đây là nơi frustration detection bằng regex thuộc về — ví dụ kiểm tra $0 thay vì $0.01 trong Claude Code.

2. Static analysis & Linter Kiểm tra structural correctness mà không cần execute. Linter integration của SWE-agent thuộc nhóm này — reject patch ngay trước khi apply nếu syntax error hoặc vi phạm type constraint.

3. Execution-based & Model-as-a-Judge Chạy thật hoặc dùng LLM khác đánh giá. Anthropic dùng evaluator agent với Playwright để verify UI output — thực sự render component và kiểm tra pixel. Hoặc dùng GPT-4 để score essay theo rubric 1-5, sau đó threshold để pass/fail.

Scoring Rubric Design

Một rubric tốt cần:

  • Dimensions riêng biệt: correctness, style, safety, performance — không gộp chung thành "chất lượng"
  • Scale rõ ràng: Binary (pass/fail) cho gating, Scalar (1-5) cho grading, Continuous (0-1) cho ranking
  • Threshold có lý do: Tại sao 4/5 là pass mà 3/5 là fail? Phải map với user impact (ví dụ: safety phải 5/5, style có thể 3/5)

Ví dụ thực tế

Claude Code: Regex thắng model call

Trong Claude Code, team phát hiện agent thường nhầm lẫn giá tiền — ghi $0 thay vì $0.01. Thay vì gọi thêm một lần LLM để check (tốn token và latency), họ dùng regex đơn giản để detect pattern \$0[^\d] hoặc \$0$. Kết quả: accuracy tương đương model call nhưng latency dưới 1ms. Đây là frustration detection bằng rule-based scoring — bắt lỗi trước khi user thấy.

SWE-agent: Linter là quality gate

SWE-agent không để agent tự ý apply code patch. Trước khi write vào file, hệ thống chạy linter (Python syntax check, ESLint, v.v.) để score output về correctness. Nếu score = 0 (có lỗi syntax), agent bắt buộc phải regenerate. Đây là feedback loop chặt chẽ: lỗi syntax → reject → retry với context mới.

Anthropic: Evaluator agent với Playwright

Với agent generate UI code, Anthropic không chỉ kiểm tra HTML string mà spawn evaluator agent dùng Playwright để thực sự render trên browser headless. Scoring dựa trên: có crash không? Layout shift có vượt ngưỡng không? Các interactive element có respond đúng không? Đây là execution-based evaluation — expensive nhưng đáng tin cậy nhất cho user-facing output.

Ứng dụng

AI Engineer xây dựng pipeline Thiết kế CI/CD cho agent không chỉ là deploy model — là deploy evaluation suite. Mỗi PR phải chạy qua bộ scoring: unit test (rule-based), integration test (execution-based), và human evaluation sampling (model-as-judge cho corner cases).

Tech Lead thiết lập quality bar Dùng evaluation metrics để đặt SLA. Ví dụ: "95% response phải đạt correctness score ≥ 4/5", "Zero safety violation (binary fail)". Đây là data-driven alternative cho "tôi thấy agent đang hoạt động tốt".

Product Manager định nghĩa success Thay vì chỉ tracking "user click", tracking "output quality score distribution". Nếu mean score giảm từ 4.2 xuống 3.8 sau một deploy, rollback ngay — trước khi user complaint flood vào support.

So sánh

Phương phápTốc độĐộ tin cậyCostUse case
Rule-based (Regex)Cực nhanh (dưới 1ms)Cao cho pattern knownZeroFormat check, known bugs
Linter/StaticNhanh (dưới 100ms)Cao cho syntaxThấpCode correctness
Model-as-JudgeTrung bình (1-3s)Trung bình (bias có thể xảy ra)Trung bìnhSemantic quality, style
Execution-basedChậm (5-30s)Cao nhấtCaoUI rendering, API integration

Kết luận: Bạn không chọn một — bạn xếp chúng thành pipeline. Rule-based là cổng vào (filter rác nhanh), linter là kiểm tra cấu trúc, execution-based là gate cuối cùng trước khi đến user. Model-as-judge dùng cho sampling và corner cases mà rule không cover.

Bài viết liên quan

Cùng cụm

Feedback Loop Design

Khi agent sai, hệ thống phản hồi thế nào để nó không tái phạm — kiến trúc loop đóng kín lỗi

Linter Integration

Reject lỗi syntax trước khi apply — scoring đầu tiên trong pipeline

Quality Gates

Không cho agent skip bước — thiết kế gating dựa trên evaluation score

Frustration Detection

Regex thắng model call khi accuracy tương đương — tối ưu rule-based scoring

Đọc tiếp

State & Session Management

Lưu trữ evaluation history và score trend để cải thiện agent qua thời gian

Multi-Agent Architecture

Triển khai evaluator agent riêng biệt — pattern chuyên gia đánh giá chuyên gia thực thi

On this page