Бэкап ИИ-приложения по частям подводит: помощник называет 14 дней вместо 30

Автор разбора Михаил Витко, менеджер PaaS-продуктов Рег.облака (платформенных сервисов, где облако берёт на себя инфраструктуру), приводит пример. После сбоя помощник называет срок возврата товара 14 дней вместо 30. База данных знает о новой редакции регламента, а поиск работает по старому индексу. Ниже план: что сохранять, что можно пересоздать и как выбрать между копией и пересборкой.

Что понадобится для бэкапа?

• Схема приложения: где лежат файлы, тексты, векторы, история диалогов.
• Доступ к хранилищам. В примере Рег.облака это S3 (облачное хранилище файлов), DBaaS PostgreSQL (управляемая база данных) и KaaS, то есть Kubernetes как услуга (платформа, где запускаются программы приложения).
• Отдельная резервная площадка со своими доступами, вне основной.
• Время на тест: замер скорости пересборки и передачи копии на вашей площадке.

Пошаговая инструкция: от описи до выбора способа восстановления

1. Опишите состав приложения. Схема помощника называется RAG (retrieval-augmented generation): программа находит нужные фрагменты документов и передаёт их языковой модели вместе с вопросом. В примере исходники хранятся в S3, PostgreSQL держит версии документов, права и историю диалогов. Qdrant, хранилище векторов, команда разворачивает сама в том же Kubernetes и сама отвечает за его снимки.
2. Проведите инвентаризацию. Для каждого компонента ответьте: есть ли независимый источник, из которого его можно восстановить.
3. Сохраните эмбеддинги отдельно от индекса. Эмбеддинги, это числовые «отпечатки» смысла текста. Сохранённые векторы позволяют заново построить поиск без обращения к модели. Если остались только PDF, придётся снова извлекать текст, делить его на фрагменты и считать векторы.
4. Зафиксируйте модель эмбеддингов. Сохраните саму модель или гарантируйте доступ к точной версии. Новая модель с той же размерностью может создавать другое пространство, и старые векторы перестанут сочетаться с новыми запросами.
5. Для внешней LLM (большой языковой модели) сохраните настройки. Модель провайдера скопировать обычно нельзя. Храните идентификатор модели, параметры запросов, промпты и тесты, а также заранее проверенную замену.
6. Резервируйте диалоги с устойчивыми идентификаторами. При восстановлении сравнивайте сами сообщения и их порядок, а не число строк. Сообщения после точки копии пропадут, если их не сохранил WAL (журнал изменений PostgreSQL) или отдельный журнал.
7. Защитите действия ИИ-агента. Ключ операции сохраняйте до первого обращения во внешнюю систему, после отката он не меняется. Неизвестный статус переводите в ручную сверку, а не повторяйте действие автоматически.
8. Вынесите резерв за пределы основной площадки. При потере рабочего контура должны остаться копии, код, образы, ключи расшифрования и сервис политик доступа. Доступность внешней LLM проверяется отдельно.

Опись согласованной копии удобно вести шаблоном:

Точка копии: дата и время
Документы: версии и метаданные
Индекс: снимок Qdrant
Эмбеддинги: точная версия модели
LLM: идентификатор модели, параметры, промпты, тесты
Код: версия приложения и образов
Диалоги: журнал после точки копии

Правило из разбора: пересобирать можно, если проверенное время вместе с подготовкой и проверкой укладывается в RTO, то есть допустимое время простоя. Для переписки Витко советует задать свой RPO, допустимый объём потерянных данных. Как восстановить приложение без рассогласования, автор обещает разобрать во второй части.

Что делать с этим прямо сейчас, по ролям?

Автору и эксперту, который собрал бота по своим материалам: храните исходники, промпты и название модели в одном месте. Без них после сбоя бот начнёт отвечать иначе.

Маркетологу: если ассистент отвечает клиентам про цены и сроки, добавьте в проверку после восстановления контрольные вопросы с известными ответами. Пример про 14 и 30 дней показывает, зачем это нужно.

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

Начните с описи: перечислите, что хранит ваше приложение и откуда каждую часть можно вернуть. Эта таблица на одну страницу сэкономит часы простоя.