جودة وكيل الذكاء الاصطناعي مرتبطة بحرق الرموز

المؤلف: Systematic Long Short

مُترجم: Deep潮 TechFlow

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

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

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

حسنًا، يجب أن تعترف أن هذا العنوان جذاب بالفعل — لكن بصراحة، هذا ليس مزاحًا.

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

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

هذا ليس صعب الفهم، أليس كذلك؟

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

الرأي القائل بأن "حرق المزيد من الرموز يُحسّن جودة العامل" يدعمه دليل تجريبي: الفرق التي تدّعي قدرتها على استخدام العامل لكتابة الكود بالكامل ونشره مباشرة إلى الإنتاج إما هي مزوّدو النماذج الأساسية أو الشركات ذات الموارد المالية الهائلة.

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

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

هذا، هو الرد.

أداء عميلك ضعيف ولا يحل المشكلات، وغالبًا ما يكون السبب هو أنك لم تُحرق عملات Token كافية.

عدد الرموز المطلوبة لحل مشكلة يعتمد بالكامل على حجم المشكلة وتعقيدها وجدتها.

كم يساوي 2+2؟ لا يتطلب ذلك عددًا كبيرًا من التوكنات.

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

لقد اكتشفنا شيئًا مثيرًا في الممارسة العملية.

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

هناك استثناء صغير ولكن مهم.

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

هذا الاستنتاج يُشعرنا في الواقع بالراحة.

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

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

هناك مبدأ توجيهي بسيط: يجب أن ينمو ميزان الرموز بشكل متناسب مع عدد أسطر الكود.

في الممارسة العملية، عادةً ما تعزز الرموز الإضافية جودة مشروع العامل من خلال الطرق التالية:

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

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

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

المزيد من الرموز يسمح له بانتقاد أعماله السابقة في سياق جديد، ويعطيه فرصة للتحسين بدلاً من أن يعلق في "الانحياز الاستنتاجي".

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

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

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

البحث، في جوهره، هو إنتاج الأساس المتمثل في "معرفة الإجابة". يقضي البشر وقتًا بيولوجيًا لإنتاج إجابات أفضل، بينما يقضي الوكلاء وقتًا حسابيًا أكبر لإنتاج إجابات أفضل.

قد لا تزال متردداً، لكن هناك العديد من الأوراق البحثية التي تدعم هذا الأمر، وبصراحة، وجود مفتاح التحكم في "الاستدلال" هو كل الدليل الذي تحتاجه.

ورقة بحثية أحبها كثيرًا، حيث قام الباحثون بتدريب النموذج على عينة صغيرة من عينات الاستدلال المُخطَّط لها بعناية، ثم استخدموا طريقة لإجبار النموذج على الاستمرار في التفكير عندما يرغب في التوقف — وذلك عن طريق إضافة "Wait" (انتظر) في المكان الذي يرغب في التوقف فيه. فقط هذا الإجراء وحده رفع أداء اختبار معياري من 50% إلى 57%.

أريد أن أكون واضحًا قدر الإمكان: إذا كنت لا تزال تشتكي من أن كود العميل غير مرضٍ، فربما لا يزال أعلى مستوى تفكير فردي غير كافٍ لك.

أعطيك حلين بسيطين جدًا.

الطريقة البسيطة الأولى: WAIT (انتظر)

أبسط شيء يمكنك البدء به اليوم: إنشاء دورة تلقائية — بعد البناء، اجعل العامل يراجع N مرات باستخدام سياق جديد، وقم بإصلاح أي مشكلات تُكتشف في كل مرة.

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

الطريقة البسيطة الثانية: VERIFY (التحقق)

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

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

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

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

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