Hiện nay có một mô hình phổ biến trong ngành AI: cho một mô hình ngôn ngữ quyền truy cập công cụ rồi để nó tự quyết định gọi công cụ nào. Mô hình này hoạt động rất đẹp trong các bản trình diễn. Nhưng nó thất bại khi đưa vào vận hành thực tế.
Tại Atlas Verified, tác nhân AI của chúng tôi có quyền truy cập hơn 100 công cụ chuyên biệt — cơ sở dữ liệu tuân thủ của chính phủ, API theo dõi tàu, dịch vụ sàng lọc trừng phạt, nhà cung cấp dữ liệu thương mại, hệ thống theo dõi container và nhiều công cụ khác. Mỗi công cụ tồn tại vì một chuyên gia tuân thủ cần chính điểm dữ liệu đó để đưa ra quyết định xác minh. Thách thức kỹ thuật không phải là xây dựng các công cụ. Đó là bảo đảm các công cụ phù hợp được gọi theo đúng thứ tự, với đúng dữ liệu đầu vào, trong mọi lần thực hiện.
Bài viết này phân tích những vấn đề thực tế của việc điều phối công cụ ở quy mô lớn và các mô hình kỹ thuật mà chúng tôi đã phát triển để giải quyết chúng.
Vấn đề bùng nổ số lượng công cụ
Khi tác nhân có 5 công cụ, việc chọn công cụ rất đơn giản. Mô hình đọc mô tả của từng công cụ, chọn công cụ phù hợp rồi gọi nó. Nhưng hệ thống bắt đầu gặp vấn đề khi mở rộng vượt quá 20, 50, 100 công cụ.
Trước hết là vấn đề cửa sổ ngữ cảnh. Mỗi công cụ cần có mô tả, lược đồ tham số và hướng dẫn sử dụng trong lời nhắc hệ thống. Với 100+ công cụ, hàng chục nghìn token đã bị sử dụng trước khi câu hỏi của người dùng được đưa vào ngữ cảnh. Mô hình dành nhiều thời gian đọc tài liệu công cụ hơn là suy nghĩ về vấn đề.
Thứ hai là vấn đề độ chính xác khi lựa chọn. Các mô hình ngôn ngữ giỏi lựa chọn giữa một vài phương án được phân biệt rõ ràng. Chúng kém trong việc lựa chọn giữa hàng chục công cụ có tên nghe tương tự nhau. Khi có nhiều công cụ với tên gọi trùng lặp dành cho kiểm tra và sàng lọc trừng phạt, mô hình thường chọn nhầm công cụ — hoặc gọi nhiều công cụ trả về dữ liệu trùng lặp.
Thứ ba là vấn đề chi phí và độ trễ. Mỗi mô tả công cụ trong lời nhắc đều tiêu tốn token. Mỗi lần gọi công cụ không cần thiết đều tiêu tốn lượt gọi API tới các dịch vụ bên ngoài, trong đó nhiều dịch vụ tính phí theo từng yêu cầu. Một tác nhân gọi 8 công cụ trong khi chỉ cần 3 công cụ sẽ vừa tốn kém vừa chậm.
Vì sao định tuyến tĩnh không hiệu quả
Giải pháp đơn giản ban đầu là định tuyến tĩnh: đối chiếu mẫu trong câu hỏi của người dùng rồi chuyển tới các nhóm công cụ đã định sẵn. "Kiểm tra công ty này" kích hoạt sàng lọc trừng phạt. "Theo dõi container này" kích hoạt theo dõi tàu. "Xác minh chứng nhận này" kích hoạt tra cứu USDA.
Cách này lập tức gặp vấn đề trong thực tế. Hãy xem câu hỏi: "Bạn có thể xác minh chứng nhận hữu cơ này từ Ấn Độ không?" Một bộ định tuyến tĩnh có thể kích hoạt tra cứu cơ sở dữ liệu hữu cơ USDA — điều đó hợp lý. Nhưng một chuyên gia tuân thủ còn muốn biết: Tổ chức chứng nhận có bị trừng phạt không? Có cảnh báo nhập khẩu FDA đang có hiệu lực đối với sản phẩm từ quốc gia đó không? Nhà xuất khẩu có xuất hiện trong bất kỳ danh sách bên bị từ chối giao dịch nào không? Có bất thường thương mại trong tuyến đường được khai báo không?
Một câu hỏi của người dùng hoàn toàn có thể cần năm công cụ trở lên thuộc các lĩnh vực khác nhau. Định tuyến tĩnh hoặc bỏ sót các kiểm tra quan trọng, hoặc kích hoạt quá mức tất cả công cụ, khiến chúng ta quay lại vấn đề chi phí và độ chính xác.
Ngữ cảnh có vai trò vô cùng quan trọng. "Hãy cho tôi biết về công ty này" có ý nghĩa hoàn toàn khác nhau tùy việc người dùng đang xem vận đơn, chứng nhận hữu cơ hay đang trao đổi nghiên cứu tổng quát. Cùng bốn từ trong câu tiếng Anh gốc này đòi hỏi các công cụ khác nhau trong từng ngữ cảnh.
Kiến trúc hai lớp: Lựa chọn và thực thi
Giải pháp của chúng tôi tách lựa chọn công cụ khỏi thực thi công cụ bằng hai lớp mô hình riêng biệt.
Lớp lựa chọn sử dụng một mô hình nhanh và ít tốn kém. Nhiệm vụ duy nhất của nó là xem câu hỏi của người dùng, ngữ cảnh hội thoại và danh mục ngắn gọn các công cụ sẵn có, sau đó chọn những công cụ nên được cung cấp cho tương tác cụ thể này. Nó không gọi các công cụ — chỉ quyết định mô hình thực thi nên được truy cập những công cụ nào.
Mô hình lựa chọn nhận được bản mô tả tinh gọn của mỗi công cụ: mô tả một dòng, dữ liệu mà công cụ trả về và các giới hạn của nó. Nội dung này gọn hơn nhiều so với lược đồ tham số đầy đủ, nên mô hình lựa chọn có thể đánh giá cả 100+ công cụ mà không chạm giới hạn ngữ cảnh. Thông thường, nó chọn 8-12 công cụ liên quan đến câu hỏi hiện tại.
Lớp thực thi sử dụng một mô hình suy luận có năng lực cao hơn. Nó chỉ nhận những công cụ mà lớp lựa chọn đã chọn, cùng lược đồ tham số đầy đủ và hướng dẫn sử dụng. Vì làm việc với một nhóm công cụ tập trung thay vì toàn bộ danh mục, nó đưa ra quyết định tốt hơn về công cụ cần gọi, thứ tự gọi và tham số sử dụng.
Sự phân tách này mang lại lợi ích có thể đo lường. Việc lựa chọn mất một phần nhỏ của giây và có chi phí rất thấp. Mô hình thực thi nhận được ngữ cảnh rõ ràng, tập trung và mắc ít lỗi hơn. Tổng số lần gọi công cụ trong mỗi tương tác giảm đáng kể sau khi chúng tôi triển khai kiến trúc này.
Lọc dựa trên khả năng
Ngoài cơ chế lựa chọn hai lớp, mỗi công cụ trong hệ thống còn khai báo các khả năng của nó — những loại nhiệm vụ mà nó có thể thực hiện. Một công cụ có thể khai báo rằng nó hữu ích cho kiểm tra tuân thủ, thông tin thương mại, phân tích tài liệu hoặc theo dõi lô hàng.
Khi hệ thống xác định ý định của người dùng, nó lọc danh mục để chỉ giữ các công cụ có khả năng phù hợp. Mô hình lựa chọn thậm chí không nhìn thấy các công cụ không liên quan đến loại nhiệm vụ hiện tại.
Điều này quan trọng vì một lý do tinh tế: các mô hình ngôn ngữ dễ bị gợi ý tác động. Nếu một công cụ sàng lọc trừng phạt có trong ngữ cảnh, mô hình có thể quyết định chạy kiểm tra trừng phạt ngay cả khi người dùng chỉ hỏi đơn giản về tuyến vận chuyển. Bằng cách loại bỏ các công cụ không liên quan trước bước lựa chọn, chúng tôi loại bỏ hẳn một nhóm lượt gọi công cụ không cần thiết.
Vòng phản hồi chất lượng
Lựa chọn công cụ chỉ là một nửa công việc. Nửa còn lại là bảo đảm công cụ trả về kết quả hữu ích — và biết phải làm gì khi chúng không đáp ứng điều đó.
Sau mỗi lần thực thi công cụ, hệ thống đánh giá chất lượng kết quả. Các dạng lỗi thường gặp bao gồm:
Kết quả trống. Công cụ chạy thành công nhưng không trả về dữ liệu. Điều này có thể có nghĩa là thực thể không tồn tại trong cơ sở dữ liệu đó (một phát hiện hợp lệ và có giá trị thông tin), hoặc truy vấn được xây dựng chưa tốt (một vấn đề cần sửa rồi thử lại).
Kết quả khớp có độ tin cậy thấp. Tìm kiếm tên gần đúng trả về kết quả nhưng điểm đối chiếu thấp hơn ngưỡng. Hệ thống cần quyết định nên trình bày chúng như các kết quả khớp tiềm năng hay loại bỏ và thử một chiến lược tìm kiếm khác.
Cỡ mẫu không đủ. Một truy vấn dữ liệu thương mại chỉ trả về kết quả từ một nguồn, trong khi cần đối chiếu chéo nhiều nguồn để bảo đảm độ tin cậy. Hệ thống nhận ra khoảng trống này và có thể yêu cầu thêm các lượt gọi công cụ để bổ sung.
Khi các kiểm tra chất lượng không đạt, hệ thống đưa hướng dẫn trở lại vòng suy luận của tác nhân. Đây không phải chỉ là thử lại đơn giản — mà là thử lại có định hướng, giải thích điều gì đã xảy ra và gợi ý cách xây dựng lại truy vấn.
Cung cấp kết quả từng bước
Xác minh tuân thủ thương mại vốn là một quá trình nhiều bước. Người dùng tải lên vận đơn và yêu cầu tác nhân xác minh. Tác nhân cần kiểm tra người gửi hàng với các danh sách trừng phạt, xác minh chứng nhận hữu cơ, tra cứu vị trí hiện tại của tàu, kiểm tra cảnh báo nhập khẩu FDA đối với hàng hóa và xác nhận phân loại thuế quan. Những kiểm tra này mất thời gian khác nhau.
Thay vì bắt người dùng chờ mọi kiểm tra hoàn tất mới hiển thị bất kỳ thông tin nào, chúng tôi truyền kết quả từng bước. Khi mỗi công cụ trả về, kết quả của nó được định dạng ngay và cung cấp cho giao diện người dùng. Người dùng thấy kết quả trừng phạt xuất hiện, tiếp đến dữ liệu tàu rồi trạng thái chứng nhận hữu cơ, mỗi kết quả được hiển thị dưới dạng thẻ có cấu trúc ngay khi sẵn sàng.
Bước tổng hợp cuối cùng, tạo bản tóm tắt bằng lời kết nối tất cả kết quả, chỉ chạy sau khi mọi công cụ đã hoàn tất.
Xác minh tự động: Khép kín quy trình
Khi tài liệu được xử lý qua quy trình OCR của chúng tôi, hệ thống trích xuất xác định các điểm dữ liệu chính — mã NOP, tên công ty, mã định danh tàu, số container, mã cảng và mã HS. Mỗi điểm dữ liệu này được liên kết với các công cụ xác minh cụ thể.
Thay vì đợi người dùng yêu cầu "xác minh tài liệu này", hệ thống tính trước các gợi ý xác minh. Khi người dùng mở một cuộc hội thoại về tài liệu, tác nhân đã biết cần gọi công cụ nào và dùng tham số gì. Điều này giảm mạnh thời gian cần để xác minh: tác nhân không cần đọc tài liệu, xác định thực thể rồi tìm xem cần kiểm tra gì. Nó đã có sẵn một kế hoạch xác minh để thực thi.
Các nguyên tắc
Việc xây dựng hệ thống này đã làm rõ một số nguyên tắc mà chúng tôi cho rằng có thể áp dụng rộng rãi trong kỹ thuật tác nhân AI:
Tách lựa chọn khỏi thực thi. Đừng để mô hình suy luận đồng thời làm mô hình định tuyến. Hãy dùng các mô hình rẻ, nhanh để phân loại và các mô hình tốn kém, có năng lực cao để suy luận.
Giảm lựa chọn, tăng độ chính xác. Một mô hình lựa chọn giữa 10 công cụ phù hợp luôn làm tốt hơn một mô hình lựa chọn giữa 100 công cụ. Hãy đầu tư vào việc lọc trước khi lựa chọn.
Xác nhận sau khi thực thi, không chỉ trước đó. Các lượt gọi công cụ có thể thất bại theo những cách không thể dự đoán. Hãy xây dựng các vòng phản hồi chất lượng để phát hiện kết quả kém và hướng dẫn việc thử lại.
Truyền kết quả liên tục, không chờ gom thành lô. Người dùng nên thấy kết quả ngay khi chúng được trả về. Việc cung cấp từng bước không chỉ cải thiện trải nghiệm người dùng — nó thay đổi căn bản cách người dùng tương tác với dữ liệu xác minh.
Làm rõ ý định. Đừng để mô hình tự suy đoán thế nào là "tốt". Hãy nói rõ cho nó. Việc lập kế hoạch mục tiêu biến sự khám phá mở thành xác minh có định hướng.
Tác nhân AI của Atlas Verified điều phối 100+ công cụ xác minh chuyên biệt để tự động hóa kiểm tra tuân thủ thương mại trên toàn chuỗi cung ứng toàn cầu.