Đánh giá ứng dụng LLM như thế nào trước khi đưa vào sử dụng?

Một chatbot trả lời đúng vài câu demo chưa có nghĩa là đã sẵn sàng cho người dùng thật. Ứng dụng LLM có thể trả lời khác nhau với những input tương tự, hallucinate, dùng sai nguồn, phản hồi chậm hoặc phát sinh chi phí cao khi traffic tăng.

Direct Answer: Để đánh giá ứng dụng LLM trước khi sử dụng, hãy xây một bộ test phản ánh tình huống thực tế rồi đo ít nhất sáu nhóm tiêu chí: chất lượng câu trả lời, độ bám nguồn, an toàn, độ trễ, chi phí và mức độ cần human review. Chỉ nên triển khai khi các chỉ số đạt ngưỡng chấp nhận đã xác định trước.

Vì sao không thể đánh giá LLM giống phần mềm thông thường?

Với phần mềm truyền thống, một input thường dẫn đến một output xác định. Trong khi đó, ứng dụng LLM có tính biến thiên: cùng một yêu cầu có thể tạo ra câu trả lời khác nhau giữa các lần chạy.

Vì vậy, kiểm thử kiểu “đầu vào A phải cho chính xác chuỗi B” thường không đủ.

OpenAI khuyến nghị eval phải phản ánh đúng tác vụ thực tế, được thực hiện sớm và lặp lại thường xuyên; đồng thời không nên chỉ dựa vào các metric chung hoặc đánh giá cảm tính kiểu “trông có vẻ hoạt động tốt”.

NIST cũng đặt việc đo lường và đánh giá trong vòng đời quản trị rủi ro AI, thay vì xem evaluation là một bước cuối cùng trước khi launch.

Một quy trình hợp lý nên là:

Define → Build test set → Run → Score → Human review → Fix → Regression test

Khung 6 nhóm tiêu chí để đánh giá ứng dụng LLM

Không phải mọi ứng dụng đều cần cùng một trọng số. Chatbot tra cứu tài liệu nội bộ có thể đặt groundedness lên cao, trong khi trợ lý chăm sóc khách hàng còn phải đặc biệt chú ý tới safety và escalation.

1. Đánh giá chất lượng câu trả lời

Tiêu chí đầu tiên là ứng dụng có hoàn thành đúng công việc được giao hay không.

Không nên dùng một tiêu chí mơ hồ như “câu trả lời tốt”. Hãy tách thành những yếu tố có thể chấm được.

Ví dụ với chatbot hỗ trợ khách hàng:

• Có hiểu đúng intent không?
• Có trả lời đúng câu hỏi không?
• Có bỏ sót thông tin quan trọng không?
• Có đưa ra bước tiếp theo phù hợp không?
• Có tuân thủ định dạng yêu cầu không?

Có thể chấm theo thang đơn giản:

• 2 điểm: đạt đầy đủ.
• 1 điểm: đúng một phần.
• 0 điểm: sai hoặc không giải quyết nhiệm vụ.

Với các tác vụ phân loại hoặc trích xuất dữ liệu, nên ưu tiên metric xác định như accuracy, precision hoặc recall khi phù hợp.

Với câu trả lời tự do, có thể kết hợp rule-based scoring, LLM-as-a-judge và đánh giá của con người.

Điểm quan trọng là tiêu chí phải gắn với task success, không phải chỉ với khả năng viết câu văn tự nhiên.

2. Kiểm tra độ bám nguồn và hallucination

Với chatbot RAG hoặc ứng dụng trả lời dựa trên knowledge base, một câu trả lời nghe hợp lý vẫn có thể sai nếu model tự bổ sung thông tin ngoài tài liệu.

Nên đánh giá riêng ít nhất ba yếu tố.

Context relevance

Dữ liệu retrieval đưa vào model có thực sự liên quan tới câu hỏi không?

Nếu retrieval sai, model rất khó trả lời đúng ngay cả khi prompt tốt.

Groundedness

Các khẳng định trong câu trả lời có được hỗ trợ bởi context đã cung cấp hay không?

Nếu model đưa thêm dữ liệu không có trong nguồn, đó là tín hiệu cần kiểm tra.

Citation correctness

Nếu ứng dụng hiển thị citation hoặc nguồn tham khảo, nguồn đó có thực sự chứng minh cho câu trả lời không?

Không nên chỉ kiểm tra xem “có citation hay không”. Citation phải đúng với claim tương ứng.

NIST Generative AI Profile nhấn mạnh các rủi ro liên quan tới confabulation và tính tin cậy của nội dung sinh bởi AI, vì vậy việc đo groundedness nên được xem là một phần của quản trị rủi ro chứ không chỉ là kiểm tra UX.

3. Đánh giá safety trước khi cho người dùng thật truy cập

Test set không nên chỉ chứa những câu hỏi bình thường.

Hãy chủ động đưa vào các trường hợp bất lợi như:

• Prompt injection.
• Yêu cầu tiết lộ system prompt.
• Yêu cầu lấy dữ liệu riêng tư.
• Input cố gắng vượt policy.
• Nội dung độc hại hoặc không phù hợp.
• Câu hỏi yêu cầu model thực hiện hành động ngoài quyền hạn.
• Dữ liệu nguồn có chứa instruction độc hại.

Tính đến tháng 9/2026, OWASP đã phát hành Top 10 for LLM Applications 2026 dành cho các rủi ro bảo mật quan trọng trong ứng dụng LLM. Các phiên bản gần đây của framework này bao phủ các nhóm rủi ro như prompt injection, rò rỉ thông tin, xử lý output không an toàn và các vấn đề liên quan tới quyền hành động của hệ thống AI.

Một safety test cần kiểm tra cả hai phía:

Không làm điều nguy hiểm khi bị yêu cầu và không từ chối nhầm yêu cầu hợp lệ.

Nếu chỉ tối ưu tỷ lệ từ chối, chatbot có thể trở nên quá bảo thủ và làm giảm trải nghiệm người dùng.

4. Đo latency trong cả workflow

Một ứng dụng có câu trả lời rất tốt nhưng mất 30 giây để phản hồi có thể vẫn không đáp ứng nhu cầu sản phẩm.

Đừng chỉ đo thời gian model sinh câu trả lời. Với ứng dụng thực tế, latency có thể gồm:

Request → retrieval → reranking → model → tool → model → response

Nên theo dõi tối thiểu:

• Time to first token.
• Tổng thời gian hoàn thành.
• P50 latency.
• P95 latency.
• Latency của từng tool hoặc retrieval step.

P95 thường hữu ích vì latency trung bình có thể che giấu những request rất chậm.

Sau đó, kết hợp latency với chất lượng. Việc chọn model nhanh hơn chỉ có ý nghĩa nếu mức giảm chất lượng vẫn nằm trong ngưỡng chấp nhận.

5. Đánh giá chi phí trên mỗi task thành công

Chi phí không nên được đo đơn thuần bằng giá một triệu token.

Một workflow có thể sử dụng model rẻ nhưng gọi model năm lần cho một task, khiến tổng chi phí cao hơn một workflow dùng model mạnh nhưng chỉ gọi một lần.

Nên theo dõi:

• Input token/task.
• Output token/task.
• Cached token nếu có.
• Số model call/task.
• Số tool call.
• Số retry.
• Chi phí trung bình/task.
• Chi phí trên mỗi task đạt yêu cầu.

Chỉ số cuối cùng đặc biệt hữu ích.

Ví dụ, phiên bản B rẻ hơn 20% mỗi request nhưng tỷ lệ trả lời đạt yêu cầu thấp hơn khiến người dùng phải hỏi lại nhiều lần. Khi đó, chi phí thực tế của một task hoàn chỉnh có thể không giảm.

6. Thiết kế human review thay vì cố tự động hóa 100%

Không phải mọi output đều cần người kiểm tra.

Human review nên tập trung vào những trường hợp mà sai sót có tác động cao hoặc automated evaluator chưa đủ đáng tin.

Ví dụ:

• Model có confidence thấp.
• Nguồn retrieval mâu thuẫn.
• Câu hỏi liên quan tới quyết định quan trọng.
• Model không tìm được tài liệu hỗ trợ.
• Người dùng khiếu nại câu trả lời.
• Output chứa hành động cần phê duyệt.

OpenAI khuyến nghị kết hợp metric tự động với human judgment và dùng phản hồi của con người để hiệu chỉnh evaluator tự động.

Human review vì vậy không chỉ là “kiểm tra lại câu trả lời”. Nó còn tạo dữ liệu để cải thiện eval set.

Xây bộ test LLM như thế nào?

Một eval tốt không cần bắt đầu bằng hàng nghìn câu hỏi.

Có thể xây phiên bản đầu tiên từ các nhóm sau:

Happy path

Các yêu cầu phổ biến mà hệ thống chắc chắn phải xử lý được.

Edge case

Input thiếu dữ liệu, câu hỏi mơ hồ hoặc yêu cầu kết hợp nhiều điều kiện.

Failure case

Những lỗi đã từng xuất hiện trong quá trình test hoặc production.

Adversarial case

Prompt injection, cố lấy dữ liệu nhạy cảm hoặc yêu cầu vượt quyền.

Out-of-scope case

Câu hỏi nằm ngoài phạm vi mà chatbot được thiết kế để trả lời.

OpenAI khuyến nghị thu thập log trong quá trình phát triển vì chính các tình huống thực tế này có thể trở thành nguồn eval case hữu ích về sau.

LLM-as-a-judge có thay thế human evaluation được không?

LLM-as-a-judge hữu ích khi cần chấm số lượng output lớn theo rubric, nhưng không nên mặc định xem evaluator là ground truth.

Evaluator cũng là model nên có thể:

• Hiểu sai rubric.
• Thiên vị một kiểu câu trả lời.
• Chấm không ổn định.
• Bỏ qua lỗi chuyên môn.

Cách an toàn hơn là:

1. Xây rubric rõ ràng.
2. Cho evaluator chấm test set.
3. Cho con người chấm cùng tập dữ liệu.
4. So sánh mức độ đồng thuận.
5. Chỉnh rubric hoặc evaluator.
6. Sau đó mới tự động hóa ở quy mô lớn.

Anthropic cũng lưu ý rằng xây dựng evaluation đáng tin cậy là vấn đề khó và một bộ benchmark không nhất thiết phản ánh đầy đủ khả năng hoặc rủi ro của hệ thống trong môi trường thực tế.

Khi nào ứng dụng LLM đủ điều kiện go-live?

Không nên dùng một con số chung như “accuracy trên 90%”.

Ngưỡng phải phụ thuộc use case và mức độ rủi ro.

Một release gate có thể được định nghĩa như sau:

NIST AI RMF khuyến nghị quản trị rủi ro theo ngữ cảnh, mục tiêu và mức chấp nhận rủi ro của từng tổ chức thay vì áp dụng một tiêu chuẩn duy nhất cho mọi hệ thống.

Quy trình evaluation trước và sau khi release

Một workflow thực tế có thể gồm sáu bước:

Bước 1: Xác định điều gì được xem là “đúng”

Viết rubric và ngưỡng chấp nhận trước khi nhìn kết quả.

Bước 2: Tạo eval set đại diện

Bao gồm happy path, edge case, lỗi cũ và adversarial case.

Bước 3: Chạy baseline

Đo chất lượng, groundedness, safety, latency và cost.

Bước 4: Review lỗi

Không chỉ nhìn điểm trung bình. Phân nhóm từng loại failure để biết cần sửa retrieval, prompt, model hay business logic.

Bước 5: Regression test

Sau mỗi thay đổi model, prompt, knowledge base hoặc tool, chạy lại cùng test set.

Bước 6: Bổ sung dữ liệu production

Những câu hỏi thất bại ngoài thực tế nên trở thành test case mới.

Evaluation vì vậy không kết thúc khi ứng dụng được launch. Nó trở thành một phần của vòng đời phát triển.

Kết luận

Đánh giá ứng dụng LLM không nên chỉ dựa vào việc chatbot trả lời vài câu demo có vẻ đúng. Một hệ thống sẵn sàng sử dụng cần được kiểm tra đồng thời về task quality, groundedness, safety, latency, cost và human review.

Cách làm thực tế là xây một eval set gần với traffic thật, xác định ngưỡng pass trước, chạy baseline rồi regression test sau mỗi thay đổi. Khi evaluation trở thành một phần của development workflow, đội phát triển có thể cải thiện model hoặc prompt mà không phải đánh đổi chất lượng một cách khó kiểm soát.