تصور کنید یک عامل صوتی با دقت خیرهکننده و تأخیر بسیار پایین ساختهاید، اما به محض اینکه اولین مشتری واقعی پشت خط میرود، کل سیستم شما فرو میپاشد. این دقیقا اتفاقی است که برای یک شرکت مدیریت ثروت افتاد و ثابت کرد که تفاوت بین یک «دموی جذاب» و یک «محصول تجاری»، در جزئیات زیرساختی نهفته است.
طبق گزارشی در dev.to که در ۲ ژوئیه ۲۰۲۶ منتشر شد، این سیستم علیرغم داشتن پایداری ۹۹.۲ درصدی در محیط تست (Staging)، پوشش ارزیابی (Eval Coverage) روی ۱,۴۰۰ نوبت گفتگو (Test Turns) و تأخیر کمتر از ۲۸۰ میلیثانیه در تولید نخستین توکن، در اولین مرحلهی پایلوت شکست خورد. این چالشها یادآور تجربیاتی است که در بررسی نرخ خرابی عاملهای صوتی بازمتن مشاهده کردیم، جایی که مدیریت نادرست وابستگیها میتواند منجر به توقفات گسترده شود. تیم توسعه شش هفته را صرف آزمایش با «پرسوناهای مصنوعی» (Synthetic Personas) کرده بود و نتایج شبیهسازی کاملاً پاک و بینقص بود، اما با این حال، سیستم «آمادهی بهرهبرداری» (Operator-ready) نبود. مشکل از «کندی» یا «حماقت» مدل نبود، بلکه زیرساخت اطراف مدل فاقد یک لایهی گیتوی (Gateway) — شبیه به یک افسر پلیس ترافیکی که اجازه میدهد خودروها منظم وارد اتوبان شوند تا تصادف رخ ندهد — بود.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، بسیاری از توسعهدهندگان گیتوی را صرفاً یک مسیریاب ساده میبینند که درخواست را به OpenAI یا Anthropic میفرستد، عملیات تکرار (Retry) را مدیریت میکند و کار را تمام میکند. اما در محیطهای حرفهای سازمانی، این رویکرد یک شکاف حاکمیتی عظیم ایجاد میکند. وقتی سیستم از محیط تست و شبیهسازی به دست مشاوران واقعی و مشتریان سطح بالا (High-net-worth clients) میرسد، اولویتها به شدت تغییر میکنند و تمرکز از «صحت مدل» به «قابلیت اطمینان عملیاتی» منتقل میشود.
کالبدشکافی یک شکست عملیاتی
این شکست در سه هفتهی اول پایلوت در چهار مرحلهی متمایز رخ داد. در روز اول، یک مشاور ارشد جلسهای را اجرا کرد که شامل سه پرسوجوی متوالی دربارهی تخصیص دارایی (Allocation queries) با مقادیر پرتفوی بسیار بزرگ بود. این حجم از داده و درخواست، باعث فعال شدن محدودیت نرخ (Rate Limit) در OpenAI درست در ساعت ۶ عصر (به وقت EST) شد؛ یعنی دقیقاً در پیک مصرف مشاوران. چون سیستم فاقد محدودیت نرخ بهتفکیک هر مستاجر (Per-tenant limits) بود، هر درخواستی که پس از رسیدن به سقف ارسال میشد، با خطای ۴۲۹ مواجه میگشت و عامل صوتی هیچ دلیل مفیدی را در لاگها ثبت نمیکرد. نتیجه این شد که یک مشتری واقعی چهار دقیقه در حالت انتظار ماند. در این نقطه، داشتن مکانیزمهای بازیابی حیاتی است، چرا که بسیاری از شکستهای API در عاملهای هوش مصنوعی با پیادهسازی متدهای خودترمیمی قابل جبران هستند.
در روز دوم، شرکت با یک بحران انطباق (Compliance crisis) مواجه شد. یک افسر رعایت قوانین سعی کرد گزارش بازرسی (Audit Log) مربوط به حادثهی روز اول را استخراج کند، اما دریافت که هیچ گزارشی وجود ندارد. در حالی که تیم توسعه آثار ردپای درخواستها (Trace Spans) را داشت، اما فاقد یک لاگ بهازای هر درخواست بود که نشان دهد کدام مشاور درگیر بوده است، بستر مشتری (Client context) چه بوده، کدام ابزارها (Tool calls) فراخوانی شدهاند و عامل در نهایت چه پاسخی داده است. این مورد به عنوان یک «شکاف انطباق» شناسایی شد، نه یک شکاف ساده در مانیتورینگ.
در هفته دوم، بخش تجاری شرکت درخواست تفکیک هزینهها (Cost attribution) را مطرح کرد. معاون عملیات میخواست تجزیه و تحلیل هزینهها را بهتفکیک هر تیم و هر مشاور ببیند. تیم فنی در کمال ناتوانی تنها میتوانست یک عدد کلی از کل هزینهها ارائه دهد، زیرا هیچ سیستم برچسبگذاری (Tagging) بهتفکیک مستاجر در زیرساخت تعبیه نشده بود. این عدم کنترل بر هزینهها در مقیاس تجاری، دقیقاً همان نقطهای است که در پروژههایی مانند سیستم XOra با تمرکز بر حذف تأخیر و بهینهسازی هزینهها سعی در حل آن شد.
در هفته سوم، یک بهروزرسانی در پرامپت که هدف آن اصلاح لحن (Tone issue) مدل بود، باعث یک شکست جدید شد. سه ساعت پس از انتشار (Push) این تغییر، عامل صوتی شروع به رد کردن برخی پرسشهای تخصصی تخصیص دارایی کرد که پیش از آن به درستی پاسخ میداد. چون تیم نسخههای پرامپت را در زمان استنتاج (Inference) — یعنی لحظهای که مدل واقعاً جواب تولید میکند، شبیه به خودِ آشپزی و نه دورهی آموزش آشپز — در Traceها تثبیت (Pin) نکرده بود، نتوانستند شناسایی کنند که شکست از چه زمانی شروع شده است یا دقیقاً کدام درخواستها تحت تأثیر این تغییر قرار گرفتهاند.
معماری یک گیتوی آمادهی بهرهبرداری
بر اساس تحلیل نویسندهی این گزارش، یک گیتوی «آمادهی عملیات» برای زنده ماندن در یک محیط تحت نظارت (Regulated environment)، باید پنج وظیفهی حیاتی را ایفا کند:
- محدودیت نرخ بهتفکیک مستاجر (Per-Tenant Rate Limiting): این محدودیت باید برای هر مستاجر/کاربر باشد، نه فقط برای کل حساب کاربری API. یک مشاور با مصرف بسیار زیاد نباید بتواند سقف نرخ را برای کل استقرار سازمان-بندی کند و دسترسی دیگران را قطع کند.
- تفکیک هزینه (Cost Attribution): هر درخواست باید با برچسب اپراتور، تیم و کاربر علامتگذاری شود. بدون این قابلیت، پاسخ به سوالات مالی (FinOps) در ماه دوم بهرهبرداری غیرممکن است.
- اجرای حفاظها (Guardrail Enforcement): در خدمات مالی، سیستم باید تضمین کند هیچ پاسخی شبیه به یک «توصیهی سرمایهگذاری مشخص» نباشد. حفاظها — مثل نردههای ایمنی کنار پل — باید روی هر پاسخ بهطور خودکار و سیستمی اجرا شوند.
- ثبت گزارش تغییرناپذیر (Immutable Audit Logging): این یک الزام قانونی و انطباقی است، نه یک قابلیت اختیاری. لاگها باید تغییرناپذیر، بهازای هر درخواست و حاوی جزئیات کافی برای بازپخش (Replay) تعامل باشند.
- جابجایی خودکار بین ارائهدهندگان (Automatic Multi-Provider Failover): وقتی OpenAI خطای ۴۲۹ (محدودیت نرخ) میدهد، سیستم باید فوراً و بدون دخالت دستی انسان، درخواست را به Anthropic ارجاع دهد. این قابلیت میتوانست از قطعی چهار دقیقهای روز اول جلوگیری کند.
بررسی ابزارهای موجود در بازار
تیم توسعه پس از هفته اول، یک آخر هفته کامل را صرف ارزیابی گزینههای گیتوی برای رفع این شکافها در میانه دوره پایلوت کرد. آنها در نهایت Portkey را انتخاب کردند؛ زیرا تحت فشار زمانی بودند و به حفاظهای بدون نیاز به پیکربندی (Zero-config guardrails)، سیستم نسخهبندی پرامپت داخلی با رابط کاربری برای بازگشت (Rollback)، و راهاندازی سریع برای کاهش هزینههای عملیاتی نیاز داشتند.
سایر گزینههای ارزیابی شده عبارت بودند از:
- LiteLLM (متنباز و Self-hosted): کاملترین مجموعه ویژگیها را برای کسانی که کنترل مطلق میخواهند ارائه میدهد، از جمله محدودیت نرخ بهتفکیک مستاجر و Fallback ارائهدهندگان. با این حال، نیاز به مدیریت استقرار، پیکربندی Redis برای پایداری محدودیت نرخ و نوشتن یک اسکیمای سفارشی برای Audit Log دارد. این ابزار برای تیمهایی با زیرساخت موجود Kubernetes انتخابی قدرمند است.
- Future AGI's Gateway (متنباز): بخشی از پشتهی کامل (Stack) ارزیابی، مشاهدهپذیری و حفاظهای FAGI است. تا ژوئن ۲۰۲۶، این ابزار یک پروکسی سازگار با OpenAI، مسیریابی چند-ارائهدهندهای و Tracing بومی OTel را ارائه میدهد. برای تیمهایی که از ابزارهای شبیهسازی FAGI برای ارزیابی صوتی استفاده میکنند بسیار جذاب است، زیرا حفاظها و سیگنالهای ارزیابی را یکپارچه میکند. اما برای کسانی که از FAGI استفاده نمیکنند، هزینه راهاندازی آن بیشتر از Portkey یا Helicone است.
- Helicone (مدیریتی/Managed): قویترین گزینه برای تفکیک هزینه و تحلیلهای بهازای هر کاربر به دلیل سیستم برچسبگذاری دانهریز و داشبورد خواناست، اما در بخش پیکربندی حفاظها ضعیفتر است.
- OpenRouter (مدیریتی/Managed): برای مسیریابی خالص و بهینهسازی تأخیر بین ارائهدهندگان عالی است، اما فاقد محدودیت نرخ بهتفکیک مستاجر و اجرای حفاظهای داخلی مورد نیاز برای انطباق سازمانی است.
- Bifrost (متنباز): یک پروکسی سریع با اعداد عملکردی خیرهکننده است. اگرچه سرعت آن واقعی است، اما برای استقرار در یک صنعت تحت نظارت (مانند مالی)، بیش از حد نوپا تشخیص داده شد.
مسیر رسیدن به آمادگی
در پایان هفته سوم، تیم معماری خود را تغییر داد. آنها Portkey را برای مدیریت نرخ و اجرای حفاظها مستقر کردند، برچسبگذاری بهازای هر مشاور را به هر درخواست افزودند و تثبیت نسخهی پرامپت را در زمان استنتاج پیادهسازی کردند و شناسهی نسخه (Version ID) را در هر Trace Span ثبت نمودند.
این تغییرات عملیات آنها را متحول کرد: حادثهی مربوط به نسخهی پرامپت اکنون فوراً شناسایی میشد و سوالات تفکیک هزینه با دو کوئری SQL ساده پاسخ داده میشد. برای مدیریت سختگیرانهترین الزامات خدمات مالی در مورد تغییرناپذیری و نگهداری لاگها، آنها یک لایهی نازک «فقط-نوشتنی» (Write-once layer) روی سیستم گزارشدهی Portkey ساختند. این کار دو روز زمان برد که نویسنده اشاره میکند باید پیش از شروع پایلوت انجام میشد.
درس اصلی این است که کیفیت مدل بهندرت عامل اصلی شکست در هوش مصنوعی سازمانی است. در واقع «زیرساخت اطراف مدل» — بهویژه گیتوی — است که تعیین میکند یک سیستم واقعاً آمادهی بهرهبرداری است یا خیر. نویسنده پیشنهاد میکند یک چکلیست «آمادگی عملیاتی» بهعنوان یک گیت CI (کنترل کیفیت خودکار) پیش از هرگونه تحویل سازمانی اجرا شود تا محدودیتهای نرخ بهتفکیک مستاجر، اسکیمای گزارش بازرسی و ردیابی نسخهی پرامپت تأیید شود.
برای کسانی که در بخشهای تحت نظارت فعالیت میکنند، هدف پاسخ به چهار سوال است: چه کسی، چقدر هزینه کرد، چه زمانی، چه کاری انجام داد و نتیجه چه بود؟ اگر گیتوی شما نمیتواند به این چهار سوال پاسخ دهد، شما آمادهی تحویل به سازمان نیستید.
گام بعدی شما
- اگر در حال استقرار عاملهای AI هستید، بررسی کنید آیا سیستم شما میتواند خطای ۴۲۹ یک ارائهدهنده را با جابجایی خودکار به مدل دیگر جبران کند یا خیر.
- یک سیستم ثبت گزارش (Audit Log) بسازید که بهتفکیک Request ID، نسخهی پرامپت و شناسه کاربر باشد.
- برای هر کاربر یا تیم، سقف مصرف (Quota) مجزا تعریف کنید تا از توقف کل سرویس جلوگیری شود.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو