لماذا يوجد zev

يوجد zev للإجابة مباشرة عن مجموعة محددة من الأسئلة: كيف يجب أن تُخزَّن الملفات الكبيرة والنماذج وتُزامَن فعليًا، وماذا يجب أن يخبرك الفرق عن كود تغيّر بنيويًا، ولماذا يعيد CI غالبًا عملاً قام به بالفعل، وكيف نتتبّع النسب الكامل لنموذج من البيانات الخام عبر كل تجربة إلى نتيجة منشورة — كل ذلك داخل محرك واحد، معنوَن بتجزئات المحتوى في كل مكان. ## الملفات الكبيرة تغيّر اقتصاديات المزامنة معاملة كل ملف ككتلة (blob) مبهمة يعني أن تغيير بايت واحد في ملف كبير يفرض إعادة نقل ذلك الملف بالكامل. بالنسبة للكود المصدري، نادرًا ما يكون هذا مشكلة — معظم التعديلات صغيرة والملفات نفسها صغيرة. لكن بالنسبة للملفات النصية أو البيانات أو النماذج الكبيرة، يصبح هذا مكلفًا بسرعة. يعالج التقسيم المحدَّد بالمحتوى في zev هذا مباشرة. عند تقسيم ملف، وُجد أن تعديلًا قرب بداية ملف بحجم 1.7 ميجابايت، على بيانات حقيقية، يتطلب إعادة نقل حوالي 1% فقط من إجمالي أجزاء الملف — أما الباقي فكان موجودًا بالفعل على الجانبين وتم تجاوزه تمامًا، سواء عند الدفع (push) أو السحب (pull). ## الفرق النصي لا يخبرك بما تغيّر فعليًا تُظهر الفروق المبنية على الأسطر الأسطر التي تغيّرت. لكنها لا تخبرك أن دالة أُعيدت تسميتها بدلاً من حذفها وإضافة أخرى مختلفة، أو أن توقيع دالة فقط هو ما تغيّر بينما بقي جسمها مطابقًا. يمكن لإنسان يقرأ الفرق أن يستنتج هذا غالبًا، لكن أداة آلية لا يمكنها ذلك، ليس بشكل موثوق. يحلّل الفرق الدلالي في zev كود Zig المصدري بمحلّل AST حقيقي ويُبلّغ عن التغييرات البنيوية مباشرة: `signature_changed`، `body_changed`، `likely_rename`، `added`، `removed` — محسوبة من البنية الفعلية المحلَّلة للكود، وليست مخمَّنة من أنماط نصية. ## وقت CI يهيمن عليه العمل غير المتغيّر تعيد معظم تشغيلات CI تنفيذ خطوات مدخلاتها — محتوى المصدر الدقيق، صورة الحاوية، الأمر — متطابقة مع تشغيل ناجح سابق. يمكن لـCI الخاص بـzev اكتشاف هذا وتجاوز الخطوة بالكامل، وتقديم النتيجة السابقة بدلاً من إعادة تشغيل Docker. في اختبار حقيقي ومقاس، خفّض هذا تنفيذ الخطوة من 0.53 ثانية (تشغيل حقيقي) إلى 0.01 ثانية (مقدَّم من الذاكرة المؤقتة) لخطوة غير متغيّرة. ## تاريخ النموذج أكثر من مجرد commits الخاصة به يشمل التاريخ الحقيقي لنموذج تعلّم الآلة مجموعة البيانات التي تدرّب عليها، وتقسيم الأجزاء الذي استخدمه، وكل تجربة شكّلت بنيته، وكل دمج لنقاط التفتيش جمعه مع تشغيل آخر. يتتبّع zev كل هذا كبيانات من الدرجة الأولى وموجَّهة بالمحتوى: `zev dataset` و`zev lineage` للنسب، و`zev experiment` للفرضيات والنتائج، و`zev drift` و`zev threshold` لاكتشاف الانحدارات تلقائيًا، و`zev merge-weights` لدمج نقاط التفتيش باستراتيجيات حقيقية على مستوى الموترات (المتوسط، الاستيفاء الموزون، SLERP، TIES-merging) — وليس مجرد دمج ملفات نصية تحتوي أرقامًا مصادفة. ## بُني ليتوسّع إلى ما هو أبعد من التحكم بالإصدارات صُمم نموذج الكائنات في zev، والعنونة بالمحتوى، ورسم النسب البياني المبني على IPLD كأساس عام الغرض، وليس مجموعة ميزات ثابتة. تتتبّع `zev context` بالفعل أي التغييرات جاءت من إنسان وأيها من نموذج ذكاء اصطناعي، وبأي موجّه (prompt)؛ ترسو `zev notarize` النتائج على السلسلة؛ تدمج `zev fedmerge` العمل بشكل نظير-إلى-نظير دون أي خادم مركزي. أُضيف كل واحد من هذه فوق نفس المحرك الذي يخزّن commit الأول الخاص بك — القصد أن يستمر هذا النمط، كمحرك للكود والبيانات والعمل المدفوع بالذكاء الاصطناعي عمومًا، وليس نظام تحكم بالإصدارات مع إضافات.