Phần IV · Production & Improve Chương 12

Cải thiện LLM agent: độ chính xác, chi phí, cascade & routing

Chapter 12 — Improving LLM Agents

TL;DR

  • Không có evaluator + CI thì không biết một thay đổi giúp hay hại. Mọi cải thiện đều qua đo lường.
  • Accuracy trước, cost sau. Accuracy đi theo thang công sức: prompt → kiến trúc → model. Vắt kiệt bậc rẻ trước.
  • Cost: model vừa đủ cho từng bước, cắt token, prompt thân thiện cache, batch việc offline, distillation.
  • Cascade: model rẻ (proxy) trả lời trước, chỉ đẩy lên model đắt (oracle) khi độ tự tin dưới ngưỡng — ngưỡng hiệu chỉnh offline trên tập held-out.
  • Routing: classifier chọn model ngay từ đầu — nhanh hơn, nhưng route sai thì không có cơ hội thứ hai. Kết hợp: router cho ca rõ, cascade cho vùng mơ hồ.

12.1Nguyên tắc: đo rồi mới sửa

📏
Đo trước, sửa sau
evaluators + CI first

Evaluator (Ch.5) và monitoring/CI (Ch.9) là thước đo cho mọi thay đổi ở chương này.

🎯
Accuracy trước
then cost

Chỉ tối ưu chi phí khi chất lượng đã đạt yêu cầu — và kiểm lại chất lượng sau mỗi lần cắt giảm.

🔁
Lỗi dịch chuyển
failure distribution shifts

Sửa lỗi này có thể đẻ ra lỗi khác. Mỗi thay đổi phải chạy lại toàn bộ bộ eval.

Thang công sức cho accuracy

Công sức · dữ liệu · độ khó debug ↑ Đi từ trái sang phải; vắt kiệt bậc rẻ trước. ① Thấp · Prompt sửa spec (thường 1 dòng) few-shot ≠ test case CI persona · CoT / thinking budget cần: vài ví dụ lỗi ② Trung bình · Kiến trúc chia nhỏ tác vụ thành bước RAG: query · chunk · rerank mô tả tool rõ định dạng self-consistency (bỏ phiếu) bước verify · guardrail cần: hiểu pattern lỗi ③ Cao · Model PEFT: LoRA / QLoRA preference tuning: DPO / KTO tối ưu prompt tự động (DSPy · TextGrad · OPRO) vòng review của người distillation (cho cost) cần: 50–500+ ví dụ gán nhãn
Ba bậc cải thiện accuracy. Bậc càng cao càng tốn dữ liệu, hạ tầng và càng khó debug/bảo trì.

12.2Công sức thấp: tinh chỉnh prompt

Sửa lỗi specification trước tiên

Nhiều lỗi thuộc Gulf of Specification: prompt không nói rõ, model đoán hợp lý nhưng sai. Ví dụ Người dùng hỏi "homes gần trung tâm", agent trả cả căn hộ lẫn nhà liền kề — vì prompt không định nghĩa "homes". Thêm một dòng mặc định (homes = nhà riêng, trừ khi người dùng nói khác) là xong.
Sửa spec trước khi xây evaluator: đo khả năng generalize trên một tác vụ chưa định nghĩa rõ là lãng phí.

Mẹo từ tác giả: trước khi viết evaluator nào, lướt 10 trace tệ nhất và tự hỏi prompt có thực sự nói điều mình muốn không. Theo kinh nghiệm của họ, khoảng một nửa lỗi giai đoạn đầu biến mất chỉ với một dòng sửa prompt.

Few-shot có chủ đích
targeted examples

2–3 cặp input/output nhắm vào lỗi đã thấy — nhưng không trùng test case CI, nếu không điểm eval phồng lên mà hành vi thật không đổi.

Few-shot động
dynamic retrieval

Có thư viện ví dụ lớn → mỗi query lấy vài ví dụ giống nhất theo embedding, thay vì nhồi tất cả.

Persona
role-based guidance

"Bạn là cố vấn thuế cẩn trọng" — định hướng giọng và cách suy luận, nhất là với tác vụ mở.

Chain-of-thought
step-by-step

Giúp tác vụ nhiều bước. Với reasoning model (o-series, R1…) thì đừng bảo "think step by step" — chỉnh thinking budget thay vì vậy.

12.3Công sức trung bình: đổi cách agent vận hành

Kỹ thuậtÝ tưởngĐánh đổi / lưu ý
Chia nhỏ tác vụThay một lời gọi làm tất cả bằng chuỗi bước: trích ràng buộc → truy vấn → lọc/tóm tắt → sinh câu trả lờiMỗi bước eval riêng được → lỗi khoanh vùng tới đúng bước
Tinh chỉnh RAGViết lại query, đổi cách chunk, số chunk, thêm reranker nhẹRetrieval thường quyết định chất lượng nhiều hơn generation (đo theo Ch.7)
Sửa mô tả tooldate: string → ghi rõ định dạng YYYY-MM-DD kèm ví dụMột chỗ sửa, hết lỗi tham số cho mọi query đặt lịch
Self-consistencySample nhiều lần (temperature > 0), lấy đáp án đa sốTốn nhiều lời gọi → dành cho quyết định stakes cao
Bước verifyLời gọi thứ hai kiểm output lần một (khớp dữ liệu? đúng persona?)Gấp đôi latency/cost → chỉ cho output quan trọng
GuardrailCheck đồng bộ trước khi tới người dùng: regex bắt chuỗi giống số an sinh xã hội, parser từ chối SQL sai cú phápRẻ, nhanh, chặn những lỗi xấu hổ nhất

Case study: DoorDash — sắp xếp lại thứ model đã có

TRƯỚC Toàn bộ event thô pickup · ping vị trí · chat… nhồi hết vào prompt Chatbot Bịa chính sách hoàn tiền, chi tiết đơn SAU Toàn bộ event thô không đổi Lớp tóm tắt lịch sử liên quan, có cấu trúc Chatbot Hallucination giảm ~90% (mô phỏng)
Không đổi model, không train lại — chỉ đổi cách tổ chức thông tin. Kiểm bằng hàng nghìn hội thoại mô phỏng (một LLM đóng vai tài xế); cải thiện giữ được khi lên production.

12.4Công sức cao: can thiệp ở mức model

Khi nào: có hàng trăm ví dụ chất lượng và prompt không cứu được.

  • LoRA: chỉ train các ma trận adapter hạng thấp thay vì toàn bộ tham số → một GPU (A100/H100), vài giờ.
  • QLoRA: lượng tử hoá base model xuống 4-bit khi train → fine-tune model 70B trên một GPU 48GB.
  • Tác vụ hẹp: thường 50–200 ví dụ tốt đã tạo khác biệt đáng kể.

Chi phí ẩn phải serve model (vLLM/TGI tự host, hoặc Together, Fireworks, Modal). Tiết kiệm từ model nhỏ phải lớn hơn chi phí train + serve + bảo trì.

DPO, KTO: train trên cặp output — một cái được ưa hơn cái kia.

Hợp với lỗi phong cách/chất lượng ("đúng nhưng dài dòng") hơn là lỗi đúng/sai.

Coi prompt là tham số tối ưu được: sinh biến thể, chấm trên golden set held-out, giữ cái tốt nhất. DSPy, TextGrad, OPRO tự động hoá việc tìm kiếm, dùng metric eval (Ch.5) làm hàm mục tiêu.

Điều kiện hàm eval rõ ràng + đủ ví dụ gán nhãn. Tác giả khuyên chờ tới khi đã vắt kiệt các cách nhanh — khó debug, khó bảo trì.

Stakes cao hoặc lỗi khó phát hiện tự động → giao diện gọn (Ch.10) để người review gán nhãn một mẫu nhỏ đều đặn.

Nhãn vừa thành dữ liệu fine-tune, vừa lộ ra failure mode mà evaluator tự động bỏ sót.

12.5Tối ưu chi phí

Cùng công thức như accuracy: tìm nguồn tốn tiền lớn nhất, sửa có mục tiêu, rồi dùng evaluator xác nhận chất lượng không tụt.

⚖️
Model vừa đủ
right-size per step

Model nhỏ cho phân loại intent, trích field, sentiment. Model lớn cho reasoning phức tạp, stakes cao.

✂️
Cắt token
input & output

Instruction gọn; bớt tài liệu RAG; model rẻ tóm tắt tài liệu dài một lần cho nhiều lời gọi sau; output ngắn, định dạng gọn (YAML ít ký tự hơn JSON).

🧊
Prompt thân thiện cache
prefix caching

Phần cố định lên đầu, phần thay đổi xuống cuối (xem sơ đồ dưới).

📦
Batching
offline jobs

Việc không gấp (chạy evaluator cả ngày, chấm dataset CI) → batch API, vd OpenAI rẻ một nửa, trả trong 24h.

🎓
Distillation
teacher → student

Model lớn sinh nhãn trên dữ liệu chưa gán → fine-tune model nhỏ bắt chước.

Vì sao thứ tự trong prompt quyết định cache hit

Provider lưu KV state (key/value mà Transformer tính cho từng token) của các prefix đã gặp. Request mới bắt đầu bằng đúng y hệt chuỗi token đó thì dùng lại, chỉ tính phần đuôi. Anthropic công bố cache hit tốn 10% giá input và giảm tới 85% latency với prompt dài.

← thứ tự token trong prompt → Request 1 Instruction cố định (dài) Query A tính từ đầu, lưu cache Request 2 cache hit — dùng lại KV Query B ✓ chỉ tính phần đuôi Request 3 Query C Instruction (prefix đã lệch) ✗ tính lại toàn bộ
Sơ đồ tự vẽ. Lệch một token — kể cả khoảng trắng hay tên người dùng chèn ở đầu — là mất cache từ vị trí đó trở đi.
  1. Instruction cố định lên trước, dữ liệu người dùng/biến đổi xuống cuối.
  2. Giữ định dạng, cách diễn đạt, khoảng trắng nhất quán giữa các request.
  3. Tra bảng giá cache của providerMức giảm cho token cached khác nhau giữa các nhà cung cấp.

Giới hạn của distillation

Student không vượt teacher và học luôn lỗi của teacher; thường calibration kém trên input hiếm hoặc lệch phân bố (vì chúng ít xuất hiện trong dữ liệu teacher sinh ra). Eval student chặt như mọi thay đổi khác và so hồ sơ lỗi với teacher. Cần hạ tầng serving → hợp với khối lượng lớn; khối lượng nhỏ thì cascade có thể kinh tế hơn vì không phải train/host model riêng.

12.6Model cascade

Bối cảnh Một LLM-as-judge tốn $0.02/trace × 10.000 trace/ngày = $200/ngày. Muốn giữ chất lượng mà chi ít hơn.

Proxy
cheap model

Trả lời trước. Phải cho ra verdict nhị phân + điểm tự tin để đặt ngưỡng.

Oracle
best current system

Không cần hoàn hảo — chỉ là hệ thống tốt nhất hiện có. Cascade cố tái tạo câu trả lời của nó với chi phí gần proxy.

Target accuracy
agreement rate r

Tỷ lệ đồng thuận tối thiểu giữa cascade và oracle, vd 95%. Mục tiêu: đạt r với ít lời gọi oracle nhất.

Query Proxy model rẻ · $ · nhanh conf ≥ t₁ ? có Trả lời của proxy ≈70% query (minh hoạ) không → escalate Tầm trung model vừa · $$ conf ≥ t₂ ? có Trả lời tầm trung ≈20% query (minh hoạ) không → escalate Oracle model mạnh · $$$ · chậm Trả lời của oracle ≈10% · chịu latency 3 lượt Mỗi bậc có ngưỡng riêng (t₁, t₂), hiệu chỉnh offline theo cùng một quy trình.
Cascade nhiều bậc (tỷ lệ phần trăm là minh hoạ). Bản hai bậc chỉ gồm proxy → oracle. Query bị escalate chậm hơn gọi thẳng oracle, nhưng latency trung bình vẫn giảm nếu phần lớn dừng ở bậc đầu.

Ước lượng độ tự tin (confidence)

Đừng tin confidence theo mặt chữ

Dù lấy từ logprobs hay để model tự khai, confidence chỉ là một tín hiệu nhiễu, không phải thước đo đúng/sai. Câu hỏi cần trả lời: khi proxy báo tự tin cao, nó có thường khớp oracle không? Tin tốt: quy trình tìm ngưỡng tự bảo vệ — nếu confidence không tách được khớp/không khớp thì sẽ không tìm ra ngưỡng, và mọi thứ đi oracle (không tiết kiệm, nhưng không hỏng gì).

Với tác vụ đáp án là một token (true/false), API trả logprob (log tự nhiên của xác suất) cho top 5–20 token. Đổi về xác suất bằng exp(), chuẩn hoá cho tổng bằng 1, lấy giá trị lớn hơn làm confidence.

Tokenlogprobexp()Chuẩn hoá
true−0.1050.900.90 ← confidence
false−2.3030.100.10
import math
top = {"true": -0.105, "false": -2.303}      # logprob của 2 nhãn hợp lệ
p = {k: math.exp(v) for k, v in top.items()}
z = sum(p.values())
label = max(p, key=p.get)
confidence = p[label] / z                    # ≈ 0.90 → rất tự tin

Giới hạn Output dài nhiều token → không có "xác suất của cả câu trả lời" để so; cách này không dùng được.

Yêu cầu structured output hai trường: answer (câu trả lời mở) và confidence (số nguyên 0–10), ép bằng JSON Schema qua API structured output của provider.

  • Tác giả thấy tương đối ổn với phân loại; kém tin cậy với output mở.
  • Model đã qua RLHF/instruction-tuning thường tự tin quá mức; base model calibrate tốt hơn (Tian et al. 2023).
  • Output mở còn thiếu một thứ: biết khi nào proxy "khớp" oracle — so chuỗi không được. Cần một LLM-judge đã được kiểm (Ch.5) để chấm độ khớp offline, hoặc nhãn người.

12.7Hiệu chỉnh ngưỡng cascade offline

  1. Chuẩn bịTập held-out N ví dụ, target đồng thuận r (vd 0.95).
  2. Chạy proxy trên cả NLưu câu trả lời + confidence.
  3. Chạy oracle trên cả NLưu câu trả lời — coi là "ground truth" cho mục đích cascade.
  4. Đánh dấu khớp / không khớpcho từng ví dụ.
  5. Sắp theo confidence của proxy, cao → thấpĐi dần xuống, tính tỷ lệ khớp cộng dồn từ đầu tới vị trí i.
  6. Ngưỡng t= confidence tại vị trí cuối cùng mà tỷ lệ khớp cộng dồn vẫn ≥ r.
100% 95% 90% 85% 80% 0% 25% 50% 75% 100% target r = 95% ngưỡng t = confidence tại vị trí này (vd 0.82) proxy tự xử lý ≈ 76% → oracle ≈ 24% query đã sắp theo confidence của proxy, cao → thấp trục dọc: tỷ lệ proxy khớp oracle, cộng dồn từ đầu danh sách
Đường cong minh hoạ (số liệu bịa). Proxy càng calibrate tốt, đường càng giữ cao lâu → điểm cắt dịch sang phải → tiết kiệm nhiều hơn.

Viết thành code (minh hoạ, tự viết):

def calibrate(conf, proxy_ans, oracle_ans, r=0.95):
    rows = sorted(zip(conf, proxy_ans, oracle_ans), key=lambda x: -x[0])
    hits, t = 0, None
    for i, (c, p, o) in enumerate(rows, start=1):
        hits += (p == o)          # output mở: thay bằng judge(p, o)
        if hits / i >= r:
            t = c                 # vẫn đạt target tới vị trí i
    return t                      # None → không có ngưỡng: gửi hết cho oracle

# runtime: answer = proxy if proxy_conf >= t else oracle(query)
Nhiều hơn hai model

Xếp chuỗi từ rẻ đến đắt; mỗi bậc một ngưỡng, hiệu chỉnh cùng cách. Dừng ở bậc đầu tiên đủ tự tin hoặc tới oracle.

Đọc thêm

FrugalGPT (Chen et al. 2023) — cascade LLM đạt chất lượng GPT-4 với một phần nhỏ chi phí. Task cascades (Shankar et al. 2026) — đổi cả việc được giao ở mỗi bậc (bậc rẻ trả lời phiên bản đơn giản của câu hỏi).

12.8Routing

Mọi query qua model rẻ trước, escalate nếu confidence thấp.

  • ✓ Có "lưới an toàn": proxy không chắc → oracle vẫn xử lý.
  • ✗ Query bị escalate đi qua ≥2 model → chậm hơn và tốn thêm lượt proxy.
  • Cần: confidence được hiệu chỉnh.

Classifier quyết định trước gửi query tới model nào — không thử model rẻ trước. Vd "giá căn này bao nhiêu?" → model nhanh, rẻ; "so sánh 3 căn theo trường học, thời gian đi làm, xu hướng giá" → model mạnh.

  • ✓ Một lượt → không có phạt latency.
  • ✗ Cần classifier đáng tin; route sai không có cơ hội thứ hai.

Router xử lý ca hiển nhiên, cascade xử lý vùng lưng chừng — tận dụng ưu điểm của cả hai.

Giải pháp có sẵn: RouteLLM (Ong et al. 2024, mã nguồn mở, train trên dữ liệu preference của Chatbot Arena; báo cáo giảm 85% chi phí trên MT-Bench mà giữ 95% chất lượng GPT-4), Model Router của Microsoft Foundry, Martian.

Query Router classifier chọn trước Rõ là dễ → Model rẻ 1 lượt · rủi ro: misroute xuống, không cứu được Mơ hồ → Cascade proxy → (conf ≥ t ?) → nếu không: oracle Rõ là khó → Oracle 1 lượt · rủi ro: misroute lên, tốn tiền
Thiết kế lai router + cascade: nhánh giữa có lưới an toàn, hai nhánh ngoài tiết kiệm latency.

12.9Chọn chiến lược cải thiện

Chiến lượcCông sứcDữ liệu cầnHợp nhất cho
Tinh chỉnh promptThấpVài ví dụ lỗiLỗi spec, định dạng, thiếu ràng buộc
Đổi kiến trúc (chia bước, retrieval, tool)Trung bìnhHiểu pattern lỗiLỗi suy luận nhiều bước, thiếu thông tin, workflow phức tạp
Tối ưu prompt tự động (DSPy, TextGrad)Trung bình≥50 ví dụ gán nhãn + hàm evalKhi sửa prompt thủ công chững lại
PEFT (LoRA/QLoRA)Cao50–200+ ví dụTác vụ hẹp, prompt không cứu được lỗi generalization
Full fine-tune / DPOCao500+ ví dụ hoặc cặp preferenceStyle, tone, format trên nhiều tác vụ; khi PEFT chưa đủ
Distillation + cascadeCaoDataset lớn + oracleGiảm cost trên tác vụ khối lượng lớn, đã hiểu rõ

→ Đi từ trên xuống. Mỗi hàng tốn công và dữ liệu hơn hàng trên — vắt kiệt lựa chọn rẻ trước.

12.10Vòng đời tiếp diễn & pitfalls

Mọi cải thiện có thể dịch chuyển phân bố lỗi: sửa prompt cho lỗi này làm nảy lỗi khác; route sang model rẻ giảm chất lượng một cách âm thầm. Dataset eval cũ dần, taxonomy cần xem lại, evaluator mới ra đời khi lỗi mới lộ diện — và mọi thay đổi đi qua CI. Ngay cả một vòng lặp thô (mỗi tuần đọc vài trace, cập nhật golden set, sửa prompt tệ nhất) cũng cộng dồn giá trị theo thời gian.

Hướng đang thay đổi nhanh: đánh giá chuỗi suy luận của reasoning model, hệ multi-agent, process reward model (chấm từng bước), ranh giới eval–monitoring mờ dần với agent chạy dài.

Áp dụng cho dự án model-routing của bạn

Chương này gần như là bản thiết kế cho bộ eval của bạn. Ý cốt lõi: eval router = bài toán hiệu chỉnh offline. Nếu bạn có sẵn một ma trận offline — mỗi request trong tập held-out đã chạy qua mọi model ứng viên, lưu output, token, cost, latency, điểm chất lượng — thì bất kỳ chính sách nào (router, cascade ở mọi ngưỡng, lai) đều mô phỏng được bằng tra bảng, không cần gọi lại API, và tái lập được hoàn toàn.

Quy trình đề xuất

  1. Tập held-out phân tầngLấy mẫu request thật theo loại tác vụ / độ khó / độ dài (dùng kỹ thuật Ch.11 để tìm phân khúc). Tách hẳn khỏi dữ liệu dùng để train/tune router.
  2. Chạy ma trận model × requestMọi model ứng viên trên mọi request, cố định prompt/temperature/seed nếu có; lưu output, token vào/ra, cost, latency.
  3. Định nghĩa "đạt"Verdict nhị phân từ một LLM-judge đã được kiểm với nhãn người (Ch.5): "output này đạt yêu cầu?" hoặc "tương đương output của oracle?". Output mở không so chuỗi được.
  4. Mô phỏng chính sáchBaseline: luôn-rẻ, luôn-đắt, random cùng tỷ lệ trộn. Ứng viên: router, cascade quét ngưỡng t, lai router + cascade. Thêm router lý tưởng (với mỗi request chọn model rẻ nhất vẫn đạt) làm cận trên.
  5. Hiệu chỉnh ngưỡngDùng đúng thuật toán 12.7 cho điểm tự tin của router ("gửi xuống model rẻ") và của proxy trong cascade. Không tìm được ngưỡng đạt r → mặc định route lên model mạnh.
  6. Chọn trên đường ParetoChính sách rẻ nhất vượt sàn chất lượng đã thống nhất, báo cáo theo từng phân khúc chứ không chỉ trung bình.
  7. Canh gác productionTheo dõi % traffic mỗi bậc, tỷ lệ escalate, drift phân bố request; hiệu chỉnh lại khi đổi model, đổi giá, hoặc phân bố request dịch chuyển.
95% 90% 85% 80% 75% $0 $2 $4 $6 $8 $10 cost / 1K request → chất lượng (tỷ lệ đạt) → sàn chất lượng 90% đường Pareto Luôn rẻ Router Router + cascade ← rẻ nhất trên sàn Cascade (t cao) Random 50/50 (bị trội) Luôn đắt (oracle) Router lý tưởng (cận trên)
Số liệu minh hoạ, không phải đo thật. Mỗi điểm là một chính sách mô phỏng trên ma trận offline. Khoảng cách từ router thật tới "router lý tưởng" cho biết còn bao nhiêu dư địa.

Bảng metric nên báo cáo

MetricĐịnh nghĩaVì sao cần
Quality retentionTỷ lệ đạt của chính sách ÷ tỷ lệ đạt của luôn-đắtCon số "giữ X% chất lượng" so được với RouteLLM
Agreement với oracle% request mà output chính sách được judge coi là tương đương oracleChính là target r của cascade
Cost / 1K request & % tiết kiệmSo với luôn-đắtTrục ngang của đường Pareto
Misroute xuốngGửi model rẻ, model rẻ trượt trong khi model mạnh đạtLỗi chất lượng — với router thuần là không cứu được
Misroute lênGửi model mạnh dù model rẻ cũng đạtTiền lãng phí; khoảng cách tới cận trên
Latency p50 / p95Tính cả lượt proxy của query bị escalateCascade có thể làm p95 xấu đi dù trung bình tốt
Phân theo phân khúcMọi metric trên, tách theo loại request / độ khóTrung bình giấu lỗi ở phân khúc hiếm

Bẫy riêng cho eval routing

  • Rò dữ liệu: router được train/tune trên chính tập dùng để đánh giá → kết quả đẹp giả. Giữ held-out tách biệt (giống quy tắc "few-shot ≠ test case CI").
  • Judge thiên vị model lớn: judge có thể ưu ái văn phong dài, trau chuốt của model đắt. Kiểm judge với nhãn người trên chính các cặp (rẻ vs đắt).
  • Oracle không phải chân lý: agreement đo "giống oracle", không phải "đúng". Với phân khúc quan trọng, kèm thêm tỷ lệ đạt tuyệt đối.
  • Confidence của router chưa calibrate: điểm "độ khó" của classifier cũng nhiễu như confidence của proxy — tìm ngưỡng theo 12.7, đừng đặt tay 0.5.
  • Ma trận cũ: đổi model, đổi giá, hay phân bố request dịch chuyển → chạy lại ma trận; đường Pareto sẽ khác.

Tự kiểm tra

Agent trả cả căn hộ khi người dùng hỏi "homes". Nên xây evaluator đo tần suất lỗi này ngay không?
Chưa. Đây là lỗi specification — prompt không định nghĩa "homes". Sửa một dòng prompt trước; chỉ xây evaluator cho những gì vẫn sai sau khi spec đã rõ.
Vì sao đặt tên người dùng ở đầu prompt, trước instruction dài, lại làm tăng chi phí?
Prefix cache chỉ ăn khi chuỗi token đầu trùng khớp tuyệt đối. Tên thay đổi ở đầu → prefix mỗi request mỗi khác → không request nào dùng lại được KV cache của instruction. Đưa instruction lên trước, dữ liệu biến đổi xuống cuối.
Proxy trả true với logprob −0.105 và false với −2.303. Confidence bằng bao nhiêu?
exp(−0.105) ≈ 0.90, exp(−2.303) ≈ 0.10; chuẩn hoá → confidence ≈ 0.90 cho true.
Nếu confidence của proxy hoàn toàn không liên quan tới việc nó có khớp oracle hay không, cascade sẽ ra sao?
Quy trình hiệu chỉnh sẽ không tìm được ngưỡng đạt target → mọi query đi oracle. Không tiết kiệm được gì, nhưng cũng không làm hỏng chất lượng — mặc định an toàn.
Khác biệt cốt lõi giữa routing và cascade là gì, và rủi ro riêng của routing?
Cascade thử model rẻ trước rồi escalate; routing chọn model ngay từ đầu bằng classifier. Routing không bị phạt latency hai lượt, nhưng route sai không có cơ hội thứ hai.
Bạn có 80 request/ngày cho một tác vụ, muốn giảm chi phí. Distillation hay cascade?
Khối lượng thấp → cascade thường kinh tế hơn: không phải train và host model riêng. Distillation chỉ đáng khi khối lượng đủ lớn để tiết kiệm mỗi query bù được chi phí train + serve + bảo trì.

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). Mọi sơ đồ, đoạn code và số liệu minh hoạ là tự thiết kế.