Đánh giá tác tử AI phải là một phần của quy trình phát triển và phát hành sản phẩm. Đây không phải hoạt động kiểm tra bên lề. Nhóm cần chạy các tình huống cố định trên toàn bộ đường thực thi và lưu bằng chứng về dữ liệu, công cụ và quyền. Sau đó, cổng phát hành phải chặn những phiên bản vi phạm chính sách hoặc tạo ra hành động chưa được phê duyệt.
Một lần chạy thành công chỉ chứng minh hệ thống đã hoạt động trong điều kiện của lần chạy đó. Theo bài viết gốc của The New Stack về đánh giá tác tử AI, vấn đề thường chỉ lộ ra sau khi cấu hình truy xuất hoặc mô hình thay đổi. Tác tử vẫn có thể trả lời câu hỏi cũ nhưng bỏ sót trích dẫn bắt buộc hoặc chọn nhầm công cụ tra cứu khách hàng.
Nguyên tắc này không thay đổi theo quy mô dự án. Dù tác tử phục vụ nhân viên nội bộ hay khách hàng, nhóm vẫn phải chứng minh được nó đã dùng đúng dữ liệu, gọi đúng công cụ và tuân thủ đúng quyền trước khi cho phép phiên bản mới đi vào vận hành.
Nội dung: xác định hành vi đúng trước khi viết bài kiểm tra
Nhóm cần chuyển khái niệm câu trả lời “khá tốt” thành các yêu cầu có thể quan sát và kiểm tra lại. Mỗi công việc phải có kết quả mong đợi, giới hạn hành động, bằng chứng bắt buộc và cách xử lý khi thiếu dữ liệu.
Với một tác tử hỗ trợ khách hàng, nhiệm vụ có thể là trả lời câu hỏi thanh toán bằng hồ sơ thuộc đúng tài khoản và viện dẫn chính sách đang có hiệu lực. Tác tử không được tự thay đổi gói dịch vụ hoặc để lộ dữ liệu của khách hàng khác. Nếu không tìm thấy chính sách, nó phải thừa nhận thiếu dữ liệu thay vì biến suy đoán thành sự thật. Trong một số trường hợp, tác tử cần yêu cầu mã tài khoản trước khi tiếp tục hoặc chuyển ngoại lệ cho người có quyền phù hợp.
Đánh giá kết quả và quá trình riêng biệt
Kết quả và quá trình tạo ra kết quả phải được đánh giá riêng. Một tác tử có thể đưa ra câu trả lời đúng sau khi truy xuất nhầm tài liệu. Nó cũng có thể hoàn thành tác vụ bằng cách gọi công cụ không cần thiết, tìm kiếm ngoài phạm vi khách hàng hoặc chuyển một yêu cầu thông thường cho con người. Bản ghi trò chuyện vẫn có vẻ thành công, nhưng đường thực thi đã chứa lỗi.
Mỗi công việc nên bắt đầu bằng một số yêu cầu quan sát được. Thông tin bắt buộc phải có nguồn được nêu tên. Thao tác ghi dữ liệu phải chờ xác nhận. Khi thiếu dữ liệu, tác tử phải hỏi thay vì đoán. Quy tắc có rủi ro cao cần điều kiện kiểm tra chính xác, còn cách diễn đạt có thể cho phép một mức biến thiên nhất định.
Xây dựng tình huống từ công việc thực tế
Một bộ đánh giá ban đầu có thể bắt đầu với 10 tác vụ thực tế, sau đó mở rộng bằng các lỗi phát hiện trong vận hành. Cách tiếp cận này giữ bộ thử sát với hành vi của người dùng và đủ nhỏ để nhóm duy trì trong giai đoạn đầu.
The New Stack đề xuất bắt đầu bằng 10 tác vụ thực tế. Con số này hữu ích hơn một bộ điểm chuẩn lớn chứa những câu lệnh mà người dùng không bao giờ gửi, đồng thời vẫn đủ nhỏ để một nhóm có thể duy trì.
Phiếu hỗ trợ, nhật ký quy trình, báo cáo sự cố và trao đổi với người dùng là nguồn đầu vào phù hợp. Bộ thử cần có những yêu cầu thông thường tạo nên phần lớn khối lượng công việc, sau đó bổ sung trường hợp chỉ dẫn mơ hồ, thiếu dữ liệu tài khoản, tài liệu đã cũ hoặc công cụ hết thời gian chờ. Một số tình huống phải yêu cầu phê duyệt trước khi tác tử hành động. Những yêu cầu hiếm gặp nhưng hợp lệ cũng cần được giữ lại.
Mô phỏng hội thoại nhiều lượt
Tác tử hoạt động qua nhiều lượt nên bài thử cũng phải mô phỏng nhiều lượt. Người dùng có thể yêu cầu thay đổi tài khoản ở lượt đầu, cung cấp mã còn thiếu ở lượt tiếp theo và xác nhận thay đổi ở lượt thứ ba. Bài thử cần kiểm tra tác tử có giữ đúng mã tài khoản và nội dung thay đổi xuyên suốt cuộc hội thoại hay không. Chi tiết không liên quan cũng không được đưa vào thao tác cuối.
Mỗi tình huống cần một bộ dữ liệu cố định. Nhóm phải đóng băng tài liệu, phản hồi của công cụ và trạng thái tài khoản tại một thời điểm đã biết. Phiên bản chính sách cùng quyền của tác tử cũng phải được cố định. Nếu không thể tái hiện một lỗi, cuộc điều tra dễ biến thành tranh luận về dữ liệu mà hệ thống có thể đã nhìn thấy. Dữ liệu thử cố định biến vấn đề đó thành việc kỹ thuật có thể xử lý.
Mọi lỗi quan trọng trong môi trường vận hành nên trở thành một ca hồi quy lâu dài. Lỗi đã xảy ra cần được giữ lại như một điều kiện phải vượt qua, không chỉ được sửa rồi bỏ quên.
Kiểm tra toàn bộ đường thực thi
Đánh giá tác tử AI phải kiểm tra cả câu trả lời cuối lẫn quá trình truy xuất dữ liệu, chọn công cụ, điền tham số, kiểm tra quyền và thực hiện hành động. Một câu trả lời thuyết phục không bù được lỗi xảy ra trong đường thực thi.
Dấu vết thực thi cần lưu yêu cầu của người dùng và chỉ dẫn hệ thống, phiên bản chính xác của mô hình cùng bản dựng ứng dụng. Câu lệnh, cấu hình truy xuất và lược đồ công cụ phải có phiên bản. Nhóm cũng cần ghi từng nguồn đã truy xuất, phiên bản của nguồn, mỗi lần gọi công cụ, tham số, kết quả, bước kiểm tra quyền và câu trả lời cuối. Độ trễ, lượng đơn vị xử lý văn bản và chi phí cũng thuộc về dấu vết này.
| Thành phần | Bằng chứng cần lưu | Mục đích kiểm tra |
|---|---|---|
| Đầu vào | Yêu cầu và chỉ dẫn hệ thống | Tái hiện lần chạy |
| Phiên bản | Mô hình và bản dựng ứng dụng | Xác định thay đổi |
| Truy xuất | Nguồn và phiên bản nguồn | Kiểm tra căn cứ |
| Công cụ | Lệnh gọi, tham số và kết quả | Phát hiện sai đường thực thi |
| Quyền | Kết quả kiểm tra phía máy chủ | Chặn truy cập sai phạm vi |
| Đầu ra | Câu trả lời hoặc hành động cuối | Đánh giá kết quả |
Kiểm tra quyền và phạm vi truy cập
Khi kết hợp với cơ chế bắt buộc ở phía máy chủ và nhật ký kiểm toán, dấu vết phải cho biết hoạt động tìm kiếm có nằm trong đúng phạm vi hay không. Phạm vi đó gồm đơn vị thuê dịch vụ và tài khoản khách hàng tương ứng. Dấu vết cũng phải chỉ ra chính sách được phê duyệt và hồ sơ được trích dẫn. Với thao tác ghi, nó cần chứng minh người dùng đã xác nhận thay đổi và bước kiểm tra quyền phía máy chủ đã thành công. Đây là các điều kiện xác định: chúng đã xảy ra hoặc chưa xảy ra.
Độ rõ ràng và tính hữu ích khó chấm theo kiểu tuyệt đối hơn. Người đánh giá hoặc mô hình chấm điểm có thể xem câu trả lời đã giải quyết yêu cầu, giải thích giới hạn hay đặt câu hỏi bổ sung hợp lý chưa. Kết quả đánh giá phải được gắn với dấu vết để khi điểm giảm, nhóm có thể tìm ra bước đã thay đổi.
Bản thân bộ chấm bằng mô hình cũng có thể sai lệch sau khi nâng cấp hoặc thay đổi tiêu chí. Vì vậy, phiên bản mô hình chấm và chỉ dẫn của nó phải được lưu cùng kết quả. Nhóm nên thường xuyên đối chiếu một mẫu điểm số với đánh giá của con người.
Tách quy tắc bắt buộc khỏi điểm số biến thiên
Cổng đánh giá phải tách những điều kiện bắt buộc khỏi các chỉ số có thể cân nhắc theo ngưỡng. Lỗi quyền, truy xuất sai phạm vi và hành động chưa được phê duyệt phải chặn phát hành, trong khi độ trễ, chi phí hoặc cách diễn đạt có thể được xem xét như quyết định sản phẩm.
Chất lượng của tác tử không thể gói trong một con số duy nhất. Mức độ hoàn thành tác vụ và căn cứ sự thật nên được theo dõi riêng với chất lượng truy xuất. Tuân thủ chính sách cũng phải tách khỏi trải nghiệm người dùng, độ trễ và chi phí.
| Loại đánh giá | Ví dụ | Cách xử lý |
|---|---|---|
| Quy tắc bắt buộc | Kiểm tra quyền | Không đạt thì chặn |
| Quy tắc bắt buộc | Xác nhận trước thao tác ghi | Không đạt thì chặn |
| Chỉ số biến thiên | Độ trễ | So với ngưỡng |
| Chỉ số biến thiên | Độ rõ ràng | Chấm điểm và xem xét |
| Chỉ số biến thiên | Chi phí | So với mốc |
Theo ví dụ của The New Stack, một phản hồi chậm thêm 200 mili giây vẫn có thể chấp nhận được, và một câu trả lời dài hơn đôi chút có thể rõ ràng hơn. Ngược lại, cập nhật chưa được phê duyệt, truy xuất chéo giữa các đơn vị thuê dịch vụ hoặc thiếu bước xác nhận phải chặn phát hành bất kể các điểm số khác tốt đến đâu.
So sánh phiên bản ứng viên với mốc chuẩn
Phiên bản ứng viên cần được so với một mốc đã biết trên cùng tình huống và cùng dữ liệu thử. Người duyệt nên thấy câu trả lời nào đã thay đổi, dữ liệu nào đứng sau chúng và đường gọi công cụ khác nhau ở đâu. Nếu phiên bản mới hoàn thành nhiều tác vụ hơn nhưng tăng gấp đôi độ trễ, nhóm có thể cân nhắc đó như một quyết định sản phẩm. Nếu điểm trung bình tăng nhưng một cổng quyền bị bỏ qua, phiên bản đó không đạt.
Khi hành vi có tính biến thiên, tình huống phải được chạy lặp lại. The New Stack nêu ví dụ một tác vụ chỉ thành công một lần trong 10 lần thử. Kết quả như vậy chưa đạt ngưỡng phát hành đáng tin cậy. Ngưỡng nên phản ánh mức rủi ro, còn những quy tắc hệ thống bắt buộc phải tuân thủ trong mọi lần chạy cần được kiểm tra tuyệt đối.
Khái niệm pass@k hỏi liệu có ít nhất một lần thành công trong k lần thử hay không, trong khi pass^k hỏi liệu toàn bộ k lần đều thành công. Phần giải thích của Anthropic về các phép đo đánh giá tác tử AI cho thấy pass^k phù hợp khi tính nhất quán là yêu cầu quan trọng. Tuy nhiên, phép đo này không thay thế được cổng kiểm tra chính xác đối với quyền và chính sách.
Chọn công cụ và kiểm soát chi phí
Nhóm không nhất thiết phải tự xây toàn bộ hạ tầng. Promptfoo, DeepEval, LangSmith và Braintrust đều có khả năng hỗ trợ quy trình đánh giá, tùy công cụ có thể bao gồm chạy tình huống, thu dấu vết và dùng mô hình để chấm kết quả. Những nhóm đang tìm hiểu cách tác tử lập trình AI hoạt động cũng cần lưu ý rằng công cụ đánh giá chỉ hữu ích khi bài thử đi qua cùng mã ứng dụng, công cụ và lớp quyền được dùng trong sản phẩm thật.
Đánh giá trực tiếp từ đầu đến cuối luôn phát sinh chi phí vì mỗi lần chạy mô hình đều tiêu tốn đơn vị xử lý văn bản. Mô hình chấm tốn kém hơn phép so sánh chuỗi đơn giản, còn một bộ thử lớn chạy ở mọi lần cập nhật sẽ nhanh chóng làm chi phí tăng. Những đánh giá đắt hơn nên dành cho tình huống có rủi ro thực sự.
Biến đánh giá thành cổng phát hành
Cổng phát hành phải chạy lại bộ thử khi mô hình, câu lệnh, cấu hình truy xuất, chính sách bộ nhớ hoặc giao diện công cụ thay đổi. Cổng này chặn lỗi rủi ro cao, áp dụng ngưỡng cho suy giảm có thể đo và chuyển các thay đổi mơ hồ cho người có trách nhiệm xem xét.
Một bộ thử nhanh có thể phục vụ các cập nhật thông thường, còn bộ rộng hơn được dùng trước đợt phát hành lớn hoặc chuyển mô hình. Nếu hành vi thay đổi có chủ đích, người duyệt cần phê chuẩn kỳ vọng mới. Việc sửa bài kiểm tra chỉ để phiên bản hiện tại vượt qua sẽ làm mất giá trị của cổng phát hành.
Kiểm soát dữ liệu đánh giá
Dữ liệu đánh giá cần được kiểm soát giống dữ liệu của chính tác tử. Dấu vết có thể chứa văn bản truy xuất, chỉ dẫn nội bộ, tham số công cụ, thông tin định danh hoặc thông tin xác thực. Nhóm phải quản lý phiên bản, giới hạn quyền truy cập và cân nhắc che giá trị nhạy cảm trước khi lưu. Mã hóa, kiểm soát truy cập và thời hạn lưu giữ cần phù hợp với loại dữ liệu liên quan.
Giữ dữ liệu đánh giá gần dữ liệu vận hành có thể rút ngắn đường xử lý. Theo tài liệu Oracle AI Vector Search, hệ thống có thể lưu biểu diễn véc tơ cạnh dữ liệu nghiệp vụ, đồng thời kết hợp tìm kiếm tương đồng với bộ lọc quan hệ và tìm kiếm từ khóa bằng truy vấn SQL. Nền tảng dữ liệu cũng có thể lưu dấu vết đánh giá và áp dụng chính sách truy cập theo hàng hoặc cột.
Nền tảng cụ thể không quan trọng bằng những thành phần phải được giữ ổn định: các ca đánh giá lâu dài, đầu vào của từng lần chạy và hồ sơ giải thích vì sao mỗi bản dựng được thông qua. Đây cũng là một phần của bài toán tích hợp AI ở quy mô lớn. Không có dấu vết và cổng phát hành, nhóm khó biết một thay đổi ở mô hình, truy xuất hay công cụ đã tác động đến hành vi nào trong sản phẩm.
Bắt đầu với 10 ca và giữ lại mọi lỗi quan trọng
Quy trình ban đầu gồm bốn việc: chọn 10 tác vụ thật, mô tả kết quả và hành động bị cấm, cố định dữ liệu thử, rồi chạy lại toàn bộ ca trước lần phát hành kế tiếp. Mỗi sự cố quan trọng sau đó phải trở thành một ca hồi quy lâu dài.
Ghi kỳ vọng và cố định dữ liệu thử
The New Stack khuyến nghị chọn 10 tác vụ thật ngay trong tuần này. Với mỗi tác vụ, nhóm ghi kết quả mong đợi, bằng chứng tác tử phải sử dụng và những hành động bị cấm. Sau đó, nhóm cố định dữ liệu thử, thu dấu vết và chạy lại các ca trước lần phát hành kế tiếp.
- Chọn 10 tác vụ từ phiếu hỗ trợ, nhật ký và phản hồi thực tế.
- Ghi kết quả mong đợi, bằng chứng bắt buộc và hành động bị cấm.
- Cố định tài liệu, trạng thái tài khoản, quyền và phản hồi công cụ.
- Thu dấu vết của toàn bộ đường thực thi.
- Chặn phát hành nếu vi phạm quyền hoặc chính sách.
- Thêm mọi sự cố quan trọng vào bộ hồi quy.
Giữ lại lỗi mới làm ca hồi quy
Khi người dùng tìm thấy một lỗi mà nhóm chưa dự đoán, lỗi ấy cũng được giữ lại. Bộ đánh giá sẽ lớn dần cùng sản phẩm và trở thành hồ sơ về những sai sót nhóm đã gặp, đã trả giá và không muốn lặp lại.
Niềm tin vào tác tử AI tăng lên khi nhóm có thể phát lại điều đã xảy ra và chứng minh phiên bản tiếp theo vẫn tuân thủ những giới hạn người dùng dựa vào. Hệ thống đánh giá vì thế là một phần của sản phẩm được phát hành.
Hãy theo dõi Sine để tiếp tục cập nhật cách xây dựng, kiểm soát và vận hành tác tử AI trong sản phẩm thực tế.
