Đánh giá LLM Online và Offline: Bạn Cần Loại Nào (và Khi Nào)

Đánh giá LLM Online và Offline: Bạn Cần Loại Nào (và Khi Nào)

Đánh giá LLM online và offline là một quyết định duy nhất, không phải hai, và bộ eval promptfoo của chúng tôi đã chứng minh điều đó vào thứ Ba tuần trước: một system prompt viết lại, 47 test case, độ faithfulness tụt từ 0.91 xuống 0.74 trong khoảng 90 giây chạy CI. Bài kiểm tra offline đã bắt được regression đó trước khi merge; còn giám sát production sẽ gặp nó sau, dưới dạng một ticket hỗ trợ. Offline hay online, cùng một kết luận: hai làn đường, hai việc khác nhau.

Đánh giá LLM offline chạy mô hình của bạn trên một bộ dữ liệu cố định trước khi deploy, để chứng minh một thay đổi không làm hỏng chất lượng đã đo. Đánh giá online chấm điểm lưu lượng production thực sau khi ra mắt, phơi bày những gì bộ dữ liệu không hề chứa. Hầu hết các đội đều cần cả hai, theo thứ tự: offline chặn trước deploy, online bắt những gì đã trôi lệch.

Điểm chính

• Eval offline chạy trên bộ dữ liệu cố định trước khi deploy; eval online chấm điểm lưu lượng thực sau khi ra mắt.
• Hầu hết các đội cần cả hai: offline chặn các lần deploy, online bắt những gì bộ dữ liệu bỏ sót.
• Offline bắt regression của prompt và lỗi định dạng đầu ra; online bắt drift, độ trễ dưới tải và các lỗi tích hợp kỳ lạ.
• Nối eval offline thành cổng chặn merge trong CI; đưa điểm online từ trace production vào bộ eval của bạn.

Đánh giá online và offline thực sự khác nhau ở đâu? (9 chiều so sánh)

Hai chế độ khác nhau trên chín trục, nhưng trục quyết định là nguồn dữ liệu: đánh giá offline chấm một bộ dữ liệu cố định, có version, trước khi deploy, còn đánh giá online chấm lưu lượng thực sau khi ra mắt. Mọi khác biệt khác (chi phí, độ trễ, rủi ro, quản trị) đều bắt nguồn từ sự phân tách đó.

Trung tâm học liệu của Label Studio coi hai chế độ là hai mode bổ trợ cho nhau thay vì đối thủ, và chúng tôi đồng ý. Bảng dưới đây mở rộng góc nhìn đó với các chỉ số riêng cho LLM mà phiên bản ML tổng quát của họ không đề cập.

Cách chúng tôi diễn giải: cột offline trả lời câu "thay đổi này có làm hỏng gì không?", còn cột online trả lời câu "production có đang trôi khỏi những gì chúng ta đã test không?". Hàng loại chỉ số là nơi hai bên tách xa nhau nhất; hướng dẫn chỉ số đánh giá LLM của chúng tôi phân tích từng chỉ số một.

Mỗi chế độ bắt được lỗi gì, và lỗi nào lọt qua cả hai?

Mỗi chế độ sở hữu một nhóm lỗi riêng mà chế độ kia không nhìn thấy. Offline bắt những thay đổi do chính bạn tạo ra; online bắt những thay đổi mà thế giới gây ra quanh bạn. Những lỗi đắt đỏ nhất, những lỗi sống sót qua cả hai tấm lưới, cần một người review thật. Bảng phân loại này là tổng hợp của chúng tôi từ những gì mỗi chế độ báo cáo, không phải một chuẩn đã công bố.

Góc phần tư chỉ offline là nơi cổng CI chứng minh giá trị: một prompt viết lại âm thầm kéo tỷ lệ tuân thủ định dạng từ 99% xuống 91% sẽ vô hình trong code review nhưng lộ rõ trong một bộ 47 case. Góc phần tư chỉ online thì tinh vi hơn. Người dùng thật diễn đạt theo những cách bộ dữ liệu chuẩn của bạn chưa từng có, API bên thứ ba timeout vào những khung giờ mà staging không bao giờ chạm tới, và sẽ có ai đó nhét cho chatbot của bạn một prompt dài 40.000 ký tự chỉ để xem chuyện gì xảy ra. Cho phía đó, hướng dẫn đánh giá agent trong production của chúng tôi bao quát cách chấm điểm các quỹ đạo nhiều bước, chứ không chỉ từng đầu ra đơn lẻ.

Hàng cuối cùng là hàng các đội hay bỏ qua, và cũng là hàng làm họ cháy túi. Những lỗi khiến bạn mất người dùng chính là những lỗi mà không chế độ nào bắt được một mình. Chúng cần con người trong vòng lặp.

Kết nối eval offline vào cổng CI như thế nào? (Cấu hình không ai chỉ bạn)

Thêm một trình chạy eval làm status check bắt buộc trên mọi pull request chạm tới prompt, mô hình hoặc cấu hình retrieval. Khẳng định một ngưỡng. Chặn merge nếu dưới ngưỡng. Tài liệu promptfoo mô tả chính xác pattern CI này, và đó cũng là thứ chúng tôi đang chạy.

Step GitHub Actions

Phiên bản rút gọn của cổng mà chúng tôi đang chạy hiện tại:

name: llm-eval-gate

on:
  pull_request:
    paths: ["prompts/**", "evals/**", "src/rag/**"]

jobs:
  faithfulness-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - name: Run offline evals, fail the PR on regression
        run: npx promptfoo@latest eval --config evals/support-agent.yaml
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}  # LLM-as-judge

File YAML khai báo các test case và assertion; lệnh eval thoát với mã khác không khi bộ eval rơi xuống dưới ngưỡng, GitHub đánh dấu check bắt buộc là failed, và nút merge chuyển xám. Bộ lọc paths rất quan trọng: một bản sửa README không nên đốt token của judge.

Cổng CI thực sự bắt được gì

Phiên bản đang chạy chấm điểm chuỗi RAG của support agent của chúng tôi trên 47 case chuẩn trong mọi PR ảnh hưởng tới prompt. Một lần chạy đầy đủ mất khoảng 90 giây CI, và merge tự động bị chặn nếu faithfulness tụt dưới 0.82. Trong ba tháng, nó đã bắt được hai regression mà nếu không sẽ được ship: một bản viết lại system prompt đẩy faithfulness từ 0.91 xuống 0.74, và một thay đổi retriever làm đôi độ dài ngữ cảnh rồi kéo độ liên quan của câu trả lời xuống dưới ngưỡng. Không bản nào trông có vẻ nguy hiểm khi review.

Một cổng faithfulness trong CI tốn 90 giây mỗi PR. Một regression faithfulness trên production tốn của bạn một ticket hỗ trợ và một lần rollback.

Chúng tôi đã so sánh các trình chạy mà bạn có thể cắm vào pattern này, gồm promptfoo, DeepEval và những công cụ còn lại, trong bài tổng hợp công cụ đánh giá LLM.

Công cụ nào chạy chế độ nào? (Ma trận công cụ và chế độ)

Không công cụ đơn lẻ nào sở hữu gọn gàng cả hai làn. promptfoo và DeepEval là những trình chạy offline trước tiên, có thể chấm dữ liệu production xuất ra theo lịch; Langfuse và LangSmith là những kho trace online trước tiên, gắn thêm bộ chấm LLM-as-judge lên trace đã nạp. Ma trận này là cách chúng tôi đọc tài liệu của từng hãng: diễn giải, không phải chân lý.

Chọn promptfoo hoặc DeepEval nếu nhu cầu đầu tiên của bạn là một cổng chặn merge ngăn prompt tệ trong CI. Chọn Langfuse hoặc LangSmith nếu nhu cầu đầu tiên là chấm lưu lượng thực, và bài so sánh Langfuse và LangSmith của chúng tôi phân tích kỹ lựa chọn đó. OpenAI Evals vẫn là kẻ lạc loài: một trình chạy offline kiểu registry không có phía production.

promptfoo chặn PR của bạn. Langfuse chấm trace production của bạn. Không bên nào thay thế bên nào.

Vòng phản hồi biến lỗi online thành bài test offline ra sao?

Lấy mẫu các trace production điểm thấp, gán nhãn cho chúng, và commit vào bộ eval offline. Bộ regression khi đó lớn lên theo mỗi bất ngờ mà production ném vào bạn, và lần deploy tiếp theo bị chặn trên bộ đã mở rộng. Cách gọi bánh đà là của chúng tôi; đó là phần mà hầu hết các đội không bao giờ xây.

Chu kỳ, theo cách chúng tôi chạy:

1. Bộ chấm online gắn cờ các trace dưới 0.7 điểm judge.
2. Chúng tôi lấy mẫu 20 đến 30 trace bị gắn cờ mỗi tuần.
3. Một người gán nhãn từng trace: đầu ra kỳ vọng cộng nhóm lỗi.
4. Các case đã gán nhãn gia nhập bộ eval offline làm ví dụ chuẩn mới.
5. PR tiếp theo chạy trên bộ đã mở rộng, và vòng lặp bắt đầu lại.

Việc lấy mẫu bắt đầu từ tầng observability LLM của bạn, vì trace chính là nguyên liệu thô. Về nhịp độ: hằng tuần thắng hằng tháng, vì drift cộng dồn. Chúng tôi gán nhãn 10 đến 15 case mỗi tuần, và bộ được coi là "đủ lớn" khi nhãn mới không còn làm dịch chuyển tỷ lệ đậu, khoảng 150 đến 250 case cho một support agent hẹp. Ranh giới giữa hai chế độ ngày càng mờ: Deepchecks ghi nhận rằng các kỹ sư Union.ai lên lịch chạy eval "offline" của họ mỗi vài phút, về hiệu quả biến chúng thành các bài kiểm tra gần thời gian thực.

Bộ eval của bạn không phải một artifact cố định. Nó lớn lên mỗi tuần khi production làm bạn bất ngờ.

Khi nào bạn cần cả hai? (Đánh giá LLM online và offline theo từng giai đoạn)

Bạn cần cả hai từ tuần ra mắt trở đi, nhưng cán cân dịch chuyển theo giai đoạn: offline gánh một mình phần việc trước deploy, tuần ra mắt thêm chấm điểm shadow hoặc canary, trạng thái ổn định dựa vào giám sát online với các lần chạy lại offline định kỳ, và một cảnh báo drift nên kết thúc bằng một bài test offline tái hiện được cộng một bộ eval lớn hơn.

Trước deploy là nơi rẻ nhất để khắt khe: một lần merge bị chặn tốn vài phút; một bản phát hành tệ tốn niềm tin. Tuần ra mắt là nơi các đội đầu tư thiếu, dù chấm điểm shadow trên một lát lưu lượng nhỏ tốn rất ít và tiết lộ liệu bộ dữ liệu chuẩn có nói dối hay không. Trạng thái ổn định là nơi sự tự mãn len vào, nên hãy đưa việc eval lại vào lịch.

Còn Đạo luật AI của EU thì sao?

Các nghĩa vụ cho hệ thống rủi ro cao của Đạo luật AI EU (EU AI Act) được áp dụng theo lộ trình đến hết tháng 8 năm 2026, với toàn bộ mốc thời hạn công bố trên EUR-Lex, và pattern tuân thủ ánh xạ gọn vào hai chế độ. Bằng chứng offline có tài liệu cho thấy hệ thống đã đạt mục tiêu chất lượng trước khi phát hành; giám sát online liên tục cho thấy nó tiếp tục đạt sau đó. Cách đọc của chúng tôi là một dấu vết kiểm toán cần cả hai loại artifact, vì chỉ log offline không chứng minh hệ thống vẫn tuân thủ, và chỉ dashboard không chứng minh nó đã tuân thủ khi ra mắt. Đó là diễn giải, không phải lời khuyên pháp lý; bài trụ cột pipeline đánh giá LLM của chúng tôi ánh xạ toàn bộ bộ yêu cầu.

Đánh giá offline là bằng chứng của bạn. Đánh giá online là hệ thống cảnh báo sớm của bạn. Cơ quan quản lý muốn cả hai.

Về tác giả: Mert Batur là Đồng sáng lập của Techsy.io, nơi đội ngũ xây dựng AI agent, hệ thống tự động hóa và pipeline voice/SDR cho khách hàng B2B. Anh viết về stack công cụ LLM mà đội Techsy thực sự dùng trong production. Kết nối trên LinkedIn.

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

Đánh giá LLM offline là gì?

Đánh giá LLM offline chạy một mô hình hoặc prompt trên một bộ dữ liệu cố định, có version, trước khi deploy. Các bài kiểm tra điển hình gồm faithfulness với ngữ cảnh truy xuất, độ liên quan của câu trả lời, tuân thủ định dạng và điểm benchmark. Vì bộ dữ liệu không bao giờ đổi giữa chừng, kết quả có thể lặp lại và diff được, đó chính xác là lý do các bộ offline hoạt động tốt làm cổng chặn merge trong CI.

Đánh giá LLM online là gì?

Đánh giá LLM online chấm lưu lượng production thực sau khi ra mắt. Một bộ chấm LLM-as-judge đánh giá các trace lấy mẫu về ảo giác, giọng văn hoặc độ đúng của tool call, và điểm chạy vào dashboard. Nó cũng hấp thụ những tín hiệu mà bài test offline không thấy: độ trễ dưới tải, phản hồi người dùng, và cách truy vấn thật khác với bộ dữ liệu chuẩn của bạn.

Khi nào nên dùng đánh giá LLM offline và online?

Dùng đánh giá offline để chặn deploy: mọi thay đổi về prompt, mô hình hoặc retrieval đều phải qua bộ eval trước khi merge. Dùng đánh giá online để giám sát những gì đã ship. Hầu hết các đội chạy tuần tự cả hai thay vì chọn một: offline trước, online từ tuần ra mắt trở đi, với lỗi production chảy ngược về bộ offline.

Ví dụ về đánh giá LLM online và offline là gì?

Ví dụ offline: một bộ promptfoo chạy 200 câu hỏi hỗ trợ chuẩn trên mọi pull request và chặn merge nếu faithfulness tụt dưới 0.82. Ví dụ online: Langfuse chấm 10% trace thực bằng bài kiểm tra ảo giác LLM-as-judge và cảnh báo khi trung bình tuần trượt dốc. Cùng một rubric, khác nguồn dữ liệu.

Human-in-the-loop khớp vào đánh giá LLM ở đâu?

Con người lấp khoảng trống mà không chế độ nào phủ: edge case mới, phán đoán chất lượng chủ quan và trôi giọng văn thương hiệu. Một nhịp thực tế là gán nhãn 10 đến 20 trace lấy mẫu điểm thấp mỗi tuần và commit các case đã gán nhãn vào bộ eval offline. Hàng đợi review là một đầu vào của pipeline, không phải dự án phụ.

Đánh giá Langfuse hoạt động thế nào cho chấm điểm online?

Langfuse nạp trace từ ứng dụng của bạn, rồi gắn các evaluator LLM-as-judge chấm từng trace theo một rubric: ảo giác, độ liên quan, độc hại hoặc một prompt tùy chỉnh. Điểm hạ xuống dashboard gắn với phiên và người dùng. Các đội xuất những trace điểm thấp kéo dài vào một dataset offline để test regression. Bài tổng hợp nền tảng observability của chúng tôi so sánh các kho trace nuôi pattern này.

Thêm eval offline vào pipeline CI/CD thế nào?

Thêm một trình chạy eval làm status check bắt buộc trên các pull request chạm tới prompt, mô hình hoặc cấu hình retrieval. Cả promptfoo và DeepEval đều chạy headless và thoát mã khác không khi assertion hỏng, việc này tự động chặn merge. Cổng YAML ở phần trước của bài là một mẫu chạy được; hãy bắt đầu với 30 đến 50 case.

Đạo luật AI của EU yêu cầu đánh giá offline hay online?

Về hiệu lực, cả hai. Với hệ thống rủi ro cao, Đạo luật kỳ vọng bằng chứng có tài liệu rằng mục tiêu chất lượng đã đạt trước khi phát hành, nghĩa là artifact offline, cộng giám sát liên tục sau deploy, nghĩa là telemetry online. Các mốc thời hạn theo lộ trình của nó chạy đến hết tháng 8 năm 2026 theo EUR-Lex. Đó là cách đọc của chúng tôi về pattern tuân thủ, không phải lời khuyên pháp lý.

LLM-as-a-judge có thể chạy ở cả chế độ offline và online không?

Có, và nên như vậy, vì rubric chuyển giao được. Ở offline, judge chấm toàn bộ đầu ra của bộ eval theo batch trong CI. Ở online, cùng prompt judge đó chấm trace production lấy mẫu trong thời gian gần thực. Giữ một rubric xuyên suốt cả hai chế độ chính là thứ làm cho baseline offline của bạn so sánh được với tín hiệu drift online.

Những chỉ số nào khác nhau giữa đánh giá offline và online?

Chỉ số offline đo chất lượng đầu ra so với sự thật nền: faithfulness, độ liên quan của câu trả lời, tuân thủ định dạng, điểm benchmark. Chỉ số online thêm tín hiệu vận hành và hành vi: độ trễ p95, tỷ lệ lỗi, tỷ lệ ảo giác trên lưu lượng thực, điểm drift và mức độ hài lòng của người dùng. Danh sách offline hỏi "nó có tốt không?", còn danh sách online hỏi "nó có còn tốt không?".

Tóm lại

• Đánh giá offline và online là hai làn bổ trợ, không phải chọn một trong hai: một bên chặn những gì bạn ship, bên kia giám sát những gì bạn đã ship.
• Bắt đầu với cổng CI ngay tuần này, thêm chấm điểm trace online lúc ra mắt, và nối vòng phản hồi trước khi bộ eval của bạn hết hạn.
• Vòng lặp chính là hệ thống. Một bộ dữ liệu chuẩn tĩnh sẽ mục; một bộ đang lớn sẽ cộng dồn.

Nếu bạn muốn một góc nhìn thứ hai về pipeline eval của mình, nhận tư vấn miễn phí.