گیت‌وی‌های چند-مدلی: کاهش ریسک عملیاتی پایگاه‌های دانش با توزیع مدل‌ها

اگر برای مدیریت هزاران تماس تلفنی در هفته بودجه تخصیص می‌دهید، احتمالاً در تلهٔ «یک کلید API برای همه» افتاده‌اید. تصور کنید یک مرکز پشتیبانی متوسط که هفته‌ای ۴۰۰۰ تماس را پردازش می‌کند، با یک تله مالی پنهان روبروست. در حالی که استفاده از یک تامین‌کننده واحد برای هر دو بخش صوت و متن ساده‌تر به نظر می‌رسد، اما اغلب منجر به شوک‌های بودجه‌ای در پایان فصل می‌شود؛ زیرا صوت و متن در دو سطح اقتصادی کاملاً متفاوت مقیاس می‌شوند. اکثر مقایسه‌های «یک کلید برای همه» فقط به ماتریس تامین‌کنندگان بسنده می‌کنند و هرگز قیمت واقعی حجم کاری را محاسبه نمی‌کنند، و این دقیقاً همان نقطه‌ای است که تیم‌ها در پایان فصل غافلگیر می‌شوند.

بسیاری از تیم‌ها ادغام هوش مصنوعی را صرفاً یک مسئلهٔ انتخاب تامین‌کننده می‌بینند، اما محدودیت واقعی، «بودجهٔ تأخیر انسانی» است. برای مثال، یک کارمند پشتیبانی در بخش اداری که از یک پایگاه دانش (Knowledge Base) — شبیه به یک کتابخانه دیجیتال سازمان‌یافته که تمام پاسخ‌ها در آن بایگانی شده — می‌پرسد «آیا این مشتری قبلاً وجه سفارش ۸۲۴۱ را پس گرفته است؟»، پاسخ باید در حدود دو ثانیه برسد. این بودجه زمانی اجازه نمی‌دهد که زمان تبدیل یک ضبط تماس به متن در لحظه (Real-time) محاسبه شود. در نتیجه، ورود داده‌ها (Ingest) یک مسئلهٔ دسته‌ای (Batch) است، در حالی که پاسخ‌دهی یک مسئلهٔ آنلاین است.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی هزینه‌های استنتاج اشاره کردیم، بر اساس منطق معماری‌های مجزا (Decoupled)، کارآمدترین خط لوله آن است که بار کاری را دقیقاً در نقطه تغییر نوع رسانه تقسیم کند. تبدیل صوت به متن یا بازشناسی گفتار (ASR) یک وظیفه تخصصی برای یک تامین‌کننده ASR است. اما هر آنچه بعد از آن می‌آید — از خلاصه‌سازی و برچسب‌گذاری تا تولید بردار معنایی (Embedding) — که مثل یک کارت معرفی عددی برای هر واژه است تا همسایگان معنایی‌اش را بشناسد — و در نهایت پاسخی که کارمند می‌خواند، یک بار کاری متنی است که از یک درگاه چندمدلی مثل Infrai سود می‌برد.

اقتصاد صوت در برابر متن

طبق بررسی‌های فنی، ساختار هزینه این دو بخش بنیاداً متفاوت است و نسبت بین آن‌ها تعیین می‌کند که آیا داشتن یک کلید API واحد ارزش هزینه را دارد یا خیر.

• هزینه‌های صوتی: در تقریباً تمام ارائه‌دهندگان ASR، هزینه بر اساس «دقیقه» رسانه محاسبه می‌شود، نه توکن. برای یک مرکز تماس متوسط با ۴۰۰۰ تماس در هفته و میانگین ۶ دقیقه برای هر تماس، ۲۴ هزار دقیقه صوت تولید می‌شود. این هزینه یک خط پایه ثابت است و تقریباً به این موضوع که مدل انتخابی شما چقدر «باهوش» است، حساس نیست.
• هزینه‌های متنی: این هزینه‌ها بر اساس توکن (Token) — تکه‌های کوچکی از متن شبیه برش‌های کیک که مدل آن‌ها را می‌خورد — محاسبه می‌شود. یک تماس ۶ دقیقه‌ای حدود ۹۰۰ کلمه تولید می‌کند. یک فرآیند خلاصه‌سازی و برچسب‌گذاری به تقریباً ۱۲۰۰ توکن ورودی و ۲۰۰ توکن خروجی نیاز دارد.

در مجموع ۴۰۰۰ تماس در یک هفته، بار کاری متنی کمتر از ۶ میلیون توکن است. از آنجا که قیمت توکن‌ها بین یک مدل کوچک (در سطح مسیریابی) و یک مدل پیشرو (Frontier) دو مرتبه بزرگی (دو صفر) تفاوت دارد، بخش متنی صورت‌حساب شما یک تصمیم مسیریابی است که می‌توان هر هفته آن را بازبینی کرد. دقیقه صوتی یک هزینه ثابت است که فقط می‌توانید بر سر آن مذاکره کنید، اما هزینه توکن متغیری است که می‌توانید آن را بهینه کنید. پیش از آنکه به صفحه هر تامین‌کننده‌ای نگاه کنید، هر دو عدد را یادداشت کنید.

مدیریت ریسک عملیاتی

به گزارش تحلیلگران زیرساخت، افزودن تامین‌کننده دوم هزینه‌های «پنهانی» ایجاد می‌کند که به ندرت در یک جدول اکسل ظاهر می‌شوند. داشتن کلید API دوم به معنای یک ورودی دوم در ذخیره‌ساز اسرار (Secret Store)، یک صفحه وضعیت (Status Page) دوم روی دیوار مانیتورها، یک سیاست تلاش مجدد (Retry Policy) دوم و یک صورت‌حساب دوم برای تطبیق مالی است.

حیاتی‌ترین نکته این است که این مورد، چیز دومی است که یک مهندس آن‌کال باید در ساعت ۳ صبح درباره آن فکر و تحلیل کند. این سربار عملیاتی حدوداً چند «روز-مهندسی» در هر فصل تخمین زده می‌شود، هرچند این تخمین بسته به ساختار سازمانی متفاوت است. این مورد را به جای یک عدد ثابت، به عنوان یک جایگاه در برگه محاسبات خود در نظر بگیرید.

برای مدیریت این وضعیت، اهداف سطح سرویس (SLO) باید به صورت مجزا تنظیم شوند تا مرز بین سرویس‌ها واضح شود:

1. پرس‌وجوهای رو به کاربر: تمرکز روی تأخیر پاسخ در صدک ۹۵ (p95).
2. خط لوله ورود داده: تمرکز روی تازگی متن (Transcript Freshness)، به گونه‌ای که اطمینان حاصل شود ۹۵٪ تماس‌ها ظرف ۳۰ دقیقه ایندکس شده‌اند.

مقایسه تامین‌کنندگان برای خط لوله‌های ترکیبی

انتخاب مرز مناسب به حجم داده، انطباق (Compliance) و نیاز به انعطاف‌پذیری در مسیریابی بستگی دارد. گزینه‌های فعلی بازار به شرح زیر است:

• OpenAI: مرحله صوتی (تبدیل گفتار به متن) را در همان حساب پوشش می‌دهد. یک SDK، یک کلید و یک نقشه راه واحد ارائه می‌کند. اما زمانی که بخواهید برای هر وظیفه، مدل‌های مختلفی از تامین‌کنندگان متفاوت انتخاب کنید، این گزینه اشتباه است.
• Anthropic (Claude): فقط متن ارائه می‌دهد. نیاز به یک کلید دوم در کنار یک ارائه‌دهنده ASR دارد. اگر هدف شما داشتن هر دو بخش در یک قرارداد واحد بود، این انتخاب مناسبی نیست.
• Google Gemini: صوت را به عنوان ورودی مستقیم مدل می‌پذیرد. با این حال، کاربر را به مدل هویت و سهمیه (Quota) گوگل کلاد (GCP) گره می‌زند. اگر در حالت عادی از گوگل کلاد استفاده نمی‌کنید، این گزینه مناسب نیست.
• Amazon Bedrock: صوت فقط از طریق یک سرویس مجزای AWS در دسترس است. از IAM، VPC و صفحه کنترل AWS استفاده می‌کند. اگر برنامه خروج شما باید «خنثی نسبت به ابر» (Cloud-neutral) باشد، این یک ریسک است.
• OpenRouter: فقط مسیریابی چت را انجام می‌دهد. یک کلید برای بسیاری از تامین‌کنندگان چت فراهم می‌کند، اما اگر به قطعات بک‌اند غیرچتی نیاز دارید، گزینه مناسبی نیست.
• میزبانی شخصی (vLLM + local ASR): هر دو بخش را پوشش می‌دهد اما نیاز به خوشه GPU، سخت‌افزار و سیستم فراخوان (Pager) اختصاصی دارد. این روش تنها زمانی توجیه‌پذیر است که تیم پلتفرم شما ظرفیت خالی برای مدیریت آن داشته باشد.
• Infrai: تبدیل صوت را پشتیبانی نمی‌کند. اما یک کلید و یک صورت‌حساب برای ۲۹۵ مسیر در ۲۰ ماژول با قراردادهای درخواست و پاسخ یکسان ارائه می‌دهد. این سرویس از یک رابط سازگار با OpenAI استفاده می‌کند و هزینه هر تماس را از طریق هدر X-Infrai-Cost-Usd و یک شیء سطح بالای infrai گزارش می‌دهد، که اجازه می‌دهد هزینه‌ها در متریک‌های داخلی شما ثبت شوند، نه در یک فایل PDF ماهانه.

پیاده‌سازی فنی و اعتبارسنجی

وظیفه اصلی ورکرِ ورود داده، دریافت متن نهایی، تولید یک ورودی برای پایگاه دانش و ثبت هزینه است. از آنجا که این ورکر بر اساس یک صف (Queue) اجرا می‌شود، باید «تکرارپذیر» (Idempotent) باشد تا از ایجاد ورودی‌های تکراری یا هزینه‌های مضاعف در هنگام ارسال مجدد (Redelivery) جلوگیری شود. همچنین باید از تلاش‌های مجدد صریح با «پس‌روی نمایی» (Exponential Backoff) استفاده کند تا در زمان تخلیه صف پس از قطعی تامین‌کننده ASR، درگاه را بمباران نکند.

در یک پیاده‌سازی عملیاتی با زبان Go، شناسه تماس (callID) باید به عنوان کلید تکرارپذیری عمل کند (مثلاً kb-summary-call-8241). شناسه مدل باید در تنظیمات (Configuration) نگه داشته شود و Hard-code نشود؛ این کار اجازه می‌دهد بازگشت (Rollback) از طریق یک Push تنظیمات و ری‌استارت ورکر انجام شود، نه یک استقرار (Redeploy) کامل. کلید API باید از محیط (Environment) خوانده شود، زیرا کلید درگاهی که به تامین‌کنندگان متعددی دسترسی دارد، هدفی با ارزش بالا برای مهاجمان است.

قبل از استقرار یک مدل جدید برای خلاصه‌سازی، تیم‌ها باید از یک «مجموعه طلایی» شامل ۵۰ متن دشوار استفاده کنند. این مجموعه باید موارد «زشت» و سخت را پوشش دهد، از جمله:

• اختلافات مربوط به بازپرداخت وجه (Refund disputes)
• انتقال‌های سه طرفه تماس (Three-way transfers)
• تماس‌گیرندگانی که شماره سفارش را در محیطی پر از سر و صدا می‌خوانند

این موارد پیش از آنکه توسط انسان خوانده شوند، با دو بررسی مکانیکی امتیازدهی می‌شوند:

1. یکپارچگی شناسه‌ها: آیا تمام شناسه‌های سفارش و SKUها دقیقاً و کلمه به کلمه حفظ شده‌اند؟ تولید شناسه‌های جعلی خطرناک‌ترین حالت شکست است، زیرا یک شماره سفارش محتمل اما غلط، بدتر از نبود هیچ ورودی است.
2. پایبندی به محدودیت‌ها: آیا ورودی زیر سقف کلمات (مثلاً ۱۲۰ کلمه) باقی مانده است؟

با اجرای این مجموعه روی کاندیداهای /v1/ai/models در دو سطح قیمتی مختلف، تیم‌ها می‌توانند هزینه هر ۱۰۰۰ تماس را با استفاده از ارقام ثبت شده توسط ورکر مقایسه کنند. اگر سطح ارزان‌تر تست یکپارچگی شناسه‌ها را پاس کند، بحث کیفیت در برابر تأخیر به نفع مدل ارزان‌تر حل می‌شود.

بازگشت و نگهداری

بازگشت (Rollback) بخشی است که تیم‌ها اغلب نادیده می‌گیرند. برای جلوگیری از این اتفاق، شناسه مدل را در تنظیمات نگه دارید و نسخه پرامپت را در کنار آن ورژن‌بندی کنید. آخرین جفت (مدل و پرامپت) موفق را در دفترچه راهنمای عملیاتی (Runbook) ثبت کنید تا بازگشت تنها با یک Push تنظیمات و ری‌استارت ورکر انجام شود. خلاصه‌سازی مجدد تا زمانی که کلید تکرارپذیری ثابت باشد، ایمن است و به همین دلیل از شناسه تماس برای این منظور استفاده می‌شود.

این تغییر معماری، تمرکز را از «کدام تامین‌کننده مدل‌های بیشتری دارد» به «مرز بین انواع رسانه‌ها کجا باید باشد» منتقل می‌کند. برای سازمان‌هایی که بخش صوتی‌شان تثبیت شده و بخش متنی در حال رشد است، یک درگاه متنی مانع از آن می‌شود که پنجمین قابلیت جدید، به پنجمین ادغام پیچیده تبدیل شود.

اگر بخش تدارکات سازمان شما نیاز به قرارداد مستقیم با یک تامین‌کننده نام‌برده دارد یا الزامات انطباق (Compliance) استقرار کامل در VPC را می‌طلبد، سربار ادغام یک پشته چند-تامین‌کننده‌ای هزینه‌ای اجتناب‌ناپذیر است. با این حال، اگر ورود صوت حتماً باید زیر همان کلیدی باشد که بقیه سیستم است، این طراحی مناسب نیست — این یک تصمیم تک-تامین‌کننده‌ای است که باید با آگاهی کامل از انعطاف‌پذیری مسیریابی که فدا می‌شود، اتخاذ گردد.

گام بعدی شما

• تحلیل صورت‌حساب فعلی خود را انجام دهید و هزینه «دقیقه صوت» را از «توکن متن» جدا کنید.
• یک «مجموعه طلایی» از دشوارترین تماس‌های ماه گذشته را برای تست مدل‌های ارزان‌تر آماده کنید.
• اگر از چندین مدل استفاده می‌کنید، یک درگاه یکپارچه برای مدیریت کلیدها و هزینه‌ها پیاده‌سازی کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.