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

作者：Systematic Long Short

ترجمة: DeepChao TechFlow

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

الكاتب لا يتحدث بشكل نظري عشوائي، بل يقدم طريقتين محددتين يمكن البدء باستخدامهما اليوم، ويحدد بوضوح حدود عدم قدرة التوكن على التوسع — وهي «مشكلة الحداثة».

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

مقدمة

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

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

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

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

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

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

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

كيف تعرف إذا كنت قد استثمرت كمية كافية من التوكن

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

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

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

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

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

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

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

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

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

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

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

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

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

ما الذي تفعله زيادة التوكن حقًا

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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