نوافذ السياق أصبحت ضخمة للغاية
يستخدم الناس كلمة agent لكل شيء.
الدالة التي تستدعي أداة هي agent. روبوت الدردشة الذي يمتلك ذاكرة هو agent. النص البرمجي الذي يحتوي على حلقة تكرارية هو agent.
هذا الخطأ يؤدي إلى هندسة سيئة. تقوم الفرق بالمبالغة في هندسة المهام البسيطة، وتقصر في هندسة المهام المعقدة. أرى فرقاً تقضي أسابيع في تنسيق الـ agents لسير عمل لا يتطلب سوى prompt واحد جيد.
إليك تعريفي للـ agent الحقيقي.
الـ agent لديه هدف. هو لا يكتفي باتباع التعليمات فحسب، بل يقرر ما يجب فعله تالياً. كما أنه يتعامل مع الفشل، ويعرف متى يتوقف.
استخدم هذه المعايير:
- إذا كان على الإنسان توجيه كل خطوة، فهي مجرد واجهة دردشة.
- إذا كان النظام يتعافى من استدعاء فاشل لأداة ما، فهو يتحرك نحو أن يصبح agent.
- إذا كان النظام يجزئ الهدف إلى مهام ويقوم بتفويضها، فهو agent حقيقي.
معظم الـ agents الناجحة هي نماذج ضيقة النطاق. فهي تؤدي وظيفة واحدة بإتقان، مثل فرز طلبات دعم العملاء (triage) أو استخراج المستندات. هي ليست محركات استدلال عامة.
تركز الفرق الناجحة على هذه الأشياء الثلاثة:
- تصميم الأدوات: ما مدى نظافة الواجهة؟
- التعامل مع الفشل: ماذا يحدث عندما لا تعيد الأداة أي نتيجة؟
- القابلية للملاحظة (Observability): هل يمكنك تتبع سبب اتخاذ الـ agent لقرار ما؟
أما الفرق غير الناجحة، فتكتفي باستبدال نموذج بآخر أحدث وتتوقع نتائج أفضل، متجاهلةً تصميم النظام.
أطر العمل مثل LangChain أو CrewAI تتغير كل شهر. إطار العمل أقل أهمية من النمط (pattern) المتبع.
استخدم هذه الأنماط:
- التخطيط ثم التنفيذ: افصل خطوة الاستدلال عن خطوة التنفيذ.
- فصل الاسترجاع عن الاستدلال: جلب السياق هي وظيفة مختلفة عن استخدامه.
- التسليم الصريح (Explicit handoffs): استخدم سجلات منظمة (structured logs) عندما ينقل agent العمل إلى آخر.
إطار العمل ليس سوى سقالات (scaffolding)، أما الهندسة المعمارية فهي المبنى.
تقنية RAG أصبحت معياراً، لكن عملية الـ chunking غالباً ما تكون معيبة. إذا قمت بتقسيم المستندات بشكل سيئ، سيفقد النموذج السياق، مما يؤدي إلى الهلوسة (hallucinations).
إذا كانت نتائج RAG الخاصة بك عديمة الفائدة، فراجع عملية الـ chunking والبيانات الوصفية (metadata). نادراً ما يكون النموذج هو المشكلة.
النماذج ستصبح أفضل. نوافذ السياق ستكبر. وتكاليف الـ tokens ستنخفض.
لا شيء من هذا يحل التحدي الهندسي الحقيقي. يجب عليك بناء أنظمة تتصرف بشكل صحيح حتى عندما لا تكون مراقباً لها.
ركز على الحوكمة، والقابلية للملاحظة، والاستخدام الموثوق للأدوات. أفضل المهندسين لن يكونوا باحثين في النماذج، بل سيكونون مصممي أنظمة يبنون ذكاءً اصطناعياً موثوقاً.
نوافذ السياق أصبحت ضخمة، وإليك سبب تغيير ذلك لكل شيء
لقد شهدنا في الآونة الأخيرة تحولاً جذرياً في قدرات نماذج اللغات الكبيرة (LLMs). فبينما كانت نوافذ السياق (context windows) تُقاس بآلاف التوكنز (tokens)، أصبحت الآن تُقاس بالملايين. هذا ليس مجرد تحسين تقني بسيط؛ إنه تغيير في قواعد اللعبة.
ما هي نافذة السياق؟
ببساطة، نافذة السياق هي مقدار المعلومات التي يمكن للنموذج "الاحتفاظ بها في ذهنه" في وقت واحد أثناء معالجة مدخلاتك وتوليد مخرجاته. فكر في الأمر كذاكرة قصيرة المدى للنموذج. إذا تجاوزت مدخلاتك حجم نافذة السياق، سيبدأ النموذج في "نسيان" الأجزاء الأولى من المحادثة أو المستند.
من الآلاف إلى الملايين
في البداية، كانت النماذج مثل GPT-3 تمتلك نوافذ سياق محدودة للغاية (حوالي 2,048 توكن). ثم انتقلنا إلى 4,096 و 8,192 مع GPT-4. ولكن الآن، مع ظهور نماذج مثل Gemini 1.5 Pro من Google، أصبح لدينا نوافذ سياق تصل إلى مليون توكن أو أكثر.
هذا يعني أنه يمكنك الآن تزويد النموذج بكتب كاملة، أو آلاف الأسطر من الأكواد البرمجية، أو حتى ساعات من الفيديو، وسيكون قادراً على فهمها ومعالجتها دفعة واحدة.
الجدل الكبير: RAG مقابل السياق الطويل (Long Context)
لطالما كان المطورون يعتمدون على تقنية RAG (Retrieval-Augmented Generation) للتعامل مع كميات كبيرة من البيانات. تعمل تقنية RAG عن طريق البحث عن الأجزاء الأكثر صلة من بياناتك وتزويدها للنموذج ضمن نافذة السياق المحدودة.
ولكن مع توسع نوافذ السياق، يبرز سؤال جوهري: هل سنحتاج إلى RAG بعد الآن؟
لماذا قد تظل RAG ضرورية؟
- التكلفة: إرسال مليون توكن في كل طلب (prompt) مكلف للغاية مقارنة بإرسال بضع مئات من التوكنز المسترجعة عبر RAG.
- السرعة (Latency): معالجة سياق ضخم تستغرق وقتاً أطول، مما يؤدي إلى استجابة أبطأ.
- الضجيج: حتى مع النوافذ الضخمة، قد يواجه النموذج صعوبة في التركيز على المعلومة الصحيحة وسط كم هائل من البيانات غير الصلة.
لماذا قد يتفوق السياق الطويل؟
- البساطة: لا حاجة لبناء قواعد بيانات متجهة (vector databases) أو خطوط أنابيب استرجاع معقدة. فقط ضع البيانات في الطلب.
- الفهم الشامل: يمكن للسياق الطويل أن يرى "الصورة الكاملة"، مما يسمح للنموذج بربط الأفكار عبر مستندات مختلفة بطريقة قد تفشل فيها RAG.
مشكلة "الإبرة في كومة القش" (Needle in a Haystack)
لا يكفي أن تكون نافذة السياق كبيرة؛ يجب أن تكون دقيقة. هنا يأتي اختبار "الإبرة في كومة القش" (Needle in a Haystack). يتم هذا الاختبار عن طريق وضع معلومة محددة (الإبرة) داخل كمية هائلة من البيانات العشوائية (كومة القش) ثم سؤال النموذج عن تلك المعلومة.
النماذج التي تمتلك نافذة سياق كبيرة ولكنها تفشل في هذا الاختبار هي نماذج غير مفيدة عملياً، لأنها "تضيع" المعلومات وسط الزحام.
ماذا يعني هذا للمطورين؟
تغيير حجم نافذة السياق يغير طريقة تفكيرنا في بناء تطبيقات الذكاء الاصطناعي:
- تطبيقات تحليل المستندات: بدلاً من تقسيم المستندات إلى قطع صغيرة (chunking)، يمكنك الآن رفع ملف PDF كامل مكون من 500 صفحة وسؤاله عن أي تفصيل.
- مساعدو البرمجة: يمكن للنماذج الآن فهم مستودع برمجيات (repository) كامل، مما يعني قدرة أفضل على فهم العلاقات بين الملفات المختلفة.
- التحليل المتعدد الوسائط: مع النوافذ الضخمة، يمكن للنماذج معالجة فيديوهات طويلة أو ملفات صوتية ضخمة كجزء من السياق.
الخلاصة
نحن لا ننتقل فقط إلى نوافذ سياق أكبر، بل ننتقل إلى عصر جديد من التفاعل مع البيانات. لن يكون السؤال "هل يمكن للنموذج قراءة هذا؟" بل "كيف يمكننا استخدام هذه القدرة لبناء أدوات أكثر ذكاءً وكفاءة؟".