Phân tích lỗi từ trace thật: từ 100 bản ghi đến danh sách việc cần sửa trước

Một FDE vừa deploy chatbot cho khách hàng thường muốn làm ngay việc có vẻ chuyên nghiệp nhất là dựng bộ evaluator tự động. Nhưng Hamel Husain viết rằng phân tích lỗi mới là “hoạt động quan trọng nhất trong evals”. Lý do rất đơn giản: chưa biết hệ thống hỏng ở đâu thì bạn cũng chưa biết cần đo cái gì.

Các bước dưới đây đi trọn một vòng phân tích lỗi. Khi xong, bạn sẽ có một file nhãn cho khoảng 100 trace, một danh sách nhóm lỗi do chính bạn đặt tên, một bảng xếp hạng và một quyết định rõ ràng về việc sửa gì trong tuần này.

Đây cũng là kỹ năng phân biệt FDE với người chỉ biết gọi API. Khi khách hàng hỏi “con bot dở chỗ nào?”, câu trả lời có số liệu đếm từ trace thật thuyết phục hơn hẳn một cảm nhận chung chung.

Bạn cần chuẩn bị gì?

Bạn cần quyền truy cập trace của một ứng dụng LLM, tức bản ghi đầy đủ input, các bước trung gian như gọi tool hay truy xuất tài liệu, và output. Bạn cũng cần một bảng tính hoặc file CSV và Python 3 cài sẵn. Langfuse là tùy chọn: hướng dẫn error analysis của họ dùng đúng quy trình này, nhưng mọi bước đều làm được bằng file thủ công.

Để ví dụ cụ thể, cả bài dùng một tình huống giả định: bot chăm sóc khách hàng của một công ty giao hàng. Bot trả lời về trạng thái đơn, phí ship và chính sách hoàn tiền. Mọi con số về bot này bên dưới đều là minh họa.

Bước 1: Lấy mẫu trace sao cho đa dạng

Quy trình của Langfuse bắt đầu bằng việc kéo một mẫu đại diện từ traffic production, từ dataset hoặc từ output của các lần thử nghiệm. Husain coi khoảng 100 trace đa dạng là số lượng thực tế để bắt đầu. Đa dạng ở đây nghĩa là phủ nhiều loại câu hỏi, nhiều kiểu người dùng, cả trace ngắn lẫn trace dài.

Xuất mẫu ra một file labels.csv có cấu trúc như sau:

trace_id,note,category
t001,,
t002,,

Kiểm tra: lướt qua 10 dòng ngẫu nhiên. Nếu cả 10 trace đều là câu hỏi tra đơn thì mẫu đang lệch, bạn cần lấy lại.

Bước 2: Open coding, chỉ ghi lỗi đầu tiên

Đọc từng trace và viết ghi chú tự do về mọi vấn đề bạn thấy. Đó là open coding. Đừng ép mình vào danh mục có sẵn, cứ viết như ghi chú cho đồng nghiệp: “bot hứa hoàn tiền 100% cho đơn đã quá 30 ngày”.

Quy tắc quan trọng nhất của bước này: chỉ ghi lỗi đầu tiên xuất hiện trong trace. Husain giải thích rằng lỗi ở thượng nguồn kéo theo lỗi ở hạ nguồn. Nếu bot gọi nhầm tool tra đơn rồi sau đó báo sai ngày giao, gốc rễ là cú gọi tool, còn ngày sai chỉ là hệ quả.

Husain khuyên tự tay gán nhãn ít nhất 30 trace trước khi xem gợi ý từ một AI agent. Ba mươi trace đầu là lúc bạn hình thành trực giác về hệ thống. Nếu giao việc này cho máy quá sớm, bạn sẽ không đủ hiểu để đánh giá xem gợi ý của máy có đúng không.

Kiểm tra: cột note của 30 dòng đầu phải là câu cụ thể, đọc lên hiểu ngay. Những ghi chú kiểu “trả lời kém” là vô dụng, hãy viết lại.

Bước 3: Axial coding, gom ghi chú thành nhóm lỗi

Giờ bạn đọc lại toàn bộ ghi chú và gom chúng thành các nhóm. Đó là axial coding. Với bot giao hàng giả định, bạn có thể ra những nhóm như sai_chinh_sach_hoan_tien, bo_qua_ngay_trong_cau_hoi, goi_sai_tool_tra_don và tra_loi_qua_dai.

Bạn có thể nhờ LLM soạn bản nháp danh sách nhóm. Nhưng hướng dẫn của Langfuse dặn rõ phải tự xem lại các nhóm được đề xuất, vì model có thể gộp những lỗi có nguyên nhân khác nhau vào cùng một nhóm. Chẳng hạn “báo sai phí ship” do bot đọc sai bảng giá khác hẳn trường hợp do bot không hỏi địa chỉ, dù bề ngoài giống nhau.

Sau đó điền cột category cho từng trace. Trace không có lỗi thì để trống. Langfuse làm bước này bằng cách tạo một score dạng boolean cho mỗi nhóm lỗi (Settings → Scores → Create, type: Boolean), để mỗi trace được đánh đạt hay trượt theo từng nhóm.

Kiểm tra: nếu một nhóm chiếm hơn nửa số lỗi, nhiều khả năng nó đang chứa vài nguyên nhân khác nhau. Hãy tách nó ra.

Bước 4: Đếm, và biết khi nào dừng đọc

Bước cuối của quy trình Husain là đếm số lỗi trong mỗi nhóm. Langfuse cũng làm như vậy: gắn nhãn mọi trace theo bộ nhóm lỗi rồi tính tỷ lệ lỗi cho từng nhóm. Script dưới đây là bản rút gọn, chỉ dùng thư viện chuẩn của Python:

import csv
from collections import Counter

with open("labels.csv", encoding="utf-8") as f:
    rows = list(csv.DictReader(f))

total = len(rows)
counts = Counter(r["category"] for r in rows if r["category"])
for cat, n in counts.most_common():
    print(f"{cat:30} {n:3}  {n/total:.0%}")

Khi nào thì đủ? Husain đưa ra quy tắc dừng: đọc tiếp cho đến khi đạt độ bão hòa lý thuyết, tức là trace mới không còn để lộ kiểu lỗi mới và cũng không làm thay đổi các nhóm đã có. Nếu đến trace thứ 100 bạn vẫn đang tạo nhóm mới, hãy lấy thêm mẫu.

Bước 5: Xếp hạng theo tần suất và mức nghiêm trọng

Chỉ đếm số lần thì chưa đủ. Product Talk xếp hạng nhóm lỗi theo cả tần suất lẫn mức nghiêm trọng. Nếu bot trả lời dài dòng 11 lần, khách chỉ thấy phiền; nếu bot hứa sai chính sách hoàn tiền 6 lần, công ty mất tiền thật và khách có thể khiếu nại.

Một cách làm đơn giản là chấm mức nghiêm trọng từ 1 đến 3 cho mỗi nhóm rồi nhân với số lần xuất hiện. Đây là cách tính đã giản lược, không phải công thức chuẩn, nhưng đủ để bắt đầu một cuộc thảo luận:

SEVERITY = {"sai_chinh_sach_hoan_tien": 3, "goi_sai_tool_tra_don": 3,
            "bo_qua_ngay_trong_cau_hoi": 2, "tra_loi_qua_dai": 1}
ranked = sorted(counts, key=lambda c: counts[c] * SEVERITY.get(c, 1),
                reverse=True)

Với số liệu giả định của bot giao hàng, bảng xếp hạng có thể trông như sau:

Nhóm lỗi	Số lần	Nghiêm trọng	Điểm	Hướng xử lý
goi_sai_tool_tra_don	8	3	24	Sửa mô tả tool trong prompt, đo lại
sai_chinh_sach_hoan_tien	6	3	18	Đưa văn bản chính sách vào context
bo_qua_ngay_trong_cau_hoi	7	2	14	Cân nhắc xây evaluator
tra_loi_qua_dai	11	1	11	Một dòng chỉ dẫn trong prompt

Nhóm xuất hiện nhiều nhất lại đứng cuối bảng. Đó chính là lý do không nên xếp hạng chỉ bằng tần suất.

Cột cuối của bảng áp dụng quy tắc của Langfuse: sửa trước đã, đừng xây evaluator cho lỗi mà prompt giải quyết được. Evaluator chỉ đáng đầu tư khi lỗi vẫn còn sau khi bạn đã sửa và cần được theo dõi lâu dài.

Những lỗi hay gặp

Trong ghi chép từ buổi chia sẻ của Husain, Alex Strick van Linschoten nêu ba sai lầm phổ biến. Sai lầm đầu tiên là bỏ qua vòng lặp: làm axial coding xong thì không quay lại open coding nữa. Trong khi đó, khi đã có nhóm lỗi, bạn đọc trace bằng con mắt khác và thường phát hiện ra nhóm cần tách hoặc gộp.

Sai lầm thứ hai là gạt chuyên gia nghiệp vụ ra ngoài. Bạn có thể không nhận ra câu trả lời về điều khoản hoàn tiền là sai, nhưng nhân viên chăm sóc khách hàng của công ty sẽ nhận ra ngay. Sai lầm thứ ba là tự động hóa quá sớm, tức dựng LLM-as-judge trước khi hiểu lỗi bằng mắt mình.

Áp dụng ở chỗ khách hàng

Ở chỗ khách hàng, nên xếp buổi phân tích lỗi ngay trong tuần đầu và mời người phụ trách vận hành ngồi chấm mức nghiêm trọng cùng bạn. Bảng xếp hạng làm xong sẽ trở thành bản kế hoạch mà cả hai bên cùng thống nhất, thay vì một danh sách yêu cầu không có thứ tự ưu tiên.

Về nghề nghiệp, khi đọc mô tả công việc FDE, hãy để ý các cụm như “evals”, “trace review” hoặc “failure analysis”.

Trong CV, thay vì viết “cải thiện chất lượng chatbot”, hãy ghi rằng bạn đã gán nhãn N trace, xác định K nhóm lỗi và giảm tỷ lệ lỗi của nhóm đứng đầu sau khi sửa prompt.

Một con số trước và sau trên cùng một tập trace là bằng chứng mà nhà tuyển dụng hiểu ngay.

Lần tới khi ai đó đề nghị dựng dashboard đo chất lượng, hãy mở 30 trace ra đọc trước. Dashboard tốt nhất được xây trên những nhóm lỗi bạn đã tự tay đặt tên.