𝗔𝗜 𝗠𝗼𝗱𝗲𝗹 𝗙𝗮𝗶𝗹𝗼𝘃𝗲𝗿 𝗗𝗿𝗶𝗹𝗹𝘀: 𝗞𝗲𝗲𝗽 𝗔𝗴𝗲𝗻𝘁𝘀 𝗨𝘀𝗲𝗳𝘂𝗹 𝗪𝗵𝗲𝗻 𝗣𝗿𝗼𝘃𝗶𝗱𝗲𝗿𝘀 𝗕𝗿𝗲𝗮𝗸

Một cơ chế fallback mô hình chỉ hoạt động trên sơ đồ thì không phải là khả năng phục hồi (resilience). Đó chỉ là một kế hoạch được gắn mác hào nhoáng hơn.

Nếu sản phẩm của bạn sử dụng các AI agent, chỉ cần một nhà cung cấp bị chậm hoặc một đợt tăng đột biến về giới hạn tốc độ (rate-limit) cũng có thể phá hỏng trải nghiệm người dùng. Nguy hiểm thực sự không nằm ở việc ngừng hoạt động hoàn toàn. Nguy hiểm nằm ở một cơ chế fallback hoạt động nửa vời. Điều này xảy ra khi một mô hình dự phòng âm thầm thay đổi định dạng dữ liệu, làm mất trạng thái công cụ (tool state), hoặc bỏ qua các trích dẫn mà không thông báo cho người dùng.

Bạn phải thực hiện các cuộc diễn tập failover thực tế trước khi lưu lượng truy cập thực tế (production traffic) buộc bạn phải học bài học xương máu.

Mục tiêu không phải là làm cho mọi mô hình đều có thể thay thế cho nhau. Mục tiêu là giữ cho quy trình làm việc (workflow) luôn an toàn và trung thực khi mô hình chính gặp lỗi.

Hầu hết các đội ngũ đều sử dụng một chuỗi đơn giản: thử mô hình chính, sau đó đến mô hình dự phòng, rồi hiển thị lỗi. Cách này bỏ lỡ các vấn đề thực sự trong các hệ thống AI. AI thường gặp lỗi theo những cách rất tinh vi:

• Một mô hình dự phòng trả về JSON với ý nghĩa các trường (field) khác nhau. • Một mô hình rẻ hơn bỏ qua các chính sách công cụ (tool policies) của bạn. • Một nhà cung cấp truyền phát (stream) các token quá chậm. • Một mô hình fallback thiếu định dạng gọi hàm (function-calling) tương tự. • Agent thử lại liên tục và làm cạn kiệt ngân sách của người dùng.

Diễn tập failover mô hình AI là một bài kiểm tra có kế hoạch. Bạn cố tình làm gián đoạn một lộ trình mô hình để xem liệu sản phẩm có duy trì được sự an toàn hay không.

Một cuộc diễn tập tốt sẽ kiểm tra:

  • Quy trình làm việc có tiếp tục chạy không?
  • Nó có bảo toàn được schema và trạng thái công cụ (tool state) không?
  • Nó có nằm trong giới hạn ngân sách chi phí và độ trễ không?
  • Nó có tạo ra một bài kiểm tra hồi quy (regression test) cho lần sau không?

Đừng bắt đầu bằng việc làm cho mọi prompt hoạt động được với nhiều nhà cung cấp. Hãy bắt đầu với những quy trình làm việc mà sự cố sẽ làm mất lòng tin.

Các quy trình làm việc ưu tiên cao:

  • Chat tương tác với khách hàng
  • Tạo báo cáo
  • Các quy trình agent có gọi công cụ
  • Trả lời RAG kèm trích dẫn
  • Trích xuất dữ liệu vào các trường có cấu trúc

Thiết kế tốt nhất bắt đầu từ một "hợp đồng" (contract), chứ không phải một danh sách tên các mô hình. Một hợp đồng fallback xác định những gì phải luôn được đảm bảo trên tất cả các nhà cung cấp. Đối với một agent hỗ trợ, điều này có thể bao gồm:

  • Hình dạng (shape) đầu vào và đầu ra
  • Mức độ tin cậy và trích dẫn
  • Quyền hạn công cụ và ngân sách còn lại
  • Các cổng chất lượng (quality gates) và quy tắc xác thực

Đôi khi, phương án fallback đúng đắn không phải là một mô hình khác. Nó có thể là:

  • Yêu cầu người dùng xác nhận
  • Trả về kết quả một phần
  • Đưa tác vụ vào hàng đợi để xử lý sau
  • Chuyển quy trình làm việc sang cho con người kiểm duyệt

Đừng coi mọi lỗi là lý do để thử một mô hình khác. Hãy sử dụng một model adapter để chuẩn hóa các lỗi và định dạng. Điều này giúp các bài diễn tập của bạn dễ dàng hơn vì bạn có thể mô phỏng các lỗi mà không cần thay đổi logic chính.

Hãy bắt đầu với ba bài diễn tập sau:

  1. Bài diễn tập Timeout: Ép mô hình chính rơi vào trạng thái ngủ (sleep). Xác minh rằng cơ chế fallback diễn ra trong phạm vi ngân sách độ trễ (latency budget) của bạn.
  2. Bài diễn tập Rate Limit: Ép xảy ra lỗi 429. Xác minh rằng hệ thống của bạn sử dụng cơ chế backoff và bảo vệ ngân sách của tenant.
  3. Bài diễn tập Schema: Ép mô hình trả về JSON không hợp lệ. Xác minh rằng hệ thống của bạn kiểm tra (validate) đầu ra hoặc dừng quy trình làm việc một cách an toàn.

Người dùng không cần biết chi tiết về nhà cung cấp của bạn. Họ cần sự phản hồi trung thực.

Thông báo tồi: Đã có lỗi xảy ra. Thông báo tốt: Tôi vẫn có thể giúp, nhưng các hành động trực tiếp hiện đang bị giới hạn tạm thời. Tôi có thể soạn thảo bước tiếp theo để bạn xem xét.

Hãy xây dựng niềm tin thông qua các ranh giới rõ ràng, chứ không phải bằng cách giả vờ như mọi thứ vẫn ổn.

Nguồn: https://dev.to/jackm-singularity/ai-model-failover-drills-keep-agents-useful-when-providers-break-1p5j

Cộng đồng học tập tùy chọn: https://t.me/GyaanSetuAi