۹۷۰۰ دلار هزینهٔ محاسباتی هدررفته در سه هفته؛ این بهای یک باگ ساده در مسیر بازپرداخت مالیات بر ارزش افزوده (VAT) در اوایل سال ۲۰۲۴ برای شرکت GlobalCart بود. این شکست، حقیقتی تلخ در محیط عملیاتی را برملا میکند: عاملهای هوش مصنوعی (AI Agents) اغلب میان ابزارهای مختلف نوسان میکنند بدون آنکه هرگز هشدار خطا صادر کنند و همین «حلقههای خاموش» باعث خونریزی مالی شرکتها میشود.
بسیاری از دموهای عاملهای هوش مصنوعی بر توانایی استفاده از ابزارها تمرکز دارند، اما در دنیای واقعی، تریاژ پشتیبانی هستهٔ اصلی منطق کسبوکار است. برای GlobalCart، چالش اصلی تنها فراخوانی یک API نیست، بلکه رعایت توافقنامههای سطح خدمات (SLA) و حفظ ردپای حسابرسی است، بدون آنکه یک تیکت ساده به صورتحساب ۲۰۰ دلاری API تبدیل شود. این تغییر رویکرد از «پرامپتنویسی» به «مسیریابی»، مرز شکست یا پیروزی عاملهای عملیاتی است. این رویکرد بهینهسازی مسیرها مشابه راهکاری است که در ادغام NeMo Switchyard و Kong برای کاهش هزینههای استنتاج مشاهده کردیم.
به گزارش وبسایت dev.to در ۲۲ اوت ۲۰۲۶، این شرکت از یک گراف تصمیمگیری شاخهای برای مدیریت تیکتها استفاده میکند. این سامانه برای موارد رایج، کد قطعی (Deterministic) را اولویت میدهد و تنها در شاخههای مبهم است که از مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — کمک میگیرد.
همانطور که در بحثهای گذشتهی ما دربارهی امنیت و پایداری مدلهای بازمتن اشاره کردیم، تکیه مطلق بر استدلال مدل در مقیاس تولید، ریسکهای پیشبینیناپذیری دارد.
مسیریابی در اینجا صرفاً یک «کد چسب» نیست، بلکه یک فرآیند ساختاریافته است. تابع route_ticket ابتدا قوانین سختافزاری را بررسی میکند. برای مثال، اگر نوع تیکت «بازپرداخت» و وضعیت سفارش «تحویل شده» باشد، سامانه بلافاصله تابع initiate_refund را فراخوانی میکند. به همین ترتیب، درخواستهای «لغو سفارش» برای کالاهایی که هنوز ارسال نشدهاند، بدون دخالت LLM، مستقیماً به تابع cancel_order هدایت میشوند.
زمانی که تیکت وارد یک مورد استثنایی (Edge Case) میشود، سامانه یک پرامپت تریاژ برای LLM میسازد. سپس عامل تصمیم میگیرد که آیا تیکت را به اپراتور انسانی ارجاع دهد یا ابزاری خاص را فراخوانی کند. اگر هیچکدام رخ ندهد، تیکت به عنوان «حلنشده» ثبت و بهطور پیشفرض ارجاع داده میشود تا از ناپدید شدن آن جلوگیری شود.
بر اساس بررسی صورتحسابهای OpenAI و Azure در اوایل سال ۲۰۲۴، تفاوت قیمت بر اساس مسیر حل تیکت در GlobalCart تکاندهنده است:
- مسیر قطعی (Happy Path): هزینهای بین ۰.۰۰۴ تا ۰.۰۱ دلار برای هر تیکت. یک فراخوانی ساده برای لغو سفارش حدود ۰.۰۰۶ دلار هزینه دارد.
- تکمرحلهای LLM: هزینهای بین ۰.۰۱۴ تا ۰.۰۴ دلار. یک پرامپت تریاژ معمولی با ۷۵۰ توکن (Token) — تکههای کوچکی از متن شبیه برشهای کیک که مدل میخورد — حدود ۰.۰۱۸ دلار هزینه دارد.
- ارجاع انسانی (بدون حلقه): ۲.۱۳ تا ۲.۱۶ دلار، که عمدتاً مربوط به هزینه جهانی اپراتور انسانی است.
- حلقه + ارجاع انسانی: میتواند به ۲.۲۸ تا ۵.۵۰ دلار برای هر تیکت برسد. یک حلقه بدون حفاظ از ۱۰ پرامپت تریاژ، پیش از ارجاع انسانی، ۰.۱۸ دلار هزینه اضافه میکند.
یک مورد خاص (تیکت شماره ۶۷۲۱۲۸) منجر به ۲۷ فراخوانی LLM شد بدون آنکه به سقف تلاش مجدد برسد و در نهایت ۵.۱۷ دلار برای یک تعامل ساده هزینه داشت. عامل صرفاً بین دو ابزار order_lookup و clarify_status در نوسان بود.
برای مقابله با این وضعیت، GlobalCart یک ماژول حفاظ (Guardrails) پیاده کرد که پاسخهای LLM را با مجموعهای از ابزارهای مجاز اعتبارسنجی میکند. اگر مدل ابزاری خارج از این لیست را پیشنهاد دهد، سامانه تخلف را ثبت کرده و مقدار False برمیگرداند.
با این حال، یک باگ بحرانی در تابع بازگشتی route_ticket باعث میشد شمارنده تلاش مجدد در هر فراخوانی ریست شود. چون متغیر retries داخل تابع تعریف شده بود و نه در حافظه تیکت، حلقه بازپرداخت VAT برای هفتهها ادامه یافت.
بنبستها (Deadlocks) زمانی رخ میدهند که LLM اقدامی مثل investigate_purchase را پیشنهاد دهد که نه ابزاری شناختهشده است و نه دستور ارجاع. در این حالت، تیکتها تا زمان پاکسازی دستی توسط مهندس SRE، روزها رها میمانند.
GlobalCart دریافت که تمرکز بر قوانین سختافزاری برای تیکتهای پرتکرار، هزینههای LLM و ارجاع انسانی را به صورت دو رقمی کاهش میدهد. همچنین افزودن حفاظهای سختگیرانه و سقف برای تلاش مجدد، ۱۲٪ دیگر از هزینههای پشتیبانی را ذخیره کرد.
جالب اینجاست که تلاش برای تنظیم دقیق (Fine-tuning) — مثل وقتی به یک پزشک عمومی تخصص پوست میدهیم تا روی یک حوزه دقیق شود — برای مدیریت موارد استثنایی، بازدهی کمی داشت. گلوگاه، هوش مدل نبود، بلکه کیفیت دادهها و در دسترس بودن API بود.
برای مدیران عملیاتی، مطمئنترین راه کاهش هزینه این است که ارجاع انسانی را پیشفرضِ هرگونه تردیدِ عامل قرار دهند. این کار تیکتهای گرانقیمت و حلقوی را پیش از آنکه هزینههای محاسباتی را بالا ببرند، پاکسازی میکند.
توسعهدهندگان باید شناسایی نشت هزینه را بر اساس تحلیلهای زنده عملیاتی اولویت دهند، نه اینکه به امتیاز کیفیت در سطح توکن تکیه کنند. تا زمانی که APIها کامل نشوند و شکستهای خاموش ابزارگذاری نشوند، مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — نمیتواند مشکل هزینههای بیحدومرز را حل کند.
گام بعدی شما
- بررسی مجدد توابع بازگشتی در عاملهای خود برای اطمینان از اینکه شمارنده تلاش مجدد (Retry Counter) در سطح وضعیت (State) تیکت ذخیره میشود، نه در سطح تابع.
- پیادهسازی یک لایه اعتبارسنجی (Guardrail) برای محدود کردن ابزارهای قابل فراخوانی توسط LLM به یک لیست سفید (Whitelist) مشخص.
- جایگزینی استدلال LLM با قوانین
if/elseساده برای بیشترین ۱۰ مورد پرتکرار در جریان کاری شما.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو