از اینجا شروع کنید·۳ دقیقه مطالعه
چرا zev وجود دارد
zev برای پاسخ مستقیم به مجموعه‌ای خاص از پرسش‌ها وجود دارد: فایل‌های بزرگ و مدل‌ها واقعاً باید چگونه ذخیره و همگام‌سازی شوند، یک تفاوت باید چه چیزی درباره کدی که به‌صورت ساختاری تغییر کرده به شما بگوید، چرا CI اغلب کاری را که قبلاً انجام داده دوباره انجام می‌دهد، و چگونه شجره‌نامه کامل یک مدل را از داده خام تا هر آزمایش تا یک نتیجه منتشرشده ردیابی کنیم — همه درون یک موتور، که در سراسر آن با هش محتوا آدرس‌دهی شده است.
## فایل‌های بزرگ اقتصاد همگام‌سازی را تغییر می‌دهند
در نظر گرفتن هر فایل به‌عنوان یک blob مبهم به این معناست که یک بایت تغییر در یک فایل بزرگ، انتقال مجدد کامل آن فایل را ضروری می‌کند. برای کد منبع این به‌ندرت مشکل‌ساز است — اکثر ویرایش‌ها کوچک هستند و خود فایل‌ها کوچک هستند. اما برای فایل‌های متنی، داده یا مدل بزرگ، این موضوع به‌سرعت پرهزینه می‌شود.
تکه‌بندی تعریف‌شده بر اساس محتوای zev مستقیماً به این موضوع می‌پردازد. وقتی یک فایل تکه‌بندی می‌شود، یک ویرایش نزدیک به ابتدای یک فایل ۱.۷ مگابایتی روی داده‌های واقعی اندازه‌گیری شده و نشان داده که فقط حدود ۱٪ از کل تکه‌های فایل نیاز به انتقال مجدد دارند — بقیه از قبل در هر دو طرف حاضر بوده و کاملاً رد شده‌اند، هم در push و هم در pull.
## یک تفاوت متنی به شما نمی‌گوید واقعاً چه چیزی تغییر کرده است
تفاوت‌های مبتنی بر خط نشان می‌دهند کدام خطوط تغییر کرده‌اند. اما به شما نمی‌گویند که یک تابع تغییر نام یافته به‌جای حذف و اضافه‌شدن یک تابع دیگر، یا اینکه فقط امضای یک تابع تغییر کرده در حالی که بدنه آن یکسان مانده است. یک انسان که تفاوت را می‌خواند اغلب می‌تواند این را استنباط کند، اما یک ابزار خودکار نمی‌تواند، حداقل نه به‌طور قابل‌اعتماد.
تفاوت معنایی zev، کد منبع Zig را با یک تجزیه‌گر واقعی AST تجزیه می‌کند و تغییرات ساختاری را مستقیماً گزارش می‌دهد: `signature_changed`، `body_changed`، `likely_rename`، `added`، `removed` — محاسبه‌شده از ساختار واقعی تجزیه‌شده کد، نه حدس‌زده از الگوهای متنی.
## زمان CI بیشتر صرف کار بدون تغییر می‌شود
اکثر اجراهای CI مراحلی را دوباره اجرا می‌کنند که ورودی‌های آن‌ها — محتوای دقیق منبع، تصویر کانتینر، دستور — با یک اجرای موفق قبلی یکسان است. CI مربوط به zev می‌تواند این را تشخیص دهد و کل مرحله را رد کند و در عوض نتیجه قبلی را ارائه دهد. در یک آزمایش واقعی و اندازه‌گیری‌شده، این کار اجرای مرحله را از ۰.۵۳ ثانیه (یک اجرای واقعی) به ۰.۰۱ ثانیه (ارائه‌شده از کش) برای یک مرحله بدون تغییر کاهش داد.
## تاریخچه یک مدل بیش از کامیت‌های آن است
تاریخچه واقعی یک مدل یادگیری ماشین شامل دیتاستی است که روی آن آموزش دیده، تقسیم‌بندی بخش‌هایی که استفاده کرده، هر آزمایشی که معماری آن را شکل داده، و هر ادغام چک‌پوینتی که آن را با یک اجرای دیگر ترکیب کرده است. zev همه این‌ها را به‌عنوان داده درجه‌یک و آدرس‌دهی‌شده بر اساس محتوا ردیابی می‌کند: `zev dataset` و `zev lineage` برای شجره‌نامه، `zev experiment` برای فرضیه‌ها و نتایج، `zev drift` و `zev threshold` برای تشخیص خودکار رگرسیون‌ها، و `zev merge-weights` برای ترکیب چک‌پوینت‌ها با استراتژی‌های واقعی سطح تنسور (میانگین‌گیری، درون‌یابی وزن‌دار، SLERP، TIES-merging) — نه فقط ادغام فایل‌های متنی که به‌طور تصادفی عدد دارند.
## ساخته‌شده برای رشد به فراتر از کنترل نسخه
مدل شیء zev، آدرس‌دهی بر اساس محتوا و گراف شجره‌نامه مبتنی بر IPLD به‌عنوان یک پایه همه‌منظوره طراحی شدند، نه یک مجموعه ویژگی ثابت. `zev context` از قبل ردیابی می‌کند کدام تغییرات از یک انسان آمده و کدام از یک مدل هوش مصنوعی، با چه پرامپتی؛ `zev notarize` نتایج را روی زنجیره بلوکی لنگر می‌اندازد؛ `zev fedmerge` کار را به‌صورت همتا-به-همتا بدون هیچ سرور مرکزی ادغام می‌کند. هرکدام از این‌ها روی همان موتوری اضافه شده که اولین کامیت شما را ذخیره می‌کند — هدف این است که این الگو ادامه یابد، به‌عنوان موتوری برای کد، داده و کار مبتنی بر هوش مصنوعی به‌طور کلی، نه یک سیستم کنترل نسخه با افزودنی‌ها.