Từ câu "con bot trả lời dở quá" đến một bộ eval: biến lời phàn nàn thành thước đo

Buổi họp đầu tiên với khách hàng thường kết thúc bằng một câu kiểu: “Con bot trả lời dở quá, các anh làm sao cho nó tốt hơn đi.” Không có số liệu, không có ví dụ cụ thể, không ai nói “tốt hơn” là tốt đến đâu. Vậy mà hai tuần sau, chính người đó sẽ là người quyết định dự án thành hay bại.

Đây là chỗ nhiều engineer giỏi bị kẹt. Bạn có thể viết prompt hay, dựng pipeline RAG gọn, nhưng nếu không biết “tốt” nghĩa là gì thì bạn đang tối ưu cho một mục tiêu không ai nhìn thấy. Kỹ năng cần học ở đây là biến lời phàn nàn của khách thành những tiêu chí mà output của model hoặc đạt, hoặc trượt.

Vì sao đây là việc của FDE chứ không phải của ai khác?

PostHog mô tả FDE là engineer được gắn vào chính đội của khách hàng. Vị trí đó cho bạn thứ mà team research ở trụ sở không có: dữ liệu thật, người dùng thật, lời phàn nàn thật. Vì thế các công ty đặt việc định nghĩa thành công vào đúng vai trò này.

Tin tuyển FDE của Cursor yêu cầu dẫn dắt discovery cùng engineer phía khách để tìm ra nút thắt thật sự, định nghĩa metric thành công rõ ràng ngay từ đầu, rồi chịu trách nhiệm giải pháp end-to-end. Đã chịu trách nhiệm end-to-end thì không thể chỉ chẩn đoán rồi bàn giao; bạn phải chứng minh mình đã chữa xong.

Bằng chứng đó, theo một hướng dẫn kỹ năng cho AI FDE trên SecondTalent, là một evaluation harness cho thấy hệ thống đạt định nghĩa “output tốt” mà hai bên đã thống nhất.

Ví dụ PostHog kể về OpenAI cho thấy eval còn đi xa hơn: FDE ở một khách hàng tự động hóa call center dựng eval để kiểm chứng hiệu năng, rồi mang dữ liệu đó về cho team research cải thiện tiếp. Eval vừa là bằng chứng cho khách, vừa là tín hiệu cho sản phẩm.

Bắt đầu từ lỗi, không bắt đầu từ metric

Phản xạ đầu tiên của nhiều người là chọn một metric phổ biến, kiểu điểm “helpfulness” hay độ tương đồng văn bản, rồi chạy. Hamel Husain và Shreya Shankar cảnh báo rằng eval chung chung làm tốn thời gian và tạo ra sự tự tin giả khi bị dùng làm thước đo chất lượng. Họ khuyên dựng evaluator riêng, xuất phát từ error analysis.

Error analysis, theo hai tác giả, là hoạt động quan trọng nhất trong eval, vì chính nó quyết định nên viết eval nào.

Tài liệu của Anthropic bổ sung một nguyên tắc: tiêu chí phải cụ thể. Thay vì “hiệu năng tốt”, hãy nói “phân loại cảm xúc chính xác”. Tiêu chí cũng phải gắn với mục đích của ứng dụng: độ chính xác trích dẫn có thể sống còn với ứng dụng y tế nhưng ít quan trọng hơn với một chatbot tán gẫu.

Một ví dụ đi trọn vòng

Thử hình dung bạn là FDE tại một công ty bán lẻ, khách triển khai bot chăm sóc khách hàng và phàn nàn “bot trả lời dở”. Bước đầu tiên không phải mở code. Bạn hỏi tiếp: “Anh cho em xem ba cuộc chat gần nhất mà anh thấy dở nhất?”

Giả sử ba cuộc chat đó lộ ra những chuyện khác hẳn nhau: bot báo sai chính sách đổi trả, bot hứa hoàn tiền khi nó không có quyền, và bot trả lời đúng nhưng dài lê thê. “Dở” thực ra là ba lỗi, với ba mức độ nghiêm trọng khác nhau.

Lúc này bạn xin thêm khoảng vài chục log, đọc hết, ghi một dòng mô tả lỗi cho mỗi output sai.

Sau khi gom nhóm, giả sử lỗi hứa hoàn tiền sai thẩm quyền ít gặp nhưng nguy hiểm nhất về pháp lý, còn lỗi sai chính sách xuất hiện nhiều nhất. Bạn mang bảng này quay lại gặp khách. Cuộc nói chuyện đổi hẳn tính chất: không còn là “làm cho tốt hơn”, mà là “anh muốn ưu tiên lỗi nào, và ngưỡng nào thì anh chấp nhận?”

Tiếp theo là viết tiêu chí. Husain và Shankar chuộng đánh giá nhị phân pass/fail hơn thang 1-5, vì nó buộc người viết nghĩ rõ hơn và gán nhãn nhất quán hơn. Với ví dụ này, tiêu chí có thể trông như sau:

Lời phàn nàn	Lỗi cụ thể	Tiêu chí pass/fail
“Bot trả lời sai”	Báo sai chính sách đổi trả	Pass nếu mọi điều kiện đổi trả nêu ra khớp văn bản chính sách hiện hành
“Bot nguy hiểm”	Hứa hoàn tiền khi không có quyền	Fail nếu output cam kết hoàn tiền mà không chuyển cho nhân viên
“Bot lan man”	Trả lời quá dài	Pass nếu câu trả lời giải quyết câu hỏi trong giới hạn độ dài đã thống nhất

Cuối cùng là ngưỡng. Anthropic đưa ví dụ biến mục tiêu “output an toàn” thành: dưới 0,1% trong 10.000 lần thử bị bộ lọc nội dung gắn cờ độc hại. Cấu trúc đó, gồm nhiệm vụ cụ thể, ngưỡng, và số lần thử, chính là thứ bạn cần đưa cho khách ký.

Với lỗi hứa hoàn tiền, bạn có thể đề xuất ngưỡng gần như bằng không; với độ dài, khách có thể chấp nhận lỏng hơn nhiều.

Đừng tin judge khi chưa kiểm tra nó

Khi số lượng output lớn, bạn sẽ dùng LLM làm judge để chấm tự động. Đây là chỗ dễ tự lừa mình nhất. Husain và Shankar nhấn mạnh: một evaluator đưa ra phán đoán phải được thử trên các ví dụ do người gán nhãn, đúng loại lỗi mà nó được giao phát hiện.

Trong ví dụ trên, bạn sẽ ngồi cùng một nhân viên chăm sóc khách hàng phía khách, gán nhãn pass/fail cho một tập output, rồi so với kết quả của judge. Nếu judge bỏ sót nhiều ca hứa hoàn tiền mà người thật bắt được, con số “đạt” trên dashboard của bạn không có nghĩa gì.

Phần đối chiếu này cũng là cách tốt để khách tin vào eval, vì người của họ đã tham gia định nghĩa “đúng”. Một bài tập đáng làm: tự gán nhãn 20 output theo một tiêu chí, cho LLM judge chấm đúng 20 output đó, rồi đếm số ca hai bên lệch nhau.

Mỗi ca lệch là một câu hỏi bạn phải trả lời được trước khi đưa bất kỳ con số nào cho khách.

Những lỗi hay gặp

Lỗi phổ biến nhất là nhận lời phàn nàn rồi đi thẳng vào sửa prompt. Bạn có thể sửa đúng thứ mình đoán, trong khi thứ khách thật sự đau lại nằm chỗ khác, và không có cách nào chứng minh tiến bộ.

Lỗi thứ hai là dùng thang điểm 1-5 vì trông có vẻ tinh tế. Khi hai người chấm cùng một output lại cho 3 và 4, con số trung bình chẳng giúp ai ra quyết định. Lỗi thứ ba là coi eval là việc làm một lần: khi dữ liệu thật đổi, nhóm lỗi đổi, và bạn phải đọc trace lại.

Lỗi cuối cùng tinh vi hơn: tự định nghĩa “tốt” mà không đưa cho khách xác nhận. Eval do một mình FDE viết là eval của FDE. Eval được khách ký vào mới là hợp đồng.

Thể hiện kỹ năng này khi đi xin việc

Khi đọc JD FDE, hãy để ý những cụm như “define success metrics”, “build evals”, “discovery”. Đó là tín hiệu công ty cần đúng kỹ năng này. Trong CV, thay vì viết “cải thiện chất lượng chatbot”, hãy viết bạn đã gom lỗi từ bao nhiêu trace, định nghĩa tiêu chí nào, và tỷ lệ pass thay đổi ra sao.

Khi phỏng vấn, nếu được hỏi “khách nói sản phẩm không tốt, bạn làm gì”, đừng vội trả lời bằng kỹ thuật. Hãy kể quy trình: hỏi ví dụ, đọc trace, gom lỗi, viết tiêu chí nhị phân, đặt ngưỡng cùng khách, kiểm tra judge.

Kể được trọn vòng đó là cách rõ nhất để cho thấy bạn biết biến một lời phàn nàn thành thước đo, chứ không chỉ biết sửa. Người biết sửa thì nhiều; người khiến khách gật đầu với một con số mới là người được giao dự án tiếp theo.