Phân biệt thử lại và chuyển đổi dự phòng
Thử lại gửi yêu cầu qua cùng một tuyến một lần nữa vì lỗi có thể chỉ mang tính tạm thời. Chuyển đổi dự phòng thay đổi nhà cung cấp hoặc mô hình vì tuyến ban đầu không khả dụng hoặc không phù hợp.
Việc xem cả hai hành động này như một vòng lặp thử lại chung khiến sự cố khó chẩn đoán hơn và có thể làm chi phí tăng nhiều lần mà không cải thiện tỷ lệ thành công.
- Thử lại: hết thời gian chờ, kết nối bị đặt lại, phản hồi 429 hoặc phản hồi 5xx tạm thời.
- Chuyển đổi dự phòng: nhà cung cấp liên tục gặp lỗi, vấn đề về năng lực mô hình hoặc hạn chế chính sách.
- Dừng: yêu cầu không hợp lệ, tham số không được hỗ trợ hoặc xác thực đầu ra thất bại.
Xây dựng bảng định tuyến tương thích về khả năng
Các mô hình dự phòng nên được nhóm theo khả năng thay vì thương hiệu. Một yêu cầu xử lý hình ảnh không thể chuyển sang mô hình chỉ xử lý văn bản, và một quy trình yêu cầu JSON nghiêm ngặt không nên định tuyến đến một mô hình thường xuyên vi phạm schema.
- Các phương thức đầu vào và đầu ra bắt buộc.
- Độ dài ngữ cảnh và đầu ra tối thiểu.
- Khả năng gọi công cụ và hỗ trợ đầu ra có cấu trúc.
- Mức giá và độ trễ tối đa có thể chấp nhận.
Áp dụng một ngân sách cấp yêu cầu
Ngân sách của yêu cầu phải bao gồm mọi lần thử lại và chuyển đổi dự phòng. Trước khi bắt đầu một lần thử khác, hãy kiểm tra xem ngân sách độ trễ và chi phí còn lại có đủ để thực hiện hay không.
const routePolicy = {
maxAttempts: 3,
maxLatencyMs: 18_000,
maxEstimatedCost: 0.12,
retryOn: [408, 429, 500, 502, 503, 504],
fallbackModels: ['primary-model', 'quality-fallback', 'fast-fallback'],
};Đo lường chất lượng dự phòng, không chỉ khả dụng
Một yêu cầu trả về thành công vẫn có thể là một thất bại của sản phẩm. Hãy theo dõi việc xác thực đầu ra, tỷ lệ người dùng phải chỉnh sửa và mức độ hoàn thành tác vụ sau một sự kiện chuyển đổi dự phòng.
Bảng điều khiển đề xuất: tỷ lệ thành công theo tuyến, tỷ lệ chuyển đổi dự phòng, độ trễ p95, chi phí ước tính, tỷ lệ vượt qua xác thực và điểm chất lượng theo mô hình.