دليل اللعب الأكثر اكتمالاً للوكيل: المشاهد والذكريات والابتكارات التفاعلية

تم تجميعه بواسطة: جيايو، كيج

< p style="text-align: left;">يعد AI Agent تغييرًا نموذجيًا نتتبعه عن كثب من خلال سلسلة مقالات Langchain التي تساعد على الفهم اتجاهات الوكيل مفيدة. في هذا التجميع، الجزء الأول هو تقرير حالة وكيل الذكاء الاصطناعي الصادر عن فريق Langchain. لقد أجروا مقابلات مع أكثر من 1300 متخصص، بما في ذلك المطورين ومديري المنتجات والمديرين التنفيذيين للشركة، وكشفوا عن الوضع الحالي واختناقات تنفيذ Agent هذا العام: 90% من الشركات لديها خطط واحتياجات لوكلاء الذكاء الاصطناعي، ولكن قدرات الوكلاء محدودة تسمح القيود للمستخدمين بتنفيذها فقط في عدد قليل من العمليات والسيناريوهات. بدلاً من التكلفة ووقت الاستجابة، يهتم الجميع أكثر بتحسين قدرات الوكيل وإمكانية ملاحظة سلوكه والتحكم فيه.

في الجزء الثاني، قمنا بتجميع تحليل العناصر الرئيسية لـ AI Agent في سلسلة المقالات In the Loop على موقع LangChain الرسمي : إمكانات التخطيط وابتكار تفاعل واجهة المستخدم/تجربة المستخدم وآليات الذاكرة. تحلل هذه المقالة طرق التفاعل لخمسة منتجات أصلية من LLM، وتماثل 3 آليات معقدة للذاكرة البشرية، وتوفر بعض الإلهام لفهم AI Agent وهذه العناصر الأساسية. في هذا الجزء، أضفنا أيضًا بعض دراسات الحالة التمثيلية لشركة Agent، مثل المقابلات مع مؤسسي Reflection AI، للتطلع إلى الإنجازات الرئيسية لـ AI Agent في عام 2025.

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

01. اتجاهات استخدام الوكيل:

تخطط كل شركة لنشر الوكيل

أصبحت المنافسة في مجال الوكيل شرسة. على مدار العام الماضي، أصبحت العديد من أطر عمل الوكلاء شائعة: على سبيل المثال استخدام ReAct مع LLM للتفكير والعمل، أو استخدام أطر عمل متعددة الوكلاء للتنسيق، أو استخدام أطر عمل أكثر قابلية للتحكم مثل LangGraph.

الضجة حول Agent ليست مجرد ضجيج على Twitter. ما يقرب من 51٪ من المشاركين يستخدمون حاليًا الوكيل في الإنتاج. وفقًا لبيانات Langchain حسب حجم الشركة، فإن الشركات المتوسطة الحجم التي تضم 100-2000 موظف هي الأكثر نشاطًا في وضع العميل في الإنتاج، بنسبة 63%.

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

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

حالات الاستخدام الأكثر شيوعًا للوكيل

حالات الاستخدام الأكثر شيوعًا للوكيل حالات الاستخدام المستخدمة تشمل حالات الاستخدام إجراء البحث والتلخيص (58%)، يليه تبسيط إجراءات العمل من خلال وكلاء مخصصين (53.5%).

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

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

المراقبة: تتطلب تطبيقات الوكيل إمكانية المراقبة والتحكم

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

عند اختبار تطبيقات LLM، يتم استخدام التقييم خارج الإنترنت (39.8%) أكثر من التقييم عبر الإنترنت (32.5%)، مما يعكس صعوبة مراقبة LLM في الوقت الفعلي. من بين الاستجابات المفتوحة التي تقدمها LangChain، لدى العديد من الشركات أيضًا خبراء بشريون يقومون بمراجعة الاستجابات أو تقييمها يدويًا كطبقة إضافية من الوقاية.

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

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

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

العوائق والتحديات في وضع الوكيل في مرحلة الإنتاج

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

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

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

تنتشر المشكلات الأمنية أيضًا في الشركات الكبيرة التي تتطلب امتثالًا صارمًا وتتعامل مع بيانات العملاء بحساسية.

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

موضوعات ناشئة أخرى

في الأسئلة المفتوحة، هناك الكثير من الثناء على القدرات التي أظهرها AI Agent:

• إدارة المهام متعددة الخطوات: AI Agent قادر على أداء تفكير أعمق وإدارة السياق، وتمكينهم من التعامل مع المهام الأكثر تعقيدًا؛

• أتمتة المهام المتكررة: لا يزال يُنظر إلى وكلاء الذكاء الاصطناعي على أنهم مفتاح للتعامل مع المهام الآلية، والتي يمكن أن توفر وقت المستخدمين لحل المزيد من المشكلات الإبداعية؛

• تخطيط المهام والتعاون: يضمن التخطيط الأفضل للمهام أن يتعامل الوكيل المناسب مع المشكلة الصحيحة في الوقت المناسب، خاصة في الأنظمة متعددة الوكلاء؛

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

بالإضافة إلى ذلك، هناك تطوران يتطلع إليهما الجميع كثيرًا:

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

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

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

02.العناصر الأساسية في AI Agent

ما هو نظام الوكيل

قبل إصدار تقرير حالة وكيل الذكاء الاصطناعي، كان فريق Langchain قد كتب بالفعل في مجال الوكيل قام بتطوير إطار عمل Langraph الخاص به وناقش الكثير من الذكاء الاصطناعي عبر مدونة In the Loop المكونات الرئيسية في Agent، والخطوة التالية هي تجميع المحتويات الرئيسية.

أولاً وقبل كل شيء، لدى كل شخص تعريف مختلف قليلاً لعامل الذكاء الاصطناعي، قدم هاريسون تشيس، مؤسس LangChain، التعريف التالي:

AI Agent هو نظام يستخدم LLM لاتخاذ قرارات التحكم في تدفق البرنامج.

وكيل الذكاء الاصطناعي هو نظام يستخدم LLM لتحديد تدفق التحكم في التطبيق.

أما بالنسبة لتطبيقه، يقدم المقال مفهوم العمارة المعرفية وتشير إلى كيفية تفكير الوكيل وكيفية ترتيب النظام للكود/الموجه LLM:

• المعرفي: استخدامات الوكيل LLM للاستدلال الدلالي حول كيفية ترتيب التعليمات البرمجية/مطالبة LLM؛

• الهندسة المعمارية: لا تزال أنظمة الوكيل هذه تتضمن الكثير من الهندسة المشابهة لهندسة النظام التقليدية.

الصورة أدناه توضح أمثلة لمستويات مختلفة من العمارة المعرفية:

• رمز البرنامج الموحد (الكود): كل شيء عبارة عن كود ثابت ، يتم إصلاح معلمات الإخراج أو الإدخال ذات الصلة مباشرة في الكود المصدري، وهذا لا يشكل بنية معرفية لأنه لا يوجد جزء معرفي؛

•  مكالمة LLM، باستثناء بعض المعالجة المسبقة للبيانات، تشكل مكالمة LLM واحدة غالبية التطبيق، وينتمي Chatbot البسيط إلى هذه الفئة؛

• Chain : سلسلة من مكالمات LLM، سلسلة حاول تقسيم حل المشكلة إلى عدة خطوات واستدعاء LLMs مختلفين لحل المشكلة. تندرج RAGs المعقدة ضمن هذه الفئة: يتم استدعاء LLM الأول للبحث والاستعلام، ويتم استدعاء LLM الثاني لإنشاء الإجابات؛

• جهاز التوجيه: في في الأنظمة الثلاثة السابقة، يمكن للمستخدمين معرفة جميع الخطوات التي سيتخذها البرنامج مسبقًا، ولكن في جهاز التوجيه، تقرر LLM بنفسها أي LLM يجب الاتصال به وما هي الخطوات التي يجب اتخاذها، مما يضيف المزيد من العشوائية وعدم القدرة على التنبؤ style="text-align: left;">• State Machine، الجمع بين LLM وجهاز التوجيه سيكون غير قابل للتنبؤ به، لأنه مع دمج هذا في حلقة، يمكن للنظام (نظريًا) إجراء مكالمات LLM غير محدودة؛

• نظام الوكيل: يطلق عليه الجميع أيضًا اسم "الوكيل المستقل" ويستخدم آلة الحالة لا تزال هناك قيود على الإجراءات التي يمكن اتخاذها والعمليات التي يتم تنفيذها بعد اتخاذ هذا الإجراء؛ تتم إزالة هذه القيود عند استخدام الوكيل المستقل. LLM لتحديد الخطوات التي يجب اتخاذها وكيفية تنسيق LLMs المختلفة ويمكن القيام بذلك باستخدام مطالبات أو أدوات أو تعليمات برمجية مختلفة.

ببساطة، كلما كان النظام أكثر "وكيلًا"، كلما حددت LLM كيفية تصرف النظام.

العناصر الأساسية للوكيل

التخطيط< /strong>

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

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

يستخدم المطورون في كثير من الأحيان استدعاء الوظائف للسماح لـ LLM باختيار العملية التي سيتم تنفيذها. استدعاء الوظائف هو إمكانية أضافتها OpenAI لأول مرة إلى LLM API في يونيو 2023. باستخدام استدعاء الوظائف، يمكن للمستخدمين توفير هياكل JSON لوظائف مختلفة والسماح لـ LLM بمطابقة واحدة (أو أكثر) من هذه الهياكل.

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

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

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

1

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

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

2. العمارة المعرفية في مجالات محددة

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

تعطي ورقة بحثية من AlphaCodium مثالاً محددًا: باستخدام ما يسمونه "هندسة التدفق" (طريقة أخرى للحديث عن البنية المعرفية). حقق الأداء الفني.

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

دراسة حالة:

التأمل مؤسس الذكاء الاصطناعي لاسكينرؤية لمستقبل العميل

انعكاس مؤسس الذكاء الاصطناعي ميشا في سيكويا كابيتال في مقابلة مع لاسكين، ميشا يُذكر أنه بدأ في تحقيق رؤيته لبناء أفضل نماذج الوكلاء في شركته الجديدة، Reflection AI، من خلال الجمع بين إمكانات البحث الخاصة بـ RL وLLM. يعد هو والمؤسس المشارك إيوانيس أنتونوغلو (رئيس AlphaGo وAlphaZero وGemini RLHF) نماذج تدريب مصممة لسير عمل Agentic. النقاط الرئيسية في المقابلة هي كما يلي:

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

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

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

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

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

تفاعل واجهة المستخدم/UX

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

1. التفاعل التحادثي (واجهة مستخدم الدردشة)

تنقسم الدردشة عمومًا إلى نوعين: الدردشة المتدفقة والدردشة غير المتدفقة.

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

لكن الدردشة المتدفقة لها عيوبها أيضًا. أولاً، يعد بث الدردشة تجربة مستخدم جديدة نسبيًا، لذا فإن منصات الدردشة الحالية لدينا (iMessage، وFacebook Messenger، وSlack، وما إلى ذلك) لا تتمتع بها؛ ثانيًا، بالنسبة للمهام طويلة الأمد، يعد هذا أمرًا محرجًا بعض الشيء، هل يفعل المستخدم ذلك؟ هل يتعين عليك فقط الجلوس هناك ومشاهدة عمل الوكيل؟ ثالثًا، عادةً ما يلزم تشغيل الدردشة المباشرة بواسطة الإنسان، مما يعني أن هناك حاجة إلى الكثير من البشر في الحلقة.

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

لهاتين الطريقتين للدردشة المزايا والعيوب التالية:

2. بيئة الخلفية (تجربة المستخدم المحيطة)

< ف نمط = "محاذاة النص: left;">سوف يفكر المستخدمون في إرسال رسائل إلى الذكاء الاصطناعي، وهو الدردشة المذكورة أعلاه، ولكن إذا كان الوكيل يعمل فقط في الخلفية، فكيف نتفاعل مع الوكيل؟

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

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

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

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

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

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

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

3. تجربة المستخدم لجدول البيانات

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

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

تستخدم منتجات Exa AI وClay AI وManaflow وغيرها من منتجات الشركات تجربة المستخدم هذه. يستخدم ما يلي Manaflow كمثال لإظهار كيفية تعامل جدول البيانات هذا مع تجربة المستخدم سير العمل.

دراسة حالة:

Manaflow كيفية الاستخدامجداول البيانات لتفاعل الوكيل

تم استلهام Manaflow من شركة Minion AI، وهي شركة عمل مؤسسها لورانس ذات يوم. المنتج الذي صممته شركة Minion AI هو وكيل الويب. يمكن لوكيل الويب التحكم في Geogle Chrome المحلي، مما يسمح له بالتفاعل مع التطبيقات مثل حجز الرحلات الجوية وإرسال رسائل البريد الإلكتروني وجدولة غسيل السيارات والمزيد. استنادًا إلى إلهام Minion AI، اختار Manaflow السماح للوكيل بتشغيل أدوات تشبه جداول البيانات، وذلك لأن Agent ليس جيدًا في معالجة واجهات واجهة المستخدم البشرية، وما يجيده Agent حقًا هو البرمجة. لذلك، يسمح Manaflow للوكيل باستدعاء برنامج Python النصي لواجهة واجهة المستخدم، وواجهة قاعدة البيانات، وواجهة برمجة تطبيقات الارتباط، ثم تشغيل قاعدة البيانات مباشرة: بما في ذلك وقت القراءة، والحجز، وإرسال رسائل البريد الإلكتروني، وما إلى ذلك.

سير العمل كما يلي: الواجهة الرئيسية لبرنامج Manaflow عبارة عن جدول بيانات (Manasheet)، حيث يمثل كل عمود خطوة في سير العمل ويتوافق كل صف مع وكيل التنفيذ AI للمهمة. يمكن برمجة كل سير عمل في جدول البيانات باستخدام اللغة الطبيعية (مما يسمح للمستخدمين غير التقنيين بوصف المهام والخطوات باللغة الطبيعية). يحتوي كل جدول بيانات على رسم بياني تبعية داخلي يحدد الترتيب الذي يتم به تنفيذ كل عمود. سيتم تعيين هذه التسلسلات لكل صف من الوكلاء لتنفيذ المهام بالتوازي والتعامل مع العمليات مثل تحويل البيانات واستدعاءات واجهة برمجة التطبيقات واسترداد المحتوى وإرسال الرسائل:

< img src="https ://img.jinse.cn/7339151_image3.png">

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

4. واجهة المستخدم التوليدية (واجهة المستخدم التوليدية)

هناك هناك تطبيقان مختلفان لـ "واجهة المستخدم التوليدية".

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

هناك طريقة أخرى أكثر تقييدًا وهي التحديد المسبق لبعض مكونات واجهة المستخدم، عادةً من خلال استدعاءات الأدوات. على سبيل المثال، إذا قامت LLM باستدعاء Weather API، فإنها تقوم بتشغيل عرض مكون Weather Map UI. نظرًا لأن المكونات المعروضة لم يتم إنشاؤها فعليًا (ولكن بها المزيد من الخيارات)، فإن واجهة المستخدم التي تم إنشاؤها ستكون أكثر دقة، على الرغم من أنها ليست مرنة تمامًا فيما يمكن أن تنشئه.

دراسة حالة:

منتجات الذكاء الاصطناعي الشخصية dot

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

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

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

• مراسل الشركة السريعة مارك أمضى ويلسون أيضًا عدة أشهر مع Dot. ذات مرة، شارك مع Dot حرف "O" الذي كتبه في فصل الخط الخاص به. قام Dot بالفعل بالتقاط صورة لحرف "O" المكتوب بخط يده قبل بضعة أسابيع وأشاد بخطه لتحسينه.

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

يمكنك أن ترى أنه في مثال توصية المقهى هذا، يقوم Dot بتمرير الإعداد المسبق تحديد مكونات واجهة المستخدم لتحقيق تأثيرات تفاعلية أصلية في LLM.

5. تجربة المستخدم التعاونية

ماذا يحدث عندما يكون الوكلاء و البشر يعملون معا؟ فكر في محرّر مستندات Google، حيث يمكن للعملاء التعاون مع أعضاء الفريق لكتابة المستندات أو تحريرها، ولكن ماذا لو كان أحد المتعاونين وكيلًا؟

يتعاون جيفري ليت وInk & Switch في مشروع Patchwork مثال عظيم للتعاون بين الإنسان والوكيل. (ملاحظة المترجم: قد يكون هذا مصدر إلهام لتحديث منتج OpenAI Canvas الأخير).

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

• في تجربة المستخدم التعاونية، العميل و غالبًا ما يعمل LLM في وقت واحد، مع أخذ عمل الآخر كمدخل؛

• في Ambient UX ، يكون LLM في الخلفية. يستمر العمل بينما يركز المستخدم على شيء آخر تمامًا.

الذاكرة

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

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

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

< قوي> 1. الذاكرة الإجرائية: الذاكرة طويلة المدى حول كيفية أداء المهام، على غرار مجموعة التعليمات الأساسية للدماغ

• الذاكرة الإجرائية البشرية: تذكر كيف لركوب الدراجة.

• ذاكرة برنامج الوكيل: تصف ورقة CoALA ذاكرة البرنامج بأنها مزيج من أوزان LLM ورمز الوكيل، والتي تحدد بشكل أساسي كيفية عمل الوكيل.

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

2. الذاكرة الدلالية: احتياطي المعرفة طويل الأمد

• الذاكرة الدلالية للإنسان: وتتكون من أجزاء من المعلومات، مثل الحقائق، والمفاهيم التي تعلمها في المدرسة، والعلاقات بينها.

• الذاكرة الدلالية للوكيل: تصف ورقة CoALA الذاكرة الدلالية بأنها مستودع للحقائق.

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

3. الذاكرة العرضية: استدعاء أحداث سابقة محددة

• الذاكرة العرضية عند الإنسان: عندما يتذكر الشخص حدثًا معينًا (أو "حلقة") مر بها في الماضي.

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

يُستخدم هذا بشكل أساسي للسماح للوكيل بتنفيذ الإجراءات كما هو متوقع. من الناحية العملية، يتم تحديث الذاكرة العرضية من خلال طريقة Few-Shots Prompt. إذا كان هناك ما يكفي من مطالبات Few-Shots للتحديثات ذات الصلة، فسيتم إكمال التحديث التالي من خلال مطالبات Dynamic Few-Shots.

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

بالإضافة إلى مراعاة نوع الذاكرة التي سيتم تحديثها في الوكيل، يحتاج المطور أيضًا إلى مراعاة كيفية تحديث ذاكرة الوكيل:

< p style="text -align: left;">الطريقة الأولى لتحديث ذاكرة العميل هي "في المسار السريع". في هذه الحالة، يتذكر نظام الوكيل الحقائق (عادةً من خلال استدعاءات الأدوات) قبل الاستجابة، ويتبع ChatGPT هذا الأسلوب لتحديث ذاكرته؛

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

مقارنة بين الطريقتين، فإن عيب أسلوب "في المسار السريع" هو وجود بعض التأخير قبل تسليم أي استجابة، ويتطلب أيضًا الجمع بين منطق الذاكرة ومنطق الوكيل.

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

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

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