Обновление базы знаний: как часто переиндексировать

RAG отвечает по тому, что уже попало в индекс. Изменения в документах, конфигах и runbook'ах появятся в ответах только после переиндексации. Как часто её запускать — зависит от того, как часто меняются источники и насколько критична свежесть для пользователей.

В Adminica векторный слой обновляют после загрузки или правки материалов в библиотеке. После смены модели эмбеддингов нужна полная переиндексация — иначе старые векторы не совпадут с новой моделью.

Когда переиндексировать

• По событию (рекомендуется для активной документации) — при пуше в репозиторий с документацией, при обновлении страниц Confluence/Notion или при загрузке новых файлов. Вебхук или шаг в CI запускает переиндексацию изменённого раздела или полную. Задержка между правкой документа и появлением в чате — минуты.
• По расписанию — если источники обновляются не по событиям (например, выгрузки из внешних систем), достаточно крона раз в день или раз в неделю. Частота зависит от того, как быстро устаревают данные: для регламентов раз в неделю может хватать, для операционных справочников — чаще.
• Вручную — после массового обновления документов или при первичной настройке. Для регулярной актуализации лучше автоматизировать.

Полная переиндексация vs инкремент

Полная переиндексация пересчитывает все документы и обновляет векторную БД с нуля. Надёжно, но дольше и ресурсоёмко при большой базе. Инкрементальное обновление добавляет и обновляет только изменившиеся документы; быстрее, но требует поддержки со стороны пайплайна (версионирование, дельта). Для многих проектов на старте достаточно полной переиндексации по расписанию или по триггеру; при росте базы имеет смысл внедрить инкремент.

Связка с CI/CD и документацией

Документация рядом с кодом (README, runbook в репозитории) позволяет запускать переиндексацию из того же пайплайна: сборка артефактов → загрузка в хранилище RAG → вызов reindex. Так версия документации и версия индекса совпадают с деплоем. Подробнее про актуализацию инструкций — в статье про CI/CD и документацию.

Итог: Частота переиндексации должна соответствовать частоте изменений источников. Оптимально — по событию (CI, вебхук); при отсутствии событий — по расписанию. Связка с CI/CD держит базу знаний в актуальном состоянии без ручного вмешательства.