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

Fallback mô hình không phải là một hành vi duy nhất. 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.

Trong môi trường sản xuất, chiến lược dự phòng mô hình nên tách thành ba quy trình:

1. Thử lại hoặc chuyển giao tương đương khi lỗi khi yêu cầu vẫn an toàn để phát lại.
2. Dự phòng chéo 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 leo thang 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 đó 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. Phát 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 việc âm thầm chuyển mô hình giữa chừng trong một câu trả lời đang được 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 phải vậy.

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ử, giám sát và phát hành qua một đợt rollout sản xuất có kiểm soá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 giữ nguyên đích, chuyển giao tương đương giữ nguyên hợp đồng mô hình, và dự phòng chéo 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à bộ điều khiển trung lập với nhà cung cấp, xem sổ tay định tuyến dự phòng API LLM.

Trước các quy trình: xác định một bao dự phòng duy nhất

Mỗi yêu cầu nên đi vào lớp định tuyến với một bao được giới hạn. Bao này cho hệ thống biết mức khôi phục nào được phép 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ừ luồng công việc của sản phẩm, chứ không phải từ một giá trị mặc định toàn cục. Một công việc tóm tắt nền có thể chịu được độ trễ cao hơn 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ịu được 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 chặn các lần thử lại lồng nhau. Nếu SDK, ứng dụng, cổng vào và bộ chuyển tiếp của nhà cung cấp đều tự retry độc lập, một sự cố nhỏ có thể nhân lên thành một đợt bùng nổ số lần thử lớn. Hãy chọn một lớp chịu trách nhiệm cho toàn bộ ngân sách số lần thử và yêu cầu mọi lớp thấp hơn báo cáo số lần đã tiêu tốn.

Biến envelope dự phòng thành chính sách dưới dạng mã

Một định nghĩa kiểu tài liệu hóa ý định, nhưng định tuyến trong môi trường sản xuất cần một chính sách có phiên bản để người vận hành có thể xem xét mà không cần thay đổi mã ứng dụng. Hãy giữ chính sách đủ nhỏ để kiểm tra và đủ cụ thể để ngăn một chuỗi dự phòng chung lọt vào các luồng công việc rủi ro cao.

Cấu hình khởi đầu này tách ba lớp tuyến phổ biến:

policy_version: 2026-08-02

routes:
  interactive_chat:
    deadline_ms: 12000
    max_attempts: 2
    max_added_latency_ms: 2500
    allow_equivalent_failover: true
    allow_cross_model_fallback: true
    allow_after_partial_output: false
    side_effect_mode: none
    required_capabilities: [streaming]

  structured_extraction:
    deadline_ms: 30000
    max_attempts: 3
    max_added_latency_ms: 8000
    allow_equivalent_failover: true
    allow_cross_model_fallback: true
    allow_after_partial_output: false
    side_effect_mode: none
    required_capabilities: [structured_output]
    required_schema_version: invoice-v4

  tool_agent_write:
    deadline_ms: 45000
    max_attempts: 2
    max_added_latency_ms: 5000
    allow_equivalent_failover: true
    allow_cross_model_fallback: false
    allow_after_partial_output: false
    side_effect_mode: write_possible
    required_capabilities: [tool_use]

Các giá trị ở trên là ví dụ, không phải ngưỡng phổ quát. Hãy thiết lập chúng dựa trên mục tiêu độ trễ hướng tới người dùng, kinh tế của tác vụ, kết quả đánh giá và rủi ro tác dụng phụ. Điểm thiết kế quan trọng là tác nhân có khả năng ghi không thể âm thầm chuyển sang một mô hình có hành vi khác.

Trong thời gian chạy, bộ định tuyến nên kết hợp chính sách với trạng thái yêu cầu và trạng thái lỗi đã quan sát. Một hàm quyết định gọn có thể làm cho ranh giới này có thể kiểm thử:

type RecoveryAction =
  | "retry_same_target"
  | "failover_equivalent"
  | "fallback_approved_model"
  | "reconcile_side_effect"
  | "restart_required"
  | "stop";

function chooseRecovery(input: {
  errorClass: string;
  attemptsUsed: number;
  deadlineRemainingMs: number;
  partialOutput: boolean;
  sideEffectState: "none" | "safe" | "uncertain";
  equivalentAvailable: boolean;
  approvedAlternateAvailable: boolean;
  policy: FallbackEnvelope;
}): RecoveryAction {
  if (input.sideEffectState === "uncertain") return "reconcile_side_effect";
  if (input.partialOutput) return "restart_required";
  if (input.attemptsUsed >= input.policy.maxAttempts) return "stop";
  if (input.deadlineRemainingMs <= 0) return "stop";

  const transient = [
    "transport_transient",
    "rate_limited",
    "provider_overloaded",
    "provider_server_error",
  ].includes(input.errorClass);

  if (transient && input.attemptsUsed === 0) return "retry_same_target";
  if (transient && input.equivalentAvailable) return "failover_equivalent";

  if (
    input.policy.allowCrossModelFallback &&
    input.approvedAlternateAvailable
  ) {
    return "fallback_approved_model";
  }

  return "stop";
}

Giữ việc chọn ứng viên tách biệt với quyết định khôi phục. chooseRecovery quyết định quy trình nào được phép; bộ chọn ứng viên sau đó lọc các mục tiêu theo năng lực, ngữ cảnh, khu vực, chi phí và chính sách chất lượng. Sự tách biệt này giúp việc xem xét sự cố dễ dàng hơn vì đội ngũ có thể phân biệt giữa “chúng ta đã chọn sai quy trình khôi phục” và “chúng ta đã chọn sai mô hình thay thế”.

Phiên bản hóa chính sách và gắn phiên bản đó vào mọi bản ghi thử lại. Khi xuất hiện hồi quy ở cơ chế fallback, người vận hành nên có thể trả lời chính sách nào đã đưa ra quyết định, những ứng viên nào đủ điều kiện và ngân sách nào còn lại tại thời điểm đó.

Quy trình 1: thử lại, rồi chuyển sang failover 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 lộ đầu ra một phần hoặc chưa đi vào trạng thái tác động phụ không chắc chắn.

Một mục tiêu tương đương là một tuyến khác vẫn giữ được hợp đồng quan trọng: cùng lớp hành vi mô hình, các năng lực bắt buộc, kỳ vọng lược đồ, cấu hình an toàn và giới hạn ngữ cảnh tương thích. Nó có thể là một khu vực, triển khai, điểm cuối nhà cung cấp hoặc nhóm công suất 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 thành 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 và yêu cầu không hợp lệ nên dừng lại vì một điểm cuối khác khó có thể sửa yêu cầu. Các lỗi hợp đồng thuộc về Quy trình 2. Đầu ra một phần và tác động phụ không chắc chắn thuộc về 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:

thời gian còn lại > độ trễ ước tính của lần thử tiếp theo + biên an toàn phản hồi
số lần thử còn lại > 0
độ trễ cộng thêm còn lại > 0
ngân sách chi phí còn lại > chi phí ước tính của lần thử, khi có giới hạn chi phí

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 thử lại của nhà cung cấp khi có sẵn. Nếu không, hãy áp dụng backoff hàm mũ với jitter và giữ độ trễ trong thời hạn 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 rất 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ự kiện quá tải. Hướng dẫn về giới hạn tốc độ LLM của bạn nên xác định cách RPM, TPM, hàng đợi, tính đồ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 mục tiêu vẫn không ổn định, hãy chuyển hướng sang một điểm cuối tương đương chỉ sau khi kiểm tra:

• Mạch đang đóng hoặc bán mở để thăm dò.
• Mục tiêu hỗ trợ các chế độ đầu vào và đầu ra cần thiết.
• Mục tiêu có thể nhận yêu cầu trong giới hạn ngữ cảnh của nó.
• Mục tiêu sử dụng cấu hình an toàn và xử lý dữ liệu như mong đợi.
• Lần thử vẫn phù hợp với thời hạn và ngân sách chi phí.

Chuyển đổi dự phòng tương đương thường ít rủi ro hơn thay đổ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 phục hồi

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 hiển thị 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 sự minh bạch đó. Tuy nhiên, hãy giữ chúng trong các trace và nhật ký 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 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 hợp đồng năng lực

Xác định các yêu cầu không thể thiếu 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ý lược đồ đố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ế so với lược đồ sau mỗi lần thử.

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

Một phản hồi thành công về HTTP vẫn có thể khiến quy trình sản phẩm thất bại. 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 với lược đồ và sử dụng đúng các công cụ được hỗ trợ.
3. Thành công của 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 lược đồ hoặc lỗi công cụ thì không phải là phương án dự phòng đáng tin cậy.

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

Một bộ định tuyến 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 cần giả vờ rằng một mô hình nào đó là tốt nhất một cách सार्व quát.

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 sinh 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ụ.

Bước 4: xác thực đầu ra dự phòng

Áp dụng trước các kiểm tra xác định:

• Xác thực JSON hoặc lược đồ
• 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
• Ràng buộc về độ 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. Chúng 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 giám định đã đượ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.

Bước 5: thay đổi chính sách theo 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 bóng nơi 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 suy giảm.

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

Quy trình 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. Phương án dự phòng đúng là dừng có kiểm soát.

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

Ngay khi các token phản hồi đã đến với 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 làm cho 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 quy trình tiếp tục đã được thiết kế và mô hình mới nhận được đúng tiền tố đã được chấp nhận.

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

Case 2: uncertain tool side effects

Giả sử một mô hình đã chọn một công cụ thanh toán, email, triển khai, ticket hoặc ghi cơ sở dữ liệu. Công cụ đó có thể đã thực thi thành công ngay cả khi kết nối bị lỗ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 dụ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 dựa 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ủa 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 thủ công đối với các hành động có tác động lớn mà vẫn chưa 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.

Case 3: safety, permission, or policy uncertainty

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 này 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 thất bại đóng hoặc chuyển cấp theo mô hình rủi ro của sản phẩm.

Case 4: no candidate satisfies the contract

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 schema, dùng sai công cụ, hoặc tạo ra tác dụng phụ sai.

Đư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 quá trình chuyển trạng thái trở nên rõ ràng.

START
  -> PRIMARY_ATTEMPT
     -> THÀNH CÔNG: xác thực và trả về
     -> TẠM THỜI + có thể phát lại: WORKFLOW_1
     -> LỖI HỢP ĐỒNG + phương án thay thế đã được phê duyệt: WORKFLOW_2
     -> ĐẦU RA MỘT PHẦN hoặc TÁC ĐỘNG PHỤ KHÔNG CHẮC CHẮN: WORKFLOW_3

WORKFLOW_1
  -> thử lại trong phạm vi ngân sách
  -> chuyển dự phòng tương đương trong phạm vi ngân sách
  -> nếu cho phép phương án thay thế tương thích: WORKFLOW_2
  -> nếu không: DỪNG

WORKFLOW_2
  -> kiểm tra năng lực
  -> thử phương án thay thế
  -> xác thực hợp đồng và tác vụ
  -> chỉ trả về khi thành công đã được xác thực
  -> nếu không: DỪNG

WORKFLOW_3
  -> đánh dấu trạng thái một phần hoặc không chắc chắn
  -> đối soát các tác động phụ bên ngoài khi có thể
  -> đề xuất khởi động lại rõ ràng hoặc chuyển lên người phụ trách
  -> không bao giờ phát lại âm thầm công việc không an toàn

Đây cũng là ranh giới phù hợp cho một cổng đa mô hình. Việc tập trung truy cập mô hình sau một điểm cuối 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: thời hạn, chế độ tác động phụ, 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 nhóm muốn dùng một khóa và một bề mặt tích hợp 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.

Chạy năm bài kiểm tra thất bại trước khi bật dự phòng tự động

Một đường dự phòng chưa từng xử lý lỗi có kiểm soát thì chỉ là một sơ đồ. Hãy kiểm thử từng lớp tuyến đường với các lỗi chạm vào một ranh giới an toàn khác nhau.

Hãy chạy các bài kiểm tra trước tiên trong môi trường cục bộ hoặc staging, rồi trong một ngày diễn tập sản xuất có phạm vi hẹp. Mục đích không phải là chứng minh mọi yêu cầu đều sống sót. Mục đích là chứng minh hệ thống thất bại ở trạng thái dự định, để lộ đủ bằng chứng để chẩn đoán sự kiện, và không tiêu tốn thêm độ trễ, chi phí, hay rủi ro tác động phụ vượt quá chính sách cho phép.

Với mỗi bài kiểm tra, hãy xác minh bốn lớp một cách độc lập:

1. Độ đúng của quyết định: bộ định tuyến đã chọn đúng quy trình dự kiến.
2. Độ đúng ngân sách: mọi lần thử đều nằm trong cùng một ràng buộc về hạn chót, số lần thử và chi phí.
3. Độ đúng đầu ra: kết quả cuối cùng đã vượt qua xác thực hợp đồng và tác vụ, hoặc trả về một trạng thái suy giảm rõ ràng.
4. Độ đúng kiểm toán: các trace ghi lại phiên bản chính sách, loại lỗi, điều kiện đủ của ứng viên, lý do định tuyến và kết quả hiển thị cho người dùng.

Lặp lại bài kiểm tra bất cứ khi nào bạn thay đổi adapter của nhà cung cấp, chủ sở hữu retry, ứng viên mô hình, phiên bản schema, hợp đồng công cụ hoặc triển khai streaming. Những thay đổi đó có thể làm thay đổi độ an toàn khi phát lại ngay cả khi hình dạng API công khai dường như không đổi.

Sử dụng bảng điểm sẵn sàng dự phòng trước khi đưa vào production

Chỉ vượt qua một vài bài kiểm tra đường đi thuận lợi là chưa đủ để bật dự phòng tự động. Một route chỉ nên được tự động hóa sau khi vượt qua năm cổng phát hành độc lập.

Xem bảng điểm như một artifact phát hành. Ghi lại loại route, phiên bản chính sách, các ứng viên đã được phê duyệt, phiên bản evaluator, kết quả kiểm tra, chủ sở hữu và ngày rà soát. Một cờ toàn cục duy nhất “fallback enabled” che giấu quá nhiều rủi ro; việc phê duyệt nên diễn ra theo từng lớp workflow.

Biên bản sẵn sàng có thể sao chép

fallback_readiness:
  route_class: support_ticket_extraction
  policy_version: fallback-v4
  owner: ai-platform
  primary_target: primary-model
  approved_candidates:
    - equivalent-deployment
    - alternate-model

  gates:
    replay_safety: pass
    contract_compatibility: pass
    task_quality: pass
    budget_control: pass
    operational_control: pass

  evidence:
    capability_matrix: contracts/support-ticket-v3.yaml
    evaluation_set: evals/support-ticket-2026-08.jsonl
    failure_drill_run: drills/2026-08-03.json
    dashboard: ai-routing/support-ticket
    runbook: runbooks/support-ticket-fallback.md

  release:
    mode: canary
    rollback_owner: oncall-ai-platform
    next_review_at: 2026-09-03

Tệp này không cần phải tồn tại theo đúng định dạng này. Điều quan trọng là quyết định phát hành có thể được xem xét và được gắn với cùng phiên bản chính sách đã được ghi trong các dấu vết sản xuất.

Triển khai chiến lược dự phòng mô hình qua bốn giai đoạn

Dự phòng tự động không nên nhảy từ một bài kiểm thử ngoại tuyến sang mọi yêu cầu sản xuất. Hãy dùng bốn giai đoạn để làm lộ lỗi quyết định trước khi chúng trở nên nhìn thấy được với người dùng.

Giai đoạn 1: shadow quyết định

Chạy bộ điều khiển dự phòng ở chế độ chỉ quan sát. Đường dẫn chính vẫn quyết định phản hồi của người dùng, trong khi bộ điều khiển ghi lại những gì nó sẽ làm.

Xem xét:

• Tần suất chính sách gắn nhãn một lỗi là có thể thử lại.
• Tần suất một ứng viên đủ điều kiện.
• Ngân sách nào sẽ chặn việc khôi phục.
• Liệu chính sách có đề xuất dự phòng sau đầu ra một phần hoặc các tác dụng phụ không chắc chắn hay không.
• Liệu các lỗi đã chuẩn hóa theo nhà cung cấp có giữ lại đủ chi tiết cho việc chẩn đoán sự cố hay không.

Chế độ shadow đặc biệt hữu ích để phát hiện các quy tắc quá rộng như “dự phòng với mọi 429” hoặc “thử mô hình khác sau bất kỳ lỗi lược đồ nào.” Những quy tắc đó có thể trông hợp lý trong khâu review mã nhưng lại hoạt động tệ trước các trạng thái yêu cầu thực tế.

Giai đoạn 2: canary các quy trình rủi ro thấp

Bật dự phòng cho một phần hẹp của lưu lượng an toàn khi phát lại như phân loại chỉ đọc, trích xuất, hoặc tóm tắt nền. Loại trừ các công cụ phía ghi, các quyết định nhạy cảm về an toàn, và các tuyến có streaming hiển thị với người dùng.

So sánh canary với đường dẫn chỉ dùng mô hình chính bằng các kết quả ở cấp tuyến:

• Tỷ lệ tác vụ được chấp nhận, không chỉ là thành công HTTP.
• Độ trễ bổ sung từ quá trình khôi phục.
• Chênh lệch chi phí trên mỗi tác vụ được chấp nhận.
• Các lỗi xác thực hợp đồng theo từng ứng viên.
• Hết thời hạn và tỷ lệ không có dự phòng đủ điều kiện.
• Tỷ lệ người dùng hủy hoặc khởi động lại rõ ràng.

Đừng mở rộng canary chỉ vì tỷ lệ lỗi của nhà cung cấp đã giảm. Chỉ mở rộng khi kết quả cuối cùng của người dùng vẫn chấp nhận được và đường dẫn khôi phục vẫn nằm trong giới hạn của nó.

Giai đoạn 3: giới hạn khôi phục tự động theo lớp rủi ro

Mở rộng chỉ những lớp quy trình đã vượt qua bảng điểm sẵn sàng. Giữ cho các khác biệt của chính sách được nêu rõ:

Giai đoạn này là nơi cổng trung gian và hợp đồng ứng dụng gặp nhau. Cổng trung gian có thể chuẩn hóa lỗi, thực thi ngân sách và chọn năng lực đủ điều kiện. Ứng dụng vẫn phải nêu rõ đầu ra đã thoát ra ngoài hay chưa, liệu có thể xảy ra tác dụng phụ hay không, và những kiểm tra chất lượng hoặc chính sách nào là bắt buộc.

Giai đoạn 4: mở rộng dần và chứng nhận lại các thay đổi

Tăng lưu lượng theo các bước có giới hạn. Ở mỗi bước, duy trì khả năng vô hiệu hóa một phiên bản chính sách, một lớp tuyến, một bộ điều hợp nhà cung cấp, hoặc một ứng viên mà không phải tắt toàn bộ lớp định tuyến.

Chạy lại các cổng chấm điểm liên quan khi bất kỳ mục nào sau đây thay đổi:

• Mô hình hoặc phiên bản mô hình.
• Bộ điều hợp nhà cung cấp hoặc điểm cuối.
• Mẫu prompt hoặc chỉ dẫn hệ thống.
• Định nghĩa công cụ hoặc phạm vi quyền.
• Lược đồ đầu ra có cấu trúc.
• Quyền sở hữu retry hoặc cấu hình timeout.
• Giao thức streaming hoặc hành vi của client.
• Chính sách an toàn hoặc bộ đánh giá chất lượng.

Trạng thái sẵn sàng fallback sẽ hết hạn khi các giả định của nó thay đổi. Một ứng viên đã được phê duyệt cho prompt, lược đồ, hoặc bộ công cụ trước đó không nên tiếp tục tự động đủ điều kiện chỉ vì quán tính.

Xác định các trình kích hoạt rollback trước khi bật canary

Canary chỉ an toàn khi nhóm thống nhất trước điều gì sẽ dừng nó. Hãy dùng các trình kích hoạt theo tuyến thay vì chờ một sự cố diện rộng.

Rollback hoặc vô hiệu hóa chính sách bị ảnh hưởng khi bạn quan sát thấy:

• Tác dụng phụ ghi trùng lặp hoặc không chắc chắn.
• Thành công ở hợp đồng liên mô hình nhưng không đạt thành công tác vụ chấp nhận được.
• Sự gia tăng các lỗi partial-stream hoặc việc ghép nối phản hồi vô hình.
• Việc vượt quá deadline lặp đi lặp lại do các nỗ lực khôi phục gây ra.
• Ngân sách bị vượt mức hoặc bị bỏ qua.
• Việc chọn ứng viên vi phạm khả năng bắt buộc hoặc chính sách an toàn.
• Sự thay đổi không giải thích được trong phân phối lý do fallback sau khi triển khai.
• Thiếu dữ liệu dấu vết ở cấp phiên bản chính sách hoặc cấp lần thử trong một sự cố.

Hành động rollback phải hẹp đúng bằng phạm vi lỗi. Tùy theo sự kiện, điều đó có thể nghĩa là vô hiệu hóa một ứng viên, buộc một tuyến chỉ dùng chuyển tiếp tương đương, đặt allowCrossModelFallback thành false, mở circuit cho một nhà cung cấp, hoặc đưa quy trình trở lại chế độ chỉ dùng primary.

Tránh một cơ chế rollback đòi hỏi phải dựng lại ứng dụng. Chính sách phục hồi thường thay đổi trong các sự cố, và phản ứng an toàn nhất thường là thay đổi cấu hình với phiên bản có thể kiểm tra/audit thay vì một bản vá mã khẩn cấp.

Sử dụng một phiếu làm việc cho mọi sự kiện dự phòng

Các sự cố dự phòng trở nên khó chẩn đoán khi mỗi nhà cung cấp hiển thị một dạng lỗi khác nhau và mỗi ứng dụng ghi lại một trạng thái yêu cầu khác nhau. Hãy ghi lại một phiếu làm việc trung lập với nhà cung cấp.

fallback_incident:
  incident_id: inc-2026-08-03-001
  route_class: support_ticket_extraction
  request_id: req_123
  policy_version: fallback-v4

  request_state:
    output_started: false
    side_effect_mode: none
    tool_execution_state: not_started
    deadline_remaining_ms: 1820
    attempts_remaining: 1

  primary_failure:
    normalized_class: overloaded
    provider_status: 529
    retry_guidance_present: true

  recovery_decision:
    workflow: cross_model_fallback
    candidate: alternate-model
    reason: equivalent_capacity_unavailable

  validation:
    transport_success: true
    contract_success: true
    task_success: false
    failure_reason: required_field_omitted

  user_outcome:
    state: explicit_failure
    partial_output: false
    duplicate_side_effect: false

  containment:
    action: disable_candidate_for_route
    owner: oncall-ai-platform

Điểm phân biệt quan trọng nhất là giữa phục hồi thành công và người dùng thành công. Một yêu cầu dự phòng có thể trả về một phản hồi HTTP hợp lệ nhưng vẫn thất bại ở schema, chọn sai công cụ, bỏ sót một तथ्य bắt buộc, hoặc vi phạm ngưỡng chất lượng của route. Việc xem xét sự cố nên đi theo kết quả cho đến tác vụ mà người dùng nhìn thấy.

Tổ chức một buổi diễn tập fallback mô hình kéo dài 60 phút

Kiểm thử đơn vị chứng minh rằng từng nhánh riêng lẻ thực thi được. Một buổi diễn tập fallback chứng minh rằng toàn bộ hệ thống phục hồi hoạt động đúng khi thời hạn, các lần thử lại, luồng, xác thực, công cụ, telemetry và các điều khiển của người vận hành tương tác với nhau.

Hãy thực hiện bài diễn tập cho từng lớp quy trình một lần. Đừng bắt đầu bằng mô phỏng sự cố toàn bộ nhà cung cấp. Một route hẹp như trích xuất chỉ-đọc hoặc tóm tắt nội bộ sẽ tạo ra bằng chứng rõ ràng hơn và giới hạn phạm vi ảnh hưởng nếu chính sách sai.

Xác định điều lệ của buổi diễn tập

Viết một điều lệ một trang trước khi bất kỳ ai chèn lỗi vào. Điều lệ ngăn buổi diễn tập biến thành một sự cố ngoài kế hoạch.

game_day:
  id: fallback-gd-2026-08-04-extraction
  route_class: structured_extraction
  policy_version: fallback-v4
  environment: staging
  exercise_owner: ai-platform
  incident_commander: reliability

  primary_target: primary-model
  approved_fallbacks:
    - equivalent-deployment
    - alternate-schema-capable-model

  traffic_scope:
    synthetic_requests: 100
    production_percentage: 0

  safety_limits:
    stop_after_minutes: 60
    max_error_rate_percent: 5
    max_duplicate_side_effects: 0
    max_unexplained_route_decisions: 0

  success_definition:
    - every request ends accepted, explicitly degraded, or safely stopped
    - no request exceeds the shared attempt budget
    - no partial stream is silently continued by another model
    - every fallback decision includes a policy version and route reason

Hãy dùng trước lưu lượng tổng hợp hoặc lưu lượng an toàn để phát lại. Nếu tuyến có thể kích hoạt ghi, hãy thay công cụ bằng một test double có kiểm soát hoặc một sandbox hỗ trợ tra cứu idempotency. Một game day nên kiểm tra các kiểm soát khôi phục, chứ không phải đặt cược vào trạng thái của khách hàng.

Assign four roles

Giữ nhóm đủ nhỏ để ra quyết định nhanh, nhưng tách biệt quan sát khỏi thực thi.

Với một nhóm rất nhỏ, một người có thể đảm nhiệm hai vai trò, nhưng người chèn lỗi không nên là người duy nhất đánh giá liệu hệ thống có phản hồi đúng hay không.

Build a scenario ladder

Bắt đầu với lỗi ít mơ hồ nhất và chỉ tăng rủi ro sau khi tuyến đã vượt qua bậc trước đó.

Đừng bỏ qua trực tiếp sang một kịch bản phức tạp liên mô hình. Nếu failover tương đương không thể bảo toàn ngân sách và hợp đồng trace, việc thêm một mô hình có hành vi khác sẽ khiến chẩn đoán khó hơn, chứ không thực tế hơn.

Inject faults at explicit boundaries

Gắn nhãn chính xác ranh giới nơi lỗi đi vào vòng đời của yêu cầu. “Provider failed” là quá mơ hồ cho một bản ghi kiểm thử hữu ích.

type InjectionPoint =
  | "before_connect"
  | "after_connect_before_headers"
  | "after_headers_before_body"
  | "after_partial_stream"
  | "after_tool_dispatch_before_ack"
  | "after_tool_ack_before_model_response"
  | "after_transport_success_before_validation";

Ranh giới xác định những hành động khôi phục nào là an toàn. Một timeout trước khi kết nối thường có thể được thử lại. Một ngắt kết nối sau khi người dùng đã thấy đầu ra đòi hỏi phải khởi động lại rõ ràng. Một xác nhận bị mất sau lệnh gọi công cụ ở phía ghi đòi hỏi phải đối soát. Xem cả ba như cùng một lớp timeout là cách các hành động trùng lặp và phản hồi không nhất quán đi vào môi trường sản xuất.

Nếu lớp fault-injection của bạn không thể nhắm tới các ranh giới đó, hãy thêm dấu mốc ranh giới vào adapter của nhà cung cấp hoặc lớp điều phối trước khi thực hiện bài kiểm tra. Các công tắc lỗi thô hữu ích cho kiểm thử khả dụng nhưng không đủ cho kiểm thử an toàn khi phát lại.

Ghi lại một dòng bằng chứng cho mỗi yêu cầu

Ngày diễn tập nên tạo ra một sổ cái ở cấp yêu cầu, không chỉ là ảnh chụp màn hình dashboard. Một dòng ngắn gọn giúp các quyết định không được giải thích trở nên hữu hình.

Lưu sổ cái bên cạnh snapshot chính sách, phiên bản validator, cấu hình lỗi và bản xuất dashboard. Nếu thiếu các phiên bản đó, một bài kiểm tra đạt có thể không được tái tạo sau lần thay đổi adapter hoặc model tiếp theo.

Chấm điểm bài tập bằng các quy tắc thăng cấp

Sử dụng ba quyết định khả dĩ: chuyển tiếp, sửa và chạy lại, hoặc dừng tự động hóa. Tránh kết quả mơ hồ kiểu “phần lớn đã đạt”.

Chuyển tiếp tuyến chỉ khi tất cả điều sau đều đúng:

• Mọi yêu cầu đều có trạng thái kết thúc được giải thích.
• Không chuỗi lần thử nào vượt quá thời hạn chung, số lần thử, hoặc trần chi phí đã cấu hình.
• Mọi đầu ra được chấp nhận đều vượt qua trình xác thực hoặc quy tắc đánh giá của tuyến.
• Đầu ra một phần và các tác động phụ không chắc chắn đi vào các trạng thái dừng hoặc đối soát rõ ràng.
• Người vận hành có thể vô hiệu hóa một ứng viên hoặc toàn bộ chính sách mà không cần triển khai mã ứng dụng.
• Hệ thống cảnh báo xác định cả các lần khôi phục thất bại lẫn các lần khôi phục có hại, chẳng hạn như khôi phục thành công nhưng chất lượng tác vụ không chấp nhận được.

Chọn sửa và chạy lại khi mô hình an toàn là đúng nhưng bằng chứng hoặc triển khai chưa đầy đủ. Ví dụ gồm thiếu lý do của tuyến, cảnh báo kích hoạt quá muộn, hoặc một ứng viên vượt qua hợp đồng nhưng không đạt mục tiêu độ trễ.

Chọn dừng tự động hóa khi bài kiểm tra phát hiện sự mơ hồ trong phát lại, tác động phụ trùng lặp, ghép nối luồng âm thầm, định tuyến không được giải thích, vượt qua chính sách, hoặc một chế độ lỗi mà máy trạng thái hiện tại không thể biểu diễn. Đó là các lỗ hổng thiết kế, không phải vấn đề tinh chỉnh.

Sử dụng bảng điểm game-day có thể sao chép

game_day_result:
  game_day_id: fallback-gd-2026-08-04-extraction
  route_class: structured_extraction
  policy_version: fallback-v4
  evaluator_version: extraction-eval-v7
  started_at: 2026-08-04T09:00:00Z
  completed_at: 2026-08-04T10:00:00Z

  scenarios:
    equivalent_failover: pass
    retry_pressure: pass
    semantic_contract_failure: pass
    partial_stream: pass
    uncertain_tool_completion: not_applicable
    fallback_degradation: fix

  totals:
    requests: 100
    accepted: 94
    explicitly_degraded: 6
    unsafe_or_unexplained: 0
    duplicate_side_effects: 0
    deadline_violations: 0

  decision: fix_and_rerun
  blockers:
    - alternate p95 latency exceeded the route objective during degradation
  owner: ai-platform
  rerun_due: 2026-08-11

Các giá trị mẫu chỉ mang tính minh họa. Hãy dùng mục tiêu tuyến và ngưỡng đánh giá của riêng bạn. Điều quan trọng là quyết định cuối cùng phải chỉ ra bằng chứng được lưu giữ và một chủ sở hữu được nêu tên.

Biến phát hiện thành các kiểm soát phát hành

Kết thúc game day bằng cách chuyển mọi phát hiện thành một trong bốn kiểm soát bền vững sau:

1. Thay đổi chính sách: tiêu chí đủ điều kiện của ứng viên, ngân sách số lần thử, thời hạn, hoặc quy tắc theo lớp tuyến.
2. Kiểm thử hợp đồng: kiểm tra tính tương thích về năng lực, lược đồ, công cụ, streaming, hoặc an toàn.
3. Kiểm soát vận hành: cảnh báo, bảng điều khiển, công tắc ngắt, cách ly ứng viên, hoặc quy trình xử lý sự cố.
4. Hành vi sản phẩm: khởi động lại rõ ràng, thông điệp trạng thái suy giảm, xác nhận thủ công, hoặc màn hình đối soát.

Đừng kết thúc bài kiểm tra bằng một danh sách quan sát. Một phát hiện không có chủ sở hữu, loại kiểm soát, và điều kiện chạy lại sẽ xuất hiện trở lại trong một sự cố thực tế.

Đối với lớp telemetry phía sau các bài thực hành này, hãy sử dụng hướng dẫn quan sát API LLM. Để phân quyền retry và hành vi giới hạn tốc độ, hãy kết hợp game day với giới hạn tốc độ LLM và chiến lược retry. Nếu nhóm của bạn vẫn đang xác định ranh giới của gateway, hãy bắt đầu với hướng dẫn cơ bản về LLM gateway.

Chuỗi triển khai trong bảy ngày

Các nhóm có thể dùng trình tự này để chuyển từ danh sách mô hình tự phát sang một playbook quy trình được kiểm soát:

1. Ngày 1 — Kiểm kê các tuyến: phân loại chế độ đầu ra, rủi ro hiệu ứng phụ, công cụ, schema, thời hạn và chủ sở hữu retry hiện tại.
2. Ngày 2 — Xác định envelope: thiết lập giới hạn số lần thử, độ trễ, chi phí, năng lực và replay cho từng lớp tuyến.
3. Ngày 3 — Xây dựng hợp đồng: ghi lại các ứng viên đã được phê duyệt và kiểm tra khả năng tương thích của công cụ, schema, ngữ cảnh, modality và chính sách.
4. Ngày 4 — Gắn đo lường cho quyết định: ghi lại lỗi đã chuẩn hóa, trạng thái yêu cầu, phiên bản chính sách, điều kiện đủ của ứng viên, ngân sách, xác thực và kết quả người dùng.
5. Ngày 5 — Chạy diễn tập lỗi: chèn timeout, bùng phát giới hạn tốc độ, đầu ra không hợp lệ, ngắt kết nối giữa luồng và thực thi công cụ không rõ ràng.
6. Ngày 6 — Shadow và canary: quan sát quyết định trước, sau đó bật một tuyến hẹp rủi ro thấp với các trigger rollback đã xác định trước.
7. Ngày 7 — Rà soát và mở rộng: kiểm tra tỷ lệ tác vụ được chấp nhận, độ trễ tăng thêm, chênh lệch chi phí, tín hiệu replay không an toàn và các sự kiện không có fallback đủ điều kiện trước khi mở rộng.

Trình tự này cố ý lấy quy trình làm trung tâm trước. Việc chọn một danh sách mô hình được xếp hạng chỉ là một bước nhỏ. Công việc ở môi trường production là chứng minh khi nào hệ thống được phép tiếp tục, khi nào nó phải xác thực, và khi nào nó phải dừng lại.

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 envelope dự phòng.
• Chính sách fallback được phiên bản hóa và có thể xem xét như cấu hình.
• Các lỗi có thể retry được được chuẩn hóa trên các nhà cung cấp.
• Tổng ngân sách retry chỉ có một chủ sở hữu.
• 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 liê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 vô hiệu hóa fallback minh bạch theo mặc định.
• Các công cụ ghi dữ liệu phía ghi sử dụng bản ghi idempotency bền vững.

Xác thực

• Vận chuyển, hợp đồng và thành công của tác vụ được đo lường riêng biệt.
• Các đầu ra có cấu trúc được xác thực sau khi fallback.
• Tham số công cụ và hành vi lựa chọn công cụ được kiểm thử theo từng mô hình.
• Các bộ đánh giá fallback phản ánh những lớp tuyến thực tế.
• Các ứng viên mới vượt qua đánh giá ngoại tuyến và canary trong production.
• Cả năm bài diễn tập lỗi đều phải đạt với mỗi lớp tuyến áp dụng được.

Vận hành

• Mỗi lần thử đều ghi lại lý do tuyến, đích đến, độ trễ và kết quả.
• Bảng điều khiển hiển thị riêng chế độ chính, thử lại, chuyển dự phòng tương đương và khôi phục liên mô hình.
• Cảnh báo bao gồm tình trạng hết hạn chót và tỷ lệ không có phương án dự phòng đủ điều kiện.
• Bộ ngắt mạch 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 mà người dùng nhìn thấy và rủi ro tác dụng phụ trùng lặp.
• Mọi trace của lần thử đều ghi lại phiên bản chính sách dự phòng đang hoạt động.
• Mỗi tuyến đều có scorecard mức độ sẵn sàng đã hoàn tất và owner được chỉ định.
• Các trigger rollback canary và công tắc tắt hẹp được kiểm thử.
• Phiếu làm việc xử lý sự cố ghi nhận trạng thái yêu cầu, xác minh và kết quả đối với người dùng.

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

Đừng tối ưu chỉ cho 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 lấp việc dự phòng hoạt động tốt cho trích xuất nhưng kém cho sinh mã hoặc sử dụng công cụ.

Trong quá trình triển khai, hãy so sánh các chỉ số này theo phiên bản chính sách và giai đoạn phát hành. Điều đó giúp có thể tách một sự cố của nhà cung cấp khỏi thay đổi bộ điều khiển, thay đổi ứng viên hoặc mở rộng canary.

Cá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, chuyển sang năng lực tương đương, 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 sẽ không an toàn.

Sự khác nhau giữa thử lại và dự phòng là gì?

Thử lại lặp lại yêu cầu trên cùng đích hoặc cùng triển khai. Chuyển dự phòng tương đương chuyển yêu cầu sang năng lực nhằm duy trì cùng hợp đồng mô hình. Dự phòng liên mô hình thay đổi mô hình và do đó cần xác minh năng lực và chất lượng.

Có nên để mọi lỗi 429 kích hoạt sang mô hình khác không?

Không. Trước hết hãy phân loại giới hạn, tuân theo hướng dẫn thử lại, kiểm tra thời hạn còn lại và dùng một lần thử lại hoặc hàng đợi có giới hạn. 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ể thay đổi chất lượng đầu ra, hành vi công cụ hoặc chi phí.

Phản hồi được phát trực tuyến có thể dự phòng giữa chừng câu trả lời không?

Thường an toàn hơn nếu không chuyển đổi một cách trong suốt sau khi token đã đến tay người dùng. Hãy dừng luồng và đưa ra tùy chọn khởi động lại rõ ràng, trừ khi ứng dụng có một giao thức tiếp tục đã được kiểm thử.

Route nên có bao nhiêu mô hình dự phòng?

Hãy dùng bộ nhỏ nhất đã được phê duyệt nhưng vẫn cung cấp khả năng khôi phục có ý nghĩa. Mỗi ứng viên bổ sung thêm 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 phục hồi.

Logic dự phòng nên nằm ở đâu?

Tập trung hóa 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 quy trình — 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.

Một đội nên triển khai dự phòng mô hình tự động như thế nào?

Bắt đầu ở chế độ shadow, chỉ canary các quy trình an toàn khi phát lại, xác định các điều kiện rollback trước khi mở rộng lưu lượng, và tái chứng nhận chính sách dự phòng bất cứ khi nào mô hình, prompt, công cụ, schema, quyền sở hữu retry hoặc yêu cầu an toàn thay đổi.

Xây dựng dự phòng xoay quanh rủi ro của quy trình

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 ra quyết định có giới hạn:

• Quy trình 1 khôi phục các yêu cầu có thể phát lại bằng retry và năng lực tương đương.
• Quy trình 2 chỉ chuyển mô hình sau khi kiểm tra năng lực và chất lượng.
• Quy trình 3 dừng phát lại tự động khi đầu ra hoặc tác động phụ khiến việc khôi phục trở nên 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 đội 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 tương thích OpenAI hợp nhất của Flatkey làm bề mặt tích hợp, rồi gắn các bao bọc đặc thù theo quy trình 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
• Truyền phát tin nhắn 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