وكيل ذكاء اصطناعي ينتج نفايات؟ المشكلة هي أنك لا تريد حرق الرموز

المشكلة ليست في كلمات التحفيز!

المؤلف: Systematic Long Short

الترجمة: 深潮 TechFlow

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

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

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

مقدمة

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

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

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

هذا منطقي، أليس كذلك؟

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

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

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

كيف تعرف إذا كنت تستثمر التوكنات بشكل كافٍ

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

هذه هي ردي.

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

كمية التوكنات اللازمة لحل مشكلة معينة تعتمد تمامًا على حجمها، وتعقيدها، ومدى حداثتها.

مثلاً، “2+2 يساوي كم؟” لا يتطلب الكثير من التوكنات.

أما مهمة مثل: “ساعدني في كتابة بوت يراقب جميع الأسواق بين Polymarket وKalshi، ويحدد الأسواق التي تتشابه من حيث المعنى، والتي يجب تسويتها قبل أو بعد حدث معين، ويحدد حدودًا لعدم وجود فرص arbitrage، ويقوم بالتداول تلقائيًا بسرعة منخفضة عند ظهور فرصة” — فهي تتطلب استثمار كمية هائلة من التوكنات.

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

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

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

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

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

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

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

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

ما الذي تفعله التوكنات الزائدة

في الممارسة، غالبًا ما تُستخدم التوكنات الإضافية لتحسين جودة الهندسة في الوكيل عبر عدة طرق:

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

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

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

• التوكنات الإضافية تتيح له استخدام سياقات جديدة لمراجعة عمله السابق، ومنحه فرصة للتحسين بدلاً من التعلق بـ"عقلية" واحدة.

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

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

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

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

كيف تحسن وكيلك

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

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

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

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

الحل الأول: WAIT (انتظر)

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

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

الحل الثاني: VERIFY (تحقق)

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

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

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

ذكرت أن “الحداثة” مشكلة لا يمكن حلها فقط بزيادة التوكنات، وأود أن أؤكد ذلك مرة أخرى، لأنك في النهاية ستواجه هذا المطب، وتأتي تشتكي أن التوكنات لا تفيد.

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