Giới thiệu: Ba Vực thẳm & vòng lặp Analyze–Measure–Improve

Một phòng khám tư dùng bot chat để đặt lịch. Tuần đầu nhận 6 bug report. Ta tách xem cái nào thuộc tầng agent (sách quan tâm) và cái nào thuộc application:

1. Hỏi: nếu thay LLM bằng một người thật đọc cùng context, lỗi còn xảy ra không? Nếu còn (bug 2, 4, 6) → gần như chắc là tầng application.
2. Hỏi: LLM có nhận đủ thông tin đúng không? Có mà vẫn sai (bug 1, 3, 5) → tầng agent.
3. Cẩn thận với "triệu chứng ở chỗ khác": bug 5 làm backend crash, nhưng nguyên nhân gốc là output của agent.
4. Kết quả: 3/6 bug thuộc phạm vi eval của sách. 3 cái còn lại xử lý bằng test UI, load test, test tích hợp API.

Prompt: Tóm tắt email sau cho quản lý. — email khách xin báo giá 200 áo đồng phục, cần trước thứ 6, hỏi thêm có in logo không.

1. Unit test kiểu assert out == "Khách cần báo giá..." sẽ fail ở lần 2 dù output tốt → assert chuỗi chính xác vô dụng.
2. Lần 4 chỉ phát hiện được nếu ai đó (người hoặc evaluator) hiểu ngữ nghĩa: "hỏi" ≠ "đồng ý".
3. Lần 3 không sai sự thật; nó sai kỳ vọng — mà kỳ vọng ("ngắn, cho quản lý đọc lướt") chưa hề được viết ra.
4. Vậy "test" LLM app cần: đo trên nhiều input và nhiều lần chạy, với tiêu chí dạng thuộc tính ("không bịa cam kết", "≤ 2 câu") thay vì so khớp chuỗi.

Giả sử bạn là kỹ sư của một hãng bay (hư cấu) sắp ra mắt bot. Làm thế nào để có "một bộ check câu hỏi chính sách" trong một buổi chiều?

1. Lấy câu hỏi thật: xuất 3 tháng ticket tổng đài, lọc ra 20 chủ đề chính sách hỏi nhiều nhất (hành lý, đổi vé, hoàn vé, vé tang lễ, trẻ em đi một mình…).
2. Viết đáp án chuẩn dạng thuộc tính với chuyên gia chính sách: mỗi câu có danh sách cụm phải có và cụm không được có (ví dụ: vé tang lễ → phải có "trước chuyến bay", không được có "sau chuyến bay").
3. Diễn đạt lại mỗi câu 3–5 kiểu (không dấu, tiếng Anh, viết sai chính tả, hỏi vòng vo) vì khách thật không hỏi theo FAQ.
4. Chạy bot, chấm tự động bằng code đơn giản dưới đây; câu nào FAIL thì người đọc lại trace.
5. Chặn launch nếu có bất kỳ FAIL nào ở nhóm "chính sách tiền bạc" — stakes cao, sai một lần cũng đắt.

# policy_eval.py — dữ liệu & câu trả lời đều là minh hoạ
CASES = [
    {"id": "P1", "q": "Bay dự đám tang có được giảm giá vé không?",
     "must": ["trước chuyến bay"], "must_not": ["sau chuyến bay", "hoàn lại sau"]},
    {"id": "P2", "q": "Hành lý xách tay tối đa bao nhiêu kg?",
     "must": ["7 kg"], "must_not": ["10 kg"]},
    {"id": "P3", "q": "Đổi tên hành khách trên vé được không?",
     "must": ["không được đổi tên"], "must_not": ["đổi tên miễn phí"]},
]
ANSWERS = {  # output thu được khi chạy bot (giả lập)
    "P1": "Bạn cứ mua vé thường, rồi xin hoàn lại sau chuyến bay trong 90 ngày.",
    "P2": "Hành lý xách tay tối đa 7 kg, kích thước 56x36x23 cm.",
    "P3": "Rất tiếc, vé không được đổi tên, bạn cần mua vé mới.",
}

def check(case, answer):
    a = answer.lower()
    missing = [m for m in case["must"] if m.lower() not in a]
    forbidden = [f for f in case["must_not"] if f.lower() in a]
    return (not missing and not forbidden), missing, forbidden

fails = 0
for c in CASES:
    ok, missing, forbidden = check(c, ANSWERS[c["id"]])
    fails += not ok
    print(f"{c['id']} {'PASS' if ok else 'FAIL'}  thiếu={missing} cấm={forbidden}")
print(f"Tỉ lệ đạt: {len(CASES) - fails}/{len(CASES)}")

P1 FAIL  thiếu=['trước chuyến bay'] cấm=['sau chuyến bay', 'hoàn lại sau']
P2 PASS  thiếu=[] cấm=[]
P3 PASS  thiếu=[] cấm=[]
Tỉ lệ đạt: 2/3

Check dạng từ khoá rất thô (bot có thể nói "trước chuyến bay" trong câu phủ định), nhưng nó đủ để đẩy P1 tới mắt người trước khi đến tay khách. Evaluator tinh hơn (LLM-as-judge có rubric) là chủ đề Chương 5.

1. Bắt đầu từ việc đọc ~50 lịch trình thật để thấy các kiểu hỏng (định tính).
2. Mỗi kiểu hỏng thành một check riêng, có thể là code (tổng giá ≤ ngân sách) hoặc judge (hợp lý về di chuyển).
3. Báo cáo tỉ lệ theo từng kiểu hỏng (định lượng) → ưu tiên sửa theo tỉ lệ × mức nghiêm trọng.

Evaluator: "output JSON hợp lệ, có sender và requests không rỗng". Cùng một hàm check có thể được dùng theo cả 4 cách:

1. Guardrail: chạy ngay sau mỗi lần gọi LLM; fail thì retry, fail tiếp thì fallback "chuyển người xử lý".
2. Monitoring: log kết quả check; dashboard tỉ lệ fail theo ngày. Tỉ lệ nhảy từ 1% lên 6% sau một đợt email marketing mới → drift.
3. Improvement: gom các input làm fail thành bộ ví dụ khó; chọn vài cái làm few-shot hoặc dữ liệu fine-tune.
4. Model migration: nhà cung cấp ra model mới rẻ hơn 40% — chạy cả hai trên 1.000 email lưu sẵn, so tỉ lệ fail trước khi chuyển.

# guardrail.py — call_llm là giả lập: lần 1 trả JSON hỏng, lần 2 trả đúng
import json

def call_llm(prompt, attempt):
    return '{"sender": "Lan", "requests": ["báo giá"' if attempt == 0 else \
           '{"sender": "Lan", "requests": ["báo giá 200 áo trước thứ 6"]}'

def valid(output):
    """Evaluator dạng code: parse được JSON + đủ field + requests không rỗng."""
    try:
        data = json.loads(output)
    except json.JSONDecodeError:
        return False, "json_invalid"
    if not data.get("sender") or not data.get("requests"):
        return False, "missing_field"
    return True, "ok"

def guarded_extract(prompt, max_retries=2, log=print):
    for attempt in range(max_retries + 1):
        out = call_llm(prompt, attempt)
        ok, reason = valid(out)
        log(f"attempt={attempt} ok={ok} reason={reason}")   # log → monitoring
        if ok:
            return json.loads(out)
    return {"sender": None, "requests": [], "fallback": "chuyển người xử lý"}

print(guarded_extract("Trích tên người gửi và yêu cầu..."))

attempt=0 ok=False reason=json_invalid
attempt=1 ok=True reason=ok
{'sender': 'Lan', 'requests': ['báo giá 200 áo trước thứ 6']}

Một câu held-out có 5 token. Model A và B gán xác suất cho token đúng ở mỗi vị trí:

1. Lấy −ln từng xác suất của A: 0,693 · 1,386 · 0,223 · 2,303 · 0,511 → tổng 5,116.
2. Chia cho số token: NLL trung bình = 5,116 / 5 ≈ 1,023.
3. Perplexity = e^1,023 ≈ 2,78 — hiểu nôm na: A "phân vân" như đang chọn giữa ~2,8 token mỗi bước.
4. Làm tương tự cho B: ≈ 1,78. B tốt hơn về mô hình hoá ngôn ngữ.
5. Nhưng điều đó không nói B tóm tắt email của bạn tốt hơn, tuân thủ format JSON tốt hơn, hay ít bịa chính sách hơn.

import math
model_A = [0.50, 0.25, 0.80, 0.10, 0.60]
model_B = [0.70, 0.40, 0.90, 0.30, 0.75]

def perplexity(probs):
    nll = -sum(math.log(p) for p in probs) / len(probs)   # NLL trung bình / token
    return math.exp(nll), nll

for name, probs in [("A", model_A), ("B", model_B)]:
    ppl, nll = perplexity(probs)
    print(f"model {name}: NLL/token = {nll:.3f}  perplexity = {ppl:.2f}")
# model A: NLL/token = 1.023  perplexity = 2.78
# model B: NLL/token = 0.574  perplexity = 1.78

Thay vì đọc 5 email mẫu sạch đẹp rồi viết prompt, bạn lấy mẫu email thật và đếm các đặc điểm cấu trúc bằng vài regex rẻ tiền. Mục tiêu không phải đo chất lượng, mà là biết "data trông như thế nào" để không thiết kế cho bài toán tưởng tượng.

1. Lấy mẫu ngẫu nhiên (ở đây 8 email cho gọn; thực tế vài trăm).
2. Liệt kê các đặc điểm nghi ngờ gây khó: forward, thread trích dẫn, chữ ký/disclaimer, tiếng Anh, rác từ PDF, nhiều yêu cầu trong một email.
3. Đếm tỉ lệ. Đặc điểm nào ≥ 10% thì prompt phải xử lý tường minh và bộ test phải có đại diện.
4. Đọc kỹ vài email của mỗi nhóm — con số chỉ chỉ đường, không thay việc đọc.

import re
from collections import Counter

EMAILS = [  # 8 email giả lập
    "Chào anh, em cần báo giá 200 áo đồng phục trước thứ 6. Cảm ơn, Lan",
    "---------- Forwarded message ----------\nFrom: Minh\nNhờ chị xử lý giúp đơn #8812",
    "Dạ em gửi lại hợp đồng.\n\n> On Mon, Hùng wrote:\n> Anh gửi bản nháp\n> > Em xem nhé",
    "Hi team, please confirm the invoice.\n--\nJohn Tran | Sales\nCONFIDENTIAL: This email is intended only for the recipient",
    "Anh ơi hủy giúp em đơn hôm qua",
    "Kính gửi Quý công ty,\nChúng tôi đề nghị hợp tác... (dán từ PDF)  Trang 1/3   Điều 1.1",
    "Re: Re: Re: lịch họp\n> > > thứ 3 được không\n> > được\n> ok chốt",
    "Gửi bộ phận CSKH: sản phẩm bị lỗi, tôi muốn đổi trả và được hoàn tiền phí ship",
]
FEATURES = {
    "forwarded": lambda e: "forwarded message" in e.lower(),
    "quoted_thread": lambda e: bool(re.search(r"^>", e, re.M)),
    "signature_or_disclaimer": lambda e: bool(re.search(r"^--\s*$|confidential", e, re.M | re.I)),
    "english": lambda e: bool(re.search(r"\b(please|the|hi)\b", e, re.I)),
    "pdf_artifact": lambda e: bool(re.search(r"Trang \d+/\d+|Điều \d", e)),
    "multi_request": lambda e: len(re.findall(r"\b(và|muốn|cần|nhờ)\b", e, re.I)) >= 2,
}
counts = Counter()
for e in EMAILS:
    for name, fn in FEATURES.items():
        counts[name] += fn(e)
print(f"{'đặc điểm':<26}{'số email':>9}{'tỉ lệ':>8}")
for name in FEATURES:
    print(f"{name:<26}{counts[name]:>9}{counts[name] / len(EMAILS):>8.0%}")

đặc điểm                   số email   tỉ lệ
forwarded                         1     12%
quoted_thread                     2     25%
signature_or_disclaimer           1     12%
english                           1     12%
pdf_artifact                      1     12%
multi_request                     1     12%

Kết luận (trên data minh hoạ): 1/4 email có thread trích dẫn → prompt phải nói rõ "chỉ tóm tắt tin nhắn mới nhất, bỏ phần trích dẫn", và bộ test phải có loại email này. Đây là cầu nối từ Comprehension sang Specification.

Prompt v1: Trích tên người gửi và tóm tắt yêu cầu trong email. Ta liệt kê mọi quyết định mà v1 để model tự đoán, rồi trả lời từng cái dựa trên data đã profile ở Ví dụ 1.7:

1. Mỗi dòng bảng là một quyết định sản phẩm, không phải chi tiết kỹ thuật — nên hỏi PM/chuyên gia domain khi không chắc.
2. Spec phải bám data: dòng "thread trích dẫn" chỉ xuất hiện vì profile cho thấy 25% email có thread.
3. Sau khi sửa, output khác format giữa các lần chạy gần như biến mất — dấu hiệu lỗi cũ là specification, không phải generalization.

Sau khi spec đã ghi "bỏ hoàn toàn chữ ký/disclaimer", bạn vẫn thấy vài tóm tắt có câu "CONFIDENTIAL…". Prompt rõ ràng rồi → nghi generalization. Câu hỏi bây giờ là bao thường xuyên.

1. Viết evaluator rẻ: tìm các cụm boilerplate trong tóm tắt (code, không cần LLM).
2. Chạy trên 2.000 output (ở đây giả lập với tỉ lệ thật ~8%).
3. Báo cáo tỉ lệ kèm khoảng tin cậy (Wilson 95%) để biết con số chắc cỡ nào.
4. So với việc chỉ đọc 10 trace và thấy 2 lỗi: ước lượng "20%" nhưng khoảng tin cậy trải từ ~6% đến ~51% — gần như vô nghĩa.

import math, random

def wilson(k, n, z=1.96):
    """Khoảng tin cậy 95% Wilson cho tỉ lệ lỗi k/n."""
    if n == 0:
        return (0.0, 1.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)

BOILERPLATE = ["confidential", "intended only for", "sent from my iphone", "bảo mật"]

def has_boilerplate(summary: str) -> bool:
    s = summary.lower()
    return any(b in s for b in BOILERPLATE)

random.seed(7)   # giả lập 2.000 tóm tắt, ~8% bị lọt disclaimer
summaries = [
    "Khách xin báo giá 200 áo. CONFIDENTIAL: intended only for recipient"
    if random.random() < 0.08 else "Khách xin báo giá 200 áo trước thứ 6."
    for _ in range(2000)
]
k = sum(has_boilerplate(s) for s in summaries)
lo, hi = wilson(k, len(summaries))
print(f"Lỗi boilerplate: {k}/{len(summaries)} = {k/len(summaries):.1%}  (95% CI {lo:.1%}–{hi:.1%})")
lo, hi = wilson(2, 10)
print(f"Chỉ 10 trace, 2 lỗi: 20%  (95% CI {lo:.1%}–{hi:.1%})")

Lỗi boilerplate: 180/2000 = 9.0%  (95% CI 7.8%–10.3%)
Chỉ 10 trace, 2 lỗi: 20%  (95% CI 5.7%–51.0%)

Khi biết lỗi ~9% và ổn định, bạn có cơ sở để chọn can thiệp mạnh hơn — ví dụ đổi kiến trúc: cắt chữ ký bằng code trước khi đưa email cho LLM, thay vì hi vọng model tự bỏ qua.

1. Analyze — lấy ngẫu nhiên 120 trace của tuần qua, mỗi trace ghi 1 dòng ghi chú tự do ("tóm tắt cả thread cũ", "tên sai: lấy 'Sơn Tùng' trong thân mail", "3 bullet nhưng bỏ mất deadline"…). Gom ghi chú thành 5 failure mode.
2. Phân loại vực — với mỗi mode hỏi "prompt đã nói chưa?": F1 tóm tắt cả thread (spec — chưa nói), F2 format lộn xộn (spec), F3 bỏ sót deadline (spec — chưa nói deadline là bắt buộc), F4 lọt chữ ký (generalization — đã nói), F5 nhầm tên (generalization — đã nói "lấy từ header").
3. Improve lần 1 (spec) — sửa prompt cho F1–F3 ngay, không cần đo trước: nói rõ "chỉ tin mới nhất", "3 bullet", "luôn nêu deadline nếu có".
4. Measure (generalization) — evaluator code cho F4 (tìm cụm boilerplate), F5 (so tên trả về với header From). Trên 2.000 email: F4 = 8,5%, F5 = 1,2%.
5. Improve lần 2 — F4 cao → đổi kiến trúc: cắt chữ ký bằng regex trước khi gọi LLM → đo lại còn 0,6%. F5 → lấy tên từ metadata, LLM không còn quyết định → 0%.
6. Quay lại Analyze — đọc 120 trace mới sau khi sửa: xuất hiện mode mới F6 "email tiếng Anh bị tóm tắt bằng tiếng Anh" (spec chưa nói ngôn ngữ output). Vòng lặp tiếp tục.

# routing_eval.py — mỗi request đã chạy qua CẢ 3 model, có điểm judge (0-1)
PRICE = {"small": 0.2, "medium": 1.0, "large": 5.0}   # $ / 1.000 request (minh hoạ)
QUALITY_BAR = 0.8
DATA = [  # (id, loại, điểm từng model, model router đã chọn)
    ("r1", "chitchat", {"small": 0.95, "medium": 0.96, "large": 0.97}, "small"),
    ("r2", "extract",  {"small": 0.85, "medium": 0.90, "large": 0.92}, "medium"),
    ("r3", "code",     {"small": 0.40, "medium": 0.82, "large": 0.93}, "medium"),
    ("r4", "math",     {"small": 0.30, "medium": 0.55, "large": 0.90}, "medium"),
    ("r5", "summarize",{"small": 0.88, "medium": 0.90, "large": 0.91}, "large"),
    ("r6", "legal",    {"small": 0.20, "medium": 0.60, "large": 0.85}, "large"),
    ("r7", "chitchat", {"small": 0.93, "medium": 0.94, "large": 0.95}, "small"),
    ("r8", "code",     {"small": 0.35, "medium": 0.70, "large": 0.88}, "small"),
]
ORDER = ["small", "medium", "large"]

def oracle(scores):
    ok = [m for m in ORDER if scores[m] >= QUALITY_BAR]
    return ok[0] if ok else max(scores, key=scores.get)

n = len(DATA)
router_q = sum(s[c] for _, _, s, c in DATA) / n
large_q = sum(s["large"] for _, _, s, _ in DATA) / n
router_cost = sum(PRICE[c] for *_, c in DATA)
large_cost = PRICE["large"] * n
under = [r for r, _, s, c in DATA if ORDER.index(c) < ORDER.index(oracle(s))]
over = [r for r, _, s, c in DATA if ORDER.index(c) > ORDER.index(oracle(s))]
below = [r for r, _, s, c in DATA if s[c] < QUALITY_BAR]
print(f"Chất lượng TB  router={router_q:.3f}  always-large={large_q:.3f}  (giữ lại {router_q / large_q:.0%})")
print(f"Chi phí        router=${router_cost:.1f}  always-large=${large_cost:.1f}  (tiết kiệm {1 - router_cost / large_cost:.0%})")
print(f"Under-route: {under}   Over-route: {over}")
print(f"Dưới ngưỡng: {below} = {len(below) / n:.0%}")

Chất lượng TB  router=0.782  always-large=0.914  (giữ lại 86%)
Chi phí        router=$13.6  always-large=$40.0  (tiết kiệm 66%)
Under-route: ['r4', 'r8']   Over-route: ['r2', 'r5']
Dưới ngưỡng: ['r4', 'r8'] = 25%

1. Tiêu đề đẹp: tiết kiệm 66% chi phí, giữ 86% chất lượng. Nếu chỉ nhìn hai số này, dễ kết luận "router tốt".
2. Nhìn theo failure mode: 2/8 request dưới ngưỡng, và cả hai là under-route ở loại toán/code — đúng nhóm người dùng khó tự phát hiện là mình bị hạ cấp.
3. Over-route r2, r5 chỉ tốn tiền (r5 dùng large cho tóm tắt mà small đã đạt 0,88).
4. Phân vực: nếu contract chưa định nghĩa "math" là một loại riêng → r4 là lỗi spec. Nếu đã định nghĩa mà classifier vẫn nhầm → generalization, cần đo trên nhiều request toán hơn (8 request thì CI rất rộng — xem LAB 3).
5. Hành động: ưu tiên giảm under-route cho code/math (stakes cao hơn) trước khi tối ưu over-route.