Vì sao đánh giá LLM khó (non-deterministic)

Vì sao đánh giá LLM khó quan trọng

Với phần mềm truyền thống, một hàm cộng hai số luôn trả về cùng một kết quả. Bạn viết một unit test, nó xanh hay đỏ, xong. Với sản phẩm dùng mô hình ngôn ngữ lớn (LLM), thế giới đảo lộn: cùng một câu hỏi, cùng một prompt, mô hình có thể trả lời khác nhau ở mỗi lần gọi. Đầu ra là văn bản tự do, không có một "đáp án đúng" duy nhất, và chất lượng phụ thuộc vào ngữ cảnh, sắc thái, giọng điệu.

Nếu một Product Manager không nắm được vì sao eval LLM khó, cái giá phải trả rất cụ thể. Đội của bạn sẽ ship một tính năng chatbot cho ngân hàng, demo chạy đẹp trong phòng họp, nhưng khi ra thật thì mô hình bịa số dư, tư vấn sai lãi suất, hoặc trả lời cộc lốc với khách. Không ai phát hiện sớm vì không có hệ thống đo lường. Bạn đốt ngân sách token, mất niềm tin của khách hàng, và tệ nhất là không biết bản cập nhật tuần sau tốt hơn hay tệ hơn bản tuần này. Thiếu kỹ năng eval, bạn bay mù.

Một ví dụ thật ở Việt Nam: một sàn thương mại điện tử thêm trợ lý tư vấn mua hàng. Ban đầu ai cũng khen. Ba tuần sau, tỉ lệ khách bấm nút mua giảm, nhưng không ai chỉ ra được nguyên nhân vì không có chỉ số chất lượng câu trả lời. Đó chính là cái giá của việc không biết đánh giá.

Bức tranh lớn

Cốt lõi cần hiểu: đầu ra LLM là ngẫu nhiên có kiểm soát. Tham số temperature quyết định độ ngẫu nhiên. Cùng đầu vào, khác đầu ra, nên bạn không thể so sánh chuỗi ký tự y hệt. Bạn phải đánh giá theo tiêu chí chất lượng, không theo khớp tuyệt đối.

graph TD
A[Cung mot cau hoi] --> B[LLM sinh phan hoi]
B --> C[Dau ra khac nhau moi lan]
C --> D[Khong the so khop tuyet doi]
D --> E[Danh gia theo tieu chi chat luong]
E --> F[Rubric va con nguoi cham diem]
E --> G[LLM lam giam khao]

Bức tranh lớn gồm ba trục. Trục một là tính không xác định: temperature, sampling, phiên bản model đổi làm kết quả trôi. Trục hai là tính đa đáp án: một câu hỏi có nhiều câu trả lời đều đúng. Trục ba là tính chủ quan: "hay" là do con người cảm nhận. Ba trục này khiến bạn phải xây một hệ đo lường mềm, chấp nhận biên độ, thay vì một test cứng.

Ví dụ chi tiết

Hãy theo chân đội sản phẩm của một công ty fintech tại TP HCM làm trợ lý hỏi đáp về thẻ tín dụng.

Bước 1: Họ viết prompt và thử tay mười câu hỏi. Mọi thứ ổn, nên họ tự tin ship.

Bước 2: Sau khi ra mắt, họ chạy lại đúng mười câu đó để "kiểm tra". Lần này mô hình trả lời câu về phí thường niên khác hẳn lần trước, một câu bịa ra con số 350 nghìn dù thực tế là 300 nghìn. Cả đội hoang mang: code không đổi, sao kết quả đổi?

Bước 3: Một kỹ sư giải thích temperature đang để 0.8. Họ hạ về 0.2 để bớt ngẫu nhiên, nhưng nhận ra dù hạ hết mức, mô hình vẫn có thể diễn đạt khác nhau và đôi khi vẫn sai số liệu.

Bước 4: Đội quyết định không dựa vào cảm tính. Họ lập một bảng ba mươi câu hỏi kèm đáp án chuẩn do chuyên viên nghiệp vụ duyệt, rồi chấm mỗi phản hồi theo tiêu chí đúng số liệu, đúng chính sách, giọng lịch sự.

Bước 5: Lần chạy đầu, chỉ 60 phần trăm câu đạt cả ba tiêu chí. Con số này xấu, nhưng lần đầu tiên họ có sự thật để cải thiện. Sau hai vòng chỉnh prompt và thêm dữ liệu tra cứu, họ nâng lên 88 phần trăm rồi mới dám ship rộng.

Bài học: chỉ khi có thước đo, đội mới thoát khỏi tranh cãi cảm tính và cải thiện được.

Lộ trình từng bước để làm chủ

graph LR
A[Hieu tinh khong xac dinh] --> B[Co dinh temperature va seed]
B --> C[Lap bo cau hoi mau]
C --> D[Dinh nghia tieu chi cham diem]
D --> E[Chay eval lap lai]
E --> F[Doc do bien dong ket qua]
F --> G[Ra quyet dinh ship hay khong]

Bắt đầu bằng việc hiểu rõ vì sao đầu ra trôi. Sau đó cố định các yếu tố kiểm soát được như temperature và phiên bản model để giảm nhiễu. Tiếp theo lập một bộ câu hỏi mẫu đại diện cho thực tế. Kế đến định nghĩa tiêu chí chấm rõ ràng. Cuối cùng chạy lặp lại, đo độ biến động, và chỉ ship khi kết quả ổn định qua nhiều lần.

Thói quen & kỷ luật

Working mindset: Không có thước đo thì mọi ý kiến về chất lượng LLM chỉ là cảm giác, và cảm giác không giúp bạn ship an toàn.

Cần luyện tập gì (drills)

Drill 1: Lấy một prompt bất kỳ, gọi mô hình mười lần với temperature 0.7, ghi lại mười đầu ra, tự đánh dấu chỗ khác biệt và chỗ nào sai lệch nghiêm trọng.

Drill 2: Cố định temperature về 0, chạy lại năm lần, quan sát xem đầu ra có còn dao động không, và viết một đoạn ba câu giải thích vì sao.

Drill 3: Viết định nghĩa "câu trả lời đạt" cho một use case cụ thể bằng ba tiêu chí rõ ràng, rồi tự chấm năm phản hồi thật theo ba tiêu chí đó.

Checklist hành động tuần này

• [ ] Chọn một tính năng LLM đang làm và gọi nó mười lần với cùng câu hỏi
• [ ] Ghi lại các điểm khác biệt và sai lệch vào một bảng
• [ ] Viết ba tiêu chí chấm "câu trả lời đạt" cho tính năng đó
• [ ] Cố định temperature và phiên bản model trong môi trường test
• [ ] Chia sẻ phát hiện với đội để cả nhóm cùng thấy vấn đề

Chỉ số & North Star

North Star của bài này là độ ổn định và tỉ lệ đạt tiêu chí qua nhiều lần chạy. Bạn muốn thấy kết quả không dao động dữ dội và tỉ lệ đạt tăng dần.

Dấu hiệu bạn đã thành thạo

Bạn giải thích được cho một người không kỹ thuật vì sao cùng câu hỏi mô hình trả lời khác nhau. Bạn không còn hoảng khi thấy đầu ra đổi mà biết đó là bản chất. Bạn luôn hỏi "chúng ta đo bằng gì" trước khi tranh luận chất lượng. Và bạn có thói quen cố định biến số trước khi chạy so sánh.

Cạm bẫy thường gặp

Chốt lại

• Đầu ra LLM là ngẫu nhiên có kiểm soát, nên không thể đánh giá bằng khớp tuyệt đối.
• Muốn đánh giá đúng, bạn phải cố định biến số và chấm theo tiêu chí chất lượng.
• Không có thước đo thì mọi tranh luận về chất lượng chỉ là cảm tính vô ích.
• Bắt đầu nhỏ với một bộ câu hỏi mẫu và ba tiêu chí, rồi mở rộng dần.