لماذا أطلقنا مساعد ذكاء اصطناعي داخل التطبيق، لا فوقه

مساعدان، وطلب واحد#

في عام 2022، كانت الطريقة الافتراضية لإضافة الذكاء الاصطناعي إلى تطبيق مؤسسي هي تركيب أداة محادثة فوق واجهة المستخدم القائمة. بعد ثلاث سنوات، لا تزال تلك البنية تُطرح كإجابة توافقية، ولا تزال تقدم إرشادات تنقّل عندما يريد المستخدمون اتخاذ إجراء. طرحت محللة ائتمان لدى مُقرض تجاري الربع الماضي السؤال نفسه على مساعدين اثنين — “أظهر لي الموردين الذين تم تأهيلهم خلال الثلاثين يوماً الماضية مع غياب نماذج ضريبية.” أنتج المساعد المضاف فقرة مهذبة حول كيفية التصفية. أنتج المساعد داخل وقت التشغيل القائمة المُصفاة، واحترم نطاق RBAC الخاص بها، وسجّل الاستعلام في مسار التدقيق خلال 22 ثانية.

الفرق ليس في النموذج. بل في ما يمكن للمساعد رؤيته.

ما الذي يعرفه فعلاً المساعد المُضاف#

تعيش معظم مساعدات الذكاء الاصطناعي المؤسسية طبقةً واحدة أعلى من التطبيق. إنها ترى DOM، وربما لقطة شاشة، وأي شيء يكتبه المستخدم. لا ترى الواصف. لا ترى نطاق الأذونات. لا ترى الاستعلام الذي شغّله الجدول للتو أو قواعد التحقق التي يفرضها النموذج. إنها تخمّن البنية ذاتها التي يحتفظ بها وقت التشغيل بالفعل في الذاكرة.

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

ما يستطيع المساعد داخل وقت التشغيل فعله#

عندما يكون المساعد جزءاً من الدرجة الأولى في وقت التشغيل، فإنه يقرأ الواصف مباشرة. يعرف أن الشاشة تحتوي على كيان مورّد، وحقل tax_form_status، وختم زمني created_at. يعرف أن نطاق RBAC للمستخدم الحالي يُقيّد النتائج بوحدة عمله. يعرف أن مكوّن التصفية يقبل مُسنداً مهيكلاً، لا سلسلة بلغة طبيعية.

لذا فإنه لا يكتب فقرة. بل يقترح مُرشِّحاً، ويُظهر للمستخدم ما هو بصدد القيام به، ويطبّقه عند الموافقة. تتقلص مساحة التفاعل من “تنقّل في التطبيق” إلى “أخبرني ماذا تريد.” كل إجراء يتخذه المساعد يمرّ عبر نفس مسارات التفويض والتدقيق التي تستخدمها واجهة المستخدم، لأنه هو واجهة المستخدم.

قصة الأمان أبسط لا أصعب#

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

لا نمنح المساعد أي صلاحية لا يمتلكها المستخدم. النموذج اللغوي الكبير محرّك اقتراحات. ووقت التشغيل طبقة التنفيذ. إذا لم يكن بإمكان المستخدم اعتماد فاتورة بقيمة 50,000 دولار، فلا يمكن للمساعد الذي يتصرف نيابة عنها ذلك أيضاً. يسجل سجل التدقيق كلاً من الإنسان والنموذج كمشاركَين في الإجراء.

لماذا يصعب إضافة هذا لاحقاً#

بناء هذا النمط في تطبيق مؤسسي قائم مكلف لأن معظم التطبيقات المؤسسية لا تمتلك واصفاً لتقرأه. ليس لدى المساعد شيء مهيكل يرتبط به، لذا يتراجع إلى DOM، وتتبع ذلك القيود.

هذا أحد الأسباب التي دفعتنا إلى تصميم الواصف ووقت التشغيل قبل المساعد. المساعد يكاد يكون نتيجة للبنية بدلاً من منتج مُضاف إليها. بمجرد أن تكون كل شاشة واصفاً، يمكن للمساعد الذي يقرأ ويكتب الواصفات أن يعمل عبر التطبيق بأكمله دون تكامل لكل شاشة.

ما يلاحظه المستخدمون#

التغيّر في السلوك مرئي في الجلسة الأولى. يتوقف المستخدمون عن سؤال المساعد عن أماكن الأشياء. يبدؤون في طلب النتائج. “اعثر على الموردين الثلاثة المُعلَّمين بتفاصيل مصرفية مكررة.” “ابدأ سير عمل تجديد للعقود التي تنتهي في مايو.” “صدِّر هذا العرض المُصفّى إلى التنسيق الذي يستخدمه قسم المالية.”

تُظهر بيانات الاستخدام الداخلية من التجارب المبكرة أن حوالي 70% من تفاعلات المساعد تُحوّل إلى إجراء ملموس يُتخذ نيابة عن المستخدم، مقارنة بأقل من 20% في نمط الإضافة الذي اختبرناه مقابله. التفاعلات المتبقية توضيحية، وحتى تلك تسحب من الواصف بدلاً من مجموعة مساعدة عامة.

الخلاصة#

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