LLM Như Một Giám Khảo: Hướng Dẫn Hoàn Chỉnh Với Ví Dụ RAG Thực Hành

So sánh các cách tiếp cận LLM-as-a-judge

Trong thực tế, các nhóm thường chọn một trong các cách tiếp cận sau tùy vào thứ họ muốn đo:

1. Chấm điểm trực tiếp để giám khảo chấm một đầu ra duy nhất theo thang số (1–5, 1–10, tùy rubric của bạn). Bạn nhận được một con số và, nếu bạn yêu cầu, một phần giải thích lập luận. Đây là điểm khởi đầu phổ biến nhất, dù có vấn đề hiệu chuẩn mà tôi sẽ quay lại sau.
2. So sánh cặp đặt hai câu trả lời cạnh nhau và yêu cầu giám khảo chọn cái tốt hơn. Cách này tránh hoàn toàn vấn đề hiệu chuẩn số vì giám khảo chỉ cần đưa ra đánh giá tương đối, không phải gán số tuyệt đối. Các nhóm thường dùng khi so sánh biến thể prompt hoặc phiên bản mô hình với nhau.
3. Đánh giá dựa trên tham chiếu cung cấp cho giám khảo cả đầu ra mô hình và câu trả lời chuẩn mực, rồi hỏi mức độ khớp. Cách này hoạt động tốt nhất cho Hỏi & Đáp thực chứng và đầu ra có cấu trúc nơi bạn đã có ground truth gán nhãn để so sánh.
4. Phân loại nhị phân giản lược phán quyết về đạt hoặc không với một thuộc tính cụ thể. Câu trả lời này có trung thực với ngữ cảnh không? Có chứa thông tin nhận dạng cá nhân không? Có tích cực không? Các kiểm tra nhị phân chạy nhanh hơn, chi phí mỗi lượt đánh giá thấp hơn và thường cho kết quả nhất quán hơn so với cách tiếp cận chấm điểm số.

Hình do Tác giả cung cấp. Bốn cách tiếp cận khác nhau của LLM như một giám khảo. 

Để có cái nhìn trực diện về điểm mạnh, trường hợp sử dụng và hạn chế, tôi đã so sánh cả bốn cách tiếp cận trong bảng sau:

Để có cái nhìn rộng hơn về các phương pháp đánh giá ngoài mô hình giám khảo, LLM Benchmarks Explained bao quát bức tranh đầy đủ.

Giám khảo LLM hoạt động như thế nào?

Về phía bên trong, đó là một cuộc gọi API đơn giản: bạn chỉ cần gói gọn nội dung muốn đánh giá (đầu ra của mô hình, truy vấn gốc của người dùng và bất kỳ ngữ cảnh truy xuất nào đã dùng trong quá trình tạo sinh) và bọc nó trong một prompt nói rõ cho mô hình giám khảo bạn quan tâm điều gì và muốn định dạng kết quả ra sao. 

Giám khảo xử lý và trả về phản hồi có cấu trúc, thường là một điểm số kèm phần lập luận giải thích vì sao chấm điểm như vậy. Chất lượng đánh giá của bạn gần như phụ thuộc hoàn toàn vào việc bạn viết thang đo (rubric) tốt thế nào. Tôi không thể nhấn mạnh điều này đủ. 

Một prompt đơn giản kiểu "hãy chấm câu trả lời này từ 1 đến 5" sẽ cho bạn các điểm số lộn xộn, vì giám khảo không có sự hiểu biết chung về việc 3 khác 4 như thế nào. Đây là lý do bạn cần nêu rõ, cụ thể, mỗi mức điểm trông ra sao và đưa ví dụ nếu có thể.

Triển khai LLM Như Một Giám Khảo

Giờ đến phần thực hành, chúng ta sẽ xây dựng một pipeline đánh giá hoàn chỉnh từ đầu: một hệ thống retrieval augmented generation (RAG) trả lời câu hỏi từ một kho tri thức nhỏ, một bộ truy vấn kiểm thử được thiết kế để kích hoạt các chế độ lỗi khác nhau, và một giám khảo LLM chấm điểm đầu ra về tính trung thực và mức độ liên quan.

Thiết lập môi trường

Bạn sẽ cần Python 3.9+ và một khóa API OpenAI, bạn có thể lấy trong bảng điều khiển OpenAI. Cài đặt các phụ thuộc:

pip install openai chromadb langchain langchain-openai langchain-community deepeval

Đặt khóa API của bạn:

import os
os.environ["OPENAI_API_KEY"] = "your-key-here"

Chúng ta dùng OpenAI cho cả trình tạo RAG và giám khảo LLM, dù sẽ là các mô hình khác nhau (GPT-4o-mini cho tạo sinh, GPT-4o cho đánh giá). Với embeddings, text-embedding-3-small là đủ cho phạm vi một hướng dẫn. Trong hệ thống sản xuất, bạn nên benchmark vài mô hình embedding trên dữ liệu miền của mình trước khi chốt.

Nếu bạn muốn tích lũy thêm kiến thức nền về RAG trước khi nhảy vào phần mã đánh giá, khóa học Retrieval Augmented Generation (RAG) với LangChain sẽ dẫn bạn qua các nền tảng căn bản.

Chuẩn bị dữ liệu và kho vector

Chúng ta cần một kho tri thức nhỏ để hệ thống RAG truy xuất. Tôi sẽ dùng một bộ đoạn văn bản về chính sách đổi trả của một công ty giả định. Bản thân nội dung không phải trọng tâm ở đây, nhưng việc có một bộ tài liệu khép kín giúp dễ dàng thấy chính xác khi nào mô hình vượt ra ngoài ngữ cảnh cung cấp (đó là chế độ lỗi mà chúng ta muốn giám khảo phát hiện).

from langchain_openai import OpenAIEmbeddings
from langchain_chroma import Chroma
from langchain.schema import Document

# Sample knowledge base
documents = [
    Document(
        page_content="All customers are eligible for a full refund within 30 days of purchase. "
        "The item must be in its original packaging and unused condition. Refunds are "
        "processed to the original payment method within 5-7 business days.",
        metadata={"source": "return_policy.pdf", "section": "refund_eligibility"}
    ),
    Document(
        page_content="Exchanges can be requested within 45 days of purchase for items of "
        "equal or lesser value. Size exchanges on clothing are free of charge. "
        "For items of greater value, the customer pays the difference.",
        metadata={"source": "return_policy.pdf", "section": "exchanges"}
    ),
    Document(
        page_content="Electronics have a 15-day return window due to rapid depreciation. "
        "Opened software and digital downloads are non-refundable. Defective electronics "
        "can be returned within 90 days with proof of defect from an authorized service center.",
        metadata={"source": "return_policy.pdf", "section": "electronics"}
    ),
    Document(
        page_content="Shipping costs for returns are covered by the company for defective items. "
        "For non-defective returns, the customer is responsible for return shipping. "
        "Free return shipping labels are available for loyalty program members regardless of reason.",
        metadata={"source": "return_policy.pdf", "section": "shipping"}
    ),
    Document(
        page_content="Gift purchases can be returned with the gift receipt for store credit only. "
        "Without a gift receipt, returns are processed at the lowest sale price in the last 90 days. "
        "Gift cards and prepaid cards are non-refundable and cannot be exchanged.",
        metadata={"source": "return_policy.pdf", "section": "gifts"}
    ),
]

# Create vector store
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Chroma.from_documents(documents, embeddings, persist_directory="./chroma_db")

print(f"Indexed {len(documents)} documents")

Năm tài liệu về chính sách đổi trả, dù không nhiều, nhưng đủ để minh họa các vấn đề truy xuất mà chúng ta quan tâm: ngữ cảnh không đầy đủ, kéo vào các đoạn không liên quan, và cơ hội phát sinh ảo giác khi mô hình cảm thấy áp lực phải đưa ra câu trả lời trọn vẹn dù ngữ cảnh không hỗ trợ đầy đủ.

Xây dựng một pipeline RAG cơ bản

Pipeline RAG truy xuất các đoạn liên quan và tạo câu trả lời. Không có gì cầu kỳ ở đây, chỉ là mẫu truy xuất rồi tạo sinh tiêu chuẩn.

from openai import OpenAI

client = OpenAI()

def rag_query(question: str, top_k: int = 2) -> dict:
    """Run a RAG query: retrieve context, generate answer."""
    
    # Retrieve
    results = vectorstore.similarity_search(question, k=top_k)
    context = "\n\n".join([doc.page_content for doc in results])
    
    # Generate
    system_prompt = """You are a helpful customer support assistant. Answer the 
    customer's question based ONLY on the provided context. If the context doesn't 
    contain enough information to answer fully, say so."""
    
    user_prompt = f"""
      Context: {context}

      Question: {question}

      Answer:
    """
    
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": user_prompt}
        ],
        temperature=0.3
    )
    
    answer = response.choices[0].message.content
    
    return {
        "question": question,
        "context": context,
        "answer": answer,
        "sources": [doc.metadata for doc in results]
    }

Tôi chọn GPT-4o-mini làm mô hình tạo sinh vì rẻ và nhanh, và chúng ta muốn tập trung vào phần đánh giá. Nhiệt độ đặt ở 0,3, giảm tính ngẫu nhiên nhưng không loại bỏ hoàn toàn. 

Và system prompt hướng dẫn rõ mô hình chỉ dùng ngữ cảnh được cung cấp, đây là thực hành tiêu chuẩn trong hệ thống RAG, dù các mô hình vẫn trượt khỏi ngữ cảnh thường xuyên hơn bạn nghĩ. Chính xác đó là điều chúng ta muốn giám khảo gắn cờ.

Hãy thử nghiệm:

result = rag_query("Can I return opened software?")
print(f"Question: {result['question']}")
print(f"Answer: {result['answer']}")
print(f"Sources: {result['sources']}")

Tạo bộ dữ liệu đánh giá

Bạn cần các ca kiểm thử bao quát những phần khác nhau của pipeline. Trong sản xuất, bạn sẽ thu thập từ truy vấn thực tế của người dùng. Với hướng dẫn này, tôi xây dựng một tập hợp cố ý bao gồm các kiểu câu hỏi mà hệ thống RAG thường vấp.

eval_questions = [
    # Straightforward questions (should be easy)
    "What is the refund window for regular purchases?",
    "Are exchanges free for clothing size changes?",
    
    # Questions requiring synthesis across chunks
    "What are my options if I received a defective laptop 60 days ago?",
    
    # Edge cases likely to cause hallucination
    "Can I get a refund for a digital download I purchased yesterday?",
    "What happens if I return a gift without the gift receipt?",
    
    # Questions where context might be incomplete
    "Do you offer refunds for international orders?",
    "Can I return an item I bought on sale?",
    
    # Adversarial or tricky questions
    "If I'm a loyalty member, do I get free return shipping even for electronics?",
]

# Generate RAG responses for all questions
eval_results = []
for q in eval_questions:
    result = rag_query(q)
    eval_results.append(result)
    print(f"Q: {q}")
    print(f"A: {result['answer'][:150]}...")
    print()

Sự pha trộn rất quan trọng. Một số câu có câu trả lời rõ ràng, trực tiếp trong tài liệu, trong khi một số yêu cầu mô hình tổng hợp thông tin từ nhiều đoạn truy xuất (câu hỏi về laptop lỗi cần cả chính sách hoàn tiền 30 ngày và điều khoản điện tử lỗi 90 ngày).

Và một vài câu, như câu hỏi về đơn hàng quốc tế, hỏi về những thứ mà kho tri thức đơn giản là không đề cập. Những câu cuối này là nơi bạn sẽ thấy ảo giác thường xuyên nhất, vì mô hình có xu hướng muốn hữu ích và lấp đầy khoảng trống bằng thông tin nghe có vẻ hợp lý nhưng không có căn cứ trong ngữ cảnh thực tế.

Để biết thêm về xây dựng và kiểm thử hệ thống RAG, bộ sưu tập Top 30 Câu Hỏi Phỏng Vấn RAG và Đáp Án là tài liệu tham khảo hữu ích.

Thiết lập giám khảo LLM

Đây là phần thú vị. Chúng ta sẽ xây hai giám khảo riêng biệt: 

• Giám khảo tính trung thực: Câu trả lời có nằm trong phạm vi của ngữ cảnh truy xuất không?
• Giám khảo mức độ liên quan: Câu trả lời có thực sự giải quyết điều đã được hỏi không?

def judge_faithfulness(question: str, context: str, answer: str) -> dict:
    """Judge whether the answer is faithful to the retrieved context."""
    
    eval_prompt = f"""
      You are an impartial judge evaluating whether an AI assistant's 
      answer is faithful to the provided context. 

      Faithfulness means every claim in the answer can be traced back to 
      information in the context. The answer should not contain information 
      that isn't supported by or inferable from the context.

      Score on a scale of 1 to 5:
      1 - The answer contains multiple claims not supported by the context
      2 - The answer contains at least one significant unsupported claim
      3 - The answer is mostly faithful but includes minor unsupported details
      4 - The answer is faithful with only trivial extrapolations
      5 - Every claim in the answer is directly supported by the context

      Context: {context}

      Question: {question}

      Answer to evaluate: {answer}

      Respond in this exact JSON format: {{"score": <int 1-5>, "reason": "<one paragraph explanation>"}}
    """

    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": eval_prompt}],
        temperature=0.0,
        response_format={"type": "json_object"}
    )
    
    import json
    return json.loads(response.choices[0].message.content)


def judge_relevance(question: str, answer: str) -> dict:
    """Judge whether the answer is relevant to the question."""
    
    eval_prompt = f"""
      You are an impartial judge evaluating whether an AI assistant's answer 
      is relevant to the user's question.

      Relevance means the answer directly addresses what the user asked. 
      A relevant answer may acknowledge limitations in available information, 
      but it should not go off-topic or provide unrelated information.

      Score on a scale of 1 to 5:
      1 - The answer does not address the question at all
      2 - The answer partially addresses the question but misses the main point
      3 - The answer addresses the question but includes significant irrelevant content
      4 - The answer addresses the question well with minor tangents
      5 - The answer directly and completely addresses the question

      Question: {question}

      Answer to evaluate: {answer}

      Respond in this exact JSON format: {{"score": <int 1-5>, "reason": "<one paragraph explanation>"}}
    """

    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": eval_prompt}],
        temperature=0.0,
        response_format={"type": "json_object"}
    )
    
    import json
    return json.loads(response.choices[0].message.content)

Một vài lựa chọn thiết kế đáng chú ý. temperature đặt ở 0.0 để tối đa tính nhất quán giữa các lần chạy. Chúng ta dùng response_format={"type": "json_object"} để đầu ra luôn phân tích được.

Rubric mô tả từng mức điểm một cách cụ thể thay vì dùng nhãn mơ hồ như "tốt" hay "kém." Nếu thiếu mức độ cụ thể đó, tôi thấy giám khảo mặc định cho mọi thứ 3 hoặc 4, điều này vô dụng.

Lưu ý rằng GPT-4o làm giám khảo dù GPT-4o-mini làm tạo sinh. Để giám khảo mạnh hơn trình tạo là mẫu hình phổ biến vì giám khảo cần khả năng theo hướng dẫn mạnh để áp dụng rubric nhất quán. 

Nếu bạn dùng cùng một mô hình cho cả hai vai trò, bạn còn đưa vào thiên lệch tự ưu tiên đã được ghi nhận, nơi mô hình đánh giá đầu ra của chính nó ưu ái hơn.

Chạy vòng lặp đánh giá

Đến lúc chạy mọi thứ và thu thập kết quả.

import json

evaluation_report = []

for result in eval_results:
    # Run both judges
    faithfulness = judge_faithfulness(
        result["question"], result["context"], result["answer"]
    )
    relevance = judge_relevance(
        result["question"], result["answer"]
    )
    
    evaluation_report.append({
        "question": result["question"],
        "answer": result["answer"][:200],
        "faithfulness_score": faithfulness["score"],
        "faithfulness_reason": faithfulness["reason"],
        "relevance_score": relevance["score"],
        "relevance_reason": relevance["reason"],
    })
    
    print(f"Q: {result['question']}")
    print(f"  Faithfulness: {faithfulness['score']}/5 | Relevance: {relevance['score']}/5")
    print(f"  Faith reason: {faithfulness['reason'][:100]}...")
    print()

# Summary statistics
faith_scores = [r["faithfulness_score"] for r in evaluation_report]
rel_scores = [r["relevance_score"] for r in evaluation_report]
print(f"Average faithfulness: {sum(faith_scores)/len(faith_scores):.2f}")
print(f"Average relevance: {sum(rel_scores)/len(rel_scores):.2f}")
print(f"Questions with faithfulness < 3: {sum(1 for s in faith_scores if s < 3)}")

Mỗi câu hỏi kích hoạt hai cuộc gọi API tới GPT-4o, một cho mỗi giám khảo. Với tám câu hỏi kiểm thử của chúng ta, tổng cộng là mười sáu cuộc gọi đánh giá, vẫn trong tầm kiểm soát. Trong sản xuất với hàng nghìn truy vấn mỗi ngày, bạn sẽ muốn gom lô, chạy bất đồng bộ, và có lẽ chỉ đánh giá một mẫu thay vì mọi phản hồi.

Phân tích kết quả và lặp lại

Các điểm số số học cho bạn cái nhìn tổng quan, nhưng phần lập luận mới cho bạn biết cần sửa gì.

# Find problematic responses
print("=== LOW FAITHFULNESS (score < 4) ===")
for r in evaluation_report:
    if r["faithfulness_score"] < 4:
        print(f"\nQ: {r['question']}")
        print(f"Score: {r['faithfulness_score']}")
        print(f"Reason: {r['faithfulness_reason']}")
        print(f"Answer preview: {r['answer'][:150]}...")

print("\n=== LOW RELEVANCE (score < 4) ===")
for r in evaluation_report:
    if r["relevance_score"] < 4:
        print(f"\nQ: {r['question']}")
        print(f"Score: {r['relevance_score']}")
        print(f"Reason: {r['relevance_reason']}")

Câu hỏi về đơn hàng quốc tế và hàng giảm giá gần như chắc chắn sẽ có điểm trung thực thấp, vì kho tri thức không đề cập các chủ đề đó, và mô hình có khả năng đã ứng biến câu trả lời. 

Câu hỏi về laptop lỗi cũng thú vị vì cần tổng hợp thông tin từ chính sách hoàn tiền chung (30 ngày) với điều khoản điện tử lỗi (90 ngày cho hàng lỗi có giấy xác nhận), và tùy vào những đoạn được truy xuất, mô hình có thể có hoặc không có bức tranh đầy đủ.

Bạn làm gì với kết quả phụ thuộc vào phát hiện. Điểm trung thực thấp trên một số loại câu hỏi thường chỉ ra một trong hai điều: hoặc bộ truy xuất kéo về các đoạn sai (vấn đề truy xuất), hoặc bộ tạo đi quá ngữ cảnh được cung cấp (vấn đề tạo sinh). 

Xem ngữ cảnh truy xuất cùng với câu trả lời sẽ cho bạn biết đang gặp vấn đề nào. Ngược lại, điểm liên quan thấp thường có nghĩa prompt hệ thống cần tinh chỉnh, hoặc ngữ cảnh truy xuất lệch chủ đề đến mức mô hình không có gì hữu ích để bám vào.

Với khía cạnh vận hành đưa đánh giá vào pipeline triển khai, khóa học LLMOps Concepts bao quát hạ tầng và mô hình quy trình.

Dùng DeepEval cho đánh giá có cấu trúc

Viết các hàm giám khảo tùy chỉnh là ổn, nhưng cho mục đích sản xuất, bạn có lẽ muốn một framework xử lý phần lặp. DeepEval là một lựa chọn chín muồi hơn, đi kèm các hiện thực chỉ số đã được kiểm thử kỹ, bao phủ các tiêu chí đánh giá phổ biến nhất.

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

# Configure metrics
faithfulness_metric = FaithfulnessMetric(
    threshold=0.7,
    model="gpt-4o",
    include_reason=True
)

relevance_metric = AnswerRelevancyMetric(
    threshold=0.7,
    model="gpt-4o",
    include_reason=True
)

# Create test cases from our RAG results
test_cases = []
for result in eval_results:
    test_case = LLMTestCase(
        input=result["question"],
        actual_output=result["answer"],
        retrieval_context=[result["context"]]
    )
    test_cases.append(test_case)

# Run evaluation
evaluate(
    test_cases=test_cases,
    metrics=[faithfulness_metric, relevance_metric]
)

Bạn nhận được từ DeepEval những thứ tự viết rất tẻ nhạt nếu tự làm: 

• Logic thử lại khi giám khảo trả về JSON sai định dạng (xảy ra thường xuyên hơn bạn nghĩ)
• Bộ nhớ đệm kết quả để chạy lại đánh giá không nhân đôi hóa đơn API của bạn
• Tích hợp Pytest cho phép nối đánh giá LLM trực tiếp vào pipeline CI/CD. 

Mỗi chỉ số cũng sinh phần tự giải thích, nghĩa là mỗi điểm số đi kèm phân tích lập luận của giám khảo để bạn kiểm tra khi có gì đó không ổn.

Để tìm hiểu sâu về toàn bộ khả năng của DeepEval, xem Evaluate LLMs Effectively Using DeepEval.

Thực hành tốt nhất cho LLM Như Một Giám Khảo

Khiến một giám khảo LLM trả về con số là việc đơn giản. Khiến các con số đó thực sự có ý nghĩa với đội của bạn đòi hỏi nhiều chăm chút hơn hầu hết mọi người kỳ vọng ban đầu.

Khung đánh giá và chỉ số

Ngoài DeepEval, hiện có vài framework để lựa chọn, và hệ sinh thái vẫn đang mở rộng. Dưới đây là so sánh thực tiễn dựa trên nơi mỗi cái phù hợp nhất:

Với hệ thống RAG, bốn chỉ số thường bao phủ hầu hết nhu cầu thực tế.

1. Tính trung thực (Faithfulness) cho biết liệu câu trả lời sinh ra có bám vào ngữ cảnh truy xuất hay không. Nếu điểm trả về là 0,6, nghĩa là khoảng 40% mệnh đề trong câu trả lời không có hỗ trợ từ tài liệu cung cấp. Đây là bộ phát hiện ảo giác chính, và theo kinh nghiệm của tôi, là chỉ số quan trọng nhất cần theo dõi liên tục.
2. Mức độ liên quan của câu trả lời nêu bật việc phản hồi có thực sự giải quyết điều được hỏi không, đây là vấn đề hoàn toàn khác. Một phản hồi có thể hoàn toàn trung thực với ngữ cảnh (mọi mệnh đề đều đúng) nhưng vẫn trật mục tiêu câu hỏi.
3. Độ chính xác ngữ cảnh (precision) nhìn vào phía truy xuất: liệu tài liệu liên quan có được xếp hạng cao trong kết quả không? Nếu tài liệu chứa câu trả lời được truy xuất ở vị trí 5 trên 5, truy xuất về kỹ thuật là hoạt động, nhưng xếp hạng kém và điều đó ảnh hưởng chất lượng tạo sinh vì mô hình chú ý nhiều hơn tới nội dung xuất hiện đầu tiên trong cửa sổ ngữ cảnh.
4. Độ bao phủ ngữ cảnh (recall) đi theo chiều ngược lại, kiểm tra bao nhiêu thông tin cần thiết để trả lời câu hỏi thực sự được truy xuất. Recall thấp là vấn đề hạ tầng truy xuất, và không có lượng prompt engineering nào ở phía tạo sinh có thể bù đắp cho ngữ cảnh vốn không tồn tại.

Bạn muốn chạy các chỉ số này cùng nhau vì các tổ hợp điểm cao/thấp khác nhau chỉ ra các nguyên nhân gốc khác nhau.

• Trung thực cao nhưng liên quan thấp nghĩa là mô hình phản ánh chính xác ngữ cảnh, nhưng bản thân ngữ cảnh không liên quan đến câu hỏi. 
• Trung thực thấp nhưng liên quan cao nghĩa là mô hình hiểu câu hỏi nhưng đã đi vượt ngoài ngữ cảnh cung cấp để trả lời. 

Mỗi tổ hợp cho bạn biết nên tìm cách sửa ở đâu.

Để thực hành trực tiếp theo dõi đánh giá trong MLflow, Evaluating LLMs with MLflow hướng dẫn tích hợp này.

Thực hành tốt khi triển khai sản xuất

Triển khai sản xuất đòi hỏi cân nhắc nhiều hơn so với chạy đánh giá trong notebook, và các vấn đề thực tế ở quy mô thường rơi vào năm nhóm đáng để xử lý trước khi bạn chốt cách tiếp cận.

1. Lên kế hoạch quanh các thiên lệch đã biết. Giám khảo LLM nhất quán chấm cao hơn cho câu trả lời dài (thiên lệch dài dòng) và hơi thiên về phản hồi xuất hiện trước trong so sánh cặp (thiên lệch vị trí). Cách giảm chuẩn cho thiên lệch vị trí là chạy mỗi so sánh cặp theo cả hai thứ tự và chỉ tính kết quả khi giám khảo nhất quán ở cả hai. Với tính dài dòng, bạn có thể thêm ngôn ngữ nêu rõ trong rubric rằng súc tích là chấp nhận được, thậm chí được ưu tiên, dù điều này chỉ giảm chứ không loại bỏ hoàn toàn.
2. Hiệu chuẩn theo con người trước khi tin điểm số. Tập hợp 50–100 ví dụ đã được người đánh giá chấm trên miền cụ thể của bạn, chạy qua giám khảo, và kiểm tra tỷ lệ đồng thuận, với bất kỳ mức nào dưới 75% cho thấy rubric cần làm rõ tiêu chí hơn. Nhớ lặp lại bước hiệu chuẩn này định kỳ vì cả mô hình giám khảo lẫn ứng dụng của bạn đều tiến hóa theo thời gian, nghĩa là mức đồng thuận trông chắc chắn sáu tháng trước có thể đã trôi dạt khi prompt, dữ liệu, hoặc phiên bản mô hình thay đổi.
3. Kiểm tra tính nhất quán tách biệt với độ chính xác. Chạy cùng đầu vào qua giám khảo hai lần và so sánh đầu ra, vì nếu một phản hồi được 3 lần này và 5 lần sau, rubric của bạn có quá nhiều khoảng diễn giải, và giám khảo đọc khác nhau mỗi lần. Khi đó, đánh giá nhị phân đạt/trượt thường cho kết quả ổn định hơn theo thời gian so với thang 5 điểm, nên cân nhắc quy đổi điểm số thành nhị phân cho giám sát sản xuất, đồng thời giữ thang chi tiết cho phân tích ngoại tuyến nơi sự không nhất quán đôi khi ít tốn kém hơn.
4. Quản lý chi phí ở quy mô. Prompt đánh giá dài hơn đáng kể so với prompt tạo sinh thông thường vì phải bao gồm câu hỏi gốc, toàn bộ ngữ cảnh truy xuất, câu trả lời sinh ra, và rubric đầy đủ với tiêu chí chấm điểm. Với hệ thống lưu lượng cao, một mẫu hình tiết kiệm chi phí là chạy đánh giá LLM chi tiết trên mẫu ngẫu nhiên 10% truy vấn, trong khi áp dụng kiểm tra tự động đơn giản (độ dài, tuân thủ định dạng, có từ khóa) cho 90% còn lại.
5. Giữ con người trong vòng lặp. Ngay cả khi giám khảo đã chạy tốt trong sản xuất, hãy thiết lập quy trình rà soát định kỳ nơi thành viên trong đội kiểm tra ngẫu nhiên một mẫu các đánh giá của giám khảo mỗi tuần. Đặc biệt chú ý tới những phản hồi được chấm hoàn hảo (5/5) vì đó chính là các trường hợp mà một lỗi bị bỏ sót sẽ tạo ra sự tự tin sai lệch lớn nhất vào câu trả lời sai.

Để tìm hiểu thêm về vận hành hóa quy trình LLM end-to-end, lộ trình Associate AI Engineer for Data Scientists bao quát toàn cảnh triển khai.

Kết luận

LLM-as-a-judge đáp ứng một nhu cầu thực tế mà cả chỉ số tự động truyền thống lẫn đánh giá thủ công đều không thể bao phủ ở quy mô lớn một mình. Chỉ số tự động bỏ qua những gì thực sự quan trọng với ứng dụng LLM; ngược lại, đánh giá thủ công bắt được điều quan trọng nhưng không theo kịp khối lượng của hệ thống sản xuất. 

Một giám khảo LLM ở giữa cho bạn cách giám sát liên tục chất lượng đầu ra với mức độ tinh tế mà các chỉ số đơn giản không thể cung cấp.

Chúng ta đã xây một pipeline hoàn chỉnh trong hướng dẫn này: hệ thống RAG với kho tri thức nhỏ, các truy vấn kiểm thử thiết kế để kích hoạt những chế độ lỗi khác nhau, các giám khảo tùy chỉnh cho tính trung thực và mức độ liên quan, và một cách tiếp cận dựa trên framework dùng DeepEval gần hơn với những gì bạn sẽ chạy trong sản xuất.

Nếu chỉ rút ra một điều, thì rubric là tất cả. Đây là lý do bạn nên đầu tư thời gian viết tiêu chí đánh giá cụ thể, rõ ràng với ví dụ cho từng mức điểm. Một rubric được thiết kế tốt với mô hình ở mức vừa phải sẽ vượt trội so với một rubric mơ hồ đi kèm mô hình mạnh nhất, mọi lần.

Nếu bạn muốn tiếp tục xây dựng từ đây:

• Building a RAG System with LangChain and FastAPI đưa pipeline RAG từ notebook lên dịch vụ sản xuất.
• Developing LLM Applications with LangChain bao quát quy trình phát triển ứng dụng rộng hơn, gồm chains, agents và memory.
• Introduction to LLMs in Python đáng xem lại nếu bạn muốn củng cố nền tảng trước khi đi sâu hơn.
• 12 LLM Projects For All Levels cung cấp thêm ý tưởng dự án để thực hành.
• What is Retrieval Augmented Generation (RAG)? bao quát nền tảng khái niệm của RAG sâu hơn.