Routing DSL: soạn một bảng điều khiển các mô hình suy nghĩ như Fable 5

Trong hai năm, kịch bản cho "thông minh hơn" là "chờ mô hình tiếp theo." Chúng tôi cho rằng đó là đơn vị tiến bộ sai lầm. Ranh giới không phải là một điểm kiểm tra duy nhất — nó là mộthội đồng. Hãy đưa cho ba mô hình tốt cùng một vấn đề khó, để chúng bất đồng, và phân xử giữa các câu trả lời, thì hội đồng sẽ đánh bại bất kỳ thành viên nào. Thường thì nó đánh bại mô hình tiếp theo trên biểu đồ giá.

Chính Routing DSL là cách bạn xây dựng bảng đó. Nó là một chiến lược định tuyến có thể lập trình — YAML + CEL — biến điểm cuối OrcaRouter của bạn thành một đồ thị suy luận: định tuyến theo độ khó, định tuyến theo tác vụ, phân nhánh đến nhiều mô hình cùng lúc, đánh giá hoặc bỏ phiếu cho đầu ra của chúng, dự phòng khi độ tin cậy thấp, và tinh chỉnh toàn bộ vì chi phí, độ trễ hoặc chất lượng. Bạn viết các quy tắc; gateway biên dịch và chạy chúng trên mỗi yêu cầu trong ~5 ms.

Bài đăng này là chuyến tham quan kỹ thuật: cú pháp, các biến bạn có thể rẽ nhánh, bốn trọng tài, dòng thác và một bộ quy tắc sản xuất hoàn chỉnh ở cuối.

Kết quả đầu tiên

Hai điểm chuẩn minh họa. (Các con số chỉ mang tính minh họa — chúng nhằm thể hiện hình dạng của hiệu ứng, không phải để trích dẫn làm điểm số chính thức.)

So sánh biên giới — một điểm cuối DSL định tuyến theo độ khó so với biên giới đơn lẻ:

Bảng Fusion so với các mô hình đơn lẻ — đạt điểm trên 93 trong số 100 nhiệm vụ (từ OpenRouter):

Ba điều đáng để ngắm nhìn:

Mọi bảng tổng hợp đều đánh bại từng thành viên của nó.Opus 4.8 + GPT-5.5 (~67.5%) vượt qua cả Opus solo (~58.5%) và GPT-5.5 solo (~60%) với 7–9 điểm. Sự bất đồng là tín hiệu; trọng tài khai thác nó.

Fusion đạt đến cấp độ tiếp theo. Ba bảng điều khiển khác nhau vượt qua Fable 5 solo (~65.5%) chỉ sử dụng các mô hình bên dưới nó.

Bạn không cần thành viên đắt tiền.Opus + Opus tự kết hợp (~65.5%) ngang bằng Fable 5 với một mô hình và một sampler. Một bảng gồm rẻ mô hình — Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro (~64.5%) — đạt thấp hơn Fable 5 một chút với chi phí mỗi token chỉ bằng một phần nhỏ. Đó là toàn bộ luận điểm: mua trí thông minh bằng cấu trúc liên kết, không phải bằng mức giá tiếp theo.

Bộ định tuyến DSL là bề mặt điều khiển cho phép bạn triển khai cấu trúc liên kết đó chỉ ở những nơi có hiệu quả — các mô hình rẻ tiền cho 80% dễ dàng, một bảng hợp nhất cho phần đuôi khó.

Ngữ pháp trong 30 giây

Một ruleset là version, một danh sách các rules, và một default bắt buộc. Các rules được đánh giá từ trên xuống dưới; when: đầu tiên đúng sẽ thắng. Không có when: nghĩa là "luôn khớp."

phiên bản: 1

rules:
  - id: only_rule
    use: { model: "claude-sonnet-4-6" }
default:
  delegate: balanced

when: là một CEL biểu thức boolean — được sandbox, chỉ sử dụng regex RE2, không có vòng lặp, không I/O, đánh giá trong micro giây, với một hạn chót 5 ms duy nhất chia sẻ cho toàn bộ tập quy tắc. use: là hiệu ứng: nơi yêu cầu được gửi đến và cách nó được điều chỉnh. Các giới hạn được cố ý nhỏ (≤30 quy tắc, ≤16 KiB mã nguồn, ≤200 ký tự cho mỗi when:) để một tập quy tắc có thể kiểm toán được.

Nguyên thủy 1 — định tuyến theo độ khó và nhiệm vụ

Bộ phân phối phân loại mọi yêu cầu trước khi định tuyến và hiển thị các tính năng cho CEL. Bạn phân nhánh trực tiếp trên chúng:

phiên bản: 1

rules:
  - id: hard_reasoning
    when: difficulty > 0.8
    use:
      model: "claude-opus-4-8"
      reasoning_effort: "high"
      thinking_budget_tokens: 32000


  - id: code_path
    when: task_class == "code" && code_keyword_density > 0.5
    use: { model: "gpt-5.5" }


  - id: cheap_chat
    when: difficulty < 0.3
    use: { model: "gemini-3-flash" }


default:
  delegate: balanced

Các biến bạn có thể đọc trong when: (viết tắt — xem tài liệu tham khảo đầy đủ trong tài liệu hướng dẫn):

Ví dụ nhóm

Hình dạng yêu cầu

request.input_tokens, request.output_max_tokens, request.stream, request.vision, request.message_count, request.has_tools

Phân loại

task_class (chat/code/agent/vision/audio/rag/creative), difficulty (0.0–1.0), code_keyword_density, reasoning_cue_count, log_prompt_tokens, tool_count

Phiên 

agent_state.turn, agent_state.tools_used, agent_state.has_edited, agent_state.last_test_failed, agent_state.consecutive_errors, agent_state.models_tried

Bối cảnh

headers["x-…"], user.group, token.name, time.hour, workspace.id
…plus six macros for the things regex-over-payload is good at: system_prompt_matches(re), user_message_matches(re), tool_definitions_include(name), tool_calls_present_any([…]), tool_results_from_any([…]), header_matches(name, re).

Bất kỳ điểm đến nào cũng có thể mang các núm điều chỉnh cho mỗi cuộc gọi, được dịch thành các tham số gốc của từng nhà cung cấp bởi bộ chuyển tiếp relay adapter: reasoning_effort (thấp/trung bình/cao), thinking_budget_tokens (1024–64000), samples (1–16), temperature (0.0–2.0), cùng với param_override / header_override được bảo vệ bởi danh sách chặn. Điều đó đã đủ để xây dựng endpoint định tuyến theo độ khó từ Bảng A: mô hình rẻ cho các tác vụ dễ, Opus với ngân sách suy nghĩ cho các tác vụ khó.

Nguyên thủy 2 — tỏa ra bảng (hợp nhất)

Đây là nơi mà mức tăng điểm chuẩn đến từ. Một song song: hiệu ứng gửi yêu cầu đến 2–5 nhánh đồng thời, sau đó một trọng tài quyết định những gì khách hàng thực sự thấy:

- id: hard_tail_panel
  when: difficulty > 0.7 && task_class == "agent"
  use:
    parallel:
      - { model: "anthropic/claude-opus-4-8", reasoning_effort: "high" }
      - { model: "openai/gpt-5.5", thinking_budget_tokens: 16000 }
      - { model: "google/gemini-3.1-pro", temperature: 0.3 }
    arbiter:
      strategy: best_of_n
      model: "anthropic/claude-sonnet-4-6"      # the judge
      template: judge_code
    max_latency_ms: 120000
    on_disagreement:                  # majority-only escape hatch
      model: "anthropic/claude-opus-4-8"
      reasoning_effort: "high"

Bốn chiến lược trọng tài, mỗi chiến lược là một câu trả lời khác nhau cho câu hỏi "kết quả đầu ra của ai thắng?":

đầu tiên — đua các chặng, phục vụ thành công đầu tiên, hủy bỏ kẻ thua cuộc. Tối ưu hóa độ trễ (bạn nhận được nhanh nhất trong N).

đa số — bỏ phiếu có cấu trúc qua đầu ra của các nhánh, không gọi thêm mô hình. Khi các nhánh chia rẽ mà không có đa số tuyệt đối, nhánh tùy chọn on_disagreement: gửi lại một lần thử mới mạnh hơn thay vì phá vỡ thế hòa. Tối ưu hóa tính mạnh mẽ cho các tác vụ có câu trả lời chính tắc.

best_of_n — một bộ đánh giá LLM đọc tất cả các ứng viên và xếp hạng chúng. Đây là cấu hình Opus + GPT-5.5 → bộ đánh giá từ Bảng B. Tối ưu hóa chất lượng trên các tác vụ mở; dự phòng sang kết quả thành công đầu tiên nếu bộ đánh giá gặp lỗi.

kiểm_tra_đạt — dựa-trên-thực-thi: phục vụ ứng viên có bản vá thực sự làm cho bộ kiểm thử vượt qua. Không có phỏng đoán của người đánh giá — harness quyết định. Đây là trọng tài mạnh nhất cho công việc mã/agent. Bộ xác minh sống bên ngoài gateway (kết nối qua VerifierProvider); nếu không có kết nối, nó giảm xuống thành first-successful.

max_latency_ms (1000–600000, mặc định 120000) giới hạn fan-out để một nhánh chậm không thể làm tắc nghẽn phản hồi — các laggard bị loại bỏ. Việc lồng parallel bên trong parallel bị từ chối ở lint; bảng điều khiển có độ sâu một cấp một cách cố ý.

Lưu ý về tính khả dụng: thời gian chạy N-way fan-out được kiểm soát bởi cờ máy chủ ROUTING_DSL_ENSEMBLE_RUNTIME trong khi tính cước theo chặng được củng cố trên staging — đó là lý do tại sao fusion là preview, không phải GA. Với cờ tắt, rule parallel: phục vụ sạch chặng đầu tiên của nó, vì vậy bạn có thể tạo và shadow các panel của mình ngay hôm nay và bật chúng khi fusion có mặt trong khu vực của bạn.

Nguyên thủy 3 — dự phòng và thác độ tin cậy

Fan-out tốn N× ngay từ đầu. Một cascade tốn thêm chỉ khi câu trả lời đầu tiên có vẻ sai. Sau phản hồi, on_low_confidence: đánh giá các tín hiệu và nếu có tín hiệu kích hoạt, sẽ gửi lại đến đích mạnh hơn:

- id: agent_with_safety_net
  when: task_class == "agent"
  use:
    pool: "@pool:fast"
  on_low_confidence:
    signals: [patch_invalid, self_doubt, next_turn_test_failed]
    threshold: { low_logprob: -1.5 }
    use:
      model: "claude-opus-4-8"
      reasoning_effort: "high"

Các tín hiệu: patch_invalid (bản diff thất bại git apply --check), self_doubt (một tập hợp regex các cụm từ thận trọng), low_logprob (mean token logprob dưới ngưỡng, nơi nhà cung cấp hiển thị nó), và next_turn_test_failed (một chốt chéo lượt — prompt của lượt này mang hình dạng của các bài kiểm tra thất bại của lượt trước). Cascades được thiết kế với độ sâu 1. Ghép chúng với agent_state.models_tried để có đa dạng khi thử lại — không bao giờ gửi sửa chữa đến model vừa thất bại.

Điều chỉnh núm: chi phí, độ trễ, chất lượng

Cùng một DSL thể hiện cả ba mục tiêu; bạn chọn theo quy tắc:

Chi phí — đại diện: rẻ nhất, giữ mô hình rẻ ở phần đuôi dễ, và dành fan-out cho độ khó > 0.7. Panel rẻ của Bảng B (~64.5% ≈ Fable 5 solo) là bằng chứng tồn tại: sự kết hợp các mô hình nhỏ có thể thay thế một mô hình tiên phong với chi phí mỗi token chỉ bằng một phần nhỏ. Hãy tỉnh táo, tuy nhiên — fusion sử dụng "tính phí từng chân" mô hình: một panel best_of_n 3-leg tính phí ba ứng viên cộng với người đánh giá. Kinh tế học hoạt động vì bạn (a) chỉ fan-out trên thiểu số yêu cầu khó và (b) hợp nhấtrẻ hơn các thành viên so với mô hình tiên phong bạn đang thay thế.

Độ trễ — arbiter: { strategy: first } cộng với một max_latency_ms chặt chẽ cho bạn nhanh nhất trong N với một giới hạn cứng.

Chất lượng — best_of_n cho công việc mở, tests_pass khi có một bộ kiểm thử để dựa vào. samples và thinking_budget_tokens mua thêm nhiều hơn trong một lần chạy đơn.

Vận hành nó mà không phá vỡ prod.

Thay đổi định tuyến thật đáng sợ, vì vậy DSL đi kèm với các thanh an toàn mà SRE mong đợi:

Kiểm tra lint mỗi lần lưu — schema, kiểm tra kiểu CEL (mọi when: phải đánh giá thành bool), phân giải tham chiếu, phạm vi knob, danh sách chặn header/param. Lỗi trả về dưới dạng {line, column, message, rule} và hiển thị dưới dạng chip lề trong trình soạn thảo.

Chạy thử — POST yêu cầu tổng hợp (task_class, difficulty, agent_state, …) và nhận lại quy tắc khớp, hiệu ứng đã giải quyết, và thời gian đánh giá trước khi bất kỳ thứ gì được gửi đi.

Chế độ Shadow — trong 24 giờ sau lần lưu đầu tiên, DSL được đánh giá nhưng không được sử dụng; một nhật ký shadow ghi lại các lựa chọn tiềm năng và bảng điều khiển hiển thị sự khác biệt (phần trăm tuyến đường thay đổi, chênh lệch chi phí dự kiến hàng ngày, số lần kích hoạt theo từng quy tắc).

Canary — một thanh trượt lưu lượng 0–100. Tăng dần 5 → 25 → 50 → 100, theo dõi các chỉ số theo từng lát; quay lại bằng cách trượt về 0.

Kiểm toán + khôi phục — mỗi lần lưu/khôi phục sẽ ghi một dòng kiểm toán trong cùng một giao dịch; các chỉnh sửa đồng thời sẽ nhận mã 409 kèm phiên bản hiện tại để bạn thử lại với trạng thái mới nhất.

Các trường hợp kiểm thử, phát lại dấu vết và chế độ xem AI 'giải thích bộ quy tắc này' hoàn thiện nó. Bạn tìm thấy nó trong bảng điều khiển dưới định tuyến → chiến lược → DSL.

Một bộ quy tắc hoàn chỉnh

Rẻ trên dễ, trung bình trên trung bình, một bảng đánh giá hợp nhất trên đuôi tác nhân cứng, với một dòng thác tự tin bên dưới:

phiên bản: 1

rules:
  - id: trivial
    when: difficulty < 0.3 && !has_tools
    use: { model: "gemini-3-flash" }


  - id: standard
    when: difficulty < 0.7
    use:
      model: "gpt-5.5"
    on_low_confidence:
      signals: [self_doubt, low_logprob]
      use: { model: "claude-opus-4-8", reasoning_effort: "high" }


  - id: hard_agent_panel
    when: difficulty >= 0.7 && task_class == "agent"
    use:
      parallel:
        - { model: "anthropic/claude-opus-4-8", reasoning_effort: "high" }
        - { model: "openai/gpt-5.5", thinking_budget_tokens: 16000 }
        - { model: "google/gemini-3.1-pro" }
      arbiter:
        strategy: tests_pass        # execution-grounded; judged fallback if no harness
      max_latency_ms: 180000
      on_disagreement:
        model: "claude-opus-4-8"
        reasoning_effort: "high"


default:
  delegate: balanced

Điểm cuối đó là điểm nằm ở đầu Bảng A — không phải vì nó tìm ra được mô hình tốt hơn, mà vì nó dành mô hình đúng cho yêu cầu đúng và kết hợp một bảng điều khiển chính xác tại nơi bảng điều khiển đó thắng.

Bắt đầu soạn

Bước nhảy vọt tiếp theo về khả năng không cần phải chờ đợi điểm kiểm tra tiếp theo. Đó là một đồ thị bạn có thể viết vào chiều nay: định tuyến theo độ khó, phân tán trên phần đuôi khó, đánh giá hoặc kiểm tra các đầu ra, phân tầng khi độ tin cậy giảm.

Tài liệu: https://docs.orcarouter.ai/routing/routing-dsl

Giao diện: định tuyến → Tạo router -> Chiến lược định tuyến → DSL (chuyên gia)

Frontier là một panel. Hãy xây dựng của bạn.