Phân tích dữ liệu trace: từ pattern đến giả thuyết đã kiểm chứng
TL;DR
- Error analysis đọc từng trace; data analysis nhìn cả tập trace để quyết định nên đọc kỹ trace nào.
- Cluster, biểu đồ, tương quan, outlier chỉ sinh giả thuyết — không phải failure mode. Luôn quay lại đọc trace thật.
- Xác nhận giả thuyết: đọc ~20 trace → viết tiêu chí kiểm được → tiêu chí đúng cho 70–80% cụm.
- Semantic search mở rộng một ví dụ lỗi thành cả quần thể lỗi; coi chừng "cùng chủ đề" ≠ "cùng lỗi".
- AI coding assistant: để nó tìm, tóm tắt, search, vẽ — không để nó kết luận nguyên nhân.
11.1Từ đọc từng trace đến nhìn cả tập
EDA (Exploratory Data Analysis) là việc "chọc ngoáy" dữ liệu để nảy ra giả thuyết — thuật ngữ John Tukey (cha đẻ box plot) đưa ra như đối trọng với confirmatory analysis (fit model, chạy kiểm định). Muốn xác nhận gì thì trước hết phải biết xác nhận cái gì; EDA trả lời câu đó. Error analysis ở Chương 3 thực chất cũng là EDA trên văn bản.
Gom trace giống nhau, đọc vài đại diện mỗi cụm, hỏi "khác biệt giữa các cụm gợi ý agent sai ở đâu?".
Turns, latency, tool call, token, sentiment… — phân phối, bảng chéo, tương quan, outlier.
Từ 1–2 ví dụ lỗi, tìm thêm trace tương tự để biết lỗi phổ biến cỡ nào.
Tăng tốc phần cơ học (nạp, vẽ, tìm) — không thay bạn suy luận.
Sai lầm số 1
Coi một cụm là một failure mode. Cụm, biểu đồ cột, hệ số tương quan… đều chỉ là lời nhắc đi đọc trace bên dưới. Vòng lặp đúng: giả thuyết thô → chọn một lát dữ liệu → đọc → làm sắc hoặc bỏ. Phần lớn giả thuyết đầu tiên sẽ bị bỏ — đó là chuyện bình thường.11.2Clustering để sinh giả thuyết
Đôi khi cluster xong chẳng thấy gì mới: các cụm khó phân biệt, hoặc chỉ ra những nhóm ai cũng biết (hỏi về căn hộ / hỏi về nhà phố). Đó vẫn là thông tin: hoặc embedding không bắt được biến thiên bạn quan tâm, hoặc biến thiên đó không phải trục chính của dữ liệu.
Trợ lý bất động sản Cluster theo embedding của câu hỏi người dùng → ra các nhóm hiển nhiên: đặt lịch xem nhà, tìm nhà, soạn email.
Hữu ích để hiểu phân bố tác vụ, nhưng không nói gì về chỗ agent sai.
Đổi sang cluster theo embedding của email agent viết ra → xuất hiện một nhóm nhỏ email đều mở đầu bằng lời xin lỗi dài dòng trước khi đưa ra bất kỳ căn nhà nào.
Đây là lỗi giọng văn mà vòng error analysis trước đã bỏ sót. Bài học: nếu cụm vô vị, đổi thứ đem đi embed.
11.3Metric theo từng trace
Ngoài clustering, tính cho mỗi trace: số lượt, latency, số tool call, token vào/ra, sentiment, phân khúc người dùng, giờ trong ngày. Rồi xem chúng phân bố, tương quan và tách theo metadata ra sao.
Hình dạng phân phối nói gì?
| Kỹ thuật | Làm gì | Tín hiệu đáng đào tiếp |
|---|---|---|
| Phân phối histogram · box plot | Xem hình dạng một metric | Hai đỉnh, đuôi dài bất thường |
| Bảng chéo cross-tab | Tỷ lệ thumbs-down theo persona, phiên bản agent, giờ, độ dài phiên | Một nhóm có tỷ lệ lỗi vượt trội (vd phiên dài lỗi nhiều hơn) |
| Tương quan | Tool call vs latency; tool call vs thumbs-down | Có liên hệ rõ → đào sâu (xem confounder ở 11.7) |
| Lọc lát rồi đọc | Lấy một lát (thumbs-down, >5 lượt, có tool X) và đọc ~20 trace liền một mạch | Pattern chỉ lộ ra khi đọc dồn, không lộ khi đọc lẻ tẻ |
| Săn outlier | Gắn cờ trace có metric lệch hẳn | Hai quy tắc: IQR hoặc cắt percentile |
Quy tắc outlier IQR
Một đoạn minh hoạ ngắn (tự viết) để gắn cờ outlier bằng IQR trên file trace:
import pandas as pd
df = pd.read_json("traces.jsonl", lines=True)
q1, q3 = df["latency_s"].quantile([0.25, 0.75])
iqr = q3 - q1
mask = (df["latency_s"] < q1 - 1.5 * iqr) | (df["latency_s"] > q3 + 1.5 * iqr)
to_read = df[mask].sample(min(20, mask.sum())) # đọc tối đa 20 cái
11.4Từ cụm đến giả thuyết đã xác nhận
Một cụm trông như "mơ hồ về địa điểm" có thể gồm nhiều lỗi khác nhau chỉ trông giống nhau ở output. Trước khi hành động, chạy một giao thức xác nhận nhẹ.
- Đọc kỹ khoảng 20 trace trong cụm ứng viênKhông lướt nhãn cụm — đọc nội dung thật.
- Viết một tiêu chí kiểm đượcVí dụ: "agent hiểu tên khu phố thành tên thành phố". Phải trả lời được có/không cho từng trace.
- Đếm: tiêu chí đúng cho 70–80% trace trong cụm?Có → pattern thật, thêm vào taxonomy. Không → cụm không đồng nhất, tách nhỏ hoặc xem lại.
Khi LLM trích feature để cluster
Nếu bạn nhờ LLM trích feature (vd "loại lỗi của trace này là gì") rồi cluster trên đó, hãy kiểm độ chính xác trích xuất trên một tập nhỏ gán nhãn tay trước. Dưới ~90% thì các cụm xây trên đó không đáng tin → dùng rule-based hoặc gán tay cho những feature quan trọng nhất.11.5Semantic search: tìm thêm trace giống lỗi đã thấy
Error analysis thường chỉ lộ ra 1–2 ví dụ xấu. Câu hỏi thật là: lỗi này phổ biến cỡ nào, và có dồn vào phân khúc người dùng nào không? Semantic search (embedding) giúp mở rộng ví dụ thành quần thể.
Lấy một trace có lỗi (vd email mở đầu bằng lời xin lỗi) → tìm các láng giềng gần nhất theo embedding → đọc danh sách xếp hạng.
Dùng khi đã có một ví dụ điển hình.
Viết mô tả pattern cần tìm (vd "email xin lỗi trước khi đưa ra căn nhà nào") → embed chính câu mô tả → tìm.
Dùng khi biết pattern trông thế nào nhưng chưa có ví dụ chuẩn.
Cho LLM trích feature riêng của ứng dụng từ mỗi trace — có đặt lịch xem nhà không? có nhắc giờ trùng không? có trả lời vòng vo không? — hoặc một tóm tắt ngắn, rồi embed cái đó thay vì trace thô.
LLM có thể tự đề xuất danh sách feature nếu bạn đưa vài ví dụ lỗi. Kết quả: khái niệm "giống nhau" gần với ý bạn hơn.
Độ giống embedding ≠ độ giống bạn cần
Hai trace có thể nằm gần nhau chỉ vì cùng chủ đề ("đặt lịch xem nhà") trong khi lỗi bạn săn hẹp hơn nhiều ("đặt trùng hai lịch xem"). Nếu có vài nhãn, đo precision (bao nhiêu kết quả thật sự là lỗi đó) và recall (bắt được bao nhiêu % lỗi có nhãn); chỉnh ngưỡng similarity hoặc đổi model embedding.11.6Dùng AI coding assistant mà không để nó "bịa" phân tích
Setup điển hình: một thư mục chứa file trace (JSON/JSONL), mô tả ngắn về ứng dụng và ý nghĩa từng field, và (nếu cần) code của app → mở phiên Claude Code / Codex tại đó và dùng làm scratchpad.
• Vẽ phân phối (vd histogram turns/phiên, trục y log, tách theo phân khúc)
• Xin nhiều biểu đồ một lúc, chỉ đọc cái bất thường
• Phác regex / rubric từ vài ví dụ lỗi
• Tóm tắt một cụm trace
• Tìm trực tiếp pattern trong trace
Hỏi "vì sao các trace này hỏng" → nhận một lời giải thích nghe rất hợp lý, rất tự tin, dựng từ vài ví dụ nó thấy — nhưng có thể sai, và rất khó nhận ra là sai.
Mọi khẳng định nhân quả = giả thuyết.
Tìm trực tiếp hay dựng index embedding?
| Quy mô trace | Cách tìm pattern |
|---|---|
| Vừa context window (vài nghìn trace ngắn) | Cho agent tìm thẳng trong file — bỏ qua bước dựng embedding index |
| Vượt context window (hàng chục nghìn, hoặc trace dài) | Quay về semantic search / index chuẩn |
Kiểm một giải thích nhân quả
- Viết giải thích thành giả thuyết cụ thểVd "lỗi do mô tả tool thiếu định dạng ngày".
- Đổi đúng một biếnSửa prompt, thay tool, hoặc chỉnh một tham số — không đổi nhiều thứ cùng lúc.
- Chạy golden set trước và sauGiả thuyết đúng → tỷ lệ của đúng failure mode đó phải giảm. Không giảm → giải thích sai, dù nghe thuyết phục đến đâu.
11.7Pitfalls thường gặp
Confounder: đừng vội tin tương quan
- Coi nhãn cụm là ground truth. Ranh giới cụm là tuỳ ý; cụm dán nhãn "sai giọng văn" có thể thực chất là "thiếu thông tin". Nhãn cụm là giả thuyết cho đến khi đọc trace xác nhận.
- Bỏ qua biến gây nhiễu (confounder). Trước khi kết luận, stratify theo độ phức tạp câu hỏi, phân khúc người dùng, thời điểm — xem pattern còn giữ trong từng tầng không.
- Tin lời giải thích nhân quả của AI assistant. Mọi khẳng định nhân quả cần một thay đổi có kiểm soát để kiểm chứng.
- Chỉ nhìn ca bất thường. Cụm, outlier, kết quả search đều lệch về ca lạ. Mỗi buổi phân tích luôn kèm một mẫu ngẫu nhiên để hiệu chỉnh cảm nhận về hệ thống nói chung.
Ghép lại
Error analysis cho bạn taxonomy từ việc đọc kỹ. Data analysis thêm kỹ thuật tổng hợp: EDA/clustering để nảy giả thuyết, metric theo trace để thấy pattern không lộ khi đọc lẻ, semantic search để đo quy mô một lỗi. AI assistant tăng tốc phần cơ học — output của nó luôn là giả thuyết cần đối chiếu với trace thật.Áp dụng cho dự án model-routing của bạn
- Mỗi quyết định route là một trace có metric: model được chọn, domain, độ dài prompt, latency, cost, điểm judge/chất lượng. Vẽ chất lượng và cost theo model × loại request; latency hai đỉnh thường là hai nhánh route trộn lẫn → tách ra đọc.
- Confounder độ khó là bẫy lớn nhất: request được đưa lên model lớn vốn đã khó hơn, nên "model lớn có tỷ lệ lỗi cao" không chứng minh router sai. Stratify theo độ khó (hoặc theo điểm của một judge độc lập) trước khi so.
- Cluster theo feature trích xuất (loại tác vụ, cần reasoning nhiều bước, có code, có tool) thay vì prompt thô → tìm nhóm request bị route xuống model quá yếu. Kiểm feature extractor ≥ ~90% trên tập gán tay trước.
- Dùng semantic search từ một ca route sai để ước lượng có bao nhiêu request tương tự — đó là con số cho biết lỗi này đáng sửa đến đâu.
- Mỗi vòng review: kèm mẫu ngẫu nhiên request, không chỉ những ca bị escalate hay bị người dùng chê.