بناء تطبيقات ذكاء اصطناعي تعمل بالفعل لا يتعلق بصياغة المطالبة (prompt) المثالية بقدر ما يتعلق بالتحكم في المعلومات التي تغذي بها النموذج. إذا سبق لك وأن جلست في دردشة طويلة مع مساعد ذكي، لتدرك فقط أنه نسي شيئاً قلته قبل عشر دقائق، فقد شعرت بالفعل بما يحدث عندما تفشل هندسة السياق. من السهل افتراض أن الذكاء الاصطناعي يعاني من ضعف الذاكرة، ولكن في الواقع، لقد اصطدمت بالحدود الصارمة لنافذة السياق (context window).
لبناء أنظمة تظل موثوقة وسريعة الاستجابة، تحتاج إلى فهم ثلاث ركائز أساسية: الرموز (tokens)، ونوافذ السياق (context windows)، والفرق بين السياق والذاكرة.
الرموز (Tokens) هي العملة الحقيقية
الرمز (token) ليس كلمة. عندما ترسل نصاً إلى نموذج، تقوم أداة تقسيم الرموز (tokenizer) بتقسيمه إلى قطع أصغر. الكلمات القصيرة الشائعة مثل "cat" أو "the" قد تشغل رمزاً واحداً لكل منها. أما المصطلح التقني المكثف مثل "internationalization" فيتم تقسيمه إلى عدة رموز. كما تُحتسب علامات الترقيم، والمسافات، والرموز الخاصة أيضاً. هذا الأمر بالغ الأهمية لأن الرموز تحكم كل شيء: فاتورة واجهة برمجة التطبيقات (API) الخاصة بك، وسرعة الاستجابة، وجودة المخرجات.
المطور الذي يخطط للتكاليف عن طريق عد الكلمات يسير في عماء. فالمطالبة المكونة من مائة كلمة والمملوءة بأقواس الكود وأسماء المتغيرات الطويلة يمكن أن تتضخم بما يتجاوز التوقعات بكثير. لهذا السبب توجد أدوات تقسيم الرموز (tokenizers) كأدوات مستقلة. قبل أن تطلق ميزة جديدة، قم بتشغيل البيانات المرسلة (payloads) النموذجية الخاصة بك عبر إحدى هذه الأدوات. ستكتشف غالباً أن تعليمات النظام، والنصوص البرمجية النمطية (boilerplate) للتنسيق، وسجل الدردشة تستهلك جزءاً من ميزانيتك أكثر من استعلام المستخدم الفعلي. تعامل مع الرموز كمورد نادر منذ اليوم الأول.
نافذة السياق هي سبورة بيضاء ثابتة
نافذة السياق هي إجمالي كمية المعلومات التي يمكن للنموذج رؤيتها في طلب واحد. فكر فيها كسبورة بيضاء ذات أبعاد ثابتة. يمكنك ملؤها بقواعد النظام، وسجل المحادثة، والمستندات المسترجعة، والسؤال الحالي. ولكن بمجرد تغطية السطح بالكامل، لا بد من التضحية بشيء ما؛ إذ يجب مسح الملاحظات القديمة، أو تصويرها وتلخيصها، أو ستفيض السبورة ببساطة.
تعلن النماذج الحديثة عن نوافذ سياق تتراوح من بضعة آلاف من الرموز إلى مئات الآلاف. ومن المغري التعامل مع النافذة الأكبر كمساحة تخزين غير محدودة، لكنها ليست كذلك؛ فالسبورة لا تزال لها حواف. عندما يتجاوز السجل الحد المسموح به، يجب على التطبيق إسقاط الرسائل القديمة أو ضغطها. فهم هذا القيد يساعدك على التوقف عن معاملة النافذة كقاعدة بيانات والبدء في معاملتها كمساحة عمل نشطة.
السياق ليس ذاكرة
إليك تمييز يربك حتى المطورين ذوي الخبرة: النموذج نفسه عديم الحالة (stateless). فهو لا يتذكرك من الأمس، أو من الأسبوع الماضي، أو من عشر دقائق مضت في جلسة مختلفة. عندما يبدو أن الذكاء الاصطناعي يتذكر أنك تفضل Python على JavaScript، أو أنك تحب الإجابات الموجزة، فإن هذه الذاكرة تعيش في طبقة التطبيق، وليس في النموذج.
يقوم التطبيق بتخزين تلك الحقائق في قاعدة بيانات، أو ذاكرة مؤقتة (cache)، أو مخزن ذاكرة. وفي كل طلب جديد، يقوم التطبيق بحقن بيانات الملف الشخصي ذات الصلة مرة أخرى في المطالبة. النموذج ببساطة يقرأ نصاً يتضمن أسطره من الفصل الأول؛ فهو لا يملك ذاتاً مستمرة. بمجرد استيعاب هذا الفصل، ستتغير بنيتك البرمجية؛ حيث ستتوقف عن مطالبة النموذج بالتذكر، وتبدأ في تصميم أنظمة تجلب السياق الصحيح في الوقت الصحيح.
لماذا قد يؤدي المزيد من السياق إلى نتائج عكسية
يوحي المنطق السليم بأن المزيد من المعلومات الخلفية يجب أن ينتج إجابات أفضل، ولكن غالباً ما يحدث العكس. السياق الزائد يخلق ضجيجاً. إذا قدمت للنموذج قاعدة بيانات برمجية كاملة بينما تحتاج فقط إلى إصلاح دالة واحدة، فإنك تجبره على البحث عن إشارة وسط الضجيج. وقد حدد الباحثون تأثير "الضياع في المنتصف" (Lost in the Middle): حيث تولي النماذج اهتماماً أكبر للتفاصيل الموجودة في بداية المطالبة ونهايتها، بينما يتم تمييع المعلومات المدفونة في المنتصف أو تجاهلها. هذا ليس خطأً برمجياً يمكنك إصلاحه بصياغة ذكية، بل هو سلوك هيكلي موجود في البنى القائمة على تقنية المحولات (transformer-based architectures).
كما أن المطالبات المتضخمة تضربك في مقتل؛ فكل رمز إضافي يتطلب عمليات حوسبة، مما يؤدي إلى ارتفاع زمن الاستجابة (latency)، وزيادة التكاليف، وتضاؤل صبر المستخدم. المطالبة المحشوة بمستندات غير ذات صلة تسبب تناقضات، وتشتت النموذج بتفاصيل جانبية، وتزيد من احتمالية تركيز الاستجابة على المشكلة الخاطئة. الحجم هو عدو الدقة.
كيف تهندس سياقاً أفضل
هندسة السياق الجيدة هي تمرين في التحرير الصارم. إليك كيفية تطبيق ذلك عملياً.
أرسل فقط ما تتطلبه المهمة. إذا سأل المستخدم عن سياسة الاسترداد الخاصة بك، فلا تدرج دليل الموظفين، ووثائق API، والنسخة التسويقية للربع الأخير. الأهمية تغلب الشمولية.
استخدم RAG لاسترجاع المستندات ذات الصلة. تتيح لك تقنية "التوليد المعزز بالاسترجاع" (Retrieval-Augmented Generation) البحث في قاعدة معرفية ضخمة وحقن الفقرات الأكثر مطابقة فقط في المطالبة (prompt). بدلاً من إلقاء دليل مكون من ألف صفحة في نافذة الدردشة، يمكنك تضمين (embed) مستنداتك، وإجراء بحث دلالي (semantic search) بناءً على استعلام المستخدم، وتضمين الفقرات الثلاث الأكثر صلة. يحصل النموذج على ما يحتاجه بالضبط، وتظل ميزانية الرموز (tokens) الخاصة بك سليمة.
لخّص المحادثات القديمة. تُعد سجلات الدردشة الكاملة مكلفة ومشتتة. استبدل سجلات الرسائل الطويلة بملخصات مستمرة. على سبيل المثال، بدلاً من تزويد النموذج بثلاثين رسالة متبادلة، قم بتخزين فقرة واحدة: "سأل المستخدم عن نشر Django، وواجه خطأ في الملفات الثابتة (static files)، وقام بإصلاح الأذونات. المشكلة الحالية هي فشل ترحيل قاعدة البيانات على Postgres 14". يحافظ هذا الملخص على الحالة دون إحداث فوضى في "السبورة".
افصل الذاكرة طويلة المدى عن الدردشة النشطة. تنتمي تفضيلات المستخدم، وإعدادات المشروع، وسجل الحساب إلى مخزن ذاكرة خارجي. قم بالاستعلام من ذلك المخزن بشكل انتقائي. يجب أن تحمل نافذة السياق المباشرة المهمة الحالية وأوجز سياق شخصي مطلوب للحفاظ على الاستمرارية فقط.
راقب استخدام الرموز (tokens) في بيئة الإنتاج. غالباً ما تعود طفرات التأخير (latency spikes) مباشرة إلى تضخم السياق. ضع تنبيهات عندما تقترب الطلبات من حد النموذج الخاص بك. راجع السجلات لتحديد المطالبات (prompts) التي تحمل عبئاً زائداً. يبدأ التحسين بنفس السؤال في كل مرة: ما الذي يمكننا إزالته دون إفساد المهمة؟
الخلاصة الحقيقية
لا تفوز أفضل تطبيقات الذكاء الاصطناعي لأنها تمتلك أكبر نوافذ سياق، بل تفوز لأنها تدير السياق بانضباط. السبورة الضخمة لا فائدة منها إذا كانت مغطاة بالخربشات. ابنِ أنظمة تقوم بالاسترجاع، والتلخيص، والفلترة. سيحصل مستخدموك على إجابات أسرع، وستظل تكاليف بنيتك التحتية قابلة للتنبؤ، وستبدأ نماذجك أخيراً في التركيز على ما يهم حقاً.
المصدر: AI Context Engineering: Tokens, Context Windows, & Memory
المجتمع: GyaanSetu AI on Telegram
