Бэкап RAG-помощника: что спасать в S3, PostgreSQL и Qdrant, а что пересобрать

⚡ Главное за 5 секунд

• Михаил Витко из Рег.облака разобрал, что бэкапить в RAG-помощнике: S3, PostgreSQL и Qdrant в Kubernetes.
• Единица восстановления — согласованный набор: версии документов, метаданные, индекс, версии кода и моделей.
• Сбой бывает тихим: сервис жив и отвечает, но по старому индексу — «14 дней» вместо «30».

🔍 Что случилось

В блоге компании Рунити на Хабре вышла первая часть материала Михаила Витко, менеджера PaaS-продуктов Рег.облака, о резервном копировании ИИ-помощника по корпоративным документам. Разбор идёт на конкретной архитектуре: исходники в S3, DBaaS PostgreSQL хранит версии документов, прикладные права и историю диалогов, API и обработчики работают в KaaS. Qdrant команда разворачивает сама — как StatefulSet с PVC и Persistent Volume в том же Kubernetes. Ответы генерирует внешняя LLM по API, эмбеддинги считает отдельная модель.

Механика RAG расписана по шагам: при загрузке документа обработчик кладёт исходный файл, выдёргивает текст, режет на фрагменты и считает эмбеддинги. На вопрос приложение находит разрешённые пользователю фрагменты и отдаёт их языковой модели. Компоненты обновляются независимо, и здесь корень проблемы: файл уже в S3, а векторы ещё не все; база знает новую редакцию регламента, а индекс — предыдущую. Автор приводит живой пример: после восстановления помощник отвечает про возврат товара «14 дней» вместо «30». Проверка доступности такой разрыв не ловит.

Дальше — инвентаризация. Эмбеддинги и индекс — разные уровни: сохранённые векторы дают пересобрать поисковую структуру без обращения к модели, а если остались только PDF, придётся заново извлекать текст, резать и векторизовать. Модель провайдера скопировать обычно нельзя, поэтому сохраняют идентификатор модели, параметры запросов, промпты и тесты. Историю диалогов резервируют с устойчивыми conversation_id, message_id, порядком сообщений и ролями.

🧠 Наш разбор

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

Второй момент — деньги и время. Полная перевекторизация корпуса стоит денег на эмбеддингах и часов простоя, хранение векторов обходится дешевле. Мы считаем, спор не про «бэкапить или не бэкапить», а про то, что команда готова пересобрать, а что обязана хранить.

Кто выигрывает: те, у кого документы и индекс версионируются вместе. Проигрывают те, кто считает Qdrant «внутренним делом приложения» и не проверяет согласованность после восстановления. Отдельная засада — версия внешней модели: провайдер её уберёт, и даже полный бэкап не вернёт прежнее поведение.

⚠️ Чего мы не знаем

В поводе нет цифр: ни объёмов корпуса, ни RPO/RTO, ни сравнения стоимости хранения векторов и пересборки. Вторая часть — про восстановление и проверку — ещё не вышла, так что рецепт согласованного отката мы не видели. И это блог вендора: архитектура привязана к его же сервисам, а Qdrant в примере — зона ответственности команды приложения, а не облака.