DSL ניתוב: הרכיב פאנל של מודלים שחושב כמו Fable 5

במשך שנתיים, ספר המשחקים ל"יותר אינטליגנציה" היה "חכה למודל הבא". לדעתנו, זו יחידת קידמה שגויה. הגבול אינו נקודת ביקורת אחת — זהו פאנל. תן לשלושה מודלים טובים את אותה בעיה קשה, תן להם לחלוק, ופסוק בין התשובות, והפאנל מנצח כל אחד מחבריו. לעתים קרובות הוא מנצח את המודל הבא במחירון.

ה-Routing DSL הוא הדרך לבנות את הפאנל הזה. זוהי אסטרטגיית ניתוב הניתנת לתכנות — YAML + CEL — שהופכת את נקודת הקצה של OrcaRouter שלך לגרף הסקה: ניתוב לפי קושי, ניתוב לפי משימה, פיצול למספר מודלים בבת אחת, שיפוט או הצבעה על הפלטים שלהם, גיבוי כאשר הביטחון נמוך, וכיוונון של הכל לפי עלות, זמן השהייה או איכות. אתה כותב כללים; השער מהדר ומפעיל אותם בכל בקשה תוך כ-5 מ"ש.

הפוסט הזה הוא הסיור ההנדסי: הדקדוק, המשתנים שעליהם ניתן לבצע הסתעפות, ארבעת הבוררים, המפל, ומערכת חוקי ייצור מלאה בסוף.

התוצאה ראשונה

שתי דוגמאות להמחשה. (המספרים הם להמחשה – הם נועדו להראות את הצורה של ההשפעה, ולא לצטט כציונים רשמיים.)

השוואת Frontierנקודת קצה DSL מנותבת קושי לעומת הפרונטיר הבודד:

פאנלי 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 סולו (~65.5%) תוך שימוש רק במודלים שמתחתיו.

אתה לא צריך מנויים יקרים. Opus + איחוי עצמי של Opus (~65.5%) תואם ל-Fable 5 עם מודל אחד ודגימה. פאנל של זולים מודלים — Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro (~64.5%) — ממש מתחת ל-Fable 5 בשבריר מהעלות לכל טוקן. זו כל התזה: קנה אינטליגנציה עם טופולוגיה, לא עם דרגת המחיר הבאה.

Routing DSL היא משטח הבקרה שמאפשר לך להשקיע את הטופולוגיה הזו רק במקום שבו היא משתלמת — דגמים זולים על 80% הקלים, fusion panel על ה-hard tail.

הדקדוק תוך 30 שניות

ערכת כללים היא גרסה, רשימה של כללים, וברירת מחדל נדרשת. כללים מוערכים מלמעלה למטה; ה-when הראשון: זה שנכון מנצח. ללא when: פירושו 'תמיד תואם.'

גרסה: 1

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

ה-when: הוא CEL ביטוי בוליאני — ארגז חול, ביטוי רגולרי RE2 בלבד, ללא לולאות, ללא קלט/פלט, הערכה במיקרו-שניות, עם מגבלת זמן יחידה של 5 אלפיות-שניה המשותפת לכל מערכת הכללים. ה-use: הוא ה אפקט: לאן הבקשה הולכת ואיך היא מכוונת. המגבלות קטנות במכוון (≤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: (בקיצור — ראה את ההתייחסות המלאה במסמכים):

דוגמאות קבוצה

צורת בקשה

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

כל יעד יכול לשאת כפתורים לכל קריאה, המתורגמים לפרמטרים המקוריים של כל ספק על ידי מתאם הממסר: reasoning_effort (low/medium/high), thinking_budget_tokens (1024–64000), samples (1–16), temperature (0.0–2.0), plus denylist-guarded param_override / header_override. זה כבר מספיק כדי לבנות את נקודת הקצה המנותבת לפי קושי מטבלה A: מודל זול בזנב הקל, Opus עם תקציב חשיבה בקשה הקשה.

פרימיטיב 2 — פריסה לפאנל (פיוז'ן)

מכאן מגיע הרמת המדד. מקבילה: אפקט שולח את הבקשה ל 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 קורא את כל המועמדים ומדרג אותם. זוהי התצורה Opus + GPT-5.5 → judge מטבלה B. מייעל איכות בעבודות פתוחות; חוזר לראשון-מצליח אם השופט שוגה.

מבחנים עוברים — מבוסס-הרצה: מגישים את המועמד שהתיקון שלו אכן גורם לחבילת הבדיקות לעבור. אין ניחוש שופט — המסגרת מחליטה. זהו הבורר החזק ביותר לעבודה עם קוד/סוכן. המאמת נמצא מחוץ לשער (מחובר דרך VerifierProvider); ללא חיבור, הוא מתדרדר לראשון-המצליח.

max_latency_ms (1000–600000, ברירת מחדל 120000) מגביל את ה-fan-out כך שרגל איטית אחת לא תוכל לעכב את התגובה — איטיים נשמטים. קינון של parallel בתוך parallel נדחה ב-lint; הפאנל הוא בכוונה בעומק רמה אחת.

הערת זמינות: זמן הריצה של פיצול N-כיווני מוגבל מאחורי דגל השרת ROUTING_DSL_ENSEMBLE_RUNTIME בעוד שחיוב לפי רגל מוקשח בסביבת ההכנה – לכן פיוז'ן הוא תצוגה מקדימה, לא GA. כשהדגל כבוי, כלל parallel: משרת בצורה נקייה את הרגל הראשונה שלו, כך שתוכלו ליצור ולבצע shadow לפאנלים שלכם היום ולהפעיל אותם כאשר פיוז'ן מגיע לאזור שלכם.

פרימיטיב 3 — גיבויים ומפלי אמון

Fan-out מוציא N× מראש. מפל מוציא תוספת רק כאשר התשובה הראשונה נראית שגויה. לאחר התגובה, 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 (הדיף נכשל ב־git apply --check), self_doubt (קבוצת regex של ביטויי גידור), low_logprob (הסתברות לוג-טוקן ממוצעת מתחת לסף, היכן שהספק חושף אותה), ו־next_turn_test_failed (נעילה בין-תורנית — הפרומפט של תור זה נושא את הצורה של הבדיקות הנכשלות מהתור הקודם). מפלים הם בעומק 1 לפי עיצוב. שלב אותם עם agent_state.models_tried כדי לקבל גיוון בניסיון חוזר — לעולם אל תשלח את התיקון למודל שבדיוק נכשל.

כוונון החוגה: עלות, השהייה, איכות

{{1}}אותה DSL מבטאת את כל שלוש המטרות; אתה בוחר לפי כלל{{/1}}

עלות — נציג: הזול ביותר, שמור על המודל הזול בזנב הקל, ושמור את ה-fan-out לדרגת קושי > 0.7. הפאנל הזול של טבלה B (~64.5% ≈ Fable 5 solo) הוא הוכחת הקיום: מיזוג של מודלים קטנים יכול להחליף מודל Frontier בשבריר מהעלות לטוקן. עם זאת, היה ברור — מיזוג משתמש ב־"לחייב כל רגל" מודל: פאנל best_of_n בעל 3 רגליים מחייב שלושה מועמדים פלוס השופט. הכלכלה עובדת כי אתה (א) מפעיל fan-out רק על המיעוט הקשה של הבקשות ו-(ב) ממזג זול יותר חברים ממודל ה-frontier שאתה מחליף.

השהייה — arbiter: { strategy: first } בתוספת max_latency_ms הדוק נותן לך את המהיר ביותר מתוך N עם תקרה קשיחה.

איכות — best_of_n לעבודה פתוחה, tests_pass כשיש חבילה להתבסס עליה. samples ו-thinking_budget_tokens קונות יותר בתוך רגל אחת.

הפעלתו מבלי לשבור את הייצור

שינויים בניתוב מפחידים, ולכן ה-DSL מגיע עם מסילות הבטיחות שמהנדס SRE מצפה להן:

בדיקת לינט בכל שמירה — סכמה, בדיקת טיפוסי CEL (כל when: חייב להתפרש כ-bool), פתרון הפניות, טווחי knob, רשימות חסימה של כותרות/פרמטרים. שגיאות מוחזרות כ-{line, column, message, rule} ומוצגות כצ'יפים בשוליים בעורך.

ריצה יבשה — שלח בקשת POST סינתטית (task_class, difficulty, agent_state, …) וקבל בחזרה את הכלל התואם, את ההשפעה שנקבעה, ואת זמן ההערכה לפני שכל דבר נשלח.

מצב צל — במשך 24 שעות לאחר השמירה הראשונה, ה-DSL הוא מוערך אך לא בשימוש; יומן צל מתעד את הבחירות שהיו נבחרות והקונסול מציג הפרש (אחוז מסלולים ששונו, שינוי עלות יומית משוער, ספירות הפעלה לכל כלל).

קנרי — מחוון תעבורה 0–100. הרמפה מ-5 → 25 → 50 → 100 תוך צפייה במדדים לפי-נתח; חזרה לאחור על ידי החלקה ל-0.

ביקורת + גלגול לאחור — כל שמירה/גלגול לאחור כותבת שורת ביקורת באותה עסקה; עריכות מקבילות מקבלות 409 עם הגרסה הנוכחית כדי שתנסה שנית מול מצב מעודכן.

מקרי בדיקה, הפעלה חוזרת של עקבות, ותצוגת AI 'הסבר את מערכת החוקים הזו' משלימים את זה. אתה מוצא את זה בלוח המחוונים תחת ניתוב → אסטרטגיה → 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

נקודת הקצה הזו היא זו שיושבת בראש טבלה A — לא משום שמצאה מודל טוב יותר, אלא משום שהיא משקיעה את המודל הנכון בבקשה הנכונה וממזגת פאנל בדיוק במקום שבו הפאנל מנצח.

התחל לכתוב

הקפיצה הבאה ביכולת אינה צריכה לחכות לנקודת הביקורת הבאה. זהו גרף שאתה יכול לכתוב אחר הצהריים: נתיב לפי קושי, להתפצל על הזנב הקשה, לשפוט או לבדוק את התפוקות, להפיץ כשהביטחון יורד.

מסמכים: https://docs.orcarouter.ai/routing/routing-dsl

ממשק משתמש: ניתוב → צור נתב -> אסטרטגיית ניתוב → DSL (מומחה)

הגבול הוא פאנל. לך תבנה את שלך.