طول السياق من أكثر المواصفات التباسًا في عالم الذكاء الاصطناعي. يشرح هذا المقال ما التوكنات، وكيف تعمل نافذة السياق من الداخل، ولماذا تتعثر بعض النماذج مع المدخلات الطويلة، وما الذي تبحث عنه حين تحتاج فعلًا إلى نموذج يستوعب محادثة كاملة، أو مذكرة قانونية، أو قاعدة شيفرة برمجية بأكملها دفعة واحدة.
يحكم معظم الناس على نموذج الذكاء الاصطناعي من خلال عدد معاملاته، أو من خلال درجته في اختبار معياري للاستدلال. هذه الأرقام مهمة، لكنها لا تخبرك إن كان النموذج يستطيع فعلًا قراءة عقدك المكوّن من 80 صفحة، أو تذكّر ما قلته قبل اثنتي عشرة رسالة، أو استيعاب مشروع برمجي كامل في ذهنه دفعة واحدة. الرقم الذي يحدد كل ذلك هو طول السياق، ويُسمّى أيضًا نافذة السياق، وهو بهدوء أكثر المواصفات عمليةً في ورقة المواصفات الكاملة للنموذج.
يُقاس طول السياق بـالتوكنات وليس بالكلمات أو الحروف. التوكن يساوي تقريبًا 0.75 من كلمة إنجليزية، أي أن 1,000 توكن تعادل نحو 750 كلمة. لكن التوكنات تحسب أيضًا كل علامة ترقيم، وكل مسافة، وكل جزء من الشيفرة، وكل عنصر في موجّه النظام الخاص بك. وحين تمتلئ نافذة السياق لدى النموذج، لا يمكنه ببساطة رؤية أي شيء أقدم. لا يتباطأ ولا يحذرك، بل ينسى.
قد تبدو عبارة "tokenization" تقنية، لكن الفكرة بسيطة. نماذج اللغة الكبيرة لا تقرأ الحروف المفردة، بل تقرأ مقاطع من النص تُسمّى توكنات، وتحدّدها المفردات التي تدرّب عليها النموذج. الكلمات الشائعة مثل "the" أو "is" تكون عادةً توكنًا واحدًا. أما الكلمات النادرة، وأسماء الأعلام، ورموز الشيفرة، فكثيرًا ما تنقسم إلى توكنين أو ثلاثة أو أكثر.
وإليك لماذا يهم ذلك عمليًا:
كل واحدة من هذه التكاليف تُخصم من الميزانية نفسها. إذا كان لدى النموذج نافذة من 4,096 توكن، وأخذ موجّه النظام لديك 400 توكن، فستبقى لديك 3,696 توكنًا لكل شيء آخر: رسالتك، وسجل المحادثة، وردّ النموذج.
هنا يقع معظم المستخدمين في المشكلة. تبدأ محادثة مع روبوت دردشة، فيبدو كل شيء سريعًا ودقيقًا، ثم بعد عشرين رسالة يبدو أنه نسي ما قلته في البداية. هذا ليس خللًا. النموذج لا يستطيع رؤية تلك الرسائل الأولى بعد الآن، لأن نافذة السياق امتلأت، وأُزيل أقدم المحتوى.
تتعامل الأنظمة المختلفة مع هذا بطرق متعددة. بعضها يقتطع (يحذف أقدم الرسائل بصمت). وبعضها يلخّص الأدوار القديمة ويُدرج نسخة مضغوطة منها. وبعضها يطلب منك بدء جلسة جديدة. لا يُعدّ أي من هذه الحلول بديلًا مثاليًا عن نافذة سياق أكبر.
💡 نصيحة عملية: احسب دائمًا موجّه النظام، وأي أمثلة قليلة، والطول المتوقع للرد، عند تقدير مقدار السياق المتاح فعليًا لمدخلات المستخدم.
تتفاوت أطوال السياق بشكل كبير بين نماذج اليوم. قبل بضع سنوات، كان 4,096 توكن يُعدّ سخيًا. أما اليوم، فتوجد نماذج تصل إلى مليون توكن أو أكثر، مع أن هناك مفاضلات حقيقية عند الطرفين.
لا تُعدّ نوافذ السياق القصيرة نقطة ضعف دائمًا. فبالنسبة للمهام القصيرة بطبيعتها، تكفي نافذة من 4K أو 8K تمامًا:
في هذه الحالات، قد يتفوق نموذج مُحسَّن للسرعة والتكلفة عند حجم سياق صغير على نموذج أكبر من الناحية العملية. ستحصل على ردود أسرع وتكاليف API أقل دون خسارة ملموسة في الجودة.
تتغير المعادلة تمامًا في حالات الاستخدام التالية:
| المهمة | عدد التوكنات التقريبي |
|---|---|
| رواية كاملة (80,000 كلمة) | نحو 110,000 توكن |
| قاعدة شيفرة لمؤسسة (أكثر من 100 ملف) | من 200,000 إلى 500,000 توكن |
| مراجعة عقد قانوني (50 صفحة) | نحو 35,000 توكن |
| نص مفرّغ لمدة ساعة | نحو 30,000 توكن |
| مقابلة بحثية مدتها 3 ساعات | نحو 80,000 توكن |
| دليل منتج كامل | نحو 60,000 توكن |
عندما تعمل مع مادة بهذا الحجم، لا تتمدد نافذة 4K فحسب، بل تنكسر. لا يستطيع النموذج رؤية السياق الذي يحتاجه للإجابة بدقة، ولا يصلح أي قدر من إعادة صياغة موجّهك ذلك.
يتطلب فهم سبب كون توسيع طول السياق مكلفًا نظرةً سريعة على ما يفعله النموذج فعلًا عندما يقرأ موجّهك.
تستخدم نماذج اللغة الحديثة آلية تُسمّى الانتباه الذاتي (self-attention). ينظر كل توكن في السياق إلى كل توكن آخر ليبني صورة للمعنى والعلاقات. وهذا ما يجعل نماذج اللغة الكبيرة بارعة في التقاط الفروق الدقيقة والتبعيات البعيدة في النص.
تكلفة هذا الحساب تتناسب تربيعيًا مع عدد التوكنات. إذا ضاعفت طول السياق، فلن يتضاعف الحساب، بل يتضاعف أربع مرات. لهذا يتطلب تدريب نماذج ذات نوافذ سياق طويلة جدًا عتادًا أكبر بكثير، ولهذا تستخدم نماذج كثيرة فعّالة حيلًا مثل انتباه النافذة المنزلقة (sliding window attention)، أو الانتباه المتفرق (sparse attention)، أو تقريبات الانتباه الخطي (linear attention) لخفض هذه التكلفة.
💡 لماذا يهم هذا بالنسبة لك: نموذج بنافذة سياق من مليون توكن ليس هو النموذج الذي يعمل جيدًا عند مليون توكن. ابحث عن اختبارات مثل اختبار "الإبرة في كومة القش" (needle in a haystack)، الذي يقيس قدرة النموذج على استرجاع حقيقة محددة مدفونة في عمق وثيقة طويلة.
أشارت أبحاث نُشرت في عام 2023 إلى نمط إخفاق ثابت عبر عدة عائلات من النماذج: ينخفض الأداء حين تقع المعلومات ذات الصلة في وسط سياق طويل. تميل النماذج إلى استرجاع المعلومات الموجودة في بداية السياق أو نهايته بموثوقية أكبر بكثير من المعلومات المدفونة في المنتصف.
ولهذا تداعيات عملية:
تحسّنت المشكلة مع أجيال النماذج الأحدث، لكنها لم تختفِ تمامًا. وهذا سبب يدعو إلى التشكيك في أي ادعاء بأن نموذجًا "يتعامل مع 200K توكن بإتقان" دون اختبارات استرجاع فعلية تدعمه.
تسارع سباق طول السياق بسرعة. إليك المواقع التي تقف عندها عدة نماذج رئيسية حاليًا.
تتميز عدة نماذج متاحة على PicassoIA بملاءمتها تحديدًا لأعمال السياق الطويل.
Kimi K2.6 من Moonshotai بُني حول معالجة السياق الطويل كهدف تصميمي أساسي. يتعامل مع الاستدلال عبر عدة وثائق بدقة استرجاع جيدة، وهو من أفضل الخيارات حين تحتاج إلى تغذية عدة ملفات أو سلسلة محادثة طويلة جدًا في جلسة واحدة.
Gemini 3.1 Pro و**Gemini 2.5 Flash** من Google يدعمان نوافذ كبيرة للغاية، وهما مُحسَّنان للحفاظ على جودة الاستدلال عند أعداد توكنات عالية، ما يجعلهما مناسبين لسير العمل الكثيف بالوثائق.
Claude Opus 4.7 و**Claude 4 Sonnet** من Anthropic خضعا لاختبارات مكثفة في مهام الوثائق الطويلة، ومعروفان بدقة استرجاع عالية في تقييمات من نوع "الإبرة في كومة القش".
IBM Granite 8B Code Instruct 128K يوفر 128,000 توكن من السياق مُحسَّن خصيصًا للشيفرة البرمجية، ما يجعله خيارًا قويًا للمشاريع البرمجية الكبيرة التي تحتاج فيها إلى أن يرى النموذج عدة ملفات في الوقت نفسه.
IBM Granite 4.0 H Small نموذج سياق طويل مدمج مصمم للكفاءة، يعمل جيدًا حتى على عتاد محدود الموارد، مع الحفاظ على استرجاع متين عبر ميزانيات توكنات ممتدة.
Meta Llama 4 Scout Instruct و**Llama 4 Maverick Instruct** من Meta يتجاوزان بوضوح حدود السياق الطويل جدًا، وهما خياران مفتوحا الأوزان يحظيان بشعبية لدى المطورين الذين يريدون الشفافية والمرونة.
ليست كل المهام بحاجة إلى نافذة سياق ضخمة. فبالنسبة للمهام القصيرة والمتكررة، تقايض هذه النماذج جزءًا من سعة السياق مقابل إنتاجية أسرع بكثير:
تشمل المراجعة القانونية، والتدقيق المالي الشامل، والبحث الأكاديمي، ومراجعات الامتثال، كلها قراءة وثائق تتراوح من عشرات الآلاف إلى مئات الآلاف من الكلمات. نموذج بنافذة 8K لا يستطيع حتى استيعاب عقد طويل واحد كاملًا. إما أن تقسّمه إلى أجزاء، بما يحمله ذلك من خطر إغفال السياق المتقاطع بين الوثائق، وإما أن تستخدم نموذجًا بنافذة كبيرة حقًا.
لهذا العمل، يُعدّ Grok 4 و**GPT 5 Pro** و**Claude Opus 4.7** من بين الأفضل أداءً باستمرار. هم لا يقبلون المدخلات الطويلة فحسب، بل يحافظون على استدلال متماسك حولها من أول توكن إلى آخره.
تتراكم السياقات بسرعة في المحادثات الطويلة. روبوت دعم فني يمر بجلسة استكشاف أخطاء تستغرق 45 دقيقة يولّد آلاف التوكنات من السجل. وجلسة كتابة إبداعية تصقل فيها قصة عبر جولات كثيرة تصل إلى حدود السياق بسرعة.
💡 تكتيك: بالنسبة لتطبيقات المنتجات، احتفظ بملخص منظّم متجدد لحالة المحادثة، وأدرجه في أعلى كل جلسة جديدة بدلًا من تمرير سجل الدردشة الخام. هذا يُبقي ميزانية التوكنات متاحة للمحتوى الجديد، بدلًا من إعادة اجترار الأدوار القديمة.
GPT 5.4 و**GPT 5** و**Kimi K2.6** يتعاملون بكفاءة مع الجلسات متعددة الأدوار الممتدة، فيحافظون على الترابط ويتتبعون التفاصيل التي وردت في بداية المحادثة، وهي تفاصيل كانت معظم النماذج ذات النوافذ الأقصر ستسقطها بالفعل.
هنا يكون طول السياق أكثر أهمية للمطورين. عندما تطلب من نموذج ذكاء اصطناعي إعادة هيكلة دالة، يحتاج إلى رؤية الأماكن التي تُستدعى فيها هذه الدالة في الشيفرة. وعندما تطلب منه كتابة وحدة جديدة، يحتاج إلى رؤية الواجهات التي يجب أن تتكامل معها. نموذج بسياق 4K يقرأ ملفًا واحدًا في المرة الواحدة. أما نموذج 128K فيستطيع استيعاب قاعدة شيفرة صغيرة كاملة والاستدلال عبرها بشكل شمولي.
IBM Granite 8B Code Instruct 128K صُمم خصيصًا لهذا الاستخدام تحديدًا. وبطول 128K توكن، يستطيع استيعاب نحو 500 إلى 800 ملف مصدري نموذجي في السياق دفعة واحدة، وهو ما يغطي معظم التطبيقات الصغيرة والمتوسطة بالكامل.
Meta Llama 3.1 405B Instruct يضيف عمقًا هائلًا من المعاملات إلى نافذة سياق طويلة، ما يجعله من أقوى الخيارات حين تحتاج إلى اتساع في فهم الشيفرة ودقة في اتباع التعليمات معًا.
حتى مع أفضل نموذج متاح للسياق الطويل، ستظهر مهام تتجاوز ما يمكن لأي نافذة سياق واحدة أن تحمله. إليك أكثر استراتيجيتين موثوقية.
الطريقة الأبسط هي تقسيم الوثائق الكبيرة إلى أجزاء تناسب نافذة السياق، ومعالجة كل جزء على حدة، ثم دمج النتائج. الخطر هو إغفال الروابط التي تمتد بين الأجزاء. وللحد من هذا الخطر:
يعمل هذا النهج جيدًا مع الوثائق التي يكون كل قسم فيها مستقلًا نسبيًا، مثل تقرير طويل ذي فصول متمايزة.
التوليد المعزز بالاسترجاع (Retrieval-Augmented Generation أو RAG) هو الخيار المعماري المناسب لقواعد المعرفة الضخمة جدًا. فبدلًا من إلقاء كل شيء في السياق دفعة واحدة، تقوم بما يلي:
يُبقي هذا السياق النشط صغيرًا ومركّزًا. والمفاضلة هي أنك يجب أن يكون لديك نظام استرجاع يقدّم الأجزاء الصحيحة فعلًا. يعمل RAG بشكل ضعيف حين تتطلب الإجابة تجميع معلومات منتشرة عبر أجزاء بعيدة من وثيقة كبيرة، وهذه تحديدًا الحالة التي يتفوق فيها نموذج السياق الطويل الحقيقي.
غالبًا ما يُجمع النهجان معًا: استخدم RAG لتحديد الأقسام الأكثر صلة، ثم غذِّ مقتطفًا أطول من تلك الأقسام إلى نموذج سياق طويل للتركيب النهائي.
طول السياق ليس العامل الوحيد المهم في النموذج، لكنه غالبًا المواصفة التي تحدد ما إذا كان النموذج قادرًا على فعل ما تحتاجه فعلًا. اختيار نموذج دون التحقق من نافذة سياقه يشبه تعيين مستشار، لتكتشف بعد الاجتماع أنه لا يتذكر إلا آخر خمس دقائق من الحديث.
على PicassoIA، يمكنك تجربة كل نموذج مذكور في هذا المقال مباشرة في متصفحك، دون أي إعداد أو تهيئة لواجهة API. أدخل وثيقة طويلة. الصق قاعدة شيفرة متعددة الملفات. شغّل محادثة تتعمق. سترى بالضبط كيف يتعامل كل نموذج مع الضغط.
إلى جانب نماذج اللغة الكبيرة، يمنحك PicassoIA الوصول إلى أكثر من 90 نموذجًا لتحويل النص إلى صورة، منها PicassoIA Image Editor Pro و**PicassoIA Image**، إضافةً إلى توليد الفيديو، وتركيب الصوت، وإزالة الخلفية، وأدوات رفع الدقة، كل ذلك في مكان واحد.
جرّب GPT 5 أو Claude Opus 4.7 أو Kimi K2.6 اليوم. الصق شيئًا طويلًا وشاهد ما يحدث.
اختر لغتك
