Wavi Books · AI, LLM & AI Agent

Đánh giá AI Agent thế nào? Từ bản demo chạy được đến hệ thống đáng tin

Nguyễn Minh Trí · Biên tập chuyên môn Wavi Books

Cách đánh giá AI Agent bằng bộ test thực tế, trace, tiêu chí đúng-sai, chi phí và human review trước khi đưa agent vào production tại Việt Nam.

## AI Agent chạy đúng trong demo vẫn có thể thất bại ngoài đời

Một agent vừa đọc email, tìm thông tin trong tài liệu rồi tạo bản nháp trả lời. Bạn thử năm câu, cả năm đều ổn. Team thở phào: có vẻ đã sẵn sàng đưa vào production.

Vấn đề thường xuất hiện ở câu thứ sáu. Email thiếu tệp đính kèm, tài liệu có hai phiên bản mâu thuẫn hoặc công cụ trả về dữ liệu rỗng. Agent vẫn tiếp tục, tự lấp phần còn thiếu bằng một câu trả lời nghe rất hợp lý. Demo không hề cho bạn thấy tình huống đó vì demo chỉ chứng minh hệ thống có thể chạy, chưa chứng minh nó biết dừng đúng lúc.

Nói đơn giản, đánh giá AI Agent là quá trình biến chữ “có vẻ ổn” thành bằng chứng có thể đo lại. Bạn cần biết agent làm đúng việc không, dùng đúng nguồn không, gọi công cụ đúng lúc không, tốn bao nhiêu chi phí và có chuyển quyết định khó cho con người hay không.

## Vì sao chấm câu trả lời cuối cùng là chưa đủ

Với chatbot thông thường, ta hay nhìn vào câu trả lời cuối: đúng hay sai, rõ hay khó hiểu. Agent phức tạp hơn vì trước khi trả lời, nó có thể lập kế hoạch, tìm tài liệu, gọi API, thử lại và thay đổi dữ liệu.

Hai agent có thể tạo ra cùng một câu trả lời nhưng mức độ an toàn rất khác. Agent thứ nhất lấy dữ liệu từ nguồn đã duyệt và gọi đúng một công cụ. Agent thứ hai gọi bốn công cụ, gặp lỗi rồi đoán tiếp. Nếu chỉ chấm đoạn văn cuối, cả hai có thể cùng được điểm cao; nếu nhìn vào trace — dấu vết từng bước thực thi — bạn sẽ thấy agent thứ hai đang tạo ra một khoản nợ rủi ro.

Bởi vậy, eval tốt phải chấm cả kết quả lẫn đường đi: chọn công cụ, tham số, nguồn dữ liệu, số lần thử, điều kiện dừng và hành động cuối cùng.

## Bắt đầu từ công việc thật, không bắt đầu từ bộ câu hỏi đẹp

Một lỗi phổ biến là tự viết 20 câu hỏi rất rõ ràng rồi coi đó là bộ test. Người dùng thật hiếm khi nói rõ như vậy. Họ viết thiếu chủ ngữ, gửi sai mã đơn, đổi ý giữa chừng hoặc yêu cầu một việc vượt quá quyền của agent.

Hãy lấy tình huống từ chính quy trình: hội thoại hỗ trợ, yêu cầu nội bộ, log lỗi, trường hợp nhân viên phải sửa tay và những lần hệ thống cũ từng gây nhầm. Sau đó ẩn hoặc loại bỏ dữ liệu cá nhân trước khi đưa vào bộ eval.

Với một agent hỗ trợ bán sách, bộ test không chỉ có câu “Tư vấn sách học Python”. Nó cần cả trường hợp người mua chưa từng lập trình, muốn học automation nhưng lại gửi nhầm ảnh sách Data Engineering; trường hợp khách hỏi bảo hành; trường hợp giá trong câu hỏi không còn đúng; và trường hợp agent không có đủ dữ liệu tồn kho để cam kết.

## Chia bộ eval thành năm nhóm dễ quản lý

Bạn không cần một bảng điểm khổng lồ ngay từ đầu. Năm nhóm sau đã đủ để nhìn ra phần lớn lỗi production:

1. **Hoàn thành nhiệm vụ:** agent có tạo đúng kết quả mà người dùng cần hay chỉ trả lời quanh vấn đề?

2. **Dùng đúng bằng chứng:** câu trả lời có dựa trên tài liệu được phép dùng, còn hiệu lực và liên quan trực tiếp không?

3. **Sử dụng công cụ:** agent có chọn đúng tool, truyền đúng tham số và xử lý kết quả rỗng hoặc lỗi không?

4. **An toàn và quyền hạn:** hành động nào phải xin duyệt, dữ liệu nào không được tiết lộ và khi nào agent phải dừng?

5. **Hiệu quả vận hành:** mỗi nhiệm vụ mất bao lâu, bao nhiêu lượt gọi model, chi phí bao nhiêu và tỷ lệ phải chuyển người thật là bao nhiêu?

Điểm số chỉ có ý nghĩa khi gắn với quyết định. Ví dụ, lỗi trình bày có thể cho phép phát hành rồi sửa dần; gửi nhầm email hoặc cập nhật sai đơn hàng phải là lỗi chặn release.

## Đừng dùng một con số trung bình để che lỗi nghiêm trọng

Giả sử agent đạt 92/100 điểm. Con số nghe rất đẹp, nhưng nếu tám lỗi còn lại đều nằm ở thao tác hoàn tiền thì hệ thống chưa thể được xem là an toàn.

Hãy tách tiêu chí thành hai lớp. Lớp thứ nhất là điều kiện bắt buộc: không lộ dữ liệu, không tự gửi khi chưa được duyệt, không bịa nguồn và không thực hiện hành động ngoài quyền. Chỉ cần trượt một điều kiện, test thất bại. Lớp thứ hai mới là điểm chất lượng như độ rõ ràng, giọng văn, tốc độ hoặc số bước thực hiện.

Cách này khiến dashboard bớt đẹp, nhưng quyết định triển khai đáng tin hơn. Production không cần một agent thắng điểm trung bình; production cần một agent không được phép thua ở chỗ nguy hiểm.

## Trace giúp tìm lỗi nằm ở model hay ở cả hệ thống

Khi agent trả lời sai, phản xạ đầu tiên thường là sửa prompt hoặc đổi model. Nhưng lỗi có thể nằm ở retrieval trả nhầm tài liệu, schema công cụ mơ hồ, timeout khiến tool bị gọi lại hoặc logic ứng dụng đã bỏ qua bước xác nhận.

Trace nên ghi lại phiên bản prompt, model, tool được gọi, tham số đã gửi, kết quả trả về, thời gian từng bước và quyết định cuối. Không ghi dữ liệu nhạy cảm thô nếu không cần thiết. Khi có trace, team mới phân biệt được ba loại lỗi: model suy luận sai; công cụ hoặc dữ liệu sai; hay workflow cho phép một sai lầm nhỏ biến thành hành động lớn.

Đây cũng là lý do cùng một model có thể hoạt động tốt trong sản phẩm này nhưng tệ ở sản phẩm khác. Agent không chỉ là model. Nó là model cộng hướng dẫn, công cụ, dữ liệu, vòng lặp và rào chắn.

## Khi nào dùng chấm tự động, khi nào cần người thật

Chấm tự động phù hợp với tiêu chí rõ: JSON có đúng schema không, có gọi đúng tool không, câu trả lời có dẫn đúng mã tài liệu không hoặc kết quả có khớp dữ liệu chuẩn không. LLM-as-a-judge có thể hỗ trợ đánh giá độ liên quan và chất lượng diễn đạt, nhưng chính bộ chấm này cũng cần được kiểm tra trên các ví dụ đã có người đánh giá.

Con người vẫn cần cho các trường hợp liên quan đến phán đoán, sắc thái, ảnh hưởng tới khách hàng và những lỗi mới chưa từng được mô tả. Một quy trình thực tế là tự động chấm toàn bộ bộ regression, sau đó lấy mẫu các ca rủi ro cao và các ca model chấm thiếu chắc chắn để reviewer đọc lại.

Đừng bắt con người đọc mọi trace; cũng đừng giao toàn bộ quyền phán xét cho một model khác. Mục tiêu là đặt sức người đúng chỗ mà tự động hóa chưa đủ đáng tin.

## Bộ test phải chạy lại sau mỗi thay đổi nhỏ

Thêm một công cụ mới, sửa mô tả tool, đổi nguồn dữ liệu hoặc cập nhật prompt đều có thể làm hành vi agent thay đổi. Một câu trả lời tốt hơn ở nhóm này đôi khi khiến nhóm khác tệ đi. Vì vậy, eval cần trở thành regression test của hệ thống AI chứ không phải một buổi kiểm tra trước ngày ra mắt.

Bạn nên lưu phiên bản bộ test, phiên bản cấu hình và kết quả theo từng lần chạy. Nếu thay model để giảm chi phí, hãy so lại tỷ lệ hoàn thành nhiệm vụ, lỗi quyền hạn, độ trễ và chi phí trên cùng một tập tình huống. Rẻ hơn mỗi request chưa chắc rẻ hơn mỗi nhiệm vụ hoàn thành nếu agent phải thử lại nhiều lần.

## Một quy trình eval nhỏ mà team Việt Nam có thể bắt đầu ngay

Bước đầu tiên, chọn một workflow hẹp và có người chịu trách nhiệm rõ. Thu thập khoảng 30–50 tình huống đã loại dữ liệu nhạy cảm, gồm cả ca bình thường, ca mơ hồ và ca phải từ chối. Với mỗi tình huống, viết kết quả mong đợi, hành động bị cấm và bằng chứng được phép dùng.

Tiếp theo, chạy agent và lưu trace. Chấm điều kiện bắt buộc trước, rồi mới chấm chất lượng và chi phí. Nhóm lỗi theo nguyên nhân thay vì sửa từng câu: mô tả tool chưa rõ, nguồn dữ liệu thiếu, prompt xung đột hay thiếu bước human approval. Sau mỗi lần sửa, chạy lại toàn bộ tập test cũ và bổ sung ca lỗi vừa phát hiện.

Với startup hoặc team sản phẩm tại Việt Nam, cách làm nhỏ này hữu ích hơn việc mua một nền tảng eval phức tạp nhưng chưa thống nhất được thế nào là “đúng”. Công cụ giúp chạy nhanh; tiêu chí đúng-sai vẫn phải đến từ nghiệp vụ thật.

## Những chỉ số nên nhìn cùng nhau

Tỷ lệ hoàn thành nhiệm vụ cho biết agent có giúp người dùng đi đến đích. Tỷ lệ gọi tool đúng cho biết workflow có đi đúng đường. Tỷ lệ chuyển người thật cho biết ranh giới tự động hóa đang đặt ở đâu. Chi phí trên một nhiệm vụ hoàn thành phản ánh thực tế hơn chi phí trên một lượt gọi model. Độ trễ ở phân vị cao cho thấy trải nghiệm của nhóm người dùng gặp ca khó, thay vì chỉ nhìn thời gian trung bình.

Cuối cùng là số lỗi nghiêm trọng trên mỗi lần chạy và số lỗi tái xuất hiện. Nếu một lỗi từng được sửa quay lại, team không chỉ có vấn đề với model; team đang thiếu regression test hoặc kiểm soát phiên bản.

## Đọc sâu hơn về thiết kế AI Agent

Tài liệu của OpenAI về xây dựng agent khuyến nghị thiết lập eval để tạo baseline, sau đó mới tối ưu model, chi phí và độ trễ. Nghiên cứu đánh giá agent cũng nhấn mạnh rằng kết quả phụ thuộc không chỉ vào model mà còn vào harness, công cụ, ngân sách thực thi và quy tắc chấm. Google gần đây mở rộng cách nhìn với coding agent chủ động: hệ thống còn phải biết insight nào đáng báo cho developer và khi nào nên im lặng.

Nếu bạn muốn nối phần đánh giá này với kiến trúc tool use, memory, workflow và human-in-the-loop, có thể xem [AI Agents in Action bản tiếng Việt](/sach/ai-agents-in-action-michael-lanham-2026). Wavi Books phụ trách dữ liệu và nội dung chuyên môn; 89ebook là đối tác thương mại độc quyền phân phối sách tiếng Việt của Wavi Books tại Việt Nam trong thời điểm hiện tại.

Điểm cần nhớ không phải là agent phải đúng 100%. Điểm cần nhớ là team phải biết agent thường sai ở đâu, sai đó gây hậu quả gì và hệ thống sẽ dừng nó trước khi hậu quả chạm tới người dùng như thế nào.