ماذا يحدث داخل Claude عندما تكتب برومبت؟

بعد أن تكتب سؤالك وتضغط إرسال يبدأ النموذج بالرد في ثوانٍ. وبينما تقرأ الإجابة، يبدو المشهد طبيعياً تقريباً، كأنك تراسل شخصاً يفكر ثم يكتب.

لكن ما يحدث فعلياً داخل Claude في تلك الثواني لا علاقة له بالتفكير بالمعنى الذي نعرفه.

فكلماتك لا تدخل إلى النموذج كلماتٍ. ولا تخرج الإجابة لأن Claude “فهم” ما تريده. فما يجري بين كلماتك والرد الذي تقرأه سلسلة من العمليات الرياضية: تحوّل نصك إلى أرقام، ثم تزنها، و تحسب احتمالات، ثم تُعيد بناء نص جديد توكناً تلو الآخر.

فمعرفة كيف يعمل Claude من الداخل ليست ترفاً تقنياً. فهي ما تفصل بين من يحصل على إجابة عشوئية ومن يحصل على الإجابة التي يريدها فعلاً .

الكلمة لا تدخل كلمةً

قبل أن يرى Claude جملتك، فهي تمر بمرحلة لا يراها أحد:

فخوارزمية Byte Pair Encoding، المعروفة اختصاراً بـ BPE، تُفكّك النص إلى وحدات أصغر تسمى tokens. الكلمة الإنجليزية القصيرة “cat” توكن واحد. كلمة مركبة مثل “unbelievable” قد تُقطَّع إلى ثلاثة توكنات. أما الجملة العربية فقصة مختلفة.

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

مع Claude 3.5 وما تلاه، تحسّن الأمر. انخفض المعدل إلى ما بين 1.7 و1.8 توكن لكل كلمة عربية. لكن الفجوة لم تُغلق.

ما الذي يعنيه هذا عملياً؟

حين تكتب رسالة بالعربية وتستقبل رداً بالعربية، تدفع فاتورة توكنات أعلى مقارنة بمن يكتب بالإنجليزية ويحصل على محتوى مكافئ. في الاستخدام الشخصي الفارق محدود. في الاستخدام المؤسسي الممتد عبر API، ملايين الطلبات شهرياً، هذا الفارق يتحوّل إلى رقم مالي حقيقي.

لكن التقطيع ليس نهاية القصة.

كل توكن يتحوّل إلى متجه رياضي، سلسلة من الأرقام تمثل موقعه في فضاء المعنى. ثم تبدأ العملية التي تُعرَّف بها بنية المحوّل: كل توكن يُقيّم علاقته بكل توكن آخر في النص، ليس بالترتيب فحسب، بل في وقت واحد وفي كل الاتجاهات.

هذا ما يتيح للنموذج أن يربط الضمير في نهاية الجملة باسم في بدايتها دون أن يقرأها خطياً كما نفعل نحن.

والنتيجة ليست إجابة. بل احتمال.

النموذج يحسب التوكن الأكثر احتمالاً في كل خطوة، يضيفه إلى السياق، يحسب من جديد، يضيف، يحسب. الرد الكامل الذي تقرأه ناتج مئات أو آلاف من هذه الخطوات التسلسلية.

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

موقع الفكرة داخل البرومبت يحدد وزنها

هذه النقطة يتجاهلها معظم من يكتبون عن البرومبتات.

دراسة نُشرت على منصة arXiv بعنوان “Lost in the Middle” أثبتت ما يبدو بديهياً حين تعرفه لكنه غير واضح قبل ذلك: النموذج لا يعالج أجزاء النص بأوزان متساوية.

المعلومات في البداية تحظى بوزن أكبر بسبب ما يُسمى Primacy Bias. المعلومات في النهاية تحظى بوزن أكبر أيضاً بسبب Recency Effect. أما ما يقع في الوسط، خاصة في النصوص الطويلة، فعُرضة للضياع.

هذا يعني شيئاً بسيطاً لكن مهماً: كل برومبت تكتبه له هندسة داخلية، وهذه الهندسة تؤثر على الإجابة بمعزل عن جودة محتواك.

مثال عملي: برومبت قبل وبعد

تخيل أنك تريد من Claude تلخيص وثيقة قانونية طويلة بأسلوب بسيط وبالعربية فقط.

البرومبت الضعيف يبدو هكذا:

“الرجاء تلخيص هذه الوثيقة. يجب أن يكون الأسلوب بسيطاً والرد بالعربية فقط. [ثم تأتي الوثيقة كاملة في المنتصف]”

المشكلة: التعليمات الجوهرية، الأسلوب واللغة، دُفنت في البداية قبل الوثيقة. بحلول نهاية المعالجة، وزنها في آلية الانتباه قد تراجع.

البرومبت المحسّن:

“[الوثيقة كاملة هنا] لخّص هذه الوثيقة بأسلوب بسيط يفهمه غير المتخصص. الرد بالعربية فقط، لا تتجاوز 200 كلمة.”

التعليمات الجوهرية في النهاية. الوثيقة في البداية كسياق. النتيجة في الغالب أدق وأقرب لما تريد.

Claude في إصداراته الحالية يدعم نافذة سياق تبلغ 200,000 توكن، ما يعادل تقريباً 150,000 كلمة إنجليزية، أو أقل بالعربية بسبب تضخم التوكنات. رقم ضخم، لكنه يخفي مشكلة: الأداء لا يبقى ثابتاً عبر هذا الحجم كله.

في اختبار “Needle in a Haystack”، وهو اختبار قياسي يقيس قدرة النموذج على استرجاع معلومة مدفونة داخل سياق ضخم، ينخفض الأداء انخفاضاً ملحوظاً كلما اقتربت المعلومة من المنتصف وكلما زاد حجم السياق الإجمالي.

النموذج لا يملك ذاكرة دائمة خارج السياق الحالي. حين يتجاوز الحوار حدود النافذة، تُحذف التوكنات الأقدم لإفساح المجال للجديدة. بداية الحوار تختفي ببساطة.

تفصيلة أخرى تستحق الانتباه: التنسيق الهيكلي.

Anthropic توصي في وثائق مطوّريها باستخدام وسوم XML داخل البرومبتات الطويلة والمعقدة. عبارات من قبيل <context></context> أو <instructions></instructions> تساعد النموذج على الفصل بين أنواع المدخلات وتقليل الخلط بين السياق والتعليمات. ليست مجرد تنسيق جمالي، بل إشارة هيكلية تُسهم في توزيع الانتباه بشكل أوضح.

الدستور الذي لا تراه

حين يرفض Claude طلباً أو يُعيد صياغته أو يُضيف تحفظاً لم تطلبه، كثيرون يصفون ذلك بالرقابة المبرمجة. الوصف دقيق في نتيجته، مُضلّل في آليته.

ما يجري فعلياً يختلف.

Anthropic طوّرت ما تسمّيه Constitutional AI. الفكرة الجوهرية: بدلاً من الاعتماد الكلي على تقييم بشري لكل استجابة في مرحلة التدريب، يتعلم النموذج تقييم استجاباته ذاتياً بناءً على مجموعة مبادئ مكتوبة، دستور.

وثّقت Anthropic هذه الآلية في ورقة بحثية بعنوان “Constitutional AI: Harmlessness from AI Feedback“، ونشرت نص الدستور علناً. في أحدث نسخه يصل إلى قرابة 23,000 كلمة.

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

هذا يفسّر لماذا لا يرفض Claude بأسلوب قاطع جاف دائماً، بل يُعيد صياغة السؤال أو يُجيب على جانب منه أو يشرح تحفظه. هذا النمط ليس عشوائياً.

لكن هذا التفسير مقنع جزئياً، لا كلياً.

الدستور نفسه ليس محايداً. المبادئ المكتوبة فيه تعكس منظومة قيمية محددة، غربية في صياغتها وأولوياتها. حين يُطبَّق على سياقات عربية أو ثقافية مختلفة، تظهر احتكاكات حقيقية: ما يُصنَّف ضاراً في سياق ثقافي قد لا يكون كذلك في سياق آخر.

الدستور وحده لا يتحكم في كل استجابة. تتشابك معه بنية النموذج وبيانات التدريب الإضافية. لكن ما يمكن قوله بثقة: رفض Claude ليس قراراً لحظياً، بل ميل مُرسَّخ في طبقات التدريب. ومعرفة هذا تغيّر طريقة الكتابة له.

العربية في نموذج لم يُبنَ لها

نقطة تستحق أن تُقال بوضوح.

Claude يتعامل مع العربية بكفاءة لافتة مقارنة بما كانت عليه النماذج قبل سنوات. لكن “أفضل مما كان” لا يعني “متكافئ مع الإنجليزية”. الفجوة حقيقية وذات أبعاد ثلاثة تتراكم على المستخدم العربي.

التكلفة أولاً.

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

في معاملة واحدة الفارق هامشي. في بنية تقنية تعالج ملايين الطلبات يتراكم حتى يصبح قراراً مالياً حقيقياً.

الأداء ثانياً.

الاستدلال المنطقي المعقد، والتحليل متعدد الخطوات، والتفكير الرياضي، كل هذه المهام تحتاج قدرة استدلالية مبنية على بيانات تدريب غزيرة. الإنجليزية حاضرة في تلك البيانات بكثافة تفوق العربية بمراحل.

النتيجة أن النموذج يؤدي هذه المهام بدقة أعلى حين يُكتب البرومبت بالإنجليزية، حتى لو كان القارئ النهائي عربياً. وهذا يضع المستخدم العربي في معادلة غير مريحة: إما أن يكتب بلغته ويقبل بأداء أدنى في المهام المعقدة، أو يتخلى عن لغته كأداة تفكير ليحصل على نتيجة أفضل.

السيادة ثالثاً، وهي الأعمق.

نموذج مُكيَّف للعربية يختلف جوهرياً عن نموذج مبني للعربية. الأول يُحاكي، والثاني يُفكّر.

حين يُجيب Claude عن سؤال في السياق العربي، يُجيب بناءً على فهم تشكّل أساساً داخل منطق لغوي وثقافي آخر ثم طُبّق على العربية. الفرق لا يظهر في الأسئلة العامة، بل يكشف عن نفسه في الحالات الحدية: الأسئلة الدقيقة ثقافياً، الفروق الدلالية التي لا تنتقل بين اللغتين، السياقات التي تحتاج خلفية عربية لا مجرد ترجمة للمفاهيم.

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

ما يحدث هنا لا يُحلّ بتحسين نسبة التوكنات وحده. يحتاج نماذج مبنية من الأساس على بيانات عربية غزيرة وبنية لغوية أصيلة. وهو ما لا يزال ينتظر من يبنيه.

ست نقاط تغيّر طريقة كتابتك

الفهم التقني يستحق أن يُترجم إلى سلوك مختلف أمام الشاشة.

ضع التعليمات الجوهرية في نهاية البرومبت.
المعلومة في الوسط معرّضة للضياع في السياقات الطويلة. البداية والنهاية تحظيان بوزن أكبر في آلية الانتباه.

لا تفترض أن النموذج يلتقط كل شيء في السياق الطويل.
نافذة 200,000 توكن لا تعني أداءً متساوياً عبرها. كلما طال السياق، ضعف الأداء على المعلومات المدفونة في المنتصف.

استخدم التنسيق الهيكلي في البرومبتات المعقدة.
الفصل الواضح بين السياق والتعليمات والأمثلة يساعد النموذج على معالجة كل جزء بدقة أكبر.

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

اعرف لماذا يرفض النموذج.
الرفض ليس عشوائياً. تغيير صياغة السؤال كثيراً ما يغيّر النتيجة، لأنك تُشكّل بيئة إحصائية مختلفة لا لأنك تتحايل.

لا تُغرق البرومبت بسياق لا يخدم المهمة.
كل توكن إضافي تكلفة، وكل معلومة زائدة احتمال إضافي للتشويش. البرومبت الجيد حادٌّ لا طويل.

حين تعرف كلمتك

حين تعرف أن كلمتك تُقطَّع وتتحوّل إلى رقم قبل أن “يراها” النموذج، يتغير شيء في طريقة تعاملك معه. ليس لأنك تفقد الثقة به، بل لأن ثقتك تصبح أكثر دقة.

جرّب الآن: خذ آخر برومبت كتبته وأعد هيكلته. ضع السياق في البداية، والتعليمات الجوهرية في النهاية، واحذف كل ما لا يخدم المهمة مباشرة. الفرق في الغالب يظهر من المحاولة الأولى.

يبقى سؤال لا تُجيب عنه هذه الآلية كلها: حين يُنتج النموذج نصاً يبدو متماسكاً وأحياناً مدهشاً، هل يعكس ذلك شيئاً أعمق من حساب الاحتمالات؟ أم أن التماسك نفسه وهم تُنتجه سلسلة التوكنات؟

لا أحد يملك إجابة قاطعة. ما نملكه هو أن نفهم الآلة بما يكفي لنستخدمها جيداً، ونبقى واعين بما تفهمه منّا فعلاً.