Demo nhìn rất ổn trên màn hình lớn. Một prompt đi vào, một câu trả lời bóng bẩy đi ra, và trong vài phút căn phòng nhẹ hẳn. Rồi có người mở spreadsheet những support ticket thật: thiếu context, câu chữ lạ, khách hàng đang bực, attachment mất, và những tên product nghe gần giống nhau. Model vẫn hữu ích, nhưng câu hỏi đổi từ “cái này có ấn tượng không?” thành “mình có thể tin nó đủ thường xuyên không?”
Đánh giá LLM performance bắt đầu khi mình ngừng xem model như một chiếc hộp kỳ diệu và bắt đầu xem nó như một phần của product system. Một language model có thể nghe rất tự tin trong khi sai. Nó có thể đúng ở ví dụ dễ và mong manh ở case quan trọng. Nó có thể cải thiện một metric nhưng làm latency, cost, privacy hoặc user trust tệ hơn. Evaluation tốt không xóa hết uncertainty, nhưng làm uncertainty hiện ra.
Bước đầu tiên là định nghĩa task bằng ngôn ngữ product bình thường. Mình đang summarize tài liệu dài, extract field, trả lời từ knowledge base, draft reply, classify risk, generate code, hay giúp user search? “Good answer” nghĩa rất khác trong từng trường hợp. Một summary ngắn có thể có giá trị trong workflow này, nhưng nguy hiểm trong workflow khác nếu nó bỏ sót chi tiết bắt buộc. Evaluation phải thuộc về công việc, không thuộc về model chung chung.
Dataset hữu ích cần nhiều hơn ví dụ sạch. Nó cần common case, edge case, historical failure, input mơ hồ, thông tin lỗi thời, câu chữ adversarial và những ví dụ mà hành vi đúng là nói “tôi không biết.” Nếu eval set chỉ toàn happy path, nó sẽ thưởng model vì làm tốt trong một thế giới product không thật sự sống. Ticket rối, doc cũ và ngôn ngữ user vụng về không phải noise. Chúng chính là bài test.
Rubric giúp biến cảm giác thành judgment. Với support answer, mình có thể chấm factual accuracy, completeness, tone, citation quality, policy compliance và việc answer có hỏi thêm thông tin thiếu thay vì bịa hay không. Với code generation, mình có thể kiểm correctness, security, readability, test coverage và độ hợp với codebase hiện có. Rubric ban đầu không cần phức tạp. Nó cần đủ rõ để hai reviewer có thể bàn về disagreement thay vì chỉ nói “mình thích câu này hơn.”
Automated check hữu ích, nhưng nên khiêm tốn. Exact match có thể hợp với structured extraction, nhưng fail với writing mở. LLM-as-judge có thể giúp so sánh answer ở scale lớn, nhưng nó có thể mang bias, bỏ lỡ domain nuance, hoặc đánh giá quá cao lời giải thích trôi chảy. Unit test có thể bắt formatting rule và required field. Retrieval metric có thể kiểm document đúng có được tìm ra không. Human review vẫn quan trọng, nhất là flow rủi ro cao nơi sai một cách nghe có lý còn nguy hiểm hơn thiếu sót rõ ràng.
Regression testing là nơi evaluation trở thành thói quen. Mỗi lần đổi prompt, nâng model, chỉnh retrieval hoặc sửa system instruction đều có thể fix một case và làm hỏng case khác. Không có eval set ổn định, team lái bằng trí nhớ. Có nó, team hỏi được câu bình tĩnh hơn: thay đổi này có cải thiện case mình quan tâm mà không phá behavior cũ không? Điều này ít hào nhoáng hơn demo, nhưng gần engineering hơn nhiều.
Performance không chỉ là chất lượng answer. Latency đổi cảm giác của user. Cost quyết định feature có scale được không. Token usage quyết định long context còn affordable không. Refusal behavior ảnh hưởng user trust. Safety behavior ảnh hưởng legal và operational risk. Một model tốt hơn một chút về quality nhưng chậm gấp đôi có thể không tốt hơn cho product thật. Dashboard evaluation nên phản ánh trade-off mà business và user sẽ sống cùng.
Production feedback khép vòng lặp. User bỏ flow, sửa draft do AI viết, thumbs-down answer, gọi support, retry prompt, hoặc lặng lẽ ngừng dùng feature. Log, PostHog event, manual review queue và incident note đều có thể chỉ ra chỗ offline eval chưa chạm tới thực tế. Mục tiêu không phải nhìn user bằng sự nghi ngờ. Mục tiêu là học nơi system giúp được, nơi nó đi quá xa, và nơi các eval example tiếp theo nên đến từ đâu.
Tôi tin AI feature hơn khi team có thể cho thấy những vết xước trong evaluation của họ. Không chỉ best example, mà cả case đã fail, rule họ thêm, model change họ từ chối, và trade-off họ chấp nhận. Nếu bạn đang build với AI, câu hỏi hữu ích nhất có thể không phải “model nào thông minh nhất?” Mà là “điều gì sẽ thuyết phục mình rằng behavior này đủ đáng tin cho user này, trong workflow này, vào hôm nay?”