Как обновлять базу знаний RAG без поломки активной версии

Не обновляйте активную коллекцию «на месте»

Если pipeline удалил старые chunks, а сервис embeddings упал на середине новых, активная база останется неполной. Пользователь не увидит техническую ошибку — он просто получит уверенное «информации нет».

Безопаснее создавать новую версию:

1. зафиксировать manifest источников;
2. скачать и проверить документы;
3. нормализовать и разбить текст;
4. построить embeddings в staging collection;
5. проверить количество объектов и контрольные запросы;
6. атомарно переключить alias активной версии;
7. сохранить предыдущую версию для rollback.

Пока новый индекс не прошёл gate, пользователи продолжают работать со старым.

Manifest делает обновление объяснимым

Для каждого источника полезно хранить:

• ID и canonical URL;
• checksum содержимого;
• версию или дату действия;
• владельца;
• ACL и класс данных;
• parser/chunking version;
• embedding model version;
• время успешной индексации.

Тогда можно ответить, почему документ попал в конкретную сборку, и переобработать только изменившиеся источники. Один и тот же manifest должен давать тот же набор объектов — это основа идемпотентности.

Какие проверки нужны до переключения

Полнота. Количество документов и chunks соответствует manifest; обязательные источники присутствуют.

Парсинг. Нет пустых документов, поломанных таблиц и страниц, состоящих из меню или повторяющихся заголовков.

Retrieval probes. Для небольшого набора известных вопросов нужные фрагменты попадают в top-k.

Права. Роли видят только разрешённые маркеры.

Актуальность. Отозванный документ отсутствует, новый имеет правильный статус и дату.

Совместимость. Приложение понимает схему метаданных новой версии.

Один успешный запрос «что такое компания» ничего не проверяет. Probe-набор должен содержать важные, редкие и проблемные документы.

Переключение должно быть атомарным

Приложение читает логическое имя вроде knowledge_active, а не жёсткий ID коллекции. После всех проверок alias одним действием указывает на новую версию. Новые запросы идут туда; начатые запросы завершаются на прежней.

Если поиск, citations или permission tests деградировали, alias возвращается назад. Rollback не должен требовать повторной индексации — иначе это не быстрый откат.

В одном из наших RAG-проектов активная версия переключается только после проверки количества points и probe search. Сбой MinIO, embeddings, PostgreSQL или Qdrant оставляет предыдущую версию активной. Это не «сложная AI-магия», а нормальная транзакционная дисциплина вокруг нескольких нетранзакционных систем.

Очередь индексации должна переживать рестарт

Большой импорт редко заканчивается за один HTTP-запрос. Нужна durable queue с lease, подтверждением выполнения и возвратом зависшей задачи. Повторная обработка не должна создавать дубли — каждый документ и chunk имеют стабильный ключ версии.

Отдельные liveness и readiness помогают не направлять трафик в процесс, который запущен, но ещё не может обращаться к индексу или базе. Это особенно важно во время обновления зависимостей.

Удаление важнее добавления

Команды хорошо тестируют появление нового документа и хуже — исчезновение старого. Но отозванная инструкция или право доступа создают больший риск.

Для удаления нужны tombstone или manifest diff, проверка отсутствия chunks во всех активных слоях, очистка кеша и тест по уникальному маркеру удалённого источника. Старые версии индекса можно хранить для rollback ограниченное время, но доступ к ним должен оставаться закрытым.

Не меняйте всё одновременно

Новая модель embeddings, другой chunk size, reranker и новый prompt в одной версии не позволят понять причину улучшения или деградации. По возможности меняйте один слой и сравнивайте на том же наборе. Если миграция вынужденно комплексная, сохраните обе версии и проведите shadow или A/B-проверку без смешивания пользовательских ответов.

Что показывать владельцу базы

Технического «успешно» мало. Нужен понятный отчёт:

• какие источники добавлены, изменены и удалены;
• какие не обработались и почему;
• какая версия активна;
• когда была последняя успешная сборка;
• какие контрольные вопросы прошли;
• можно ли откатить;
• кто подтвердил публикацию.

Так база знаний перестаёт быть чёрным ящиком команды AI и становится управляемым корпоративным ресурсом.

Release checklist версии RAG

• Новый индекс собран отдельно от активного.
• Manifest, схемы и версии моделей сохранены.
• Проверены полнота, retrieval, citations и ACL.
• Переключение alias атомарно.
• Предыдущая версия доступна для быстрого rollback.
• Повторы pipeline идемпотентны.
• Сбой любой зависимости не портит активную версию.
• Удаление и отзыв прав проверены так же, как добавление.

Если база обновляется часто, этот pipeline ценнее ещё одной настройки промпта. Пользователь простит чуть сухой ответ. Ответ по отменённому документу — вряд ли.