QSOFT نفذت بوت RAG على YandexGPT لصالح Boiron من دون Python أو أدوات orchestration

شاركت QSOFT تفاصيل حول تنفيذ روبوت RAG قائم على Yandex Cloud Agent لشركة Boiron الدوائية. يعمل المساعد على موقع الويب الحالي مع PHP و WordPress، ويجيب على أسئلة المستخدمين على مدار الساعة، ويتولى جزءاً من الحمل الذي كان يذهب سابقاً إلى الدعم اليدوي.

لماذا كان هذا ضرورياً

تمتلك Boiron في روسيا فهرساً كبيراً وعقيداً: 130 تحضيراً معالجياً أحادي المكون و10 أدوية مركبة. بالنسبة للمستخدمين، المشكلة ليست فقط في عدد بطاقات المنتجات، بل في بنية المعرفة من حولها. يحتوي البوابة على أوصاف للمنتجات الفردية والمجموعات المواضيعية والأقسام الأكثر تعقيداً مثل "بروتوكول الأنف والأذن والحنجرة". لهذا السبب، لا يمكن مطابقة سؤال الزائر ببساطة مع منتج واحد حسب الكلمات الرئيسية: يجب على النظام أن يفهم السياق ويوجه المستخدم إلى القسم الصحيح في قاعدة المعرفة.

كان الحمل على الدعم أيضاً ملحوظاً. وفقاً لـ QSOFT، يتلقى الموقع أكثر من 300 ألف طلب سنوياً، أي أكثر من 800 يومياً. مع مثل هذا التدفق، لم يتم حل بعض الأسئلة على الفور، وضاعت بعض الاستفسارات، واضطر البعض الآخر إلى أن يتم التعامل معه يدوياً من قبل المتخصصين. للمواضيع الطبية، هذا مهم بشكل خاص: يتوقع المستخدم إجابة سريعة، لكن الإجابة يجب أن تعتمد على بيانات دقيقة وليس على الارتجال الحر للنموذج.

كيف تم بناء الحل

بدلاً من خدمة Python منفصلة وحلقة أوركسترا معقدة، استخدمت الفريق Yandex Cloud Agent مع نموذج YandexGPT ودمجت المساعد في مكدس PHP و WordPress الموجود. بشكل أساسي، هذا سيناريو RAG: يبحث الروبوت أولاً عن جزء ذي صلة في قاعدة المعرفة، ثم يصيغ إجابة للمستخدم. يقلل هذا النهج من خطر "الهلوسة" ويساعد على إبقاء الإجابات ضمن حدود المحتوى المتحقق منه، وهو أكثر أهمية للمنتجات الدوائية من الصياغة الجميلة.

حل المشروع عدة مهام عملية في وقت واحد:

• التطبيق بدون إعادة بناء كاملة للموقع والتخلي عن المكدس الحالي
• البحث في قاعدة معرفة طبية كبيرة مع مراعاة الروابط بين الأقسام
• معالجة الطلبات على مدار الساعة دون قائمة انتظار للمتخصصين
• تقليل عدد الطلبات المفقودة والمعالجة اليدوية

اختيار المعمارية نفسه مهم بشكل خاص. في العديد من مشاريع RAG، تنمو طبقة من الأوركسترز والخدمات الوسيطة والخطوط الأنابيب المخصصة بسرعة حول النموذج. هنا، اتخذ الفريق النهج المعاكس: حافظ أولاً على مجموعة CMS و backend العاملة، ثم أضاف طبقة وكيل فوقها. بالنسبة للعمل، هذا أبسط في الصيانة وأرخص في التطبيق وأوضح للفرق التي لديها بالفعل موقع ويب يعمل ولا ترغب في بناء منصة ML منفصلة من الصفر.

ما أعطاه التنفيذ

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

مجال التطبيق نفسه جدير بالملاحظة. في الطب والمجالات ذات الصلة، لا يمكن السماح للنموذج بالإجابة بحرية كاملة، لأن تكلفة الخطأ أعلى من التجارة الإلكترونية العادية. لذلك، حالة Boiron مثيرة للاهتمام ليس كعرض توضيحي لروبوت دردشة آخر، بل كمثال على تطبيق RAG الحذر في صناعة حساسة. لم تحاول الفريق تحويل المساعد إلى مستشار عام، بل حددته بقاعدة معرفة موثوقة ومهمة البحث الدقيق فيها.

ما معنى هذا

توضح حالة QSOFT أنه يمكن نشر الذكاء الاصطناعي التطبيقي للطب دون تغيير جذري في المكدس وبدون أوركسترا معقدة حول النموذج. إذا تم تنظيم قاعدة المعرفة جيداً وتم ضبط البحث فيها بعناية، حتى موقع ويب بسيط بـ PHP و WordPress يمكن أن يحصل على مساعد مفيد يجيب بشكل أسرع من الناس ولا يتجاوز حدود المحتوى المتحقق منه.