تقوم بلصق مائة صفحة من التوثيق في المطالبة (prompt) وتطرح سؤالاً بسيطاً. تأتي الإجابة خاطئة. أو تتجاهل قاعدة التنسيق التي وضعتها في الأعلى. لقد أعطيتها كل شيء. كان من المفترض أن تنجح العملية. لكنها لم تنجح.
هذا هو "فخ السياق" (context trap). يفترض معظم المطورين أن تزويد الذكاء الاصطناعي بمزيد من المعلومات يؤدي تلقائياً إلى نتائج أفضل. ولكن غالباً ما يكون العكس هو الصحيح. يتطلب بناء تطبيقات ذكاء اصطناعي موثوقة فهم ثلاث آليات أساسية: كيف تحسب النماذج النصوص، وكم يمكنها استيعابه في المرة الواحدة، وماذا يحدث للمعلومات بمجرد انتهاء المحادثة.
الرموز (Tokens): العملة الحقيقية
الرمز (token) هو أصغر وحدة يعالجها النموذج اللغوي. قد يكون حرفاً واحداً، أو جزءاً من كلمة، أو كلمة شائعة بالكامل. غالباً ما تنقسم كلمة "purchase" إلى رمزين، بينما تظل كلمة قصيرة مثل "cat" كما هي. تستهلك علامات الترقيم والمسافات الرموز أيضاً. أما الكود البرمجي فهو "شره" بشكل خاص؛ فكتلة من كود Python تحتوي على إزاحات متداخلة ورموز خاصة يمكن أن يتضخم عدد رموزها ليصل إلى ثلاثة أو أربعة أضعاف العدد الذي قد تخمنه بمجرد النظر إليها.
لماذا يجب على المطورين الاهتمام؟ تسعير الـ API يعتمد على الرمز. وكذلك وقت المعالجة. فالمطالبة التي تبدو كصفحتين من النص قد تكلف قروشاً أو دولارات اعتماداً على محتواها. والأسوأ من ذلك، أن الرموز تتراكم على كلا جانبي التبادل؛ فأنت تدفع مقابل كل رمز في مطالبتك، وتدفع أيضاً مقابل كل رمز يولده النموذج رداً عليك. إن النمو غير المنضبط للسياق يؤدي بصمت إلى تآكل هوامش الربح.
نافذة السياق هي بمثابة سبورة بيضاء
تحدد نافذة السياق (context window) الحد الأقصى لما يمكن للنموذج رؤيته في المرة الواحدة. تخيل سبورة بيضاء معلقة في غرفة صغيرة. يمكنك ملؤها بتعليمات النظام، وأسئلة المستخدم، والمستندات المسترجعة، والمحادثات السابقة. لكن السبورة لا تكبر أبداً؛ فعندما يصل نص جديد، يسقط النص القديم من الحافة.
هذا الأمر مهم لأن النماذج لا تحذرك عندما تبدأ في إسقاط المحتوى. إذا كانت تعليمات النظام الخاصة بك تقع في أعلى محادثة طويلة، واستمررت في إضافة الرسائل، فستخرج تلك التعليمات في النهاية عن نطاق الرؤية. قد يعود النموذج إلى السلوك الافتراضي، أو يتجاهل قواعد التنسيق الخاصة بك، أو يناقض التوجيهات السابقة. توفر النماذج المختلفة حدوداً مختلفة، حيث تتعامل بعضها مع بضعة آلاف من الرموز بينما يتعامل البعض الآخر مع مئات الآلاف، لكن الآليات تظل متطابقة. يتشارك المدخل والمخرج في نفس الميزانية؛ فالنموذج الذي يولد استجابة مكونة من ألفي رمز، تتوفر لديه ألفا رمز أقل لتذكر ما أخبرته به.
الذاكرة هي حيلة وليست ميزة
لا توجد ذاكرة مستمرة داخل أوزان النموذج أثناء عملية الاستدلال (inference). لا شيء على الإطلاق. عندما تغلق علامة التبويب وتعود غداً، لن يتعرف عليك النموذج. كل استدعاء للـ API هو بمثابة "بداية باردة" (cold start).
ما يبدو وكأنه ذاكرة ليس سوى عملية تنظيم حسابات ذكية من قبل طبقة التطبيق. تقوم الواجهة الأمامية (frontend) بتخزين رسائلك في قاعدة بيانات. وعندما ترسل استعلاماً جديداً، يقوم البرنامج بجلب التاريخ ذي الصلة، ودمجه في مطالبة جديدة، وإرسال الحزمة كاملة إلى النموذج. أما النموذج نفسه فيظل غافلاً عما يحدث.
هذا التمييز بالغ الأهمية لفرق المنتجات. إذا كنت تعتمد على النموذج لـ "تذكر" تفضيلات المستخدم، فأنت تبني على الرمال. عليك بناء إدارة الحالة (state management) بنفسك. قرر ما الذي يجب تخزينه مؤقتاً (cache). قرر كيفية تحديثه. وأدرك أن كل بايت من التاريخ تعيد إرساله يستهلك مساحة "السبورة البيضاء" الخاصة بك.
عندما يصبح السياق ضجيجاً
يؤدي إغراق المطالبة بالمعلومات إلى نتائج عكسية بطرق يمكن التنبؤ بها.
الضجيج يقتل الإشارة. إذا قمت بإلقاء قاعدة بيانات برمجية كاملة لتسأل عن خطأ واحد، فسيواجه النموذج مشكلة "إبرة في كومة قش". قد يشير إلى الملف الخاطئ، أو يقترح تغييرات على كود غير مستخدم، أو يقدم إجابة عامة لأنه لا يستطيع