Giám sát và Đánh giá LLM: Hướng dẫn xây dựng AI Evaluation Stack toàn diện

Phần mềm truyền thống có tính xác định: Đầu vào A cộng với hàm B luôn bằng đầu ra C. Tính xác định này cho phép các kỹ sư phát triển các bài kiểm thử mạnh mẽ. Ngược lại, AI tạo sinh (Generative AI) mang tính ngẫu nhiên (stochastic) và khó đoán trước. Cùng một câu lệnh (prompt) thường cho ra các kết quả khác nhau vào thứ Hai so với thứ Ba, làm phá vỡ các bài kiểm thử đơn vị (unit testing) truyền thống mà các kỹ sư vẫn tin dùng.

Để có thể triển khai các sản phẩm AI mức độ doanh nghiệp, các kỹ sư không thể chỉ dựa vào các "kiểm tra cảm tính" (vibe checks) hôm nay đạt nhưng ngày mai lại thất bại khi khách hàng sử dụng. Người xây dựng sản phẩm cần áp dụng một lớp hạ tầng mới: AI Evaluation Stack (Ngăn xếp đánh giá AI).

Định nghĩa mô hình đánh giá AI

Các bài kiểm thử phần mềm truyền thống là các khẳng định nhị phân (đạt/không đạt). Trong khi một số đánh giá AI sử dụng khẳng định nhị phân, nhiều đánh giá khác thực hiện trên thang điểm (gradient). Một bài đánh giá (eval) không phải là một tập lệnh đơn lẻ; nó là một đường ống có cấu trúc gồm các khẳng định — từ kiểm tra cú pháp mã nghiêm ngặt đến kiểm tra ngữ nghĩa tinh tế — nhằm xác minh chức năng dự định của hệ thống AI.

Phân loại kiểm tra đánh giá

Để xây dựng một đường ống hiệu quả về chi phí, các khẳng định phải được tách thành hai lớp kiến trúc riêng biệt:

Lớp 1: Các khẳng định xác định (Deterministic assertions)

Một phần đáng ngạc nhiên các lỗi AI trong sản xuất không phải là các "ảo giác" ngữ nghĩa — chúng là các lỗi cú pháp và định tuyến cơ bản. Các khẳng định xác định đóng vai trò là cổng đầu tiên của đường ống, sử dụng mã truyền thống và regex để xác thực tính toàn vẹn về cấu trúc.

Thay vì hỏi liệu một phản hồi có "hữu ích" hay không, các khẳng định này đặt ra các câu hỏi nhị phân nghiêm ngặt:

• Mô hình có tạo ra lược đồ khóa/giá trị JSON chính xác không?
• Nó có gọi công cụ (tool call) đúng với các tham số bắt buộc không?
• Nó có điền thành công một GUID hoặc địa chỉ email hợp lệ không?

Về mặt kiến trúc, các khẳng định xác định phải là lớp đầu tiên của ngăn xếp, hoạt động theo nguyên tắc "thất bại nhanh" (fail-fast) với chi phí tính toán thấp. Nếu một API hạ lưu yêu cầu một lược đồ cụ thể, một chuỗi JSON bị lỗi là một lỗi nghiêm trọng. Bằng cách đánh giá thất bại ngay lập tức tại lớp này, các nhóm kỹ thuật ngăn chặn đường ống kích hoạt các kiểm tra ngữ nghĩa tốn kém (Lớp 2) hoặc lãng phí thời gian xem xét của con người (Lớp 3).

Lớp 2: Các khẳng định dựa trên mô hình (Model-based assertions)

Khi các khẳng định xác định đạt, đường ống phải đánh giá chất lượng ngữ nghĩa. Vì ngôn ngữ tự nhiên linh hoạt, mã truyền thống không thể dễ dàng khẳng định liệu một phản hồi có "hữu ích" hay "thấu cảm" hay không. Điều này dẫn đến đánh giá dựa trên mô hình, thường được gọi là "LLM-as-a-Judge" (LLM đóng vai trò giám khảo).

Mặc dù việc sử dụng một hệ thống không xác định để đánh giá một hệ thống khác có vẻ ngược đời, nhưng đây là một mô hình kiến trúc cực kỳ mạnh mẽ cho các trường hợp sử dụng cần sự tinh tế. Hầu như không thể viết một regex đáng tin cậy để xác minh xem một phản hồi có "có thể hành động" hay "lịch sự" hay không. Trong khi các người xem xét con người xuất sắc ở sự tinh tế này, họ không thể mở rộng quy mô để đánh giá hàng chục nghìn trường hợp kiểm tra CI/CD. Do đó, LLM-as-a-Judge trở thành đại lý có thể mở rộng quy mô thay thế sự phán đoán của con người.

3 đầu vào quan trọng cho các khẳng định dựa trên mô hình

Tuy nhiên, các khẳng định dựa trên mô hình chỉ mang lại dữ liệu đáng tin cậy khi LLM-as-a-Judge được cung cấp 3 đầu vào quan trọng:

1. Một mô hình lý luận tiên tiến (SOTA): Giám khảo phải sở hữu khả năng lý luận vượt trội so với mô hình sản xuất. Nếu ứng dụng của bạn chạy trên một mô hình nhỏ hơn, nhanh hơn để giảm độ trễ, giám khảo phải là một mô hình lý luận tiên phong để xấp xỉ sự phán đoán cấp độ con người.
2. Bảng tiêu chí đánh giá nghiêm ngặt: Các câu lệnh đánh giá mơ hồ ("Đánh giá câu trả lời này tốt như thế nào") sẽ tạo ra các đánh giá ồn ào và ngẫu nhiên. Một bảng tiêu chí (rubric) mạnh mẽ định nghĩa rõ các mức độ thất bại và thành công.
3. Dữ liệu thực tế (Golden outputs): Mặc dù bảng tiêu chí cung cấp các quy tắc, một "câu trả lời mong đợi" đã được con người kiểm duyệt đóng vai trò là đáp án. Khi LLM-Judge có thể so sánh đầu ra của mô hình sản xuất với một Golden Output đã xác minh, độ tin cậy của điểm số sẽ tăng lên đáng kể.

Kiến trúc: Đường ống Offline và Online

Một kiến trúc đánh giá mạnh mẽ yêu cầu hai đường ống bổ sung cho nhau. Đường ống online giám sát dữ liệu đo đếm sau khi triển khai, trong khi đường ống offline cung cấp đường cơ sở và các ràng buộc xác định cần thiết để đánh giá các mô hình ngẫu nhiên một cách an toàn.

Đường ống đánh giá Offline

Mục tiêu chính của đường ống offline là kiểm thử hồi quy (regression testing) — xác định các lỗi, sự trôi dạt (drift) và độ trễ trước khi đưa vào sản xuất. Triển khai một tính năng LLM doanh nghiệp mà không có bộ đánh giá offline đóng vai trò cổng kiểm soát là một phản kiến trúc; nó tương đương với việc hợp nhất mã chưa biên dịch vào nhánh chính.

Quy trình

1. Lập bộ dữ liệu vàng (Golden dataset)

Vòng đời offline bắt đầu bằng việc lập một "bộ dữ liệu vàng" — một kho lưu trữ kiểm thử tĩnh, được kiểm soát phiên bản gồm 200 đến 500 trường hợp đại diện cho toàn bộ phạm vi hoạt động của AI. Mỗi trường hợp kết hợp một tải trọng đầu vào chính xác với một "đầu ra vàng" (golden output) mong đợi (ground truth).

Quan trọng nhất, bộ dữ liệu này phải phản ánh phân phối lưu lượng thực tế dự kiến. Trong khi hầu hết các trường hợp bao gồm các tương tác "happy-path" tiêu chuẩn, các kỹ sư phải kết hợp có hệ thống các trường hợp cạnh, các cuộc tấn công jailbreak và đầu vào đối nghịch. Đánh giá "khả năng từ chối" dưới áp lực vẫn là một yêu cầu tuân thủ nghiêm ngặt.

2. Định nghĩa tiêu chí đánh giá

Sau khi bộ dữ liệu được lập, các kỹ sư phải thiết kế tiêu chí đánh giá để tính điểm tổng hợp cho mỗi đầu ra mô hình. Một kiến trúc mạnh mẽ đạt được điều này bằng cách gán điểm có trọng số trên sự kết hợp giữa các khẳng định Lớp 1 (xác định) và Lớp 2 (dựa trên mô hình).

Ví dụ, một khung đánh giá có thể sử dụng hệ thống điểm 10 điểm cho một tác vụ gửi email.

Ngưỡng đạt và logic ngắn mạch

Trong ví dụ này, ngưỡng đạt 8/10 yêu cầu 8 điểm để thành công. Quan trọng nhất, đường ống đánh giá phải thực thi đánh giá ngắn mạch nghiêm ngặt (logic fail-fast). Nếu mô hình thất bại ở bất kỳ khẳng định xác định nào — chẳng hạn như tạo ra lược đồ JSON bị lỗi — hệ thống phải ngay lập tức đánh rớt toàn bộ trường hợp kiểm tra (0/10).

3. Thực thi đường ống và tổng hợp tín hiệu

Hệ thống thực thi đường ống offline — thường được tích hợp như một bước chặn CI/CD trong một pull request. Cơ sở hạ tầng lặp lại qua bộ dữ liệu vàng, tiêm mỗi tải trọng kiểm tra vào mô hình sản xuất, bắt lấy đầu ra và thực hiện các khẳng định đã định nghĩa.

Mỗi đầu ra được tính điểm dựa trên ngưỡng đạt. Sau khi thực thi lô hoàn tất, kết quả được tổng hợp thành tỷ lệ đạt tổng thể. Đối với ứng dụng cấp doanh nghiệp, tỷ lệ đạt cơ bản thường phải vượt quá 95%, tăng lên 99% trở lên đối với các lĩnh vực tuân thủ nghiêm ngặt hoặc rủi ro cao.

Đường ống đánh giá Online

Trong khi đường ống offline đóng vai trò người gác cổng trước khi triển khai, đường ống online là hệ thống đo đếm sau triển khai. Mục tiêu của nó là giám sát hành vi trong thế giới thực, bắt các trường hợp cạnh mới nổi và định lượng sự trôi dạt của mô hình.

1. Tín hiệu người dùng tường thuật

Phản hồi trực tiếp, xác định chỉ ra hiệu suất mô hình:

• Thích/không thích (Thumbs up/down): Phản hồi tiêu cực quá mức là chỉ số hàng đầu cho thấy sự suy giảm hệ thống.
• Phản hồi trong ứng dụng: Phân tích các nhận xét bằng văn bản để xác định các chế độ thất bại mới.

2. Tín hiệu hành vi ngầm định

Dữ liệu đo đếm hành vi tiết lộ các sự thất bại "im lặng" mà người dùng bỏ cuộc mà không phản hồi rõ ràng:

• Tỷ lệ tạo lại và thử lại: Tần suất thử lại cao cho thấy đầu ra ban đầu không giải quyết được ý định người dùng.
• Tỷ lệ xin lỗi: Quét các từ khóa heuristic ("Tôi xin lỗi") để phát hiện khả năng bị suy giảm.
• Tỷ lệ từ chối: Tỷ lệ từ chối cao nhân tạo cho thấy các bộ lọc an toàn được hiệu chuẩn quá mức đang từ chối các truy vấn hợp lệ.

3. Khẳng định xác định trong sản xuất (Đồng bộ)

Vì các kiểm tra mã xác định thực thi trong vài mili-giây, các nhóm có thể tái sử dụng các khẳng định offline Lớp 1 để đánh giá đồng bộ 100% lưu lượng sản xuất. Việc ghi lại các tỷ lệ đạt/không đạt này ngay lập tức phát hiện các đột biến bất thường ở đầu ra bị lỗi.

4. LLM-as-a-Judge trong sản xuất (Bất đồng bộ)

Nếu các thỏa thuận quyền riêng tư dữ liệu (DPA) cho phép ghi lại đầu vào của người dùng, các nhóm có thể triển khai các khẳng định dựa trên mô hình. Về mặt kiến trúc, LLM-Judge sản xuất không bao giờ được thực thi đồng bộ trên đường dẫn quan trọng, vì điều này sẽ làm tăng gấp đôi độ trễ và chi phí tính toán. Thay vào đó, một LLM-Judge nền sẽ lấy mẫu bất đồng bộ một phần (ví dụ: 5%) các phiên hàng ngày để tạo bảng điều khiển chất lượng liên tục.

Thiết kế vòng lặp phản hồi (Flywheel)

Các đường ống đánh giá không phải là hạ tầng "cài đặt và quên đi". Nếu không có cập nhật liên tục, các bộ dữ liệu tĩnh sẽ bị "già" (concept drift) khi hành vi người dùng phát triển.

Để làm cho hệ thống thông minh hơn theo thời gian, các kỹ sư phải kiến trúc một vòng lặp phản hồi kín khai thác dữ liệu đo đếm sản xuất để cải tiến liên tục.

Quy trình cải tiến liên tục:

1. Thu thập: Người dùng kích hoạt tín hiệu tiêu cực hoặc cờ hành vi ngầm định trong sản xuất.
2. Phân loại: Nhật ký phiên cụ thể được gắn cờ tự động và định tuyến để xem xét của con người.
3. Phân tích nguyên nhân gốc rễ: Chuyên gia lĩnh vực điều tra sự thất bại, xác định khoảng trống và cập nhật hệ thống AI.
4. Mở rộng bộ dữ liệu: Đầu vào người dùng mới, cùng với đầu ra mong đợi đã được sửa đổi, được thêm vào Bộ Dữ liệu Vàng offline cùng với một số biến thể tổng hợp.
5. Kiểm thử hồi quy: Mô hình được đánh giá lại liên tục đối với trường hợp cạnh mới được phát hiện này trong tất cả các lần chạy trong tương lai.

Kết luận: Định nghĩa mới về "Hoàn thành"

Trong kỷ nguyên AI tạo sinh, một tính năng hoặc sản phẩm không còn được coi là "hoàn thành" chỉ vì mã biên dịch được và câu lệnh trả về một phản hồi mạch lạc. Nó chỉ hoàn thành khi một đường ống đánh giá tự động hóa nghiêm ngặt được triển khai và ổn định — và khi mô hình liên tục đạt đối với cả bộ dữ liệu vàng được tuyển chọn và các trường hợp cạnh sản xuất mới được phát hiện.

Đây là thời điểm để bạn chia sẻ khuôn khổ này với các nhóm kỹ thuật, sản phẩm và pháp lý của mình để thiết lập một tiêu chuẩn chất lượng AI thống nhất trong tổ chức. Hãy ngừng đoán xem liệu các mô hình của bạn có đang suy giảm trong sản xuất hay không, và hãy bắt đầu đo lường.