Randall Newman، CPTO والمؤسس المشارك لشركة Satisfi Labs – سلسلة المقابلات

Randall Newman، CPTO والمؤسس المشارك لشركة Satisfi Labs، هو قائد تقني ومنتجات يمتلك خبرة واسعة في بناء منصات الذكاء الاصطناعي، التكنولوجيا المالية، وأنظمة عالية الأداء. منذ تأسيسه لشركة Satisfi Labs، لعب Newman دورًا محوريًا في تصور وتصميم وتوسيع تقنية الذكاء الاصطناعي الحوارية للشركة، بينما كان يشرف على تطوير المنتجات، والهندسة المعمارية، وفرق الهندسة، والتكاملات الإستراتيجية. قبل Satisfi Labs، شغل منصب رئيس المنتج في Satisfi Inc. وأسّس شركة التسويق المتنقل Right On Mobile. في مرحلة سابقة من مسيرته، قضى Newman أكثر من 17 عامًا في CIBC World Markets، حيث تولى مناصب قيادية عليا شملت المخاطر الإستراتيجية، التداول عالي التردد، والمراجحة في الأسهم، جامعًا بين خبرة التداول الكمي وتطوير التكنولوجيا العملية.

Satisfi Labs هي شركة ذكاء اصطناعي تركز على نشر وكلاء ذكاء اصطناعي متخصصين للرياضة، والترفيه، والسياحة، والمعالم، وغيرها من أعمال التجارب الحية. تأسست الشركة في عام 2016، وتطورت من الذكاء الاصطناعي الحواري ومحرك الإجابة إلى منصة وكيلة صممت لمساعدة المؤسسات على أتمتة دعم الضيوف، وزيادة تحويلات التذاكر والتجارة، واستخلاص الرؤى من محادثات العملاء. يمكن لوكلائها الذكاء الاصطناعي العمل بأكثر من 50 لغة والاتصال بأنظمة التذاكر، وإدارة علاقات العملاء (CRM)، وإدارة المحتوى، وغيرها من أنظمة الأعمال لتنفيذ إجراءات مثل بيع التذاكر، وتصعيد المحادثات إلى الموظفين البشر، وجمع معلومات العملاء، وتقديم ردود مخصصة. تقول Satisfi Labs إن تقنيتها موثوقة الآن من قبل أكثر من 775 علامة تجارية، مع تكاملات وشراكات تشمل شركات مثل Ticketmaster، Simpleview، MappedIn، Ventrata، وVozzi.

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

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

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

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

الدرس الأخير هو ذلك الذي بدأ كل الأعمال. الميزة تأتي من اكتشاف التسعير غير الصحيح قبل أن يفعله الآخرون. أعتقد أن التسعير غير الصحيح الآن هو أن معظم الشركات تنظر إلى وكلاء الذكاء الاصطناعي كوسيلة لتقليل تكاليف الدعم. في Satisfi Labs، نراهم كقناة إيرادات. في أماكننا الرياضية، حوالي 40٪ من محادثات الوكلاء تتعلق بالتذاكر. هؤلاء المشجعون لا يأتون لتقديم شكاوى. إنهم يأتون ومعهم المال في يدهم، يسألون عن مكان الجلوس. ابحث عن ما يسعِره السوق بصورة خاطئة، وابدأ في الاستحواذ عليه. نفس الحدس كما في أعمال المراجحة.

تأسست Satisfi Labs في عام 2017، قبل ازدهار الذكاء الاصطناعي التوليدي الحالي بوقت طويل، وتطورت من معالجة اللغة الطبيعية السياقية والذكاء الاصطناعي الحواري إلى منصة وكيلة. ما هي أكبر التغييرات المعمارية المطلوبة للانتقال من الأنظمة المصممة أساسًا للإجابة على الأسئلة إلى الوكلاء القادرين على اتخاذ إجراءات نيابة عن المستخدمين؟

قضينا عقدًا من الزمن في بناء آلاف الوكلاء الذكاء الاصطناعي لأكثر من 800 عميل مؤسسي بما في ذلك فرق MLB/NFL، وأماكن الترفيه، ومنظمات السياحة. أكبر تغيير هو أنك تمنح النظام السلطة، وليس مجرد المعلومات.

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

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

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

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

يُستخدم الآن مصطلح “الذكاء الاصطناعي الوكالي” لتغطية مجموعة واسعة من المنتجات. من منظور هندسي، أين ترسم الخط الفاصل بين روبوت محادثة متقدم، ومساعد ذكاء اصطناعي، ووكيل ذكاء اصطناعي ذاتي الاستقلالية حقًا؟

سأطرح سؤالًا واحدًا: ما المسؤولية التي delegatedها الشخص فعليًا؟

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

الواجهة لا تخبرك أيًا مما تنظر إليه. يمكن لمنتج محادثة أن يمتلك استقلالية حقيقية خلفه. شيء يُسوّق كوكيل قد يظل بحاجة إلى موافقة شخص على كل إجراء مفيد.

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

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

أطلقت Satisfi Labs مؤخرًا Satisfi Forward، ممارسة هندسية مُنشرة مسبقًا. ما الفجوة التي رأيتها بين بناء منصة ذكاء اصطناعي قادرة وبين جعل الوكلاء يعملون بموثوقية داخل بيئة العميل الواقعية التي دفعتك لإنشاء هذا النموذج؟

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

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

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

أصبح إنتاج الكود أرخص كثيرًا، مما يجعل هذا النموذج أكثر عملية مما كان عليه في السابق. لكنني لا أرى Satisfi Forward كذراع خدمات مرفقة بمنتج SaaS. كل مشاركة تعلمنا ما يجب أن يكون عليه المنتج التالي. عندما يطلب ثلاثة عملاء نفس سير العمل، فهذا ليس عبئًا على الدعم. بل هو كتابة خارطة الطريق نفسها، مع وجود عملاء يدفعون. النموذج القديم لـ SaaS كان يخمن الميزات وينتظر الأدلة. بهذه الطريقة نحصل على الأدلة أولًا، والإيرادات أثناء جمعها. أعتقد أن هذا هو ما يبني به شركات المنتجات في عصر الذكاء الاصطناعي.

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

أولًا، لن أسمح أبدًا للسرعة أن تعوض فشلًا أمنيًا. بعض المتطلبات هي قيود. تقوم بالتحسين ضمن هذه القيود.

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

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

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

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

يصف Satisfi Labs نموذجًا يمكن فيه للوكلاء المتخصصين العمل معًا كقوة عمل ذكاء اصطناعي. ما هي أصعب المشكلات التقنية المتعلقة بتنظيم عدة وكلاء متخصصين، خاصةً فيما يتعلق بالتوجيه، والسياق المشترك، والقرارات المتضاربة، وتحديد أي وكيل يجب أن يتصرف؟

أصعب جزء هو الحفاظ على المساءلة أثناء توزيع العمل.

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

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

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

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

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

تركز Satisfi Labs بشكل متزايد على قياس الوكلاء مقابل الأهداف والنتائج التجارية بدلاً من مقاييس مثل حجم المحادثات. ما الذي يجب على المؤسسات قياسه فعليًا لتحديد ما إذا كان وكيل الذكاء الاصطناعي يؤدي أداءً جيدًا، وكيف تقيم الموثوقية قبل السماح للوكيل بتمتع بسلطة أكبر؟

ابدأ بالنتيجة التجارية، ثم اسأل كم من تلك النتيجة تسبب فيها الوكيل فعليًا.

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

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

تحتاج الموثوقية إلى بطاقة تقييم خاصة بها. الإكمال، الدقة، الإجراءات غير المصرح بها، التعافي من الفشل، جودة التصعيد. لا يمكنك دمج حادث خصوصية خطير في معدل تحويل جيد.

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

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

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

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

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

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

بعض هذه الأمور تحتاج إلى نماذج أفضل. الكثير منها يحتاج إلى تكامل وتصميم تفاعل أفضل. الانتظار لحدوث اختراق لن يحل مشكلة سير عمل صُمم حول النص ثم يُقرأ بصوت عالٍ. سأقَيِّم التقدم بهذه الطريقة: هل يكمل الناس المهمة بدقة، وبجهد أقل، تحت ظروف واقعية؟

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

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

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

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

موافقة العميل وموافقة الشركة أمران مختلفان، بالمناسبة. تأكيد العميل للشراء لا يمنح الوكيل صلاحية تجاوز سياسات الشركة. موافقة الموظف على استثناء لا تعني أن العميل وافق على الرسوم.

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

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

أعتقد أن البروتوكولات وسيلة لتحقيق هدف. يمنح MCP تطبيقات الذكاء الاصطناعي طريقة مشتركة للوصول إلى الأدوات والسياق. تتعامل بروتوكولات الوكيل إلى الوكيل مع التعاون بين الوكلاء. هذا ذو قيمة. لا ينبغي عليك بناء تكامل مخصص في كل مرة يحتاج فيها الوكيل إلى أداة. إنه مشابه لما فعلته واجهات برمجة التطبيقات (APIs) لتكاملات البرمجيات.

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

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

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

شكرًا لك على المقابلة الرائعة، القراء الذين يرغبون في معرفة المزيد يجب أن يزوروا Satisfi Labs.