Khi tác tử AI thất bại, mô hình không nhất thiết là nguyên nhân. Lỗi có thể nằm ở công cụ, dữ liệu trả về, khung điều phối hoặc môi trường thực thi. Đội kỹ thuật cần dựng lại toàn bộ quá trình từ yêu cầu đến kết quả trước khi quyết định thay mô hình.
Theo bài viết gốc của The New Stack, tác tử có thể tự chọn công cụ, đổi hướng giữa chừng và tiếp tục chạy sau một quyết định sai. Kết quả cuối cùng vì thế chỉ cho thấy triệu chứng, không xác định được thành phần gây lỗi.
Khả năng quan sát truyền thống không còn đủ
Nhật ký cùng dữ liệu đầu vào và đầu ra không thể hiện đầy đủ nguyên nhân thất bại của tác tử AI. Kỹ sư còn phải biết tác tử đã đi qua những bước nào. Họ cũng cần xác định công cụ được sử dụng, điểm mắc kẹt và thời điểm tác tử đổi hướng.
Trong phần mềm thông thường, sự cố thường để lại một điểm bắt đầu rõ ràng. Đó có thể là một ngoại lệ, yêu cầu thất bại hoặc dịch vụ ngừng hoạt động. Tác tử AI có thể không tạo ra dấu hiệu tương tự. Nó vẫn chạy sau một quyết định sai ở bước trước và tạo ra kết quả có vẻ hoàn chỉnh.
The New Stack cho biết ngay cả những tác tử lập trình có hiệu suất tốt nhất cũng thất bại trong hơn 60% nhiệm vụ lấy từ các kho mã thực tế. Con số này cho thấy việc phát hiện thất bại và việc xác định nguyên nhân là hai vấn đề riêng biệt.
Adel el Hallak là Phó chủ tịch phụ trách sản phẩm của Nvidia. Ông cho rằng chỉ xem nhật ký, dữ liệu đầu vào và đầu ra là chưa đủ. Điều tra có thể đòi hỏi phát lại toàn bộ quá trình thực thi để tìm bước đầu tiên làm tác tử đi sai hướng. Đây cũng là lý do việc hiểu cách tác tử AI lập trình hoạt động quan trọng hơn việc chỉ đánh giá câu trả lời cuối cùng.
Môi trường thực thi là nơi thu thập dấu vết
Môi trường thực thi là lớp phù hợp để ghi lại hoạt động của tác tử vì nó nằm trên đường đi giữa mô hình, khung điều phối và công cụ. Dấu vết tại đây giúp đội kỹ thuật phân biệt lỗi mô hình với lỗi điều phối, dữ liệu hoặc chính sách.
OpenShell cung cấp khả năng quan sát quá trình thực thi
Nvidia xem môi trường thực thi là điểm thu thập phần lớn thông tin cần thiết. OpenShell nằm bên dưới nền tảng NemoClaw và quản lý vùng cách ly cùng chính sách. Nó cũng cung cấp khả năng quan sát quá trình hoạt động của tác tử.
El Hallak gọi OpenShell là thành phần không thể bỏ qua trong các kiến trúc tham chiếu của Nvidia. Theo ông, đội phát triển có thể thay khung điều phối hoặc mô hình, nhưng vẫn cần một môi trường thực thi mở, an toàn và có cơ chế quản trị.
Nvidia chia hệ thống tác tử thành ba lớp:
- Mô hình cung cấp năng lực xử lý.
- Khung điều phối tổ chức công việc và đường đi của tác tử.
- Môi trường thực thi kiểm soát hoạt động, chính sách và dấu vết.
Khung điều phối cũng có thể gây lỗi
Cách phân lớp này giúp đội kỹ thuật tránh quy mọi sự cố về mô hình. Nghiên cứu NOAH của Nvidia cho thấy hiệu suất tác tử có thể cải thiện khi đổi khung điều phối nhưng giữ nguyên mô hình. Một khung điều phối không phù hợp vì thế có thể kéo giảm khả năng của một mô hình vốn đủ tốt.
Mỗi mô hình có cách phản hồi khác nhau, nên mô hình và khung điều phối cần được phát triển cùng nhau hoặc có cấu hình riêng phù hợp. Góc nhìn này gắn trực tiếp với bài toán hạ tầng AI và cách vận hành: khả năng của mô hình chỉ là một phần, còn chất lượng thực tế phụ thuộc vào cách các lớp trong hệ thống phối hợp.
An toàn AI là một bài toán kỹ thuật hệ thống
An toàn của tác tử AI phụ thuộc vào khả năng kiểm thử, cách ly, giám sát và tái hiện lỗi trên toàn hệ thống. Kiểm soát quyền truy cập sẽ không đủ nếu đội vận hành không thể xác định tác tử đã làm gì và dựa vào dữ liệu nào để ra quyết định.
Jensen Huang, Tổng giám đốc Nvidia, mô tả an toàn AI là một vấn đề kỹ thuật. El Hallak so sánh cách tiếp cận đó với kiểm thử phần mềm truyền thống: nếu phần mềm có lỗi, đội phát triển không phát hành mà tiếp tục sửa cho đến khi vượt qua các bài kiểm thử.
Tác tử khiến quy trình này phức tạp hơn vì tái hiện lỗi có thể đòi hỏi dựng lại những gì đã xảy ra trên toàn hệ thống. Việc thu thập đủ dấu vết cũng tạo thêm chi phí. The New Stack dẫn lại kết quả của OpenAI về chi phí giám sát. Hoạt động này làm tăng khoảng 20% lượng tính toán suy luận đối với những tác tử hoạt động lâu dài có năng lực cao nhất của hãng.
Cách tiếp cận của Nvidia kết hợp khung điều phối có quản trị, môi trường thực thi được cách ly và điện toán bảo mật nhằm bảo vệ mô hình cùng dữ liệu người dùng. El Hallak cho rằng cơ chế bảo đảm có thể được kéo dài xuống tận lớp chip.
Khi tác tử được trao nhiều khả năng hành động hơn, câu hỏi AI nên được trao bao nhiêu quyền phải đi cùng khả năng truy vết và kiểm soát trong lúc thực thi.
SAFE đưa việc chia sẻ lỗi ra ngoài từng công ty
Secure Agent Findings Exchange, gọi tắt là SAFE, hướng đến một cơ chế chung để các tổ chức báo cáo lỗi của tác tử. Việc chia sẻ giúp những bên khác nhận diện và vá cùng một kiểu lỗ hổng thay vì phải tự phát hiện lại.
Nvidia đang tham gia SAFE. Theo The New Stack, sáng kiến này được khoảng 140 công ty ủng hộ và hướng đến xây dựng hạ tầng báo cáo lỗi dựa trên cách ngành phần mềm truyền thống công bố lỗ hổng.
El Hallak cho rằng khi một công ty phát hiện lỗ hổng, thông tin đó không chỉ hữu ích cho riêng công ty ấy mà còn giúp những bên khác vá lỗi. SAFE muốn tránh tình trạng mỗi đội phải tự phát hiện lại cùng một kiểu thất bại.
Phần mềm truyền thống đã có các cơ chế chia sẻ lỗ hổng và bản sửa lỗi. Với tác tử AI, một hệ thống tương đương vẫn chưa hình thành. Khó khăn nằm ở chỗ lỗi có thể trải qua nhiều lớp, từ mô hình, công cụ và khung điều phối đến môi trường thực thi.
Khi một tác tử gỡ lỗi cho tác tử khác
Một tác tử có thể tìm lỗ hổng trong khi tác tử khác tạo bản vá, nhưng kết quả cuối không tự giải thích nguyên nhân khi một trong hai thất bại. Việc điều tra vẫn cần dữ liệu về mô hình, công cụ và đường đi trong quá trình thực thi.
CrowdStrike đang tinh chỉnh các mô hình Nemotron của Nvidia bằng dữ liệu bảo mật tích lũy qua nhiều năm. Mục tiêu là tạo thành một cặp tác tử. Một tác tử tìm cách khai thác lỗ hổng, tác tử còn lại vá lỗ hổng đó.
Nếu một trong hai đi sai hướng, một bản vá kém có thể bắt nguồn từ mô hình, đường đi trong quá trình thực thi hoặc công cụ mà tác tử đã sử dụng. El Hallak nhấn mạnh rằng một nhiệm vụ cụ thể cần năng lực chuyên biệt thay vì một hệ thống đa dụng.
Khi doanh nghiệp xây tác tử cho quy trình chuyên biệt, lỗi có thể không xuất hiện trong phép đánh giá mô hình đa dụng hoặc bài kiểm tra an toàn phổ biến. Đội nền tảng vì thế phải giải quyết hai việc riêng biệt. Họ cần phát hiện thất bại và dựng lại đủ quá trình thực thi để tìm nguyên nhân.
Nội dung cần kiểm tra trước khi thay mô hình
Trước khi thay mô hình, đội kỹ thuật nên kiểm tra đường đi của yêu cầu, công cụ được gọi, dữ liệu trả về, quyết định đổi hướng và chính sách của môi trường thực thi. Trình tự này giúp xác định thành phần gây lỗi thay vì phản ứng với riêng kết quả đầu ra.
- Đường đi của yêu cầu từ lúc bắt đầu đến khi tạo kết quả.
- Các công cụ mà tác tử đã gọi và thứ tự gọi.
- Dữ liệu do từng công cụ trả về.
- Thời điểm tác tử đổi hướng hoặc lặp lại một bước.
- Chính sách được áp dụng trong môi trường thực thi.
Nếu không có những dấu vết đó, đội ngũ chỉ nhìn thấy triệu chứng ở đầu ra. Một mô hình tốt vẫn có thể hoạt động kém trong khung điều phối không phù hợp. Ngược lại, một lỗi tưởng thuộc về mô hình có thể biến mất khi cách tổ chức công việc được sửa.
Khi tác tử AI thất bại, hãy bắt đầu bằng việc dựng lại toàn bộ quá trình thực thi rồi mới quyết định có cần thay mô hình hay không.
