Как обновлять базу знаний для RAG

Когда базу знаний для RAG пора обновлять

Обновление базы знаний — это не разовое действие, а регулярный процесс. RAG работает хорошо ровно до тех пор, пока хранящиеся в индексе куски документов совпадают с текущим состоянием ваших данных. Как только информация в базе перестаёт отражать реальность, ассистент начинает давать устаревшие, а иногда и противоречащие друг другу ответы. Поэтому важно заранее определить, какие события должны запускать обновление.

Типичные сигналы к обновлению базы знаний для RAG: появились новые документы, регламенты или прайсы; изменились правила бизнеса, которые уже вошли в текст; обнаружена ошибка в существующем документе; пользователи через форму обратной связи указали на неточный или устаревший ответ; изменился сам сценарий использования — например, ассистент вместо техподдержки начал отвечать и по внутренним регламентам. Признак проблемного индекса прост: ассистент уверенно цитирует то, чего уже нет в актуальной версии документа, или не находит информацию, которая точно есть.

Практичное правило: выстраивайте политику обновления не по календарю, а по событиям. Есть данные, критичные для правильности ответа (цены, параметры, нормативы) — они должны пережигать индекс при каждом изменении. Есть справочные материалы, где допустимо обновление раз в неделю или месяц. Разделите базу на слои по частоте изменения — это сильно упростит жизненный цикл базы знаний.

Переквалификация документов: чанкинг

Чанкинг — это разбиение документа на фрагменты (куски, «чанки»), которые попадают в индекс и по которым ассистент ищет ответ. Важно понимать: изменение текста документа не отражается в базе автоматически. До тех пор пока документ не переквалифицирован, старые куски продолжают лежать в индексе. Поэтому первое правило обновления — при любой заметной правке исходного документа выполняйте его переквалификацию, а не точечную правку старых кусков.

Размер куска и способ его нарезки напрямую влияют на качество ответа. Слишком мелкие куски теряют контекст: модель получает обрывок и не понимает, о чём речь. Слишком крупные — размазывают смысл и уводят поиск в менее релевантные фрагменты. Ориентир большинства решений — куски в районе 300–800 токенов, но оптимальный размер подбирается под конкретный домен и модель эмбеддингов. Стоит тестировать несколько вариантов настраиваемого перекрытия кусков, чтобы соседние фрагменты не теряли связность.

Правильная стратегия переквалификации — версионировать не только документ, но и сам алгоритм чанкинга. Если вы изменили правила нарезки (например, перешли с наивной нарезки по абзацам на структурную по заголовкам), старые куски физически несовместимы с новыми. В этом случае нельзя просто добавить новые фрагменты поверх старых — нужна полная переквалификация слоя документа, чтобы в индексе не лежали фрагменты с разной логикой нарезки про один и тот же материал.

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

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

Самый простой и предсказуемый способ бесшовного обновления — это два индекса. Вы готовите второй, обновлённый индекс в фоне, заполняете его полностью и только потом переключаете запросы на него. Пока идёт подготовка, первый индекс продолжает обслуживать пользователей. Переключение мгновенно, откат — тоже. Издержка в том, что вам нужно хранить две копии векторов, но для большинства бизнес-баз это приемлемая цена за надёжность.

Более экономный вариант — инкрементальное обновление прямо в рабочем индексе. Добавление новых кусков: переквалифицируете только новые документы и добавляете их эмбеддинги. Изменение: старые куски документа удаляете по его идентификатору, а новые добавляете. Удаление: убираете куски по идентификатору документа или по фильтру источника. Ключевое условие — у каждого куска есть стабильный идентификатор, привязанный к документу, чтобы вы могли точечно заменить именно испорченный фрагмент, а не весь контент.

Идентификаторы кусков как основа обновления

Без стабильной схемы идентификации обновлять индекс руками становится невозможно. Рекомендую хранить в метаданных каждого куска: идентификатор документа (например, артикул или хэш исходника), номер версии документа и сам текст чанка. Когда вносится правка, вы находите все куски по идентификатору и переписываете их целиком. Это гарантирует, что в индексе не останется гибридов — фрагментов, собранных из старой и новой версий одного абзаца.

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

Актуальность ответа напрямую связана с тем, на какую версию документа ссылается ассистент. Если в базе лежат куски из трёх версий одного регламента, модель будет честно цитировать то, что уже отменено. Поэтому в метаданных куска должна быть не только дата, но и явный признак версии и актуальности — например, флаг «действующий» или «устаревший».

Практическая схема: каждый документ имеет канонический идентификатор и набор версий. Актуальная версия помечается как действующая, предыдущие — как архивные. Поиск по умолчанию ограничивается только действующими кусками, а для внутренней аналитики архивные версии можно держать отдельно. Такой подход убирает главную причину противоречивых ответов — случайную выдачу устаревших фрагментов как актуальных.

Не забывайте про юридическую и договорную сторону. Если ассистент консультирует по условиям договора или политике, важно понимать период действия каждой версии. Храните историю версий и связывайте ответы с конкретной версией источника. Тогда даже если обнаруженная ошибка требует отката, вы можете восстановить версию, которая была актуальна на момент вопроса.

Контроль актуальности ответов и связь с источниками

Обновить индекс недостаточно — нужно проверить, что ответы стали правильными. Без контроля обновление базы знаний для RAG превращается в оптимизм на бумаге. Настройте проверку на двух уровнях: тестовая выборка вопросов и мониторинг боевых ответов.

Тестовый корпус: соберите 100–200 типовых вопросов, которые реально задают пользователи, с ожидаемыми ответами. Перед каждым обновлением прогоняйте его по изменённой базе и сравнивайте, не появились ли регрессии. Так вы быстро поймёте, не сломало ли изменение структуры чанков уже работавшие сценарии. Автоматическая оценка через LLM по эталонному ответу ускорит работу на больших корпусах, но не заменяет выборочную ручную проверку.

Мониторинг боевых ответов: собирайте метрику, нашёл ли ассистент релевантный источник, и как пользователи оценивают ответ — лайк или дизлайк. Резкий рост числа ответов «нет данных» или негатива после обновления — сигнал немедленно откатываться. И главное — всегда связывайте ответы с источниками. Когда ассистент показывает, на какой документ и какого числа он опирался, пользователь и команда сразу видят, что данные актуальны, и легче находить недостающие обновления.

Как настроить регулярное обновление: пошагово

Соберём процесс в повторяемый регламент, который можно передать команде. Он не требует пересборки системы каждый раз — при грамотной настройке это рутинная операция.

1. Опишите источники истины. Определите, какие документы являются каноническими (база стандартов, CRM-справочники, регламенты) и кто отвечает за их актуальность.
2. Настройте обнаружение изменений. Подключите импорт из исходных систем либо ручной механизм пометки «документ изменился». Отслеживайте даты изменения и хэши файлов.
3. Автоматизируйте переквалификацию изменённых документов. Скрипт берёт изменённые исходники, пересобирает их куски и обновляет индекс по идентификаторам.
4. Добавьте версии и флаги актуальности. У каждого куска — документ, версия, статус «действующий» или «архивный».
5. Прогоняйте тестовый корпус. Перед публикацией обновления проверяйте регрессии на типовых вопросах.
6. Контролируйте боевые ответы. Смотрите на метрики находки источника и отзывы пользователей; при проблеме — откат на предыдущий индекс.

Такой процесс делает обновление предсказуемым: каждый раз вы знаете, что изменилось, как прошла проверка и что можно откатить в случае проблемы. Отдельно зафиксируйте, кто выполняет обновление и кто утверждает изменения критичных документов, — это снижает риск случайной ошибки.

Типичные ориентиры для отрасли: у многих команд качество ответов заметно падает, если база не обновлялась более 1–2 месяцев, а доля устаревших ответов в таких системах порой поднимается до трети всех выдач. Точные цифры зависят от сферы и частоты изменения данных — это ориентиры, а не гарантированные результаты.

Частые вопросы

Как часто нужно обновлять базу знаний для RAG? Зависит от сферы. Критичные данные (цены, нормативы, регламенты) обновляйте при каждом изменении, справочные — реже. Организуйте базу по слоям и задайте политику для каждого слоя — это практичнее, чем опираться на единый график.

Можно ли обновлять базу без остановки ассистента? Да. Используйте инкрементальные правки по идентификаторам кусков либо схему из двух индексов и переключайте запросы мгновенно. Пауза в обслуживании при обновлении не нужна.

Что делать, если после обновления ответы стали хуже? Проведите сравнение на тестовом корпусе и откатитесь на предыдущий индекс либо проверьте, не сломалась ли логика чанкинга и не остались ли в индексе устаревшие версии без флага актуальности.