اگر امروز برای هر تکه کد، هزینه توکن‌های مدل‌های پیشرو را می‌پردازید، باید بدانید که دقت بالا دیگر نیازمند پرداخت مبالغ گزاف نیست. سامانه Tirtha ثابت کرد می‌توان با معماری هوشمند، کیفیت خروجی را در سطح مدل‌های برتر نگه داشت و هم‌زمان هزینه‌ها را تقریباً ۸ برابر کمتر کرد.
طبق گزارشی که ۲۸ ژوئن ۲۰۲۶ در وب‌سایت dev.to منتشر شد، این سامانه به جای تکیه مطلق بر مدل‌های گران‌قیمت برای هر وظیفه، از یک «آبشار» (Cascade) استفاده می‌کند که درخواست‌ها را بر اساس سطح اطمینان و اعتبارسنجی فیلتر می‌کند. این تغییر رویکرد در زمانی رخ می‌دهد که توسعه‌دهندگان برای ایجاد تعادل میان هزینه بالای توکن‌های مدل‌های پیشرو و قابلیت اطمینانی که برای کدهای محیط عملیاتی (Production) نیاز دارند، در تکاپو هستند. این رویکرد یادآور تلاش‌های مشابه برای بهینه‌سازی ورودی‌هاست، مشابه آنچه در سامانه Tokdiet برای کاهش ۷۱ درصدی هزینه توکن‌ها بدون افت کیفیت مشاهده شد. تصور کنید شرکتی که قبلاً برای پاسخ به هر سؤال، صرف‌نظر از میزان پیچیدگی آن، هزینه یک متخصص ارشد را می‌پرداخت؛ Tirtha این مدل را با یک برنامه‌نویس تازه‌کار جایگزین می‌کند که تنها زمانی از متخصص کمک می‌گیرد که با بن‌بستی واقعی روبرو شود.
همان‌طور که در تحلیل‌های قبلی ما درباره بهینه‌سازی هزینه‌های مدل‌های بازمتن اشاره کردیم، استراتژی کاهش هزینه بدون افت کیفیت، فعلاً اولویت اصلی صنعت است.
معماری سامانه
این سامانه عملیات را به دو کانال اصلی تقسیم می‌کند:
- کانال قابلیت (Capability Channel): یک مدل محلی ارزان‌قیمت با نام gpt-oss-120b که مسئولیت حل اولیه مسئله را بر عهده دارد.
- کانال ساختار (Structure Channel): مجموعه‌ای از گیت‌های اعتبارسنجی و حفاظ‌ها (Guards) که تعیین می‌کنند آیا پاسخ به‌دست‌آمده قابل اعتماد است یا باید درخواست به یک مدل پیشرو ارجاع داده شود.
برای بهینه‌سازی بیشتر، یک لایه حافظه موقت (Cache) در مقابل این دو کانال قرار گرفته است تا از حل مجدد مسائل کاملاً تکراری جلوگیری کند. زمانی که مدل محلی با اطمینان پاسخ دهد و حفاظ‌های لایه ساختار آن را تأیید کنند، درخواست با هزینه کم پاسخ داده می‌شود. در صورت شکست حفاظ‌ها، درخواست به مدل پیشرو ارتقا می‌یابد. بخش عمده‌ای از دشواری‌های اندازه‌گیری و رفتارهای جالب این سامانه دقیقاً در این کانال ساختار نهفته است.
عملکرد کدنویسی و سیستم امتیازدهی
نتایج در تاریخ ۲۴ ژوئن ۲۰۲۶، با استفاده از تنظیمات BENCH-DOSSIER-coding روی ۱۶۴ مسئله جمع‌آوری شد. برای تضمین صداقت در نتایج، تیم توسعه از یک روش امتیازدهی «ضد نشت» (Leak-proof) در HumanEval+ استفاده کرد. در این ساختار، تست‌های عمومی یا پایه به عنوان دروازه‌ای برای پذیرش اولیه عمل می‌کنند، در حالی که تست‌های پنهان «پلاس» (Plus tests)، امتیازدهی واقعی را بر عهده دارند. به این ترتیب، مدل هرگز تست‌هایی را که بر اساس آن‌ها مورد ارزیابی قرار می‌گیرد، نمی‌بیند.
علاوه بر این، نتایج در وضعیت PRISTINE اجرا شدند؛ به این معنا که حافظه موقت مرحله‌بندی (Staging Cache) ابتدا کاملاً پاک شد تا نرخ بازیابی صفر باشد. تحت این شرایط سخت‌گیرانه، آبشار کامل Tirtha به نتایج زیر دست یافت:
- صحت ۹۴.۵٪ در تست‌های پلاس
- صحت ۹۹.۴٪ در تست‌های پایه
- ۹۶٪ از مسائل به صورت ارزان پاسخ داده شدند
- تنها ۳.۷٪ درخواست‌ها به مدل پیشرو ارجاع یافتند
- ۰ مورد برخورد با حافظه موقت (اجرای سرد)
برای درک بهتر زمینه این نتایج، در همان تاریخ و با همان ابزار اندازه‌گیری، مدل‌های پیشرو به عنوان معیار سنجش مورد آزمایش قرار گرفتند: مدل Sonnet 4.6 صحت ۹۲.۷٪ در تست‌های پلاس، مدل Opus 4.8 صحت ۹۳.۳٪ و مدل GPT-5.3-codex صحت ۹۰.۲٪ را ثبت کردند. این نشان می‌دهد که معماری آبشاری Tirtha در این بنچمارک خاص، دقیقاً در سطح یا بالاتر از نقاط مرجع مدل‌های پیشرو قرار دارد.
اثبات بهبود قابلیت اطمینان
ادعای اصلی این است که «کانال ساختار» و نه اندازه مدل است که باعث افزایش قابلیت اطمینان می‌شود. مدل محلی پایه، زمانی که به تنهایی و از طریق OpenRouter در همان روز اجرا شد، تنها ۸۴.۸٪ در تست‌های پلاس امتیاز گرفت. معماری آبشاری این عدد را به ۹۴.۵٪ رساند، به این معنا که تقریباً ۱۰ درصد از صحت در تست‌های پلاس، مستقیماً حاصل معماری سیستم است. این چالشِ حفظ دقت در مدل‌های کوچک‌تر، مشابه سقوط ۲۸ درصدی دقت مدل‌های متوسط هنگام خروجی JSON است که نشان می‌دهد مدل‌های کوچک‌تر در مواجهه با سخت‌گیری‌های ساختاری آسیب‌پذیرترند.
برای جداسازی این اثر، تیم توسعه یک تست حذف (Ablation Test) را در ۲۷ ژوئن ۲۰۲۶ روی ناوگان داخلی خود اجرا کرد:
- سامانه کامل: ۱۰۰٪ صحت
- حذف اعتبارسنجی (Verification Removed): ۷۵٪ صحت
- حذف حفاظ‌ها (Guards Removed): ۵۰٪ صحت
مشخص شد که با حذف حفاظ‌ها، صحت خروجی عملاً نصف می‌شود. این داده‌ها شواهد داخلی جهت‌داری را فراهم می‌کند که نشان می‌دهد کانال ساختار حامل اصلی بهبود قابلیت اطمینان است، هرچند تیم توسعه اشاره کرده است که این یک تست با تعداد نمونه کم (small-n) روی یک بستر داخلی بوده و نه یک بنچمارک عمومی بلندمدت.
بهره‌وری هزینه و حافظه
نمونه‌های زنده از محیط عملیاتی در ۲۳ و ۲۴ ژوئن ۲۰۲۶ تأثیر اقتصادی این سیستم را برجسته می‌کند:
- هزینه ترکیبی (Blended Cost): ۰.۰۰۲۰۱ دلار برای هر درخواست (بر اساس ۳۱۳ درخواست در ۲۳ ژوئن)، در مقایسه با هزینه ۰.۰۱۷ دلاری هر درخواست در مدل‌های پیشرو.
- ترکیب ارائه (Serve Mix): ۹۱٪ محلی، ۹٪ ارجاع شده به مدل پیشرو و ۷٪ برخورد با حافظه موقت (بر اساس ۳۲۴ درخواست در ۲۴ ژوئن که منجر به ذخیره ۴.۷۲ دلار شد).
- سرعت بازیابی: برخورد با حافظه موقت به طور میانگین ۰.۱۶ ثانیه طول کشید که بسته به مورد، ۲۴ تا ۱۸۵ برابر سریع‌تر از حل مجدد مسئله بود و میانه آن ۷۱ برابر (n=8) ثبت شد.
در زمینه بهره‌وری کانتکست‌های طولانی، یک لایه فشرده‌سازی در ۲۶ ژوئن ۲۰۲۶ با استفاده از یک مدل محلی 7B تست شد. این لایه فشرده‌سازی تنها به ۱۶۵ توکن کانتکست نیاز داشت، در حالی که برای کانتکست کامل و خام ۲۸,۰۰۰ توکن لازم بود؛ این یعنی اشغال فضای حافظه تنها ۰.۶٪ بود. در یک بنچمارک بازیابی اطلاعات چندگامی (multi-hop context-rot)، مدل 7B تا ۲۸ هزار توکن، صحت ۱۰۰ درصدی خود را حفظ کرد. این تلاش‌ها برای افزایش سرعت و بهینه‌سازی استنتاج، در راستای مسیرهای توسعه‌ای است که DeepSeek نیز با استفاده از پیش‌نویس‌های موازی برای کاهش تأخیر استنتاج V4 دنبال کرده است.
مرزهای کانتکست طولانی
یک پروب NIAH چندگامی تک-پرومپتی (۳ گام در ۲ تکرار، n=6) که در ۲۸ ژوئن ۲۰۲۶ انجام شد، نشان داد که سیستم تا ۲۰۸ هزار توکن کاملاً پاک و با صحت ۱۰۰٪ عمل می‌کند. اما در ۲۱۶ هزار توکن و بالاتر، سیستم با یک سقف سخت HTTP-500 مواجه شد.
تیم توسعه تصریح کرد که این یک محدودیت پیکربندی شده در زیرساخت است که می‌توان آن را افزایش داد، و نه یک سقوط در کیفیت یا محدودیت مربوط به پنجره متنی مدل ۲۶۲ هزار توکنی. از آنجایی که سیستم به جای تزریق توکن‌های خام از لایه فشرده‌سازی/حافظه استفاده می‌کند، این آزمایش در واقع کفِ لوله‌کشی زیرساختی را نشان می‌دهد، نه تست مسیر عملیاتی واقعی را.
شکاف‌های صادقانه و داده‌های در انتظار
علیرغم این نتایج، بنچمارک‌های رسمی بلندمدت طراحی شده‌اند اما هنوز اجرا نشده‌اند. اگرچه ابزارهای اجرای RULER، LongMemEval، faithfulness و SWE-bench ادغام شده‌اند، اما به دلیل اینکه Sandbox نمی‌تواند Docker را کلون یا اجرا کند، روی یک ماشین پاک اجرا نشده‌اند.
در نتیجه، در حال حاضر اعداد رسمی برای RULER، SWE-bench یا LongMemEval وجود ندارد. LongMemEval به ویژه حیاتی است زیرا تست واقعی برای اثبات مزیت لایه‌ی فشرده‌سازی در طول نشست‌های مختلف با بیش از ۲۰۰ هزار توکن است. سایر شکاف‌ها شامل حجم کم نمونه‌ها در تست‌های حذف و احتمال آلودگی داده‌های آموزشی (Training Contamination) است، زیرا مسائل HumanEval+ به صورت عمومی در دسترس هستند.
این نتیجه، این فرض را که برای دستیابی به قابلیت اطمینان بالا حتماً به یک مدل عظیم نیاز است، تغییر می‌دهد. این امر نشان می‌دهد که «هوش» یک سامانه می‌تواند به جای وزن‌های مدل که کار را انجام می‌دهند، به گیت‌های معماری که کار را تأیید می‌کنند، منتقل شود.
برای مخاطب، این بدان معناست که هوش مصنوعی در محیط عملیاتی می‌تواند از حالت «گران و دقیق» یا «ارزان و نامطمئن» به یک مدل ترکیبی منتقل شود که به صورت پیش‌فرض هم ارزان و هم دقیق است. پس از رفع مشکلات Docker در Sandbox، تیم قصد دارد اعداد مربوط به بنچمارک‌های بلندمدت را با ذکر تاریخ‌های دقیق و تعداد نمونه‌ها منتشر کند.
گام بعدی شما
- اگر از مدل‌های گران‌قیمت برای کارهای تکراری کدنویسی استفاده می‌کنید، معماری Cascade را برای تفکیک درخواست‌ها بررسی کنید.
- لایه‌های اعتبارسنجی (Verification) را به جای افزایش اندازه مدل، به عنوان اولویت توسعه در نظر بگیرید.
- برای مدیریت کانتکست‌های حجیم، به جای تزریق مستقیم توکن‌ها، از لایه‌های فشرده‌سازی (Compaction) استفاده کنید.
اما تأثیر این معماری بر مصرف حافظه VRAM در مقیاس صنعتی حتی پیچیده‌تر است — به تحلیل ما درباره بهینه‌سازی‌های KV Cache مراجعه کنید.
گفتگو