A16Z: هندسة معمارية ناشئة لتطبيقات النماذج الكبيرة

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

مصدر الصورة: تم إنشاؤه بواسطة Unbounded AI

تعد نماذج اللغات الكبيرة (LLMs) من العناصر الأساسية الجديدة القوية لتطوير البرامج. ولكن نظرًا لأن LLM جديدة جدًا وتتصرف بشكل مختلف تمامًا عن موارد الحوسبة العادية ، فليس من الواضح دائمًا كيفية استخدام LLM.

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

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

تكنولوجيا LLM المكدس

يبدو الإصدار الحالي من مكدس تطبيقات LLM كما يلي:

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

فيما يلي قائمة بالارتباطات لكل عنصر للرجوع إليها بسرعة:

، أدوات / أنظمة مشتركة لكل مكون رئيسي من مكدس التطبيقات

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

القسم التالي يشرح بإيجاز نمط التصميم هذا.

نمط التصميم: التعلم السياقي

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

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

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

على مستوى عالٍ جدًا ، يمكن تقسيم سير العمل هذا إلى ثلاث مراحل:

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

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

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

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

معالجة البيانات / التضمين

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

تتضمن ** بيانات السياق ** لتطبيقات LLM المستندات النصية وملفات PDF وحتى التنسيقات المهيكلة مثل جداول CSV أو SQL. تباينت حلول تحميل البيانات وتحويلها (ETL) التي يستخدمها المطورون الذين قابلناهم على نطاق واسع. يستخدم معظمهم أدوات ETL التقليدية ، مثل Databricks أو Airflow. يستفيد البعض أيضًا من برامج تحميل المستندات المضمنة في إطار عمل التنسيق ، مثل LangChain (المدعوم من Unstructed) و LlamaIndex (المدعوم من Llama Hub). ومع ذلك ، نعتقد أن هذا الجزء من مجموعة التكنولوجيا متخلف نسبيًا وهناك فرصة لتطوير حل نسخ البيانات خصيصًا لتطبيقات LLM.

بالنسبة إلى ** التضمين ** ، يستخدم معظم المطورين واجهة OpenAI API ، وخاصة نموذج text-embedding-ada-002. هذا النموذج سهل الاستخدام (خاصة إذا كنت تستخدم بالفعل واجهات برمجة تطبيقات OpenAI أخرى) ، ويعطي نتائج جيدة بشكل معقول ، ويصبح أرخص. تستكشف بعض الشركات الكبرى أيضًا Cohere ، الذي يركز عمل منتجاته بشكل أكبر على التضمين ولديه أداء أفضل في بعض السيناريوهات. بالنسبة للمطورين الذين يفضلون المصدر المفتوح ، فإن مكتبة Hugging Face's Sentence Transformers هي المعيار. من الممكن أيضًا إنشاء أنواع مختلفة من حفلات الزفاف اعتمادًا على حالة الاستخدام ؛ هذه ممارسة متخصصة نسبيًا اليوم ، ولكنها مجال بحث واعد.

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

ومع ذلك ، هناك أيضًا عدد كبير من قواعد بيانات المتجهات المتاحة. ومن أبرزها:

• ** الأنظمة مفتوحة المصدر ** مثل Weaviate و Vespa و Qdrant: تتمتع هذه الأنظمة عادةً بأداء ممتاز للعقدة الواحدة ويمكن تخصيصها لتطبيقات معينة ، مما يجعلها شائعة لدى فرق الذكاء الاصطناعي ذات الخبرة الذين يرغبون في تطوير منصات مخصصة.
• Faiss et al ** Native Vector Management Libraries **: تتمتع هذه المكتبات بخبرة مطور واسعة ويسهل بدءها للتطبيقات الصغيرة وتجارب التطوير. ولكن قد لا تحل هذه بالضرورة محل قواعد البيانات الكاملة على نطاق واسع.
• ** امتدادات OLTP ** مثل pgvector: رائعة للمطورين الذين يرون ثغرات في كل شكل من أشكال قاعدة البيانات ويحاولون التوصيل بـ Postgres ، أو الشركات التي تشتري معظم البنية التحتية لبياناتها من مزود سحابي واحد حل دعم متجه لطيف. ليس من الواضح ما إذا كان متجه الاقتران بإحكام مقابل أعباء العمل القياسية أمرًا منطقيًا على المدى الطويل.

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

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

بناء سريع والحصول عليها

الفوري للبناء والحصول

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

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

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

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

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

تنفيذ تلميح / المنطق

تنفيذ تلميح / المنطق

اليوم ، OpenAI هي شركة رائدة في مجال النماذج اللغوية. أطلق كل مطور قابلناه تقريبًا تطبيق LLM جديدًا باستخدام OpenAI API ، وعادة ما يستخدم نموذج gpt-4 أو gpt-4-32k. يوفر هذا أفضل سيناريو لحالة الاستخدام لأداء التطبيق ، وهو سهل الاستخدام لأنه يمكن أن يستخدم نطاقًا واسعًا من مجالات الإدخال ، وغالبًا لا يتطلب ضبطًا دقيقًا أو استضافة ذاتية.

بمجرد أن يبدأ المشروع في الإنتاج ويبدأ في التوسع ، يمكن أن تلعب مجموعة واسعة من الخيارات. تتضمن بعض الأسئلة الشائعة التي نسمعها ما يلي:

• قم بالتبديل إلى gpt-3.5-turbo: هذا أرخص بحوالي 50 مرة من GPT-4 وأسرع بكثير. لا تحتاج العديد من التطبيقات إلى دقة بمستوى GPT-4 ، ولكنها تحتاج إليها للاستدلال بزمن انتقال منخفض ودعم فعال من حيث التكلفة للمستخدمين المجانيين.
• تم اختباره مع البائعين الآخرين (خاصة نموذج Anthropic's Claude): يقدم كلود استنتاجًا سريعًا ودقة بمستوى GPT-3.5 والمزيد من خيارات التخصيص للعملاء الكبار ونوافذ السياق حتى 100 كيلو (على الرغم من أننا وجدنا أن الدقة تتناقص مع زيادة طول الإدخال) .
• تصنيف الطلبات الجزئية لنماذج مفتوحة المصدر: هذا فعال بشكل خاص لحالات استخدام B2C ذات الحجم الكبير مثل البحث أو الدردشة ، حيث تختلف تعقيدات الاستعلام على نطاق واسع ويحتاج المستخدمون المجانيون إلى الخدمة بتكلفة زهيدة:

1. هذا عادة ما يكون أكثر منطقية بالاقتران مع ضبط النموذج الأساسي مفتوح المصدر. لن نتعمق في مجموعة الأدوات هذه في هذه المقالة ، ولكن يتم استخدام منصات مثل Databricks و Anyscale و Mosaic و Modal و RunPod بشكل متزايد من قبل فرق الهندسة.

2. يمكن أن تستخدم النماذج مفتوحة المصدر خيارات استدلال متعددة ، بما في ذلك واجهة API البسيطة لـ Hugging Face و Replicate ؛ موارد الحوسبة الأولية من موفري السحابة الرئيسيين ؛ والمنتجات السحابية (السحابة العاقدة الرأي) مع تفضيلات أوضح مثل تلك المذكورة أعلاه.

حاليًا ، يتخلف ** نموذج المصدر المفتوح ** عن المنتجات المسجلة الملكية ، لكن الفجوة بدأت تنغلق. وضع نموذج Meta LLaMa معايير جديدة لدقة المصدر المفتوح وأنتج مجموعة من المتغيرات. نظرًا لأن LLaMa مرخص فقط للاستخدام البحثي ، فقد بدأ العديد من مقدمي الخدمة الجدد في تدريب نماذج أساسية بديلة (على سبيل المثال ، معًا ، Mosaic ، Falcon ، Mistral). لا تزال Meta تناقش ما إذا كنت تريد إطلاق إصدار حقيقي مفتوح المصدر من LLaMa 2.

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

لم يكن لدى معظم المطورين الذين قابلناهم فهم عميق ** للأدوات التشغيلية ** الخاصة بـ LLM. يعد التخزين المؤقت أمرًا شائعًا نسبيًا (غالبًا ما يعتمد على Redis) ، حيث يؤدي ذلك إلى تحسين وقت استجابة التطبيق وتقليل التكاليف. أدوات مثل الأوزان والتحيزات مع MLflow (مستوحاة من التعلم الآلي التقليدي) أو Layer with Helicone (المصمم لـ LLM) تستخدم أيضًا على نطاق واسع. يمكن لهذه الأدوات تسجيل وتتبع وتقييم مخرجات LLM ، غالبًا لغرض تحسين بناء الأطراف أو ضبط خطوط الأنابيب أو اختيار النماذج. هناك أيضًا العديد من الأدوات الجديدة التي يتم تطويرها للتحقق من صحة إخراج LLM (مثل الدرابزين) أو اكتشاف هجمات حقن التلميح (مثل Rebuff). تشجع معظم هذه الأدوات التشغيلية عملاء Python الخاصين بهم على إجراء مكالمات LLM ، لذلك سيكون من المثير للاهتمام أن نرى كيف تتعايش هذه الحلول بمرور الوقت.

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

ماذا عن الوكلاء؟

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

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

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

يتطلع إلى المستقبل

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

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