تصور کنید در یک محیط کاری پرفشار، برای دریافت یک پاسخ ساده از دستیار هوش مصنوعی، باید ۳۰ ثانیه منتظر بمانید؛ این وقفه در دنیای نرم‌افزارهای تجاری به معنای مرگ محصول است. شرکت JarvisBitz Tech در ۱۸ سپتامبر ۲۰۲۶ فاش کرد که چگونه با یک بازنگری ساختاری، این تأخیر را به زیر ۳ ثانیه رسانده است. آن‌ها این بحران را نه به عنوان یک محدودیت در مدل زبانی، بلکه به عنوان یک شکست در ارکستراسیون (هماهنگ‌سازی) سیستم تحلیل کردند.
بسیاری از شرکت‌هایی که دستیارهای هوش مصنوعی را به محصولات خود اضافه می‌کنند، هنگام مقیاس‌پذیری با دیواری مشابه برخورد می‌کنند. آن‌ها معمولاً یک «گردش کار ثابت» می‌سازند که در آن یک پنجرهٔ چت روی کتابخانه‌ای عظیم از اسناد قرار دارد؛ نتیجه‌ای که منجر به پاسخ‌های کند و غیردقیق می‌شود و باعث می‌شود محصول در نظر کاربر خراب یا ناکارآمد به نظر برسد. این چالش‌ها دقیقاً همان دلایلی هستند که بسیاری از چت‌بات‌ها را به جای تبدیل شدن به محیط‌های کاری یکپارچه، در حد ابزارهای ساده‌ای برای بهره‌وری نگه داشته است. در این مورد خاص، مشتری یک شرکت SaaS در حوزه خودرو در ایالات متحده بود که یک پایگاه دانش ۱۲۰ گیگابایتی شامل حدود ۴۰,۰۰۰ سند PDF را مدیریت می‌کرد.
زمینه‌ی شکست
این مشتری از ابتدا اهدافی بلندپروازانه داشت و پیاده‌سازی دستیار خود را خیلی زود و با جدیت آغاز کرده بود. هدف این بود که ابزاری ساخته شود که بتواند به مشتریان در یافتن اطلاعات کمک کند، نیازهای آن‌ها را تشخیص دهد، به پرسش‌ها پاسخ دهد، فرصت‌های فروش را در جریان گفتگوها شناسایی کند، در یک کتابخانه عظیم از اسناد جست‌وجو کند و در نهایت از تعاملات صوتی پشتیبانی نماید.
اما طبق گزارش JarvisBitz، تا زمانی که این تیم وارد پروژه شد، سیستم در اجرای اکثر این وظایف ضعیف عمل می‌کرد. ابزار بیشتر شبیه به یک اسکریپت صلب و خشک بود که فقط ظاهر یک رابط چت را داشت. سیستم به طور مکرر در تشخیص قصد (Intent) مشتری اشتباه می‌کرد. بحرانی‌ترین مسئله این بود که پاسخ‌ها بین ۱۰ تا ۳۰ ثانیه طول می‌کشیدند تا ظاهر شوند. در یک رابط چت، این میزان تأخیر باعث می‌شود کاربر احساس کند محصول از کار افتاده یا «مرده» است. برای استارتاپ‌های SaaS، چنین تجربه کاربری ضعیفی می‌تواند منجر به ریزش سریع کاربران شود، به همین دلیل اتخاذ استراتژی‌های هوشمند برای حفظ کاربر در مقیاس بالا حیاتی است.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی استنتاج در مدل‌های سازمانی اشاره کردیم، مشکل اغلب در لایه‌های میانی است. در این مورد، مدل زبانی تنها یک‌پنجم مشکل بود و اکثر تأخیرها پیش از شروع تولید متن رخ می‌داد. سیستم دچار چهار عادت بد ساختاری بود که اثر یکدیگر را تشدید می‌کردند:
- بازیابی بیش از حد: چون سیستم ابتدا تصمیم نمی‌گرفت که چه نوع سؤالی پرسیده شده است، هر پرسشی باعث استخراج مجموعه‌ای گسترده از قطعات متنی از سراسر کتابخانه می‌شد.
- ارسال داده‌های اضافی: تمام متون بازیابی‌شده بدون هیچ فیلتری در پرامپت ریخته می‌شدند. پرامپت‌های بزرگ‌تر منجر به تولید کندتر، هزینه‌ی بیشتر و کاهش توانایی مدل در شناسایی قطعه متنی که واقعاً اهمیت دارد، می‌شوند.
- احراز هویت دیرهنگام: بررسی دسترسی‌ها و مجوزها بعد از مرحله بازیابی انجام می‌شد. سیستم ابتدا مطالب را بازیابی می‌کرد و سپس آن‌ها را دور می‌ریخت، که این کار هم باعث اتلاف زمان می‌شد و هم گاهی اجازه می‌داد مطالب محدودشده به پنجره زمینه نفوذ کنند.
- فقدان حافظه موقت: سیستم هیچ حافظه‌ای از پرسش‌های قبلی نداشت. اگر دو نفر در فاصله یک ساعت از هم سؤال یکسانی می‌پرسیدند، سیستم هر دو بار تمام هزینه‌ی محاسباتی و زمانی را به طور کامل پرداخت می‌کرد.
خط لوله‌ی ارکستراسیون جدید
تیم فنی برای حل این بحران، سیستم را با استفاده از Google Vertex AI و مدل Gemini بازسازی کرد که با زبان پایتون نوشته شده بود. آن‌ها برای مسیر صوتی، قابلیت‌های تبدیل گفتار به متن (Speech-to-Text) و متن به گفتار (Text-to-Speech) را ادغام کردند. آن‌ها تمرکز را از ابزارها به «ترتیب عملیات» تغییر دادند و یک خط لوله‌ی تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — با ارکستراسیون عامل‌محور (Agentic Orchestration) طراحی کردند.
در این ساختار جدید، یک توالی سخت‌گیرانه دنبال می‌شود که در آن هر لایه پیش از فراخوانی مدل، پارامترهای خاصی را تعیین می‌کند:
- تشخیص قصد (Intent Detection): این لایه تصمیم می‌گیرد کاربر چه نوع درخواستی دارد و باید در کدام مسیر قرار گیرد. این مرحله باید حتماً اول باشد چون تمام مراحل بعدی — از جمله اینکه چه چیزی بازیابی شود، کدام قوانین اعمال شوند و آیا این پرسش یک سرنخ فروش (Lead) است یا خیر — به آن وابسته است.
- بازیابی آگاه از دسترسی (Authorization-Aware Retrieval): این لایه تعیین می‌کند که کاربر خاص، مجاز به دیدن کدام اسناد است. با اعمال این مورد به عنوان یک محدودیت در خودِ جست‌وجو، سیستم از اتلاف منابع و ریسک فیلتر کردن پس از بازیابی جلوگیری می‌کند.
- ساخت بستر متن (Context Construction): سیستم کوچک‌ترین مجموعه‌ای از قطعات متنی را که می‌تواند پاسخ را به خوبی ارائه دهد، شناسایی می‌کند. پرامپت‌های کوچک‌تر سریع‌تر، ارزان‌تر و دقیق‌تر هستند.
- حافظه موقت (Caching): این لایه تعیین می‌کند چه مواردی را می‌توان به طور ایمن بین کاربران و جلسات مختلف بازاستفاده کرد و چه مواردی باید منحصر‌به‌فرد باقی بمانند تا پرسش‌های تکراری هزینه‌ی کامل ایجاد نکنند.
- اجرای عامل‌محور (Agentic Execution): در نهایت، سیستم درباره اقدام بعدی تصمیم می‌گیرد: ارائه پاسخ، پرسیدن سؤال تکمیلی، مسیریابی سرنخ فروش یا انتقال گفتگو به یک اپراتور انسانی. این امر به دستیار اجازه می‌دهد به جای دنبال کردن یک اسکریپت ثابت، به درخواست کاربر «پاسخ» دهد.
حل نشت دسترسی‌ها
یکی از حیاتی‌ترین تغییرات، انتقال احراز هویت به داخل مرحله‌ی بازیابی بود. در طراحی قبلی، اسناد ابتدا بازیابی و سپس فیلتر می‌شدند که علاوه بر اتلاف منابع محاسباتی، یک ریسک امنیتی ایجاد می‌کرد؛ جایی که مطالب غیرمجاز می‌توانستند به پنجرهٔ زمینه (Context Window) — میزان متنی که مدل هم‌زمان در ذهن نگه می‌دارد، شبیه میز کاری که جا برای چند ورق دارد — نفوذ کنند.
JarvisBitz هشدار می‌دهد که تست کردن مجوزها با حساب‌های مدیر (Admin) کاملاً بی‌فایده است، زیرا مدیران به همه چیز دسترسی دارند و در نتیجه هر پاسخی درست به نظر می‌رسد. آن‌ها توصیه می‌کنند تست‌ها با محدودترین حساب‌های کاربری ممکن انجام شود تا اطمینان حاصل شود که محدودیت‌های بازیابی واقعاً کار می‌کنند. اگر سیستمی فقط توسط سازندگانت با حساب‌های سطح بالای آن‌ها تست شود، در واقع مجوزهای دسترسی اصلاً تست نشده‌اند.
بهینه‌سازی برای دقت و هزینه
با محدود کردن بستر متن، تیم متوجه شد که مدل قابل‌اعتمادتر شده است. تیم در این رویکرد بسیار سخت‌گیر بود: پرامپت فقط حاوی قطعاتی است که به سؤال پاسخ می‌دهند و نه هیچ چیز دیگر. مدلی که ۳ متن بسیار مرتبط را می‌خواند، بسیار دقیق‌تر از مدلی است که ۳۰ متن پر از نویز و اطلاعات اضافی را بررسی می‌کند.
نتایج این بازسازی در سه معیار کلیدی ملموس و قابل اندازه‌گیری بود:
- تأخیر: زمان تا نخستین توکن (Time to First Token) از ۱۰ تا ۳۰ ثانیه به زیر ۳ ثانیه رسید. (لازم به ذکر است که این مورد مربوط به اولین توکن در تعاملات معمول است؛ پاسخ‌های طولانی همچنان برای اتمام استریمینگ زمان بیشتری می‌برند).
- صحت: تشخیص قصد و بازیابی در موارد کاربردی تعریف‌شده توسط مشتری به حدود ۹۸٪ رسید. (این نرخ بر اساس موارد کاربردی خاص مشتری اندازه‌گیری شده و یک نرخ جهانی نیست).
- هزینه: هزینه‌های عملیاتی به دلیل کاهش حجم پرامپت‌ها و استفاده از پاسخ‌های ذخیره شده در حافظه موقت، حدود ۳۰٪ کاهش یافت که نتیجه مستقیم کاهش تعداد کل توکن‌ها بود.
فعال‌سازی مسیر صوتی
این بهینه‌سازی‌ها تنها دلیل ممکن شدن رابط کاربری صوتی بود. در واقع همان موتور پردازشی پشت رابط صوتی قرار دارد، با این تفاوت که در ورودی تبدیل گفتار به متن و در خروجی تبدیل متن به گفتار قرار گرفته است.
رابط صوتی نسبت به تأخیر بسیار حساس‌تر از متن است؛ یک مکث ۳ ثانیه‌ای در یک مکالمه شفاهی مانند یک ابدیت به نظر می‌رسد. بدون مسیریابی قصد و تراشیدن بستر متن، دستیار نمی‌توانست با سرعتی پاسخ دهد که یک مکالمه طبیعی را حفظ کند. این رویکرد بهینه‌سازی تأخیر در لایه‌های پردازشی، مشابه راهکاری است که در زیرساخت Preterview برای رساندن تأخیر عامل‌های صوتی به زیر یک ثانیه به کار گرفته شد.
این معماری تضمین می‌کند که در حالی که هوش مصنوعی جمع‌آوری داده‌ها و مسیریابی سرنخ‌ها را مدیریت می‌کند، تصمیمات حساس همچنان در دست انسان باشد. دستیار می‌تواند به طور طبیعی از پاسخ به یک حقیقت به سمت پرسیدن سؤالات واجد شرایط برای جذب مشتری حرکت کند، اما بدون حضور انسان در چرخه (Human-in-the-loop)، معامله‌ای را نمی‌بندد یا سوابق را تغییر نمی‌دهد. این یک انتخاب آگاهانه در طراحی است، نه یک محدودیت فنی.
برای هر تیمی که با کندی دستیار هوش مصنوعی خود دست‌وپنجه نرم می‌کند، درس این است: پیش از تعویض مدل، اندازه‌گیری کنید که زمان دقیقاً کجا تلف می‌شود. در اکثر موارد سازمانی، گلوگاه سیستم‌های پیرامونی — یعنی بازیابی، مجوزها و مدیریت بستر متن — است، نه خودِ مدل زبانی (LLM). بخش سختِ هوش مصنوعی سازمانی، فراخوانی مدل نیست؛ بلکه سیستم‌های تأیید و کنترل پیرامون آن است که یک دموی ساده را از یک محصول آماده برای تولید متمایز می‌کند.
گام بعدی شما
- پیش از تعویض مدل زبانی برای رفع کندی، نقاط دقیق اتلاف زمان در خط لوله‌ی بازیابی و احراز هویت خود را اندازه‌گیری کنید.
- احراز هویت را از مرحله‌ی «پس از بازیابی» به «در حین بازیابی» منتقل کنید تا هم سرعت افزایش یابد و هم ریسک نشت داده کاهش یابد.
- حجم پرامپت‌ها را با سخت‌گیری کاهش دهید؛ دقت مدل با حذف نویزهای متنی افزایش می‌یابد.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو