Posted inAI

Tự động hóa LLM-as-a-Judge với GitHub Actions: Chặn đứng lỗi AI trước khi Deploy

Artificial Intelligence tutorial - IT technology blog
Artificial Intelligence tutorial - IT technology blog

Khi Unit Test truyền thống bất lực trước AI

2 giờ sáng, điện thoại mình rung liên hồi vì hệ thống báo lỗi. Con chatbot RAG của công ty bỗng dưng “đổi nghề” từ tư vấn nghiệp vụ sang… dạy nấu ăn cho khách hàng. Nguyên nhân rất đơn giản: Một bạn dev vừa thay đổi prompt để chatbot nghe thân thiện hơn, test tay vài câu thấy ổn nên merge thẳng vào production.

Vấn đề nằm ở chỗ LLM có tính bất định (non-deterministic). Cùng một câu hỏi, mỗi lần AI lại trả về một kết quả khác nhau. Các câu lệnh assert response == "expected" kinh điển hoàn toàn vô dụng vì AI hiếm khi trả về hai câu giống hệt từng dấu phẩy. Nếu không có quy trình đánh giá tự động đủ thông minh để hiểu ngữ nghĩa, việc deploy ứng dụng AI chẳng khác nào chơi xổ số với trải nghiệm người dùng.

Ba hướng tiếp cận kiểm thử LLM hiện nay

Để giải quyết bài toán này, mình đã cân nhắc ba phương pháp phổ biến với những đánh đổi riêng:

1. Kiểm thử dựa trên quy tắc (Rule-based)

Phương pháp này dùng Regex hoặc check từ khóa trong câu trả lời. Nó chạy nhanh và gần như miễn phí. Tuy nhiên, nó không thể nhận biết được câu trả lời có đúng thái độ (tone of voice) hay có bị ảo tưởng (hallucination) hay không. Ví dụ: Bạn không thể dùng Regex để kiểm tra xem một đoạn văn 200 chữ có tóm tắt đúng ý chính hay không.

2. Đánh giá thủ công (Human-in-the-loop)

Đây là tiêu chuẩn vàng về độ chính xác khi con người trực tiếp chấm điểm. Nhưng nó là rào cản lớn cho việc scale dự án. Không ai đủ kiên nhẫn ngồi check lại 1.000 câu trả lời mỗi khi bạn chỉ thay đổi một dòng trong System Prompt.

3. LLM-as-a-Judge (AI chấm điểm AI)

Chúng ta dùng một model mạnh (như GPT-4o hoặc Claude 3.5 Sonnet) làm giám khảo để chấm điểm model nhỏ hơn. Judge model sẽ dựa trên một bộ tiêu chí (rubric) cụ thể để đánh giá. Đây là phương án cân bằng nhất giữa tốc độ, chi phí và độ tin cậy.

Tiêu chí Rule-based Human-in-the-loop LLM-as-a-Judge
Tốc độ Gần như tức thì Vài giờ đến vài ngày 1 – 2 phút
Chi phí ~$0 Rất đắt (lương dev) Trung bình (~$0.1 – $0.5/test)
Độ linh hoạt Thấp Rất cao Cao

Thiết lập “Cổng kiểm soát” trên GitHub Actions

Đưa LLM-as-a-Judge vào CI/CD giúp mình tự tin hơn khi release. Mỗi khi có Pull Request, hệ thống sẽ chạy bộ test case mẫu (Golden Dataset). Nếu điểm chất lượng trung bình dưới ngưỡng cho phép (ví dụ 7/10), GitHub sẽ chặn không cho merge code.

Bước 1: Viết Script đánh giá (evaluator.py)

Thay vì chỉ yêu cầu AI chấm điểm chung chung, mình sử dụng kỹ thuật Chain-of-Thought trong prompt để Judge model giải thích lý do trước khi đưa ra con số cuối cùng. Điều này giúp việc debug dễ dàng hơn nhiều.

import os
from openai import OpenAI

client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))

def judge_response(input_text, context, ai_response):
    prompt = f"""
    Bạn là chuyên gia kiểm định chất lượng AI. Hãy đánh giá câu trả lời dựa trên ngữ cảnh.
    
    [Ngữ cảnh]: {context}
    [Câu hỏi]: {input_text}
    [AI trả lời]: {ai_response}
    
    Tiêu chí chấm điểm (0-10):
    - 0: Trả lời sai hoàn toàn hoặc bịa đặt thông tin.
    - 5: Trả lời đúng ý chính nhưng thiếu chi tiết quan trọng.
    - 10: Trả lời chính xác, đầy đủ và văn phong chuyên nghiệp.
    
    Phản hồi theo định dạng JSON: {"reason": "...", "score": 10}
    """
    
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": prompt}],
        response_format={ "type": "json_object" }
    )
    # Logic xử lý kết quả và trả về score
    return score

Bước 2: Tự động hóa với GitHub Actions

Cấu hình file .github/workflows/llm_eval.yml để workflow tự kích hoạt mỗi khi có code mới. Mình khuyến khích sử dụng Python 3.10 trở lên để tận dụng các thư viện mới nhất.

name: LLM Quality Gate
on:
  pull_request:
    branches: [ main ]

jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install dependencies
        run: pip install openai
      - name: Run Evaluation
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: python evaluator.py

Kinh nghiệm thực chiến để tối ưu chi phí

Khi mới triển khai, mình từng mất gần $50 chỉ trong một buổi sáng vì chạy test quá đà. Dưới đây là cách mình tối ưu:

  • Chọn lọc Golden Dataset: Thay vì test toàn bộ database, mình chỉ chọn ra 30-50 câu hỏi “xương xẩu” nhất đại diện cho các edge case.
  • Phân cấp Judge Model: Dùng GPT-4o-mini để chấm các task đơn giản và chỉ dùng GPT-4o cho các task đòi hỏi logic phức tạp. Việc này giúp giảm 80% chi phí API.
  • Chặn chạy test lãng phí: Sử dụng paths-ignore trong GitHub Actions để không chạy test AI nếu bạn chỉ sửa file README hoặc tài liệu.

Lời kết

Từ ngày áp dụng quy trình này, những cuộc gọi khẩn cấp lúc nửa đêm giảm hẳn. Mình không còn phải lo lắng mỗi khi cập nhật logic cho chatbot. LLM-as-a-Judge không thể thay thế hoàn toàn con người, nhưng nó là lớp màng lọc cực kỳ hiệu quả để loại bỏ những lỗi ngớ ngẩn trước khi chúng tiếp cận người dùng thật.

Đừng đợi đến khi AI của bạn “nói nhảm” với khách hàng mới đi tìm cách test. Hãy xây dựng một bộ khung đánh giá tự động ngay từ ngày đầu tiên.

Share:
Tags: