Đánh giá cộng tác: làm cho con người đồng ý về "thế nào là lỗi"

4.1Vì sao phải căn chỉnh phán đoán con người

Chương 3 cho bạn danh sách failure mode bằng cách đọc trace và gán nhãn. Nhưng mỗi nhãn "Pass/Fail" là một phán đoán của con người — và phán đoán thì có ba "bệnh" cố hữu:

Sách dẫn hai bằng chứng: Notion vận hành eval với khoảng 70 kỹ sư và lập riêng một nhóm chỉ để viết rubric "thế nào là tốt" cho từng tính năng AI; và nghiên cứu của Shankar và cộng sự (2024) quan sát thấy dev thường xuyên sửa lại nhãn cũ khi xem thêm ví dụ. Bài học: rubric là tài liệu sống, phải tiến hoá cùng dữ liệu — và nếu nhãn không đáng tin thì mọi thứ xây trên nó đều thừa hưởng nhiễu.

4.2Một chuyên gia có đủ không? — "Benevolent dictator"

Trực giác: đồng thuận chỉ là vấn đề khi có nhiều người phán. Nếu một người đáng tin làm "nguồn sự thật" duy nhất, sẽ không có xung đột nhãn để giải quyết. Sách mượn thuật ngữ từ quản trị mã nguồn mở — nơi một maintainer có tiếng nói cuối cùng — và cho rằng ở công ty nhỏ-vừa, chỉ định một chuyên gia domain chính thường hiệu quả hơn là họp hội đồng.

Khi nào hết phù hợp: domain quá rộng để một người đánh giá toàn diện; tiêu chí bị các bên (legal, product, CSKH) tranh cãi; hoặc bạn cần chứng minh quy trình khách quan với bên ngoài (audit, khách hàng doanh nghiệp).

4.3Quy trình gán nhãn cộng tác 9 bước

Trực giác: quy trình này giống "kiểm thử rubric". Rubric là một đặc tả; mỗi người gán là một "bản cài đặt" độc lập của đặc tả đó. Nếu hai bản cài đặt cho kết quả khác nhau trên cùng input, lỗi nằm ở đặc tả. Vòng lặp 9 bước là cách tìm và vá các lỗ hổng đó cho tới khi đặc tả đủ chặt.

1. Lập team gán nhãnHai người trở lên có chuyên môn hoặc góc nhìn liên quan (team lớn: đại diện engineering, product, legal, CSKH). Nói rõ vai trò và phạm vi ngay từ đầu.
2. Viết rubric nhápMỗi tiêu chí một rubric: định nghĩa làm việc + vài ví dụ Pass/Fail. Thường là "chính thức hoá" các failure mode từ error analysis.
3. Chọn bộ trace chung20–50 trace đại diện, cố tình đưa vào ca mơ hồ. Ai cũng đồng ý ca dễ; ca khó mới là nơi thử rubric.
4. Gán nhãn độc lậpKhông trao đổi. Bàn bạc lúc này làm nhãn tương quan với nhau → mất khả năng phát hiện chỗ mơ hồ.
5. Đo IAA cho từng tiêu chíκ thấp ở tiêu chí nào → rubric đó mơ hồ. κ cao → tiêu chí đó sẵn sàng.
6. Alignment sessionMỗi buổi tập trung một tiêu chí. Mục tiêu: hiểu nguồn gốc bất đồng và sửa rubric (mục 4.9).
7. Sửa rubricLàm rõ định nghĩa, thay/thêm ví dụ, điều chỉnh tiêu chuẩn. Rubric phải chính xác hơn sau mỗi vòng.
8. LặpTrace mới → gán độc lập → đo κ → sửa, tới khi mỗi tiêu chí quan trọng đạt κ khoảng 0.6 trở lên.
9. Chốt rubric & nhãnTài liệu rubric cuối + bộ nhãn đồng thuận (gold standard): vừa chứng minh con người áp dụng được rubric, vừa là ground truth để chấm LLM judge.

Chọn bộ trace chung: đừng lấy ngẫu nhiên thuần tuý

Nếu 85% trace production là Pass dễ, lấy ngẫu nhiên 40 trace sẽ cho ~34 ca dễ — cả team đồng ý hết, κ trông ổn, và bạn chẳng học được gì. Hãy phân tầng: một phần ca dễ (để kiểm tra người gán không "khó tính vô cớ"), nhiều ca biên, và một ít lỗi đã biết từ error analysis.

Nguồn ca biên hay dùng: trace mà hai reviewer ở Chương 3 từng ghi chú khác nhau; trace có câu hỏi nhiều ý; trace mà một LLM phân loại thử cho độ tự tin thấp; trace gần ranh giới chính sách (vd. số tiền sát hạn mức). Đoạn code tự viết dưới đây chọn mẫu theo tỉ lệ và xoay vòng theo loại request để không dồn vào một chủ đề:

import random

def pick_shared_set(traces, n=40, mix=(0.35, 0.40, 0.25), seed=42):
    """Chọn bộ trace chung: dễ / ca biên / lỗi đã biết theo tỉ lệ mix.
    traces: list dict có 'id', 'bucket' ∈ {'easy','borderline','known_fail'},
            và 'category' (loại request) để trải đều."""
    rng = random.Random(seed)
    buckets = ("easy", "borderline", "known_fail")
    chosen = []
    for bucket, share in zip(buckets, mix):
        pool = [t for t in traces if t["bucket"] == bucket]
        k = min(len(pool), round(n * share))
        # xoay vòng theo category để không dồn vào một loại request
        by_cat = {}
        for t in rng.sample(pool, len(pool)):
            by_cat.setdefault(t["category"], []).append(t)
        while k and any(by_cat.values()):
            for cat in list(by_cat):
                if by_cat[cat] and k:
                    chosen.append(by_cat[cat].pop()); k -= 1
    rng.shuffle(chosen)              # trộn để người gán không đoán được nhóm
    return [t["id"] for t in chosen]

# Chạy thử trên 400 trace giả (70% dễ, 20% biên, 10% lỗi):
# easy 14 · borderline 16 · known_fail 10 · tổng 40

Gán nhiều tiêu chí một lượt — nhưng đo riêng từng tiêu chí

Đọc một trace tốn công; gán luôn 3–4 tiêu chí trong một lượt đọc là hợp lý. Nhưng khi đo và họp, tách từng tiêu chí: hai người có thể cùng nhận ra lỗi sự thật mà có trực giác hoàn toàn khác về "giọng quá trang trọng".

trace_id | link_trace | factual (P/F) | complete (P/F) | tone (P/F) | note (bắt buộc khi F hoặc phân vân)

4.4Đo đồng thuận: vì sao % đồng ý đánh lừa bạn

Percent agreement (P_o, observed agreement) = số item hai người gán cùng nhãn / tổng item. Dễ tính, dễ hiểu — nhưng không trừ phần trùng hợp ngẫu nhiên. Nếu 95% trace là Pass và cả hai người "bấm Pass cho nhanh" mà không đọc, họ vẫn đạt 95%.

Điều trớ trêu: hệ thống càng được sửa tốt, nhãn càng dồn về Pass, nên đồng ý ngẫu nhiên càng cao. Đầu dự án tỉ lệ Pass ~50% thì may rủi cho ~50%; khi Pass lên 90%, may rủi đã cho 0.9² + 0.1² = 82%.

4.5Cohen's Kappa — đồng ý vượt mức may rủi

Ví dụ tự dựng: 100 trace, tiêu chí "câu trả lời đủ ý"

(Sách có một ví dụ tính tay tương tự về tóm tắt email; ở đây dùng số liệu khác để bạn tự đối chiếu.)

1. P_o — đồng ý quan sátĐường chéo: (70 + 15) / 100 = 0.85.
2. P_e — đồng ý do may rủiA gán Pass 78%, B gán Pass 77%. P_e = 0.78 × 0.77 + 0.22 × 0.23 ≈ 0.601 + 0.051 = 0.651.
3. κ(0.85 − 0.651) / (1 − 0.651) = 0.199 / 0.349 ≈ 0.57 → chỉ "moderate", dù 85% nghe rất đẹp.

trace:  1  2  3  4  5  6  7  8  9  10
A:      P  P  F  P  P  F  P  P  P  F
B:      P  P  F  F  P  P  P  P  P  F

Code tự viết: Cohen's κ có xử lý ca biên

Hàm dưới đây nhận hai list nhãn bất kỳ (không chỉ P/F). Chú ý ca biên: nếu cả hai người chỉ dùng đúng một nhãn cho mọi item, P_e = 1 và κ không xác định — trả về NaN thay vì giả vờ là 1.0.

from collections import Counter

def cohen_kappa(a, b):
    """κ cho 2 người gán cùng một danh sách item (nhãn phân loại bất kỳ)."""
    n = len(a)
    assert n == len(b) and n > 0
    po = sum(x == y for x, y in zip(a, b)) / n
    ca, cb = Counter(a), Counter(b)
    pe = sum(ca[l] / n * cb[l] / n for l in set(a) | set(b))
    if pe == 1:                      # cả hai dùng đúng 1 nhãn duy nhất
        return float("nan")          # κ không xác định — đừng báo 1.0
    return (po - pe) / (1 - pe)

A = list("PPFPPFPPPF"); B = list("PPFFPPPPPF")
print(round(cohen_kappa(A, B), 3))   # 0.524

4.6Đọc điểm κ, đặt ngưỡng & đừng quên khoảng tin cậy

Sách khuyên nhắm κ ≥ 0.6 trước khi coi nhãn là đáng tin, nhưng ngưỡng thực tế tuỳ mục đích: ~0.5 là đủ để quyết định tách/gộp failure category; ≥ 0.6 để kiểm định LLM judge; ≥ 0.7 khi nhãn đi vào train model hoặc báo cáo tuân thủ. Với tiêu chí chủ quan, 0.6 rất khó; ~0.4 đã là tiến bộ thật.

Khoảng tin cậy: κ = 0.62 trên 40 trace thực ra là "khoảng 0.35 đến 0.85"

Phần này là bổ sung tự soạn (sách không đi sâu). Bộ trace chung thường chỉ 20–50 item, nên κ dao động rất mạnh. Cách đơn giản nhất để thấy độ bất định: bootstrap — lấy mẫu lại có hoàn lại các item, tính κ nhiều lần, lấy phân vị 2.5% và 97.5%.

import random
from collections import defaultdict

def bootstrap_ci(a, b, rounds=2000, seed=0):
    """Khoảng tin cậy 95% cho κ bằng cách lấy mẫu lại các item."""
    rng, pairs, ks = random.Random(seed), list(zip(a, b)), []
    for _ in range(rounds):
        s = [rng.choice(pairs) for _ in pairs]
        k = cohen_kappa([x for x, _ in s], [y for _, y in s])
        if k == k:                   # bỏ NaN
            ks.append(k)
    ks.sort()
    return ks[int(.025 * len(ks))], ks[int(.975 * len(ks))]

def per_criterion_report(rows):
    """rows: list of dict {trace, criterion, annotator, label} (2 người)."""
    by = defaultdict(dict)           # (criterion, trace) -> {annotator: label}
    for r in rows:
        by[(r["criterion"], r["trace"])][r["annotator"]] = r["label"]
    for c in sorted({c for c, _ in by}):
        pairs = [tuple(v.values()) for (cc, _), v in by.items() if cc == c and len(v) == 2]
        a, b = [x for x, _ in pairs], [y for _, y in pairs]
        lo, hi = bootstrap_ci(a, b)
        po = sum(x == y for x, y in pairs) / len(pairs)
        print(f"{c:<12} n={len(pairs):3d}  %agree={po:.0%}  "
              f"kappa={cohen_kappa(a, b):.2f}  CI95=[{lo:.2f}, {hi:.2f}]")

Chạy trên dữ liệu của ví dụ 4.3a (40 trace × 3 tiêu chí):

complete     n= 40  %agree=82%  kappa=0.62  CI95=[0.34, 0.85]
factual      n= 40  %agree=95%  kappa=0.87  CI95=[0.67, 1.00]
tone         n= 40  %agree=68%  kappa=0.32  CI95=[0.01, 0.60]

4.7Khi có > 2 người, thang thứ tự, hoặc thiếu nhãn

Cohen's κ giả định: đúng 2 người, nhãn phân loại, và cả hai gán mọi item. Lệch khỏi một trong ba giả định → đổi chỉ số.

Cặp X (lệch 1 bậc):   4 4 3 3 2 5 2 4
Cặp Y (lệch 3–4 bậc): 1 4 1 3 2 5 5 5

trace:  1  2  3  4  5  6  7  8
Lan:    P  P  F  F  P  –  F  P
Minh:   P  P  F  –  F  P  F  P
Tú:     P  –  P  F  P  P  F  P        (– = không gán)

Code tự viết cho hai chỉ số trên (nhãn phân loại), đã chạy ra đúng 0.50 và 0.615:

from collections import Counter, defaultdict
from itertools import permutations

def fleiss_kappa(table):
    """table: mỗi phần tử là list nhãn của 1 item (mọi item cùng số người gán)."""
    N, n = len(table), len(table[0])
    cats = sorted({l for row in table for l in row})
    # đồng ý trên từng item = tỉ lệ cặp người gán trùng nhãn
    P_i = [sum(c * (c - 1) for c in Counter(row).values()) / (n * (n - 1)) for row in table]
    P_bar = sum(P_i) / N
    p_j = {c: sum(row.count(c) for row in table) / (N * n) for c in cats}
    P_e = sum(p * p for p in p_j.values())
    return (P_bar - P_e) / (1 - P_e)

def krippendorff_alpha_nominal(units):
    """units: list các list nhãn, None = người đó không gán item này."""
    o = defaultdict(float)                     # ma trận coincidence
    for u in units:
        v = [x for x in u if x is not None]
        m = len(v)
        if m < 2:
            continue                           # item chỉ có 1 nhãn: bỏ qua
        for i, j in permutations(range(m), 2):
            o[(v[i], v[j])] += 1 / (m - 1)
    cats = sorted({c for c, _ in o})
    n_c = {c: sum(o[(c, k)] for k in cats) for c in cats}
    n = sum(n_c.values())
    D_o = sum(o[(c, k)] for c in cats for k in cats if c != k) / n
    D_e = sum(n_c[c] * n_c[k] for c in cats for k in cats if c != k) / (n * (n - 1))
    return 1 - D_o / D_e

t = [list("PPP"), list("PPP"), list("PPF"), list("PFF"), list("FFF"), list("PPP")]
u = [list("PPP"), ["P", "P", None], list("FFP"), ["F", None, "F"],
     list("PFP"), [None, "P", "P"], list("FFF"), list("PPP")]
print(round(fleiss_kappa(t), 3), round(krippendorff_alpha_nominal(u), 3))  # 0.5 0.615

Khi dùng thật, các thư viện như statsmodels (Fleiss) hay gói krippendorff trên PyPI tiện hơn; code trên để bạn hiểu cơ chế và kiểm chứng số liệu.

4.8Đừng dùng κ để chấm LLM judge

Trực giác: κ là một con số đối xứng — hoán đổi vai trò judge và gold, κ không đổi. Nhưng hậu quả của hai kiểu sai thì không đối xứng chút nào. Ví dụ dưới đây dựng hai judge có cùng κ mà tính cách trái ngược.

def judge_report(gold, pred, name):
    """gold/pred: list 'P'/'F'. Coi 'P' là lớp dương (positive)."""
    tp = sum(g == "P" and p == "P" for g, p in zip(gold, pred))
    fn = sum(g == "P" and p == "F" for g, p in zip(gold, pred))
    fp = sum(g == "F" and p == "P" for g, p in zip(gold, pred))
    tn = sum(g == "F" and p == "F" for g, p in zip(gold, pred))
    tpr, tnr = tp / (tp + fn), tn / (tn + fp)
    print(f"{name}: kappa={cohen_kappa(gold, pred):.2f}  TPR={tpr:.1%}  TNR={tnr:.1%}  "
          f"lọt lỗi={fp}  báo động giả={fn}")

gold    = ["P"] * 80 + ["F"] * 20
lenient = ["P"] * 78 + ["F"] * 2 + ["P"] * 10 + ["F"] * 10
strict  = ["P"] * 66 + ["F"] * 14 + ["P"] * 3 + ["F"] * 17
judge_report(gold, lenient, "Judge L (dễ dãi)")
judge_report(gold, strict,  "Judge S (khắt khe)")
# Judge L (dễ dãi): kappa=0.56  TPR=97.5%  TNR=50.0%  lọt lỗi=10  báo động giả=2
# Judge S (khắt khe): kappa=0.56  TPR=82.5%  TNR=85.0%  lọt lỗi=3  báo động giả=14

4.9Alignment session: sửa rubric, không phân xử nhãn

Trực giác: mỗi ca lệch là một bug report cho rubric. Buổi họp là buổi triage bug: tái hiện (mỗi người đã nghĩ gì), khoanh vùng (chữ nào trong rubric cho phép hiểu khác), và vá (thay đổi gì để lần sau không tái diễn). Không ai "thắng" một bug report.

Ca điển hình trong sách (trợ lý CRM bất động sản)

Tiêu chí: "câu trả lời hợp với persona khách". Rubric ban đầu chỉ nói đại ý: nhà đầu tư cần thông tin đầu tư, người mua lần đầu cần thông tin về quy trình mua; kèm một ví dụ Pass và một ví dụ Fail rõ ràng. Nghe hợp lý — nhưng không nói gì về câu trả lời pha trộn. Một trace: khách là nhà đầu tư hỏi về căn duplex; câu trả lời có cả tiền thuê hiện tại lẫn câu kiểu "hợp với gia đình, có sân sau". Ba người chấm ba kiểu:

Trong sách, tiêu chí "hợp persona" chỉ đạt κ khoảng 0.3–0.4 ở vòng đầu. Khi soi kỹ, người gán đồng ý về việc có thông tin hợp mục tiêu khách hay không, nhưng lệch về việc ngôn từ có đang nói với nhầm đối tượng không. Tách thành hai tiêu chí giúp thấy ngay phần nào cần sửa.

5 kỹ thuật sửa rubric

Lưu giữ mọi thứ: bộ gold và tài liệu dùng lại cho kiểm định evaluator tự động, fine-tune, audit khi bị chất vấn phương pháp, và để hiểu vì sao rubric trông như hiện tại khi cần sửa tiếp.

4.10Cạm bẫy thường gặp (và cách phát hiện sớm)

• Bỏ qua gán độc lập. Bàn trước rồi mới gán → κ cao nhưng đo "groupthink", không đo độ rõ của rubric. Người mới chỉ cầm rubric có thể hiểu khác hẳn. (Không áp dụng nếu chỉ có một người gán.)
• Rubric đầu tiên quá sơ sài. Vòng đầu κ thấp, người gán nản. Đầu tư định nghĩa + vài ví dụ trước khi bắt đầu; tách chữ "phù hợp" thành các khía cạnh cụ thể (từ vựng, giọng, mức chi tiết).
• Chỉ báo % đồng ý. Ăn mừng 90% trong khi may rủi đã cho 80%. Luôn tính κ (hoặc chỉ số phù hợp).
• Lờ drift theo thời gian. Sau vài trăm trace, vì bối cảnh kinh doanh mới, vì mệt, hay đơn giản vì đã thấy nhiều ví dụ, người gán dễ dãi hoặc khắt khe dần. Định kỳ gán lại bộ neo 10–15 trace từ đầu dự án. Drift tự nó không xấu — xấu là không biết nó tồn tại.
• "Thông đồng" qua LLM (synthetic-annotator collusion). Hai người cùng nhờ một LLM chấm hộ → κ rất cao, nhưng đó là LLM nhất quán với chính nó chứ không phải người đồng ý về tiêu chí.
• Tranh luận nhãn cũ. Câu hỏi đúng là "sửa rubric thế nào thì lần sau ta đã đồng ý?", không phải "trace này lẽ ra Pass hay Fail?".

Bảng "triệu chứng → nghi vấn → kiểm tra" (tự soạn)

def drift_check(before, after, ids):
    """So nhãn của CÙNG một người trên bộ neo ở hai thời điểm."""
    k = cohen_kappa(before, after)
    f2p = [i for i, b, a in zip(ids, before, after) if b == "F" and a == "P"]
    p2f = [i for i, b, a in zip(ids, before, after) if b == "P" and a == "F"]
    print(f"self-kappa = {k:.2f} | Fail→Pass: {f2p} | Pass→Fail: {p2f}")
    if len(f2p) >= 2 and not p2f:
        print("⚠ lệch một chiều về phía DỄ DÃI — đọc lại rubric trước khi gán tiếp")
    elif len(p2f) >= 2 and not f2p:
        print("⚠ lệch một chiều về phía KHẮT KHE — kiểm tra xem tiêu chuẩn có vừa đổi?")
    elif f2p or p2f:
        print("ℹ lật hai chiều — nhiễu ngẫu nhiên, xem các ca này có phải ca biên")

ids   = [f"A{i:02d}" for i in range(1, 13)]
week0 = list("PPFPFPFPPFPF")
week8 = list("PPPPFPPPPFPP")
drift_check(week0, week8, ids)
# self-kappa = 0.44 | Fail→Pass: ['A03', 'A07', 'A12'] | Pass→Fail: []
# ⚠ lệch một chiều về phía DỄ DÃI — đọc lại rubric trước khi gán tiếp

4.11Case study: team VíXanh đi từ κ 0.27 tới bộ gold

Tự làm người gán nhãn thứ ba

Dưới đây là 8 trace bịa của bot VíXanh. Hãy gán C2 · Giải quyết được việc theo rubric v2 ở trên, rồi so với hai người gán mô phỏng: Lan (khắt khe với câu trả lời chung chung nhưng quen tay chấp nhận chuyển tổng đài) và Minh (dễ dãi). Lab tính κ từng cặp và cho bạn xem nhãn theo rubric v2 kèm lý do.

4.12Kết quả cần có & nối sang các chương khác

Sách tóm lại: domain hẹp, tiêu chí rõ, chuyên gia có thời gian → benevolent dictator (nhanh, gọn); chủ quan, phức tạp hoặc quy mô lớn → quy trình cộng tác. Rubric và bộ gold là cây cầu giữa phán đoán con người và đo lường tự động.

Mẫu lưu trữ tối thiểu (tự soạn)

# gold.jsonl — một dòng / (trace, tiêu chí)
{"trace_id": "T0412", "criterion": "C2", "label": "F", "rubric_version": "v3",
 "decided_by": "consensus", "annotators": {"Lan": "F", "Minh": "P", "Tu": "F"},
 "note": "chuyển tổng đài khi bot tự huỷ được gói trả góp (<24h)"}

# decision_log.md — một dòng / thay đổi rubric
2026-09-12 | C3 → tách C3a/C3b | lý do: lệch emoji vs đồng cảm | đề xuất: Hà | duyệt: Head of CX
2026-09-19 | C3a + luật "nhắc lại vấn đề cụ thể" | lý do: 5 ca "mình hiểu cảm giác" | đề xuất: Tú

Trường annotators giữ nguyên nhãn gốc của từng người — sau này muốn tính lại κ hay nghiên cứu vì sao lệch vẫn làm được. Trường rubric_version cho phép gán lại có chọn lọc khi rubric đổi.

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

Hệ thống của bạn gửi mỗi request LLM tới một model phù hợp (nhỏ / vừa / lớn), cân bằng chất lượng – chi phí – độ trễ. Chi phí và độ trễ đo tự động được; chất lượng thì cần nhãn người. Câu hỏi cốt lõi của eval: "route này có chấp nhận được không?" — tức câu trả lời của model được chọn có đủ tốt cho request này không. Chương 4 giúp bạn biến câu hỏi mơ hồ đó thành nhãn đáng tin.

1. Ai là người gán?

Nếu chỉ mình bạn quyết "đạt/không đạt" → bạn là benevolent dictator (và như sách nhắc, hãy trung thực về giới hạn hiểu biết — với request về y khoa hay pháp lý, bạn không phải chuyên gia). Cách làm thực tế: bạn là người phán chính, nhưng chạy một vòng hiệu chuẩn với một đồng nghiệp trên 40 request để kiểm tra rubric có đứng được khi rời khỏi đầu bạn không — vì cuối cùng một LLM judge sẽ phải áp dụng nó.

2. Rubric nháp v0 cho "route chấp nhận được"

3. Code tự viết: tạo sheet ẩn danh & báo cáo κ từng tiêu chí

import csv, random, hashlib
from collections import defaultdict

CRITERIA = ["correct", "covers_ask", "format_ok"]      # + 'acceptable' = AND của 3 cái

def make_blind_sheet(logs, n=40, seed=7, path="sheet.csv", key_path="key.csv"):
    """logs: dict {req_id, tier, category, prompt, answer, model}.
    Chọn mẫu phân tầng theo (tier, category), ẨN tên model, xáo thứ tự."""
    rng = random.Random(seed)
    strata = defaultdict(list)
    for r in logs:
        strata[(r["tier"], r["category"])].append(r)
    picked, keys = [], list(strata)
    while len(picked) < n and any(strata.values()):
        for k in keys:
            if strata[k] and len(picked) < n:
                picked.append(strata[k].pop(rng.randrange(len(strata[k]))))
    rng.shuffle(picked)
    with open(path, "w", newline="") as f, open(key_path, "w", newline="") as g:
        w, wk = csv.writer(f), csv.writer(g)
        w.writerow(["item", "prompt", "answer"] + CRITERIA + ["note"])
        wk.writerow(["item", "req_id", "tier", "model"])
        for r in picked:
            item = hashlib.sha1(r["req_id"].encode()).hexdigest()[:8]   # id mờ
            w.writerow([item, r["prompt"], r["answer"]] + [""] * (len(CRITERIA) + 1))
            wk.writerow([item, r["req_id"], r["tier"], r["model"]])
    return path, key_path

def load(path):
    with open(path) as f:
        return {row["item"]: row for row in csv.DictReader(f)}

def report(sheet_a, sheet_b, key_path):
    """Hai người điền P/F vào bản sao của sheet; key chỉ mở SAU khi gán xong."""
    A, B, K = load(sheet_a), load(sheet_b), load(key_path)
    items = sorted(set(A) & set(B))
    for c in CRITERIA + ["acceptable"]:
        get = (lambda s, i: s[i][c]) if c != "acceptable" else \
              (lambda s, i: "P" if all(s[i][x] == "P" for x in CRITERIA) else "F")
        a, b = [get(A, i) for i in items], [get(B, i) for i in items]
        po = sum(x == y for x, y in zip(a, b)) / len(items)
        print(f"{c:<11} %agree={po:.0%}  kappa={cohen_kappa(a, b):.2f}")
    print("\nCa lệch 'covers_ask' (đem vào alignment session):")
    for i in items:
        if A[i]["covers_ask"] != B[i]["covers_ask"]:
            print(f"  {i} tier={K[i]['tier']:<6} A={A[i]['covers_ask']} B={B[i]['covers_ask']}"
                  f"  noteA={A[i]['note']!r}")

Đã chạy thử với log giả lập 500 request và hai sheet điền tự động; đầu ra có dạng covers_ask %agree=88% kappa=0.66 kèm danh sách item lệch và tier tương ứng — tier chỉ hiện ra sau khi gán xong, qua file key.

4. Cạm bẫy riêng của eval routing

• Thấy tên model khi gán. Bias kỳ vọng làm nhãn đo định kiến thay vì chất lượng. Luôn ẩn tên + trộn tier.
• Chỉ báo % đồng ý. Router tốt → phần lớn route acceptable (85–95%) → đúng vùng mà % đồng ý vô nghĩa (LAB 1). Báo κ và dồn mẫu các ca router phân vân.
• Collusion qua LLM trong pool. Nếu cả hai người dùng cùng một LLM gợi ý nhãn — và LLM đó lại là một model trong pool routing — κ đẹp giả, và nhãn nghiêng về phong cách của chính model đó.
• Drift "dễ tính dần với model rẻ". Sau vài trăm câu của model nhỏ, ngưỡng "chấp nhận được" tụt dần. Giữ bộ neo 10–15 request gán lại mỗi 2–3 tuần; dùng drift_check ở mục 4.10.
• Trộn chi phí/độ trễ vào nhãn chất lượng. "Câu này ổn nhưng model lớn thì phí" — không thuộc rubric. Nhãn người chỉ đo chất lượng; đánh đổi được tính ở tầng phân tích.
• Một κ cho mọi loại request. Tách báo cáo theo loại (code, trích xuất, chat…) — "đủ yêu cầu" với code và với chat có thể cần luật khác nhau.

5. Nhãn thứ hai: "regret" — model lớn có tốt hơn đáng kể không?

"Acceptable" trả lời "route này có hỏng không". Để chỉnh ngưỡng router, bạn còn muốn biết "route rẻ có làm người dùng thiệt không". Gợi ý (tự soạn): với một mẫu request đã route về tier nhỏ, chạy thêm model lớn, cho người gán xem hai câu trả lời thứ tự ngẫu nhiên, không tên, hỏi: "Có câu nào tốt hơn đáng kể đến mức người dùng sẽ nhận ra không? (A / B / Ngang nhau)". Đây là nhãn 3 lớp → vẫn dùng Cohen's κ (hoặc Fleiss nếu ≥ 3 người). Định nghĩa "đáng kể" sẽ là tiêu chí khó đồng thuận nhất — chuẩn bị tinh thần cho vài vòng alignment và các decision rule kiểu "chỉ tính khi khác biệt làm thay đổi hành động của người dùng".

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. Hai câu trích nguyên văn được đánh dấu rõ. Mọi ví dụ số, case study VíXanh, rubric mẫu, lab và đoạn code là tự dựng để minh hoạ. Nguồn: Evals for AI Engineers — Shreya Shankar & Hamel Husain, O'Reilly (Early Release).