Giao diện cho review thủ công: đọc trace nhanh hơn, đúng chỗ hơn

10.1Vì sao vẫn cần người đọc trace — và vì sao không phải spreadsheet

Trực giác. Hãy nghĩ evaluator tự động (Ch.5) như camera an ninh: chạy 24/7, rẻ, nhưng chỉ nhìn đúng những góc đã được lắp. Người review là thanh tra đi bộ: chậm và đắt, nhưng thấy được thứ không camera nào được lắp để nhìn. Ta cần thanh tra vì hai lý do:

1. Điểm mù của evaluator — judge chỉ đo những tiêu chí đã viết ra; một kiểu lỗi mới (vd agent nhầm khu học chính) không có judge nào canh.
2. Định nghĩa chất lượng thay đổi — càng xem dữ liệu, team càng hiểu "tốt" nghĩa là gì (criteria drift, Ch.4). Nhãn của người là thứ giữ judge bám theo định nghĩa mới.

Câu hỏi của chương vì thế không phải "có nên review tay không" mà là review thế nào cho hiệu quả. Và điểm nghẽn đầu tiên là công cụ: một trace LLM gồm query, nhiều tool call có tham số có cấu trúc, tài liệu được retrieve, reasoning trung gian và output cuối — thứ này không sống tốt trong hàng–cột.

Ví dụ xuyên suốt của sách: trợ lý bất động sản nhận yêu cầu "tìm nhà 3 phòng ngủ dưới $600k gần trung tâm, email 2 căn tốt nhất cho khách". Một trace gồm 3 tool call (tìm listing, lọc, xem lịch), 6 listing được retrieve, reasoning chọn căn và một email 2 đoạn. Nhồi vào một hàng spreadsheet, người review phải tự dựng lại trace trong đầu nhiều lần.

10.2Nguyên tắc thiết kế: heuristic usability của Nielsen

Sách dùng một tập con các heuristic usability kinh điển của Jakob Nielsen làm khung khởi đầu, dịch mỗi nguyên tắc sang một quyết định thiết kế cụ thể cho review tool. Tóm lại bằng lời của sổ tay:

Trực giác: reviewer là người làm một việc lặp lại hàng trăm lần. Mỗi giây ma sát nhân lên hàng trăm; mỗi cơ hội bấm nhầm nhân lên thành hàng chục nhãn sai. Heuristic giúp ta nhìn UI bằng con mắt đó thay vì con mắt "cho có".

10.3Thành phần cốt lõi: một review UI tốt trông thế nào

Hai yêu cầu nền tảng theo sách:

Wireframe do sổ tay tự thiết kế, gom các nguyên tắc và tính năng của chương. Các số tròn khớp với bảng chú thích bên dưới.

Mô hình dữ liệu cho nhãn: quyết định quan trọng hơn giao diện

UI đẹp mà lưu nhãn sai cách thì mọi thứ phía sau (golden set, hiệu chỉnh judge, đo drift) đều hỏng. Đây là schema sổ tay đề xuất cho mỗi lần reviewer bấm một nhãn:

{
  "trace_id": "tr-8a3f",
  "reviewer": "lan",
  "verdict": "fail",                  // pass | fail | defer
  "tags": ["tone_mismatch"],          // axial codes (Ch.3) — danh sách có thể thêm mới
  "note": "Khách nhà đầu tư, 2 đoạn đầu toàn xã giao",   // open code
  "spans": [{"start": 0, "end": 118, "tag": "tone_mismatch"}],  // inline annotation
  "rubric_version": "v2",             // nhãn này theo định nghĩa nào?
  "source": "uncertainty",            // random | uncertainty | failure — dùng khi ước lượng
  "agent_version": "v2.3",
  "supersedes": "lbl-0192",           // sửa nhãn cũ = bản ghi MỚI trỏ về bản cũ
  "ts": "2026-09-21T10:14:03Z"
}

• Append-only + supersedes: sửa nhãn không xoá lịch sử → đo được ai đổi ý, đổi ở đâu (tín hiệu criteria drift, §10.5).
• rubric_version: khi định nghĩa "tone" thay đổi, bạn biết nhãn nào cần xem lại.
• source: bắt buộc nếu muốn ước lượng tỷ lệ lỗi đúng cách — chỉ nhãn có source = random mới dùng để ước lượng (§10.6).
• defer là một verdict riêng, không phải "chưa chấm" — để biết ca nào đang chờ thảo luận.

10.4Tính năng làm review nhanh hơn và tốt hơn

Sách chia các tính năng nâng cao thành ba nhóm: làm từng lượt review nhanh hơn, thu feedback chất lượng hơn, và giúp điều hướng trong cả tập dữ liệu.

Vì sao phím tắt là đòn bẩy số 1

Sách ước lượng reviewer dùng hotkey đi qua trace nhanh hơn 2–3 lần người bấm chuột, và khuyên thêm phím tắt trước mọi cải tiến giao diện khác. Lý do nằm ở chỗ thời gian bị mất: không phải lúc đọc, mà lúc thao tác giữa các lần đọc.

Code: một review app tối thiểu (~50 dòng, chỉ thư viện chuẩn Python)

Đây là bản "UI tối giản" ở §10.9, do sổ tay tự viết: một trace mỗi màn hình, tool call thu gọn bằng <details>, phím tắt P/F/D/N/B, bắt buộc lý do khi Fail, nhãn ghi append-only vào labels.jsonl.

# review_app.py — review UI tối thiểu, chỉ dùng thư viện chuẩn Python.
# Chạy: python review_app.py traces.jsonl  → mở http://localhost:8765
import json, sys, time
from http.server import BaseHTTPRequestHandler, HTTPServer

TRACES = [json.loads(l) for l in open(sys.argv[1], encoding="utf-8") if l.strip()]
LABELS = "labels.jsonl"          # append-only: sửa nhãn = ghi bản ghi mới

PAGE = """<!doctype html><meta charset=utf-8><title>Review</title>
<style>body{font:15px system-ui;max-width:860px;margin:auto}
pre{white-space:pre-wrap;background:#f4f4f4;padding:8px}
.out{border:2px solid #36c;padding:10px}</style>
<div id=bar></div><div id=view></div>
<textarea id=note rows=2 cols=80 placeholder="ghi chú (bắt buộc khi Fail)"></textarea>
<p>Phím: <b>P</b> pass · <b>F</b> fail · <b>D</b> defer · <b>N</b>/<b>B</b> next/back</p>
<script>
let T=[], i=0;
fetch('/api/traces').then(r=>r.json()).then(d=>{T=d; show();});
function show(){ const t=T[i];
  bar.textContent=`Trace ${i+1}/${T.length} · ${t.id} · agent ${t.version}`;
  view.innerHTML=`<p><b>Query:</b> ${t.query}</p>`+
    t.tools.map(c=>`<details><summary>▸ ${c.name}</summary><pre>${JSON.stringify(c,null,1)}</pre></details>`).join('')+
    `<div class=out>${t.output.replace(/\\n/g,'<br>')}</div>`; note.value=''; }
async function label(v){
  if(v==='fail' && !note.value.trim()){ note.focus(); return alert('Fail cần lý do'); }
  await fetch('/api/label',{method:'POST',body:JSON.stringify({id:T[i].id,verdict:v,note:note.value})});
  if(i<T.length-1){i++; show();} }
document.addEventListener('keydown',e=>{
  if(e.target===note) return;                 // đang gõ ghi chú thì không bắt phím
  const k=e.key.toLowerCase();
  if(k==='p') label('pass'); if(k==='f') label('fail'); if(k==='d') label('defer');
  if(k==='n'&&i<T.length-1){i++;show();} if(k==='b'&&i>0){i--;show();} });
</script>"""

class H(BaseHTTPRequestHandler):
    def _send(self, body, ctype="application/json"):
        self.send_response(200); self.send_header("Content-Type", ctype + "; charset=utf-8")
        self.end_headers(); self.wfile.write(body.encode("utf-8"))
    def do_GET(self):
        if self.path == "/api/traces": self._send(json.dumps(TRACES, ensure_ascii=False))
        else: self._send(PAGE, "text/html")
    def do_POST(self):
        rec = json.loads(self.rfile.read(int(self.headers["Content-Length"])))
        rec["ts"] = time.time(); rec["reviewer"] = self.headers.get("X-Reviewer", "me")
        with open(LABELS, "a", encoding="utf-8") as f: f.write(json.dumps(rec, ensure_ascii=False) + "\n")
        self._send('{"ok":true}')

if __name__ == "__main__":
    print(f"{len(TRACES)} traces → http://localhost:8765")
    HTTPServer(("localhost", 8765), H).serve_forever()

Mỗi dòng của traces.jsonl có dạng {"id","version","query","tools":[{"name",…}],"output"}. Hai điều cố ý làm "đúng" dù bản này rất nhỏ: (1) phím tắt bị tắt khi đang gõ ghi chú; (2) nhãn không bao giờ bị ghi đè. Điều cố ý bỏ qua để giữ ngắn: escape HTML của output (dữ liệu production phải escape trước khi đưa vào innerHTML), đăng nhập, tag, filter — chính là những thứ Lab 1 bên dưới thêm vào.

10.5Case study EvalGen & bài học về criteria drift

Sách dùng EvalGen (Shankar và cộng sự, 2024; bản công khai EvalGen v2 tích hợp trong ChainForge) để minh hoạ các nguyên tắc trên trong một thiết kế tối giản.

Criteria drift nhìn thấy được

Sơ đồ sổ tay tự vẽ: một reviewer chấm 40 trace liên tiếp. Tới trace 18, sau khi thấy nhiều email xã giao dài cho khách nhà đầu tư, cô ấy đổi định nghĩa "tone đạt" từ "lịch sự" thành "hợp persona". Nhãn trước đó giờ theo một chuẩn khác.

# drift_check.py — phát hiện criteria drift bằng cách chấm lại 10 trace đầu ở cuối buổi.
import math

def cohen_kappa(a, b):
    labels = sorted(set(a) | set(b))
    n = len(a)
    po = sum(x == y for x, y in zip(a, b)) / n                     # đồng thuận quan sát
    pe = sum((a.count(l) / n) * (b.count(l) / n) for l in labels)  # đồng thuận do may rủi
    return (po - pe) / (1 - pe) if pe < 1 else 1.0

def wilson(k, n, z=1.96):
    """Khoảng tin cậy 95% cho tỷ lệ k/n — dùng cho lát random nhỏ (§10.6)."""
    p = k / n
    d = 1 + z * z / n
    c = (p + z * z / (2 * n)) / d
    h = z * math.sqrt(p * (1 - p) / n + z * z / (4 * n * n)) / d
    return max(0, c - h), min(1, c + h)

# Số liệu minh hoạ: nhãn lượt 1 (đầu buổi) và lượt 2 (cuối buổi) của cùng 10 trace
first  = ["P", "P", "F", "P", "P", "F", "P", "P", "P", "P"]
second = ["P", "F", "F", "P", "F", "F", "P", "F", "P", "P"]
print("tự đồng thuận:", sum(x == y for x, y in zip(first, second)) / 10)   # 0.7
print("kappa:", round(cohen_kappa(first, second), 2))                        # 0.4
flipped = [i for i, (x, y) in enumerate(zip(first, second)) if x != y]
print("trace đổi nhãn:", flipped)       # [1, 4, 7] → mở lại đúng các trace này
print("Wilson 3/40:", [round(x, 3) for x in wilson(3, 40)])   # [0.026, 0.199]

10.6Chọn trace nào để người đọc: ba chiến lược lấy mẫu

Trực giác: bạn có ngân sách 40 lượt đọc/tuần cho hàng chục nghìn trace. Mỗi chiến lược lấy mẫu là một cái "đèn pin" chiếu vào một vùng khác của quần thể: có đèn chỉ soi chỗ đã biết là hỏng, có đèn soi chỗ các evaluator cãi nhau, có đèn soi ngẫu nhiên. Không đèn nào soi được hết.

Hàng nghìn đến hàng triệu output, chỉ một phần nhỏ được người xem. Ba chiến lược, mỗi cái nhìn thấy một phần khác nhau của "quần thể" trace:

Trong thực tế sách khuyên trộn cả ba: random làm baseline, uncertainty bắt ca mơ hồ, failure-driven xử lý ca rõ ràng hỏng.

Chỉnh tỷ lệ theo tỷ lệ lỗi

Code: dựng batch review theo tỷ lệ trộn

# sampling.py — dựng batch review theo tỷ lệ trộn failure / uncertainty / random.
import random
from collections import Counter

def disagreement(verdicts):
    """Tỷ lệ phiếu thiểu số: 0 = mọi evaluator đồng ý, 0.5 = chia đôi."""
    c = Counter(verdicts)
    return min(c.values()) / len(verdicts) if len(c) > 1 else 0.0

def build_review_batch(traces, n=40, mix=(0.5, 0.3, 0.2), seed=None):
    rng = random.Random(seed)
    n_fail, n_unc = round(n * mix[0]), round(n * mix[1])
    n_rand = n - n_fail - n_unc
    # 1) Random rút TRƯỚC, từ toàn bộ quần thể → lát này không thiên lệch.
    batch = [{**t, "source": "random"} for t in rng.sample(traces, n_rand)]
    picked = {t["id"] for t in batch}
    def take(pool, k, source):
        for t in pool:
            if k == 0: break
            if t["id"] not in picked:
                picked.add(t["id"]); batch.append({**t, "source": source}); k -= 1
        return k                                     # số suất còn thiếu
    flagged = [t for t in traces if t["flags"]]      # guardrail, 👎, lỗi tool...
    rng.shuffle(flagged)
    left = take(flagged, n_fail, "failure")
    unsure = sorted((t for t in traces if disagreement(t["verdicts"]) > 0),
                    key=lambda t: -disagreement(t["verdicts"]))
    left = take(unsure, n_unc + left, "uncertainty")  # thiếu ca fail → dồn sang
    if left:                                          # vẫn thiếu → lấp bằng random,
        rest = [t for t in traces if t["id"] not in picked]   # nhưng gắn nhãn riêng
        take(rng.sample(rest, left), left, "fill")
    rng.shuffle(batch)                               # reviewer không đoán được nguồn
    return batch

def estimate_fail_rate(labeled):
    """Chỉ dùng lát 'random' để ước lượng tỷ lệ lỗi tổng thể."""
    rand = [t for t in labeled if t["source"] == "random"]
    return sum(t["human"] == "fail" for t in rand) / len(rand), len(rand)

if __name__ == "__main__":
    rng = random.Random(7)
    traces = [{"id": f"tr-{i:04d}",
               "flags": ["thumbs_down"] if rng.random() < 0.03 else [],
               "verdicts": [rng.random() < 0.9, rng.random() < 0.88, rng.random() < 0.95]}
              for i in range(5000)]
    b = build_review_batch(traces, n=40, seed=1)
    print(Counter(t["source"] for t in b))           # {'failure': 20, 'uncertainty': 12, 'random': 8}

Ba chi tiết thiết kế đáng chú ý: (1) rút random trước từ toàn bộ quần thể — nếu rút sau, từ "phần còn lại" đã bị loại ca flagged, lát random không còn đại diện; (2) khi thiếu ca failure (lỗi hiếm), suất thừa dồn sang uncertainty — đúng tinh thần "lỗi hiếm → tăng uncertainty/random"; (3) xáo batch để reviewer không biết trace đến từ lát nào, tránh thiên kiến "trace từ hàng failure chắc là hỏng".

Gợi ý thí nghiệm: (1) kéo tỷ lệ lỗi xuống 2%: failure-driven vẫn cho nhiều lỗi nhất mỗi lượt, nhưng gần như toàn loại A đã biết và luôn 0 lỗi C; pool flagged lúc này chỉ còn vài chục trace nên qua các tuần sẽ lặp lại đúng những lỗi đó (mô phỏng chỉ chạy một batch, nên hiện tượng "cạn" theo thời gian bạn phải tự hình dung); (2) tắt rule-based và xem cột B của Uncertainty sụt — minh hoạ pitfall "evaluator tương quan"; (3) đặt random = 0% và xem dòng ước lượng tỷ lệ lỗi biến mất, trong khi "Fail/cả batch" cho con số bi quan sai lệch. Mọi tham số của mô hình (xác suất flag, độ nhạy judge…) là giả định minh hoạ.

10.7Nhìn theo nhóm: clustering & search

Review từng trace bắt lỗi cụ thể; nhưng nhiều lỗi chỉ lộ ra khi xem một nhóm trace cùng lúc. Review UI tốt cần công cụ khám phá mẫu hình qua các trace giống nhau — chủ yếu là clustering và search (Ch.11 đi sâu hơn).

Kết hợp với bulk tag: xem vài trace đại diện mỗi cụm, rồi gán một failure mode chung cho cả cụm — nhanh, nhưng kiểm tra kỹ trước khi áp hàng loạt.

Code: cluster ngữ nghĩa để chọn đại diện

# cluster_review.py — gom trace theo nghĩa rồi chọn vài đại diện mỗi cụm để review.
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.cluster import KMeans
from collections import defaultdict

queries = [  # dữ liệu minh hoạ
    "căn hộ giá rẻ gần trường tốt quận 7", "chung cư rẻ gần trường cấp 1 tốt",
    "căn hộ dưới 3 tỷ gần trường quốc tế", "nhà phố cho nhà đầu tư lợi suất cho thuê",
    "đầu tư căn hộ cho thuê lợi suất cao", "so sánh lợi suất cho thuê hai dự án",
    "đặt lịch xem nhà thứ bảy", "hẹn xem căn hộ sáng chủ nhật", "dời lịch xem nhà sang tuần sau",
]
X = TfidfVectorizer(ngram_range=(1, 2)).fit_transform(queries)
km = KMeans(n_clusters=3, n_init=10, random_state=0).fit(X)

clusters = defaultdict(list)
for q, c in zip(queries, km.labels_):
    clusters[c].append(q)
for c, qs in clusters.items():
    print(f"cụm {c} ({len(qs)} trace):", qs)
# Quy trình: đọc 3–5 trace mỗi cụm → nếu ≥ 4/5 cùng lỗi, mới tính tới bulk tag cả cụm.

Chạy thử (scikit-learn 1.8) cho ra ba cụm "gần trường", "lợi suất đầu tư", "lịch hẹn" — nhưng câu "hẹn xem căn hộ sáng chủ nhật" bị kéo vào cụm "gần trường" vì chung chữ "căn hộ". Đó là bài học thật: TF-IDF bắt từ, không bắt ý. Production nên dùng embedding của query/output, và luôn đọc đại diện trước khi tin cụm — cụm là giả thuyết, không phải kết luận.

10.8Đưa review vào quy trình kỹ thuật

UI chỉ có giá trị nếu được dùng đều và feedback thực sự làm hệ thống thay đổi. Không ai dùng → ma sát vẫn còn quá cao.

Code: đo xem LLM judge còn khớp người không

Mỗi nhãn người trong UI cũng là một điểm dữ liệu để kiểm tra judge. Chỉ cần lưu kèm verdict của judge cho cùng trace:

# judge_calib.py — đo judge còn khớp người không, từ nhãn trong review UI.
import json

def calibration(rows):
    """rows: [{'human': 'pass'|'fail', 'judge': 'pass'|'fail'}] (bỏ qua 'defer')."""
    rows = [r for r in rows if r["human"] in ("pass", "fail")]
    tp = sum(r["human"] == "fail" and r["judge"] == "fail" for r in rows)
    fn = sum(r["human"] == "fail" and r["judge"] == "pass" for r in rows)  # judge lọt lỗi
    tn = sum(r["human"] == "pass" and r["judge"] == "pass" for r in rows)
    fp = sum(r["human"] == "pass" and r["judge"] == "fail" for r in rows)  # judge báo động giả
    return {
        "n": len(rows),
        "TPR (bắt được lỗi)": tp / max(1, tp + fn),
        "TNR (tha đúng cái tốt)": tn / max(1, tn + fp),
        "lọt lỗi → cần xem": fn,
    }

if __name__ == "__main__":
    # Số liệu minh hoạ: 60 trace người đã chấm trong tuần
    rows = ([{"human": "fail", "judge": "fail"}] * 14 + [{"human": "fail", "judge": "pass"}] * 6 +
            [{"human": "pass", "judge": "pass"}] * 37 + [{"human": "pass", "judge": "fail"}] * 3)
    print(json.dumps(calibration(rows), ensure_ascii=False, indent=1))
    # TPR = 14/20 = 0.70 → judge lọt 30% lỗi: mở 6 trace FN, xem có chung failure tag không

Kết quả minh hoạ: TPR 0,70, TNR 0,925. Sáu trace "người Fail, judge Pass" chính là đầu vào để sửa prompt judge — đúng tín hiệu sách mô tả (người liên tục đánh Fail cái judge cho Pass → sửa prompt, huấn luyện lại, hoặc thay judge). Lưu ý: nếu các nhãn này đến từ batch trộn (nhiều ca flagged), TPR/TNR vẫn dùng được vì chúng tính có điều kiện trên nhãn người; thứ không dùng được là tỷ lệ lỗi tổng.

{
  "case_id": "golden-0147",
  "from_trace": "tr-9c12",
  "input": {"query": "3 PN dưới $600k gần trung tâm, email 2 căn", "persona": "first_time"},
  "tool_fixtures": {"search_listings": "fixtures/tr-9c12/search.json"},
  "expected": {"verdict": "pass_required",
               "must_not": ["giá vượt budget", "listing không có trong kết quả tool"]},
  "tags_at_creation": ["budget_wrong", "hallucinated_listing"],
  "rubric_version": "v2",
  "added_by": "lan", "added_at": "2026-09-23"
}

10.9Tiến hoá của một review UI, tín hiệu vận hành & DocWrangler

Sách kể lại hành trình của review UI cho trợ lý bất động sản qua ba giai đoạn. Điểm đáng học là mỗi giai đoạn sửa đúng thứ giai đoạn trước làm hỏng:

1. Spreadsheet — export log sang Google Sheets. Query bị cắt, email là khối text liền, ghi chú nhiều người dồn một ô, kết quả tool là chuỗi JSON phải dán sang tab khác để đọc. Chậm, không cấu trúc, dễ sai.
2. UI tối giản — Streamlit/Gradio/AI assistant: một trace mỗi màn hình, input – persona – email tách rõ, nút Pass/Fail + comment, Next/Prev. Đã khác biệt lớn.
3. UI nâng cao — thêm tool call & retrieval, failure tag (axial code) + ghi chú tự do (open code), highlight thực thể, phím tắt, metadata, cluster view + bulk tag, search "tìm email giống thế này".

Case study: DocWrangler — review khép vòng vào prompt

DocWrangler (Shankar và cộng sự, 2025) là một IDE cho xử lý tài liệu bằng LLM. Sách dùng nó để cho thấy review UI không chỉ để đánh giá mà còn để cải thiện hệ thống: ghi chú nhẹ (nhanh hơn gán nhãn chính thức) tích luỹ thành tín hiệu đủ để đề xuất prompt mới.

1. Xem cạnh nhau: tài liệu gốc · output trích xuất · prompt đã sinh ra nó.
2. Open coding nhanh: ghi chú tự do kiểu "bỏ sót trường ngày", "bỏ qua bảng thứ hai".
3. Cải thiện prompt: gom ghi chú + prompt hiện tại → hệ thống đề xuất prompt mới, hiển thị song song với bản cũ để chấp nhận / từ chối / sửa tiếp.

10.10Case study tổng hợp: từ spreadsheet đến review UI trong 6 tuần

10.11Pitfalls thường gặp — và cách sửa

• Đọc quá ít trace. Xem vài ví dụ sau mỗi thay đổi rồi thôi. Lỗi tinh vi chỉ lộ sau hàng chục–hàng trăm trace; lỗi hiếm (dưới 1%, như gửi email nhầm người) vẫn có thể rất đắt. Sửa: mỗi buổi review có một mẫu ngẫu nhiên từ các trace đã pass mọi check tự động — cách duy nhất để thấy điểm mù của evaluator.
• Dựa quá nhiều vào bất đồng giữa evaluator. Uncertainty sampling chỉ đa dạng bằng mức độ không tương quan của các evaluator; nếu tất cả là LLM judge có prompt na ná, chúng đồng ý và bất đồng ở cùng chỗ → cả loại lỗi không bao giờ được lấy mẫu. Sửa: thêm ít nhất một evaluator rule-based vào pool (thử trong Lab 2).
• Xem nhẹ UI tuỳ biến. Nền tảng có sẵn là khởi đầu hợp lý, nhưng khi quy trình chín, view theo domain, phím tắt cho annotation hay dùng và diff giữa các phiên bản prompt làm reviewer nhanh và nhất quán hơn rõ rệt. Sửa: nhật ký ma sát → build đúng thứ đang cản.
• Không cho sửa nhãn cũ. Criteria drift âm thầm làm dataset mất nhất quán. Sửa: nhãn append-only có supersedes, rubric_version; chấm lại mù định kỳ.
• Bỏ phần random, hoặc tính tỷ lệ lỗi trên cả batch trộn. Buổi review toàn edge case → bức tranh bi quan sai lệch. Sửa: lưu source, chỉ ước lượng trên lát random, kèm khoảng tin cậy.
• (Tự bổ sung) Phím tắt cướp phím khi đang gõ. Reviewer gõ ghi chú và vô tình kích hoạt Fail/Next. Sửa: bỏ qua phím khi focus ở ô nhập; Esc để thoát.
• (Tự bổ sung) Bulk tag không kiểm tra. Gán nhãn cả cụm sau khi đọc 2–3 trace → hàng chục nhãn sai vào golden set. Sửa: đọc đại diện + trace xa tâm, gắn source = bulk, kiểm tra ngẫu nhiên.
• (Tự bổ sung) Review không dẫn tới hành động. Nhãn nằm trong DB, không ai xem. Sửa: nút golden set/file bug ngay trong UI, triage định kỳ, dashboard "người ≠ judge".

Nối với các chương khác

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

Router của bạn gửi mỗi request tới model phù hợp, cân bằng chất lượng / chi phí / latency. "Trace" ở đây là một quyết định route, và câu hỏi review không còn là "output có tốt không" mà là "route này có đúng không" — một câu hỏi so sánh: model rẻ hơn có đủ không, model đắt hơn có đáng không. Mọi thứ trong chương vẫn áp dụng, nhưng cần đổi hình dạng của UI.

Ánh xạ từng ý của chương sang router

Code: biến nhãn route thành con số ra quyết định

# routing_review.py — biến nhãn review quyết định route thành con số hành động được.
# Nhãn: ok | upgrade (model rẻ không đủ tốt) | downgrade (model đắt là thừa) | defer
from collections import Counter, defaultdict

PRICE = {"small": 0.0004, "large": 0.0060}   # $/request trung bình — số minh hoạ

def routing_report(labels, weekly_volume):
    lab = [r for r in labels if r["label"] != "defer"]
    c = Counter(r["label"] for r in lab)
    n = len(lab)
    small = [r for r in lab if r["routed"] == "small"]
    large = [r for r in lab if r["routed"] == "large"]
    up_rate = sum(r["label"] == "upgrade" for r in small) / max(1, len(small))
    down_rate = sum(r["label"] == "downgrade" for r in large) / max(1, len(large))
    share_large = len(large) / n          # chỉ đúng nếu labels đến từ lát RANDOM
    saving = weekly_volume * share_large * down_rate * (PRICE["large"] - PRICE["small"])
    extra = weekly_volume * (1 - share_large) * up_rate * (PRICE["large"] - PRICE["small"])
    by_cat = defaultdict(Counter)
    for r in lab: by_cat[r["category"]][r["label"]] += 1
    return {"n": n, "ok_rate": c["ok"] / n,
            "under-route (small→nên large)": round(up_rate, 3),
            "over-route (large→small đủ)": round(down_rate, 3),
            "tiết kiệm nếu sửa over-route ($/tuần)": round(saving, 2),
            "chi thêm nếu sửa under-route ($/tuần)": round(extra, 2),
            "theo loại request": {k: dict(v) for k, v in by_cat.items()}}

if __name__ == "__main__":
    demo = ([{"routed": "small", "label": "ok", "category": "faq"}] * 22 +
            [{"routed": "small", "label": "upgrade", "category": "code"}] * 4 +
            [{"routed": "large", "label": "ok", "category": "code"}] * 9 +
            [{"routed": "large", "label": "downgrade", "category": "faq"}] * 5 +
            [{"routed": "large", "label": "defer", "category": "legal"}] * 2)
    for k, v in routing_report(demo, weekly_volume=200_000).items(): print(k, "=", v)

Chạy với dữ liệu minh hoạ: 40 nhãn hợp lệ, OK 77,5%; under-route 15,4% (4/26 request vào model-S), over-route 35,7% (5/14 request vào model-L). Với 200k request/tuần, sửa over-route tiết kiệm ~$140/tuần, sửa under-route tốn thêm ~$112/tuần. Cột "theo loại request" cho thấy under-route đều là code, over-route đều là faq → hai chỉnh ngưỡng theo category, không phải một ngưỡng chung. Cảnh báo: các tỷ lệ này chỉ ngoại suy được nếu nhãn đến từ lát random — đúng bài học Ví dụ 10.9.

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. Ví dụ, số liệu minh hoạ, code, bài tập, case study và lab là tài liệu tự soạn của sổ tay. Nguồn: Evals for AI Engineers — Shreya Shankar & Hamel Husain, O'Reilly (Early Release).