تصور کنید یک پلتفرم آموزشی دارید که باید برای هزاران کاربر، از یادگیری زبان گرفته تا آمادگی آزمونهای سخت هند، پاسخهای دقیق بدهد، اما هر بار که مدل هوش مصنوعی در ساعت ۲ بامداد دچار اختلال شود، کل سیستم شما متوقف شود. تفاوت یک نمونه اولیه (Prototype) با یک محصول واقعی، در همان لولهکشیهای خستهکنندهای است که تعیین میکنند وقتی یک پرامپت شکست میخورد، چه اتفاقی بیفتد.
توسعهدهندگان Vararuchi به نقل از گزارش dev.to اعلام کردند که انتقال از کتابخانههای سادهی پرامپت به یک «رجیستری ویژگیها» (Feature Registry)، تنها راه متوقف کردن شکستهای بحرانی و نشت هزینههای استنتاج بود. در حال حاضر، یک لایه مسیریابی (Routing) متمرکز، بیش از ۶۰ قابلیت مبتنی بر هوش مصنوعی را در پنج حالت یادگیری مختلف مدیریت میکند.
اکثر مدرسهای هوش مصنوعی تنها پنجرههای چتی هستند که پرامپتهای پیچیدهای دارند. اما Vararuchi با روش متفاوتی عمل میکند؛ این پلتفرم با حفظ وضعیت بلندمدت (Long-term State) کاربر، میداند که کاربر چه مفاهیمی را یاد گرفته و بر اساس آن سطح دشواری را تطبیق میدهد. این سیستم در دامنههای متنوعی فعال است: از آموزش عمومی و آمادگی آزمونهای رقابتی هند مانند JEE، NEET و UPSC (که هر یک سرفصلهای رسمی و قوانین خاص نمره منفی دارند)، تا یادگیری زبان بر اساس استانداردهای CEFR از سطح A0 تا C1، کوچینگ شغلی با مصاحبههای شبیهسازی شده و حتی یک حالت «آرنا» (Arena) برای رقابت کاربران.
همانطور که در تحلیلهای پیشین ما دربارهی مدیریت هزینههای مدلهای زبانی اشاره کردیم، مقیاسپذیری در این سطح، یک چالش مهندسی عظیم است. مسئله اصلی این نیست که آیا یک مدل زبانی بزرگ (LLM) — شبیه کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — میتواند فتوسنتز را توضیح دهد یا نه، بلکه مسئله این است که ۶۰ ویژگی مختلف با تضادهای هزینه و کیفیت را در شرایط بحرانی چگونه مدیریت کرد. این رویکرد برای جلوگیری از توقف کامل سیستم حیاتی است؛ چرا که اتکای مطلق به یک مدل واحد میتواند در صورت بروز اختلال، کل زنجیره عملیاتی را با شکست مواجه کند. تیم توسعهدهنده در گزارش خود اشاره کردند که پیش از این، فراخوانهای مدلها به صورت پراکنده بود و منطق تلاش مجدد (Retry Logic) و «بودجه تفکر» (Thinking Budget) متفاوتی داشتند که در نهایت منجر به ایجاد یک فایل رجیستری واحد شد.
رجیستری ویژگیها
طبق مستندات این تیم، هر قابلیت اکنون به صورت یک خط کد در رجیستری تعریف شده است (مثلاً chat_message یا generate_quiz یا km_build_concepts). این رجیستری سه مورد حیاتی را به طور صریح تعیین میکند:
- قیمت و هزینه: بررسیهای دقیق هزینهای (Cost Audit) نشان داد که «توکنهای تفکر» (Thinking Tokens) که با نرخ خروجی محاسبه میشوند، بزرگترین منبع نشت هزینه در سیستم بودند.
- زنجیره مدلها: تعریف یک مدل اصلی و مدلهای جایگزین (Fallback) مشخص برای هر ویژگی.
- پیکربندی تولید: تنظیماتی خاص مانند فعال بودن استریم (
stream: true) یا مدت زمان کش (cacheTtlMs)؛ به عنوان مثال، برای کوییزها مقدار ۳۰ دقیقه تنظیم شده است.
مکانیزم مسیریابی و کنترل خطا
این سیستم از استراتژی لایهای با استفاده از مدلهای Gemini 2.5 Flash، Pro و Lite بهره میبرد. روتر (Router) سیستم، شکستها را با منطق زیر مدیریت میکند:
- ویژگیهای مبتنی بر Lite: اگر مدل Lite دچار مشکل شود، سیستم به مدل Flash با همان قیمت منتقل میشود؛ در اینجا در دسترس بودن سرویس بر حاشیه سود اولویت دارد.
- ویژگیهای مبتنی بر Flash: در صورت خطا، سیستم به مدل Lite با همان قیمت سقوط میکند؛ چرا که یک پاسخ با کیفیت پایینتر (Degraded Answer)، بهتر از نمایش صفحه خطا برای کاربر است.
- محتوای چندوجهی (Multimodal): برای تصاویر، PDFها و ویدیوها هیچ مدل جایگزینی تعریف نشده است. دلیل این تصمیم این است که کیفیت مدلهای کوچکتر در تحلیل بصری تأییدنشده است، بنابراین سیستم ترجیح میدهد «بلند شکست بخورد» (Fail Loud) و به جای بازگرداندن نتایج بیکیفیت یا غلط، بهطور خودکار مبلغ کاربر را مسترد کند.
برای بهینهسازی بیشتر، روتر بهگونهای طراحی شده که اگر مدل ارزانتری در زنجیره بتواند پاسخ را تولید کند، تفاوت قیمت را بهطور خودکار به کاربر بازمیگرداند. همچنین کشینگ (Caching) بهشدت کنترل شده و تنها از طریق یک «لیست سفید» (Allowlist) برای تولیدکنندگان قطعی (Deterministic) مانند کوییزها، مرورها و سرفصلها فعال است، در حالی که چتهای شخصیسازی شده هرگز کش نمیشوند. علاوه بر این، یک دیوار پرداخت (Paywall) در سمت کلاینت، نسخهای دقیق از قیمتها را نگه میدارد و هرگونه تضاد در قیمتها منجر به شکست در فرآیند CI میشود.
اصلاح «قراردادهای نامرئی»
تیم Vararuchi متوجه یک باگ بحرانی شدند: امتیاز «تسلط» (Mastery) کاربران با وجود استفاده فعال از پلتفرم، روی ۰٪ باقی میماند. تحلیلها نشان داد که مسیر ثبت پیشرفت (Write-back path) به این وابسته بود که کاربران کلمات کلیدی مخفی مانند «quiz» یا «check» را در چت تایپ کنند. این بدان معنا بود که حالتهای «تمرین» (Practice) و «مرور» (Review) — که در واقع سطوحی بودند که برای یادگیری طراحی شده بودند — هیچ مسیر بازگشتی برای ثبت دادهها نداشتند؛ یعنی رابط کاربری عملیات را انجام میداد اما نتایج را دور میریخت.
آنها این مشکل را با پیادهسازی یک موتور مشترک برای masteryRules و pathProgress حل کردند. بهجای تکیه بر محرکهای مستند نشده، یک دکمه صریح با عنوان «بررسی درک من» (Check my understanding) اضافه کردند تا حلقه بازخورد برای کاربر کاملاً قابل مشاهده و شفاف باشد.
بهبود تابآوری کاربر
توسعهدهندگان همچنین شیوه مدیریت خطاها را تغییر دادند. آنها از روش بلعیدن خطاها با console.error(e) و رندر کردن مقدار null دست کشیدند، زیرا این کار باعث ایجاد صفحات خالی میشد که از دید کاربر تفاوتی با کراش کامل اپلیکیشن نداشت. اکنون هر نقطه فراخوانی AI از یک مؤلفه وضعیت خطای مشترک استفاده میکند که کاربر را از بروز مشکل مطلع کرده و مسیر تلاش مجدد (Retry) را فراهم میکند؛ بدین ترتیب، تجربه کاربر از «اپلیکیشن خراب است» به «اپلیکیشن با یک مشکل کوچک مواجه شد» تغییر کرد.
برای کسانی که در حال بررسی استکهای فنی خود هستند، جالب است بدانند Vararuchi اکنون در هر تغییر، ۶۹۳ تست را روی ۶۳ فایل اجرا میکند و از React 19 و بکانند Firebase/Firestore روی Cloud Run استفاده میکند. این نظم در ساختار کد و تستها نشان میدهد که یکپارچگی الگوهای کدنویسی چگونه میتواند به یک مزیت رقابتی در توسعه محصولات هوش مصنوعی تبدیل شود. این پلتفرم در حال حاضر در آدرس vararuchi.com فعال است.
گام بعدی شما
- اگر محصول هوش مصنوعی توسعه میدهید، ابتدا تمام حالتهای شکست (Failure Modes) خود را نقشهبرداری کنید. تفاوت یک پروتتایپ و یک محصول در مدیریت این شکستهاست.
- برای کاهش هزینهها، زنجیرهای از مدلهای سنگین به سبک (Lite/Flash) را برای قابلیتهای غیربحرانی تعریف کنید.
- به جای تکیه بر پرامپتهای سیستمی طولانی، منطق کسبوکار را در یک لایه رجیستری خارج از مدل پیادهسازی کنید.
اما تأثیر معماریهای مشابه در کاهش تأخیر استنتاج حتی چشمگیرتر است — به بررسی ما درباره بهینهسازی KV Cache مراجعه کنید.
گفتگو