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

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

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

1. Термин: Data Version Control (DVC)

DVC — это open-source инструмент, который расширяет Git для работы с большими файлами и датасетами. В отличие от Git LFS, DVC не хранит сами файлы в Git, а только их хеши и ссылки на удалённое хранилище (S3, GCS, Azure Blob, локальная папка). Это позволяет:

• Версионировать датасеты размером в гигабайты и терабайты.
• Воспроизводить эксперименты с точными копиями данных.
• Совместно работать над данными, используя Git-подобный workflow.

Для RAG корпус документов — это набор текстовых файлов (PDF, TXT, Markdown), которые после чанкинга и эмбеддинга превращаются в векторный индекс. DVC позволяет отслеживать обе сущности: сырой корпус и готовый индекс.

2. Как DVC работает: хранение больших файлов, метаданные в Git

DVC не заменяет Git, а работает поверх него. Основные компоненты:

• .dvc файлы — текстовые файлы, которые Git отслеживает. Они содержат хеш (MD5) и путь к удалённому хранилищу.
• Кэш DVC — локальная папка .dvc/cache, где хранятся версионированные файлы.
• Удалённое хранилище (remote) — S3, GCS, SFTP и т.д.

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

my-rag-project/
├── .git/
├── .dvc/
│   ├── cache/
│   └── config
├── data/
│   ├── documents/          # сырой корпус
│   │   ├── doc1.pdf
│   │   └── doc2.txt
│   ├── chunks/             # чанки (опционально)
│   └── index/              # векторный индекс (FAISS, Annoy)
├── documents.dvc           # DVC-файл для папки data/documents
├── index.dvc               # DVC-файл для папки data/index
└── pipeline.dvc            # DVC-пайплайн (опционально)

Команды:

3. Применение DVC к RAG корпусу: версионирование документов и индексов

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

1. Корпус документов (сырые файлы, чанки) — источник знаний.
2. Векторный индекс — результат обработки корпуса (эмбеддинги, структура поиска).

Почему это важно:

• При изменении корпуса (добавление, удаление, обновление документов) индекс становится неактуальным.
• Для отладки или A/B-тестирования нужно иметь возможность вернуться к старой версии корпуса и индекса.
• В команде разработчиков каждый может работать со своей копией данных, не боясь конфликтов.

Типичный workflow:

# 1. Добавляем новый документ
cp new_report.pdf data/documents/
dvc add data/documents
git add data/documents.dvc
git commit -m "add new report v2"

# 2. Пересобираем индекс
python build_index.py --input data/documents --output data/index
dvc add data/index
git add data/index.dvc
git commit -m "rebuild index for v2"
git tag v2.0

# 3. Пушим данные в удалённое хранилище
dvc push

4. Процесс: dvc add, git tag, dvc push, dvc checkout, восстановление

Рассмотрим полный цикл управления версиями.

4.1 Создание снапшота (snapshot)

# После изменений в data/documents
dvc add data/documents          # создаёт/обновляет documents.dvc
git add data/documents.dvc
git commit -m "Update documents: added Q3 report"
git tag v1.0                    # тег для удобного отката
dvc push                        # загружает новые файлы в S3

4.2 Откат к предыдущей версии

# Переключиться на тег v1.0
git checkout v1.0
# Восстановить файлы data/documents из кэша/удалённого хранилища
dvc checkout
# Теперь data/documents соответствует состоянию на момент v1.0

4.3 Восстановление индекса вместе с корпусом

Если индекс тоже под DVC:

git checkout v1.0
dvc checkout
# data/documents и data/index восстановлены синхронно

Важно: DVC не хранит сам индекс в Git, только ссылку. Поэтому dvc checkout скачает нужную версию индекса из кэша или удалённого хранилища.

5. Интеграция с CI/CD: автоматический ребилд индекса

DVC отлично встраивается в пайплайны CI/CD (GitHub Actions, GitLab CI, Jenkins). Пример сценария:

1. Разработчик добавляет новый документ, коммитит .dvc файл и пушит в Git.
2. CI/CD триггер:
   • dvc pull — скачивает актуальные документы.
   • python build_index.py — пересобирает индекс.
   • dvc add data/index — версионирует новый индекс.
   • git add data/index.dvc && git commit -m "auto rebuild index" — коммитит метаданные.
   • dvc push — загружает новый индекс в удалённое хранилище.
3. После успешного билда — деплой новой версии RAG-сервиса.

Преимущество: индекс всегда соответствует корпусу, а история изменений прозрачна.

6. Преимущества DVC для RAG

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

Для RAG-системы DVC — оптимальный выбор благодаря простоте, интеграции с Git и поддержке пайплайнов.

8. Best practices для DVC в RAG

• Храните корпус и индекс отдельно: два разных .dvc файла, чтобы можно было обновлять индекс без изменения корпуса (например, при смене модели эмбеддингов).
• Используйте теги: git tag v1.0, git tag v2.0 для маркировки стабильных версий.
• Не коммитьте .dvc/cache: добавьте .dvc/cache в .gitignore.
• Настройте удалённое хранилище: S3 или GCS с политикой жизненного цикла (например, удалять старые версии через 90 дней).
• Автоматизируйте сборку индекса: используйте dvc run или Makefile, чтобы при изменении корпуса индекс пересобирался одной командой.
• Документируйте версии: в README или CHANGELOG указывайте, какие документы добавлены в каждой версии.

Пример .dvc/config:

[remote "myremote"]
    url = s3://my-bucket/dvc
    region = us-east-1

9. Пример полного цикла с DVC

# Инициализация
git init
dvc init
dvc remote add -d myremote s3://my-rag-data/dvc

# Первая версия корпуса
mkdir -p data/documents
cp initial_docs/*.pdf data/documents/
dvc add data/documents
git add data/documents.dvc
git commit -m "Initial corpus v1"
git tag v1.0
dvc push

# Сборка индекса
python build_index.py --input data/documents --output data/index
dvc add data/index
git add data/index.dvc
git commit -m "Initial index v1"
git tag v1.0-index
dvc push

# Вторая версия: добавляем документы
cp new_doc.pdf data/documents/
dvc add data/documents
git add data/documents.dvc
git commit -m "Add new doc v2"
git tag v2.0
dvc push

# Пересборка индекса
python build_index.py --input data/documents --output data/index
dvc add data/index
git add data/index.dvc
git commit -m "Rebuild index v2"
git tag v2.0-index
dvc push

# Откат к v1
git checkout v1.0
dvc checkout
# Теперь data/documents и data/index (если был закоммичен) соответствуют v1

10. Потенциальные проблемы и их решение

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

Задача: Создать мини-RAG систему с версионированием корпуса через DVC.

Инструменты: Python, DVC, FAISS, sentence-transformers, Git.

Шаги:

1. Инициализируйте Git-репозиторий и DVC.
2. Создайте папку data/documents и добавьте 3-5 текстовых файлов (например, статьи из Википедии).
3. Выполните dvc add data/documents, закоммитьте и поставьте тег v1.0.
4. Напишите скрипт build_index.py, который читает документы, разбивает на чанки, создаёт эмбеддинги и сохраняет FAISS-индекс в data/index.
5. Запустите скрипт, затем dvc add data/index, закоммитьте и поставьте тег v1.0-index.
6. Измените корпус (добавьте/удалите файл), повторите шаги 3-5 с тегом v2.0.
7. Сделайте откат к v1.0: git checkout v1.0 && dvc checkout. Убедитесь, что корпус и индекс вернулись к исходному состоянию.
8. Настройте удалённое хранилище (можно локальную папку) и выполните dvc push / dvc pull.

Ожидаемый результат: Вы сможете переключаться между версиями корпуса и индекса одной командой, а также делиться данными с коллегами через удалённое хранилище.

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

Навигация

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