Thiết kế đánh giá AI: Ưu tiên sự minh bạch trước khi trực quan hóa dữ liệu

Đánh giá và phân tích AI

Giả sử bạn đang thử nghiệm các công cụ AI mới. Có thể bạn đang triển khai và chạy phân tích cho một công ty quảng cáo và muốn tự động hóa việc triển khai lược đồ sự kiện tiêu chuẩn của mình, hoặc bạn là một nhà sản xuất podcast đang tự động hóa việc tạo nội dung mạng xã hội từ tập mới nhất. Mặc dù các LLM hiện đại, mới được huấn luyện có khả năng xử lý tốt nhiều tác vụ này chỉ trong một lần chạy (one-shot), nhưng tính đặc thù này có thể khiến bạn lãng phí token và thời gian khi phải liên tục nhắc (prompt) chúng với cùng các tài nguyên, mô tả và kịch bản. Với suy nghĩ đó, bạn bắt đầu tìm hiểu các công cụ, dù đó là MCP server, kỹ năng đại lý (agent skill) hay plugin đại lý.

Vấn đề là làm thế nào để bạn biết một kỹ năng (dù do bạn tự phát triển hay là mã nguồn mở của người khác) có xứng đáng với thời gian, hoặc quan trọng hơn là hạn mức (quota) và token của bạn hay không? Làm thế nào để thiết kế các đánh giá (khách quan hơn) về công cụ AI và từ đó thu thập, phân tích các chỉ số liên quan? Đó chính là bối cảnh để sử dụng các khung đánh giá mã nguồn mở như Inspect AI và Harbor nhằm đánh giá các kỹ năng đại lý. Nhưng làm thế nào để bạn "mở rộng đánh giá", sử dụng trực quan hóa để phát hiện xu hướng và cùng nhau khám phá các hướng đi thay thế bằng Google Sheets và Data Studio?

Những câu hỏi này và nhiều vấn đề khác chính là những gì tôi hy vọng sẽ trình bày cho bạn trong loạt bài này!

Mặc dù bạn hoàn toàn có thể chỉ đọc về cách thức và lý do tôi thực hiện nghiên cứu của riêng mình, bạn cũng có thể làm theo hướng dẫn của tôi và chạy các tập lệnh benchmark.

Vì vậy, nếu bạn muốn thực hành cùng, hãy dành chút thời gian hoàn thành codelab đã đề cập ở trên và quay lại khi bạn đã xong. Đừng lo, chúng tôi vẫn sẽ ở đây khi bạn quay lại!

Lưu ý: Loạt bài blog này chứa các sơ đồ do AI tạo ra cùng với ảnh chụp màn hình thực tế và các chỉnh sửa vẽ tay trên cả hai. AI cũng hỗ trợ chỉnh sửa văn bản ở mức độ nhỏ.

Nâng cấp các đánh giá của bạn

Trong codelab, chúng ta đã học cách chạy các đánh giá với Gemini CLI, Inspect và Inspect SWE trong một Docker Sandbox biệt lập để hiểu mức độ hỗ trợ của từng kỹ năng đối với đại lý trong việc trả lời cùng một câu hỏi.

Đối với những người thực hành tại nhà, vui lòng cài đặt thêm inspect view ngay bây giờ trước khi bạn cần dùng nó để chạy các đánh giá bên dưới; hãy chuẩn bị tinh thần chờ đợi vài phút để các đánh giá hoàn tất tùy thuộc vào máy tính và mức sử dụng hạn mức của bạn.

Về các tệp nguồn mới của chúng tôi, mặc dù chúng được chú thích kỹ lưỡng và hy vọng là được viết theo cách tự mô tả, tôi sẽ giải thích thêm sau.

Một lưu ý về các mô hình

Cho mục đích demo nghiên cứu của mình, tôi đã sử dụng ba mô hình khác nhau: google/gemini-3.5-flash-lite và google/gemini-3.6-flash làm "bộ giải" (các mô hình đang được đánh giá), và google/gemini-3.1-flash-lite làm "bộ chấm điểm" (mô hình đánh giá các lượt chạy). Cả ba (và các mô hình nói chung) khác biệt ở nhiều khía cạnh, nhưng cụ thể hơn là về khả năng giải quyết vấn đề, tốc độ và chi phí.

Chúng tôi cố tình chuyển việc chấm điểm cho bản demo này sang một mô hình thế hệ trước vì bằng cách thay đổi tiêu chí chấm điểm thành các quyết định nhị phân nghiêm ngặt và áp dụng quy trình giảm thiểu theo lập trình, nó mang lại các đánh giá đủ mạnh mẽ mà không làm tiêu tốn hạn mức của bộ giải. Đối với một hệ thống đánh giá sản xuất, hãy cân nhắc sử dụng các mô hình mới hơn và có năng lực hơn làm bộ chấm điểm vì chúng có khả năng có khoảng tin cậy hẹp hơn.

Để có bảng phân tích kỹ thuật đầy đủ về kiến trúc bộ chấm điểm tách rời này và tìm hiểu cách bạn có thể thay thế bằng các mô hình tùy chọn của riêng mình, hãy xem phần README về Decoupled Grader & Multidimensional Rubrics.

Thiết lập đánh giá

Lưu ý về khả năng tái lập & thiết lập cục bộ: Nếu bạn đang thực hiện theo tại máy, hãy clone các định nghĩa kỹ năng miền vào google-skills/ trước khi chạy các lượt benchmark:

Chuyển sang chế độ toàn màn hình Thoát chế độ toàn màn hình

Tất cả các đánh giá trong loạt bài này được benchmark trên Python 3.13 sử dụng inspect-ai (v0.3.247), inspect-swe (v0.2.66), inspect-viz (v0.4.1) và pandas (v3.0.3). Nếu các bản phát hành PyPI thượng nguồn giới thiệu các thay đổi gây lỗi (breaking changes), hãy kiểm tra thông số kỹ thuật Môi trường & Phụ thuộc trong README để biết các phiên bản cố định chính xác và hướng dẫn cách tái lập cấu hình.

Đối với nghiên cứu này, tôi đã sử dụng một tập lệnh đánh giá mới; mặc dù các chi tiết của tập lệnh rất quan trọng đối với bất kỳ ai muốn tự tạo đánh giá hoặc chạy mã khi chúng ta thực hiện, nếu bạn chủ yếu quan tâm đến phân tích và trực quan hóa, hãy thoải mái bỏ qua phần tiếp theo.

Tập lệnh gốc đã chạy một loạt thử nghiệm nhỏ trên máy cục bộ. Mặc dù phiên bản này có thể và đã được chạy trên máy cục bộ, nó ưu tiên ba khía cạnh kiến trúc cần thiết để chạy các thử nghiệm tự động như một phần của quy trình phát triển quy mô lớn hơn:

Để có bảng phân tích kỹ thuật đầy đủ về các trụ cột kiến trúc này—bao gồm các lược đồ cấu hình bên ngoài (questions.json, thrifty_system_prompt.txt), các biện pháp bảo vệ giới hạn tốc độ bộ giải (phiên bản="0.51.0"), tách rời hạn mức bộ chấm điểm và các công thức toán học uốn cong điểm số, hãy xem phần Evaluation Pipeline Architecture & Technical Reference trong README.

Chạy đánh giá

Các lệnh này tạo ra một ma trận đánh giá dựa trên mô hình x điều kiện kỹ năng x mẫu x kỷ nguyên. Để có cái nhìn trực quan nhanh (mà tôi sẽ liên tục tham chiếu trong suốt bài viết), hãy xem bên dưới.

Chú thích: Trực quan hóa ma trận đánh giá sẽ được chấm điểm và so sánh. Trong Inspect AI, các yếu tố chấm điểm, ở đây được biểu thị là Facts, được xếp loại Đúng (C) hoặc Sai (I).

Với tất cả những điều đó, cuối cùng đã đến lúc bắt tay vào thực hiện. Tôi đã chạy các đánh giá của chúng tôi với lệnh sau:

Chuyển sang chế độ toàn màn hình Thoát chế độ toàn màn hình

Lệnh này chạy một lượt quét song song 4 chiều trên các mô hình và điều kiện kỹ năng, đồng thời áp dụng thời gian chờ tác vụ 300 giây và vô hiệu hóa tìm kiếm web để giảm thiểu chi phí token. Xem README để biết Tham chiếu tham số CLI đầy đủ và chi tiết về Cơ chế mẫu cấu hình bên ngoài.

Chạy và chờ đợi

Nếu bạn dự định thực hiện và chưa làm, hãy chạy dòng lệnh. Nếu bạn quan tâm đến cách đọc và tương tác với Giao diện người dùng dòng lệnh (Terminal User Interface), vui lòng tham khảo codelab trước đó.

Hãy theo dõi dòng lệnh đang chạy đủ lâu để xác định rằng nó không bị treo hoặc gặp lỗi rõ ràng, sau đó có thể dành chút thời gian để chuẩn bị đồ ăn, lấy nước hoặc đi dạo quanh khu nhà. Hãy tận hưởng những điều nhỏ bé trong cuộc sống, được chứ? Trường hợp xấu nhất, bạn cũng có được một chuyến đi dạo 20 phút, không tệ chút nào phải không!?

Xem các đánh giá

Sau khi đã hoàn tất, việc đọc đầu ra của terminal chỉ là cách cơ bản nhất để hiểu các đánh giá. Bây giờ bạn đã có các nhật ký đánh giá thô, bạn cần làm gì để bắt đầu sử dụng chúng một cách phân tích và quan trọng hơn là thuyết phục?

Để bắt đầu, tôi chỉ cần chạy

Chuyển sang chế độ toàn màn hình Thoát chế độ toàn màn hình

và nhấp vào liên kết để mở trình duyệt đến GUI.

Để phân tích dấu vết chẩn đoán từng bước trong GUI trình duyệt, hãy xem phần README về Local Diagnostic Trace Analysis (inspect view).

Kết quả của tôi hiện ra như thế này (sau một chút thao tác kéo và thả cột):