Phân tích lỗi (Error Analysis): từ trace thô đến taxonomy lỗi

3.1Bức tranh toàn cảnh pha Analyze

Trong vòng đời Analyze → Measure → Improve (chương 1), Analyze là lúc ta nhìn xem hệ thống thực sự làm gì và hỏng ở đâu — trước khi viết bất kỳ evaluator nào. Lý do rất thực dụng: nếu chưa biết hệ thống hỏng theo những kiểu nào, bạn sẽ đo những thứ "nghe hay" (độ lưu loát, "helpfulness") thay vì những thứ đang thật sự làm người dùng khổ.

Ví dụ xuyên suốt của sách (và của các chương sau): một trợ lý CRM bất động sản giúp môi giới tìm listing, phân tích thị trường nhanh, soạn email cho khách và xem lịch dẫn đi xem nhà. Người dùng nói kiểu hội thoại, mơ hồ; hệ thống là agentic — LLM tự chọn bước tiếp theo (query listing → soạn email → xem lịch…), kết quả tool quay lại cho LLM, lặp đến khi xong. Chỉ một yêu cầu ngắn cũng có thể kéo theo nhiều bước và nhiều ràng buộc phải giữ suốt chuỗi. Trong trang này, các ví dụ tự viết đặt bối cảnh CRM đó ở thị trường Việt Nam (quận, tỷ đồng, tên khách Việt) cho dễ hình dung.

Trực giác: bác sĩ đọc bệnh án trước khi kê đơn

Hãy nghĩ tới một phòng khám mới mở. Bác sĩ giỏi không bắt đầu bằng việc mua sẵn 20 loại xét nghiệm "phổ biến". Họ khám trực tiếp vài chục bệnh nhân đầu tiên, ghi chú những gì thấy (open coding), rồi mới nhận ra "à, phần lớn là viêm họng, có một nhóm dị ứng theo mùa, và hai ca rất nặng cần quy trình riêng" (axial coding). Chỉ sau đó họ mới quyết định cần xét nghiệm nào (evaluator, chương 5) và đo tần suất (prevalence). Error analysis chính là "khám lâm sàng" cho hệ thống LLM.

Thuật ngữ nền

3.2Trace — đơn vị để đọc

Sách nhấn mạnh: ta đánh giá trace, không đánh giá từng bước riêng lẻ. Hành vi của một agent chỉ có nghĩa khi nhìn trọn từ đầu tới cuối; một message nhìn riêng có thể hoàn toàn hợp lý mà vẫn dẫn tới kết quả sai. Đọc cả trace giúp tìm ra chỗ lỗi khởi nguồn, thay vì đếm các triệu chứng phía sau như những lỗi độc lập.

{"trace_id": "tr-017",
 "query": "Gửi chị Lan 2 căn 2PN dưới 3 tỷ ở Thủ Đức đẹp nhất nhé",
 "steps": [
  {"type": "llm",  "out": "Kế hoạch: search_listings → lookup_contact → draft_email"},
  {"type": "tool", "name": "search_listings",
   "args": {"district": "Thủ Đức", "bedrooms": 2, "max_price": 3.0e9},
   "result": "5 listings"},
  {"type": "tool", "name": "lookup_contact", "args": {"name": "Lan"},
   "result": [{"id": 88, "name": "Trần Lan", "role": "seller"},
              {"id": 131, "name": "Nguyễn Thị Lan", "role": "buyer"}]},
  {"type": "tool", "name": "draft_email", "args": {"to": 88, "listings": ["L2", "L5"]}},
  {"type": "llm",  "out": "Em đã soạn email gửi chị Lan với 2 căn đẹp nhất."}]}

Tính không tất định (nondeterminism)

Vì output của LLM không tất định, chạy cùng một query hai lần có thể ra hai trace khác nhau — một trace chỉ là một đường chạy có thể. Khi một lỗi có vẻ "lúc có lúc không", hãy chạy lại cùng query vài lần để xem tần suất.

Đưa trace về dạng dễ annotate

Sách khuyên xuất trace từ nền tảng observability (Braintrust, LangSmith, Weave…) hoặc log JSON/DB, và nhiều team thấy spreadsheet — mỗi dòng một trace — là dễ gán nhãn nhất. Định dạng không quan trọng bằng việc trace đầy đủ. Đoạn code tự viết dưới đây "làm phẳng" file JSONL như ví dụ trên thành CSV có sẵn cột để ghi chú:

# flatten_traces.py — JSONL trace → CSV để annotate (code minh hoạ, tự viết)
import csv, json, sys

def summarize_step(step: dict) -> str:
    if step["type"] == "tool":
        args = json.dumps(step.get("args", {}), ensure_ascii=False)
        res = step.get("result", "")
        if isinstance(res, list):
            res = f"{len(res)} kết quả: " + "; ".join(r.get("name", str(r)) for r in res)
        return f"[tool] {step['name']}({args}) → {res}"
    return f"[llm] {step.get('out', '')}"

def flatten(path_in: str, path_out: str) -> int:
    n = 0
    with open(path_in, encoding="utf-8") as f, \
         open(path_out, "w", newline="", encoding="utf-8") as g:
        w = csv.writer(g)
        w.writerow(["trace_id", "query", "steps", "final", "open_code", "verdict"])
        for line in f:
            if not line.strip():
                continue
            t = json.loads(line)
            steps = [summarize_step(s) for s in t["steps"]]
            final = t["steps"][-1].get("out", "") if t["steps"] else ""
            # để trống 2 cột cuối cho người annotate
            w.writerow([t["trace_id"], t["query"], "\n".join(steps), final, "", ""])
            n += 1
    return n

if __name__ == "__main__":
    print(flatten(sys.argv[1], sys.argv[2]), "trace đã ghi")

Mẹo nhỏ: giữ cột steps ở dạng nhiều dòng trong một ô (Google Sheets/Excel hiển thị được), đừng tách mỗi bước ra một cột — trace dài ngắn khác nhau sẽ làm bảng loạn.

3.3Bước 1a — Bộ trace ban đầu từ log production

Bao nhiêu trace? Sách không đưa con số cố định: khoảng 100 trace là điểm khởi đầu hợp lý, nhưng tín hiệu thật là saturation. Nếu đã đọc 60 trace và 20 trace gần nhất đều rơi vào những lỗi đã biết, nhiều khả năng bạn đã bão hoà; nếu lỗi mới vẫn liên tục xuất hiện thì đọc tiếp. Dừng quá sớm → sót lỗi; kéo quá lâu → phí công xác nhận điều đã biết. App đơn giản bão hoà sớm; agent nhiều tool, nhiều bước cần khám phá lâu hơn.

Có hai nguồn để lập bộ trace: log production (ưu tiên nếu có) và query tổng hợp (mục 3.4). Với log production, sách gợi ý ba nguyên tắc:

1. Phủ đa dạngLấy mẫu trải qua nhiều tính năng, nhiều kiểu input. Dữ liệu nhỏ → random là đủ; dữ liệu lớn → cluster query (theo embedding hoặc keyword) rồi lấy mẫu từ mỗi cụm.
2. Săn trải nghiệm tệChủ động lấy trace có tín hiệu xấu: thumbs-down, người dùng diễn đạt lại cùng một yêu cầu nhiều lần, phiên kết thúc bằng việc người dùng chuyển sang kênh khác (gọi hotline, nhắn người thật).
3. Hỏi chuyên gia domainMôi giới lâu năm thường biết loại yêu cầu nào khó trước khi dữ liệu xác nhận — hãy nhờ họ chỉ điểm.

# sample_traces.py — lấy mẫu phân tầng + săn tín hiệu xấu (code minh hoạ, tự viết)
import random, re
from collections import defaultdict

BUCKETS = [("email", r"email|thư"), ("lịch", r"lịch|hẹn|xem nhà"),
           ("phân tích", r"giá|thị trường|so sánh|comps")]

def bucket_of(query: str) -> str:
    q = query.lower()
    for name, pat in BUCKETS:
        if re.search(pat, q):
            return name
    return "tìm nhà" if re.search(r"căn|nhà|pn|tỷ", q) else "khác"

def is_bad(t: dict) -> bool:
    return t.get("thumbs") == "down" or t.get("rephrased", 0) >= 2 or t.get("escalated", False)

def sample(traces, n_strat=65, n_bad=25, min_per_bucket=10, seed=42):
    rng = random.Random(seed)
    by_bucket = defaultdict(list)
    for t in traces:
        by_bucket[bucket_of(t["query"])].append(t)
    picked, total = [], len(traces)
    # 1) mỗi cụm tối thiểu min_per_bucket, phần còn lại chia theo tỷ lệ
    rest = n_strat - min_per_bucket * len(by_bucket)
    for b, items in by_bucket.items():
        k = min(len(items), min_per_bucket + round(rest * len(items) / total))
        picked += [dict(t, source="strat", bucket=b) for t in rng.sample(items, k)]
    # 2) săn trace có tín hiệu xấu, không trùng với phần đã lấy
    seen = {t["trace_id"] for t in picked}
    bad = [t for t in traces if is_bad(t) and t["trace_id"] not in seen]
    picked += [dict(t, source="bad_signal", bucket=bucket_of(t["query"]))
               for t in rng.sample(bad, min(n_bad, len(bad)))]
    return picked

3.4Bước 1b — Query tổng hợp: dimension → tuple → query

Chưa có trace thật (app mới, hoặc tính năng mới)? Tạo bộ query tổng hợp, chạy app trên đó để sinh trace. Sai lầm phổ biến mà sách cảnh báo: bảo thẳng LLM "sinh N query cho app của tôi". Kết quả là các biến thể na ná nhau, cùng test một năng lực, không bao giờ chạm tới case mơ hồ hay ngoài phạm vi — và trace sinh ra cũng na ná nhau, che mất những lỗi chỉ xuất hiện ở điều kiện khác.

Cách tốt hơn là thêm một lớp gián tiếp: (1) định nghĩa các dimension — trục mà các yêu cầu khác nhau; (2) sinh các tuple — mỗi tuple chọn một giá trị từ mỗi dimension; (3) từ mỗi tuple mới sinh một query ngôn ngữ tự nhiên, bằng một lời gọi LLM riêng. Tách "sinh tuple" khỏi "sinh query" buộc bộ dữ liệu đa dạng một cách có kiểm soát.

Chọn dimension: trục nơi app dễ hỏng

Dimension tốt mô tả nơi app có khả năng hỏng. Muốn tìm ra chúng: nói chuyện với PM, đọc phản hồi người dùng, tự dùng app, hoặc nhờ vài người dùng thử và để lỗi của họ gợi ý dimension. Không cần liệt kê đủ mọi dimension trước khi bắt đầu — có ba dimension đủ đa dạng là sinh dữ liệu được, thêm dần sau.

Từ tuple đến query

Sách gợi ý: tự viết tay khoảng 20 tuple để thấm không gian bài toán (hỏi chuyên gia hoặc đọc query thật nếu bí), rồi dùng LLM scale lên ≥ 100. Một số người thích 10–20 query được chăm chút kỹ và làm giàu dần theo thời gian — cũng ổn nếu dùng làm nền cho cải tiến liên tục chứ không phải test một lần. Sau khi sinh, lọc chất lượng mạnh tay: query gượng gạo hay lệch mục tiêu → vứt, sinh lại; mọi bước sau phụ thuộc vào độ "thật" của bộ này.

# tuples.py — sinh tuple có luật loại trừ + kiểm tra độ phủ (code minh hoạ, tự viết)
import itertools, random
from collections import Counter

DIMS = {
    "feature":  ["tìm nhà", "phân tích thị trường", "xếp lịch", "soạn email"],
    "persona":  ["mua lần đầu", "nhà đầu tư", "hạng sang"],
    "scenario": ["rõ ràng", "mơ hồ", "ngoài phạm vi"],
}
# tổ hợp vô nghĩa hoặc không muốn test (ví dụ: giả định của team)
EXCLUDE = [{"feature": "phân tích thị trường", "persona": "mua lần đầu", "scenario": "ngoài phạm vi"}]

def excluded(t: dict) -> bool:
    return any(all(t[k] == v for k, v in rule.items()) for rule in EXCLUDE)

def make_tuples(n: int, seed: int = 7):
    keys = list(DIMS)
    all_t = [dict(zip(keys, combo)) for combo in itertools.product(*DIMS.values())]
    valid = [t for t in all_t if not excluded(t)]
    rng = random.Random(seed)
    picked = rng.sample(valid, min(n, len(valid)))
    return all_t, valid, picked

all_t, valid, picked = make_tuples(20)
print(len(all_t), "tổ hợp,", len(valid), "hợp lệ,", len(picked), "được chọn")
for dim in DIMS:                      # mỗi giá trị có xuất hiện ít nhất 1 lần không?
    c = Counter(t[dim] for t in picked)
    missing = [v for v in DIMS[dim] if c[v] == 0]
    print(f"{dim:9s}", dict(c), "THIẾU:" if missing else "", missing or "")

Bước kế tiếp (không in ở đây): với mỗi tuple, gọi LLM với một prompt mô tả app, nêu rõ ba giá trị của tuple, cho 1–2 query mẫu do bạn viết, và yêu cầu viết một query mới mà người dùng thật có thể gõ — đúng mức độ mơ hồ mà tuple chỉ định. Lưu cả tuple lẫn query để về sau có thể cắt tỷ lệ lỗi theo từng dimension (mục 3.7).

Cuối cùng, chạy từng query end-to-end và xuất toàn bộ trace (mọi bước LLM, tool call, input, output). Với bộ trace trong tay, bạn sẵn sàng đọc.

3.5Bước 2 — Open coding: đọc và ghi chú tự do

Quy trình gán nhãn của sách gồm hai bước mượn từ nghiên cứu định tính (grounded theory — dùng một cách thực dụng, không theo đầy đủ phương pháp luận): open coding (đọc trace, ghi quan sát tự do) rồi axial coding (gom quan sát thành category có cấu trúc). "Coding" ở đây đơn giản là gắn nhãn mô tả ngắn cho phần dữ liệu có vẻ quan trọng. Tinh thần: để category tự nổi lên từ những gì thực sự thấy, thay vì bắt đầu bằng một danh sách có sẵn.

1. Đứng ở vị trí người dùngHọ có được phục vụ tốt không? Câu trả lời có giải quyết đúng yêu cầu? Chỉ ghi nhận cái sai — chưa đoán nguyên nhân, chưa nghĩ cách sửa.
2. Ghi lỗi đầu tiênThường là điểm sai xa nhất về phía thượng nguồn; nó hay kéo theo cả chuỗi lỗi phía sau, và sửa nó thường giải quyết cả chuỗi. Ghi lỗi đầu tiên nhanh hơn và tránh việc liệt kê từng triệu chứng.
3. Viết ngắn nhưng đủ ngữ cảnhChữ thường, không cần trau chuốt, một cụm từ hoặc một-hai câu — nhưng đồng đội đọc phải hiểu mà không cần mở lại trace.
4. Thêm phán quyết nhị phânCột "chấp nhận được / không". Buộc chọn phe (kể cả case lưng chừng) sắc hơn điểm số mơ hồ và giúp làm rõ bạn coi cái gì là lỗi.
5. Bí thì dùng "lăng kính"Tạm nhìn top-down qua các loại lỗi LLM phổ biến (vd. hallucination — thông tin không có căn cứ trong input nhưng được nói như sự thật) hoặc lỗi đặc thù domain (text-to-SQL: join sai; bot CSKH: trái chính sách). Mục đích là giúp nhìn ra, không phải ép trace vào khung.
6. Dừng khiđã gán ≥ 20 trace có vấn đề và lỗi mới không còn xuất hiện.

Bảng ghi chép tối giản: ID trace · trace (hoặc tóm tắt) · ghi chú lỗi đầu tiên · Đạt/Không đạt. Sách minh hoạ bằng các quan sát điển hình ở trợ lý CRM — diễn giải ngắn: SQL rơi mất một điều kiện người dùng nói rõ; đề xuất giờ xem nhà vào khung lịch đã bận; email cho nhà đầu tư nhưng giọng như viết cho người mua lần đầu; mô tả số phòng trái với listing vừa lấy về; gửi nhầm người nhận; địa danh trùng tên bị tự chọn âm thầm; đưa giá đề nghị mà không tra dữ liệu so sánh; phớt lờ lỗi tool rồi bịa kết quả; "tóm tắt nhanh" nhưng trả lời rất dài; được bảo soạn lại gửi luôn. Lưu ý: đó chưa phải category — chỉ là quan sát thô; có cái sẽ gộp chung, có cái đứng riêng.

3.6Bước 3 — Axial coding: cấu trúc hoá thành failure mode

Open coding cho một đống quan sát quý nhưng rời rạc. Axial coding là bước tìm quan hệ giữa các ghi chú và gom chúng thành nhóm cấp cao — các kiểu lỗi tách biệt, lặp lại. Có nhóm hiện ra ngay (bỏ qua ngân sách, bỏ sót số phòng ngủ → vi phạm ràng buộc người dùng). Có nhóm chỉ lộ sự khác biệt sau khi đọc nhiều: bịa đặc điểm căn nhà và bịa hành động của khách nghe như cùng là "bịa", nhưng nguyên nhân khác (một cái bịa chi tiết không có trong dữ liệu listing, một cái hiểu sai/bịa ý định người dùng) và cách sửa khác → tách thành hai mode. Đây chỉ là lượt đầu; gộp/tách lại sau là bình thường.

Codebook: viết định nghĩa đủ để người khác áp dụng

Mỗi mode nên có: tên ngắn, định nghĩa một dòng, tính khi / không tính khi (ranh giới), và 1–2 trace ví dụ. Sách lưu ý cuối axial coding bạn phải có danh sách mode tách biệt kèm ví dụ đại diện — chúng là điểm tham chiếu cho bước gán nhãn. Mẫu codebook tự viết:

# codebook.py — codebook + kiểm tra nhất quán nhãn (code minh hoạ, tự viết)
CODEBOOK = {
    "constraint":   "Kết quả không thoả điều kiện người dùng đã nói rõ",
    "fake_listing": "Nêu thuộc tính căn nhà trái với / không có trong dữ liệu tool",
    "fake_action":  "Thực hiện/khẳng định hành động người dùng không yêu cầu",
    "persona_tone": "Giọng/nội dung lệch persona khách",
    "ambiguity":    "Có ≥2 cách hiểu hợp lý nhưng agent tự chọn không hỏi lại",
    "tool_ignored": "Phớt lờ kết quả hoặc lỗi trả về từ tool",
}

def check(rows):
    """rows: list of dict {trace_id, verdict, labels: set[str]} → danh sách vấn đề."""
    problems = []
    for r in rows:
        unknown = r["labels"] - CODEBOOK.keys()
        if unknown:
            problems.append((r["trace_id"], f"nhãn lạ {unknown} — thêm vào codebook hay gõ nhầm?"))
        if r["verdict"] == "fail" and not r["labels"]:
            problems.append((r["trace_id"], "Không đạt nhưng chưa gán mode nào → taxonomy thiếu mode?"))
        if r["verdict"] == "pass" and r["labels"]:
            problems.append((r["trace_id"], "Đạt nhưng có nhãn lỗi → xem lại phán quyết"))
    return problems

rows = [{"trace_id": "tr-017", "verdict": "fail", "labels": {"ambiguity"}},
        {"trace_id": "tr-021", "verdict": "fail", "labels": set()},
        {"trace_id": "tr-030", "verdict": "pass", "labels": {"tone"}}]
for p in check(rows):
    print(*p)

Hai dòng "vấn đề" mà code này bắt được chính là hai tín hiệu quan trọng nhất của vòng tinh chỉnh: trace Không đạt nhưng không khớp mode nào (taxonomy thiếu) và nhãn không có trong codebook (định nghĩa trôi dạt).

LLM được giúp ở đâu — và không ở đâu

3.7Bước 4 — Gán nhãn có cấu trúc & đếm

Lúc này bạn có hai thứ: bộ trace kèm ghi chú open coding, và danh sách failure mode từ axial coding. Bước tiếp theo nối định tính sang định lượng: đi lại từng trace, đối chiếu ghi chú với danh sách mode, đánh dấu mode nào áp dụng. Nếu bạn tự làm axial coding thì chỉ là áp lại ánh xạ vừa xây; nếu LLM đã giúp gom nhóm thì phải bảo đảm các nhóm đó được áp nhất quán — làm tay, hoặc đưa ghi chú + danh sách mode cho LLM gán rồi rà lại.

Trong spreadsheet: mỗi mode một cột, mỗi trace đánh 1/0. Một trace có thể dính nhiều mode. Prevalence = số trace có mode ÷ tổng số trace — tính bằng công thức spreadsheet, pivot table hoặc Pandas (để cắt theo dimension). Gặp trace không khớp mode nào, hoặc mode cần tách → cứ chỉnh định nghĩa.

# prevalence.py — đếm prevalence, cắt theo dimension, khoảng tin cậy Wilson (minh hoạ, tự viết)
import math
import pandas as pd

def wilson(k: int, n: int, z: float = 1.96):
    if n == 0:
        return (0.0, 0.0)
    p = k / n
    denom = 1 + z * z / n
    center = (p + z * z / (2 * n)) / denom
    half = z * math.sqrt(p * (1 - p) / n + z * z / (4 * n * n)) / denom
    return (max(0.0, center - half), min(1.0, center + half))

df = pd.read_csv("labeled_traces.csv")        # cột: trace_id, scenario, source, ...
MODES = ["constraint", "fake_listing", "fake_action", "persona_tone", "ambiguity", "tool_ignored"]

est = df[df["source"] == "strat"]             # chỉ phần lấy mẫu phân tầng để ước lượng tỷ lệ
rows = []
for m in MODES:
    k, n = int(est[m].sum()), len(est)
    lo, hi = wilson(k, n)
    rows.append({"mode": m, "k": k, "n": n, "prev": k / n, "ci95": f"[{lo:.0%}, {hi:.0%}]"})
print(pd.DataFrame(rows).sort_values("prev", ascending=False).to_string(index=False))

# Lỗi tập trung ở đâu? cắt theo dimension của tuple (dùng toàn bộ mẫu, chỉ để khám phá)
print(df.groupby("scenario")[MODES].mean().round(2))

Từ con số tới ưu tiên

Sách nói prevalence cho biết lỗi nào phổ biến nhất — hữu ích để quyết định dồn công vào đâu. Trong thực tế, người tóm tắt khuyên kết hợp thêm mức nghiêm trọng: một lỗi hiếm nhưng không đảo ngược được (gửi email thật cho khách) có thể đáng sửa trước một lỗi phổ biến nhưng vô hại (trả lời hơi dài).

3.8Bước 5 — Lặp, bão hoà & gán nhãn đầy đủ

Error analysis không làm một lần. Thường có 2–3 vòng đọc trace và tinh chỉnh taxonomy; vòng sau hay lộ lỗi chưa thấy (sách lấy ví dụ: trợ lý hiểu nhầm địa danh trùng tên sang một nơi khác mà không hỏi lại → thêm mode "mơ hồ địa danh"). Tinh chỉnh có bốn dạng:

• Thực tế, khoảng 2 vòng nghiêm túc open coding + gán nhãn lại là đủ để tiến gần bão hoà với cùng bộ dữ liệu; phân tích tiếp trên dữ liệu cũ cho lợi ích giảm dần.
• Nhưng phải quay lại định kỳ với dữ liệu mới: sau khi sửa lỗi, mở rộng tới nhiều người dùng hơn, hay khi hành vi người dùng đổi. Giá trị nằm ở việc nhìn hệ thống hiện tại, không phải nghiền một bộ dữ liệu tĩnh.
• Làm nhiều sẽ nhanh: có trực giác nên nhìn vào đâu, taxonomy ổn định, gán nhãn thành thói quen — có người còn ghi mọi lỗi ngay khi open coding vì đã đủ nhanh.

Giới hạn của "chỉ ghi lỗi đầu tiên"

Ghi lỗi đầu tiên giúp gán nhãn nhanh, nhưng sách chỉ ra nó đếm thiếu những mode hay xuất hiện muộn trong trace — vd. sai giọng thường đi sau một lỗi ràng buộc, nên hiếm khi được ghi là "đầu tiên". Hệ quả: khó đo tác động của bản sửa. Nếu bạn sửa mode "sai giọng" mà trước đó chỉ ghi được vài trace, bạn không biết bản sửa có hiệu quả không. Cách xử lý: khi muốn đo một bản sửa, quay lại gán nhãn đầy đủ mọi lần xuất hiện của riêng mode đang sửa/theo dõi — không cần làm với mọi mode.

# saturation.py — kiểm tra bão hoà từ log gán nhãn theo thứ tự đọc (minh hoạ, tự viết)
def saturation_point(first_modes, window=20):
    """first_modes: list mode (hoặc None nếu Đạt) theo đúng thứ tự đã đọc.
    Trả về chỉ số trace mà tại đó đã có `window` trace liên tiếp không lộ mode mới."""
    seen, streak = set(), 0
    for i, m in enumerate(first_modes, start=1):
        if m is not None and m not in seen:
            seen.add(m)
            streak = 0
        else:
            streak += 1
        if streak >= window:
            return i, sorted(seen)
    return None, sorted(seen)

log = ["constraint", None, "fake_listing", None, "constraint", "tone", None, "ambiguity"] + \
      [None, "constraint", "tone", None, "fake_listing"] * 5
print(saturation_point(log))   # → (28, [...4 mode...]) với log minh hoạ này

3.9Case study: một vòng error analysis trọn vẹn trên 20 trace

3.10Bẫy thường gặp

Sách nói không có một cách "đúng" duy nhất để làm error analysis, nhưng có rất nhiều cách sai. Mỗi bẫy dưới đây kèm một mini-ví dụ tự viết:

• Dữ liệu không đại diện — bộ query không phản ánh độ đa dạng và độ khó của người dùng thật → hoặc không lỗi nghiêm trọng nào lộ ra, hoặc lộ lỗi không giống production. Ví dụ: team test 100 query tiếng Việt chuẩn, nhưng 35% người dùng thật gõ không dấu và viết tắt ("can ho 2pn q7 duoi 3ty").
• Bỏ qua open coding, dùng nhãn chung chung ("hallucination", "instruction following", "verbosity") hoặc metric bán sẵn của vendor — nghe hợp lý nhưng bỏ sót lỗi đặc thù gây hại thật (đề xuất giờ xem nhà không trống, nhầm persona khách). Ví dụ: dashboard báo "faithfulness 0,91" trong khi bot vẫn đọc thông tin đơn của khách khác (case study C17) — không metric chung nào hỏi câu đó.
• Thang Likert 1–5 không có rubric chi tiết — nhiễu, người chấm ít đồng thuận. Quyết định nhị phân theo từng failure mode tái lập tốt hơn. Ví dụ (số minh hoạ): hai người chấm 20 trace, Likert "độ hữu ích" trùng khớp chính xác 7/20; cùng 20 trace với câu hỏi "có vi phạm ràng buộc không?", trùng 18/20.
• Đóng băng taxonomy quá sớm — hạ tầng eval bị khoá quanh một hiểu biết chưa đầy đủ. Ví dụ: xây 6 LLM-judge theo taxonomy v1, vòng 2 tách "vi phạm ràng buộc" thành cứng/mềm → phải viết lại judge và gán nhãn lại dữ liệu hiệu chỉnh.
• Loại chuyên gia domain khỏi việc gán nhãn — nhãn hời hợt hoặc sai. Tool annotate cồng kềnh với họ? Đầu tư giao diện đơn giản hơn (chương 10). Ví dụ: kỹ sư đánh "Đạt" cho email báo "căn sổ hồng riêng" — môi giới biết ngay căn đó chỉ có hợp đồng mua bán, một lỗi pháp lý nghiêm trọng.
• Nhờ LLM sinh taxonomy từ đầu — ra nhãn chung chung, lệch phân bố lỗi thật; có team mất hàng tháng xây trên nền đó.
• (Thêm của người tóm tắt) Lấy tỷ lệ trên mẫu săn lỗi làm tỷ lệ production — xem mục 3.3 và case study.
• (Thêm của người tóm tắt) Sửa lỗi ngay trong lúc open coding — mỗi lần thấy lỗi lại nhảy vào sửa prompt khiến bạn không bao giờ đọc hết mẫu và không có bức tranh tần suất; ghi lại, sửa sau.

3.11Đầu ra của pha Analyze & kết nối các chương

Taxonomy là từ vựng chung của team để nói về cách hệ thống hỏng, và nó dẫn dắt mọi quyết định ở pha Measure và Improve. Nếu taxonomy không khớp lỗi người dùng thật gặp, mọi evaluator xây trên nó sẽ đo sai thứ.

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

Hệ thống của bạn nhận mỗi request LLM và quyết định gửi tới model nào (rẻ/nhanh vs mạnh/đắt), cân bằng chất lượng – chi phí – độ trễ. Cám dỗ lớn nhất là nhảy thẳng vào metric ("accuracy của router", "tiết kiệm 40% cost"). Chương 3 bảo: đọc trace routing trước, để biết router hỏng theo những kiểu nào — vì mỗi kiểu hỏng cần một metric và một cách sửa khác nhau.

Bước 1 — Định nghĩa "trace" của router

Trace routing phải đủ để một người đọc trả lời được "quyết định này đúng không, và nếu sai thì sai ở bước nào". Tối thiểu:

{"trace_id": "rt-0412",
 "request": {"text": "Tóm tắt hợp đồng đính kèm, nêu rủi ro", "tokens_in": 182000,
             "sla_ms": 20000, "caller": "legal-app"},
 "features": {"lang": "vi", "task": "summarize", "len_bucket": "xl", "has_code": false},
 "router": {"version": "r-2.3", "difficulty": 0.58,
            "candidates": {"nano": 0.21, "mid": 0.64, "frontier": 0.59}, "chosen": "mid"},
 "calls": [{"model": "mid", "ctx_limit": 128000, "truncated": true,
            "latency_ms": 9100, "cost_usd": 0.19, "status": "ok"}],
 "output": "…bản tóm tắt…",
 "shadow": {"frontier": {"verdict": "pass", "cost_usd": 1.84}},
 "feedback": {"thumbs": "down"}}

Hai trường hay bị quên: truncated (nhiều SDK cắt context âm thầm) và shadow — kết quả của model không được chọn trên cùng request, chỉ cần cho mẫu trace dùng để phân tích.

Bước 2 — Bộ trace: production + tổng hợp

• Production: phân tầng theo model được chọn × loại tác vụ (để tier ít được chọn vẫn có mặt), rồi săn tín hiệu xấu riêng của routing: người dùng bấm "regenerate", fallback kích hoạt, cost/request thuộc top 1%, latency vượt SLA, điểm router nằm sát ngưỡng (±0,03).
• Tổng hợp: dimension gợi ý — loại tác vụ (chat, code, tóm tắt, suy luận, trích xuất, dịch), độ khó thật (dễ / khó / gài bẫy "ngắn mà khó", "dài mà dễ"), độ dài context (<4k / 4–32k / 32–128k / >128k), ràng buộc (ưu tiên rẻ / nhanh / chất lượng), ngôn ngữ (vi có dấu / không dấu / en / trộn). Thử preset "model-routing" ở LAB 2.
• Shadow replay: chạy mỗi trace mẫu thêm trên 1–2 model khác và chấm Đạt/Không đạt (người chấm, hoặc sau này judge đã hiệu chỉnh) — đây là "sự thật" để nói under/over-route.

Bước 3 — Open coding các quyết định route

Bước 4 — Axial coding → taxonomy routing v1

Chú ý cặp "under-route": sách nhấn mạnh tách khi cách chẩn đoán/sửa khác nhau — ở đây một cái sửa bộ ước lượng độ khó, cái kia cần luật theo domain. Gộp thành "under-route" chung sẽ khiến bạn sửa sai chỗ.

Bước 5 — Đếm và biến thành metric

Nhãn 0/1 theo từng mode cho ra prevalence như mọi app khác. Với routing, hai mode chính còn có thể quy ra tiền và chất lượng nhờ shadow replay:

# routing_analysis.py — phân loại under/over-route từ shadow replay (minh hoạ, tự viết)
TIERS = ["nano", "mid", "frontier"]            # thứ tự tăng dần về năng lực & giá

def classify(t):
    """t: {chosen, verdict: {model: 'pass'|'fail'}, cost: {model: usd}}"""
    ok = [m for m in TIERS if t["verdict"].get(m) == "pass"]
    if not ok:
        return "no_model_passes", 0.0          # không model nào đạt → không phải lỗi router
    cheapest_ok = ok[0]
    chosen = t["chosen"]
    if t["verdict"].get(chosen) != "pass":
        return "under_route", 0.0
    if TIERS.index(chosen) > TIERS.index(cheapest_ok):
        return "over_route", t["cost"][chosen] - t["cost"][cheapest_ok]
    return "ok", 0.0

traces = [
    {"id": "R02", "chosen": "nano", "verdict": {"nano": "fail", "frontier": "pass"},
     "cost": {"nano": 0.0004, "frontier": 0.021}},
    {"id": "R03", "chosen": "frontier", "verdict": {"mid": "pass", "frontier": "pass"},
     "cost": {"mid": 0.0016, "frontier": 0.019}},
    {"id": "R10", "chosen": "frontier", "verdict": {"mid": "fail", "frontier": "pass"},
     "cost": {"mid": 0.004, "frontier": 0.045}},
]
counts, waste = {}, 0.0
for t in traces:
    label, extra = classify(t)
    counts[label] = counts.get(label, 0) + 1
    waste += extra
    print(t["id"], label, f"+${extra:.4f}" if extra else "")
n = len(traces)
print({k: f"{v}/{n}" for k, v in counts.items()}, f"lãng phí ≈ ${waste:.4f}")

Lưu ý verdict thiếu được coi là không biết (không đạt), nên model chưa chạy shadow sẽ không bao giờ được coi là "rẻ hơn mà vẫn đạt" — bảo thủ có chủ đích. Với một mẫu shadow đủ lớn, bạn có ba metric đầu tiên cho benchmark routing: tỷ lệ under-route (mất chất lượng), tỷ lệ over-route + $ lãng phí/1.000 request, và tỷ lệ vi phạm ràng buộc cứng (nên ≈ 0, đo bằng check code).

Bẫy riêng của routing

• Chỉ chấm "model được chọn có trả lời tốt không" — không bao giờ phát hiện over-route (câu trả lời tốt, chỉ là đắt vô ích).
• Dùng leaderboard công khai thay cho open coding — "model X mạnh hơn ở benchmark Y" không nói gì về traffic tiếng Việt, không dấu, pháp lý của bạn.
• Điểm "route tốt 1–5" — thay bằng câu hỏi nhị phân theo từng mode: under? over? vi phạm ràng buộc?
• Bộ tổng hợp toàn câu dễ — router trông tuyệt vời vì 90% request đi nano và đều đạt; phải có tuple "ngắn mà khó" và "dài mà dễ".
• Quên tính không tất định — model đích không tất định, nên một lần shadow "fail" có thể là xui; với trace sát ranh giới, chạy 3 lần.
• Đóng băng taxonomy khi thêm model mới vào pool — mỗi model mới có thể mang theo mode mới (vd. từ chối quá mức, format JSON khác).

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, trace, case study, code và lab do người tóm tắt tự viết để minh hoạ. Trích nguyên văn: 1 câu (đã đánh dấu). Nguồn: Evals for AI Engineers — Shreya Shankar & Hamel Husain, O'Reilly (Early Release).