zev が存在する理由

zev は、特定の問いに直接答えるために存在します。大きなファイルやモデルは実際にどう保存・同期されるべきか、構造的に変化したコードについて差分は何を伝えるべきか、なぜ CI はすでに行った作業をこれほど頻繁にやり直すのか、そして生データからすべての実験を経て公開された結果まで、モデルの系譜全体をどう追跡するか — これらすべてを、コンテンツハッシュで一貫してアドレス指定される一つのエンジンの中で。 ## 大きなファイルは同期の経済性を変える すべてのファイルを不透明な blob として扱うと、大きなファイル内のたった1バイトの変更でも、そのファイル全体の再転送が必要になります。ソースコードではこれが問題になることはめったにありません — ほとんどの編集は小さく、ファイル自体も小さいからです。しかし、大きなテキスト、データ、モデルファイルでは、これはすぐにコストがかさみます。 zev のコンテンツ定義チャンク分割は、これに直接対処します。ファイルがチャンク分割されている場合、1.7 MB のファイルの先頭付近での編集は、実データで測定した結果、ファイルの全チャンクのうち約1%のみの再転送で済むことがわかりました — 残りはすでに両側に存在しており、push でも pull でも完全にスキップされます。 ## テキスト差分は実際に何が変わったかを教えてくれない 行ベースの差分は、どの行が変わったかを示します。しかし、ある関数が削除されて別の関数が追加されたのではなく、リネームされたということや、関数の本体は同一のままシグネチャだけが変わったということは教えてくれません。差分を読む人間はしばしばこれを推測できますが、自動化されたツールは確実にはできません。 zev のセマンティック差分は、Zig ソースコードを実際の AST パーサーで解析し、構造的な変更を直接報告します: `signature_changed`、`body_changed`、`likely_rename`、`added`、`removed` — これらはテキストパターンからの推測ではなく、実際に解析されたコードの構造から計算されます。 ## CI の時間の大半は変化のない作業に費やされる ほとんどの CI 実行は、入力 — 正確なソース内容、コンテナイメージ、コマンド — が以前の成功した実行と同一であるステップを再実行しています。zev の CI はこれを検出してステップ全体をスキップし、Docker を再実行する代わりに以前の結果を返すことができます。実際に測定したテストでは、これによって変化のないステップの実行時間が 0.53 秒(実際の実行)から 0.01 秒(キャッシュからの提供)に短縮されました。 ## モデルの履歴はコミットだけではない 機械学習モデルの本当の履歴には、学習に使われたデータセット、使用されたシャード分割、モデルのアーキテクチャを形作ったすべての実験、そして別の実行と組み合わせたすべてのチェックポイントのマージが含まれます。zev はこれらすべてを、ファーストクラスのコンテンツアドレス指定データとして追跡します: 系譜のための `zev dataset` と `zev lineage`、仮説と結果のための `zev experiment`、回帰を自動的に検出する `zev drift` と `zev threshold`、そしてテンソルレベルの実際の戦略(平均化、重み付き補間、SLERP、TIES-merging)でチェックポイントを組み合わせる `zev merge-weights` — たまたま数値を含むテキストファイルを単にマージするのではありません。 ## バージョン管理を超えて成長するために構築されている zev のオブジェクトモデル、コンテンツアドレス指定、IPLD ベースの系譜グラフは、固定された機能セットではなく、汎用的な基盤として設計されました。`zev context` はすでに、どの変更が人間によるもので、どの変更がどのようなプロンプトを伴う AI モデルによるものかを追跡しています。`zev notarize` は結果をチェーン上に固定します。`zev fedmerge` は中央サーバーなしでピアツーピアに作業をマージします。これらはいずれも、最初のコミットを保存するのと同じエンジンの上に追加されました — この意図は、コードとデータ、そして AI 主導の作業全般のためのエンジンとして、このパターンが今後も続いていくことにあります。付加機能付きのバージョン管理システムとしてではなく。