Chiến lược dự phòng mô hình: Sổ tay 3 quy trình

Fallback của mô hình không chỉ là một hành vi. Nó là một tập hợp các quyết định khôi phục với những giới hạn an toàn khác nhau.

Một chiến lược dự phòng mô hình trong môi trường production nên tách thành ba quy trình:

1. Thử lại hoặc chuyển sang phương án dự phòng tương đương khi yêu cầu vẫn an toàn để gửi lại.
2. Dự phòng giữa các mô hình khi một mô hình khác có thể đáp ứng cùng năng lực và cam kết chất lượng.
3. Dừng, đối soát hoặc chuyển cấp khi đầu ra đã đến tay người dùng hoặc có thể đã xảy ra tác dụng phụ từ công cụ.

Sự tách biệt này quan trọng vì hành động khôi phục nhanh nhất không phải lúc nào cũng là an toàn nhất. Gửi lại một yêu cầu phân loại bị lỗi thường có rủi ro thấp. Nhưng âm thầm chuyển mô hình giữa chừng trong một câu trả lời dạng stream hoặc sau một lệnh gọi công cụ thanh toán không chắc chắn thì không.

Sổ tay này biến chính sách dự phòng thành ba quy trình vận hành mà đội ngũ của bạn có thể triển khai, kiểm thử và quan sát.

Quyết định dự phòng mô hình trong một bảng

Bắt đầu từ trạng thái của yêu cầu, không phải tên nhà cung cấp.

Quy tắc cốt lõi rất đơn giản: thử lại bảo toàn mục tiêu, chuyển sang phương án dự phòng tương đương bảo toàn hợp đồng mô hình, và dự phòng giữa các mô hình làm thay đổi rủi ro của hợp đồng. Mỗi bước cần một kiểm tra đủ điều kiện chặt chẽ hơn.

Để tìm hiểu sâu hơn về circuit breaker, chuẩn hóa lỗi và một bộ điều khiển trung lập với nhà cung cấp, xem sổ tay định tuyến dự phòng cho LLM API.

Trước các quy trình: xác định một fallback envelope

Mỗi yêu cầu nên đi vào lớp định tuyến với một envelope có giới hạn. Envelope này cho hệ thống biết có thể cho phép bao nhiêu khả năng khôi phục trước khi yêu cầu phải dừng lại.

type FallbackEnvelope = {
  requestId: string;
  deadlineMs: number;
  maxAttempts: number;
  maxAddedLatencyMs: number;
  maxCostUsd?: number;
  allowEquivalentFailover: boolean;
  allowCrossModelFallback: boolean;
  allowAfterPartialOutput: false;
  sideEffectMode: "none" | "read_only" | "write_possible";
  requiredCapabilities: string[];
  requiredSchemaVersion?: string;
};

Các giá trị này nên đến từ quy trình làm việc của sản phẩm, không phải từ một mặc định toàn cục. Một tác vụ tóm tắt chạy nền có thể chấp nhận độ trễ cao hơn so với một trợ lý lập trình tương tác. Một câu trả lời chat không dùng công cụ có thể chấp nhận hành vi khôi phục khác với một tác nhân có thể triển khai mã hoặc gửi email.

Envelope này cũng ngăn các lần thử lại lồng nhau. Nếu SDK, ứng dụng, gateway và bộ chuyển đổi nhà cung cấp đều tự động thử lại độc lập, một sự cố nhỏ có thể nhân lên thành một đợt bùng phát số lần thử lớn. Hãy chọn một lớp chịu trách nhiệm cho tổng ngân sách số lần thử và yêu cầu mọi lớp bên dưới báo cáo phần đã tiêu tốn.

Quy trình 1: thử lại, rồi dự phòng tương đương

Sử dụng quy trình này khi thao tác có thể phát lại và hệ thống chưa xuất ra đầu ra một phần hoặc chưa đi vào trạng thái side effect không chắc chắn.

Một đích đến tương đương là một tuyến khác vẫn giữ nguyên hợp đồng quan trọng: cùng nhóm hành vi mô hình, các năng lực bắt buộc, kỳ vọng về schema, cấu hình an toàn và các giới hạn ngữ cảnh tương thích. Nó có thể là một vùng, triển khai, endpoint nhà cung cấp hoặc nhóm năng lực khác.

Bước 1: chuẩn hóa lỗi

Ánh xạ các phản hồi đặc thù của nhà cung cấp vào một phân loại nội bộ nhỏ:

• transport_transient
• rate_limited
• provider_overloaded
• provider_server_error
• authentication_or_permission
• invalid_request
• deadline_exhausted
• contract_failure
• partial_output
• side_effect_uncertain

Thông thường chỉ bốn loại đầu tiên đủ điều kiện để tự động phát lại. Lỗi xác thực, quyền truy cập và yêu cầu không hợp lệ nên dừng lại vì một endpoint khác khó có thể sửa được yêu cầu. Các lỗi về hợp đồng thuộc Quy trình 2. Đầu ra một phần và side effect không chắc chắn thuộc Quy trình 3.

Bước 2: tính toán ngân sách còn lại

Trước mỗi lần thử, hãy kiểm tra:

remaining time > estimated next-attempt latency + response safety margin
remaining attempts > 0
remaining added latency > 0
remaining cost budget > estimated attempt cost, when a cost ceiling exists

Nếu bất kỳ ngân sách bắt buộc nào đã cạn, hãy thoát thay vì thử thêm một nhà cung cấp nữa.

Bước 3: thử lại với backoff và jitter

Sử dụng hướng dẫn retry của nhà cung cấp khi có sẵn. Nếu không, áp dụng exponential backoff với jitter và giữ độ trễ nằm trong deadline của yêu cầu.

function retryDelayMs(attempt: number, retryAfterMs?: number): number {
  if (retryAfterMs !== undefined) return retryAfterMs;

  const base = Math.min(250 * 2 ** attempt, 4_000);
  const jitter = Math.random() * base * 0.3;
  return Math.round(base + jitter);
}

Jitter quan trọng vì nếu không, nhiều khách hàng đồng thời có thể thử lại theo cùng một lịch và kéo dài một sự cố quá tải. Hướng dẫn giới hạn tốc độ LLM của bạn nên xác định cách RPM, TPM, hàng đợi, mức đồng thời và ngân sách thử lại tương tác với nhau.

Bước 4: chuyển sang năng lực tương đương

Nếu cùng đích đó vẫn không khỏe, hãy định tuyến sang một endpoint tương đương chỉ sau khi kiểm tra:

• Circuit đang đóng hoặc ở trạng thái half-open để thăm dò.
• Đích hỗ trợ các chế độ input và output bắt buộc.
• Đích có thể chấp nhận yêu cầu trong giới hạn context của nó.
• Đích sử dụng cấu hình an toàn và xử lý dữ liệu như mong đợi.
• Lần thử này vẫn nằm trong hạn chót và khung chi phí.

Chuyển đổi dự phòng tương đương thường ít rủi ro hơn so với việc đổi mô hình vì nó nhằm giữ nguyên hợp đồng phản hồi.

Bước 5: ghi lại lý do khôi phục

Trả về một kết quả định tuyến như:

{
  "workflow": "retry_equivalent_failover",
  "primary_attempts": 2,
  "equivalent_failover_attempts": 1,
  "recovered": true,
  "recovery_reason": "provider_overloaded",
  "added_latency_ms": 684
}

Không tiết lộ chi tiết nội bộ của nhà cung cấp cho người dùng cuối trừ khi sản phẩm của bạn cam kết mức minh bạch đó. Tuy nhiên, hãy giữ chúng trong trace và log vận hành.

Quy trình 2: dự phòng chéo mô hình có kiểm soát

Dự phòng chéo mô hình chỉ phù hợp khi mô hình thay thế đã được phê duyệt trước cho tác vụ đó. Một mô hình chỉ trả về văn bản là chưa đủ; nó phải đáp ứng hợp đồng của quy trình.

Bước 1: tạo một hợp đồng năng lực

Xác định các yêu cầu không thể thỏa hiệp cho từng lớp tuyến.

{
  "route_class": "support_ticket_triage_v3",
  "required": {
    "input": ["text"],
    "output": ["json_schema"],
    "tools": [],
    "minimum_context_tokens": 24000,
    "schema": "triage-result-v3",
    "languages": ["en", "es", "de"],
    "safety_profile": "customer-support-standard"
  },
  "fallback_models": [
    "approved-model-b",
    "approved-model-c"
  ]
}

Đối với các tuyến có dùng công cụ, hãy bao gồm hành vi chọn công cụ, hỗ trợ công cụ song song, xử lý schema đối số, và việc mô hình có tuân thủ đáng tin cậy các điều kiện “không gọi” hay không. Với đầu ra có cấu trúc, hãy xác thực phản hồi thực tế theo schema sau mỗi lần thử.

Bước 2: tách biệt thành công vận chuyển với thành công tác vụ

Một phản hồi HTTP thành công vẫn có thể làm thất bại quy trình sản phẩm. Hãy đánh giá ít nhất ba lớp:

1. Thành công vận chuyển: nhà cung cấp đã trả về một phản hồi đầy đủ.
2. Thành công hợp đồng: phản hồi được phân tích, khớp schema và dùng đúng các công cụ được hỗ trợ.
3. Thành công tác vụ: đầu ra thực sự hoàn thành công việc của người dùng ở mức chất lượng chấp nhận được.

Sự phân biệt này là thiết yếu khi so sánh các ứng viên dự phòng. Một mô hình có tỷ lệ phản hồi cao nhưng thường xuyên lỗi schema hoặc lỗi công cụ thì không phải là một phương án dự phòng đáng tin cậy.

Bước 3: xếp hạng các ứng viên đã phê duyệt theo chính sách

Một bộ định tuyến trong môi trường production có thể chấm điểm các mục tiêu đủ điều kiện bằng các tín hiệu vận hành mà không giả định rằng một mô hình nào đó là tốt nhất trong mọi trường hợp.

type Candidate = {
  id: string;
  capabilitiesPass: boolean;
  circuitOpen: boolean;
  estimatedLatencyMs: number;
  estimatedCostUsd: number;
  recentContractSuccess: number;
  recentTaskSuccess: number;
};

function eligible(candidate: Candidate, envelope: FallbackEnvelope): boolean {
  return (
    candidate.capabilitiesPass &&
    !candidate.circuitOpen &&
    candidate.estimatedLatencyMs <= envelope.maxAddedLatencyMs &&
    (envelope.maxCostUsd === undefined ||
      candidate.estimatedCostUsd <= envelope.maxCostUsd)
  );
}

Tránh một danh sách tĩnh “chính, dự phòng, dự phòng” cho mọi tác vụ. Bộ dự phòng tốt nhất cho tạo mã có thể khác với bộ tốt nhất cho trích xuất, dịch thuật, thị giác hoặc thực thi công cụ.

Step 4: xác thực đầu ra dự phòng

Trước tiên, áp dụng các kiểm tra xác định:

• Xác thực JSON hoặc schema
• Kiểm tra các trường bắt buộc
• Xác thực đối số công cụ
• Kiểm tra định dạng trích dẫn hoặc URL
• Giới hạn độ dài và ngôn ngữ
• Các mẫu đầu ra bị cấm

Sau đó thêm các kiểm tra chất lượng theo từng quy trình làm việc. Các kiểm tra này có thể là các quy tắc nhẹ, một bộ đánh giá tác vụ, rà soát ngẫu nhiên bởi con người, hoặc một mô hình phán xét đã được xác thực. Nếu cổng chất lượng thất bại, đừng gắn nhãn fallback là đã phục hồi.

Step 5: thay đổi chính sách bằng canary

Trước khi mở rộng một mô hình dự phòng mới:

1. Phát lại một bộ đánh giá ngoại tuyến.
2. Chạy lưu lượng shadow khi chính sách cho phép.
3. Bật ứng viên cho một tỷ lệ nhỏ các lỗi đủ điều kiện.
4. So sánh thành công hợp đồng, thành công tác vụ, độ trễ và chi phí.
5. Chỉ mở rộng nếu giá trị phục hồi lớn hơn rủi ro thoái lui.

Theo dõi các phép đo này bằng một lược đồ giám sát khả năng quan sát API LLM ghi lại một route và một span cho mỗi lần thử.

Workflow 3: dừng, đối soát hoặc leo thang

Một số lỗi không nên kích hoạt thêm một lần gọi mô hình nữa. Fallback đúng là một trạng thái dừng có kiểm soát.

Trường hợp 1: đầu ra streaming một phần

Khi token phản hồi đã đến tay người dùng, việc âm thầm chuyển sang mô hình khác có thể tạo ra mâu thuẫn, nội dung trùng lặp, các khối mã bị hỏng, hoặc thay đổi phong cách đột ngột. Nó cũng khiến phản hồi cuối cùng khó quy trách nhiệm và gỡ lỗi.

Thay vào đó, hãy dùng một trong các kết quả rõ ràng sau:

• Kết thúc luồng bằng một lỗi có thể khôi phục và một hành động “thử lại”.
• Đề nghị khởi động lại câu trả lời từ đầu.
• Chỉ tiếp tục nếu ứng dụng có một giao thức tiếp tục được thiết kế sẵn và mô hình mới nhận đúng tiền tố đã được chấp nhận.

Mặc định nên là allowAfterPartialOutput: false.

Trường hợp 2: các tác động phụ của công cụ không chắc chắn

Giả sử một mô hình đã chọn công cụ thanh toán, email, triển khai, ticket, hoặc ghi vào cơ sở dữ liệu. Công cụ có thể đã thành công ngay cả khi kết nối thất bại trước khi bộ điều phối của bạn ghi nhận kết quả. Phát lại toàn bộ quy trình có thể nhân đôi tác động phụ.

Bảo vệ các công cụ ghi dữ liệu với:

• Một khóa idempotency dựa trên thao tác của người dùng, không phải trên lần thử của nhà cung cấp.
• Một bản ghi thực thi bền vững với các trạng thái planned, started, succeeded, failed và unknown.
• Khử trùng lặp tại ranh giới công cụ.
• Một truy vấn đối soát trước bất kỳ lần phát lại nào.
• Rà soát của con người đối với các hành động có tác động lớn nhưng vẫn còn không chắc chắn.

type ToolExecution = {
  operationId: string;
  toolName: string;
  state: "planned" | "started" | "succeeded" | "failed" | "unknown";
  externalReference?: string;
};

function nextAction(execution: ToolExecution): "continue" | "reconcile" | "stop" {
  if (execution.state === "succeeded") return "continue";
  if (execution.state === "failed") return "stop";
  return "reconcile";
}

Giữ riêng thông tin xác thực của nhà cung cấp và thông tin xác thực của công cụ. Hướng dẫn quản lý khóa API an toàn bao quát mô hình bí mật và kiểm soát truy cập xung quanh.

Trường hợp 3: không chắc chắn về an toàn, quyền hạn hoặc chính sách

Tính sẵn sàng không nên làm suy yếu quyết định về an toàn hoặc ủy quyền. Nếu ứng viên dự phòng không hỗ trợ các kiểm soát chính sách bắt buộc, tuyến đó là không đủ điều kiện. Nếu hệ thống không thể xác định một thao tác có được phép hay không, hãy đóng theo mặc định hoặc chuyển cấp theo mô hình rủi ro của sản phẩm.

Trường hợp 4: không có ứng viên nào đáp ứng hợp đồng

Trả về một lỗi có kiểu mà ứng dụng có thể xử lý:

{
  "status": "unavailable",
  "reason": "no_eligible_fallback",
  "retryable": true,
  "retry_after_ms": 30000,
  "request_id": "req_123"
}

Một phản hồi suy giảm rõ ràng tốt hơn một câu trả lời có vẻ thành công nhưng vi phạm lược đồ, dùng sai công cụ, hoặc thực hiện sai tác động phụ.

Đưa ba quy trình vào một máy trạng thái

Lớp điều phối nên làm cho sự chuyển trạng thái trở nên tường minh.

START
  -> PRIMARY_ATTEMPT
     -> SUCCESS: validate and return
     -> TRANSIENT + replayable: WORKFLOW_1
     -> CONTRACT_FAILURE + approved alternate: WORKFLOW_2
     -> PARTIAL_OUTPUT or SIDE_EFFECT_UNCERTAIN: WORKFLOW_3

WORKFLOW_1
  -> retry inside budget
  -> equivalent failover inside budget
  -> if compatible alternate allowed: WORKFLOW_2
  -> otherwise: STOP

WORKFLOW_2
  -> capability check
  -> alternate attempt
  -> contract and task validation
  -> return only on validated success
  -> otherwise: STOP

WORKFLOW_3
  -> mark partial or uncertain state
  -> reconcile external side effects when possible
  -> offer explicit restart or human escalation
  -> never silently replay unsafe work

Đây cũng là ranh giới phù hợp cho một cổng đa mô hình. Việc tập trung hóa quyền truy cập mô hình phía sau một endpoint tương thích OpenAI có thể giảm trùng lặp tích hợp, nhưng ứng dụng vẫn cần cung cấp ý định quy trình làm việc: thời hạn, chế độ tác vụ phụ, các công cụ bắt buộc, phiên bản lược đồ, và việc có cho phép dự phòng xuyên mô hình hay không. Flatkey cung cấp một lớp truy cập API hợp nhất cho các đội muốn có một khóa và một bề mặt tích hợp duy nhất trên nhiều nhà cung cấp mô hình; chính sách định tuyến an toàn nhất vẫn bắt đầu bằng các hợp đồng ứng dụng rõ ràng.

Danh sách kiểm tra triển khai chiến lược dự phòng mô hình

Chính sách

• [ ] Mỗi lớp tuyến đều có một vùng chứa dự phòng.
• [ ] Các lỗi có thể thử lại được chuẩn hóa xuyên suốt các nhà cung cấp.
• [ ] Tổng ngân sách retry có một người chịu trách nhiệm duy nhất.
• [ ] Các endpoint tương đương được phân biệt với các mô hình thay thế.
• [ ] Các ứng viên dự phòng xuyên mô hình có hợp đồng năng lực được phiên bản hóa.
• [ ] Đầu ra một phần mặc định tắt dự phòng minh bạch.
• [ ] Các công cụ phía ghi sử dụng bản ghi idempotency bền vững.

Xác thực

• [ ] Thành công về truyền tải, hợp đồng và tác vụ được đo riêng biệt.
• [ ] Đầu ra có cấu trúc được xác thực sau khi dự phòng.
• [ ] Đối số công cụ và hành vi chọn công cụ được kiểm thử theo từng mô hình.
• [ ] Các bộ đánh giá dự phòng đại diện cho các lớp tuyến thực tế.
• [ ] Ứng viên mới phải vượt qua đánh giá ngoại tuyến và một canary trên môi trường production.

Vận hành

• [ ] Mỗi lần thử ghi lại lý do tuyến, đích, độ trễ và kết quả.
• [ ] Dashboard hiển thị riêng primary, retry, equivalent failover, và cross-model recovery.
• [ ] Cảnh báo bao gồm cạn thời hạn và tỷ lệ không có dự phòng đủ điều kiện.
• [ ] Circuit breaker sử dụng các probe half-open có kiểm soát.
• [ ] Rà soát sự cố bao gồm chất lượng có thể nhìn thấy bởi người dùng và rủi ro tác vụ phụ trùng lặp.

Các chỉ số chứng minh dự phòng đang hữu ích

Đừng chỉ tối ưu theo tỷ lệ lỗi của nhà cung cấp. Hãy theo dõi kết quả của người dùng.

Hãy phân đoạn các chỉ số này theo lớp tuyến. Một tỷ lệ khôi phục tổng hợp có thể che giấu việc dự phòng hoạt động tốt cho extraction nhưng kém cho code generation hoặc sử dụng công cụ.

Câu hỏi thường gặp

Chiến lược dự phòng mô hình là gì?

Chiến lược dự phòng mô hình là một chính sách để quyết định khi nào một yêu cầu AI nên thử lại cùng đích đến, chuyển sang năng lực tương đương khi failover, chuyển sang một mô hình thay thế đã được phê duyệt, hoặc dừng lại vì việc phát lại có thể không an toàn.

Sự khác biệt giữa retry và fallback là gì?

Retry sẽ lặp lại yêu cầu đối với cùng một đích đến hoặc cùng một triển khai. Failover tương đương sẽ chuyển yêu cầu sang năng lực được thiết kế để bảo toàn cùng một hợp đồng mô hình. Fallback xuyên mô hình thay đổi mô hình và vì vậy cần xác thực về năng lực và chất lượng.

Có phải mọi lỗi 429 đều nên kích hoạt một mô hình khác?

Không. Trước tiên hãy phân loại giới hạn, tuân thủ hướng dẫn retry, kiểm tra thời hạn còn lại, và sử dụng retry có giới hạn hoặc hàng đợi. Việc chuyển mô hình có thể hữu ích khi có năng lực thay thế đã được phê duyệt, nhưng nó cũng có thể làm thay đổi chất lượng đầu ra, hành vi công cụ, hoặc chi phí.

Phản hồi dạng streamed có thể fallback giữa chừng không?

Thông thường sẽ an toàn hơn nếu không chuyển một cách minh bạch sau khi token đã đến tay người dùng. Hãy dừng luồng và đề xuất khởi động lại rõ ràng, trừ khi ứng dụng có giao thức tiếp tục đã được kiểm thử.

Nên có bao nhiêu mô hình fallback cho một route?

Hãy dùng tập hợp nhỏ nhất đã được phê duyệt nhưng vẫn cung cấp khả năng phục hồi có ý nghĩa. Mỗi ứng viên thêm vào sẽ kéo theo công việc đánh giá, giám sát, và ứng phó sự cố. Một danh sách dài chưa được kiểm thử không phải là khả năng chống chịu.

Logic fallback nên đặt ở đâu?

Hãy tập trung hóa việc chuẩn hóa nhà cung cấp, định tuyến, ngân sách số lần thử, và khả năng quan sát trong một gateway hoặc lớp điều phối. Giữ ý định đặc thù của workflow—rủi ro tác động phụ, yêu cầu schema, chính sách an toàn, và ngưỡng chất lượng—gần với ứng dụng.

Xây dựng fallback dựa trên rủi ro của workflow

Chiến lược dự phòng mô hình tốt nhất không phải là “thử mô hình tiếp theo.” Nó là một hệ thống quyết định có giới hạn:

• Workflow 1 phục hồi các yêu cầu có thể phát lại bằng retry và năng lực tương đương.
• Workflow 2 chỉ chuyển mô hình sau khi kiểm tra năng lực và chất lượng.
• Workflow 3 dừng phát lại tự động khi đầu ra hoặc tác động phụ khiến việc phục hồi không an toàn.

Thiết kế đó cải thiện tính sẵn sàng mà không che giấu lỗi hợp đồng hay nhân đôi hành động của người dùng. Nếu nhóm của bạn đang chuẩn hóa quyền truy cập trên các nhà cung cấp mô hình, hãy dùng lớp API thống nhất tương thích OpenAI của Flatkey làm bề mặt tích hợp, rồi gắn các lớp bao bọc đặc thù cho từng workflow này vào mọi route production.

Nguồn và tài liệu đọc thêm

• Mã lỗi API của OpenAI
• Structured Outputs của OpenAI
• Lỗi API của Anthropic
• Streaming messages của Anthropic
• Mẫu retry với backoff của AWS
• Mẫu circuit breaker của AWS
• Chiến lược retry của Google Cloud