Data and model versioning

Git for code, DVC for large data and model files, validation before training, and a frozen evaluation set, so any model can be traced back to the exact data that made it.

DVC (Data Version Control)

Also called data versioning, dvc add, dvc push, DVC remote

What: An open source command-line tool that versions large files next to Git. It stores the data in a cache and a remote such as S3, Google Cloud Storage, Azure or SSH, and commits small .dvc pointer files to Git instead.
Why: Checking out an old commit then brings back the exact data it used, so experiments stay reproducible without putting gigabytes into Git.

Shell

dvc init
dvc add data/raw/transactions.parquet
git add data/raw/transactions.parquet.dvc .gitignore
dvc remote add -d storage s3://my-bucket/dvc
dvc push
git commit -m "Track raw data v1"

Watch out

Committing the .dvc file but forgetting dvc push, so teammates get a pointer to data that is not there.

DVC pipelines

Also called dvc.yaml, dvc repro, stages

What: Stages declared in dvc.yaml, each with a command, its dependencies and its outputs. dvc repro reruns only the stages whose inputs changed, and dvc.lock records the exact hashes used.
Why: It turns "run these scripts in this order" into a reproducible graph, and the lock file proves which data and code produced a model.

YAML

stages:
  featurise:
    cmd: python -m churn.features data/raw data/features
    deps: [data/raw, src/churn/features.py]
    outs: [data/features]
  train:
    cmd: python -m churn.train --data data/features
    deps: [data/features, src/churn/train.py]
    params: [train.seed, train.max_depth]
    outs: [artefacts/model.joblib]
    metrics: [metrics.json]

Data validation

Also called data contracts, schema checks, data quality tests, Great Expectations, pandera

What: Automatic checks on data before it is used: expected columns and types, value ranges, share of missing values, uniqueness of keys and row counts within a band. Libraries such as Great Expectations, pandera or Evidently tests express them as code.
Why: A renamed column or a unit change upstream silently ruins a model. Failing the pipeline on bad data is far cheaper than serving bad predictions.

Watch out

Validating only the training data and never the live requests the model receives.

Frozen evaluation set

Also called holdout set, golden set, test set

What: A fixed, versioned set of examples with known correct answers that every candidate model or prompt is scored on, kept separate from training data and changed only deliberately.
Why: Comparing a new model with the current one is only fair on the same examples. It is the basis of every quality gate later in the lifecycle.

Watch out

Letting evaluation examples leak into training data, which makes every new model look better than it is.

Lineage

Also called provenance, model lineage

What: The recorded chain from a prediction back to the model version, the training run, the code commit, the parameters and the data version that produced it.
Why: When predictions go wrong, lineage answers "what changed?" in minutes, and it is what auditors and regulators ask for in finance and health.
Example: A support ticket shows a bad score; the log has model version 7, whose run records commit a1b2c3 and DVC data hash 9f8e, so you can rebuild the exact model.

Versioning documents and indexes

Also called RAG data versioning, embedding index version, vector index

What: Treating the document snapshot, the chunking settings, the embedding model and the resulting vector index as one versioned artefact for a retrieval-augmented app, so an answer can be traced to the index that fed it.
Why: Changing the embedding model or chunk size changes answers as much as changing the prompt. Without versions you cannot compare or roll back.

Watch out

Re-embedding part of the corpus with a new embedding model, so vectors from two models sit in one index and retrieval quietly degrades.

Go deeper