AI agent tôi triển khai đã vượt qua 23 unit test, nhưng chỉ trong vòng một giờ sau khi chạy thực tế, nó đã tự bịa ra một tính năng sản phẩm và báo giá thấp hơn ba lần so với thực tế. Khi người dùng chỉ ra lỗi, bot càng khẳng định chắc chắn hơn, cuộc hội thoại kết thúc, và tôi mất luôn một khách hàng. Sai lầm này chứng minh rằng một bộ unit test có tính xác định (deterministic) không thể đảm bảo độ tin cậy của một agent.

Tại sao unit test không đủ cho các AI agent

Unit test hoạt động hiệu quả với mã nguồn truyền thống vì cùng một đầu vào luôn cho ra cùng một đầu ra. "2 + 2 = 4" là một sự đảm bảo mà bạn có thể xác minh bằng một phép kiểm tra bằng nhau đơn giản. Tuy nhiên, một agent vận hành bằng LLM sẽ thay đổi đầu ra tùy thuộc vào prompt, ngữ cảnh xung quanh và trạng thái của bất kỳ công cụ bên ngoài nào mà nó gọi. Một bài kiểm tra chỉ kiểm tra sự bằng nhau chính xác của chuỗi ký tự sẽ bỏ lỡ các lỗi ảo giác (hallucinations), sự thay đổi tông giọng hoặc vi phạm các guardrails. Thất bại thầm lặng khiến tôi mất khách hàng cho thấy rằng bạn phải đánh giá toàn bộ quá trình tương tác, chứ không chỉ các hàm riêng lẻ.

Xây dựng một hệ thống đánh giá (evaluation harness) trước khi viết mã tính năng

Tôi đã đảo ngược quy trình phát triển: thiết kế một hệ thống đánh giá (evaluation harness) bốn lớp trước, sau đó mới viết agent. Hệ thống này chạy 131 bài kiểm tra trong một lần duy nhất, chi phí khoảng ba cent mỗi lần chạy và hoàn tất trong khoảng mười một phút. Tôi gán mỗi bài kiểm tra cho mô hình nhỏ nhất có thể xử lý được nó, dành riêng các mô hình lớn hơn, đắt tiền hơn cho những thời điểm chúng thực sự mang lại giá trị.

Lớp 1 – Chức năng của công cụ (Tool functionality)

Tuyến phòng thủ đầu tiên kiểm tra xem agent có gọi các công cụ của nó một cách chính xác hay không. Các bài kiểm tra bao gồm tìm kiếm thành công, các truy vấn cố tình viết sai định dạng và các lỗi API mô phỏng. Vì việc sử dụng công cụ phần lớn là có tính xác định — hoặc là yêu cầu được tạo chính xác hoặc API sẽ trả về lỗi — nên các câu lệnh assertion trong Python là đủ. Việc phát hiện một yêu cầu sai định dạng ở bước này sẽ ngăn chặn sự nhầm lẫn ở các bước sau.

Lớp 2 – Tuân thủ hướng dẫn (Instruction following)

Tiếp theo, hệ thống đánh giá sẽ xác minh xem agent có tôn trọng các guardrails hay không. Một LLM nhỏ hơn sẽ đóng vai trò là bộ đánh giá, quét phản hồi của agent để kiểm tra sự tuân thủ: giữ đúng nhân vật, tránh các chủ đề bị cấm và xuất ra đúng schema JSON yêu cầu. Lớp này bắt được sự lệch lạc về ngữ nghĩa (semantic drift) mà unit test thường bỏ lỡ, chẳng hạn như việc trượt sang một persona không mong muốn hoặc làm rò rỉ các prompt nội bộ.

Lớp 3 – Hành vi hướng mục tiêu (Goal-oriented behavior)

Lớp thứ ba là quan trọng nhất. Nó đặt câu hỏi liệu agent có thực sự hoàn thành mục đích của mình hay không. Đối với một bot tìm kiếm khách hàng tiềm năng (lead-generation bot), điều đó có nghĩa là xác nhận nó có đặt đúng các câu hỏi sàng lọc và chuyển giao cho con người khi thích hợp hay không. Tôi sử dụng một mô hình thiên về lập luận (reasoning-oriented model) ở đây vì nó có thể đánh giá luồng tổng thể mà không làm tăng chi phí. Nếu bot thất bại trong việc đạt được mục tiêu — ngay cả khi đã vượt qua hai lớp đầu tiên — nó sẽ bị đánh dấu để thiết kế lại.

Lớp 4 – Hiệu suất (Performance)

Cuối cùng, hệ thống ghi lại độ trễ và tốc độ tạo token. Phản hồi chậm sẽ làm xói mòn trải nghiệm người dùng, đặc biệt là trong chat thời gian thực. Bằng cách theo dõi các chỉ số này cùng với tính chính xác về chức năng, tôi đảm bảo agent vừa chính xác vừa có khả năng phản hồi nhanh.

Các lựa chọn tiết kiệm chi phí

Con số 0,03 USD mỗi lần chạy không phải là một chiêu trò marketing; nó đến từ việc khớp độ phức tạp của bài kiểm tra với kích thước mô hình. Các kiểm tra công cụ có tính xác định chạy trên môi trường runtime rẻ nhất, việc tuân thủ hướng dẫn sử dụng một mô hình nhẹ, và chỉ có các đánh giá hướng mục tiêu mới gọi đến một mô hình mạnh mẽ hơn, dù đắt tiền hơn. Cách tiếp cận phân tầng này giữ cho tổng chi phí đủ thấp để có thể chạy toàn bộ bộ kiểm tra sau mỗi lần thay đổi mã nguồn.

Sự đánh đổi: tốc độ và sự an toàn

Việc đưa vào một hệ thống đánh giá đã tạo ra những trở ngại ban đầu. Các chu kỳ phát triển bị kéo dài và tiến độ ra mắt bị chậm lại.

Những điều cần lưu ý tiếp theo

  • Các bộ đánh giá dựa trên mô hình (Model-driven evaluators): Khi các LLM cải tiến, bộ đánh giá ở Lớp 2 có thể trở nên tinh vi hơn, giúp giảm thiểu các trường hợp dương tính giả trong khi vẫn phát hiện được các vi phạm chính sách tinh vi.

Bài học rút ra

Nếu bạn xây dựng các AI agent để đưa vào vận hành thực tế (production), một hệ thống đánh giá phân lớp không phải là tùy chọn; nó là nền tảng. Bằng cách đầu tư trước chi phí cho việc kiểm thử toàn diện — 0,03 USD mỗi lần chạy, mười một phút cho mỗi bộ kiểm tra — bạn sẽ bảo vệ mình trước những thất bại thầm lặng mà unit test đơn thuần không thể phát hiện được.