Đánh giá RAG: đo retrieval trước, rồi mới đến generation

7.1Pipeline RAG hai tầng và chỗ đặt eval

RAG (Retrieval-Augmented Generation) = trước khi trả lời, hệ thống đi tìm đoạn văn liên quan trong kho tri thức (tài liệu, bảng, web) rồi nhét chúng vào prompt để LLM trả lời dựa trên bằng chứng. Điểm khác search truyền thống: "người đọc" kết quả không phải con người lướt 3 link đầu, mà là LLM — đọc được nhiều đoạn cùng lúc. Vì vậy mục tiêu retrieval dịch về phía recall: thà lấy dư còn hơn bỏ sót đoạn chứa đáp án.

Nhưng nhồi thật nhiều cũng có giá: context window có hạn, text nhiễu làm LLM trả lời kém đi, và API tính tiền theo token. Lời giải phổ biến là lấy rộng rồi lọc kỹ — pipeline hai tầng:

Bức tranh retrieval hiện đại (vài năm gần đây)

# rrf.py — Reciprocal Rank Fusion tối giản (tự viết, chạy được)
from collections import defaultdict

def rrf(rankings, c=60, top_n=5):
    """rankings: list các danh sách doc_id đã xếp hạng (mỗi retriever một list)."""
    score = defaultdict(float)
    for ranking in rankings:
        for rank, doc in enumerate(ranking, start=1):
            score[doc] += 1 / (c + rank)
    return sorted(score, key=score.get, reverse=True)[:top_n], dict(score)

bm25  = ["D7", "D2", "D9", "D4", "D1"]   # khớp đúng mã lỗi "ERR-4031"
dense = ["D4", "D3", "D7", "D8", "D2"]   # khớp ý "không đăng nhập được VPN"
fused, s = rrf([bm25, dense])
print(fused)
for d in fused: print(d, round(s[d], 5))

7.2Xây dataset đánh giá retrieval

Muốn đo retriever, cần danh sách query, mỗi query gắn với chunk chứa đáp án ("chunk vàng", gold chunk). Tự tay viết câu hỏi thực tế rồi map tới đúng chunk là chuẩn nhất nhưng đắt. Sách đề xuất mở rộng bằng LLM theo ba bước: sinh → làm khó → lọc.

Bước ②: sinh cặp QA tổng hợp

Cắt tài liệu thành chunk — đúng đơn vị mà retriever index (đổi cách chunk thì phải sinh lại hoặc ánh xạ lại nhãn!). Với mỗi chunk, nhờ LLM rút một sự thật cụ thể, tự đứng được, rồi viết câu hỏi mà chỉ sự thật đó trả lời. Kết quả là bộ ba (câu hỏi, đáp án, context).

Bước ③: câu hỏi khó với chunk "mồi nhử"

Câu hỏi sinh từ một chunk hay mượn nguyên văn chunk → retriever khớp keyword là trúng, quá dễ so với query thật (diễn đạt khác, chạm tới chủ đề có ở nhiều tài liệu, hỏi so sánh). Để stress-test: chọn chunk đích A → tìm chunk B, C giống A (bằng embedding/keyword) nhưng không chứa đáp án → nhờ LLM viết câu hỏi chỉ A trả lời được nhưng mượn thuật ngữ của B, C.

# synth.py — sinh câu hỏi khó có mồi nhử (tự viết; call_llm là hàm bạn cắm vào)
import json, random

GEN_PROMPT = """Đây là một đoạn tài liệu nội bộ (chunk ĐÍCH):
<<<{target}>>>
Và các đoạn DỄ NHẦM (không chứa đáp án):
<<<{distractors}>>>
Viết MỘT câu hỏi mà nhân viên có thể hỏi thật, CHỈ chunk ĐÍCH trả lời được,
nhưng dùng lại vài từ khoá của các đoạn DỄ NHẦM. Không chép nguyên câu của chunk ĐÍCH.
Trả JSON: {{"question": "...", "answer": "..."}}"""

def tokens(t): return set(t.lower().replace(",", " ").replace(".", " ").split())

def similar_chunks(target_id, chunks, n=2):
    """Thay cho embedding search: xếp chunk khác theo Jaccard từ vựng với chunk đích."""
    t = tokens(chunks[target_id])
    others = [(len(t & tokens(c)) / len(t | tokens(c)), cid)
              for cid, c in chunks.items() if cid != target_id]
    return [cid for _, cid in sorted(others, reverse=True)[:n]]

def build_hard_set(chunks, call_llm, n=10, seed=0):
    rng, rows = random.Random(seed), []
    for target_id in rng.sample(sorted(chunks), min(n, len(chunks))):
        d_ids = similar_chunks(target_id, chunks)
        out = json.loads(call_llm(GEN_PROMPT.format(
            target=chunks[target_id], distractors="\n---\n".join(chunks[d] for d in d_ids))))
        rows.append({"question": out["question"], "answer": out["answer"],
                     "gold": [target_id], "distractors": d_ids, "kind": "hard"})
    return rows

if __name__ == "__main__":
    chunks = {
        "hr-12#3": "Nhân viên chính thức được làm remote tối đa 2 ngày mỗi tuần, đăng ký trên HRM trước 17h ngày làm việc liền trước.",
        "hr-12#4": "Nhân viên thử việc không được đăng ký làm remote, trừ khi giám đốc khối phê duyệt bằng email.",
        "it-03#1": "Khi làm remote, bắt buộc bật VPN công ty trước khi truy cập Jira và Git nội bộ.",
        "hr-07#2": "Ngày phép năm của nhân viên chính thức là 15 ngày, đăng ký trên HRM trước 3 ngày làm việc.",
    }
    fake = lambda p: json.dumps({"question": "Muốn làm ở nhà thứ Sáu thì hạn chót đăng ký là khi nào?",
                                  "answer": "17h thứ Năm, trên HRM"})
    for r in build_hard_set(chunks, fake, n=1, seed=3): print(r)
    print(similar_chunks("hr-12#3", chunks))

Ở production, thay similar_chunks bằng truy vấn embedding thật; giữ lại cột distractors để phân tích lỗi.

Bước ④: lọc câu hỏi phi thực tế

Câu hỏi tổng hợp đôi khi kỳ quặc hoặc lạc domain. Cách lọc giống cách lọc tuple ở Chương 3: tự chấm một tập nhỏ về độ thực tế & đúng domain → dùng làm few-shot cho một LLM chấm phần còn lại → giữ câu đạt ngưỡng. Thang 1–5 ở đây ổn vì mục tiêu chỉ là xếp hạng rồi loại dữ liệu yếu, không phải đo tỉ lệ lỗi của hệ thống (việc đó vẫn nên dùng nhãn nhị phân như Chương 4).

7.3Precision@k và Recall@k

Hai metric cơ bản nhất, cùng nhìn vào top-k kết quả. Chúng khác nhau ở mẫu số:

Cả hai coi relevance là nhị phân. Nếu dataset chấm mức độ (0–3), phải chọn ngưỡng để nhị phân hoá (vd. "> 1 mới tính là liên quan") và ghi rõ ngưỡng trong báo cáo — đổi ngưỡng là đổi con số. k nên theo loại câu hỏi: tra một sự thật cần k = 1–2; câu hỏi tổng hợp ("tóm tắt các thay đổi chính sách năm nay") cần k = 5–10.

Ví dụ xuyên suốt 7.3–7.5 (bịa): query "Chính sách hoàn tiền của gói Pro?", hệ thống trả top-5 như dưới. Relevance chấm 0–3; query có tổng 4 tài liệu liên quan trong corpus (1 cái bị đẩy xuống hạng 8, ngoài top-5).

# metrics.py — Precision/Recall/RR/NDCG tự viết, không cần thư viện
import math

def precision_at_k(rels, k, thr=1):
    top = rels[:k]
    return sum(r >= thr for r in top) / k

def recall_at_k(rels, k, n_relevant_total, thr=1):
    if n_relevant_total == 0:
        return None  # query không có tài liệu liên quan: bỏ khỏi trung bình
    return sum(r >= thr for r in rels[:k]) / n_relevant_total

def reciprocal_rank(rels, k, thr=1):
    for i, r in enumerate(rels[:k], start=1):
        if r >= thr:
            return 1 / i
    return 0.0

def dcg(rels):
    return sum(r / math.log2(i + 1) for i, r in enumerate(rels, start=1))

def ndcg_at_k(rels, k, all_grades=None):
    """all_grades=None  -> IDCG = sắp lại chính top-k đã retrieve (cách của sách)
       all_grades=[...] -> IDCG = sắp lại MỌI tài liệu có nhãn của query (cách IR cổ điển)"""
    pool = rels[:k] if all_grades is None else all_grades
    ideal = dcg(sorted(pool, reverse=True)[:k])
    return dcg(rels[:k]) / ideal if ideal > 0 else 0.0

if __name__ == "__main__":
    rels = [0, 2, 0, 3, 1]          # top-5 của ví dụ 7.3 (dữ liệu bịa)
    print("P@5  ", precision_at_k(rels, 5))
    print("R@5  ", recall_at_k(rels, 5, n_relevant_total=4))
    print("RR   ", reciprocal_rank(rels, 5))
    print("DCG  ", round(dcg(rels), 4), "IDCG", round(dcg([3, 2, 1, 0, 0]), 4))
    print("NDCG@5 (sách)   ", round(ndcg_at_k(rels, 5), 4))
    print("NDCG@5 (toàn bộ)", round(ndcg_at_k(rels, 5, all_grades=[0, 2, 0, 3, 1, 2]), 4))
    print("P@5 thr=2", precision_at_k(rels, 5, thr=2), "R@5 thr=2", recall_at_k(rels,5,3,thr=2))
    X = [1, 1, 1, 0, 0]; Y = [0, 0, 0, 3, 0]
    print("trap X", ndcg_at_k(X, 5), "Y", round(ndcg_at_k(Y, 5), 4))
    print("trap X full", round(ndcg_at_k(X,5,all_grades=[1,1,1,3]),4), "Y full", round(ndcg_at_k(Y,5,all_grades=[3,1,1,1]),4))

$ python3 metrics.py
P@5   0.6
R@5   0.75
RR    0.5
DCG   2.9407 IDCG 4.7619
NDCG@5 (sách)    0.6176
NDCG@5 (toàn bộ) 0.5166
P@5 thr=2 0.4 R@5 thr=2 0.6666666666666666
trap X 1.0 Y 0.4307
trap X full 0.4671 Y full 0.2832

7.4MRR, hit rate và hiệu ứng "lost in the middle"

Reciprocal rank (RR) của một query = 1 / (vị trí tài liệu liên quan đầu tiên); không có trong top-k thì RR = 0. MRR@k = trung bình RR trên mọi query. Metric này chỉ quan tâm: "thứ có ích đầu tiên xuất hiện sớm cỡ nào?" — hợp với câu hỏi chỉ cần một sự thật.

Hit rate@k đơn giản hơn nữa: tỉ lệ query có ít nhất một tài liệu liên quan trong top-k. Sách coi đây thường là metric khởi đầu thực dụng nhất, vì với nhiều ứng dụng một tài liệu đúng là đủ để trả lời.

Vì sao vị trí vẫn quan trọng: "lost in the middle"

Có người lập luận: "LLM đọc hết top-10, đứng #1 hay #7 thì khác gì?" Sách dẫn nghiên cứu của Liu et al. (2024): giấu đáp án giữa 20 tài liệu và đo độ chính xác theo vị trí — kết quả là đường cong chữ U, cao nhất khi đáp án ở đầu hoặc cuối, tụt hơn 30 điểm % khi ở giữa. LLM không chú ý đều toàn bộ context. Vậy retrieve được chưa đủ; vị trí cũng quan trọng — đó là lý do MRR vẫn có ích ngay cả khi có nhiều chunk liên quan.

7.5NDCG@k — khi tài liệu có ích "nhiều ít" khác nhau

Precision, Recall, MRR đều coi relevance là nhị phân. Thực tế, với "Tóm tắt xu hướng lương ngành data năm nay", một báo cáo khảo sát lương mới là rất liên quan (3), một bài tổng quan thị trường lao động là hơi liên quan (1), một thông báo nghỉ lễ là không liên quan (0). NDCG@k dành cho relevance có mức độ (graded relevance) và dựa trên hai trực giác:

1. Càng liên quan càng đóng góp nhiều — tài liệu rel 3 có giá trị gấp ba tài liệu rel 1.
2. Càng ở trên càng giá trị — đóng góp ở vị trí i bị chia cho log₂(i+1): vị trí 1 giữ nguyên, vị trí 2 còn ~63%, vị trí 10 chỉ ~29%.

DCG@k = Σ_i=1..k rel_i / log₂(i+1). Con số này khó đọc (phụ thuộc số tài liệu liên quan), nên chuẩn hoá: IDCG@k = DCG của thứ tự lý tưởng, và NDCG@k = DCG@k / IDCG@k ∈ [0, 1]. NDCG = 1 nghĩa là xếp hoàn hảo; 0.5 nghĩa là mới thu được khoảng nửa giá trị có thể đạt nếu xếp tốt hơn. Nhờ chuẩn hoá, so sánh được giữa các query.

7.6Chọn metric nào? — kèm phòng lab tính tay

Mặc định an toàn theo sách: Recall@k cho stage 1, NDCG@k cho stage rerank; hit rate@k là điểm khởi đầu thực dụng; MRR khi chỉ cần một sự thật. Sơ đồ quyết định dưới đây là cách tự tổng hợp:

7.7Chunking — một biến số cần tune

Trước khi retriever tìm được gì, tài liệu phải được cắt thành chunk — đơn vị mà retriever trả về. Chunk quá nhỏ: một ý bị cắt đôi, retriever chỉ thấy một nửa. Chunk quá lớn: phần có ích bị pha loãng bởi text thừa, embedding "nhoè" giữa nhiều chủ đề, và tốn token trong context. Cách đơn giản nhất: fixed-size + overlap — cắt theo số token cố định, các chunk liền kề chia sẻ một phần token để nội dung gần ranh giới xuất hiện trọn vẹn trong ít nhất một chunk.

Tune bằng grid search

Không có cấu hình tốt nhất cho mọi corpus. Cách thực dụng mà sách đề xuất: chọn vài giá trị kích thước × overlap, index lại corpus cho từng tổ hợp, đo Recall@k / NDCG@k trên cùng tập query, chọn cấu hình tốt nhất. Trong ví dụ giả định của sách, overlap giúp ở mọi kích thước và chunk rất lớn thua chunk trung bình — nhưng con số cụ thể tuỳ tài liệu và kiểu câu hỏi của bạn.

1. Chọn lưới: vd. size ∈ {128, 256, 512} × overlap ∈ {0, 25%, 50%}.
2. Index lại corpus cho từng cấu hình — và ánh xạ lại nhãn vàng: chunk vàng được định nghĩa theo đoạn văn bản (offset ký tự), rồi quy đổi sang chunk-id của mỗi cấu hình.
3. Đo Recall@k, NDCG@k — tách theo lát cắt (easy/hard/real).
4. Chọn cấu hình tốt nhất, cân nhắc thêm chi phí index và số token vào prompt.

# chunking.py — chia chunk + "tỉ lệ đáp án bị cắt đôi" như một chẩn đoán rẻ trước khi chạy retriever
import itertools, math

def chunk_spans(n_tokens, size, overlap):
    """Trả về list (start, end) theo token, end không tính. overlap < size."""
    stride = size - overlap
    spans, start = [], 0
    while True:
        spans.append((start, min(start + size, n_tokens)))
        if start + size >= n_tokens:
            return spans
        start += stride

def contains_span(spans, a, b):
    """Chunk đầu tiên chứa trọn đoạn đáp án [a, b), hoặc None nếu bị cắt đôi ở mọi chunk."""
    return next((i for i, (s, e) in enumerate(spans) if s <= a and b <= e), None)

# gold set bịa: (độ dài tài liệu, vị trí bắt đầu đáp án, độ dài đáp án) — đơn vị token
gold = [(1000, 240, 40), (1000, 500, 60), (800, 120, 30), (1200, 760, 90),
        (600, 250, 20), (900, 380, 70), (1500, 1010, 50), (700, 60, 25)]

if __name__ == "__main__":
    total = sum(n for n, _, _ in gold)
    print("size overlap chunks  cost×  split-rate")
    for size, frac in itertools.product([128, 256, 512], [0, 0.25, 0.5]):
        ov = int(size * frac)
        n_chunks = indexed = split = 0
        for n, a, L in gold:
            spans = chunk_spans(n, size, ov)
            n_chunks += len(spans)
            indexed += sum(e - s for s, e in spans)       # token phải embed + lưu
            split += contains_span(spans, a, a + L) is None
        print(f"{size:4d} {ov:6d} {n_chunks:6d} {indexed/total:6.2f} {split/len(gold):9.0%}")

$ python3 chunking.py      # gold set bịa, đáp án cố tình đặt gần ranh giới
size overlap chunks  cost×  split-rate
 128      0     64   1.00       88%
 128     32     82   1.31       25%
 128     64    116   1.90       25%
 256      0     33   1.00       62%
 256     64     40   1.27       25%
 256    128     56   1.80        0%
 512      0     18   1.00       25%
 512    128     22   1.23        0%
 512    256     25   1.57        0%

7.8Đánh giá generation: faithfulness & relevance

Retrieval hoàn hảo chưa đảm bảo câu trả lời tốt: bước generation vẫn có thể hỏng. Sách đo generation theo hai chiều, và xây evaluator bằng các kỹ thuật của Chương 5.

Viết judge faithfulness (theo tinh thần Chương 5)

Judge nhận context + câu trả lời, kiểm từng claim. Code dưới đây tự viết: tách câu thành claim, gọi judge cho từng claim, trả điểm liên tục (để debug) và nhãn PASS/FAIL nhị phân (để báo cáo tỉ lệ lỗi). Relevance kiểm bằng code rẻ khi query có thực thể rõ ràng.

# faith.py — faithfulness theo claim + relevance check bằng code (tự viết)
import json, re

JUDGE_PROMPT = """Bạn kiểm tra tính trung thành (faithfulness) của một câu trả lời RAG.
CONTEXT:
{context}

CLAIM: {claim}

Claim này có được CONTEXT ủng hộ trực tiếp không? Chỉ dựa vào CONTEXT,
không dùng hiểu biết riêng. Trả JSON: {{"verdict": "supported" | "unsupported"
| "contradicted", "evidence": "<trích ngắn từ context hoặc rỗng>"}}"""

def split_claims(answer):
    # đơn giản: mỗi câu là một claim; production nên nhờ LLM tách claim nguyên tử
    return [s.strip() for s in re.split(r"(?<=[.!?])\s+", answer) if s.strip()]

def faithfulness(answer, context, call_llm):
    verdicts = []
    for claim in split_claims(answer):
        out = json.loads(call_llm(JUDGE_PROMPT.format(context=context, claim=claim)))
        verdicts.append((claim, out["verdict"]))
    ok = sum(v == "supported" for _, v in verdicts)
    return ok / len(verdicts), verdicts   # điểm liên tục để debug; PASS/FAIL = mọi claim supported

def mentions_entity(answer, required_terms):
    """Relevance check rẻ bằng code: câu trả lời có nhắc thực thể mà query hỏi không?"""
    a = answer.lower()
    return all(t.lower() in a for t in required_terms)

if __name__ == "__main__":
    ctx = "Nhân viên chính thức có 15 ngày phép năm. Phép chưa dùng được chuyển sang quý 1 năm sau."
    ans = ("Bạn có 15 ngày phép năm. Phép chưa dùng được chuyển sang quý 1 năm sau. "
           "Nếu nghỉ việc, phép còn lại được trả bằng tiền.")
    def fake_llm(prompt):  # judge giả lập để chạy offline: claim có số/cụm khớp context?
        claim = prompt.split("CLAIM: ")[1].split("\n")[0]
        key = claim.split()[-4:]
        hit = " ".join(key).rstrip(".") in ctx
        return json.dumps({"verdict": "supported" if hit else "unsupported", "evidence": ""})
    score, v = faithfulness(ans, ctx, fake_llm)
    for c, x in v: print(f"[{x:11}] {c}")
    print("faithfulness =", round(score, 2), "| PASS" if score == 1 else "| FAIL")
    print("relevance(mentions 'phép'):", mentions_entity(ans, ["phép"]))

$ python3 faith.py
[supported  ] Bạn có 15 ngày phép năm.
[supported  ] Phép chưa dùng được chuyển sang quý 1 năm sau.
[unsupported] Nếu nghỉ việc, phép còn lại được trả bằng tiền.
faithfulness = 0.67 | FAIL
relevance(mentions 'phép'): True

Context swapping — công cụ debug grounding

Nếu câu trả lời gần như không đổi khi context bị tráo → LLM đang dựa vào parametric knowledge. Nguy hiểm tinh vi: câu trả lời có thể tình cờ đúng, nhưng khi model không biết, nó sẽ bịa thay vì dùng bằng chứng. Theo sách, cách sửa thường nằm ở prompt (chỉ dựa vào tài liệu được cung cấp; không có thì nói không có), không phải retriever.

7.9Chẩn đoán: lỗi retrieval hay lỗi generation?

Chẩn đoán có giá trị nhất của chương: với mỗi trace, hỏi hai câu độc lập — retrieval có đưa chunk vàng vào context không? và câu trả lời cuối có đúng không? Đếm trace vào 4 ô cho biết nên đầu tư vào đâu.

# triage.py — xếp trace vào ma trận 2×2 (tự viết)
from collections import Counter

def quadrant(row, k=5):
    retrieved_ok = any(g in row["retrieved"][:k] for g in row["gold"])
    answer_ok = row["answer_pass"]            # nhãn người hoặc judge đã hiệu chỉnh
    return {(True, True): "OK", (True, False): "GEN_FAIL",
            (False, True): "LUCKY", (False, False): "RET_FAIL"}[(retrieved_ok, answer_ok)]

def triage(rows, k=5):
    c = Counter(quadrant(r, k) for r in rows)
    n = len(rows)
    for q in ["OK", "GEN_FAIL", "LUCKY", "RET_FAIL"]:
        print(f"{q:9} {c[q]:4d}  {c[q]/n:6.1%}")
    # ưu tiên: khâu nào gây nhiều câu trả lời SAI hơn?
    if c["RET_FAIL"] == c["GEN_FAIL"]:
        return "ngang nhau — đọc trace để quyết"
    return "retrieval" if c["RET_FAIL"] > c["GEN_FAIL"] else "generation"

rows = [
    {"gold": ["hr-07#2"], "retrieved": ["hr-07#2", "hr-07#5"], "answer_pass": False},
    {"gold": ["adm-04#1"], "retrieved": ["it-09#3", "hr-02#1"], "answer_pass": False},
    {"gold": ["it-03#1"], "retrieved": ["hr-12#3", "hr-12#4"], "answer_pass": True},
    {"gold": ["fin-02#3"], "retrieved": ["fin-02#3", "fin-02#1"], "answer_pass": True},
]
print("Ưu tiên sửa:", triage(rows))

7.10Case study end-to-end: bot hỏi đáp tài liệu nội bộ

7.11Cạm bẫy thường gặp

• Chỉ nhìn metric end-to-end. Một con số "đúng/sai" không cho biết lỗi ở retrieval hay generation — đo từng tầng: Recall@k cho retrieval, faithfulness cho generation. Triệu chứng: team sửa prompt ba vòng mà tỉ lệ đúng không nhúc nhích (vì chunk vàng không bao giờ vào context).
• Overfit dữ liệu tổng hợp. Câu hỏi mượn nguyên văn chunk → retrieval dễ giả tạo; chunk "vàng" có thể không duy nhất hoặc không tối ưu; thiếu câu multi-hop / cần phán đoán. Recall đẹp mà user vẫn kêu → bổ sung 20–30 query thật từ log trước khi kết luận. Triệu chứng: lát cắt easy 0.93, lát cắt real 0.63 (case study).
• Chọn sai metric. Cần một sự thật → MRR/hit rate; cần tổng hợp nhiều chunk → Recall@k/NDCG@k. Tối ưu sai metric = tối ưu hành vi không cải thiện câu trả lời. Triệu chứng: MRR tăng nhưng câu hỏi so sánh vẫn sai.
• Bỏ qua chunking như một biến số. Cùng một retriever, Recall@k có thể đổi đáng kể chỉ vì cách cắt chunk. Triệu chứng: đổi embedding model đắt tiền mà không đỡ, trong khi chunk bảng vẫn mất tiêu đề.
• Chấm generation mà không kiểm grounding. Trôi chảy và giống đáp án mẫu không có nghĩa là bám bằng chứng. Một câu trả lời nghe đúng nhưng mâu thuẫn context phá vỡ lý do tồn tại của RAG.
• Không tách "retrieve đúng" với "trả lời đúng". Bỏ lỡ tín hiệu quan trọng nhất về nút thắt — ma trận 2×2 cho biết đầu tư vào đâu.
• (Tự bổ sung) Đo sai k. Đo Recall@10 trong khi prompt chỉ nhận top-3 → metric đẹp hơn trải nghiệm thật.
• (Tự bổ sung) Quên tầng tạo query. Trong hội thoại nhiều lượt (Chương 6), câu "còn thử việc thì sao?" phải được viết lại thành query đầy đủ. Hãy log cả query đã viết lại để đánh giá khâu này riêng.

7.12Quy trình tổng hợp & checklist

1. Dataset: query + chunk vàng (thủ công, tổng hợp, câu hỏi khó, đã lọc) — lưu nhãn theo offset, ghi cột lát cắt.
2. Đo retrieval: hit rate/Recall@k cho độ phủ; MRR/NDCG@k cho thứ hạng — tại đúng k mà khâu sau tiêu thụ.
3. Đo generation riêng: faithfulness (judge theo claim, đã hiệu chỉnh) + relevance.
4. Chẩn đoán: xếp trace vào ma trận 2×2; context swap cho các ca nghi ngờ.
5. Tune chunking: kích thước, overlap, ranh giới cấu trúc, tiền tố ngữ cảnh — đo tác động lên metric retrieval, xác nhận trên held-out.

7.13Áp dụng cho dự án model-routing

Hệ thống của bạn gửi mỗi request LLM tới model phù hợp, cân bằng chất lượng / chi phí / độ trễ. Nhìn kỹ, router là một retriever: "corpus" là danh sách model, "query" là request, "tài liệu liên quan" là các model trả lời đạt chuẩn. Toàn bộ bộ công cụ của chương dùng lại được gần như nguyên vẹn.

# router_eval.py — đánh giá router bằng metric xếp hạng (tự viết, dữ liệu bịa)
import math

COST = {"nano": 0.1, "mini": 0.4, "mid": 1.5, "large": 5.0, "xl": 15.0}  # $/1M token (bịa)

# Nhãn offline: model nào PASS mỗi request (chấm bằng judge đã hiệu chỉnh, Ch.5)
PASS = {
    "r1 tóm tắt email":        {"nano", "mini", "mid", "large", "xl"},
    "r2 SQL 3 bảng join":      {"mid", "large", "xl"},
    "r3 RAG 80k token context": {"large", "xl"},
    "r4 phân loại ý định":     {"mini", "mid", "large", "xl"},
}
ROUTER = {  # thứ hạng router đưa ra (ứng viên #1 được gọi trước, lỗi thì fallback)
    "r1 tóm tắt email":        ["mini", "nano", "mid", "large", "xl"],
    "r2 SQL 3 bảng join":      ["mini", "mid", "large", "xl", "nano"],
    "r3 RAG 80k token context": ["xl", "large", "mid", "mini", "nano"],
    "r4 phân loại ý định":     ["mini", "mid", "nano", "large", "xl"],
}

def grade(model, passing):
    """3 = model PASS rẻ nhất, 2 = PASS nhưng đắt hơn, 0 = FAIL."""
    if model not in passing: return 0
    return 3 if COST[model] == min(COST[m] for m in passing) else 2

def dcg(g): return sum(x / math.log2(i + 2) for i, x in enumerate(g))

rows = []
for req, ranking in ROUTER.items():
    g = [grade(m, PASS[req]) for m in ranking]
    ideal = sorted((grade(m, PASS[req]) for m in COST), reverse=True)
    first_ok = next(i for i, m in enumerate(ranking, 1) if m in PASS[req])
    # cascade: gọi lần lượt theo thứ hạng tới khi PASS -> trả tiền cho cả các lần hỏng
    spent = sum(COST[m] for m in ranking[:first_ok])
    regret = spent - min(COST[m] for m in PASS[req])
    rows.append((1 / first_ok, ranking[0] in PASS[req], dcg(g[:3]) / dcg(ideal[:3]), regret))
    print(f"{req:26} grades={g} RR={1/first_ok:.2f} NDCG@3={rows[-1][2]:.2f} regret=${regret:+.1f}")

n = len(rows)
print(f"MRR={sum(r[0] for r in rows)/n:.3f}  Hit@1={sum(r[1] for r in rows)/n:.2f}  "
      f"NDCG@3={sum(r[2] for r in rows)/n:.3f}  mean cascade regret=${sum(r[3] for r in rows)/n:.2f}/1M tok")

$ python3 router_eval.py
r1 tóm tắt email           grades=[2, 3, 2, 2, 2] RR=1.00 NDCG@3=0.93 regret=$+0.3
r2 SQL 3 bảng join         grades=[0, 3, 2, 2, 0] RR=0.50 NDCG@3=0.55 regret=$+0.4
r3 RAG 80k token context   grades=[2, 3, 0, 0, 0] RR=1.00 NDCG@3=0.91 regret=$+10.0
r4 phân loại ý định        grades=[3, 2, 0, 2, 2] RR=1.00 NDCG@3=0.81 regret=$+0.0
MRR=0.875  Hit@1=0.75  NDCG@3=0.801  mean cascade regret=$2.67/1M tok

Routing cho request RAG theo độ dài context

Request RAG có đặc điểm riêng: độ dài prompt phụ thuộc k và kích thước chunk. Ba hệ quả cho eval:

• Bộ lọc cứng = stage 1: model có context window nhỏ hơn prompt phải bị loại. Đo "Recall" của bộ lọc: tỉ lệ request mà model PASS rẻ nhất vẫn còn sau lọc. Nếu bộ lọc dùng ước lượng token thô (ký tự/4) có thể loại oan hoặc để lọt model gây lỗi cắt context.
• Lost in the middle phụ thuộc model: model nhỏ thường chịu context dài kém hơn. Tạo lát cắt dataset theo độ dài (≤ 4k, 4–32k, > 32k token) và theo vị trí chunk vàng trong context, rồi đo pass-rate của từng model trên từng ô → router học được "request dài + chunk vàng ở giữa → cần model lớn".
• Router và retriever tương tác: đổi k từ 5 lên 10 làm prompt dài gấp đôi → có thể đẩy request sang model đắt hơn. Khi tune chunking/k (7.7), đo luôn chi phí routing kéo theo, không chỉ Recall@k.

Tự kiểm tra

Tóm tắt diễn giải bằng tiếng Việt cho mục đích học tập cá nhân, không phải bản dịch. Nguồn: Evals for AI Engineers — Shreya Shankar & Hamel Husain, O'Reilly (Early Release). Toàn bộ ví dụ, case study, bài tập, code và số liệu tính toán là nội dung tự soạn với dữ liệu bịa để minh hoạ.