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

https://www.youtube.com/watch؟v=laf-lacf2qy

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

في هذا المنشور ، سنستكشف:

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

لنبدأ!

ما هو LLM؟

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

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

عندما يتعلق الأمر باستخدام LLMS ، هناك ثلاثة أشياء مهمة لفهمها:

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

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

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

ما هو المطالبة؟

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

اعتمادًا على كيفية تدريب نموذج معين ، قد يعالج المطالبة بشكل مختلف ، وتقديم رمز مختلف. حتى نفس النموذج يمكن أن ينتج مخرجات مختلفة. هذه النماذج غير محددة ، مما يعني أنه يمكنك المطالبة بها بنفس الطريقة ثلاث مرات والحصول على ثلاث نتائج مختلفة. هذا هو السبب في أنك قد تتلقى مخرجات مختلفة من نماذج مختلفة في العالم ، مثل Openai’s GPT ، و Claude’s ، و Gews’s Gemini.

الآن بعد أن نعرف ماهية موجه ، كيف نستخدم المطالبات للحصول على المخرجات التي نريدها؟

ما هي الهندسة السريعة؟

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

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

فيما يلي بعض المكونات الرئيسية للتطبيق الفعال:

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

لنجربها!

مثال: كيفية تحسين المطالبات لتكون أكثر فاعلية
تخيل أنك تستخدم github copilot وقل: Write a function that will square numbers in a list في ملف جديد بدون رمز مسبق لتقديم سياق copilot. في البداية ، يبدو هذا بمثابة موجه واضح وفعال. ولكن هناك الكثير من العوامل غير واضحة:

• ما هي اللغة التي يجب أن تكون الوظيفة مكتوبة؟
• هل تريد تضمين الأرقام السلبية؟
• هل سيكون للمدخلات من أي وقت مضى غير الأرقام؟
• هل يجب أن تؤثر على القائمة المحددة أو إرجاع قائمة جديدة؟

كيف يمكننا تحسين هذه المطالبة لتكون أكثر فاعلية؟ دعونا نغيره إلى: Write a Python function that takes a list of integers and returns a new list where each number is squared, excluding any negative numbers.

هذه المطالبة الجديدة واضحة ومحددة حول اللغة التي نريد استخدامها ، وما الذي يجب أن تفعله الوظيفة ، والقيود الموجودة هناك ، ونوع الإدخال المتوقع. عندما نمنح Github Copilot سياقًا ، سيكون الإخراج أفضل مع ما نريد منه!

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

كيفية تحسين النتائج عند دفع LLMS

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

الارتباك الفوري

من السهل خلط طلبات متعددة أو أن تكون غير واضح عند كتابة المطالبات ، والتي يمكن أن تربك النموذج الذي تستخدمه. قل أنك تسليط الضوء على شيء في Visual Studio Code وأخبر Copilot fix the errors in this code and optimize it. هل من المفترض أن تقوم الذكاء الاصطناعي بإصلاح الأخطاء أو تحسينها أولاً؟ لهذه المسألة ، ما الذي يفترض أن يتحسن؟ السرعة ، الذاكرة ، أو قابلية القراءة؟

لحل هذا ، تحتاج إلى تقسيم المطالبة إلى خطوات ملموسة مع السياق. يمكننا ضبط هذه المطالبة عن طريق فصل يسألنا: First, fix the errors in the code snippet. Then, optimize the fixed code for better performance. إن بناء موجه تكراري يجعل من المرجح أن تحصل على النتيجة التي تريدها لأن الخطوات المحددة التي يحتاجها النموذج أكثر وضوحًا.

قيود الرمز المميز

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

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

أخطاء الافتراض

من السهل افتراض أن LLM يعرف أكثر مما تفعل بالفعل. إذا قلت add authentication to my app, هل يعرف النموذج ما الذي يفعله تطبيقك؟ هل تعرف التقنيات التي قد ترغب في استخدامها للمصادقة؟

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

أفضل الممارسات الهندسية

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

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

خطواتك التالية

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

• إذا كنت ترغب في مشاهدة هذا العرض التوضيحي في العمل ، فقد أنشأنا ملف تعليمي على YouTube التي ترافق هذه المدونة.
• إذا كان لديك أي أسئلة ، فقم بتشغيلها في GitHub Community Thread وسنكون متأكدين من الرد.
• تذكر أن اشترك في Github Copilot (إذا لم تكن قد بدأت بالفعل) للبدء مجانًا.
• انضم إلينا في الجزء التالي من السلسلة حيث سنسير من خلال أفضل الممارسات الأمنية.

ترميز سعيد!

---