Что такое data version control (DVC) для RAG корпуса документов?

Краткий тезис

Data Version Control (DVC) — это система управления версиями данных и ML-моделей, работающая поверх Git. Для RAG-корпуса DVC позволяет версионировать не только код индексации и retrieval, но и сами документы, чанки, эмбеддинги и метаданные. Это даёт возможность откатывать retrieval к конкретной версии корпуса, воспроизводить эксперименты и работать в команде, не захламляя Git-репозиторий большими файлами.

1. Проблема: версионирование данных в RAG

В RAG-системе корпус документов постоянно меняется:

• добавляются новые документы,
• меняются правила chunking,
• обновляются эмбеддинги.

Git не предназначен для хранения больших бинарных файлов (чанков, векторов). Без версионирования:

• невозможно откатиться к старой версии индекса,
• сложно воспроизвести конкретный эксперимент,
• команда не может синхронизироваться по данным.

Data Version Control (DVC) решает эту задачу, сохраняя большие файлы в удалённом хранилище (S3, GCS, MinIO), а в Git — только метаданные (хэши, пути, версии).

2. Как работает DVC (общее описание)

DVC — это open-source инструмент, который:

• заменяет большие файлы в репозитории на dvc-файлы — текстовые файлы, содержащие хэш и URL удалённого хранилища.
• добавляет команды для push/pull данных.
• позволяет описывать пайплайны (dvc.yaml) с этапами и зависимостями.

Ключевые понятия

• DVC-файл (.dvc) — метафайл, хранящий ссылку на файл в remote.
• Кэш DVC — локальная папка .dvc/cache, где хранятся файлы по хэшу.
• Remote — удалённое хранилище (S3, GCS, Azure Blob, SSH и т.д.).
• dvc.yaml — описание пайплайна: команды, входы, выходы.

Типичный workflow

dvc init
dvc add data/documents.parquet
git add data/documents.parquet.dvc .gitignore
git commit -m "добавил версию 1 корпуса"
dvc push

После этого большой файл documents.parquet не попадает в Git, а его версия управляется через .dvc-файл.

3. Применение DVC для RAG корпуса

В контексте RAG версионировать нужно не только сырые документы, но и:

• чанки (chunks), полученные после разбиения;
• эмбеддинги (embedding vectors), рассчитанные моделью;
• индекс (например, FAISS-индекс);
• конфигурацию (параметры chunking, выбранная модель эмбеддинга).

Пример структуры репозитория

my-rag-project/
├── data/
│   ├── raw/                # сырые PDF, txt, html
│   ├── chunks.parquet      # чанки (DVC)
│   └── index.faiss         # FAISS-индекс (DVC)
├── src/
│   ├── chunk_and_embed.py
│   └── build_index.py
├── .dvc/
├── dvc.yaml
├── params.yaml             # параметры chunking
└── ...

Пайплайн в dvc.yaml

stages:
  chunk_and_embed:
    cmd: python src/chunk_and_embed.py
    deps:
      - data/raw
    params:
      - chunk_size
      - chunk_overlap
      - embedding_model
    outs:
      - data/chunks.parquet
      - data/embeddings.parquet
  build_index:
    cmd: python src/build_index.py
    deps:
      - data/embeddings.parquet
    outs:
      - data/index.faiss

Теперь при изменении параметров chunking DVC пересоберёт только зависимые этапы и сохранит новую версию данных.

4. Версионирование retrieval через Git-теги

Ключевая идея: метка (git tag) фиксирует состояние всего проекта — и кода, и данных.

Workflow для RAG

1. Подготовили корпус версии v1.0.
2. Выполнили dvc commit и dvc push.
3. Создали тег: git tag -a v1.0 -m "корпус: chunk_size=500, model=bge-large-en".
4. Позже изменили chunking на 300 токенов, обновили данные.
5. Создали тег v2.0.

Откат retrieval

git checkout v1.0
dvc checkout

После этих команд в рабочей папке появятся именно те чанки и эмбеддинги, которые соответствуют версии v1.0. Теперь можно запустить retrieval и генерацию — результат будет строго воспроизводим.

Почему это важно в Agentic RAG? Агенты могут выполнять несколько шагов retrieval. Если корпус изменился, поведение агента может стать непредсказуемым. DVC гарантирует, что при фиксированном теге retrieval всегда одинаков.

5. Преимущества DVC для RAG корпуса

6. Альтернативы DVC

Для командных RAG-проектов DVC — практически стандарт.

7. Интеграция DVC в CI/CD

Пример GitHub Actions workflow:

name: Build and version RAG corpus
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          lfs: false
      - name: Setup DVC
        run: pip install dvc[s3]
      - name: Pull data from S3
        run: dvc pull
      - name: Run pipeline
        run: dvc repro
      - name: Push new data
        run: dvc push
      - name: Commit dvc.lock
        run: |
          git config user.name "ci-bot"
          git add dvc.lock
          git commit -m "Update data pipeline"

После каждого изменения кода или параметров CI автоматически пересобирает корпус, версионирует новую версию и пушит данные в S3.

8. Пример workflow: от сырых PDF до FAISS-индекса с DVC

1. Инициализация

   mkdir rag-corpus && cd rag-corpus
   git init
   dvc init
   dvc remote add -d myremote s3://my-bucket/rag-data
   

2. Добавление сырых документов

   cp /path/to/papers/*.pdf data/raw/
   dvc add data/raw
   git add data/raw.dvc .gitignore
   git commit -m "initial raw documents"
   dvc push
   

3. Первый пайплайн (chunk_size=500):

   • Создаём dvc.yaml с этапом chunk_and_embed.
   • Параметры кладём в params.yaml.
   • Запускаем: dvc repro.
   • Коммитим изменения dvc.lock и params.yaml в Git.
   • Тегируем: git tag v1.0-chunk500.

4. Изменение chunk_size на 300

   • Правим params.yaml.
   • dvc repro — DVC замечает изменение параметра, перезапускает этап.
   • Новые чанки и эмбеддинги попадают в кэш.
   • Коммит + git tag v2.0-chunk300.

5. Откат к v1.0

   git checkout v1.0-chunk500
   dvc checkout
   

   Теперь в папке data/ лежит в точности тот набор чанков и индекс, который был при первой версии.

Пет-проект для закрепления

Задача Реализовать версионированный RAG корпус с помощью DVC на минимальном наборе текстов (3-5 документов) и продемонстрировать откат retrieval.

Инструменты Python, LangChain (TextLoader, RecursiveCharacterTextSplitter), sentence-transformers, FAISS, DVC, Git, локальный remote (папка на диске).

Шаги:

1. Создайте Git-репозиторий и выполните dvc init.
2. Положите несколько TXT-файлов в data/raw/.
3. Напишите скрипт, который:
   • загружает тексты,
   • разбивает на чанки (параметр chunk_size в params.yaml),
   • получает эмбеддинги через sentence-transformers,
   • сохраняет FAISS-индекс в data/index.faiss.
4. Оформите этап в dvc.yaml с зависимостью от data/raw и параметрами.
5. Запустите dvc repro, закоммитьте, поставьте тег v1.
6. Увеличьте chunk_size, снова выполните dvc repro, тег v2.
7. Сделайте git checkout v1 + dvc checkout — убедитесь, что FAISS-индекс изменился (можно сравнить размер файла или загрузить в память).

Ожидаемый результат Репозиторий, в котором по тегам можно восстановить точное состояние корпуса. При git checkout v1 и dvc checkout retrieval вернёт документы, соответствующие старой стратегии chunking.

Связь с другими вопросами

DVC обеспечивает воспроизводимость данных, без которой невозможно надёжное тестирование routing или planning.

Навигация

• Предыдущий: 266
• Следующий: 268
• Индекс: 00. Индекс разборов