قابلیت Non-Blocking در Gemini Live API سکوت‌های آزاردهندهٔ عامل‌های صوتی را حذف

تصور کنید یک عامل صوتی برای بررسی وضعیت سفارش شما، چهار ثانیه سکوت می‌کند؛ در دنیای تجربهٔ کاربری، این یعنی محصول شکست خورده است. Gemini Live API با معرفی فراخوانی توابع ناهمگام، این مشکل را حل می‌کند تا جریان گفتگو حتی در زمان کندی سیستم‌های بک‌اند قطع نشود. طبق یک راهنمای فنی که در ۱۸ اوت ۲۰۲۶ منتشر شد، این سازوکار به توسعه‌دهندگان اجازه می‌دهد تا فراخوانی‌های ابزاری خاص را با برچسب NON_BLOCKING مشخص کنند.

تعامل صوتی در لحظه، تجربه‌ای بسیار شکننده است. برخلاف کاربران متنی که چند ثانیه انتظار برای بارگذاری را تحمل می‌کنند، کاربر صوتی سکوت را به معنای کرش کردن سیستم یا قطع شدن تماس می‌بیند. این تأخیر معمولاً از ماهیت «مسدودکننده» (Blocking) ابزارهای سنتی ناشی می‌شود؛ یعنی مدل داده را درخواست می‌کند، جلسه متوقف می‌شود و خروجی صوتی منتظر نتیجه می‌ماند. یک تعامل زنده و طبیعی شامل زنجیره‌ای پیچیده از مراحل است: بازشناسی گفتار، پرس‌وجو از CRM، جست‌وجو در پایگاه‌داده، جست‌وجوی وب، تولید پاسخ توسط مدل و در نهایت تبدیل متن به صوت. چون سیستم‌های خارجی تأخیرهای پیش‌بینی‌ناپذیری دارند، مسدود کردن هر فراخوانی، طبیعی بودن گفتگو را نابود می‌کند.

همان‌طور که در تحلیل قبلی ما درباره‌ی اینکه چگونه داده‌های Google Workspace به منبع پیش‌فرض برای جمینای تبدیل شدند اشاره کردیم، این به‌روزرسانی روی لایه‌ی اجرا تمرکز دارد. این تغییر، عامل را از چرخهٔ خطی «درخواست-انتظار-پاسخ» به یک معماری موازی می‌برد؛ جایی که مدل می‌تواند انتظارات کاربر را مدیریت کند در حالی که داده‌ها هنوز در مسیر هستند.

سازوکار Non-Blocking

در یک جریان مسدودکننده سنتی، وقتی کاربر وضعیت استرداد وجه را می‌پرسد، توالی زیر رخ می‌دهد: کاربر می‌پرسد $ \rightarrow $ مدل تابع get_refund_status را فراخوانی می‌کند $ \rightarrow $ گفتگو متوقف می‌شود $ \rightarrow $ بک‌اند چهار ثانیه منتظر می‌ماند $ \rightarrow $ نتیجه بازمی‌گردد $ \rightarrow $ مدل پاسخ را ادامه می‌دهد. در این حالت، کاربر یک وقفه طولانی می‌شنود که از نظر طراحی مکالمه‌ای فاجعه است.

با رفتار جدید NON_BLOCKING، فرآیند به این شکل تغییر می‌کند:

• کاربر درخواست را مطرح می‌کند.
• مدل فراخوانی ابزار را در پس‌زمینه (Background) فعال می‌کند.
• گفتگو بلافاصله ادامه می‌یابد (عامل می‌تواند سؤالی برای شفاف‌سازی بپرسد یا فرآیند جاری را برای کاربر توضیح دهد).
• مدل به محض بازگشت نتیجه از بک‌اند، آن را در جریان پاسخ ادغام می‌کند.

از نظر مفهومی، تعریف یک ابزار در جمینای برای این رفتار به شکل زیر است:

tool = {
  "function_declarations": [
    {
      "name": "get_order_status",
      "description": "Get current order status",
      "parameters": {
        "type": "object",
        "properties": {
          "order_id": {"type": "string"}
        },
        "required": ["order_id"]
      },
      "behavior": "NON_BLOCKING"
    }
  ]
}

الزامات معماری برای محیط عملیاتی

فراخوانی ناهمگام یک کلید جادویی نیست و برای جلوگیری از توهم (Hallucination) — شبیه دوستی که با اطمینان خاطره‌ای را اشتباه تعریف می‌کند — به یک بک‌اند قدرتمند نیاز دارد. ناهمگام بودن به معنای حدس زدن یا پاسخ‌های گمانه‌زن نیست. اگر وضعیت استرداد وجه هنوز بازنگشته، عامل نباید ادعا کند که عملیات تکمیل شده است. توسعه‌دهندگان باید وضعیت‌ها را به سه دستهٔ «مشخص»، «در انتظار» و «نامعلوم» تقسیم کنند و تنها داده‌های تأیید شده را به عنوان حقیقت ارائه دهند.

بر اساس بررسی منابع متعدد، توسعه‌دهندگان باید یک مدیریت‌کنندهٔ وظایف ناهمگام (Async Task Manager) اختصاصی را برای مدیریت چرخهٔ حیات این فراخوانی‌ها پیاده‌سازی کنند. یک قانون حیاتی این است که هرگز یک Callback در WebSocket را با کارهای HTTP همگام (Synchronous) مسدود نکنید. در عوض باید از یک الگوی ناهمگام استفاده کرد:

async def execute_tool(call): $ \rightarrow $ ایجاد شناسه وظیفه $ \rightarrow $ asyncio.create_task(run_with_timeout(call)) $ \rightarrow $ ذخیره در رجیستری. سپس وقتی عملیات تکمیل شد، تابع on_tool_done نتیجه را به جلسه زنده بازمی‌گرداند.

اجزای کلیدی این معماری عبارت‌اند از:

• مدیریت وضعیت وظیفه: ردیابی دقیق اینکه یک فراخوانی در کدام وضعیت است: PENDING (در انتظار)، RUNNING (در حال اجرا)، COMPLETED (تکمیل شده)، TIMEOUT (اتمام زمان)، FAILED (شکست خورده)، CANCELLED (لغو شده) یا STALE (منقضی شده).
• کنترل هم‌زمانی: تعیین سقف max_parallel_tools (مثلاً ۳ ابزار) برای جلوگیری از فشار بیش از حد به APIهای سازمانی در لایه‌های پایین‌تر. فراخوانی‌های اضافی باید در صف قرار گیرند.
• زمان‌بندی (Timeout): هر ابزار باید زمان‌بندی تعریف‌شده‌ای (مثلاً ۵۰۰۰ میلی‌ثانیه) داشته باشد. سرویس‌های خارجی ممکن است در ۳۰۰ میلی‌ثانیه، ۸ ثانیه یا هرگز پاسخ دهند؛ یک وظیفه که دچار Timeout شده باید یک وضعیت ساختاریافته برگرداند، نه اینکه برای همیشه معلق بماند.
• کلیدهای Idempotency: این کلیدها برای عملیات «نوشتن» (Write) ضروری هستند. چون سیستم‌های ناهمگام ابهام در تکرار ایجاد می‌کنند (جایی که نوشتن موفق است اما کلاینت پاسخ را گم می‌کند)، سرویس مقصد باید تضمین کند که برای هر کلید، عملیات تنها یک‌بار اجرا شود (مثلاً در ایجاد تیکت پشتیبانی).
• همبسته‌سازی نتایج: سیستم باید session_id، call_id، آرگومان‌های ابزار، زمان شروع و نوبت گفتگو را ذخیره کند تا اطمینان حاصل شود که نتایج به درستی تطبیق داده شده و پیش از تحویل، هنوز مرتبط هستند.

سیاست طبقه‌بندی ابزارها

هر تابعی نباید ناهمگام باشد. راهنمای گوگل یک طبقه‌بندی مبتنی بر ریسک را برای رفتار ابزارها پیشنهاد می‌دهد. مدل نباید ریسک تجاری را خودش طبقه‌بندی کند؛ این سیاست باید در متادیتای اپلیکیشن تعریف شود.

• ناهمگام (READ_FAST / READ_SLOW): کاندیداهای مناسب شامل جست‌وجوی مشتری، وضعیت سفارش، تیکت‌ها، موجودی انبار، وضعیت ارسال، بازیابی دانش و جست‌وجوی وب هستند. خواندن‌های کند باید شامل به‌روزرسانی‌های وضعیت باشند.
• مسدودکننده (WRITE_HIGH_RISK / FINANCIAL / PRODUCTION): تراکنش‌های مالی، تغییرات در محیط عملیاتی (Production) و حذف‌های پرریسک. این موارد نیاز به رفتار مسدودکننده و تأیید صریح کاربر دارند.

به عنوان مثال، فراخوانی get_order_status کاندیدای عالی برای حالت NON_BLOCKING با زمان‌بندی ۵۰۰۰ میلی‌ثانیه و idempotent: true است. در مقابل، عملیات create_refund باید در حالت mode: blocking با زمان‌بندی ۱۰۰۰۰ میلی‌ثانیه و requires_confirmation: true باشد.

مدیریت مداخلات کاربر

عامل‌های صوتی واقعی باید از قابلیت Barge-in (قطع کردن صحبت AI توسط کاربر) پشتیبانی کنند. وقتی کاربر صحبت مدل را قطع می‌کند، سیستم باید فوراً پخش صوت فعلی را متوقف کرده و ارزیابی کند که آیا وظایف پس‌زمینهٔ موجود هنوز مرتبط هستند یا خیر.

اگر کاربر درخواستش را از سفارش A به سفارش B تغییر داد، عامل باید در صورت امکان اولین وظیفه را لغو کند. اگر لغو غیرممکن بود، سیستم باید نتیجه را «منقضی» (Stale) علامت بزند تا از تزریق داده‌های نامرتبط به گفتگو جلوگیری شود. عامل می‌تواند از زمان انتظار برای پرسیدن سؤالات شفاف‌ساز، جمع‌آوری جزئیات شناسایی یا اجرای سایر ابزارهای خواندنی مستقل استفاده کند، اما هرگز نباید نتایج تأییدنشده را وعده دهد.

امنیت و مشاهده‌پذیری

احراز هویت نباید به مدل سپرده شود. یک فراخوانی ابزار تولیدشده توسط مدل، به معنای داشتن مجوز (Authorization) نیست. برنامه باید زنجیره سخت‌گیرانه «هویت کاربر $ \rightarrow $ نقش $ \rightarrow $ مجوز منبع $ \rightarrow $ مجوز ابزار $ \rightarrow $ اعتبارسنجی آرگومان $ \rightarrow $ اجرا» را دنبال کند. بدون این ساختار، عامل صوتی به یک راه برای دور زدن امنیت (Authorization Bypass) تبدیل می‌شود.

همچنین، سیستم باید خروجی‌های حساس را فیلتر کند. اگر یک CRM پروفایل کامل بانکی و مدارک شناسایی را برمی‌گرداند اما کاربر فقط تاریخ ارسال را پرسیده است، تنها همان تاریخ باید به مدل منتقل شود تا میزان افشای داده‌ها به حداقل برسد.

برای سنجش موفقیت، توسعه‌دهندگان باید «زمان سکوت گفتگو» (Conversation Silence Time) را ردیابی کنند، نه فقط تأخیر خام بک‌اند. یک ابزار ممکن است چهار ثانیه زمان ببرد، اما اگر عامل بگوید: «سیستم مشتری کمی بیشتر زمان می‌برد. تا جواب بیاید، می‌توانم چند مورد دیگر را تأیید کنم»، سکوت ادراک‌شده توسط کاربر ممکن است به کمتر از یک ثانیه برسد. برای دستیابی به این سطح از دقت در پایش، ابزارهای پیشرفته‌تری مورد نیاز است؛ برای مثال، Zooid با ردیابی دستی ژنراتورها توانست نقاط کور پایش در سیستم‌های Voice AI را حذف کند تا تحلیل دقیق‌تری از عملکرد سیستم ارائه دهد.

سنجه‌های کلیدی مشاهده‌پذیری عبارت‌اند از:

• تأخیر P50/P95 ابزارها و نرخ Timeout/Cancellation.
• تعداد فراخوانی‌های موازی و نرخ موفقیت وظایف.
• تأخیر اولین پاسخ صوتی و مجموع زمان سکوت گفتگو.

این تغییر در Gemini Live API معیار موفقیت هوش مصنوعی صوتی را از «صحت پاسخ» به «روانی تعامل» تغییر می‌دهد و توسعه‌دهندگان را مجبور می‌کند از Wrapperهای ساده API به سمت ماشین‌های وضعیت (State Machines) پیچیده حرکت کنند که تنش بین داده‌های کند و گفتار سریع را مدیریت می‌کنند.

توسعه‌دهندگان اکنون باید مجموعه‌ابزارهای خود را بازبینی کنند تا شناس کنند کدام عملیات «خواندنی» را می‌توان به حالت ناهمگام منتقل کرد تا نرخ حفظ کاربر (User Retention) بهبود یابد. پیش از عرضه، تست‌ها باید پاسخ‌های کند، نتایج خارج از ترتیب، تزریق دستورات (Prompt Injection) و نوشتن‌های تکراری را پوشش دهند تا اطمینان حاصل شود که وضعیت نهایی کسب‌وکار حتی در صورت قطع شدن گفتگو، درست باقی می‌ماند.

گام بعدی شما

• لیست ابزارهای فعلی خود را بررسی کنید و عملیات «خواندنی» (Read) را به حالت Non-blocking منتقل کنید.
• یک سیستم مدیریت وضعیت (State Management) برای ردیابی وظایف Pending و Stale پیاده‌سازی کنید.
• سنجهٔ «زمان سکوت ادراک‌شده» را به جای تأخیر خام API در داشبورد نظارتی خود قرار دهید.

اما مدیریت حافظه در این تعاملات موازی چالش‌های جدیدی ایجاد می‌کند — به تحلیل ما درباره‌ی پنجره‌های متنی پویا مراجعه کنید.