كيف تعمل النماذج اللغوية الكبيرة فعلياً

ما هو الـ LLM؟

يرمز الـ LLM إلى Large Language Model (أي نموذج لغوي كبير). تجاهل الضجيج التسويقي، وإليك ما يفعله فعلاً:

تعطيه نصّاً، فيتنبّأ بالـ token التالي.

هذه هي عملية التوليد الجوهرية. يتعلّم الـ LLM أنماطاً إحصائية من مزيج ضخم من النصوص وغيرها من بيانات التدريب، ثم يوظّف تلك الأنماط token بعد آخر ليولّد الرد.

حين تسأل "ما عاصمة فرنسا؟" لا يبحث النموذج عن الجواب في قاعدة بيانات، بل يتنبّأ، انطلاقاً من نمط سؤالك، بأنّ أرجح ما يليه هو "عاصمة فرنسا هي باريس".

الـ tokens: كيف يرى النموذج النص

لا تقرأ الـ LLMs الكلمات كما تقرؤها أنت، بل تُقسّم النص إلى tokens: قطع صغيرة قد تكون كلمات كاملة، أو أجزاء من كلمات، أو حتى حروفاً مفردة.

لكل نموذج حدّ للـ tokens (token limit)، أي أقصى عدد من الـ tokens يمكنه معالجتها دفعةً واحدة. وهذه ليست مجرّد معلومة عابرة، بل القيد الجوهري الذي يُشكّل طريقة عمل الـ LLMs.

الـ context window

الـ context window هي الذاكرة العاملة للنموذج، أي مجموع النص الذي يستطيع "رؤيته" في أي لحظة: رسائلك وردوده وأي تعليمات من المطوِّر.

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

أمثلة على أحجام الـ context window (يختلف الحدّ الدقيق باختلاف النموذج والمنتج):

• 4K token: نحو 3,000 كلمة (النماذج المبكّرة)
• من 128K إلى 1M token: نحو 100,000 إلى 750,000 كلمة (متاحة في كثير من نماذج السياق الطويل الحالية)
• 1M+ token: نحو 750,000 كلمة أو أكثر (تدعمها بعض النماذج الحالية)

كل استدعاء للـ API يتلقّى سياقه

إليك ما لا يدركه معظم الناس: الـ LLM الأساسي لا يحتفظ من تلقاء نفسه باستدعاء الـ API السابق. فلا بدّ أن يزوّده التطبيق بالسياق اللازم لكل دورة جديدة.

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

تنقّل بين الدورات لترى ما الذي يُرسَل فعلاً. (صفّ "التعليمات" هو نصّ الإعداد الخفيّ الذي يكتبه المطوِّر، وستتعرّف عليه في الوحدة التالية.)

لاحظ كيف يتضخّم السياق في هذا المثال البسيط: الدورة 1 ترسل رسالتين، والدورة 2 ترسل 4، والدورة 3 ترسل 6. لا يواصل النموذج المحادثة داخلياً؛ بل يزوّده التطبيق بالنص مجدداً، فيتنبّأ بما يليه.

حين تمتلئ الـ context window، لا بدّ أن يُسقط التطبيق المادة الأقدم أو يلخّصها أو يسترجعها عند الحاجة. وأي شيء لا يضمّنه في الطلب التالي لا يكون متاحاً لذلك الاستدعاء من النموذج.

لماذا يهمّ هذا للأمن

إذا كان الـ LLM، في جوهره، متنبّئاً بالـ token التالي بنافذة نصّية محدودة وبلا ذاكرة بين الطلبات، فإنه:

• لا يمكن ضمان "اتّباعه للقواعد"؛ فهو يولّد نصّاً متّسقاً إحصائياً مع تعليماته وتدريبه، فمُدخَل مصاغ بذكاء قد يحرفه عنها
• لا يستطيع "حماية الأسرار" بشكل موثوق؛ فأي شيء داخل الـ context window مجرّد نصّ، والـ prompt المناسب كثيراً ما ينجح في استخراجه
• لا يملك داخل سياق اللغة الطبيعية حدّاً أمنياً صارماً يضمن ألّا تتحوّل البيانات غير الموثوقة إلى تعليمات؛ يساعد ترتيب أدوار الرسائل، لكنه ليس نظام صلاحيات حتمياً

كل ثغرة أمنية في الذكاء الاصطناعي ستتعلّمها تعود جذورها إلى هذه الأساسيات.

والآن وقد عرفتَ حقيقة الـ LLM، يبقى سؤال: كيف يتحكّم المطوّرون في سلوكه؟ هنا يأتي دور الـ system prompt، ومن هنا تبدأ الهشاشة بالتسرّب.

المصادر

• Attention Is All You Need: البحث الذي قدّم بنية الـ Transformer التي تقوم عليها نماذج الـ LLM الحديثة
• Google Gemini API: Long context: أمثلة حديثة على الـ context windows الطويلة وسلوكها