Fallback trong ứng dụng AI là cách xử lý thay thế khi model hoặc một bước workflow không thể cho kết quả đạt yêu cầu. Tùy nguyên nhân, hệ thống có thể retry giới hạn, dùng model đã đánh giá, áp quy tắc, hỏi thêm dữ liệu hoặc chuyển người. Lựa chọn cần giữ quyền và báo rõ trạng thái.
Fallback nghĩa là gì trong ứng dụng AI?
Model call không phải bước duy nhất có thể lỗi. Request có thể không qua xác thực, dữ liệu không đủ, truy xuất không tìm được nguồn, model timeout, response sai schema, nội dung không đạt tiêu chí, công cụ bên ngoài không phản hồi hoặc bước phê duyệt chưa hoàn tất. Thiết kế fallback phải bắt đúng lớp lỗi thay vì gom tất cả thành “AI không hoạt động”.
Fallback tốt không nhất thiết luôn tạo câu trả lời khác. Trong nhiều tình huống, phản hồi an toàn là nói chưa thể hoàn thành, đề nghị người dùng kiểm tra đầu vào hoặc chuyển nhân viên. Mục tiêu là đưa hệ thống về trạng thái có thể dự đoán, bảo toàn dữ liệu/quyền và cho người dùng bước tiếp theo.
Model dự phòng là một loại fallback, không phải phương án mặc định cho mọi lỗi. Model thứ hai có thể khác về khả năng, chính sách dữ liệu, region, output format, độ trễ và chất lượng. Nếu ứng dụng không kiểm tra những khác biệt đó, chuyển tuyến chỉ đổi một lỗi kỹ thuật thành lỗi nghiệp vụ khó nhận biết.
Hãy tách retry khỏi fallback. Retry gửi lại cùng tác vụ khi lỗi có khả năng tạm thời. Fallback đổi cách xử lý khi retry không phù hợp hoặc đã thất bại: model khác đã đánh giá, quy tắc xác định, câu trả lời cached còn hiệu lực, hàng đợi xử lý sau hay chuyển người. Mỗi nhánh cần điều kiện, owner và cách hiển thị trạng thái.
Phân loại lỗi trước khi chọn phương án
Phân loại theo nguyên nhân giúp tránh retry lỗi không thể tự hết:
- Lỗi người dùng/đầu vào: thiếu trường, định dạng sai, câu hỏi ngoài phạm vi hoặc dữ liệu vượt giới hạn.
- Lỗi quyền/policy: user không có quyền, nội dung bị chặn bởi quy định hoặc connector không được phép.
- Lỗi tạm thời phía dịch vụ: timeout, mất kết nối, provider đang quá tải hoặc lỗi gateway.
- Lỗi quota/limit: hết hạn mức theo client, tenant hoặc model.
- Lỗi chất lượng: model trả thiếu nguồn, sai schema, thiếu căn cứ hoặc không đạt rubric.
- Lỗi công cụ/dữ liệu: search index không sẵn, tool call sai tham số, nguồn mâu thuẫn hoặc tài liệu chưa cập nhật.
- Lỗi an toàn/nghiêm trọng: nguy cơ lộ dữ liệu, hành động ngoài quyền, output tác động cao hoặc khả năng prompt injection.
Không phải mọi lỗi trả status giống nhau đều có cùng cách xử lý. Một lỗi từ connector có thể báo timeout, nhưng nếu nghiệp vụ yêu cầu dữ liệu đó để kết luận, app không nên dùng câu trả lời cache hoặc mặc định. Mặt khác, câu hỏi thiếu một thông tin có thể được giải quyết bằng cách hỏi lại thay vì đưa người dùng tới đội hỗ trợ.
Thuộc tính của chính sách fallback
Mỗi error policy cần có các trường cụ thể để frontend, backend, on-call và nhóm nghiệp vụ xử lý nhất quán.
- Trigger: điều kiện quan sát để phân loại lỗi, mã lỗi, timeout hay kết quả validation.
- Retry rule: lỗi nào retry được, giới hạn số lần, deadline, backoff và idempotency.
- Fallback path: model/tác vụ thay thế, rule-based response, yêu cầu thêm dữ liệu, hàng đợi hoặc người phụ trách.
- Compatibility: schema, capability, nguồn dữ liệu, quyền truy cập, region và rubric mà tuyến dự phòng phải đáp ứng.
- User message: trạng thái, điều đã hoàn thành/chưa hoàn thành và hành động kế tiếp.
- Data behavior: dữ liệu có được lưu, retry, redacted hay xóa không; không tạo bản ghi trùng.
- Observability: request ID, mã lỗi, route, retry count, thời gian, owner, log trường nào được phép.
- Recovery: điều kiện quay lại tuyến chính, circuit breaker, cách bật/tắt và runbook.
Ma trận lỗi và cách xử lý
| Tình huống | Fallback có thể chọn | Điều kiện/giới hạn |
|---|---|---|
| Đầu vào thiếu | Hỏi lại trường bắt buộc, lưu draft nếu phù hợp. | Không tự điền giả; nêu chính xác thông tin cần bổ sung. |
| Timeout tạm thời | Retry giới hạn; sau đó báo chưa hoàn tất hoặc chuyển hàng đợi. | Tính vào deadline tổng; tránh retry vô hạn và submit trùng side effect. |
| Quota hoặc rate limit | Trả trạng thái thử lại sau, queue hoặc route dự phòng được duyệt. | Không lặp cùng request ngay nếu hạn mức chưa hồi; giữ công bằng theo tenant. |
| Model chính lỗi | Chọn model khác đã test hoặc quy trình thủ công. | Xác minh data policy, capability, schema và chất lượng trước failover. |
| Không có nguồn phù hợp | Trả lời chưa tìm thấy, hỏi thêm hoặc chuyển chuyên gia. | Không tạo câu trả lời tổng quát như thể có bằng chứng trong kho. |
| Output sai schema | Validation, một bước repair có giới hạn, hoặc dừng. | Không thực thi tool/action trên output chưa qua kiểm tra. |
| Output chất lượng thấp | Yêu cầu làm rõ, truy xuất lại có tiêu chí, hoặc chuyển người. | Không gọi model lặp đến khi tình cờ ra đáp án dễ nghe. |
| Rủi ro an toàn/quyền | Fail closed, cô lập action, báo owner hoặc chuyển người. | Không hạ guardrail để giữ tính sẵn sàng. |
Workflow xử lý request lỗi
- Gán request ID và kiểm tra đầu vào. Trước khi gọi model, xác thực user, quyền, schema và giới hạn payload. Lỗi ở đây thường cần sửa input hoặc quyền, không phải thử model khác.
- Gọi tuyến chính có deadline. Đặt timeout theo tổng budget ứng dụng, bao gồm truy xuất, model, tool và frontend. Đừng để từng bước tự cộng retry mà vượt thời hạn người dùng chấp nhận.
- Phân loại kết quả. Dùng status/error code và validation. Tách lỗi tạm thời, quota, đầu vào, policy, chất lượng và action nguy hiểm để chọn nhánh.
- Áp retry có giới hạn. Chỉ retry lỗi có khả năng tạm thời; giữ idempotency key cho thao tác có side effect, tăng khoảng chờ theo cơ chế của nền tảng và giới hạn số lần.
- Đánh giá fallback. Kiểm tra tuyến thay thế có thể xử lý đúng task/dữ liệu/quyền và trả output phù hợp. Nếu không có tuyến đã được kiểm chứng, dừng an toàn hoặc chuyển người.
- Validate đầu ra lần nữa. Kiểm tra schema, nguồn, quyền và điều kiện nghiệp vụ trước khi hiển thị hoặc thực thi action. HTTP thành công không có nghĩa nội dung đạt yêu cầu.
- Thông báo và ghi log tối thiểu. Cho biết phần nào chưa xong, request ID và bước kế tiếp. Log route, loại lỗi, retry và latency nhưng quản lý nội dung nhạy cảm theo chính sách.
- Hồi phục có giám sát. Cảnh báo owner, kiểm tra nguồn lỗi, cập nhật trạng thái circuit breaker và thử phục hồi trước khi khôi phục lưu lượng đầy đủ.
Google Cloud API Gateway mô tả model routing có request log và monitoring phục vụ chẩn đoán route/failure; đây là ví dụ triển khai cụ thể. Hệ thống khác có telemetry khác nhau, nên cần xác minh trường log và error taxonomy theo provider đang dùng thay vì mặc định mã lỗi tương đương.
Ví dụ và prompt thiết kế
Hãy xét trợ lý tìm quy trình nội bộ có câu trả lời phải dựa trên tài liệu hiện hành. Khi model chính timeout, app có thể thử lại một lần trong deadline còn lại. Nếu tiếp tục lỗi, nó hiển thị “chưa tạo được câu trả lời”, giữ request ID và liên kết tìm kiếm thủ công. Nếu model dự phòng được duyệt, app chỉ chuyển route khi nguồn, quyền người dùng và khả năng trích citation tương thích; nếu không, chuyển tới nhóm hỗ trợ.
Nếu search không tìm ra tài liệu, đó không phải cùng loại lỗi với provider timeout. Retry model có thể không tạo nguồn mới. App nên nêu chưa tìm thấy căn cứ, hỏi từ khóa khác hoặc chuyển owner kho nội dung. Nếu truy xuất trả tài liệu mà user không được phép xem, đây là lỗi authorization; fallback tuyệt đối không được bypass bằng tài khoản có quyền rộng.
Tạo ma trận fallback cho luồng [mô tả] theo các lỗi: đầu vào thiếu, model timeout/quota, tool lỗi, output sai schema, nguồn trống/mâu thuẫn, chất lượng thấp và rủi ro an toàn. Với từng lỗi, ghi tín hiệu phát hiện, có retry không, budget, route dự phòng được phép, cách validate, thông điệp người dùng, dữ liệu log, owner và điều kiện khôi phục. Đánh dấu giả định; không coi model khác là tương thích nếu chưa có bằng chứng và test.
Prompt có thể giúp liệt kê nhánh, nhưng việc áp chính sách phải nằm trong cấu hình và logic ứng dụng có thể test. Nếu agent được quyền gọi công cụ, validate tên tool, tham số và quyền ở lớp server. Không chỉ nhắc trong prompt “hãy cẩn thận”; hệ thống phải chặn hành động không được cấp.
Điều kiện retry, failover và chuyển người
- Nếu lỗi tạm thời và request an toàn để lặp: retry với giới hạn, deadline và cơ chế chống side effect trùng.
- Nếu thiếu dữ liệu đầu vào: hỏi người dùng bổ sung hoặc dừng, không gọi thêm model để suy đoán.
- Nếu lỗi quota: thông báo/queue hoặc chọn tuyến được phép theo quota; không tăng vô hạn retry.
- Nếu model chính lỗi: failover chỉ khi endpoint đã kiểm thử về dữ liệu, capability, schema và chất lượng.
- Nếu chất lượng thấp hoặc nguồn vắng: hỏi lại, trả không đủ căn cứ, hoặc chuyển người; không lặp gọi để ép một câu trả lời.
- Nếu có lỗi quyền/an toàn: dừng action, fail closed, ghi nhận sự cố và thông báo nhóm phụ trách theo runbook.
Microsoft Learn về rủi ro agent nhấn mạnh quyền tối thiểu, khả năng tạm dừng và yêu cầu approval cho hành động rủi ro cao/khó đảo ngược. Vì vậy, fallback không nên làm giảm yêu cầu người duyệt chỉ để giữ uptime. Trong một số ứng dụng, trạng thái “chưa thể xử lý” tốt hơn response tự động không đáng tin.
Lỗi thiết kế thường gặp
- Retry mọi lỗi: làm tăng độ trễ/tải trong khi đầu vào sai hoặc quyền bị từ chối vẫn không đổi.
- Retry vô hạn: request treo và provider bị quá tải nặng thêm.
- Failover mù: model thứ hai khác policy/schema hoặc không có dữ liệu cùng quyền.
- Fallback trả cache không kiểm tra độ mới: thông tin cũ xuất hiện như hiện hành.
- Output HTTP 200 được coi là thành công: schema có thể sai, citation rỗng hoặc nội dung không đủ căn cứ.
- Che lỗi bằng lời trả lời chung: người dùng không biết task có hoàn tất và có thể dựa vào kết quả bịa.
- Không kiểm soát action lặp: retry gửi email/tạo ticket/giao dịch hai lần.
- Không có người nhận: escalation tạo hàng đợi mồ côi mà không ai theo dõi.
Checklist kiểm thử fallback
- Liệt kê taxonomy lỗi theo từng dependency.
- Test đầu vào invalid, policy deny, timeout, quota, lỗi tool, output sai và nguồn không có.
- Xác nhận retry có deadline và không tạo side effect lặp.
- Kiểm thử model dự phòng bằng eval cùng quyền/schema/nguồn.
- Xác nhận fallback không lộ dữ liệu hoặc trả response cũ.
- Kiểm tra thông điệp frontend nói đúng trạng thái và request ID.
- Diễn tập circuit breaker, chuyển người, khôi phục và rollback.
Để đặt KPI cho fallback và chất lượng, xem cách đánh giá ứng dụng LLM. Khi xây kiến trúc ứng dụng từ ý tưởng đến vận hành, tham khảo bản đồ kỹ năng xây ứng dụng AI.
Google Cloud API Gateway gọi model routing là Public Preview. defaultModel được chọn khi model trong request không khớp rule; đây là định tuyến theo payload, không phải tự failover khi upstream timeout hoặc trả lỗi. Failover runtime cần được thiết kế riêng với điều kiện lỗi, giới hạn retry và model đã kiểm thử. Hãy xác minh giới hạn Preview hiện hành trước khi phụ thuộc vào tính năng này.
Nguồn tham khảo
Không có một fallback phù hợp cho mọi lỗi. Hãy xác định behavior theo mức ảnh hưởng, quyền, khả năng khôi phục và yêu cầu của từng ứng dụng.
Câu hỏi thường gặp
Retry có nên áp dụng cho mọi lỗi model không?
Không. Retry hợp lý với một số lỗi tạm thời trong deadline, nhưng đầu vào sai, quyền bị từ chối, quota hoặc nguồn thiếu cần nhánh khác. Giới hạn số lần và bảo vệ side effect để request lặp không tạo hành động trùng.
Khi nào nên chuyển sang model dự phòng?
Khi có lỗi tuyến chính và model dự phòng đã được đánh giá cho cùng loại nhiệm vụ, dữ liệu, schema và quyền. Nếu chưa chứng minh tương thích, trả trạng thái chưa hoàn tất hoặc chuyển người an toàn hơn failover mù.
Fallback rule-based có thể dùng khi nào?
Khi tình huống có quy tắc xác định, đầu ra nằm trong phạm vi hẹp và logic được kiểm thử. Nếu thông tin phụ thuộc dữ liệu cập nhật hoặc có nhiều điều kiện, rule tĩnh có thể trả lời cũ/sai; cần thể hiện giới hạn.
Có thể dùng cached answer khi model lỗi?
Chỉ nếu câu trả lời còn hạn, cùng quyền/ngữ cảnh và nguồn chưa thay đổi. Với thông tin cá nhân, thời gian thực hoặc có tác động cao, tái sử dụng cache có thể gây rủi ro; nên bỏ cache hoặc chuyển xử lý.
Người dùng nên thấy gì khi fallback xảy ra?
Thông báo trung thực về bước chưa hoàn thành, request ID nếu hữu ích và việc cần làm như thử lại sau, bổ sung dữ liệu hoặc liên hệ người hỗ trợ. Không cho biết “đã xử lý” khi app chỉ tạo bản nháp hoặc chưa xác minh kết quả.
Kiểm thử fallback bằng cách nào?
Dùng fault injection/mock theo từng loại lỗi, xác nhận retry count, timeout, output frontend, log và không có side effect lặp. Test failover riêng về quyền, schema, chất lượng và đường quay lại model chính.
Bình luận (0
)