Hướng dẫn Kiến trúc Xử lý Lỗi cho Gọi Công cụ LLM
Trong quá trình phát triển, việc một tác nhân AI gọi API bên ngoài có vẻ dễ dàng. Nhưng trong môi trường sản xuất, điều này lại trở thành một rủi ro. Để xử lý lỗi cho các cuộc gọi công cụ của LLM hoàn toàn phụ thuộc vào mô hình sẽ đảm bảo rằng các pipeline tự động sẽ bị hỏng ngay khi một dịch vụ kết nối gặp sự cố hoặc hoạt động sai.
Hướng dẫn này phác thảo một chiến lược phòng thủ đa lớp, bao gồm các loại lỗi, chiến lược thử lại và dự phòng, cũng như suy luận lỗi ở cấp độ mô hình. Những bản thiết kế kiến trúc này sẽ chỉ cho bạn cách xây dựng các tác nhân mạnh mẽ, sẵn sàng cho sản xuất.
Việc nhầm lẫn giữa lỗi công cụ có thể thử lại và không thể thử lại là một trong những cách nhanh nhất để phá hỏng các tác nhân trong sản xuất. Khi một cuộc gọi công cụ thất bại, hệ thống phải xác định nguyên nhân thay vì gửi lại yêu cầu một cách mù quáng hoặc ném ra một ngoại lệ chung chung.
Logic vận hành này yêu cầu phân chia trách nhiệm khôi phục giữa hai lớp: lớp điều phối và chính LLM. Lớp điều phối chịu trách nhiệm thử lại ở cấp độ hạ tầng một cách im lặng cho các vấn đề tạm thời. Mô hình chịu trách nhiệm khôi phục dựa trên suy luận khi một vấn đề ở cấp độ ứng dụng yêu cầu thay đổi hành vi của tác nhân.
Việc phân tách rõ ràng các khối hệ thống này đòi hỏi phải xem xét các lỗi trong sản xuất qua bốn loại riêng biệt và ánh xạ từng loại vào lớp khôi phục thích hợp của nó.
Kết nối TCP bị ngắt, thời gian chờ phân giải DNS tạm thời và phản hồi HTTP "503 Service Unavailable" tiêu chuẩn là các ví dụ về gián đoạn cấp độ hạ tầng. Những vấn đề này hoàn toàn tạm thời và nằm ngoài logic ứng dụng. Vì vậy, lớp điều phối nên chặn chúng và xử lý khôi phục một cách im lặng thông qua các lần thử lại ở cấp độ mạng. LLM cơ bản không nên biết rằng đã xảy ra lỗi vận chuyển.
Loại này bao gồm các trường hợp API phía dưới có thể truy cập được nhưng từ chối yêu cầu. Điều này xảy ra do các ràng buộc vận hành phía trên, chẳng hạn như đạt giới hạn tốc độ (429 Too Many Requests) hoặc gặp sự cố nền tảng nội bộ (500 Internal Server Error). Lớp điều phối chịu trách nhiệm cho quá trình khôi phục này. Nó cần kiểm tra các tiêu đề phản hồi, trích xuất hướng dẫn giới hạn và trì hoãn thực thi trước khi thử lại.
Những lỗi này xảy ra khi một dịch vụ hoặc cơ sở dữ liệu phía trên từ chối cuộc gọi công cụ do không khớp schema, thiếu tham số bắt buộc hoặc định dạng dữ liệu không hợp lệ (400 Bad Request). Vì bản thân payload có cấu trúc sai, lớp điều phối không thể sửa chữa nó. Mô hình phải đọc lỗi, điều chỉnh suy luận và tạo ra một yêu cầu đã được sửa. Điều này giữ cho quy trình làm việc ổn định vì tác nhân sửa nguyên nhân gốc thay vì lặp lại cùng một cuộc gọi không hợp lệ.
Loại này bao gồm các tình huống mà công cụ phía dưới thực thi thành công ở lớp mạng nhưng trả về lỗi cụ thể của ứng dụng. Ví dụ bao gồm truy vấn cơ sở dữ liệu trả về không có bản ghi hoặc API trả về chuỗi JSON không thể phân tích cú pháp, bị hỏng. Lớp mô hình chịu trách nhiệm khôi phục ở đây. Tác nhân phải tiếp nhận đầu ra bất ngờ này để suy luận về lỗi vận hành. Từ đó,
Nó tự động quyết định bước tiếp theo, dù là thay đổi đường thực thi, chuyển sang công cụ dự phòng, hay chuyển vấn đề trực tiếp cho con người.
**Tách biệt các lần thử lại tạm thời khỏi quá trình phục hồi cấp mô hình trên cùng một canvas**
Đối với các lỗi vận chuyển tạm thời và lỗi dịch vụ bên ngoài, lớp điều phối phải thực thi một cơ chế thử lại có cấu trúc để tránh làm quá tải các API hạ nguồn. Tiêu chuẩn sản xuất dựa trên **backoff theo cấp số nhân** kết hợp với **jitter toàn phần**. Điều này đảm bảo các lần thử lại được dãn cách dần dần và ngẫu nhiên hóa về mặt toán học để tránh vấn đề "bầy đàn ồ ạt". Hệ thống cũng nên chủ động phân tích các tiêu đề `Retry-After` do các điểm cuối bị giới hạn gửi đến, ghi đè các khoảng thời gian mặc định để tuân thủ giới hạn tốc độ của bên thứ ba.
Khi các lần thử lại tự động ở cấp hệ thống không giải quyết được vấn đề, stack sản xuất của bạn cần một đường dẫn dự phòng được xác định để tránh toàn bộ quá trình chạy bị sập. Một số lỗi yêu cầu lớp điều phối phải định tuyến xung quanh một dịch vụ chết. Các lỗi cấu trúc khác yêu cầu mô hình phải chủ động suy luận vấn đề và thích ứng. Thay vì coi các lớp này là các phương pháp thiết kế đối lập, các kiến trúc agent cấp sản xuất triển khai chúng cạnh nhau.
Khi một công cụ bên ngoài ném ra một ngoại lệ, các nhà phát triển thường có xu hướng bắt nó, dừng chuỗi thực thi và từ bỏ việc xử lý lỗi thêm. Một mẫu kiên cường hơn là định dạng lỗi ứng dụng đó thành một chuỗi có cấu trúc sạch sẽ, truyền nó trở lại như một kết quả công cụ và liên kết nó với ID gọi công cụ ban đầu. Bằng cách trả lại ngữ cảnh ngoại lệ thô trực tiếp vào đồ thị thực thi, bạn cho phép mô hình đọc thông báo lỗi như dữ liệu và thông minh hình thành bước tiếp theo của nó.
Ngay cả với các prompt hệ thống nghiêm ngặt, một LLM đôi khi sẽ gọi một tên hàm không tồn tại trong định nghĩa runtime của nó hoặc phát ra một payload vi phạm lược đồ JSON. Đây là một rào cản phổ biến khi triển khai gọi hàm LLM, nơi mô hình gặp khó khăn với các ràng buộc có cấu trúc. Nếu framework truyền lệnh gọi sai này, nó sẽ gây ra sự cố. Thay vào đó, lớp điều phối nên chặn lệnh gọi không hợp lệ và chèn một vòng lặp phản hồi sửa lỗi trực tiếp vào lịch sử hội thoại:
[LLM gọi công cụ không tồn tại: "Fetch_User_Data_v2"]
[Lớp điều phối bắt lỗi và thêm thông báo hệ thống]
"Lỗi: Công cụ 'Fetch_User_Data_v2' không tồn tại. Các công cụ có sẵn là: ['get_user_profile', 'update_user']."
[LLM đọc ngữ cảnh sửa lỗi, tự động sửa logic runtime và gọi 'get_user_profile']
Cho phép một agent kiểm tra lỗi của chính nó và thử lại thực thi công cụ là vô cùng mạnh mẽ. Nhưng nếu không có ranh giới nghiêm ngặt, nó sẽ giới thiệu một rủi ro mới. Nếu một LLM gặp lỗi logic dai dẳng, nó có thể rơi vào vòng lặp, liên tục gọi cùng một công cụ hỏng và nhanh chóng tiêu tốn ngân sách token của bạn.
Để ngăn chặn các vòng lặp thực thi vô hạn này, lớp điều phối của bạn cần thực thi một bộ đếm cứng trên các lần thử lại của mô hình. Hệ thống nên cắt bớt
Vòng lặp sẽ kích hoạt cảnh báo hệ thống rõ ràng khi vượt quá ngưỡng đã định trước (thường là ba lần thử).
Khi một hệ thống bên ngoài chính gặp sự cố ngoại tuyến, mô hình không nên bị lỗi. Bạn có thể thiết kế các chuỗi dự phòng ở cả lớp mô hình và lớp công cụ để đảm bảo tính khả dụng cao. Ví dụ, nếu mô hình nền tảng cao cấp của bạn gặp sự cố ngừng hoạt động hoặc bị giới hạn tốc độ nghiêm trọng giữa tác vụ, khung điều phối của bạn có thể chuyển đổi ngữ cảnh thực thi sang nhà cung cấp đám mây thứ cấp hoặc giải pháp mã nguồn mở cục bộ. Tương tự, nếu lệnh gọi công cụ CRM chính của bạn liên tục thất bại, pipeline có thể bắt lỗi và chuyển hướng tải trọng đến công cụ cơ sở dữ liệu sao lưu thứ cấp.
Không phải mọi lỗi công cụ đều cần phải kết thúc một phiên hoạt động. Nếu nhiệm vụ chính của agent là tạo một báo cáo thị trường toàn diện và công cụ dịch thuật của nó bị lỗi, hệ thống nên thực hiện suy giảm có kiểm soát. Lớp điều phối có thể bắt lỗi công cụ, thêm ghi chú cho biết mô-đun dịch thuật tạm thời không khả dụng và hướng dẫn mô hình xuất văn bản cuối cùng bằng ngôn ngữ gốc của nó. Cung cấp một tài sản có giá trị cao nhưng hoàn thành một phần hầu như luôn tốt hơn việc trả về một trang lỗi trống cho người dùng cuối.
Khi một phụ thuộc bên ngoài gặp sự cố ngừng hoạt động kéo dài, việc tiếp tục gửi các yêu cầu thử lại tự động sẽ lãng phí tài nguyên cơ sở hạ tầng mạng và khiến hệ thống của bạn phải chịu độ trễ timeout dài. Việc triển khai mẫu circuit breaker ngăn chặn điều này bằng cách theo dõi các lỗi liên tiếp trên tất cả các lần chạy agent đang hoạt động.
Circuit breaker hoạt động như một máy trạng thái phân tán trực tiếp trong lớp quy trình làm việc của bạn, cách ly hoàn toàn các phụ thuộc bị hỏng cho đến khi chúng được xác nhận hoạt động trở lại. Trong các framework ưu tiên mã, việc thiết lập này yêu cầu xây dựng middleware tùy chỉnh có trạng thái hoặc kéo vào các thư viện cơ sở hạ tầng chuyên dụng phức tạp. Nhưng với một nền tảng tự động hóa trực quan, bạn có thể thiết kế và kết nối toàn bộ máy trạng thái trực tiếp vào bố cục quy trình làm việc mà không cần thêm nhiều cơ sở hạ tầng.
