آمار ترافیکی هر سرویس LLM واقعی یک پترن تکرارشونده دارد: بخش بزرگی از درخواست‌ها ساده‌اند — بازنویسی یک جمله، دسته‌بندی، جواب کوتاه، فرمت‌کردن داده — و بخش کوچکی واقعاً سخت. اما اگر همه‌ی ترافیک به مدل بزرگ برود، برای پرسش‌های ساده هم قیمت کامل می‌پردازید و تأخیر کامل می‌گیرید. راه‌حل، افزودن یک لایه‌ی تصمیم به خود سیستم است: مسیریاب و آبشار. ایده این است که هر پرسش به ارزان‌ترین مدلی برود که «کافی» است — و تشخیص کفایت، خودش یک مسئله‌ی مهندسی است.
آبشار چیست؟
معماری آبشار ساده‌ترین شکل این ایده است: پرسش اول به مدل ارزان می‌رود؛ به پاسخ اعتماد سنجیده می‌شود؛ اگر اعتماد کافی بود همان جواب برگردد، وگرنه پرسش با همه‌ی زمینه به مدل گران‌تر ارجاع می‌شود. فرقش با انتخاب ثابت مدل، همین مرحله‌ی سنجش است — و همه‌ی چالش آبشار هم در همین سنجش جمع شده است: مدل کوچک هیچ‌وقت نمی‌گوید «جواب من شاید غلط است». پس باید از نشانه‌های غیرمستقیم اعتماد استفاده کرد.
مسیریاب چطور تصمیم می‌گیرد؟
سه رویکرد رایج، از ساده به پیچیده: قاعده‌ای — طول پرسش، وجود کلمات کلیدی سخت («تحلیل کن»، «ریاضی»، «کد»)، نوع وظیفه از فراخوانی تابع؛ سریع و قابل‌فهم، اما خشن. طبقه‌بند کوچک — یک مدل بسیار کوچک یا embedding که آموزش دیده است دشواری/نوع پرسش را پیش‌بینی کند؛ دقیق‌تر از قاعده و ارزان‌تر از هر LLM. مبتنی بر خود پاسخ — امتیاز اطمینان مدل کوچک (مثلاً فاصله‌ی توزیع توکن‌ها)، یا اجرای پاسخ کوتاه و سریع و سنجش سازگاری. معمول‌ترین ترکیب واقعی: قاعده‌های سخت برای موارد آشکار + طبقه‌بند برای وسط‌ها.
سنجش اعتماد: قلب ماجرا
خطر اصلی آبشار، اعتماد کاذب است: مدل کوچک با اطمینان کامل جواب غلط می‌دهد و مسیریاب رد می‌کند. سه راه مقابله: پرسش‌های کنترل — هر از گاهی پرسش‌هایی با جواب شناخته‌شده به همان مسیر بفرستید و نرخ خطای واقعی هر مدل در هر کلاس وظیفه را نگه دارید؛ این عددها آستانه‌های مسیریاب را تغذیه می‌کنند. سازگاری — برای وظایف مهم، دو بار با دما بالا بپرسید؛ ناهم‌خوانی یعنی ارجاع به مدل بزرگ. تفکیک کلاس وظیفه — اعتماد را عمومی نسازید؛ مدل کوچک در خلاصه‌سازی قابل‌اعتماد و در استدلال حقوقی نیست؛ آستانه را به‌ازای هر کلاس بگذارید. و همیشه یک شیر اطمینان بگذارید: مسیر علامت‌گذاری‌شده برای «الان مطمئن نیستم» که کاربر یا لاگ آن را ببیند، نه جوابِ خامِ مشکوک.
مسیریابی هوشمند یعنی پول را فقط همان‌جا خرج کنید که پرسش واقعاً سخت است — و تشخیص «سختی» هم یک مدل می‌خواهد.
حساب اقتصادی
یک مثال فرضی ولی واقع‌نما: اگر ۷۰٪ ترافیک شما پرسش‌های سبکی باشد که مدل کوچک با هزینه‌ی یک‌دهم جوابشان می‌دهد، هزینه‌ی کل تقریباً به ۳۰٪ + ۷٪ ≈ ۳۷٪ سقوط می‌کند — یعنی حدود دو‌سوم صرفه‌جویی، در عوضِ هزینه‌ی یک طبقه‌بند کوچک. به این اضافه کنید تأخیر کمتر برای اکثریت کاربران و ظرفیت آزادشده‌ی مدل بزرگ برای پرسش‌های واقعاً سخت. فهرست کامل هزینه‌ی سناریوها را در راهنمای هزینه‌ی API ببینید. البته هزینه‌ی پنهان هم دارد: دو مسیر یعنی دو رفتار، دو لاگ، دو مجموعه‌ی ارزیابی — پیچیدگی عملیاتی را جدی بگیرید.
کجا جواب نمی‌دهد؟
سه حالت که آبشار ارزشش را از دست می‌دهد: وظایف یکدستِ سخت — اگر همه‌ی ترافیک شما تحلیل پیچیده است، مسیریاب فقط تأخیر اضافه می‌کند؛ مستقیم بروید سراغ مدل بزرگ. حساسیت حیاتی — وقتی هر پاسخ غلط هزینه‌ی بالایی دارد، سنجش اعتماد آن‌قدر سختگیر می‌شود که عملاً همه‌چیز ارجاع می‌خورد؛ لایه‌ی مسیریاب وسط‌چین بی‌معناست. و ترافیک کم — با چند صد درخواست در روز، حساب کتاب صرفه‌جویی ممکن است به پیچیدگی نگهداری نرسد. قاعده‌ی تصمیم را در چارچوب بزرگ‌تر راهنمای انتخاب مدل ببینید.
جمع‌بندی
آبشار و مسیریاب همان جایی‌اند که مدل‌های کوچک بیشترین ارزش اقتصادی را می‌سازند: نه جایگزین مدل بزرگ، بلکه نگهبان دروازه‌اش. شروع عملی: ترافیک واقعی‌تان را یک هفته برچسب بزنید (ساده/متوسط/سخت)، نسبت‌ها را ببینید، برای کلاس ساده مدل کوچک را با آستانه‌های سختگیرانه آزمایشی بگذارید و با پرسش‌های کنترل، نرخ خطا را هفته‌ای یک‌بار چک کنید. عدد واقعی، بهترین طراح مسیریاب است. برای تست رفتار مدل‌های کوچک و بزرگ روی پرسش‌های خودتان، یک حساب بسازید.