Posted inAI

Đánh Giá LLM: Phương Pháp và Công Cụ Thực Tế Để Đo Chất Lượng Mô Hình AI Trên Production

AI tutorial - IT technology blog
AI tutorial - IT technology blog

Bối Cảnh & Tại Sao Đánh Giá LLM Lại Quan Trọng

Bạn triển khai một tính năng AI. Người dùng bắt đầu phàn nàn rằng bot trả lời sai. Bạn kiểm tra log — model chạy bình thường, trả về 200 OK, độ trễ ổn. Nhưng câu trả lời thì vô nghĩa. Đó chính là khoảng trống mà đánh giá LLM sinh ra để lấp đầy.

Kiểm thử phần mềm truyền thống mang tính nhị phân: hàm có trả về đúng giá trị không? LLM không hoạt động theo cách đó. Một mô hình có thể đưa ra câu trả lời trôi chảy, nghe có vẻ tự tin nhưng thực ra sai về mặt thực tế, lạc đề, hoặc độc hại. Nếu không có đánh giá có cấu trúc, bạn đang mò mẫm trong bóng tối trên production.

Tôi học bài học này theo cách khó nhất với một bot hỗ trợ khách hàng. Thời gian phản hồi tuyệt vời, uptime hoàn hảo, và tôi nghĩ hệ thống đang rất ổn — cho đến khi một manager chuyển cho tôi ảnh chụp màn hình bot nói với khách hàng rằng bảo hành của họ đã hết hạn trong khi thực tế chưa hết. Model bị ảo giác. Không có gì trong pipeline giám sát của tôi phát hiện ra điều đó.

Sau khi xây dựng lại tầng đánh giá từ đầu, tôi đã vận hành thiết lập này trên production khoảng sáu tháng. Tỷ lệ phản hồi lỗi giảm từ khoảng 8% xuống dưới 2% trên lượng traffic được lấy mẫu. Đây là những thành phần thực sự tạo ra sự khác biệt.

Bạn Thực Sự Đang Đo Cái Gì?

Đánh giá LLM chia thành hai nhóm lớn:

  • Dựa trên tham chiếu: Bạn có sẵn câu trả lời đúng và so sánh đầu ra của model với nó (khớp chính xác, BLEU, ROUGE, độ tương đồng ngữ nghĩa).
  • Không cần tham chiếu: Không có ground truth — bạn đánh giá các thuộc tính như tính mạch lạc, độ liên quan, độ trung thực, hoặc mức độ an toàn bằng cách dùng một model khác làm giám khảo (LLM-as-judge).

Với hầu hết các ứng dụng production, bạn sẽ cần cả hai. Đánh giá dựa trên tham chiếu bắt được các lỗi hồi quy về thực tế; đánh giá không cần tham chiếu bắt được giọng văn, định dạng và chất lượng lập luận.

Cài Đặt: Dựng Stack Đánh Giá

Hai thư viện tôi dùng thường xuyên nhất là DeepEval (kiểm thử LLM đa năng) và RAGAS (chuyên biệt cho pipeline RAG). Cài cả hai vào virtual environment của dự án:

pip install deepeval ragas openai anthropic

DeepEval tích hợp với pytest, nên các đánh giá chạy như một phần trong pipeline CI — đúng là nơi chúng cần có mặt. RAGAS không phụ thuộc framework và hoạt động với LangChain, LlamaIndex, hoặc Python thuần.

Dành Riêng Cho Ứng Dụng RAG

Nếu ứng dụng của bạn dùng retrieval-augmented generation, RAGAS cung cấp bốn chỉ số cốt lõi ngay từ đầu:

  • Faithfulness (Độ trung thực): Câu trả lời có bám sát ngữ cảnh đã truy xuất không?
  • Answer Relevancy (Độ liên quan của câu trả lời): Câu trả lời có thực sự liên quan đến câu hỏi không?
  • Context Precision (Độ chính xác ngữ cảnh): Các đoạn văn bản đúng có được truy xuất không?
  • Context Recall (Độ bao phủ ngữ cảnh): Tất cả các đoạn cần thiết có được đưa vào không?
pip install ragas datasets

Cấu Hình: Định Nghĩa Metrics và Test Case

Xây Dựng Bộ Test DeepEval

Bước quan trọng nhất là xây dựng bộ dữ liệu vàng (golden dataset) — tập hợp các đầu vào kèm đầu ra kỳ vọng hoặc tiêu chí đánh giá. Đừng bỏ qua bước này. Chỉ 50 test case được chọn kỹ còn bắt được nhiều lỗi hồi quy hơn 1.000 test case ngẫu nhiên.

from deepeval import evaluate
from deepeval.metrics import AnswerRelevancyMetric, FaithfulnessMetric, HallucinationMetric
from deepeval.test_case import LLMTestCase

# Định nghĩa test case
test_case = LLMTestCase(
    input="What is the warranty period for Product X?",
    actual_output="Product X comes with a 2-year warranty.",
    expected_output="Product X has a 2-year warranty from the date of purchase.",
    retrieval_context=[
        "Product X warranty: 2 years from date of purchase, covering manufacturing defects."
    ]
)

# Cấu hình metrics
answer_relevancy = AnswerRelevancyMetric(threshold=0.7)
faithfulness = FaithfulnessMetric(threshold=0.8)
hallucination = HallucinationMetric(threshold=0.2)  # càng thấp càng tốt

# Chạy đánh giá
evaluate([test_case], [answer_relevancy, faithfulness, hallucination])

Việc chọn ngưỡng quan trọng hơn hầu hết các hướng dẫn thừa nhận. Quá lỏng thì bạn không bắt được gì. Quá chặt thì mỗi lần deploy lại kích hoạt cảnh báo giả — team bắt đầu bỏ qua các lỗi CI, và như vậy thì mất hết ý nghĩa. Tôi bắt đầu ở mức 0.7 cho tất cả, rồi siết dần từng metric khi tôi biết được khoảng điểm nào thực sự dự đoán được khiếu nại của người dùng.

Chạy RAGAS Trên Pipeline RAG

from datasets import Dataset
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision, context_recall

# Đầu ra từ pipeline — thu thập từ các lần chạy thực tế
data = {
    "question": ["How do I reset my password?"],
    "answer": ["Go to Settings > Security > Reset Password and follow the steps."],
    "contexts": [[
        "To reset your password: navigate to Settings, click Security, then Reset Password."
    ]],
    "ground_truth": ["Users can reset their password via Settings > Security > Reset Password."]
}

dataset = Dataset.from_dict(data)

result = evaluate(
    dataset,
    metrics=[faithfulness, answer_relevancy, context_precision, context_recall]
)

print(result)
# Kết quả: {'faithfulness': 0.97, 'answer_relevancy': 0.89, ...}

LLM-as-Judge Cho Chất Lượng Mở

Một số thứ khó đưa vào chỉ số số học — giọng văn, tính chuyên nghiệp, sự phù hợp văn hóa. Với những trường hợp này, tôi dùng một model riêng làm giám khảo. Mấu chốt là viết một rubric chặt chẽ, không mơ hồ:

import anthropic

client = anthropic.Anthropic()

def judge_response(question: str, answer: str) -> dict:
    prompt = f"""Bạn là một người đánh giá chất lượng nghiêm khắc. Hãy chấm điểm câu trả lời AI này theo thang 1-5.

Tiêu chí:
- Độ chính xác (1-5): Thông tin có đúng không?
- Giọng văn (1-5): Có chuyên nghiệp và hữu ích không?
- Sự đầy đủ (1-5): Có trả lời đầy đủ câu hỏi không?

Câu hỏi: {question}
Câu trả lời: {answer}

Chỉ trả về một đối tượng JSON: {{"accuracy": X, "tone": X, "completeness": X, "reasoning": "giải thích ngắn gọn"}}"""

    response = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=256,
        messages=[{"role": "user", "content": prompt}]
    )
    
    import json
    return json.loads(response.content[0].text)

# Sử dụng
scores = judge_response(
    "What's the refund policy?",
    "We offer a 30-day money-back guarantee on all products."
)
print(scores)

Một lưu ý quan trọng: LLM giám khảo không hoàn hảo. Chúng có xu hướng thiên vị câu trả lời dài hơn, nghe có vẻ tự tin hơn — dù câu trả lời ngắn hơn đôi khi chính xác hơn. Hãy đối chiếu đầu ra của giám khảo với đánh giá của con người ít nhất mỗi tháng một lần.

Xác Minh & Giám Sát: Duy Trì Chất Lượng Ổn Định Theo Thời Gian

Tích Hợp Đánh Giá Vào CI/CD

DeepEval đi kèm plugin pytest. Thêm đoạn này vào bộ test và nó sẽ chặn các lần deploy bị hồi quy xuống dưới ngưỡng của bạn:

# tests/test_llm_quality.py
import pytest
from deepeval import assert_test
from deepeval.metrics import AnswerRelevancyMetric
from deepeval.test_case import LLMTestCase

@pytest.mark.parametrize("test_case", load_golden_dataset())
def test_answer_quality(test_case):
    metric = AnswerRelevancyMetric(threshold=0.75)
    assert_test(test_case, [metric])

deepeval test run tests/test_llm_quality.py

Tôi chạy lệnh này trên mọi PR có chạm vào prompt template, logic truy xuất, hoặc phiên bản model. Nó đã bắt được ít nhất hàng chục lỗi hồi quy tinh vi trước khi chúng tới tay người dùng.

Giám Sát Production Bằng Lấy Mẫu

Chạy đánh giá đầy đủ trên mỗi request production rất tốn kém. Thay vào đó, hãy lấy mẫu một phần traffic thực và đánh giá bất đồng bộ:

import random
import asyncio

async def maybe_evaluate(question: str, answer: str, context: list[str]):
    # Đánh giá 5% traffic production
    if random.random() > 0.05:
        return
    
    scores = await run_ragas_async(question, answer, context)
    
    # Ghi vào hệ thống giám sát
    log_metric("llm.faithfulness", scores["faithfulness"])
    log_metric("llm.answer_relevancy", scores["answer_relevancy"])
    
    # Cảnh báo nếu điểm giảm xuống dưới ngưỡng
    if scores["faithfulness"] < 0.6:
        send_alert(f"Faithfulness giảm xuống {scores['faithfulness']:.2f}")

Các Chỉ Số Cần Theo Dõi Theo Thời Gian

Xây dựng một dashboard đơn giản với các tín hiệu này — thậm chí bắt đầu bằng một bảng tính cũng được:

  • Điểm faithfulness (trung bình hàng tuần) — bộ phát hiện ảo giác
  • Điểm answer relevancy — đo lường độ lệch chủ đề
  • Tỷ lệ thumbs-up/thumbs-down của người dùng — ground truth từ người dùng thực
  • Tỷ lệ escalation — bot thất bại và chuyển sang người hỗ trợ bao nhiêu lần
  • Latency p95 — lỗi hồi quy chất lượng thường đi kèm với tăng vọt độ trễ khi đổi model

Điểm tự động và phản hồi người dùng kết hợp lại đáng tin cậy hơn từng cái riêng lẻ. Tôi từng thấy faithfulness của RAGAS đứng trên 0.9 trong khi tỷ lệ thumbs-down tăng dần tuần này qua tuần khác — hóa ra model đang trung thực trích dẫn ngữ cảnh đã lỗi thời sáu tháng. Chạy cả hai tín hiệu bắt được vấn đề trong vòng một tuần; chỉ dùng một tín hiệu thì không phát hiện ra được.

Khi Điểm Giảm Sút: Danh Sách Kiểm Tra Gỡ Lỗi

  1. Kiểm tra xem model nền có bị cập nhật bởi nhà cung cấp không — các thay đổi âm thầm xảy ra nhiều hơn vendor thừa nhận. Nếu cần kiểm soát hành vi model chặt chẽ hơn, hãy cân nhắc fine-tuning trên tập dữ liệu riêng.
  2. Xem lại các thay đổi prompt template gần đây. Chỉ thêm một câu cũng có thể làm thay đổi hành vi theo những cách không lộ ra cho đến khi bạn nhìn vào phần đuôi của phân phối điểm.
  3. Kiểm tra pipeline truy xuất — context precision thấp có nghĩa là model đang nhận các đoạn văn không liên quan.
  4. Nhìn thẳng vào các test case thất bại, không chỉ nhìn vào điểm tổng hợp. Các pattern trong lỗi thường chỉ ra nguyên nhân gốc rễ nhanh hơn bất kỳ chỉ số tóm tắt nào.

Đánh giá không phải là việc cài đặt một lần rồi thôi. Đó là một vòng phản hồi bạn duy trì khi ứng dụng phát triển và model thay đổi. Hãy bắt đầu nhỏ — 20 ví dụ được gán nhãn tốt với hai hoặc ba metrics còn hiệu quả hơn một framework phức tạp mà bạn không bao giờ thực sự duy trì. Chỉ thêm độ phức tạp sau khi bạn đã xác định được tín hiệu nào thực sự dự đoán được sự hài lòng của người dùng thực sự trong bối cảnh của bạn.

Share:
Tags: