موثوقية مكالمات أقوى وأذكى: أنظمة احتياطية لـ ASR وLLM

يعمل نظام Retell الصوتي كسلسلة حيّة من ثلاث خطوات أساسية. وكل خطوة تعتمد على الخطوة التي تسبقها.

ASR ← LLM ← TTS

ASR (التعرّف التلقائي على الكلام) يستمع إلى المتصل ويحوّل كلامه إلى نص.

LLM (نموذج اللغة) يقرأ ذلك النص، ويفهم ما قيل، ويقرّر ما الذي سيردّ به.

TTS (تحويل النص إلى كلام) يأخذ ذلك الردّ ويحوّله إلى صوت منطوق يسمعه المتصل.

إذًا فإنّ التدفّق هو أساسًا: يتحدّث المتصل ← يفرّغ ASR كلامه نصًّا ← يولّد LLM ردًّا ← ينطقه TTS مجددًا.

عندما يكون أحدهم في مكالمة، يمثّل كل من نظامي ASR وLLM النظامين الحرجين اللذين يعملان في الوقت الفعلي. وكلاهما قد يفشل أو يتباطأ أو يتصرّف بشكل غير متوقّع. نحتاج إلى أن نكون قادرين على الاعتماد على عمل النظامين معًا، لذا بنينا منظومة تراقب باستمرار وتنشئ نسخًا احتياطية وتبدّل في الوقت الفعلي. وإليك كيف يعمل الاثنان معًا ولماذا تهمّ هذه التحديثات:

أولًا، نراقب التأخّر (لا الفشل)

نطرح باستمرار سؤالًا بسيطًا واحدًا: "هل يواكب النظام المحادثة؟" كل 0.1 ثانية، نقارن:

• كمية الصوت التي أرسلناها
• كمية الصوت التي جرت معالجتها فعليًا

إذا اتّسعت الفجوة إلى أكثر من 5 ثوانٍ، فتلك إشارتنا: هذا المزوّد يتخلّف عن الركب. ليس معطّلًا. وليس منهارًا. لكنه في طريقه إلى ذلك. وعندها نتحرّك.

نحتفظ بـ "شبكة أمان" حيّة لصوتك

أثناء معالجة الصوت، نحتفظ بنسخة احتياطية متجدّدة لأي شيء لم تتمّ معالجته بالكامل بعد. تخيّل الأمر هكذا:

• إذا أكّد النظام أنه عالج شيئًا ما ← نتخلّص منه
• إذا لم يفعل بعد ← نحتفظ به

وهكذا في أي لحظة، تكون لدينا نسخة مثالية من الصوت "البيني"، وهو الجزء الأكثر عرضة للضياع. بلا تخمين. وبلا فجوات.

ثم نستبدله بنسخة احتياطية

لحظة اكتشافنا للتأخّر، لا ننتظر. نقوم بما يلي:

• نشغّل مزوّدًا احتياطيًا (هناك ترتيب أولوية: الأسرع، الأقرب، الأكثر موثوقية أولًا)
• نرسل كل ذلك الصوت "المعلّق" ليتمكّن من اللحاق بالركب
• نوقف تشغيل المزوّد المتعثّر

كما نمنح المزوّد الجديد فترة سماح قصيرة (~20 ثانية) ليستقرّ قبل أن نبدأ بتقييم أدائه.

والنتيجة؟

النصّ التفريغي فقط… يستمرّ. بلا قفزة. بلا رجوع. بلا فجوات غريبة. من منظور المتصل، لم يحدث شيء.

لماذا يهمّ هذا

معظم الأنظمة تنتظر حتى ينهار المزوّد بالكامل قبل التبديل.

نحن لا نفعل ذلك. نلتقط اللحظة التي يبدأ فيها بالتعثّر ونستبدله قبل أن يصبح مشكلة أصلًا.

الخلاصة

• لا ننتظر الفشل
• نكتشف التباطؤ في الوقت الفعلي
• نحفظ كل ثانية من الصوت
• نبدّل المزوّدين بسلاسة

وهكذا تستمرّ المحادثة في التدفّق تمامًا كما ينبغي.

LLM: من التوجيه على مستوى المزوّد إلى التوجيه على مستوى النشر

كيف تعمل أنظمتنا الاحتياطية لـ LLM

الآن على جانب الردّ، ليس الفشل بهذا الوضوح. إنه أكثر دقّة. لكل نموذج LLM (مثل GPT-4.1) لدينا مجموعة من "عمليات النشر" التي تخدم ذلك النموذج. تخيّل عملية النشر كمركز بيانات فعلي. عندما نريد توليد ردّ بالذكاء الاصطناعي—أو استرجاع سياق مؤسَّس من LLM Knowledge Graph لتحسين الدقّة وتقليل الهلوسات—نحتاج إلى تحديد عملية نشر معيّنة لمعالجة ذلك الطلب.

خلف الكواليس، هناك بضعة أجزاء متحرّكة وقد يصبح الأمر معقّدًا بعض الشيء، لكن الفكرة الأساسية بسيطة:

نوجّه إلى عمليات النشر ذات زمن الاستجابة الأقل

يضمن ذلك توليد الردود بشكل أسرع ويقلّل التأخّر للحفاظ على تزامن المحادثات في الوقت الفعلي.

نقيس ونراقب باستمرار & معدّل الأخطاء لكل عملية نشر

ونقطع حركة البيانات عن تلك التي لديها معدّلات أخطاء مرتفعة.

لدينا حاجة للسرعة عند إرسال طلب إلى عملية نشر

إذا كانت بطيئة، لا ننتظر. نرسل الطلب إلى مكان آخر ونستمرّ حتى يستجيب أحدها.

ليفز أفضل نموذج ذكاء اصطناعي

إذا فشل نموذج عبر عمليات نشر متعدّدة، لا نستمرّ في تجربته. نبدّل إلى نموذج آخر ونستمرّ.

الخلاصة

نحن لا نعتمد على نموذج واحد أو مزوّد واحد.

نحن باستمرار:

• نوجّه إلى الخيار الأفضل
• نتجنّب ما يفشل
• نتسابق نحو ردود أسرع
• ونبدّل عند الحاجة

وهكذا حتى عندما تمرّ الأنظمة بيوم سيّئ، لا تمرّ محادثاتك به.