فهرس
4 دقيقة للقراءة

جعل نماذج اللغة الكبيرة تكتب كوداً لقراءة 10 ملايين توكن - كيف يعمل RLM

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

“هل نافذة السياق الأكبر تجعل الذكاء الاصطناعي أذكى؟”

الجواب: لا. في الواقع، كلما طال المدخل، تراجع أداء النموذج.

تعفن السياق (Context Rot) - لماذا نحتاج RLM

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

حتى النماذج التي تُعلن عن نوافذ سياق بحجم 128 ألف أو مليون توكن تكون أدق ما يمكن عند حدود 10 آلاف توكن تقريباً. بعد تجاوز 100 ألف توكن، ينخفض الأداء بشكل حاد. هذه الظاهرة تُسمى تعفن السياق (Context Rot).

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

الفكرة الجوهرية - “لا تقرأ كل شيء، استخرج ما تحتاجه”

يتبنى RLM (Recursive Language Model - نموذج اللغة التكراري) نهجاً مختلفاً جذرياً. بدلاً من تغذية 10 ملايين توكن لنموذج اللغة دفعة واحدة، يُخزّن النص في متغيرات Python ويسمح للنموذج بكتابة كود لقراءة الأجزاء التي يحتاجها فقط بشكل انتقائي.

بتعبير مبسّط: تعامل مع النموذج كمعالج مركزي (CPU) ومع النص الضخم كقرص صلب. النموذج يعالج حوالي 50 ألف توكن ذات صلة في كل مرة، بينما يستخرج إجابات دقيقة من مستندات تتجاوز 10 ملايين توكن.

هذا تحوّل جوهري في النموذج الفكري: من “أعطِ النموذج سياقاً أكبر” إلى “دع النموذج يُقرر أي سياق يحتاجه.”

المكونات الثلاثة الأساسية

RLM Orchestrator (المنسّق)

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

LMHandler (معالج النموذج)

خادم مقابس (socket server) يتولى ترحيل طلبات LLM API. الميزة الحاسمة هنا أنه يُتيح استدعاء النموذج حتى أثناء تنفيذ الكود - بمعنى أن النموذج يمكنه طرح أسئلة على نفسه أثناء معالجة البيانات.

Environment / REPL (البيئة التنفيذية)

بيئة Python معزولة يُخزَّن فيها النص الضخم في متغير context. الدالة المحورية هي llm_query()، التي تسمح للنموذج باستدعاء نفسه بشكل تكراري أثناء التنفيذ. من هنا جاءت كلمة “Recursive” (تكراري) في اسم RLM.

حلقة التنفيذ - استكشف، قسّم، اجمع، أنهِ

يتبع RLM حلقة منظمة لمعالجة المستندات الضخمة:

الاستكشاف (Explore): يبدأ النموذج بفحص بنية البيانات - ينفّذ شيئاً مثل print(context[:500]) لفهم ما يتعامل معه. لا يغوص في الملايين مباشرة، بل يتفحص عينة أولاً.

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

التجميع (Aggregate): تُدمج الإجابات الفرعية - إما عبر منطق Python (عدّ، تصفية، ترتيب) أو بطلب تلخيص من النموذج لدمج نتائج عدة أجزاء في إجابة متماسكة.

الإنهاء (Terminate): عندما يجمع النموذج معلومات كافية، يستدعي FINAL(answer) لإرجاع الاستجابة النهائية.

هذه الحلقة يمكن أن تتكرر عدد المرات اللازمة، وكل تكرار يبني على ما اكتشفته التكرارات السابقة.

علاقة Ralph Wiggum - “لا بأس بالفشل، استمر في التكرار”

ملحق Claude Code الذي انتشر مؤخراً - Ralph Wiggum - يتشارك فلسفة مع RLM رغم اختلاف المشكلة التي يحلها.

كيف يعمل Ralph Wiggum

عندما يُنهي Claude مهمة ويحاول الخروج، يعترض Stop Hook عملية الإنهاء ويُعيد حقن التعليمات الأصلية. في كل تكرار، يستطيع Claude رؤية الملفات المُعدّلة في الجولات السابقة وسجل Git، مما يمكّنه من تحسين النتائج تدريجياً.

ما يجمعهما

كلا النهجين يتعاملان مع مشكلات لا يمكن حلها باستدعاء واحد لنموذج اللغة، وذلك عبر حلقات تكرارية. كلاهما يُعامل الفشل كبيانات - كل تكرار يرجع لنتائج التكرارات السابقة ليتحسن.

أين يختلفان

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

نصائح عملية للتطبيق

المعالجة على دفعات: لا تستدعِ النموذج 1,000 مرة لـ 1,000 سطر. عالج 50 سطراً في كل استدعاء عبر 20 استدعاءً بدلاً من ذلك. التكلفة تنخفض والدقة تتحسن.

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

تحديد عمق التكرار: العمق 1 كافٍ في معظم الحالات. التعمق أكثر يُراكم الأخطاء بدلاً من تحسين الدقة.

إدارة السجل: استخدم نوافذ متحركة (rolling windows) أو أساليب قائمة على التلخيص لمنع تعفن السياق من التراكم عبر التكرارات المتعاقبة.

الخلاصة

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

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

انضم إلى النشرة الإخبارية

احصل على تحديثات حول أحدث مشاريعي ومقالاتي وتجاربي في الذكاء الاصطناعي وتطوير الويب.