Provider Routing در Editorial/AI Workflows

1) مسئله: Router ارزان‌ترین مدل نیست

در یک workflow تحریریه، خلاصه‌سازی، بررسی وفاداری به منبع و تفسیر تصویر نیازهای یکسانی ندارند. اگر Routing فقط «ارزان‌ترین مدلِ در دسترس» باشد، ممکن است داده به provider نامجاز برود، مدل modality لازم را نداشته باشد، مدل retire شده باشد یا fallback هیچ‌وقت روی همان task ارزیابی نشده باشد. هدف این درس ساخت Editorial Provider Routing Matrix v1 است؛ تصمیمی که از evidence قابل بازپخش به دست می‌آید، نه از ترجیح لحظه‌ای.

2) مرز COM-007: Routing، نه طراحی کل Editorial Cell

این درس مالک انتخاب provider/model برای stageهای مشخص است. طراحی نقش‌های چندمدلی COM-006 و Claim/Source Registry در COM-008 خارج از این مرزند. این درس traffic واقعی، billing، credential یا production routing را تغییر نمی‌دهد و هیچ vendor doc را مجوز معماری MAKNOW فرض نمی‌کند.

3) مدل ذهنی: Task Contract → Eligibility → Eval Floor → Budgets → Route → Approval

ابتدا نیاز task و policy را ثبت کنید. سپس provider/modelهای نامجاز را حذف کنید. فقط بعد از capability و lifecycle معتبر، quality floor را با eval مخصوص همان task بسنجید. latency و cost بعد از hard gateها بررسی می‌شوند. اگر Primary از دست رفت، Fallback از صفر evidence می‌خواهد و approval قبلی را به ارث نمی‌برد.

4) FACT: Vendorها یک مدل جهانی ندارند

مستندات فعلی OpenAI و Gemini چند model variant با مشخصات و trade-offهای متفاوت فهرست می‌کنند. نتیجهٔ مجاز فقط این است که provider و model_id باید ورودی صریح routing باشند. از catalog نمی‌توان یک ranking جهانی یا تضمین کیفیت برای workflow خودمان استخراج کرد.

5) FACT: Lifecycle بخشی از قابلیت عملیاتی است

Anthropic lifecycleهایی مانند Active، Legacy، Deprecated و Retired را مستند می‌کند و اعلام می‌کند request به مدل Retired شکست می‌خورد. بنابراین routeای که دیروز معتبر بوده می‌تواند امروز از نظر lifecycle نامعتبر شود. رفتار دقیق هر provider باید از منبع خودش بررسی شود.

6) قرارداد ۲۲ فیلدی Routing Matrix

هر ردیف routing باید هویت Rule و Stage، نوع task، modality/context/tooling لازم، policy data، provider/model، lifecycle، capability match، eval suite، quality floor، budgetهای latency/cost، Primary/Fallback، trigger، degraded state، approval، decision و evidence را ثبت کند.

7) Hard Gateها را قبل از Optimization اجرا کنید

اگر data_policy_class ناسازگار است یا modality/tooling لازم وجود ندارد، route همان‌جا BLOCKED می‌شود. پایین‌بودن قیمت یا latency نمی‌تواند hard constraint را جبران کند. Router خوب ابتدا eligible set می‌سازد؛ بعد بین گزینه‌های eligible مقایسه می‌کند.

8) Capability Match باید Task-specific باشد

برچسب «multimodal» یا «reasoning» به‌تنهایی کافی نیست. برای هر stage مشخص کنید چه modality، context و tooling لازم است و همان نیاز را با evidence قابل مشاهده مقایسه کنید. API call موفق فقط transport compatibility را نشان می‌دهد، نه suitability برای task.

9) Lifecycle Gate را Versioned نگه دارید

model_lifecycle_state را همراه زمان مشاهدهٔ evidence نگه دارید. Primary بازنشسته یا unavailable نباید فقط با alias جدید ادامه پیدا کند. اگر lifecycle معلوم نیست، state امن HOLD_LIFECYCLE_UNKNOWN است تا evidence به‌روز شود.

10) Quality Floor با Eval مخصوص همان Task

مدلی که latency و cost خوبی دارد اما source-faithfulness eval را رد می‌کند، برای آن stage eligible نیست. quality floor را برای throughput پایین نیاورید. missing eval هم success نیست؛ HOLD_EVAL_MISSING است.

11) Latency و Cost Budget هستند، نه یک Score جادویی

پس از عبور از policy/capability/lifecycle/eval، budgetهای latency و cost برای انتخاب عملیاتی استفاده می‌شوند. آن‌ها را با quality در یک عدد مبهم جمع نکنید. اگر budgetها trade-off دارند، rationale و stop/pivot trigger را ثبت کنید.

12) Fallback یک تصمیم جدید است

Fallback فقط به این دلیل که schema پاسخ مشابه دارد equivalent نیست. باید capability، policy، lifecycle و eval خودش را پاس کند. استفاده از fallback معتبر DEGRADED_FALLBACK_REVIEW می‌سازد و approval_requirement=REVIEW_BEFORE_RELEASE می‌شود؛ approval Primary خودکار منتقل نمی‌شود.

13) Typed Non-success Stateها را حفظ کنید

• capability ناسازگار → BLOCKED_CAPABILITY
• data policy ناسازگار → BLOCKED_DATA_POLICY
• lifecycle بازنشسته و fallback معتبر نداریم → BLOCKED_LIFECYCLE
• eval زیر quality floor → BLOCKED_QUALITY_FLOOR
• eval لازم وجود ندارد → HOLD_EVAL_MISSING
• lifecycle معلوم نیست → HOLD_LIFECYCLE_UNKNOWN
• evidence decisive ناقص است → HOLD_EVIDENCE_MISSING

14) مثال منفی: Primary retire شده، Replacement سریع و ارزان است اما Eval را رد می‌کند

اشتباه رایج این است که برای سبز نگه‌داشتن throughput، Replacement را مستقیم promote کنیم. تصمیم درست این است که quality floor ثابت بماند. اگر fallback دیگری تمام gateها را پاس کرده باشد، route به آن fallback با state DEGRADED_FALLBACK_REVIEW می‌رود؛ در غیر این صورت release باید HOLD/BLOCKED بماند.

15) Lab و Transfer: Baseline جوابِ سناریوی تغییرکرده نیست

Lab هشت fixture آفلاین و ۴۸ assertion deterministic دارد. در Transfer، Primary retire می‌شود و Replacement پیشنهادی cost/latency را پاس می‌کند ولی source-faithfulness را نه. از evidence جدید recompute کنید: nominal replacement رد می‌شود، fallback فقط با eval مستقل قابل استفاده است و هر degraded route نیازمند approval تازه است.