اول نتیجه را بگوییم: هزینه‌سوزی ربات خدمات مشتری، هشتاد درصدش به‌خاطر گران بودن قیمت واحد مدل نیست، بلکه مشکل در روش فراخوانی است. یک ربات پرسش و پاسخ پس از فروش داخلی ما با چند هزار کاربر فعال روزانه، در ماه اول عرضه، صورتحسابش مستقیماً به سه برابر بودجه رسید. پس از بررسی، قیمت واحد مدل حتی یک ریال هم تغییر نکرده بود و همه‌اش هزینه‌های پنهان در ساختار فراخوانی بود. این مقاله فرآیند بازنگری را می‌نویسد؛ اگر بهینه‌سازی هزینه API مدل‌های بزرگ مرتبط است، می‌توانید با صورتحساب خودتان یک‌به‌یک بررسی کنید.
صورتحساب غیرعادی چه شکلی است
ویژگی غیرعادی «بالا بودن کل مبلغ» نیست، بلکه «عجیب بودن ساختار» است. ما جزئیات فراخوانی روزانه را استخراج کردیم و سه نقطه مشکوک پیدا شد: در روزهایی که حجم فراخوانی بالاترین بود، میانگین توکن هر درخواست در حال افزایش بود؛ نسبت تعداد تلاش‌های مجدد نزدیک به بیست درصد بود؛ و برای یک سؤال یکسان کاربر، گاهی چند صد توکن و گاهی بیش از ده هزار توکن مصرف می‌شد که واریانس بسیار زیادی داشت. این سه مورد در کنار هم، اساساً نشان می‌دهد که مشکل در سمت مدل نیست، بلکه در زنجیره فراخوانی خودمان است.
چهار هزینه پنهان، هر کدام از دیگری مخفی‌تر
اول، مدل پرچمدار کارهای درشت انجام می‌دهد. در ابتدا برای راحتی، همه درخواست‌ها را یکسان به مدل پرچمدار می‌فرستادیم. اما در سناریوی خدمات مشتری، بیش از هفتاد درصد مواردی مثل «سفارشم کجاست» و «چطور مرجوع کنم» از نوع تشخیص قصد و پاسخ‌های متنی ثابت هستند؛ این نوع وظایف با مدل کوچک کاملاً کافی است و هزینه یک مرتبه بزرگی تفاوت دارد. سپردن پاسخ «ساعت کاری چند است» به مدل پرچمدار، مثل استفاده از کامیون برای تحویل غذاست.
دوم، تورم بی‌مهار زمینه. در گفت‌وگوی چندنوبتی، همه پیام‌های تاریخی را به‌طور کامل برمی‌گرداندیم؛ وقتی کاربر به نوبت دهم می‌رسید، فقط تاریخچه بیشتر توکن‌ها را اشغال می‌کرد. مشکل‌سازتر اینکه بسیاری از تاریخچه‌ها هیچ ارتباطی با سؤال فعلی نداشتند و صرفاً همراهی می‌کردند. زمینه هرچه طولانی‌تر باشد هوشمندتر نیست؛ پس از طول مشخصی، بهبود دقت محدود است اما هزینه به‌صورت خطی افزایش می‌یابد.
سوم، طوفان تلاش مجدد. ما یک تلاش مجدد ساده برای شکست تنظیم کردیم، اما عقب‌نشینی و قطع‌کننده مدار پیاده‌سازی نکردیم. وقتی بالا دست گاهی timeout می‌داد، همان دسته درخواست‌ها مکرراً ارسال می‌شد؛ یک بار شکست، یک بار تلاش مجدد، تلاش مجدد باز شکست و باز تلاش مجدد. این بخش از فراخوانی‌ها در صورتحساب کاملاً هدر رفته بود و کاربر همچنان خطا می‌دید.
چهارم، صورتحساب مضاعف جریانی و غیرجریانی. این مورد بیشتر از همه نادیده گرفته می‌شود. برخی از زنجیره‌های ما برای دریافت نتیجه کامل و پس‌پردازش، یک بار غیرجریانی فراخوانی می‌کردند؛ و فرانت‌اند هم برای افکت ماشین‌تحریر، یک بار جریانی. برای یک سؤال، دو هزینه. بعداً یکپارچه به دریافت جریانی و مونتاژ محلی تغییر دادیم و این هزینه مضاعف حذف شد.
مسیریابی لایه‌ای چطور پیاده‌سازی می‌شود
ایده پیچیده نیست: تقسیم بر اساس سختی وظیفه. تشخیص قصد، استخراج اسلات، متن ثابت و امثال آن، از مدل سبک استفاده می‌کنند؛ و فقط مکالمات پیچیده‌ای که واقعاً نیاز به استدلال، قضاوت چندمرحله‌ای و آرامش احساسی دارند، به مدل پرچمدار سپرده می‌شوند. یک لایه دروازه مدل در وسط برای قضاوت اضافه می‌شود؛ درخواست که وارد می‌شود ابتدا از دسته‌بند می‌گذرد، برچسب وظیفه می‌گیرد و سپس تصمیم‌گیری می‌شود که به کدام مدل مسیریابی شود.
ما از منطق انتخاب خودکار بهترین مدل بر اساس وظیفه استفاده کردیم و یک دور مقایسه روی مسیریابی چندمدلی SiCore TokenWorks انجام دادیم؛ پس از سوئیچ وظایف ساده به مدل سبک، هزینه کلی به‌وضوح کاهش یافت و پاسخ‌دهی هم سریع‌تر شد. نکته کلیدی اینجا «استفاده از کدام مدل» نیست، بلکه این است که جدول نگاشت «کدام وظیفه با کدام مدل» باید مداوم تنظیم شود. در ابتدای عرضه بر اساس تجربه تنظیم کردیم و پس از دو هفته بر اساس نرخ برخورد واقعی یک بار دیگر کالیبره کردیم؛ نتیجه بسیار بهتر از تنظیم سرانگشتی بود. مزیت یکپارچگی دسترسی چندمدلی هم همین‌جا نمایان می‌شود: تغییر استراتژی مسیریابی نیازی به تغییر کد کسب‌وکار ندارد و فقط تنظیم لایه دروازه کافی است.
مقایسه صورتحساب قبل و بعد از بهینه‌سازی
عدد مشخص نمی‌دهیم، نسبت می‌دهیم. کل حجم فراخوانی تغییری نکرد، چون تعداد کاربران تغییری نکرد. هزینه کل حدود شصت درصد کاهش یافت؛ سهم فراخوانی مدل پرچمدار از نزدیک صد درصد به حدود سی درصد رسید و بقیه به مدل‌های سبک منشعب شد. فراخوانی‌های مرتبط با تلاش مجدد از نزدیک بیست درصد به درصد تک‌رقمی فشرده شد. میانگین توکن هر درخواست حدود چهل درصد کاهش یافت که عمدتاً از برش زمینه بود. بخش صورتحساب مضاعف جریانی مستقیماً به صفر رسید. در مجموع، از سه برابر بودجه به داخل بودجه با مقداری مازاد برگشتیم.
مانیتورینگ و هشدار چطور تنظیم می‌شود
پولی که صرفه‌جویی شده باید حفظ شود و این به مانیتورینگ بستگی دارد، نه به خودکنترلی. ما چهار هشدار تنظیم کردیم: توکن یک درخواست از آستانه عبور کند فعال شود، برای جلوگیری از خارج شدن زمینه از کنترل؛ نرخ تلاش مجدد از نسبت تعیین‌شده عبور کند فعال شود، برای جلوگیری از طوفان تلاش مجدد؛ سهم فراخوانی مدل پرچمدار به‌طور غیرعادی بالا رود فعال شود، که نشان می‌دهد مسیریابی ممکن است از کار افتاده باشد؛ و افزایش روزانه هزینه نسبت به دوره قبل از آستانه عبور کند فعال شود. این چهار مورد نیازی به پیچیدگی زیاد ندارند؛ تجمیع روزانه و هشدار عبور از خط کافی است. در مدل صورتحساب Token، هزینه به‌صورت لحظه‌ای انباشته می‌شود؛ اگر تا پایان ماه منتظر بمانید و صورتحساب را ببینید و بعد بهینه کنید، پول قبلاً خرج شده است.
در یک جمله: بخش عمده هزینه ربات خدمات مشتری در ساختار فراخوانی است، نه در قیمت واحد مدل. اگر این چهار کار — مسیریابی لایه‌ای، برش زمینه، کنترل تلاش مجدد و یکپارچگی جریانی — را محکم انجام دهید، صورتحساب خودبه‌خود پایین می‌آید. یک قدم فراتر، اگر در سناریوی شما RAG هم وجود دارد، تعداد بازیابی پایگاه برداری هم ارزش بررسی با همین منطق را دارد.