Your Old Prompts Are Making Claude Worse - Lance Martin, Anthropic

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

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

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

والأداء. إليك مثال، هذا تقييم قمت ببنائه. إنه تقييم اصطناعي لتذاكر دعم العملاء. يوجد حوالي 50 تذكرة. وما أفعله هو أنني أبدأ باستخدام Opus 48. وأقوم أساساً بمحاكاة الانتقال إلى Opus 55، حسناً؟ وفي هذه العملية، أقوم بإدراج كل نمط خاطئ على حدة وقياس النتيجة. هذه هي النقطة الوسطى، حسناً؟ ما يحدث هو أنه يأخذ متوسط جميع الأنماط الخاطئة عبر المعيار القياسي . النقطة الأساسية هي هذه. عندما أقوم بالانتقال من Opus 48 إلى 55، في البداية ومع إدراج هذه الأنماط الخاطئة، نرى بعض التوفير في التكلفة وتحسناً بسيطاً في الأداء. يمكنك رؤية أنه يتجه لليسار ويرتفع قليلاً. إذا قمت بتشغيل prompt audit فوق ذلك، أحصل على دفعة إضافية في كل من الأداء وتقليل التكلفة لأسباب مختلفة. لأن هذا الأمر يمر عبر الكود ويزيل طقوس التحقق والمحفزات التي تسبب استهلاك Opus 55 لرموز (tokens) إضافية.

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

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

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

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

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

جرب هذا الأمر. Claude API build eval. هذا في الواقع أمر جيد جداً لأنه لا يفرض رأياً على الإطلاق بشأن مكان تخزين بياناتك. إنه لا يهتم بذلك. يمكنك توجيهه إلى أي حل تتبع تستخدمه. إنها مجرد مهارة في كود "كلود"(Claude code). إنها توظف المبادئ التي تحدثت عنها لاختبار التقييم والتحقق من سلامته نيابة عنك. لذا، يمكنك إعطاء هذه المهارة، "مهلاً، إليك مشكلة أريد حلها. هذا ما أهتم به. هذه هي البيانات الخام. على سبيل المثال، هذه هي عمليات التتبع التي أريد العمل بها". ويمكن لهذا الأمر مساعدتك في بناء مجموعة تقييم. سيرشدك خلال العملية ويوجهك خطوة بخطوة لبنائها. سيساعدك، وسيعرض لك البيانات. سيعرض لك التقييم. سيقوم بالتحقق من سلامة المقيم والمعايير معك. لذا، سيسير معك خلال عملية بناء التقييم بناءً على بعض أفضل ممارساتنا. ولدينا أيضاً تدوينة رائعة حول هذا الموضوع سأشاركها معكم. وهو يتناسب بشكل جيد جداً مع "تسلق التلال"(hill climbing). بمجرد أن تبني تقييماً جيداً يتمتع بهامش في النطاق المتقدم، وتباين منخفض، ويتوسع كما هو متوقع مع التفكير والنموذج، يمكنك حينها البدء في تحسينه. تعد نماذج "كلود" المتقدمة فعالة جداً في عمليات التحسين التكراري (تسلق التلال). لذا، فهي تنظر إلى التقييم بشكل مستقل وتعمل ذاتياً على تحسينه دون تدخل منك. بمجرد بناء تقييم جيد، يمكن لـ "كلود" العمل على تحسينه.

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

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

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

وقمت باختبار المهارة. لم تكن المهارة في البداية جيدة جدًا في الإجابة على أسئلة التقييم في مجموعتي، بلغت دقتها 66%. لذا ، قمت بإعداد حلقة ارتقاء من خلال منح كود Claude وصولاً إلى نص المهارة والوثائق نفسها، وتركته بشكل أساسي ينظر بشكل متكرر إلى الإخفاقات في مجموعة التقييم ويحاول معرفة سبب تحريف المهارة لما ورد في الوثائق. وهناك جميع أنواع الحيل الصغيرة ، ويمكنني، كما تعلم، التحدث عن ذلك بمزيد من التفصيل. لكن النقطة المهمة هي أن Claude يمكنه العثور بشكل مستقل، في هذه الحالة الخاصة، على نص المهارة المناسب لتحسين الأداء بشكل كبير في التقييم. وأتحدث عن هذا في رابط المدونة أدناه. ومرة أخرى، هذا مثال جيد على تقييم محدد النطاق بشكل جيد: خدمة بسيطة أقوم بتعديل مهارة لها، وحلقة ارتقاء مستقلة أدت إلى أداء أفضل بكثير. فقط عندما أضبط النظام بهذه الطريقة مع تقييم محدد بعناية، وسطح سهل التعديل، يمكن لـ Claude التعامل معه وتحسين الأداء بشكل كبير. يعمل هذا بشكل جيد مع المطالبات، ويعمل بشكل جيد مع المهارات. الأسطح البسيطة المعتمدة على النصوص جيدة جدًا لهذا النوع من عمليات الارتقاء. الآن، هذه خدعة أخرى مثيرة للاهتمام رأيت الكثير من العملاء يحبونها . يمكنك أيضًا تطبيق الارتقاء (hill climbing) لتقليل التكلفة. ما يميز هذا الأمر هو أنني أضفت توجيهات إلى أمر الارتقاء هذا. إذا طلبت منه خفض التكلفة، فإنه سيحاول ببساطة العثور على إعداد يحقق مستوى أداء مكافئ على الأقل ويضمن خفض

التكلفة. وسيبحث في عناصر مثل مستوى الجهد ، والنموذج، ومطالباتك (prompts). إليك مثال بسيط على نفس معيار دعم العملاء ذاك . أبدأ بنموذج Opus 48 بمستوى جهد عالٍ مع مطالبة أساسية. وأطلب ببساطة من "متسلق التلال"(hill climber) خفض التكلفة. ما يفعله هو أنه يبحث في مجموعات الجهد والنموذج ويختار تلك التي تخفض التكلفة باستمرار عبر الجولات دون التأثير على الأداء. في هذه الحالة، انتقل إلى Opus 5 بمستوى جهد منخفض. نرى قفزة كبيرة في الأداء وانخفاضاً طفيفاً في التكلفة. ثم يقوم "متسلق التلال" ذاتياً بتجربة نموذج "فرونت" بمستوى جهد منخفض. نرى مرة أخرى تراجعاً بسيطاً في الأداء، لكن مع انخفاض كبير في التكلفة. ثم يقرر ضبط المطالبة، ونستعيد الأداء نوعاً ما. وهكذا حصلنا على خفض بنسبة 90%في التكلفة مع تحسن ملحوظ في الأداء باستخدام "متسلق التلال" ذاتياً. هذه طريقة رائعة أخرى؛ إذا كان لديك تقييم ، يمكنك استخدام "متسلق التلال" لتقول: " حسناً، حافظ على ثبات الأداء ولكن خفض تكاليفي جوهرياً من خلال ضبط الجهد، واختيار النموذج، والمطالبات". استخدام آخر رائع جداً لـ "متسلق التلال". وما يميز هذا الأمر هو أنه يمكنك القيام به إذا كان لديك تقييم مشبع. يمكنك ببساطة القول: "حسناً، لنفترض أن تقييمي مشبع، لا بأس". "لا يهم". "أنا لا أهتم بالأداء". " أريد فقط خفض التكلفة". إذاً يمكنك إخبار "متسلق التلال": "حسناً، حافظ على ثبات الأداء وحاول فقط تقليل التكلفة". ويمكنه البحث عن إعدادات وغالباً ما يجد أشياء مثيرة جداً للاهتمام. في هذه الحالة

بالذات، هناك حدس عام بأن الانتقال إلى نماذج أقوى بجهد أقل غالباً ما يكون أرخص وأكثر كفاءة من نماذج أقل بجهد عالٍ. الأمر يشبه أن شخصاً أذكى يحتاج لبذل جهد أقل لتحقيق هدف أفضل أو لحل المشكلة بشكل أكثر فعالية. وهو ما يؤدي في النهاية إلى استخدام رموز (tokens) أقل، وبالتالي يصبح الأمر أرخص. هذا حدس عام شهدناه كثيراً هنا. وهذا مدمج في مهارة "متسلق التلال" هذه. إذاً، هذه خدعة أخرى رائعة. سأفتح باب الأسئلة قريباً جداً. سأختتم فقط ببعض التعليقات الأخرى. هذه إشارة بسيطة إلى موضوع الوكيل المُدار الذي سمعتم عنه هذا الصباح. أود فقط أن أؤكد على هذه النقطة قليلاً. أعتقد أنه كجزء من إطلاق العنان للحدود التقنية، من المهم جداً تصميم أنظمة قادرة على الاستفادة القصوى من أحدث نماذج كلود (Claude). وعلى وجه الخصوص، من المثير للاهتمام إذا نظرت إلى السنوات القليلة الماضية، حيث يمثل المحور الأفقي (X) الوقت، والمحور الرأسي (Y) مدة المهمة البشرية. لقد رأيتم هذه المنحنيات. إنها مجرد مخططات قياس. من المثير للتفكير في الماضي، كما تعلمون، كان كلود أوبوس 3 ( Claude Opus 3) قادراً على القيام بحوالي 4 دقائق فقط من العمل المستقل. وفي ظل هذا النطاق، كانت المنتجات التي يمكنك بناؤها محدودة للغاية. كان الأمر يقتصر حقاً على الإكمال التلقائي أو الدردشة. الآن، رأينا خلال عام 2025 أن النماذج أصبحت أكثر قدرة . يمكنها القيام بساعات من العمل. ربما ما يعادل ساعة إلى ساعتين من العمل البشري.

اكتسب "كود كلود"(Claude Code) بالطبع شعبية كبيرة خلال عام 2025. ونحن ندخل الآن في مرحلة جديدة حيث تتجاوز مدة هذه المهام بالنسبة للنماذج يوماً إلى يومين. أعتقد أن هذا أصبح خارج نطاق ما يمكن لمقاييس الأداء قياسه الآن. ولكن في هذا النطاق حيث لديك نماذج يمكنها القيام بما يعادل أياماً من العمل، ما هي الأنظمة التي تحتاجها؟ تتغير الاعتبارات كثيراً لأنك تريد نماذج يمكنها القيام بالأشياء بشكل مستقل لفترات طويلة جداً. الآن، كيف تتأكد من أنها آمنة وموثوقة؟ تتغير الاعتبارات بشكل كبير. وقد سمعتم عن ذلك هذا الصباح، ولكن هذا هو الدافع وراء إحدى واجهات برمجة التطبيقات الجديدة لدينا المسماة "وكلاء كلود المدارين"(Claude Manage Agents). والمبدأ هنا، وقد كتبت مدونة حوله في أبريل، هو فصل "العقل" عن " اليدين". والفكرة هنا بسيطة للغاية. لديك نظام الوكيل، الذي يمثل العقل فعلياً. ولديك اليدان، وهي عبارة عن بيئات معزولة (Sandboxes). هذا هو المكان الذي يقوم فيه نظام الوكيل بكتابة التعليمات البرمجية وتنفيذ الإجراءات. وأنت تريد أن تكون هذه الأشياء منفصلة عن بعضها البعض. على وجه الخصوص، تريد أن تكون قادراً على استعادة النظام في حال تعطل النظام الأساسي أو تعطلت البيئة المعزولة. تخيل أن لديك وكيلاً قمت بتشغيله طوال الليل ثم تعطلت البيئة المعزولة في منتصف الليل. إنه أمر محبط للغاية. ستفقد الحالة، وستفقد سجل الجلسة، وكل شيء. لذا عندما صممنا هذا، صممناه لعالم سيقوم فيه كلود بأداء عمل لفترات طويلة جداً. ولذلك فهو قابل للاسترداد. هذا يعني أن سجل الجلسة هو كائن مستقل، منفصل عن النظام، ومنفصل عن البيئة المعزولة، وهو مخصص للإضافة فقط،

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

يمكنه الوصول إلى مصادر مختلفة تحددها، ويمكنه كتابة تحديثات على Slack. مثال أتمتة بسيط للغاية، وقابل للتخصيص بدرجة عالية، لكنه يوضح كيف تجتمع كل هذه العناصر الأساسية معًا. إنه يجمع بين النشر المجدول. كل هذا يعمل على البنية التحتية لشركة Anthropic. إنه يخزن الأسرار بشكل آمن. ويتمتع بذاكرة. وهو مثال رائع وشامل من البداية للنهاية. مرة أخرى، النقطة الأخيرة هي أنه يمكنك تشغيل هذا في Cloud Code. لذا، قم بتشغيل Cloud API على متن النظام، وأعطه رابط المدونة، وسيقوم بتشغيل هذا البرنامج التعليمي لك. سيقوم بإنشاء المثال، ويمكنك ببساطة تجربته. النقطة الأساسية هنا هي وجود عدة طرق يمكنك من خلالها تسخير الأدوات والتأكد من أن الحدود تعمل بفعالية دون عوائق. من المهم جدًا مراجعة مطالباتك (prompts) . من المهم جدًا التأكد من استخدام ذاكرة التخزين المؤقت للمطالبات بفعالية، خاصة إذا كنت تبني وكلاء لفترة طويلة، لضمان إدارة التكلفة. من المهم التفكير في أنظمة اختبار مصممة للعمل لفترات طويلة من حيث الموثوقية والأمان. ومن المهم أيضًا التفكير في التقييمات وتحسين النتائج تدريجيًا. وعندما يجتمع كل هذا معًا، ستمتلك وكلاء يمكنك تكليفهم بمهمة، مثل التقييم، وتركهم يعملون لفترة طويلة، والتحسين المستمر لهذا التقييم، ثم تعود في الصباح مثلاً لتجد أن الأداء قد تحسن بشكل ملحوظ. وهذه في الواقع هي الطريقة التي أرى بها العديد من زملائي يعملون الآن. يقضي الناس وقتًا أطول بكثير في تصميم التقييمات، وببساطة تحديد المهام التي يمكن لـ Claude تحسينها بفعالية،

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

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

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

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

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

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

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

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

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

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

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

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

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

هنا، أنا لا أعرض ذلك، ولكن عندما جربت هايكو (Haiku) كان الإصدار 4.5. هايكو لدينا الآن هو 5.5، وهو أفضل بكثير. إصدار 4.5 بجهد منخفض كان تراجعاً ملحوظاً، لذا استبعدنا تلك النقطة من البيانات. لكن ببساطة، إذا كان لديك تقييم، فإن تسلق التلال وسيلة جيدة جداً للبحث عن مزيج جيد من النموذج والجهد. توجيهات الجهد الأكثر عمومية إذا لم يكن لديك تقييم تكون معقدة ودقيقة، وأعتقد أن النصيحة التي أوصي بها بشكل عام بشأن الجهد هي تجربة نموذج أقوى بجهد منخفض. أوبوس (Opus) 5.5 بجهد منخفض . جرب ذلك ببساطة. غالباً ما تكون النماذج الأفضل بجهد منخفض أكثر كفاءة في استخدام الرموز، وبالتالي أرخص من النماذج الأضعف بجهد عالٍ. هذه هي النقطة الرئيسية التي سأترككم بها. >> إذن، ليس الجهد المتوسط؟ >> جرب الجهد المنخفض في البداية. يمكنك دائماً زيادة الجهد، ولكن بشكل أساسي، أحب أن يكون النموذج ذكياً جداً دون بذل جهد مفرط. هذه غالباً هي النقطة المثالية للتوازن بين التكلفة والأداء.

بالطبع يمكنك زيادة الجهد، لكنني أعتقد أن الناس غالباً ما يبدؤون بشيء مثل أقصى جهد . هذا يستهلك الكثير من الرموز بشكل مفرط . لذا من الحكمة غالباً البدء بنموذج أذكى بجهد منخفض ثم الانطلاق من هناك إذا احتجت إلى ذلك. >> نعم، في الواقع، تحدثنا عن هذا في المدونة هنا. كنت سأفتحها. ليس لدي إنترنت. لا بأس. سأخبرك بها أنا إذاً. نعم، الأمر يتعلق ببساطة بإخبار كلود (Claude) بمدى عمق التفكير المطلوب. لذا، الجهد المنخفض يعني "لا تفكر بعمق"، وكلما زدت الجهد، فهذا يعني "فكر بعمق أكبر". لذا، هذا هو السبب في أن نموذجاً أكثر ذكاءً بشكل أساسي عند بذل جهد منخفض يمكن أن يكون أكثر كفاءة في استخدام الرموز (Tokens)، وبالتالي أرخص من نموذج أرخص من حيث الرموز الأساسية عند بذل جهد عالٍ. لأن، على سبيل المثال، سونيت 5 (Sonic 5) عند بذل جهد عالٍ يستهلك الكثير والكثير من الرموز في التفكير، بينما النموذج الأكثر ذكاءً عند جهد منخفض سيستهلك رموزاً أقل في التفكير مع مستوى ذكاء أساسي أعلى. هذا هو الحدس العام. نعم، لذا فإن السؤال يتعلق بتحديد الميزانيات في عملية "تسلق التلال"(hill climbing). أساساً، عندما تقوم بتشغيل هذه المهارة وإعدادها، سيطلب منك تحديد ميزانية. لذا، سيقوم بإدارة ذلك نيابة عنك . سيتتبع الميزانية التي تخصصها لجولة " تسلق التلال". هذا يمكن أن يحدث بالتأكيد رغم ذلك. أعني، وهذا هو السبب في أن هذا مثال كلاسيكي. ولهذا السبب فإن تصميم تقييم جيد أمر مهم حقاً. إذا كان لديك تقييم محدد بشكل سيئ، تخيل مثلاً أن لديك تقييماً تكون فيه الـ 20%الأخيرة مستحيلة

. ستحرق عدداً هائلاً من الرموز محاولاً حل تلك الـ 20%الأخيرة من المشكلات التي لا يمكن حلها فعلياً. بالنسبة لبناء التقييم، السؤال يتعلق بالتعاون بين الإنسان وكلود (Claude) في الحلقة. لذا، أعتقد أن البشر ما زال لديهم دور في توجيه الهدف. مثل: ما الذي نحاول تقييمه فعلياً ولماذا هو مهم؟ لذا، التفضيلات الشخصية مهمة نوعاً ما. أي، ما الذي تحاول الإجابة عليه فعلياً؟ على سبيل المثال، سأعطي مثالاً من تجربة "هاميل"(Hamel) العامة في استخدام مهارة بناء التقييم الخاصة بنا داخلياً. لذا، الأمر يشبه القول: حسناً، إنه تطبيق لدعم العملاء. لنفترض أن هذا هو تطبيقك. ما المهم؟ ما الذي يعتبر مهماً؟ بماذا تهتم؟ هذه أمور يمكن للإنسان أن يوجه كلود فيها. الآن، بمجرد تحديد هذه الأمور بوضوح ، يمكن لكلود النظر في المسارات الأولية وتحديد أين يقصر التطبيق فعلياً عن تحقيق أهدافي. لذا، أعتقد أن هذا نوع من التعاون الجيد الذي يمكنك وضعه في مكانه. وهذا هو الوقت الذي يكون فيه النظر إلى البيانات مفيداً جداً. لذا، يمكن لكلود مساعدتك في توجيهك، مثل: حسناً، لقد اطلعت على البيانات. إليك مجموعة من الحالات التي تبدو إشكالية. وهذا يشبه تماماً وجود مقيم متصل بالإنترنت. لذا، تخيل أن لديك نظام تتبع، ولديك مقيم متصل. لديه تصنيف لرضا العملاء مثلاً. إنه يقوم بوضع علامات، مثل : إليك المسارات الإشكالية من أجلك. الأمر نفسه تماماً. كأنك تخبر كلود، أو تخبر المقيّم عبر الإنترنت: هذا ما أهتم به، وهذا ما أريدك أن تتحقق منه. يمكنه

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

وهكذا تستمر هذه الحلقة. هذا نمط جيد جداً في رأيي. إنه منطقي للغاية. وما يحدث هنا هو أنك عادةً ما تقوم بالتحسين بناءً على الحالات التي تفشل فيها في بيئة الإنتاج. ثم تضع تلك الحالات في اختبارات تراجع ( regression tests) بمجرد نجاحها جميعاً. ويستمر ذلك حتى ترى عدداً قليلاً جداً من حالات الفشل في الإنتاج. لذا، فهذه طريقة عامة جيدة لهيكلة حلقة التقييم الخاصة بك . والعديد من الشركات مثل LangChain و Arize و BrainTrust لديها منتجات تقدم هذه الحلقة الخارجية، والتي تبدو فعالة جداً. بالفعل. لذا يصبح التحدي هنا: حسناً، من ستجعلهم مقيمين؟ كيف تعرف ما هو "الجيد" في الإنتاج وما الذي سترقيه إلى مجموعات التقييم غير المتصلة (أوفلاين)؟ أجل، الأمر ليس سهلاً على الإطلاق. أعتقد أن هناك الكثير من العمل على المنتجات في هذا المجال حالياً.

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