Bài 54: Vì sao đánh giá LLM khó hơn ML truyền thống

Sau bài này, bạn cần:

• Giải thích được vì sao đánh giá LLM khó hơn ML cổ điển (Series 2).
• Liệt kê 6 thử thách: open-endedness, multiple valid answers, subjective quality, hallucination, bias/safety, reasoning depth.
• Phân biệt 4 nhóm metric (reference-based, LLM-as-judge, human, task-specific) và biết khi nào dùng nhóm nào.
• Phân biệt benchmark eval (MMLU, HellaSwag) và production eval (real user feedback).
• Hiểu Goodhart's Law và vấn đề data contamination ảnh hưởng đến độ tin cậy benchmark.
• Ước lượng được trade-off chi phí giữa human eval, LLM-as-judge, automatic metric.
• Biết các framework eval (lm-evaluation-harness, HELM, DeepEval, Promptfoo).

Module 9 gồm 6 bài. Bài 54 (bài này) trả lời "vì sao khó". Bài 55-59 đi sâu từng nhóm phương pháp: reference metric, LLM-as-judge, hallucination, RAG eval, benchmark phổ biến.

ML cổ điển — output rời rạc / số:
─────────────────────────────────────────────────────────
Classification           accuracy, precision, recall, F1, AUC
Regression               MSE, MAE, R², RMSE
Ranking                  NDCG, MAP, MRR
Clustering               silhouette, ARI, V-measure
Detection / segmentation IoU, mAP

Đặc điểm chung:
  - Có ground truth duy nhất (label đúng / sai).
  - Metric ra 1 con số trên test set.
  - Kết quả deterministic với cùng input.
  - So sánh hai model = so sánh hai con số.

Series 2 (ai-machine-learning) đã dùng các metric này cho tasks như phân loại email spam, dự báo giá nhà, phân cụm khách hàng. Quy trình rõ ràng: chia train/val/test, fit model, đo metric trên test, chọn model có metric cao nhất.

Toàn bộ giả định nằm ở chỗ: có một ground truth duy nhất cho mỗi input. Giả định này không còn đúng với LLM.

LLM — output là text generation open-ended:
─────────────────────────────────────────────────────────
  - Output là chuỗi token có độ dài thay đổi.
  - Cùng 1 prompt có thể có nhiều câu trả lời đều "đúng".
  - Chất lượng phụ thuộc tiêu chí (helpful, factual,
    creative, an toàn, đúng format) — đôi khi xung đột.
  - Sampling (temperature > 0) → cùng input ra output khác.
  - Khó định nghĩa "ground truth" duy nhất.
  - Một câu trả lời có thể đúng fact nhưng lệch tone,
    hoặc đúng tone nhưng sai fact.

Ví dụ đơn giản: prompt "Viết câu mở đầu cho email từ chối phỏng vấn". Câu trả lời có vô số phiên bản chấp nhận được, mỗi phiên bản đánh giá khác nhau ở các trục: lịch sự, ngắn gọn, formal, mức độ giải thích. Không có một label duy nhất để so khớp.

Đây là lý do nền tảng khiến không thể "porting" trực tiếp accuracy / F1 sang LLM.

Prompt: "Viết một bài thơ ngắn về AI."
─────────────────────────────────────────────────────────
Output A — 4 câu lục bát, ẩn dụ "lửa và đêm".
Output B — haiku 3 dòng.
Output C — thơ tự do, vần lưng.
Output D — đoạn văn xuôi có nhịp.

Cái nào "đúng"?  Tất cả đều hợp lệ.
String match với reference đơn lẻ → ~0 điểm cho mọi output.

Với task open-ended, không gian câu trả lời đúng quá lớn. Metric so khớp chuỗi (exact match, edit distance) sẽ phạt mọi câu trả lời không trùng tham chiếu — kể cả khi câu trả lời tốt hơn tham chiếu.

Hệ quả: cần metric "soft" (nghĩa tương đương) hoặc judge có khả năng đọc hiểu — đây là động lực cho BLEU/ROUGE/BERTScore (Bài 55) và LLM-as-Judge (Bài 56).

Translation EN → VI:
─────────────────────────────────────────────────────────
Source : "The book is on the table."
Valid 1: "Quyển sách ở trên bàn."
Valid 2: "Cuốn sách nằm trên bàn."
Valid 3: "Trên bàn có quyển sách."
Valid 4: "Sách đang đặt trên bàn."
... (vô số biến thể đúng nghĩa, khác diễn đạt)

Summarization một bài báo 1000 từ:
  - Tóm 3 câu, 5 câu, 10 câu đều có thể đúng.
  - Chọn ý nào để giữ → tùy mục đích.

BLEU và ROUGE phần nào giải quyết bằng n-gram overlap nhiều reference, nhưng nếu chỉ có 1 reference (đa số dataset thực tế) thì hai bản dịch đúng nhưng diễn đạt khác sẽ ra điểm chênh lệch lớn.

Đây là lý do BERTScore (so semantic embedding) và LLM-as-judge (so ngữ nghĩa) ngày càng phổ biến trong evaluation pipeline thực tế.

Tiêu chí khó định lượng:
─────────────────────────────────────────────────────────
  helpfulness     — câu trả lời có giải quyết nhu cầu?
  creativity      — ý mới, góc nhìn mới?
  tone            — formal / casual / thân thiện?
  conciseness     — ngắn gọn không cắt ý?
  fluency         — đọc trôi chảy?
  safety          — không có nội dung gây hại?

Annotator inter-rater agreement trên các tiêu chí này
thường chỉ 60-80% (Cohen's kappa 0.4-0.7) — nghĩa là
hai người chấm cùng output đôi khi bất đồng.

Bouquet et al. và nhiều khảo sát sau cho thấy: ngay cả với hướng dẫn chấm chi tiết, người chấm vẫn không hoàn toàn thống nhất. Khi metric "tự nhiên" đã có noise ở tầng người, thì kỳ vọng một con số tự động duy nhất phản ánh chất lượng là không khả thi.

Cách tiếp cận thực tế: chấm trên nhiều chiều (multi-criteria) thay vì một điểm tổng; chấp nhận noise và đo bằng nhiều annotator để lấy trung bình hoặc majority.

Hallucination: model trả lời với giọng văn tự tin nhưng nội dung sai sự thật (bịa fact, sai số liệu, viện dẫn nguồn không tồn tại).

Khó ở chỗ:
─────────────────────────────────────────────────────────
  - Câu chữ trông trôi chảy, đúng ngữ pháp, đúng format.
  - Sai ở mức fact — cần kiến thức ngoài để phát hiện.
  - Không thể phát hiện bằng metric so chuỗi.
  - Cần fact-check: đối chiếu KB, search web, hoặc
    consensus giữa nhiều model.
  - Mỗi câu fact-check tốn chi phí (search API, người đọc).

Bài 57 đi sâu cách phát hiện và đo lường hallucination (SelfCheckGPT, FActScore, faithfulness trong RAG). Trong scope bài này, ta chỉ cần ghi nhận: phát hiện hallucination là một trục đánh giá riêng và đắt đỏ.

Bias / harmful output dạng tinh vi:
─────────────────────────────────────────────────────────
  - Gender / racial stereotype trong câu trả lời.
  - Refuse trả lời với một số nhóm đối tượng nhưng
    chấp nhận với nhóm khác.
  - Output có thông tin nguy hiểm khi prompt vô tội.
  - Bị jailbreak qua phrasing đặc biệt.

Khó test exhaustive vì:
  - Không gian prompt vô hạn.
  - Adversarial user liên tục thử kỹ thuật mới.
  - Một bộ test fixed nhanh chóng lỗi thời.

Các bộ test phổ biến: BBQ (bias QA), ToxiGen (toxicity), HarmBench, JailbreakBench. Tất cả đều là sample của không gian, không thể bao phủ trọn vẹn. Red-teaming chủ động (cố tình tìm cách phá) là phần bổ sung quan trọng nhưng tốn người.

Final answer đúng KHÔNG đồng nghĩa với reasoning đúng:
─────────────────────────────────────────────────────────
Task: 12 × 13 = ?
Model A reasoning:
  "12 × 13 = 12 × (10 + 3) = 120 + 36 = 156" → đáp án 156 ✓
Model B reasoning:
  "12 × 13 ≈ 150, làm tròn xuống 156" → đáp án 156 ✓ (logic sai)
Model C reasoning:
  bịa các bước sai nhưng vô tình ra 156.

Code generation:
  - Code chạy đúng test case nhưng O(n²) thay vì O(n log n).
  - Đúng output nhưng vi phạm constraint không kiểm tra được.

Với task lý luận (math, code, logic), đánh giá chỉ dựa final answer có thể đánh giá cao những lối tắt may mắn. Quá trình suy luận cũng cần được đo — đây là động lực cho process-based reward model và step-by-step verifier.

Lightman et al. 2023 (Let's Verify Step by Step, arXiv 2305.20050) chỉ ra: process supervision (chấm từng bước) cải thiện đáng kể model trên MATH so với outcome supervision (chỉ chấm kết quả cuối).

Nhóm                Ví dụ                    Đặc điểm
─────────────────────────────────────────────────────────────
Reference-based     BLEU, ROUGE, METEOR,    Cần reference. Rẻ, nhanh.
                    BERTScore, BLEURT.       Yếu với output sáng tạo.
                    (Bài 55)

LLM-as-Judge        GPT-4 / Claude chấm     Bám sát cảm nhận người.
                    output theo rubric.      Có bias judge. Tốn API.
                    (Bài 56)

Human evaluation    Side-by-side, Likert,   Gold standard. Tốn $$ và
                    Arena (Chatbot Arena).   thời gian. Noise giữa
                                             annotator.

Task-specific       Exact match (QA),       Khi task có ground truth
                    pass@k (code),           cứng. Không gen-eral.
                    accuracy (multi-choice),
                    IoU (UI extraction).

Quy tắc chọn: nếu task có ground truth cứng (multi-choice, extraction, code chạy được test) → task-specific. Nếu task có reference nhưng đa dạng → reference-based + LLM-judge. Nếu task open-ended (chat, viết) → LLM-judge + human spot-check.

                   Benchmark                Production
─────────────────────────────────────────────────────────
Dataset            Cố định, public          Real user prompt
Phân phối          Curated (academic)       Long-tail, noisy
Mục đích           So model với model       Đo trải nghiệm thực
Metric             Accuracy, pass@k         Satisfaction, retention,
                                            CSAT, p95 latency
Ví dụ              MMLU, HellaSwag,         A/B test, thumbs up/down,
                   HumanEval, MT-Bench      session length, complaint
Tần suất           Khi release model        Liên tục (online)

Hệ quả quan trọng: benchmark cao không bảo đảm production tốt. Một model điểm MMLU 85% có thể trả lời kém các câu user thật vì distribution khác. Ngược lại model điểm thấp hơn vài % có thể được user yêu thích hơn nhờ tone, độ dài, format.

Chatbot Arena (LMSYS) là một ví dụ kết hợp: dùng user thật chấm side-by-side, tổng hợp Elo score. Đây là metric "production-style" nhưng vẫn chuẩn hóa được giữa các model.

Goodhart's Law (1975, Charles Goodhart): "When a measure becomes a target, it ceases to be a good measure." Khi một metric trở thành mục tiêu tối ưu, nó mất khả năng đo lường thứ nó từng đo.

Trong LLM eval:
─────────────────────────────────────────────────────────
  - Optimize cho MMLU → model học pattern multi-choice
    nhưng khả năng chat thực tế không tốt thêm tương xứng.
  - Optimize cho BLEU translation → câu dịch lặp n-gram của
    reference, kém tự nhiên.
  - Optimize cho thumbs-up rate → model nịnh nọt user (sycophancy)
    thay vì đúng.

Cách giảm tác động: dùng nhiều metric độc lập, giữ một số metric "ngoài training" để giám sát; thường xuyên thay test set; bổ sung evaluation định tính (đọc spot-check) bên cạnh số.

Contamination = test data đã có mặt trong pretrain corpus.
─────────────────────────────────────────────────────────
Vấn đề:
  - LLM crawl Common Crawl + GitHub + arXiv + diễn đàn.
  - Nhiều benchmark (MMLU, HumanEval, MATH) public từ lâu.
  - Đáp án benchmark thường xuất hiện trong web.
  - Khi test, model có thể "nhớ" thay vì "suy luận".

Hậu quả:
  - Score benchmark cao hơn năng lực thật.
  - So sánh model bị méo: model train data mới chiếm lợi.
  - Khó verify vì pretrain corpus đóng (proprietary).

Các nỗ lực giảm contamination: benchmark "live" (LiveCodeBench, LiveBench) thay câu hỏi định kỳ; canary string trong câu hỏi để check leak; tạo benchmark mới khó (GPQA Diamond, ARC-AGI) khi benchmark cũ "no đầy". Đây là cuộc rượt đuổi liên tục.

Magar & Schwartz 2022, Sainz et al. 2023, và Roberts et al. 2023 cung cấp các phương pháp detect contamination — vẫn là vấn đề mở năm 2026.

Một thay đổi (fine-tune, prompt, RAG) có thể:
─────────────────────────────────────────────────────────
  - Tăng accuracy QA + giảm fluency.
  - Tăng safety + tăng tỷ lệ refuse với prompt hợp lệ.
  - Tăng pass@1 code + giảm pass@5 (vì giảm diversity).
  - Tăng MMLU + giảm khả năng multilingual.

Pareto improvement = cải thiện ít nhất 1 metric mà
KHÔNG giảm metric nào khác. Thường khó đạt.

Trade-off (Pareto frontier):
  - Phải chọn metric ưu tiên theo use case.
  - Multi-metric eval (radar chart, table) thay vì 1 số.

Vì vậy đánh giá LLM hiếm khi gom về một con số. Tốt nhất là báo cáo một bảng nhiều metric, đánh dấu cell có thay đổi đáng kể, và để người ra quyết định cân nhắc trade-off.

Chiều         Câu hỏi                  Ví dụ metric
─────────────────────────────────────────────────────────
Capability    Model làm được gì?       MMLU, HumanEval, GSM8K,
                                       MATH, SWE-Bench
Safety        Output có hại không?     HarmBench, ToxiGen, BBQ,
                                       jailbreak success rate
Robustness    Input adversarial /      AdvGLUE, paraphrase
              nhiễu vẫn ổn?            invariance, typo robustness
Fairness      Bias theo nhóm?          BBQ, StereoSet, demographic
                                       parity ở output rate
Efficiency    Latency, cost, VRAM?     tokens/sec, $/1M token,
                                       memory footprint, p95 ms

Một báo cáo eval đầy đủ nên đụng cả 5 chiều. Trong thực tế, các team thường ưu tiên 2-3 chiều phù hợp use case (ví dụ: customer support chatbot quan tâm capability + safety + latency).

1. Build test set nhỏ đại diện — 50-200 case lấy từ user thật hoặc do team viết tay phản ánh các tình huống quan trọng.
2. Mix metric:
   • Automatic (BLEU/ROUGE/exact match): rẻ, làm "guardrail" smoke test.
   • LLM-as-judge: bám cảm nhận người, scale được.
   • Human (annotator): trên một subset, làm calibration cho LLM-judge.
3. Track theo thời gian — lưu lịch sử điểm theo commit / version model / version prompt.
4. Luôn có baseline — so với phiên bản trước, so với GPT-4 hoặc Claude làm reference.
5. Refresh test set định kỳ — thêm case mới từ production fail; loại case lỗi thời.

Quy tắc cho team mới: bắt đầu nhỏ. Một test set 50 case + LLM-as-judge là đủ để phát hiện regression khi đổi prompt hoặc đổi model.

A/B test khi đã có user thật:
─────────────────────────────────────────────────────────
Variant A (control)   : prompt / model hiện tại
Variant B (treatment) : thay đổi mới

Metric production:
  - Thumbs up rate, regenerate rate, copy rate.
  - Session length, retention 7d / 30d.
  - Conversion (đặt hàng, sub, click).
  - Latency p50/p95/p99.
  - Cost / request, cost / user.
  - Số ticket support sinh ra.

Cần:
  - Sample size đủ (power analysis).
  - Random assignment đúng (per-user, không per-request).
  - Theo dõi tín hiệu dài hạn (vài tuần).

Production metric phản ánh giá trị kinh doanh thực tế nhưng noise cao và chậm. Offline eval (benchmark + LLM-judge) làm bước lọc nhanh trước khi đẩy thay đổi vào A/B test. Hai loại bổ sung lẫn nhau.

Phương pháp           Chi phí / response   Độ tin cậy
─────────────────────────────────────────────────────────
Automatic metric      Gần như free         Trung bình.
(BLEU, ROUGE,         (vài giây CPU)        Yếu với open-ended.
exact match)

LLM-as-Judge          $0.001 - $0.01       Cao nếu rubric tốt
(GPT-4 / Claude judge)(input + output       và judge mạnh.
                       prompt + scoring)    Có bias judge.

Human eval            $10 - $100           Gold standard.
(crowd / chuyên gia)  (tùy độ phức tạp     Noise giữa annotator.
                       task và market)

Production signal     Free                 Chậm, nhiễu, lệch
(user thumbs, A/B)                          khán giả nhưng đúng
                                            mục tiêu kinh doanh.

Một pipeline thực tế hiệu quả: automatic làm smoke test cho mọi commit; LLM-as-judge chạy nightly trên test set chính (~500 case); human eval làm calibration hàng quý hoặc khi có regression nghi vấn; A/B test cho thay đổi lớn.

Khi reasoning model (o1, o3, DeepSeek-R1, Claude 3.7 thinking)
xuất hiện, benchmark cũ (MMLU, HellaSwag) bão hòa (> 90%).
Benchmark mới khó hơn:
─────────────────────────────────────────────────────────
Mathematical reasoning
  - AIME (American Invitational Math Exam)
  - MATH (Hendrycks et al., 12.5K bài thi olympiad)
  - Putnam, OmniMATH

Code
  - SWE-Bench / SWE-Bench Verified (sửa bug repo thật)
  - HumanEval+, MBPP+ (test case mở rộng)
  - LiveCodeBench (live, ít contamination)
  - BigCodeBench, CRUXEval

General reasoning
  - GPQA (Graduate-level Google-Proof Q&A)
  - ARC-AGI (Abstract Reasoning Corpus)
  - BIG-Bench Hard (BBH)
  - DROP, MUSR, Zebra Puzzles

Long-context / agent
  - RULER, LongBench, ∞Bench
  - τ-Bench, AgentBench, WebArena

Đặc trưng chung của lứa benchmark mới: ít contamination, cần multi-step reasoning, có ground truth verify được tự động. Bài 59 sẽ overview chi tiết MMLU, HellaSwag, HumanEval.

Framework               Vai trò
─────────────────────────────────────────────────────────
lm-evaluation-harness   EleutherAI. Standard cho benchmark
                        academic (MMLU, ARC, HellaSwag,
                        GSM8K, HumanEval...). Hỗ trợ
                        nhiều model backend.
HELM                    Stanford CRFM. Holistic Evaluation
                        of Language Models — multi-metric,
                        multi-scenario, ưu tiên fairness,
                        robustness, efficiency.
DeepEval               Confident AI. Pytest-style cho eval
                        ứng dụng LLM. Có metric RAG, hallucination,
                        toxicity. Hợp dùng trong CI.
Promptfoo              Node/CLI. Side-by-side test prompt,
                        model, provider. Tốt cho dev prompt.
Ragas                  RAG-specific (faithfulness, answer
                        relevancy, context precision/recall).
                        Bài 58 dùng.
OpenAI Evals           Framework open source của OpenAI,
                        YAML config + Python.
Inspect AI             UK AI Safety Institute. Mạnh ở
                        capability + safety eval.
LangSmith / Langfuse   Observability + eval cho ứng dụng
                        LangChain / agent.

Lựa chọn nhanh: benchmark academic → lm-evaluation-harness; eval RAG → Ragas + DeepEval; iterate prompt → Promptfoo; production observability → Langfuse / LangSmith.

pip install evaluate sacrebleu openai

import evaluate
from openai import OpenAI

# 1. Test set nhỏ: prompt + reference đáp án
testset = [
    {
        "prompt": "Thủ đô của Việt Nam là gì?",
        "reference": "Hà Nội",
    },
    {
        "prompt": "Dịch sang tiếng Anh: 'Tôi yêu lập trình.'",
        "reference": "I love programming.",
    },
    {
        "prompt": "Tóm tắt: Python là ngôn ngữ thông dịch, đa năng.",
        "reference": "Python là ngôn ngữ lập trình thông dịch đa năng.",
    },
]

client = OpenAI()

def generate(prompt: str) -> str:
    r = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.0,
    )
    return r.choices[0].message.content.strip()

# 2. Sinh output
preds = [generate(t["prompt"]) for t in testset]
refs  = [t["reference"] for t in testset]

# 3a. Exact match (task-specific)
em = sum(1 for p, r in zip(preds, refs) if p.lower() == r.lower()) / len(testset)
print(f"Exact match: {em:.2%}")

# 3b. BLEU (reference-based, Bài 55)
bleu = evaluate.load("sacrebleu")
print("BLEU:", bleu.compute(predictions=preds, references=[[r] for r in refs]))

# 3c. LLM-as-Judge (Bài 56) — preview rubric đơn giản
def judge(prompt, pred, ref):
    rubric = (
        "Đánh giá câu trả lời theo thang 1-5 dựa trên độ chính xác và rõ ràng. "
        f"Câu hỏi: {prompt}\nReference: {ref}\nCâu trả lời: {pred}\n"
        "Chỉ trả về 1 số 1-5."
    )
    r = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": rubric}],
        temperature=0.0,
    )
    return int(r.choices[0].message.content.strip())

scores = [judge(t["prompt"], p, t["reference"]) for t, p in zip(testset, preds)]
print(f"LLM-judge avg: {sum(scores)/len(scores):.2f} / 5")

Đoạn code trên là khung tối thiểu. Bài 55-58 sẽ thay từng phần bằng metric chuyên biệt (BERTScore, RAGAS, SelfCheckGPT) và làm việc với test set lớn hơn.

Bài 54 (bài này)  Vì sao đánh giá LLM khó. Tổng quan
                  6 thử thách, 4 nhóm metric, framework.

Bài 55            Reference-based metrics: BLEU, ROUGE,
                  METEOR, BERTScore, BLEURT — công thức,
                  ưu nhược, ví dụ.

Bài 56            LLM-as-Judge: dùng GPT-4 / Claude làm
                  judge, rubric, pairwise vs pointwise,
                  bias judge và cách giảm.

Bài 57            Hallucination: phát hiện và đo
                  (SelfCheckGPT, FActScore), faithfulness.

Bài 58            RAG evaluation: Faithfulness, Answer
                  Relevancy, Context Precision/Recall
                  với Ragas.

Bài 59            Benchmark overview: MMLU, HellaSwag,
                  HumanEval, GSM8K, MT-Bench, Chatbot Arena.

Cuối module, bạn sẽ có khung đầy đủ để xây evaluation pipeline cho dự án LLM bất kỳ: chọn metric, dựng test set, chạy nightly, đọc kết quả, ra quyết định.

• Build evaluation TRƯỚC khi fine-tune hoặc tối ưu prompt. Không có baseline đo lường, mọi cải tiến đều cảm tính.
• Track score qua từng iteration — commit prompt / model / config kèm điểm eval. Lịch sử này quý giá khi debug regression.
• Mix các loại metric: automatic guardrail + LLM-judge nightly + human calibration định kỳ.
• Coi test set là live artifact: bổ sung case khi production lỗi, gỡ case lỗi thời, không để test set chết.
• Re-evaluate khi production data thay đổi (mùa, đối tượng user mới, domain mới) — test set cũ có thể không còn đại diện.
• Đừng optimize 1 con số: nhớ Goodhart's Law. Luôn nhìn radar/multi-metric.
• Cẩn thận với benchmark public: contamination + Goodhart. Kết quả nội bộ trên test set riêng (có canary) đáng tin hơn.

1. Liệt kê 5 task LLM mà bạn nghĩ là khó đánh giá nhất. Với mỗi task: ghi rõ vì sao khó (open-ended? subjective? hallucination?) và đề xuất 1 metric khả thi.
2. Chọn 1 task LLM bạn đang làm (chatbot, summarization, classification, RAG...). Tự xây test set 20 case đại diện: 10 case "happy path", 5 case edge case, 5 case adversarial / khó.
3. Với test set ở câu 2, định nghĩa "gold standard": câu trả lời lý tưởng và tiêu chí chấm (rubric 3-5 chiều, mỗi chiều 1-5 điểm).
4. So sánh 2 model (ví dụ gpt-4o-mini vs claude-haiku) trên test set 20 case dùng code preview ở bước 21. Ghi nhận chênh lệch theo từng chiều, không chỉ điểm trung bình.
5. Đọc Chatbot Arena leaderboard, chọn 2 model có điểm Elo cách nhau < 20. Thử 5 prompt thực tế của bạn trên cả hai và đánh giá: bạn có đồng ý với thứ hạng leaderboard không? Vì sao?
6. (Mở rộng) Cài lm-evaluation-harness và chạy MMLU mini (1 subset) trên 1 SLM (Llama-3.2-1B / Phi-3-mini). So sánh với điểm public report.