Đánh giá LLM: Chỉ số, Khung làm việc và Những gì Thực sự Hiệu quả năm 2026

Đánh giá LLM là sự khác biệt giữa "có vẻ ổn" và "tôi có thể chứng minh nó hoạt động." Nếu bạn đang triển khai các tính năng được hỗ trợ bởi LLM cho người dùng mà không có quy trình đánh giá hệ thống, về cơ bản bạn đang triển khai mã chưa được kiểm thử, ngoại trừ việc các chế độ lỗi là ảo giác (hallucinations), độc hại và câu trả lời sai lầm thầm lặng thay vì các dấu vết ngăn xếp (stack traces).

Hướng dẫn này bao gồm mọi thứ: chỉ số, phương pháp, khung làm việc, thiết kế quy trình và tuân thủ Đạo luật AI của EU. Không thiên vị nhà cung cấp, không nội dung sáo rỗng.

Tổng quan nhanh

Trước khi đi vào chi tiết, đây là bức tranh toàn cảnh trong một bảng duy nhất.

Bây giờ hãy cùng phân tích từng phần.

Đánh giá LLM là gì (và Tại sao Nó Quan trọng vào năm 2026)?

Đánh giá LLM là quy trình hệ thống đo lường và chấm điểm chất lượng đầu ra của các mô hình ngôn ngữ lớn dựa trên các tiêu chí xác định, độ chính xác, mức độ liên quan, an toàn và độ trung thực đối với dữ liệu nguồn. Nó bao gồm các chỉ số tự động, chấm điểm LLM-as-a-judge và xem xét của con người để đảm bảo các ứng dụng hỗ trợ LLM cung cấp kết quả đáng tin cậy trong môi trường sản xuất.

Tại sao điều này lại quan trọng ngay bây giờ? Vì hai lý do. Thứ nhất, LLM đã chuyển từ nguyên mẫu sang các tính năng sản xuất mà người dùng thực tế phụ thuộc vào. Một chatbot ảo giác về chính sách công ty hoặc một hệ thống RAG trích dẫn các tài liệu không tồn tại không còn là lỗi demo vui nhộn nữa, mà là vé hỗ trợ kỹ thuật, rủi ro pháp lý hoặc mất khách hàng.

Thứ hai, việc thực thi Đạo luật AI của EU bắt đầu vào tháng 8 năm 2026. Nếu hệ thống AI của bạn phục vụ người dùng EU, bạn sẽ cần các thực hành đánh giá được ghi chép lại, không chỉ là một tin nhắn Slack nói rằng "tôi đã thử vài prompt và nó trông ổn."

Hầu hết các đội vẫn đang làm cái mà bạn có thể gọi là "đánh giá dựa trên cảm tính" (vibes-based evaluation), kiểm tra ngẫu nhiên một vài đầu ra trong sân chơi (playground) và quyết định rằng nó đủ tốt. Điều đó hiệu quả khi LLM là các thử nghiệm. Nó không hiệu quả khi chúng là các tính năng.

Đánh giá trả lời ba câu hỏi: Đầu ra có chính xác không? Có an toàn không? Có hữu ích không? Phần còn lại của hướng dẫn này sẽ chỉ cho bạn cách trả lời cả ba câu hỏi một cách hệ thống.

Một điểm phân biệt quan trọng: hướng dẫn này bao gồm đánh giá ứng dụng, kiểm thử cách sản phẩm hỗ trợ LLM của bạn hoạt động trên các tác vụ thực tế. Điều này khác với đánh giá mô hình (các điểm chuẩn tiền huấn luyện như MMLU), vốn cho bạn biết cách một mô hình nền tảng hoạt động chung chung nhưng hầu như không nói gì về cách nó sẽ hoạt động trong ứng dụng cụ thể của bạn.

Tóm lại: Nếu bạn đang triển khai các tính năng LLM mà không có đánh giá hệ thống, bạn đang bay trong mù mịt. Câu hỏi không phải là có nên đánh giá hay không, mà là đánh giá như thế nào.

Chỉ số Đánh giá LLM: Đo lường Cái gì và Khi nào

Các chỉ số bạn theo dõi hoàn toàn phụ thuộc vào những gì bạn đang xây dựng. Một chatbot cần đánh giá khác với một trình tạo mã. Dưới đây là một phân loại thực tế được tổ chức theo trường hợp sử dụng, không phải theo bảng chữ cái.

Chỉ số Tương đồng Văn bản (Khi bạn có Câu trả lời Tham chiếu)

Các chỉ số cổ điển này so sánh văn bản được tạo ra với một tham chiếu đã biết là đúng:

• BLEU đo lường độ chính xác n-gram, tức là có bao nhiêu chuỗi từ trong đầu ra khớp với tham chiếu. Ban đầu được thiết kế cho dịch máy.
• ROUGE đo lường độ bao phủ (recall), tức là có bao nhiêu nội dung tham chiếu xuất hiện trong đầu ra. Phổ biến cho các tác vụ tóm tắt.
• BERTScore sử dụng các embedding ngữ cảnh để đo lường sự tương đồng ngữ nghĩa, nắm bắt các cách diễn đạt lại mà BLEU và ROUGE bỏ sót.

Vấn đề là? Những chỉ số này chỉ hoạt động khi bạn có câu trả lời thực tế (ground truth) để so sánh. Hãy bỏ qua BLEU cho việc tạo sinh mở, vì nó phạt việc diễn đạt sáng tạo, điều mà bạn mong muốn từ một chatbot tốt.

Chỉ số Đánh giá Ngữ nghĩa (Khi bạn Cần Ý nghĩa, Không phải Khớp Chính xác)

Đối với việc tạo sinh mở, bạn cần các chỉ số đánh giá ý nghĩa:

• Mức độ liên quan của câu trả lời chấm điểm xem phản hồi có thực sự giải quyết câu hỏi của người dùng hay không.
• Tính mạch lạc đo lường mức độ logic của dòng chảy đầu ra.
• Sự ngắn gọn gắn cờ các phản hồi dài dòng không cần thiết.
• G-Eval là tùy chọn linh hoạt: bạn định nghĩa các tiêu chí đánh giá tùy chỉnh bằng ngôn ngữ tự nhiên, và một giám khảo LLM chấm điểm đầu ra sử dụng lập luận chuỗi suy nghĩ (chain-of-thought). Đây là nơi hầu hết các đội dành thời gian của họ vào năm 2026.

Chỉ số Dành riêng cho RAG

Nếu bạn đang xây dựng hệ thống tạo sinh tăng cường truy xuất (RAG), bạn đang đánh giá hai thành phần: bộ truy xuất (retriever) và bộ tạo sinh (generator). Khung làm việc Ragas định nghĩa bốn chỉ số cốt lõi:

• Độ trung thực (Faithfulness), Câu trả lời có dựa trên ngữ cảnh được truy xuất không? Điều này giúp phát hiện ảo giác.
• Mức độ liên quan của ngữ cảnh, Bộ truy xuất có lấy đúng tài liệu không?
• Độ bao phủ ngữ cảnh (Context recall), Bộ truy xuất có tìm thấy TẤT CẢ các tài liệu liên quan không?
• Mức độ liên quan của câu trả lời, Phản hồi có thực sự giải quyết truy vấn không?

Chỉ số An toàn và Tuân thủ

Những chỉ số này bảo vệ người dùng và công ty của bạn:

• Tỷ lệ ảo giác, độ chính xác thực tế so với các nguồn đã biết
• Phát hiện độc hại, nội dung gây hại, xúc phạm hoặc không phù hợp
• Đo lường thiên kiến, sự đối xử khác biệt giữa các nhóm nhân khẩu học
• Phát hiện rò rỉ PII, dữ liệu cá nhân xuất hiện trong đầu ra

Chỉ số Nào cho Ứng dụng Nào?

Đây là bảng mà không hướng dẫn của nhà cung cấp nào đưa cho bạn. Thay vì liệt kê mọi chỉ số theo bảng chữ cái, hãy khớp loại ứng dụng của bạn với các chỉ số thực sự quan trọng:

Tóm lại: Đừng đo lường mọi thứ. Chọn 3-5 chỉ số phù hợp với LOẠI ứng dụng của bạn và tập trung vào đó.

Bạn Thực sự Chạy Đánh giá Như Thế Nào? (Ba Phương pháp)

Có ba cách để đánh giá đầu ra LLM. Hầu hết các đội sản xuất sử dụng cả ba, nhưng với tỷ lệ rất khác nhau.

Chỉ số Tự động (Nhanh, Rẻ, Hạn chế)

Chấm điểm dựa trên kịch bản sử dụng các chỉ số như BLEU, ROUGE, khớp chính xác hoặc mẫu regex. Bạn viết một bài kiểm tra, nó chạy trong vài mili giây và bạn nhận được kết quả đạt/không đạt.

Ưu điểm: nó nhanh, có thể tái tạo và gần như miễn phí. Nhược điểm: các chỉ số này không thể đánh giá sự tinh tế, sáng tạo hoặc tính hữu ích trong thế giới thực. Một phản hồi có thể đạt điểm hoàn hảo trên ROUGE nhưng vẫn vô dụng đối với người dùng.

Sử dụng chỉ số tự động cho kiểm thử hồi quy, cổng chặn CI/CD và sàng lọc khối lượng lớn nơi bạn cần tốc độ hơn chiều sâu.

LLM-as-a-Judge (Mặc định của năm 2026)

Đây là nơi ngành công nghiệp đã hạ cánh. Bạn sử dụng một LLM riêng biệt, thường là GPT-4o hoặc Claude, để chấm điểm đầu ra dựa trên tiêu chí của bạn. Mô hình G-Eval hoạt động như sau: định nghĩa tiêu chí đánh giá của bạn bằng ngôn ngữ tự nhiên, cung cấp cho giám khảo các tiêu chí cộng với trường hợp kiểm thử, và nó tạo ra lập luận chuỗi suy nghĩ cộng với điểm số.

Nghiên cứu từ Zheng et al. cho thấy tương quan khoảng 81% với điểm số của con người, đủ tốt cho đánh giá hàng ngày khi bạn hiểu các chế độ lỗi (sẽ nói thêm ở phần tiếp theo).

Sử dụng LLM-as-a-judge cho việc tạo sinh mở, đánh giá chất lượng chủ quan và các tiêu chí tùy chỉnh không thể được nắm bắt bởi các chỉ số đơn giản.

Đánh giá của Con người (Tiêu chuẩn Vàng, Không thể Mở rộng)

Các chuyên gia xem xét chấm điểm đầu ra sử dụng bảng rubric, thang đo Likert hoặc kiểm thử mù A/B. Không gì sánh bằng việc một con người đọc một phản hồi và nói "cái này thực sự hữu ích" hoặc "cái này sẽ làm người dùng bối rối."

Vấn đề: nó tốn $5-50 mỗi lần đánh giá, mất vài phút thay vì vài mili giây, và bạn không thể chạy nó cho mọi yêu cầu. Sử dụng đánh giá của con người để hiệu chỉnh LLM-as-judge của bạn, kiểm toán tuân thủ và xác thực các trường hợp biên.

Lựa chọn Phương pháp của Bạn

Tóm lại: Sử dụng LLM-as-a-judge cho 80% lượt đánh giá của bạn, chỉ số tự động cho cổng chặn CI/CD và xem xét của con người cho hiệu chỉnh và tuân thủ. Đó là chiến lược của năm 2026.

LLM-as-a-Judge: Cách hoạt động, Khi nào thất bại

LLM-as-a-judge đã trở thành phương pháp đánh giá mặc định vì lý do chính đáng: nó linh hoạt, tương đối rẻ và tương quan tốt với phán đoán của con người. Nhưng nó có những điểm mù thực sự mà các hướng dẫn của nhà cung cấp thường bỏ qua.

Cách G-Eval Hoạt động

Mô hình này khá đơn giản. Bạn định nghĩa thế nào là "tốt" bằng ngôn ngữ tự nhiên, LLM giám khảo đọc tiêu chí của bạn cùng với đầu ra đang được đánh giá, suy luận từng bước và tạo ra điểm số.

Dưới đây là một ví dụ thực tế sử dụng triển khai G-Eval của DeepEval:

from deepeval.metrics import GEval
from deepeval.test_case import LLMTestCase, LLMTestCaseParams

correctness_metric = GEval(
    name="Correctness",
    criteria="Determine if the output is factually correct based on the expected output.",
    evaluation_params=[
        LLMTestCaseParams.ACTUAL_OUTPUT,
        LLMTestCaseParams.EXPECTED_OUTPUT,
    ],
    threshold=0.7,
)

test_case = LLMTestCase(
    input="What is the capital of France?",
    actual_output="Paris is the capital of France.",
    expected_output="The capital of France is Paris.",
)

correctness_metric.measure(test_case)
print(f"Score: {correctness_metric.score}")  # 0.0 to 1.0
print(f"Reason: {correctness_metric.reason}")

Bạn có thể định nghĩa bất kỳ tiêu chí nào: tính chính xác, sự hữu ích, tính chuyên nghiệp, tuân thủ giọng điệu thương hiệu, và LLM giám khảo sẽ chấm điểm dựa trên đó.

Các Thiên kiến Đã biết (Những gì Hướng dẫn Nhà cung cấp Không nói với Bạn)

Đây là nơi hầu hết các hướng dẫn đánh giá dừng lại. Họ chỉ cho bạn cách thiết lập và tiếp tục. Nhưng các giám khảo LLM có những thiên kiến hệ thống có thể âm thầm làm hỏng kết quả đánh giá của bạn:

• Thiên kiến vị trí: Khi so sánh hai đầu ra (kiểm thử A/B), giám khảo LLM luôn ưu tiên tùy chọn được trình bày đầu tiên. Đổi thứ tự và "người chiến thắng" thay đổi.
• Thiên kiến tự ưu tiên: GPT-4 đánh giá đầu ra của GPT-4 cao hơn so với cách Claude đánh giá những đầu ra tương tự, và ngược lại. Giám khảo ưu tiên họ mô hình của chính mình.
• Thiên kiến dài dòng: Các phản hồi dài hơn nhận điểm cao hơn bất kể chất lượng thực tế. Một câu trả lời 500 từ đạt điểm cao hơn một câu trả lời 100 từ nói cùng điều đó rõ ràng hơn.
• Thiên kiến neo giữ: Nếu bạn hiển thị cho giám khảo các điểm số hoặc ví dụ trước đó, các đánh giá subsequent bị kéo về phía các điểm neo đó.

Giảm thiểu Thiên kiến Giám khảo

Những thiên kiến này có thể quản lý được một khi bạn biết về chúng:

1. Ngẫu nhiên hóa thứ tự tùy chọn trong so sánh A/B (khắc phục thiên kiến vị trí)
2. Sử dụng một họ mô hình khác làm giám khảo so với bộ tạo sinh của bạn (khắc phục thiên kiến tự ưu tiên)
3. Bao gồm hướng dẫn chuẩn hóa độ dài trong tiêu chí chấm điểm của bạn (khắc phục thiên kiến dài dòng)
4. Chạy hội đồng đa giám khảo, sử dụng 2-3 LLM khác nhau và lấy điểm trung bình cho các đánh giá quan trọng

Tóm lại: LLM-as-a-judge hoạt động tốt một cách đáng ngạc nhiên, nhưng chỉ khi bạn biết các điểm mù của nó. Luôn xác thực với điểm số của con người trên trường hợp sử dụng cụ thể của bạn trước khi tin tưởng hoàn toàn.

Đánh giá Hệ thống RAG: Độ trung thực, Mức độ Liên quan và Độ bao phủ

Đánh giá RAG là trường hợp sử dụng đánh giá phổ biến nhất vào năm 2026, và nó hoàn toàn khác với việc đánh giá một LLM độc lập. Bạn đang kiểm thử hai thành phần: bộ truy xuất và bộ tạo sinh, và lỗi ở bất kỳ thành phần nào cũng tạo ra đầu ra kém.

Bốn Chỉ số Cốt lõi

• Độ trung thực (Faithfulness), Câu trả lời được tạo ra có thực sự dựa trên ngữ cảnh được truy xuất không? Một phản hồi nghe có vẻ đúng nhưng bao gồm thông tin không có trong các tài liệu được truy xuất là một ảo giác. Đây là chỉ số quan trọng nhất của bạn.
• Mức độ liên quan của ngữ cảnh, Bộ truy xuất có lấy các tài liệu thực sự liên quan đến truy vấn không? Rác vào, rác ra.
• Độ bao phủ ngữ cảnh (Context recall), Bộ truy xuất có tìm thấy TẤT CẢ các tài liệu liên quan không, hay nó đã bỏ sót ngữ cảnh quan trọng?
• Mức độ liên quan của câu trả lời, Ngay cả với việc truy xuất hoàn hảo, phản hồi cuối cùng có thực sự giải quyết những gì người dùng hỏi không?

Chạy Đánh giá RAG với Ragas

Ragas là khung làm việc được xây dựng riêng cho đánh giá RAG. Đây là mô hình cốt lõi:

from ragas import evaluate
from ragas.metrics import faithfulness, context_relevancy, answer_relevancy
from datasets import Dataset

# Your evaluation dataset
eval_data = {
    "question": ["What is our refund policy?"],
    "answer": ["You can request a refund within 30 days of purchase."],
    "contexts": [["Refund Policy: Customers may request a full refund within 30 days."]],
    "ground_truth": ["Customers can get a refund within 30 days."],
}

eval_dataset = Dataset.from_dict(eval_data)

result = evaluate(
    dataset=eval_dataset,
    metrics=[faithfulness, context_relevancy, answer_relevancy],
)
print(result)
# {'faithfulness': 0.95, 'context_relevancy': 0.88, 'answer_relevancy': 0.91}

Sai lầm Phổ biến trong Đánh giá RAG

Ba mô hình khiến các đội gặp rắc rối lặp đi lặp lại:

1. Chỉ đánh giá bộ tạo sinh và bỏ qua chất lượng bộ truy xuất. Câu trả lời của bạn có thể được tạo ra hoàn hảo từ các tài liệu sai.
2. Sử dụng BLEU hoặc ROUGE cho RAG, các chỉ số này hoàn toàn không thể phát hiện ảo giác. Một phản hồi có thể đạt điểm cao trên ROUGE trong khi chứa thông tin bịa đặt.
3. Không kiểm thử với các truy vấn đối kháng, các trường hợp biên phá vỡ việc truy xuất (truy vấn mơ hồ, câu hỏi ngoài phạm vi, truy vấn không có tài liệu liên quan) là nơi các hệ thống RAG thất bại nặng nề nhất.

Nếu bạn đang chọn stack phù hợp cho ứng dụng AI của mình, hãy đảm bảo cơ sở hạ tầng của bạn hỗ trợ đánh giá ngay từ đầu, việc bổ sung sau này luôn khó khăn hơn.

Tóm lại: Đánh giá RAG là bắt buộc. faithfulness và context_relevancy là hai chỉ số bắt buộc phải theo dõi. Mọi thứ khác là thứ yếu.

Đánh giá Tác nhân AI: Vượt xa Các Chỉ số Đơn lẻ

Đánh giá tác nhân là nơi mọi thứ trở nên thực sự khó khăn. Không giống như chatbot hoặc hệ thống RAG, một tác nhân thực hiện nhiều bước, sử dụng công cụ, đưa ra quyết định và có thể đi theo những hướng không mong đợi. Các chỉ số đơn lẻ truyền thống không nắm bắt được điều này.

Chỉ số Dành riêng cho Tác nhân

• Tỷ lệ hoàn thành tác vụ, Tác nhân có hoàn thành mục tiêu tổng thể không? Đây là chỉ số định hướng chính của bạn.
• Tính chính xác khi sử dụng công cụ, Nó có gọi đúng công cụ với đúng tham số không? Một tác nhân gọi truy vấn cơ sở dữ liệu với bộ lọc sai có thể "hoàn thành" tác vụ với dữ liệu sai.
• Duy trì ngữ cảnh, Tác nhân có duy trì ngữ cảnh mạch lạc qua quy trình nhiều bước không, hay nó mất dấu những gì đang làm?
• Chi phí mỗi tác vụ thành công, Các tác nhân có thể đốt cháy các cuộc gọi API. Một tác nhân mất 47 cuộc gọi LLM để hoàn thành một tác vụ lẽ ra chỉ mất 5 là một vấn đề chi phí sản xuất.
• Khôi phục lỗi, Khi một cuộc gọi công cụ thất bại hoặc trả về kết quả không mong đợi, tác nhân có thích nghi hay bị mắc kẹt trong vòng lặp?

Thách thức Kiểm thử Thống kê

Đây là điều làm cho đánh giá tác nhân khác biệt cơ bản: hành vi của tác nhân là không xác định. Chạy cùng một tác vụ mười lần và bạn có thể nhận được bảy lần thành công, hai lần hoàn thành một phần và một lần vòng lặp vô hạn. Bạn cần đánh giá thống kê, chạy mọi trường hợp kiểm thử N lần và báo cáo tỷ lệ hoàn thành, không phải đạt/không đạt.

Các khung làm việc đang bắt kịp. DeepEval hiện bao gồm các chỉ số dành riêng cho tác nhân, và AWS đã công bố các mô hình đánh giá tác nhân. Nhưng thành thật mà nói, công cụ vẫn còn sơ khai. Nếu bạn đang triển khai tác nhân AI trong sản xuất, hãy chuẩn bị xây dựng một số logic đánh giá tùy chỉnh.

Tóm lại: Đánh giá tác nhân vẫn còn sớm, nhưng tỷ lệ hoàn thành tác vụ và chi phí mỗi tác vụ là hai chỉ số bạn nên theo dõi từ ngày đầu tiên.

So sánh các Khung làm việc Đánh giá LLM

Mọi so sánh khung làm việc hiện có đều được viết bởi một nhà cung cấp xếp hạng chính họ đầu tiên. Đây là phiên bản trung lập.

Chọn Cái này Nếu...

• Bạn mới bắt đầu: DeepEval hoặc Ragas, cả hai đều miễn phí, tài liệu tốt, thiết lập nhanh
• Bạn đang sử dụng LangChain: LangSmith, tích hợp sâu khiến nó trở thành con đường ít kháng cự nhất
• Bạn cần chặn CI/CD: Braintrust, công cụ duy nhất chặn triển khai gốc khi đánh giá thất bại
• Bạn muốn khả năng quan sát tự lưu trữ: Langfuse, sự kết hợp truy vết + đánh giá mã nguồn mở tốt nhất
• Bạn cần giám sát sản xuất: Arize Phoenix, phân tích embedding và phát hiện trôi dạt mạnh nhất
• Bạn chỉ đánh giá RAG: Ragas, được xây dựng riêng, nhẹ, chỉ số RAG tốt nhất

Để xem sâu hơn về từng công cụ với phân tích giá và hướng dẫn thiết lập, hãy xem Các Công cụ Đánh giá LLM Tốt nhất [sắp ra mắt].

Tóm lại: Không có khung làm việc "tốt nhất" duy nhất. DeepEval cho chỉ số tùy chỉnh, Ragas cho RAG, Braintrust cho CI/CD, Langfuse cho khả năng quan sát tự lưu trữ. Chọn cái phù hợp với quy trình làm việc của bạn.

Xây dựng Quy trình Đánh giá của Bạn: Từ Ad-Hoc đến Tự động hóa

Hầu hết các đội xây dựng tính năng LLM đều mắc kẹt ở cái mà chúng tôi gọi là Cấp độ 1 -- kiểm tra thủ công một vài đầu ra và hy vọng điều tốt nhất. Đây là cách để tiến bộ.

Mô hình Trưởng thành Đánh giá

Xây dựng Bộ dữ liệu Vàng

Việc đánh giá của bạn chỉ tốt bằng dữ liệu kiểm thử của bạn. Bắt đầu với 50-100 ví dụ được chọn lọc thủ công đại diện cho các truy vấn người dùng thực tế, bao gồm các trường hợp biên và đầu vào đối kháng, và bao quát toàn bộ phạm vi hành vi mong đợi.

Phiên bản hóa các bộ dữ liệu của bạn. Chúng nên phát triển khi sản phẩm của bạn phát triển, các tính năng mới có nghĩa là các trường hợp kiểm thử mới. Một bộ dữ liệu vàng từ sáu tháng trước có lẽ không phản ánh những gì người dùng của bạn đang làm hôm nay.

Chất lượng kết quả đánh giá của bạn bằng với chất lượng sự thật cơ bản (ground truth) của bạn. Hãy đầu tư thời gian.

Tích hợp CI/CD

Khi bạn có bộ dữ liệu vàng, hãy kết nối nó vào quy trình triển khai của bạn. Chạy đánh giá trên mọi PR chạm vào prompt, logic truy xuất hoặc cấu hình mô hình, để mọi thay đổi kỹ thuật prompt đều được đo lường trước khi nó được shipped, không phải shipped dựa trên phỏng đoán. Đặt ngưỡng điểm, ví dụ: faithfulness >= 0.8 và hallucination_rate < 0.05, và chặn triển khai nếu chúng thất bại.

Dưới đây là thiết lập GitHub Actions tối thiểu làm điểm bắt đầu:

# .github/workflows/llm-eval.yml
name: LLM Evaluation
on:
  pull_request:
    paths: ['prompts/**', 'src/llm/**']
jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - run: pip install deepeval
      - run: deepeval test run tests/eval_suite.py
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

Điều này kích hoạt đánh giá bất cứ khi nào ai đó thay đổi tệp prompt hoặc mã liên quan đến LLM. Nếu bất kỳ chỉ số nào giảm xuống dưới ngưỡng, PR không thể merge. Đó là kiểm thử hồi quy cho các ứng dụng LLM.

Giám sát Sản xuất

Khi bạn đã ở giai đoạn sản xuất, hãy lấy mẫu và đánh giá lưu lượng trực tiếp -- 1-5% là điển hình. Theo dõi sự trôi dạt chỉ số theo thời gian, vì các bản cập nhật mô hình, thay đổi dữ liệu và hành vi người dùng thay đổi đều có thể làm giảm chất lượng mà không ai nhận thấy.

Thiết lập cảnh báo khi các chỉ số giảm xuống dưới ngưỡng. Ghi nhật ký tất cả các đánh giá để kiểm toán tuân thủ (bạn sẽ cảm ơn chính mình khi cuộc kiểm toán Đạo luật AI của EU đến). Như Gergely Orosz lưu ý, đánh giá cần phải là một quy trình liên tục, không phải một hộp kiểm khi ra mắt.

Tóm lại: Hầu hết các đội đều mắc kẹt ở Cấp độ 1 (cảm tính). Đạt đến Cấp độ 2 (bộ dữ liệu vàng) mất một ngày và thay đổi đáng kể sự tự tin của bạn trong việc triển khai các tính năng LLM.

Đạo luật AI của EU và Đánh giá LLM: Những gì Bạn cần cho Tuân thủ

Đây là phần mà không hướng dẫn đánh giá nào khác bao gồm, và với việc thực thi vào tháng 8 năm 2026 đang đến gần, đây là phần quan trọng nhất đối với các trưởng nhóm kỹ thuật và CTO.

Những gì Đạo luật AI của EU Yêu cầu

Đạo luật AI của EU (Quy định 2024/1689) phân loại các hệ thống AI theo mức độ rủi ro và áp đặt các yêu cầu tương ứng. Các hệ thống rủi ro cao cần đánh giá hệ thống, tài liệu hóa và giám sát liên tục. Ngay cả các hệ thống "rủi ro hạn chế" (nơi hầu hết các ứng dụng LLM rơi vào) cũng có nghĩa vụ minh bạch và tài liệu hóa.

Điểm mấu chốt: ngay cả khi bạn không có trụ sở tại EU, nếu hệ thống AI của bạn phục vụ người dùng EU, các quy tắc này áp dụng cho bạn. Khung phân loại rủi ro của Ủy ban Châu Âu giúp bạn xác định hệ thống của mình nằm ở đâu.

Ánh xạ Thực hành Đánh giá với Tuân thủ

Đây là cách các chỉ số đánh giá của bạn kết nối trực tiếp với các điều khoản của Đạo luật AI của EU:

Red Teaming cho Tuân thủ

Đạo luật AI của EU yêu cầu kiểm thử đối kháng cho các hệ thống rủi ro cao. Red teaming có nghĩa là cố gắng phá vỡ hệ thống của bạn một cách hệ thống:

• Tiêm prompt, Người dùng có thể thao túng prompt hệ thống không?
• Nỗ lực jailbreak, Người dùng có thể bỏ qua các hướng dẫn an toàn không?
• Thăm dò thiên kiến, Hệ thống có đối xử khác biệt với các nhóm nhân khẩu học không?
• Trích xuất dữ liệu, Người dùng có thể trích xuất dữ liệu huấn luyện hoặc PII không?

Tài liệu hóa mọi thứ: phương pháp luận, phát hiện, biện pháp giảm thiểu. Lên lịch các bài tập red team hàng quý tối thiểu.

Các bước Thực tế cho Sẵn sàng Tháng 8 năm 2026

1. Phân loại mức độ rủi ro của hệ thống AI của bạn (hầu hết các ứng dụng LLM là "rủi ro hạn chế")
2. Thiết lập các chỉ số và ngưỡng đánh giá ngay bây giờ
3. Triển khai đánh giá tự động trong CI/CD
4. Thiết lập giám sát sản xuất với ghi nhật ký kiểm toán
5. Tài liệu hóa chính thức phương pháp luận đánh giá của bạn
6. Lên lịch các bài tập red teaming thường xuyên
7. Chuẩn bị các quy trình phản ứng sự cố

Tóm lại: Ngay cả khi bạn không ở EU, Đạo luật AI đang thiết lập tiêu chuẩn toàn cầu. Xây dựng các thực hành đánh giá và tài liệu hóa ngay bây giờ giúp bạn tránh khỏi sự vội vã sau này.

Sai lầm Đánh giá Phổ biến (và Cách Tránh chúng)

Sau khi giúp các đội thiết lập quy trình đánh giá LLM, đây là những sai lầm chúng tôi thấy lặp đi lặp lại:

1. Đánh giá với dữ liệu huấn luyện của bạn, Nếu các trường hợp kiểm thử của bạn trùng lặp với những gì mô hình đã thấy trong quá trình tinh chỉnh, điểm số của bạn là vô nghĩa. Luôn sử dụng các bộ đánh giá được giữ lại (held-out).
2. Sử dụng BLEU/ROUGE cho các tác vụ mở, Các chỉ số này đo lường sự chồng chéo văn bản bề mặt. Chúng không thể phát hiện ảo giác, đánh giá sự hữu ích hoặc phán đoán chất lượng sáng tạo.
3. Tin tưởng mù quáng vào các điểm chuẩn, Nhiễm bẩn điểm chuẩn là có thật. Các mô hình được huấn luyện trên các câu hỏi MMLU đạt điểm cao trên MMLU nhưng điều đó không có nghĩa là chúng sẽ hoạt động tốt trên tác vụ cụ thể của bạn. Luôn sử dụng các đánh giá dành riêng cho ứng dụng.
4. Bỏ qua hiệu chỉnh con người, LLM-as-judge cần xác thực với điểm số của con người trên DỮ LIỆU CỦA BẠN trước khi bạn tin tưởng nó. Chạy ít nhất 50 ví dụ qua cả người xem xét con người và LLM judge, sau đó kiểm tra tương quan.
5. Đánh giá một lần, Đánh giá không phải là hộp kiểm khi ra mắt. Mô hình thay đổi, hành vi người dùng thay đổi và chất lượng truy xuất giảm sút. Hãy làm cho nó liên tục.
6. Cùng một mô hình làm giám khảo và bộ tạo sinh, Thiên kiến tự ưu tiên làm tăng điểm số. Sử dụng một họ mô hình khác để chấm điểm.
7. Không phiên bản hóa các bộ dữ liệu đánh giá của bạn, Các đánh giá của bạn nên phát triển cùng với sản phẩm của bạn. Theo dõi thay đổi, thêm các trường hợp biên mới, loại bỏ các trường hợp kiểm thử lỗi thời.
8. Bỏ qua chi phí, Chạy LLM-as-judge trên mọi yêu cầu sản xuất trở nên đắt đỏ rất nhanh. Lấy mẫu thông minh -- 1-5% lưu lượng là đủ cho giám sát.

Cách Techsy Tiếp cận Đánh giá LLM

Chúng tôi đã xây dựng các quy trình đánh giá cho các đội khởi nghiệp triển khai các tính năng LLM trên chatbot, hệ thống RAG và tác nhân AI. Sự tham gia điển hình của chúng tôi tuân theo một mô hình:

1. Kiểm toán, Chúng tôi xem xét các đầu ra LLM hiện tại của bạn, xác định các chế độ lỗi và ánh xạ vị trí của bạn trên mô hình trưởng thành
2. Lựa chọn chỉ số, Dựa trên loại ứng dụng của bạn, chúng tôi định nghĩa 3-5 chỉ số thực sự quan trọng (sử dụng khung làm việc từ hướng dẫn này)
3. Tạo bộ dữ liệu vàng, Chúng tôi xây dựng bộ dữ liệu đánh giá ban đầu của bạn, bao gồm các trường hợp biên đối kháng mà hầu hết các đội bỏ sót
4. Thiết lập quy trình, Tích hợp CI/CD với chấm điểm tự động và các cổng triển khai
5. Bàn giao, Đội của bạn sở hữu nó từ đó trở đi, với tài liệu và sổ tay vận hành

Hầu hết các đội không cần đối tác bên ngoài cho việc này, nếu bạn có một kỹ sư ML và một tuần dành riêng, hướng dẫn này cung cấp mọi thứ bạn cần. Nhưng nếu bạn thiếu thời gian, đối mặt với hạn chót tuân thủ hoặc muốn ý kiến thứ hai có kinh nghiệm về chiến lược đánh giá của mình, chúng tôi sẵn sàng giúp đỡ.

Cần giúp xây dựng quy trình đánh giá cho ứng dụng LLM của bạn? Nhận tư vấn miễn phí

Câu hỏi Thường gặp

Bạn đánh giá hiệu suất LLM như thế nào?

Bắt đầu bằng cách định nghĩa tiêu chí thành công của bạn: độ chính xác, an toàn, mức độ liên quan, hoặc bất cứ điều gì quan trọng đối với trường hợp sử dụng của bạn. Chọn 3-5 chỉ số phù hợp với loại ứng dụng của bạn (xem bảng chỉ số-ứng dụng ở trên), xây dựng bộ dữ liệu vàng với ít nhất 50 trường hợp kiểm thử và chạy đánh giá tự động sử dụng các khung làm việc như DeepEval hoặc Ragas. Xác thực điểm số tự động của bạn với phán đoán của con người trên một mẫu trước khi tin tưởng chúng.

Những chỉ số nào được sử dụng để đánh giá LLM?

Các chỉ số cốt lõi bao gồm độ trung thực, mức độ liên quan của câu trả lời và tỷ lệ ảo giác cho các hệ thống RAG; BLEU và ROUGE cho dịch thuật và tóm tắt; độc hại và thiên kiến cho an toàn; và tỷ lệ hoàn thành tác vụ cho các tác nhân. Các chỉ số phù hợp phụ thuộc vào loại ứng dụng của bạn, một chatbot cần đánh giá khác với một trình tạo mã.

LLM-as-a-judge là gì?

Một phương pháp trong đó một LLM riêng biệt (thường là GPT-4o hoặc Claude) đánh giá đầu ra của một LLM khác dựa trên các tiêu chí bạn định nghĩa. G-Eval là triển khai phổ biến nhất, sử dụng chấm điểm chuỗi suy nghĩ. Nghiên cứu cho thấy tương quan khoảng 81% với xếp hạng của con người, khiến nó trở thành mặc định thực tế cho đánh giá hàng ngày vào năm 2026.

Bạn phát hiện ảo giác trong LLM như thế nào?

Sử dụng các chỉ số độ trung thực so sánh văn bản được tạo ra với các tài liệu nguồn. Cả DeepEval và Ragas đều cung cấp phát hiện ảo giác tích hợp sẵn kiểm tra xem mọi tuyên bố trong đầu ra có dựa trên ngữ cảnh được cung cấp không. Đối với các hệ thống sản xuất, kết hợp phát hiện tự động với kiểm tra ngẫu nhiên của con người trên các đầu ra được gắn cờ.

Khung làm việc đánh giá LLM nào là tốt nhất?

Không có cái nào là tốt nhất duy nhất. DeepEval cho chỉ số tùy chỉnh và đánh giá toàn diện, Ragas cho đánh giá dành riêng cho RAG, Braintrust cho tích hợp CI/CD và chặn triển khai, LangSmith cho các đội đã sử dụng LangChain, và Langfuse cho khả năng quan sát tự lưu trữ. Chọn cái phù hợp với quy trình làm việc của bạn.

Bạn đánh giá hệ thống RAG như thế nào?

Đo lường bốn chỉ số: độ trung thực (câu trả lời có dựa trên ngữ cảnh không?), mức độ liên quan của ngữ cảnh (lấy đúng tài liệu không?), độ bao phủ ngữ cảnh (tìm thấy tất cả tài liệu liên quan không?) và mức độ liên quan của câu trả lời (giải quyết truy vấn không?). Ragas và DeepEval là các công cụ tiêu chuẩn. Quan trọng là, đánh giá cả bộ truy xuất và bộ tạo sinh, hầu hết các đội chỉ kiểm thử bộ tạo sinh và bỏ sót các lỗi truy xuất.

G-Eval là gì?

G-Eval là một khung làm việc LLM-as-a-judge sử dụng prompting chuỗi suy nghĩ để đánh giá đầu ra dựa trên các tiêu chí tùy chỉnh. Bạn mô tả thế nào là "tốt" bằng tiếng Anh đơn giản, và LLM giám khảo suy luận qua từng đầu ra và gán điểm số. Bài báo gốc của Liu et al. cho thấy sự phù hợp mạnh mẽ với đánh giá của con người trên nhiều tác vụ NLG.

Đạo luật AI của EU ảnh hưởng như thế nào đến đánh giá LLM?

Đạo luật AI của EU yêu cầu đánh giá hệ thống, tài liệu hóa và giám sát cho các hệ thống AI phục vụ người dùng EU. Các hệ thống rủi ro cao phải chứng minh độ chính xác, mạnh mẽ, minh bạch và không phân biệt đối xử thông qua các thực hành đánh giá chính thức. Ngay cả các hệ thống rủi ro hạn chế cũng có nghĩa vụ minh bạch. Việc thực thi bắt đầu vào tháng 8 năm 2026, và các yêu cầu áp dụng cho bất kỳ công ty nào phục vụ người dùng EU, bất kể bạn đặt trụ sở ở đâu.

Bạn đánh giá các tác nhân AI như thế nào?

Theo dõi tỷ lệ hoàn thành tác vụ, tính chính xác khi sử dụng công cụ, duy trì ngữ cảnh qua các bước và chi phí mỗi tác vụ thành công. Đánh giá tác nhân yêu cầu các phương pháp thống kê, chạy cùng một tác vụ nhiều lần và báo cáo tỷ lệ hoàn thành, không phải kết quả đạt/không đạt đơn lẻ. Công cụ vẫn còn sơ khai, nhưng DeepEval và AWS đều cung cấp các khung đánh giá tác nhân đang nổi lên.

Nhiễm bẩn điểm chuẩn là gì?

Khi dữ liệu huấn luyện LLM bao gồm các câu hỏi kiểm thử điểm chuẩn, làm tăng điểm số một cách nhân tạo mà không phản ánh khả năng thực sự. Đây là lý do tại sao các điểm chuẩn công khai như MMLU không nên là phương pháp đánh giá duy nhất của bạn. Các mô hình có thể đạt điểm ấn tượng trên các điểm chuẩn bị nhiễm bẩn trong khi hoạt động kém trên các tác vụ thực tế. Luôn bổ sung điểm chuẩn bằng đánh giá dành riêng cho ứng dụng trên dữ liệu của riêng bạn.

Đánh giá LLM tốn bao nhiêu?

Các công cụ mã nguồn mở như DeepEval và Ragas là miễn phí. LLM-as-a-judge tốn khoảng $0.01-0.05 mỗi lần đánh giá tùy thuộc vào mô hình giám khảo. Các nền tảng thương mại như Braintrust và LangSmith có các gói miễn phí cho các đội nhỏ và gói trả phí cho sử dụng sản xuất. Đánh giá của con người chạy $5-50 mỗi lần đánh giá. Hầu hết các đội có thể có một quy trình đánh giá vững chắc hoạt động với dưới $100/tháng.

Nguồn

• Tài liệu DeepEval, Chỉ số
• Tài liệu Ragas, Chỉ số
• Tài liệu Braintrust, Evals
• Tài liệu LangSmith, Đánh giá
• Tài liệu Langfuse, Điểm số và Đánh giá
• Tài liệu Arize Phoenix
• Đạo luật AI của EU, Văn bản đầy đủ (Quy định 2024/1689)
• Đạo luật AI của EU, Phân loại Rủi ro (Ủy ban Châu Âu)
• Judging LLM-as-a-Judge, Zheng et al., 2023
• G-Eval: NLG Evaluation using GPT-4 -- Liu et al., 2023
• How to Build an LLM Evaluation Framework, The Pragmatic Engineer