Routing DSL: สร้างแผงโมเดลที่คิดเหมือน Fable 5

เป็นเวลาสองปีที่คู่มือสำหรับ "ปัญญาที่มากขึ้น" คือ "รอโมเดลถัดไป" เราคิดว่านั่นเป็นหน่วยความก้าวหน้าที่ผิด พรมแดนไม่ใช่จุดตรวจสอบเดียว — มันคือกลุ่ม. ให้โมเดลที่ดีสามตัวเจอปัญหาเดียวกันที่ยาก ให้พวกมันไม่เห็นด้วยกัน และตัดสินระหว่างคำตอบ แล้วกลุ่มก็จะเอาชนะสมาชิกคนใดคนหนึ่งของมัน บ่อยครั้งมันเอาชนะโมเดลถัดไปในแผนภูมิราคา

ตัวRouting DSLเป็นวิธีที่คุณสร้างแผงควบคุมนั้น ซึ่งเป็นกลยุทธ์การกำหนดเส้นทางที่โปรแกรมได้ — YAML + CEL — ที่เปลี่ยนปลายทาง OrcaRouter ของคุณให้เป็นกราฟการอนุมาน: กำหนดเส้นทางตามความยาก, กำหนดเส้นทางตามงาน, แจกจ่ายไปยังหลายโมเดลพร้อมกัน, ตัดสินหรือลงคะแนนผลลัพธ์ของพวกมัน, ถอยกลับเมื่อความมั่นใจต่ำ, และปรับแต่งทั้งหมดเพื่อต้นทุน ความหน่วง หรือคุณภาพ คุณเขียนกฎ; เกตเวย์จะคอมไพล์และรันกฎเหล่านั้นในทุกคำขอภายในประมาณ 5 มิลลิวินาที.

โพสต์นี้คือทัวร์วิศวกรรม: ไวยากรณ์, ตัวแปรที่คุณสามารถแยกสาขาได้, ตัวตัดสินสี่ตัว, การเรียงลำดับ, และชุดกฎการผลิตที่สมบูรณ์ในตอนท้าย

ผลลัพธ์ก่อน

ตัวอย่างเกณฑ์มาตรฐานสองตัวอย่างที่แสดงให้เห็น (ตัวเลขเป็นเพียงการแสดงให้เห็น — มีจุดประสงค์เพื่อแสดง รูปแบบของผลกระทบ ไม่ใช่เพื่ออ้างเป็นคะแนนอย่างเป็นทางการ)

การเปรียบเทียบ Frontier — จุดสิ้นสุด DSL ที่กำหนดเส้นทางตามความยาก เทียบกับ solo frontier:

แผง Fusion เทียบกับโมเดลเดี่ยว — ได้คะแนน 93 จาก 100 งาน (จาก OpenRouter):

สามสิ่งที่ควรจ้องมอง:

แผงฟิวชันทุกอันเอาชนะสมาชิกทุกคนของตัวเอง Opus 4.8 + GPT-5.5 (~67.5%) เอาชนะทั้ง Opus solo (~58.5%) และ GPT-5.5 solo (~60%) ได้ 7–9 คะแนน ความไม่เห็นพ้องคือสัญญาณ; การไกล่เกลี่ยเก็บเกี่ยวมัน

Fusion ถึงระดับถัดไป แผงที่แตกต่างกันสามแผงข้าม Fable 5 solo (~65.5%) โดยใช้เฉพาะโมเดล ด้านล่าง มัน.

คุณไม่จำเป็นต้องมีสมาชิกราคาแพง Opus + Opus self-fusion (~65.5%) ตรงกับ Fable 5 ด้วยหนึ่งโมเดลและหนึ่ง sampler กลุ่มของราคาถูกโมเดล — Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro (~64.5%) — ได้ผลลัพธ์ที่ต่ำกว่า Fable 5 เพียงเล็กน้อยที่ต้นทุนต่อโทเคนเพียงเศษเสี้ยว นั่นคือประเด็นทั้งหมด: ซื้อปัญญาด้วย topology ไม่ใช่ด้วยระดับราคาถัดไป

Routing DSL คือพื้นผิวควบคุมที่ช่วยให้คุณใช้โทโพโลยีนั้นเฉพาะในจุดที่คุ้มค่า — โมเดลราคาถูกสำหรับ 80% ที่ง่าย แผงฟิวชันสำหรับส่วนที่ยาก

ไวยากรณ์ใน 30 วินาที

กฎเซตคือเวอร์ชัน รายการของกฎ และค่าเริ่มต้นที่จำเป็น กฎจะถูกประเมิน จากบนลงล่าง; when แรกที่เป็นจริงจะเป็นฝ่ายชนะ. No when: หมายถึง 'ตรงกันเสมอ.'

เวอร์ชัน: 1

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

เมื่อ: เป็น CEL นิพจน์บูลีน — ปลอดภัย (sandboxed) ใช้ regex RE2 เท่านั้น ไม่มีลูป ไม่มี I/O ประเมินผลในระดับไมโครวินาที โดยมีกำหนดเวลา 5 ms เดียวที่ใช้ร่วมกันทั่วทั้งชุดกฎ use: คือ effect: ที่คำขอไปและวิธีการปรับแต่ง ขีดจำกัดถูกตั้งให้เล็กโดยเจตนา (≤30 กฎ, ≤16 KiB ของซอร์ส, ≤200 ตัวอักษรต่อ when:) เพื่อให้ชุดกฎยังคงตรวจสอบได้

พื้นฐาน 1 — เส้นทางตามระดับความยากและภารกิจ

ตัวจัดจำหน่ายจะจำแนกทุกคำขอก่อนการกำหนดเส้นทางและเปิดเผยฟีเจอร์ต่างๆ ให้กับ CEL คุณสามารถแยกย่อยตามคำขอเหล่านั้นได้โดยตรง:

เวอร์ชัน: 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

ตัวแปรที่คุณสามารถอ่านได้ใน when: (ตัวย่อ — ดูเอกสารอ้างอิงฉบับเต็มใน docs):

กลุ่มตัวอย่าง

รูปแบบคำขอ

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

การจำแนกประเภท

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

เซสชัน 

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

บริบท

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).

ปลายทางใดๆ สามารถมีปุ่มปรับต่อการเรียกใช้ ซึ่งถูกแปลเป็นพารามิเตอร์ดั้งเดิมของผู้ให้บริการแต่ละรายโดย relay adapter: reasoning_effort (low/medium/high), thinking_budget_tokens (1024–64000), samples (1–16), temperature (0.0–2.0) รวมถึง param_override / header_override ที่ป้องกันโดย denylist. นั่นก็เพียงพอที่จะสร้าง endpoint ที่กำหนดเส้นทางตามความยากจากตาราง A: โมเดลราคาถูกสำหรับส่วนท้ายที่ง่าย, Opus พร้อมงบประมาณการคิดสำหรับส่วนที่ยาก

พื้นฐานที่ 2 — การกระจายออกไปยังแผง (ฟิวชัน)

นี่คือที่มาของ benchmark lift การทำงานแบบขนาน: เอฟเฟกต์จะส่งคำขอไปยัง 2–5 ส่วนพร้อมกัน, จากนั้น ผู้ชี้ขาด ตัดสินว่าลูกค้าเห็นอะไรจริงๆ:

- 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"

สี่กลยุทธ์ของผู้ชี้ขาด แต่ละอย่างเป็นคำตอบที่แตกต่างสำหรับคำถามที่ว่า "ผลลัพธ์ของใครชนะ?":

แรก — แข่งในแต่ละเส้นทาง ส่งมอบความสำเร็จแรก ยกเลิกผู้แพ้. ปรับให้เหมาะสมกับ เวลาแฝง (คุณจะได้ผลลัพธ์ที่เร็วที่สุดจาก N).

เสียงส่วนใหญ่ — การโหวตแบบมีโครงสร้างข้ามผลลัพธ์ของขา โดยไม่มีการเรียกใช้โมเดลเพิ่มเติม เมื่อขาแตกออกโดยไม่มีเสียงข้างมากที่ชัดเจน ตัวเลือก on_disagreement: สาขาจะส่งภารกิจใหม่ที่เข้มข้นกว่าแทนที่จะให้ผลลัพธ์แบบเสมอ ปรับให้เหมาะสม ความทนทาน ในงานที่มีคำตอบมาตรฐาน.

best_of_n — LLM judgeอ่านผู้สมัครทั้งหมดและจัดอันดับ นี่คือการกำหนดค่า Opus + GPT-5.5 → judge จาก Table B เพิ่มประสิทธิภาพ คุณภาพ บนงานปลายเปิด; ถอยกลับไปใช้ first-successful หากผู้ตัดสินผิดพลาด.

การทดสอบผ่าน — ยึดตามการดำเนินการ: ให้บริการผู้สมัครที่แพตช์ของเขาทำให้ชุดทดสอบผ่านจริงๆ ไม่มีการเดาของผู้ประเมิน — ตัวโครงทดสอบเป็นผู้ตัดสิน นี่คือผู้ชี้ขาดที่แข็งแกร่งที่สุดสำหรับงานที่เกี่ยวกับโค้ดหรือเอเจนต์ ตัวตรวจสอบอยู่ภายนอกเกตเวย์ (เชื่อมต่อผ่าน VerifierProvider); หากไม่ได้เชื่อมต่อใดๆ จะลดระดับไปเป็นสำเร็จอันดับแรก

max_latency_ms (1000–600000, ค่าเริ่มต้น 120000) จำกัดการกระจาย (fan-out) เพื่อให้ขาที่ช้าตัวเดียวไม่สามารถทำให้การตอบสนองหยุดชะงัก — ผู้ที่ล้าหลังจะถูกตัดออก การซ้อน parallel ภายใน parallel จะถูกปฏิเสธที่ lint; แผงนี้ตั้งใจให้มีเพียงระดับเดียว

หมายเหตุเกี่ยวกับความพร้อมใช้งาน: รันไทม์ N-way fan-out ถูกจำกัดอยู่หลังแฟล็กเซิร์ฟเวอร์ ROUTING_DSL_ENSEMBLE_RUNTIME ในขณะที่ per-leg billing ได้รับการทำให้แข็งแกร่งบน staging — นั่นคือเหตุผลที่ fusion อยู่ในสถานะpreview, not GA. เมื่อปิดแฟล็ก กฎ parallel: จะให้บริการเลกแรกอย่างราบรื่น ดังนั้นคุณสามารถสร้างและทดสอบแผงของคุณวันนี้ และเปิดใช้งานเมื่อ fusion มาถึงในภูมิภาคของคุณ.

Primitive 3 — ฟอลแบ็กและคาสเคดความเชื่อมั่น

Fan-out ใช้จ่าย N× ล่วงหน้า. หนึ่ง cascade ใช้จ่ายเพิ่มเติม เฉพาะเมื่อคำตอบแรกดูผิด. หลังจากตอบรับ, on_low_confidence: ประเมินสัญญาณ และหากเกิดการกระตุ้น, จะส่งไปยังปลายทางที่แข็งแกร่งกว่าอีกครั้ง:

- 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"

สัญญาณ: patch_invalid (การ diff ล้มเหลวเมื่อใช้ git apply --check), self_doubt (ชุด regex ของวลีที่แสดงความลังเล), low_logprob (ค่าเฉลี่ย logprob ของ token ต่ำกว่าเกณฑ์ โดยที่ผู้ให้บริการเปิดเผยค่านั้น), และ next_turn_test_failed (กลไก latch ข้ามรอบ — prompt ของรอบนี้มีรูปแบบของ test ที่ล้มเหลวในรอบที่แล้ว). Cascades มี depth-1 โดยการออกแบบ. จับคู่กับ agent_state.models_tried เพื่อให้ได้ ความหลากหลายในการลองใหม่ — อย่าส่งการซ่อมไปยังโมเดลที่เพิ่งล้มเหลวเด็ดขาด.

ปรับหมุนปุ่ม: ต้นทุน ความหน่วง คุณภาพ

DSL เดียวกันแสดงวัตถุประสงค์ทั้งสาม; คุณเลือกตามกฎ:

ต้นทุน — ตัวแทน: ถูกที่สุด, เก็บโมเดลราคาถูกไว้ทางหางที่ง่าย, และสงวนการกระจายงานสำหรับความยาก > 0.7 แผงราคาถูกของตาราง B (~64.5% ≈ Fable 5 solo) เป็นข้อพิสูจน์การมีอยู่: การฟิวชันของโมเดลขนาดเล็กสามารถแทนที่โมเดลระดับแนวหน้าได้ด้วยต้นทุนต่อโทเคนเพียงเศษเสี้ยว จงมองให้ชัดเจน — การฟิวชันใช้โมเดล"คิดเงินทุกขา" โมเดล: แผง best_of_n แบบ 3 ขาคิดเงินจากผู้สมัครสามคนและผู้ตัดสิน เศรษฐศาสตร์ทำงานได้เพราะคุณ (ก) กระจายงานเฉพาะกับคำขอส่วนน้อยที่ยาก และ (ข) รวม ถูกกว่า สมาชิกที่ถูกกว่าโมเดลระดับแนวหน้าที่คุณกำลังแทนที่

เวลาแฝง — arbiter: { strategy: first } รวมกับ max_latency_ms ที่จำกัดแน่นจะให้ค่าที่เร็วที่สุดใน N โดยมีเพดานจำกัด

คุณภาพ — best_of_n สำหรับงานปลายเปิด, tests_pass เมื่อมีชุดทดสอบเพื่อยึดโยง. samples และ thinking_budget_tokens ให้มากขึ้นภายในรอบเดียว

การใช้งานมันโดยไม่ทำให้ prod เสีย

การเปลี่ยนแปลงเส้นทางเป็นเรื่องที่น่ากลัว ดังนั้น DSL จึงมาพร้อมกับราวนิรภัยที่ SRE คาดหวัง:

Lint ทุกครั้งที่บันทึก — schema, CEL type-check (every when: ต้องประเมินเป็น bool), ref resolution, knob ranges, header/param denylists. ข้อผิดพลาดจะถูกส่งกลับเป็น {line, column, message, rule} และแสดงผลเป็น gutter chips ในตัวแก้ไข.

การทดลองรัน — ส่งคำขอจำลอง (task_class, difficulty, agent_state, …) และรับกลับคืนกฎที่ตรงกัน ผลกระทบที่ถูกแก้ไข และเวลาในการประเมินก่อนที่จะส่งมอบสิ่งใด

โหมดเงา — เป็นเวลา 24 ชม. หลังจากบันทึกครั้งแรก DSL จะถูก ประเมินแต่ไม่ถูกใช้; บันทึกเงาจะบันทึกการเลือกที่อาจเกิดขึ้นและคอนโซลจะแสดง diff (เปอร์เซ็นต์ของเส้นทางที่เปลี่ยน, ผลต่างต้นทุนรายวันที่คาดการณ์, จำนวนการยิงต่อกฎ).

Canary — แถบเลื่อนปริมาณการจราจรแบบ 0–100. ค่อยๆ เพิ่มจาก 5 → 25 → 50 → 100 โดยดูเมตริกต่อสไลซ์; ย้อนกลับโดยเลื่อนไปที่ 0.

การตรวจสอบ + การย้อนกลับ — ทุกการบันทึก/การย้อนกลับจะเขียนแถวการตรวจสอบในธุรกรรมเดียวกัน; การแก้ไขพร้อมกันจะได้รับรหัส 409 พร้อมเวอร์ชันปัจจุบัน เพื่อให้คุณลองใหม่กับสถานะล่าสุด

กรณีทดสอบ, การเล่นซ้ำร่องรอย, และมุมมอง AI 'explain this ruleset' ช่วยเสริมให้ครบถ้วน คุณจะพบได้ในแดชบอร์ดภายใต้ การกำหนดเส้นทาง → กลยุทธ์ → DSL.

กฎกติกาที่สมบูรณ์

ถูกในเรื่องง่าย กลางในเรื่องปานกลาง แผงฟิวชันที่ถูกตัดสินบนหางที่หนักหน่วงของตัวแทน พร้อมน้ำตกแห่งความมั่นใจด้านล่าง:

เวอร์ชัน: 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

เอนด์พอยต์นั้นคือจุดที่อยู่บนสุดของ Table A — ไม่ใช่เพราะมันพบโมเดลที่ดีกว่า แต่เพราะมันใช้โมเดลที่ถูกต้องกับคำขอที่ถูกต้องและผสานแผงตรงที่แผงนั้นชนะ

เริ่มเขียน

การก้าวกระโดดครั้งถัดไปในความสามารถไม่จำเป็นต้องรอจุดตรวจถัดไป มันคือกราฟที่คุณสามารถเขียนได้ในบ่ายนี้: กำหนดเส้นทางตามความยาก, กระจายออกไปยังส่วนที่ยาก, ตัดสินหรือทดสอบผลลัพธ์, และกระจายต่อเมื่อความมั่นใจลดลง

เอกสาร: https://docs.orcarouter.ai/routing/routing-dsl

UI: การกำหนดเส้นทาง → สร้างเราเตอร์ -> กลยุทธ์การกำหนดเส้นทาง → DSL (ผู้เชี่ยวชาญ)

Frontier คือแผง ไปสร้างของคุณเอง