Agent Evaluation Framework 2026 - Kiến trúc Đánh giá Multi-Agent với LLM-as-Judge, Ragas, Braintrust, Redis và ClickHouse

Posted on: 4/14/2026 8:10:52 PM

Trong suốt năm 2024 và 2025, cộng đồng AI đã dành phần lớn năng lượng để xây agent: chọn framework, cắm MCP, ghép sub-agent, tinh chỉnh prompt. Đến đầu năm 2026, câu hỏi đã đổi từ "làm sao dựng được agent" sang "làm sao biết agent của mình thực sự hoạt động — và vẫn hoạt động sau mỗi lần thay đổi". Benchmarks công cộng như MMLU, HumanEval, SWE-bench chỉ cho bạn biết một mô hình thông minh đến đâu trên một bài thi cố định, không nói được agent của bạn có giải đúng loại công việc của khách hàng bạn. Đây là lý do vì sao evaluation framework trở thành phần quan trọng nhất của mọi hệ thống multi-agent production: nó biến "cảm giác agent hoạt động tốt" thành dữ liệu có thể kiểm chứng, so sánh và đem vào CI/CD.

Bài viết này đi sâu vào kiến trúc đánh giá agent năm 2026: phân loại metric, vai trò của LLM-as-Judge, cách xây golden dataset, cách dùng Redis và ClickHouse để biến pipeline eval thành một hệ thống quan sát được, và cách gắn chặt eval vào quy trình release để mỗi lần đẩy prompt mới không trở thành ván bài may rủi.

1. Vì sao agent cần eval framework riêng, không dùng benchmark công cộng

Benchmark công cộng được thiết kế để so sánh mô hình, không phải để đánh giá hệ thống. Một agent production là sự kết hợp của mô hình nền, prompt, công cụ, trí nhớ, chính sách an toàn và ngữ cảnh doanh nghiệp. Thay một con trong chuỗi đó — ví dụ nâng Claude Sonnet 4.5 lên Opus 4.6, thêm một tool gọi ERP mới, hay chỉ đổi rubric safety — và hành vi cuối cùng có thể thay đổi theo những hướng không dự đoán được. Benchmark công cộng không bao giờ chạm vào chuỗi này.

• Benchmark overfitting: Hầu hết các mô hình lớn đã "nhìn thấy" test set công cộng trong quá trình huấn luyện hoặc fine-tune. Điểm cao trên SWE-bench không đồng nghĩa với điểm cao trên repo nội bộ của bạn.
• Không đo trajectory: Benchmark kiểu multiple-choice chỉ chấm kết quả cuối, không chấm đường đi. Nhưng với agent, việc dùng sai tool, gọi lặp, hay bỏ qua bước xác thực mới là nguyên nhân gây thảm hoạ.
• Không có business metric: Một agent tư vấn bảo hiểm có thể rất "thông minh" nhưng chuyển đổi 2%; một agent khác "ngu hơn" nhưng chuyển đổi 12%. Benchmark không nói cho bạn điều đó.
• Không kiểm tra được guardrail: Safety, compliance, PII leakage, prompt injection là các nguy cơ phải đo định lượng trên dữ liệu của chính bạn.

2. Phân loại evaluation — bản đồ cần thuộc lòng

Trước khi chọn công cụ, phải hiểu mình đang đánh giá chiều nào. Có bốn trục chính mà một framework eval trưởng thành phải phủ được:

graph TD
    R[Agent Evaluation] --> T1[Theo thời điểm]
    R --> T2[Theo tín hiệu]
    R --> T3[Theo đối tượng đo]
    R --> T4[Theo mục đích]
    T1 --> T1A[Offline
pre-deploy]
    T1 --> T1B[Online
production]
    T2 --> T2A[Reference-based
có đáp án vàng]
    T2 --> T2B[Reference-free
đánh giá theo rubric]
    T3 --> T3A[Outcome
kết quả cuối]
    T3 --> T3B[Trajectory
đường đi]
    T3 --> T3C[Component
từng module]
    T4 --> T4A[Regression
không tụt]
    T4 --> T4B[Improvement
so sánh A/B]
    T4 --> T4C[Compliance
an toàn]
    style R fill:#e94560,stroke:#fff,color:#fff
    style T1 fill:#0f3460,stroke:#fff,color:#fff
    style T2 fill:#0f3460,stroke:#fff,color:#fff
    style T3 fill:#0f3460,stroke:#fff,color:#fff
    style T4 fill:#0f3460,stroke:#fff,color:#fff

Offline eval chạy trên dataset cố định trước khi deploy: nhanh, lặp được, dễ gắn vào CI. Điểm yếu là dataset cố định sẽ dần lệch so với phân phối traffic thật. Online eval chạy trên log production thật: phản ánh đúng người dùng, nhưng chỉ phát hiện vấn đề sau khi chúng đã xảy ra. Một kiến trúc trưởng thành luôn cần cả hai và dùng online feedback để nuôi lại offline dataset.

Reference-based đối chiếu output với đáp án vàng — dùng được cho task có đầu ra xác định (SQL, JSON, function call). Reference-free chấm điểm theo rubric — dùng cho câu trả lời mở, sáng tạo, tư vấn. Reference-free thường cần LLM-as-Judge và đó là nơi bias xuất hiện nhiều nhất.

3. Outcome vs Trajectory vs Component — ba chiều metric bắt buộc

Một thất bại điển hình của đội non kinh nghiệm là chỉ đo kết quả cuối cùng. Nhưng agent có đặc điểm đặc biệt: hai agent cho ra cùng một kết quả có thể hoàn toàn khác nhau về độ tin cậy. Một agent gọi đúng API ngay lần đầu, một agent retry 7 lần và gọi sai 3 tool trước khi may mắn đúng. Nhìn từ outcome thì giống nhau; nhìn từ trajectory thì một bên là production-ready, một bên là quả bom hẹn giờ.

4. LLM-as-Judge — công cụ quyền lực nhưng nhiều cạm bẫy

LLM-as-Judge là kỹ thuật dùng một mô hình mạnh (Claude Opus, GPT-class, Gemini 2.x) để chấm điểm output của agent. Nó cho phép scale việc đánh giá câu trả lời mở ra quy mô hàng triệu log mà nếu dùng nhân lực sẽ không tưởng. Nhưng nó không miễn phí về độ chính xác: nhiều nghiên cứu năm 2025 đã chỉ ra bốn loại bias làm biến dạng kết quả.

• Verbosity bias: Judge có xu hướng cho điểm cao câu trả lời dài. Giải quyết bằng cách normalize theo độ dài hoặc ép rubric có điểm trừ cho thông tin thừa.
• Position bias: Khi so sánh A và B, vị trí ảnh hưởng lớn. Luôn hoán đổi và lấy trung bình hai lượt.
• Self-preference bias: Judge có xu hướng thiên vị output của chính "họ hàng" mô hình. Chọn judge khác họ với agent.
• Verbose-rubric bias: Rubric càng nhiều chữ càng mơ hồ, điểm càng không nhất quán. Rubric tốt ngắn, đếm được, có ví dụ neo.

sequenceDiagram
    participant D as Dataset (golden)
    participant A as Agent Under Test
    participant J as Judge LLM
    participant C as Calibrator
    participant R as Redis (cache)
    participant CH as ClickHouse
    D->>A: input_i
    A->>R: check cache by hash
    R-->>A: miss
    A->>A: execute trajectory
    A->>R: store output, trajectory
    A->>J: prompt(output, rubric)
    J-->>A: {score, reason}
    A->>C: apply bias correction
    C-->>A: calibrated_score
    A->>CH: insert eval_run row
    CH-->>A: ack
    Note over C,J: Calibrator so với
golden human label

Cốt lõi của việc dùng LLM-as-Judge đúng cách là hai thứ: rubric có thể đo được và calibrator. Rubric nên viết theo kiểu check-list ("Có dẫn nguồn đúng không? Có dùng sai tool không? Có leak PII không?"), thay vì câu hỏi mở ("Câu trả lời có tốt không?"). Calibrator là một tập vàng vài trăm ví dụ đã được người gắn nhãn; mỗi lần nâng cấp judge hay rubric, bạn đo agreement rate (Cohen's kappa, Pearson) giữa judge và human — nếu rơi xuống dưới ngưỡng, không được dùng judge đó cho regression test.

5. Golden dataset — tài sản quý hơn model

Một sự thật nhiều team bỏ qua: mô hình có thể thay đổi, framework có thể đổi, nhưng golden dataset là cái còn lại và tăng giá trị theo thời gian. Dataset vàng tốt là thứ quyết định chất lượng mọi quyết định release sau này. Có bốn nguồn xây dataset thực tế:

1. Synthetic từ LLM: Dùng một model mạnh sinh ra các task mẫu. Nhanh nhưng dễ "đồng nhất" — phải được đội ngũ domain review lại.
2. Log production: Lấy hội thoại thật từ ClickHouse, lọc theo intent, độ dài, kết quả. Đây là nguồn phản ánh đúng phân phối traffic nhất.
3. Failure mining: Cào log những case thất bại (user phàn nàn, retry, fallback) — bổ sung liên tục để chống regression.
4. Red-team: Đội an toàn thiết kế case chống lại chính agent — prompt injection, edge case, adversarial input.

6. Kiến trúc pipeline eval tham chiếu 2026

Một pipeline eval production-grade cần đạt bốn tính chất: idempotent (chạy lại cùng input cùng agent version cho cùng kết quả), parallel (chạy vài nghìn ví dụ trong vài phút), observable (mỗi score đều trace ngược lại trajectory gốc), và versioned (biết rõ eval nào chạy trên model nào, prompt version nào, dataset version nào).

graph LR
    subgraph "Control Plane"
        UI[Eval UI / CLI]
        ORC[Eval Orchestrator]
    end
    subgraph "Data Plane"
        DS[(Golden Dataset
Postgres + S3)]
        Q[Redis Queue
Streams]
        W1[Worker 1]
        W2[Worker 2]
        W3[Worker N]
        A[Agent Under Test]
    end
    subgraph "Scoring"
        JUDGE[Judge LLM Pool]
        CAL[Calibrator Service]
        RUB[Rubric Registry]
    end
    subgraph "Storage & Analytics"
        CH[(ClickHouse
eval_runs)]
        DASH[Grafana / Superset]
        ALERT[Alertmanager]
    end
    UI --> ORC
    ORC --> DS
    ORC --> Q
    Q --> W1
    Q --> W2
    Q --> W3
    W1 --> A
    W2 --> A
    W3 --> A
    A --> JUDGE
    RUB --> JUDGE
    JUDGE --> CAL
    CAL --> CH
    CH --> DASH
    CH --> ALERT
    style ORC fill:#e94560,stroke:#fff,color:#fff
    style CH fill:#0f3460,stroke:#fff,color:#fff
    style Q fill:#dc382d,stroke:#fff,color:#fff
    style A fill:#4CAF50,stroke:#fff,color:#fff

Orchestrator nhận yêu cầu "chạy eval_suite X trên agent_version Y" và đẩy từng ví dụ vào Redis Streams. Worker pool tiêu thụ, gọi agent, thu trajectory, gửi sang judge pool, đẩy score vào ClickHouse. Kết quả gắn thành một run_id để có thể so sánh run-to-run.

7. Vai trò Redis — không chỉ là queue

Redis có mặt ít nhất bốn vai trò trong pipeline eval trưởng thành, và việc hiểu đúng giúp giảm đáng kể chi phí gọi LLM:

• Streams làm queue fan-out: Một eval suite 5.000 ví dụ có thể được phát vào XADD eval:stream, các worker đọc song song bằng consumer group. So với Kafka, Redis Streams setup nhẹ hơn và p99 thường dưới 10ms.
• Idempotent cache: Key eval:{agent_version}:{input_hash} lưu output và trajectory. Chạy lại suite không cần gọi LLM lại nếu agent_version chưa đổi — rẻ gấp nhiều lần.
• Semantic cache cho judge: Rubric + output similarly tương đương → reuse judge score. Cẩn thận: semantic cache chỉ an toàn với judge deterministic và rubric ít thay đổi.
• Rate limiting & token bucket: Gọi judge qua một proxy có rate limit bằng Redis để không đụng trần API provider trong lúc chạy hàng ngàn eval song song.
• Leaderboard & realtime stats: ZADD leaderboard:suite_id score agent_version để dashboard có thể hiển thị top agent version theo thời gian thực.

8. ClickHouse — event store và phòng thí nghiệm số

ClickHouse là công cụ hoàn hảo để lưu và truy vấn eval data vì ba đặc điểm: append-only, cột hoá, và SQL đủ mạnh để slice theo mọi chiều. Dưới đây là schema tham chiếu tối giản nhưng đủ dùng cho mọi trường hợp production:

CREATE TABLE eval_runs (
    run_id           UUID,
    suite_id         String,
    suite_version    String,
    agent_name       String,
    agent_version    String,
    model            LowCardinality(String),
    prompt_version   String,
    example_id       String,
    category         LowCardinality(String),
    difficulty       Enum8('easy'=1,'medium'=2,'hard'=3),

    -- kết quả
    outcome_score    Float32,
    trajectory_score Float32,
    safety_score     Float32,
    judge_reason     String,
    human_label      Nullable(Float32),

    -- cost & latency
    input_tokens     UInt32,
    output_tokens    UInt32,
    tool_calls       UInt16,
    latency_ms       UInt32,
    cost_usd         Float32,

    -- trace
    trace_id         String,
    trajectory_json  String,

    created_at       DateTime64(3)
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(created_at)
ORDER BY (suite_id, agent_version, created_at, example_id)
TTL created_at + INTERVAL 180 DAY;

Với schema này, bạn trả lời được các câu hỏi quan trọng bằng một truy vấn duy nhất:

-- So sánh agent_version mới vs cũ theo category
SELECT
    category,
    agent_version,
    avg(outcome_score)       AS outcome,
    avg(trajectory_score)    AS trajectory,
    avg(safety_score)        AS safety,
    avg(cost_usd)            AS cost,
    quantile(0.95)(latency_ms) AS p95_ms,
    count()                  AS n
FROM eval_runs
WHERE suite_id = 'production_suite_v3'
  AND agent_version IN ('2026-04-10','2026-04-14')
  AND created_at > now() - INTERVAL 24 HOUR
GROUP BY category, agent_version
ORDER BY category, agent_version;

9. Online evaluation — đo agent trên traffic thật

Offline eval dù tốt đến đâu vẫn có ba giới hạn: dataset luôn lệch một phần với phân phối thật, không phát hiện được concept drift, và không đo được tín hiệu người dùng. Do đó, mọi agent production cần một vòng eval online chạy trên chính log của nó:

graph LR
    U[User Traffic] --> A[Agent Prod]
    A --> L[Log Stream]
    L --> S[Sampler
1-10%]
    S --> E1[Implicit Eval
thumbs, retry, abandon]
    S --> E2[LLM Judge
offline scoring]
    S --> E3[Human Review
priority sampling]
    E1 --> CH[(ClickHouse
eval_runs)]
    E2 --> CH
    E3 --> CH
    CH --> D[Dashboard]
    CH --> DS[Dataset Miner]
    DS --> G[(Golden Dataset)]
    style A fill:#e94560,stroke:#fff,color:#fff
    style CH fill:#0f3460,stroke:#fff,color:#fff

Chú ý ba kỹ thuật quan trọng: stratified sampling (lấy mẫu theo category để không bỏ sót nhóm hiếm), priority sampling (ưu tiên review case có tín hiệu xấu — user retry, fallback, tool error), và counterfactual sampling (dùng shadow traffic chạy song song version cũ và mới cùng lúc trên cùng input — so sánh fair nhất).

10. Eval gate trong CI/CD — biến chất lượng thành hàng rào

Phần thưởng lớn nhất của eval framework là biến mỗi thay đổi agent thành một PR có thể review được bằng số. Pattern điển hình cho pipeline:

flowchart TD
    PR[Pull Request
prompt/model/tool change] --> L[Lint & unit test]
    L --> S[Smoke eval
50 examples]
    S --> D{Pass smoke?}
    D -- No --> FAIL[Fail CI]
    D -- Yes --> F[Full eval
2000 examples]
    F --> C{Regression detected?}
    C -- Yes --> BLK[Block merge +
post comparison report]
    C -- No --> SH[Shadow deploy]
    SH --> SHE[Shadow eval
24h online]
    SHE --> G{Meet SLO?}
    G -- No --> ROLL[Auto rollback]
    G -- Yes --> PROD[Promote to production]
    style PR fill:#e94560,stroke:#fff,color:#fff
    style PROD fill:#4CAF50,stroke:#fff,color:#fff
    style FAIL fill:#ff9800,stroke:#fff,color:#fff
    style BLK fill:#ff9800,stroke:#fff,color:#fff
    style ROLL fill:#ff9800,stroke:#fff,color:#fff

Một số quy tắc từ kinh nghiệm triển khai:

• Smoke eval < 5 phút: Nếu developer phải chờ quá lâu, họ sẽ vô hiệu hoá nó. Dùng subset 50-100 ví dụ representative.
• Full eval chạy parallel: 2.000 ví dụ song song 50 worker mất 4-8 phút; Redis Streams giữ backpressure gọn.
• Ngưỡng regression theo từng metric: Thay vì một điểm tổng, đặt threshold riêng cho outcome (ngưỡng nghiêm), safety (không được tụt dù 0.01), cost (không tăng > 15%).
• Comparison report trên PR: Post một bảng so sánh run cũ vs mới, slice theo category — đây là artifact giúp code review có nghĩa.
• Shadow deploy là không thể bỏ: Offline eval không bắt được tất cả; 24 giờ shadow trên traffic thật chặn 90% lỗi còn lại trước khi tác động người dùng.

11. Calibration và judge drift — bài toán dài hạn

Một rủi ro ít team để ý: judge model cũng thay đổi. Provider upgrade version, hành vi chấm khác đi, và toàn bộ trending của bạn bị lệch mà không ai biết. Giải pháp là calibration harness: mỗi tuần chạy judge trên một tập "kim cương" 200-500 ví dụ đã có human label cố định, đo agreement. Nếu kappa tụt dưới 0.7, freeze judge version, điều tra, và chỉ upgrade khi đã re-calibrate.

12. Case study — từ không eval đến eval gate 2.000 ví dụ mỗi PR

Tình huống thực tế từ một nhóm xây agent hỗ trợ kỹ thuật cho sản phẩm SaaS B2B. Trước khi có eval framework, đội release bằng "cảm tính": thay prompt, chạy thử 10 case, deploy. Sau ba tháng, số ticket phàn nàn tăng 40%; một lần thay model đã khiến agent ngừng escalate case thanh toán — vấn đề chỉ bị phát hiện sau 9 ngày.

Quá trình triển khai eval trong 6 tuần:

• Tuần 1-2: Lấy 1.500 log production, clean, gắn nhãn bằng 3 annotator nội bộ với rubric 5 chiều (đúng/đủ/thân thiện/an toàn/dẫn tool đúng). Cohen's kappa đa annotator: 0.78.
• Tuần 3: Dựng pipeline Redis + ClickHouse, 20 worker song song, một full run 1.500 ví dụ mất 6 phút.
• Tuần 4: Dựng judge với Claude Opus 4.6, calibrate xuống còn agreement 0.82 với human.
• Tuần 5: Gắn smoke eval 80 ví dụ vào CI; ba PR bị chặn vì regression outcome > 3 điểm — sau đó được fix trước khi merge.
• Tuần 6: Shadow deploy 24h cho mỗi release mới, tự động rollback 2 lần khi safety tụt bất ngờ.

Kết quả sau 8 tuần: ticket phàn nàn giảm 62%, thời gian điều tra bug giảm từ trung bình 3.5 ngày xuống 4 giờ, và đội engineering lần đầu tự tin đẩy thay đổi prompt ngay trước weekend mà không lo lo.

13. Roadmap triển khai 6 tháng

14. Những sai lầm thường gặp và cách tránh

15. Kết luận — eval là sản phẩm, không phải script

Năm 2026, ranh giới giữa đội AI "chơi" agent và đội AI "vận hành" agent nằm ở một thứ duy nhất: có eval framework coi việc đánh giá agent là một sản phẩm nội bộ — có owner, có roadmap, có SLA, có người chịu trách nhiệm. Redis và ClickHouse không phải là điều mới, nhưng ghép đúng cách chúng biến một vấn đề "đo đạc mơ hồ" thành một pipeline có thể quan sát, scale và bảo vệ quyết định release.

Nếu hôm nay đội của bạn đang đẩy prompt hay model bằng cảm tính, bước đầu tiên không phải là mua thêm công cụ: hãy bỏ ra một tuần thu 500 hội thoại thật, gắn nhãn 5 chiều với 3 người, và đo Cohen's kappa. Con số đó sẽ cho bạn biết chính xác đội mình đang ở đâu trên con đường eval — và từ đó mọi bước tiếp theo trở nên rõ ràng.

Nguồn tham khảo

• Braintrust — AI agent evaluation: A practical framework for testing multi-step agents
• Galileo — Agent Evaluation Framework 2026: Metrics, Rubrics & Benchmarks
• Confident AI — AI Agent Evaluation: Metrics, Traces, Human Review, and Workflows
• arXiv 2512.12791 — Beyond Task Completion: An Assessment Framework for Evaluating Agentic AI Systems
• Google Cloud — Evaluate Gen AI agents on Vertex AI
• Langfuse — Agent Evaluation cookbook
• Ragas — Metrics library cho RAG và agentic workflow
• ClickHouse — Documentation chính thức
• Redis Streams — Official documentation