v0.1، محرك استدلال يقدر يشرح ما فعله

استخراج الـ tensor هو الجزء السهل. معرفة ما يعنيه، أي طبقة، أي موضع، أي مسار تنفيذ، أي kernel، هو الهندسة.

المشكلة: الـ probes تحتاج hidden states بمصادر معروفة

سبب وجود Ember سؤال بحثي عن الصرف العربي: أين في المحوّل تمثّل الجذور والأوزان، وليش يفشل توافر التمثيل أحيانًا في إنتاج سلوك توليدي؟ كل صيغة من صيغ داك السؤال تبدأ فعلًا نفسه: خذ tensor من نموذج يشتغل وقل شيء عنه. الفعل لا يكون ذا معنى إلا إذا عُرف مصدر الـ tensor بدقة، أي نموذج، أي طبقة، أي موضع token، أي مسار تنفيذ، وما سبقه.

تفريغ hidden state من غير داك السياق مو دليلًا؛ إنه رقم. الادعاء المركزي لالمقال دا هو ادعاء إصدار v0.1: تفريغ الـ hidden states لا يفيد ما لم يُعرف مصدره الدلالي والرقمي الدقيق. بنى v0.1 المحرك اللي يجعل داك المصدر صريحًا.

الحل الساذج: تفريغ ما يحسبه النموذج

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

• هوية الـ tensor، أي طبقة أنتجت هذي الذاكرة؟ هل هي قبل أو بعد residual؟ أي norm غذّاها؟
• الموضع، للـ prompt tokens كثيرة وللـ decode خطوات كثيرة. تفريغ لا يقول لأي موضع ينتمي الصف مو ممكن محاذاته مع أي شيء.
• المسار، أي kernel نفّذ هذا الإسقاط، ومن أي تمثيل (كتل Q8 مضغوطة أم f32 موسّعة)؟ ممكن لجريانين أن ينتجا اسم الملف نفسه وأرقامًا مختلفة.

ليش فشل: المحمّل كان يملك الإجابات

محمّل v0.1 (CHANGELOG.md، v0.1: تحميل GGUF v3 لـ F32/F16/BF16/Q8_0؛ أوزان Q8_0 عبر mmap؛ kernels فك ترميز SIMD؛ prefill مقسّم) كان يعرف كل ما يحتاجه الباحث: الـ dtype، الشكل، الترتيب، الملف اللي جاء منه الـ tensor. المشكلة أن هذي المعرفة كانت تتوقف عند حدود المحمّل. كان على مسار الاستخراج أن يكتشفها من جديد، وصيغة GGUF تجعل داك صعبًا فعلًا:

• تُخزَّن tensors الـ linears وembeddings بصيغة f32/f16 بترتيب [in, out] مع كون البعد الأول متصلًا؛ تحتاج linears إلى تصحيح row-major وembeddings إلى مقايضة الأبعاد، ورأس lm مرتبط يحتاج transpose حقيقي، الخطأ في أي منها يفسد كل tensor لاحق بصمت (موثّق في docs/architecture.md ودوال الترتيب في المحمّل).
• إزاحات الـ tokenizer بايتات، لا محارف. استخراج يفترض إزاحات محارف ينكسر عند أول prompt عربي، وهو، لهذا المشروع، كل prompt.
• معالجة الـ dtype مُرقّمة بالإصدارات (إعادة ترقيم K-quant في 2024)؛ محمّل يفترض الأرقام القديمة يقرأ كل tensor K خطأ من غير خطأ.

النتيجة: الحصول على tensor ومعرفة ما يعنيه مشكلتان مختلفتان، والثانية هي الهندسة الفعلية.

التصميم: مسار مرجعي مقروء بالبناء

أبقى v0.1 مسار تنفيذ مرجعيًا غير مُحسَّن عمدًا باعتباره مرجع الصحة بجانب مسار Q8 السريع المضغوط: النموذج نفسه، والمدخلات نفسها، kernels عامة، وسطيات صريحة. لازم يتفق المساران على المخرجات الجشعة ضمن المغلفات المسجّلة (اختبارات A/B مضبوطة، واختبارات تتبّع بصمة وhidden states، CHANGELOG.md v0.1). المسار المرجعي مو خطة بديلة؛ إنه تعريف ما يُسمح للمسار السريع بتغييره.

ووفوق كدا: توليد مخزّن بالـ KV cache مع فك ترميز جشع حتمي، وتتبّع عمليات منظم، واستخراج حالات كامنة (CHANGELOG.md v0.1). "حتمي" هنا حتمية دلالية: حرارة 0 مع بذرة ثابتة تنتج الـ tokens نفسها والـ hidden states نفسها على الثنائي نفسه، لا بالضرورة أزمنة حائط متطابقة.

إيش يقول المحرك إنه فعل

الـ trace دفتر يوميات لكل عملية. في 2026-08-04، تتبّع الثنائي الحالي prefill من 6 tokens على Llama-3.2-1B Q8_0 إلى 275 حدثًا، كل حدث يحمل اسم العملية ونوعها وفهرس الطبقة وأشكال وأحجام المدخلات والمخرجات والمدة وتقدير FLOPs (artifacts/benchmark-v01/part1-legibility.md القسم 2):

{"duration_ns": 5896, "estimated_flops": 0, "input_bytes": 49152,
 "input_shape": [6, 2048], "layer": 18446744073709551615,
 "name": "embedding", "op_kind": "Embedding", "output_bytes": 49152}

كل طبقة وإسقاط وnorm وعملية attention تظهر بأشكالها وأحجامها؛ ومرحلة الـ decode تُتتبَّع لكل خطوة. الـ trace هو المحرك يقول ما فعله، مصدر كل tensor أنتجه، بالترتيب.

ومسار الاستخراج يكتب داك المصدر بجانب الـ tensors. استخراج مباشر على النموذج نفسه أنتج دليل تشغيل من 16 شرائح لكل طبقة (صف f32 ببعد 2048 لكل طبقة، موضع نهاية الـ prompt) إضافة إلى manifest يسجّل معمارية النموذج والـ tokenizer والخلفية وتجزئات العينات وتجزئة الإعداد وchecksums (artifacts/benchmark-v01/part1-legibility.md القسم 3). الـ artifact ذاتي الوصف: schema_version وlayout وtensor_contract وdtype وoutput_format وسجلات النموذج والـ tokenizer كاملة في الـ manifest، لا مفترضة.

سلم التحقق

أسس v0.1 كمان المفردات اللي تستخدمها السلسلة كلها (docs/validation.md): smoke (الأمر عمل) < golden logits (مقارنة المخرجات بمرجع موثوق) < فحوص المرجعية للتنشيطات (مقارنة الحالات الداخلية) < الـ probes (قابلية الفك) < التدخلات (الاستخدام السببي). كل درجة ادعاء مختلف. شحن v0.1 اختبارات golden logits وبصمة الـ trace للمسارات اللي يدعمها؛ والسلم هو ما يجعل "مدعوم" متميزًا عن "مُتحقق منه رقميًا في كل صف".

إيش اللي لا يشتغل بعد

• في v0.1، كانت فحوص المرجعية للتنشيطات معلّقة لعدة صفوف؛ "مدعوم" كان يعني وجود مسار تنفيذ، لا أن كل معمارية مُتحقق منها golden.
• دعم Qwen2.5 كان تجريبيًا صراحة؛ gemma 4 كانت نصية كثيفة بس، وتبقى فجوتها الرقمية غير موثوقة حتى اليوم.
• الافتراضي --arch كان يسقط بصمت إلى gpt2 لما يحتاج النموذج معمارية صريحة، فخ شُحن وأُصلح لاحقًا مع --arch auto.
• بايتات الـ tokenizer كانت مصدر أخطاء غير ASCII متكررة (أُصلحت في v0.5)؛ مسار ترميز الاستخراج لسه يحمل قيد إزاحات بايتية في v0.1.
• llama.cpp يبقى المرجع الخارجي للأداء؛ v0.1 لم يقدّم ادعاء إنتاجية، ولا يقدّمه المقال دا. صفحة إصدار v0.1 تسمي أرقامها "أرقام تحقق خاصة بالمضيف... لا لوحة صدارة".

إيش اللي أطلق هذا

معرفة من أين جاء الـ tensor ملاحظة. الخطوة التالية تغييره وملاحظة النتيجة، وهو ما يتطلب آلات الالتقاط والتعديل والاستعادة في v0.2.