White-label AI-чат-бот: где ломается мультитенантность
Первый white-label AI-чат-бот почти всегда собирается под одного заказчика: одна база знаний, один ключ к модели, одна очередь обработки. Пока арендатор один, всё работает. Ломается это ровно тогда, когда решение начинают продавать нескольким компаниям, а движок остаётся общим: мультитенантный чат-бот в такой сборке держится на ручных договорённостях.
Самая дорогая поломка — общая база знаний без привязки к арендатору. Поиск по запросу «условия поставки» честно находит ближайшие фрагменты, и среди них оказываются абзацы из документов соседа: цены, реквизиты, служебная переписка. Разделение на уровне PostgreSQL — отдельная схема, обязательный идентификатор арендатора в каждой записи и в каждом запросе — убирает этот класс утечек целиком, а не «делает его маловероятным».
Второй разрыв — тарификация. Расход модели падает в общий счёт: реселлер не может показать клиенту, сколько тот израсходовал, а мы не можем притормозить одного тяжёлого пользователя, не задев остальных. Нужен учёт расхода по каждому арендатору, квоты и предсказуемая деградация при их исчерпании.
Третий — обновления и рост. Переиндексация знаний одного клиента останавливает ответы всем, а пиковая нагрузка одного арендатора тянет за собой задержки всей платформы. Изоляция данных арендаторов, отдельные лимиты и обновление каталога знаний по одному тенанту — та самая инженерная часть, которую на демо не видно, а на десятом клиенте она определяет, масштабируется продукт или нет. Разбираем, как это закрывается.
Что даёт изоляция арендаторов и раздельные расчёты
В white-label AI-чат-боте под одной оболочкой живут десятки заказчиков, и изоляция арендаторов — это не только про сохранность данных. Каждый клиент получает собственное пространство схемы, индекса и хранилища, поэтому ошибка в одном контуре перестаёт быть общей аварией: неудачная переиндексация корпуса или сбой конфигурации больше не выводят из строя всех сразу.
Раздельный учёт расхода строится на идемпотентных счётчиках — вызовы модели, объём обработанных токенов и хранение считаются на каждом запросе и ложатся в журнал по арендатору. Тарификация становится воспроизводимой: цифру видно до последней строки, а ручная работа при закрытии периода сводится к сверке расхождений вместо пересчёта логов вручную.
Подключение нового клиента перестаёт быть отдельным проектом. Профиль арендатора, лимиты, наборы документов и правила выбора источников описываются декларативно, и копия проверенного шаблона разворачивается рядом с работающими контурами, без их остановки и без ручной правки кода.
Отдельно закрыт класс отказов, который дороже всего стоит репутационно: протечка контекста, когда модель отвечает по документам чужого заказчика. Проверки изоляции входят в регрессионный набор и прогоняются при каждом релизе, поэтому доля таких инцидентов не растёт вместе с числом арендаторов.
Нагрузка на поддержку меняет характер: вместо разбора инцидентов с доступами и данными остаются вопросы про расширение лимитов. Это и есть измеримый результат — срок подключения нового клиента сокращается до повторяемой процедуры, ручные операции при тарификации уходят, а отказы из-за чужих данных не воспроизводятся.
Варианты архитектуры: общая база или у каждого своя
Схема разделения клиентов определяет, сколько инженерных часов уходит на подключение нового партнёра и как далеко расходятся данные между арендаторами. Ниже — четыре рабочие конфигурации, которые мы собирали в продакшене, с их реальными ограничениями.
| Схема | Когда подходит | Ограничения |
|---|---|---|
| Общая база с фильтром | Десятки клиентов на типовых сценариях, запуск за считаные дни | Ошибка в правилах доступа открывает чужие документы; общий индекс растёт и замедляет поиск |
| Отдельная база на клиента | Свои документы и права, инфраструктура при этом общая | Нужна автоматика создания базы и её обновлений, иначе подключение упирается в ручную работу |
| Отдельный контур на клиента | Требования регулятора, запрет на соседство данных разных заказчиков | Каждый контур отдельно обновляется, мониторится и резервируется — растёт объём рутинной эксплуатации |
| Гибридная схема | Типовые сценарии общие, чувствительные данные изолированы | Сложнее маршрутизация запросов и версионирование общих шаблонов |
Почему на практике чаще приходят к гибриду
Общий каталог шаблонов и типовых инструкций обновляется один раз и сразу расходится по всем партнёрам, а приватные документы остаются в изолированном пространстве и не покидают контур заказчика. Схему стоит закладывать с запасом: перевод клиента с общей базы на отдельный контур позже — это миграция индекса и повторная проверка прав доступа, а не смена настройки.
Этапы вывода многоклиентского чат-бота в работу
Прежде чем подключать первого арендатора, мы разбираем текущее состояние: какие базы знаний уже есть, в каком виде документы, как устроены каналы обращений и сколько запросов приходит в пике. На этом этапе видно, где проходят границы данных каждого клиента, — именно от них зависит схема разделения и то, как решение будет вести себя при росте числа арендаторов.
От разбора до передачи в эксплуатацию
- Аудит текущего решения. Смотрим источники знаний, форматы файлов, действующие интеграции и объём обращений. Фиксируем, что переносится без изменений, а что придётся перестраивать.
- Схема разделения клиентов. Определяем модель: отдельное пространство данных и поисковый индекс на каждого арендатора, собственные ключи доступа и лимиты. Решение фиксируем в схеме, а не в переписке.
- Настройка маршрутизации запросов. Обращение попадает в контур нужного клиента, подтягивает только его базу знаний и правила ответа. Здесь же задаём очередь и ограничения, чтобы активность одного арендатора не влияла на остальных.
- Проверка изоляции. Прогоняем сценарии, где запрос одного клиента не должен вернуть фрагменты чужой базы — ни в ответе, ни в логах, ни в выгрузках. Отдельно проверяем кэш и общие служебные индексы.
- Учёт и биллинг. Привязываем счётчики к арендатору: число обращений, объём контекста, активные каналы. Реселлер получает отчёт по каждому своему клиенту.
- Передача в эксплуатацию. Отдаём конфигурации, схему разделения, инструкцию по подключению нового арендатора и регламент обновления базы знаний. Дальше — сопровождение, мониторинг и разбор инцидентов.
Комплект передачи: конфигурации, схемы, доступы, регламенты
Комплект передачи — это не архив со скриншотами и парой инструкций, а воспроизводимый набор, по которому ваш инженер поднимет копию white-label AI-чат-бота и повторит релиз без нас. Всё, что собирается в процессе, остаётся у заказчика: конфигурации чат-бота, схема разделения арендаторов, правила доступа, документация и порядок обновлений.
- Конфигурации чат-бота — рабочие файлы промптов, параметров моделей, порогов релевантности и правил отсечения ответов, разложенные по средам, с отдельным набором для каждого арендатора.
- Схема разделения арендаторов — как изолируются данные, ключи, лимиты запросов и биллинг каждого реселлерского аккаунта, что вынесено в общий слой, а что не пересекается.
- Правила доступа — матрица ролей, наборы прав для служебных ключей, порядок выдачи и отзыва, места хранения секретов и порядок их ротации.
- Документация и инструкции — описание интерфейсов, регламент подключения нового арендатора, памятки для поддержки и разбор типовых отказов с точками локализации.
- Регламент обновлений — как выходят изменения конфигураций и кода, порядок миграций базы, тестовый контур перед выкаткой и правило отката на предыдущую сборку.
- Схемы и карты сервисов — диаграммы потоков запросов, зависимостей компонентов и точек интеграции с внешними системами.
- Порядок приёмки — контрольные сценарии, по которым ваша команда проверяет работоспособность после передачи и при последующих обновлениях.
Комплект лежит в вашем репозитории и обновляется вместе с продуктом, а не остаётся снимком на дату сдачи. На следующем релизе мы сверяемся с этим регламентом, а не восстанавливаем логику по памяти — поэтому доработки не превращаются в археологию.
Кейс: как реселлер вырос с одного клиента до сорока
Точка старта: один заказчик и ручная настройка
Первый клиент реселлера жил в отдельном контуре: своя база знаний, свой индекс, инструкции для модели правились вручную под лексику его поддержки. Подключение заняло три недели — почти всё время ушло на разбор формулировок одной компании, а не на техническую часть. На втором заказчике стало видно, что схема не масштабируется: документы разных клиентов лежали в одном индексе, и ответы одного всплывали у другого.
Что переделали
Развели арендаторов: у каждого свой набор документов, своя векторная база и своя инструкция для модели, общим остался только слой маршрутизации запросов. Подключение базы знаний из Notion свели к мастеру настройки — реселлер сам загружает документы, проверяет ответы в тестовом режиме и публикует бота. Учёт потребления привязали к числу диалогов и объёму обработанных документов, а права и доступы разграничили на уровне арендатора, а не приложения целиком.
Метрики до и после
Время подключения клиента сократилось с трёх недель до одного дня, восемь из десяти заказчиков реселлер заводит сам. Доля отказов — ответов без опоры на базу знаний и переводов на оператора — упала с 19% до 4%, потому что качество проверяется на тестовом наборе вопросов до публикации бота. Через два квартала после переделки реселлер ведёт сорок клиентов той же командой из двух человек.
Как перенести существующий чат-бот в многоклиентский режим?
Перенести существующего бота в многоклиентский режим можно без переписывания, если логика диалога уже отделена от хранения данных. Переделывать приходится не ядро, а три места: определение клиента в запросе, изоляцию данных и конфигурацию под каждого заказчика. Сценарии, интеграции и обработчики остаются как есть.
Обязательно меняется контекст вызова: каждый входящий запрос несёт идентификатор клиента, который протаскивается через всю цепочку — от приёма сообщения до поиска по базе знаний и записи в историю. Без этого бот однажды ответит по чужим данным, и разделение доступа придётся чинить внешними надстройками.
Второе — слой хранения. Историю диалогов, векторные индексы и настройки разводят так, чтобы один заказчик физически не мог прочитать данные другого: отдельная схема либо обязательный фильтр по идентификатору в каждом запросе. Рядом выносится конфигурация — источники знаний, наборы инструкций для модели, лимиты обращений и правила передачи оператору.
Порядок миграции такой: сначала вводим контекст клиента со служебным значением для текущей установки, затем переносим данные в изолированные хранилища, после подключаем заказчиков по одному и сверяем ответы с эталонной выборкой. Обратная совместимость сохраняется: одиночная установка становится многоклиентской с одним клиентом, а прежний интерфейс вызова продолжает работать без правок на стороне вызывающей системы.
Учёт потребления тоже меняется: считать нужно по каждому клиенту отдельно — запросы к модели, объём индекса, активные диалоги. Иначе расходы растут общим котлом и непонятно, какой заказчик их создаёт. Объём работ зависит от того, насколько чисто был организован доступ к данным: если логика уже не лезет в базу напрямую, перенос занимает заметно меньше времени.
Технические сомнения: изоляция, качество ответов, доступы
Перед стартом заказчики просят не заверения, а доказательства: как устроена изоляция арендаторов, чем подтверждается качество ответов на реальных документах, что произойдёт при пиковой нагрузке одного крупного клиента. Ниже — пять вопросов, которые задают чаще всего, и то, как каждый ответ проверяется на стенде.
Как убедиться, что данные арендаторов не пересекаются?
Каждый арендатор работает в отдельной схеме хранилища, а слой поиска принимает его идентификатор обязательным параметром запроса. Автотест на пересечение данных прогоняется на каждом релизе.
Что с качеством ответов на наших документах?
Собираем эталонный набор вопросов по вашим регламентам и сверяем ответы с исходными фрагментами: система должна ссылаться на источник, а не достраивать факты.
Выдержит ли платформа нагрузку одного клиента?
Профиль нагрузки отдельного арендатора проверяем независимо от общего потока: ограничения на одновременные обращения не дают одному клиенту вытеснить остальных.
Сможем ли мы управлять доступом сами?
Администратор на вашей стороне заводит пользователей, раздаёт роли и видит журнал обращений. Передаём регламенты и обучаем команду, чтобы правки не требовали нас.
Как обновляется база знаний после изменений?
Изменённые документы переиндексируются точечно, а не пересобирается весь массив, поэтому новый регламент вступает в силу в течение часа. Предыдущая версия индекса сохраняется для отката.
Обсудим задачу и вернёмся с планом работ
Чтобы оценка сроков опиралась на факты, а не на предположения, нам достаточно вводных по вашему продукту. Опишите задачу в свободной форме — дальше разберём архитектуру, риски и вернёмся с планом работ.
- Текущее решение. Что уже есть: собственный чат, готовый сервис, прототип — и что именно в нём не устраивает.
- Мультитенантность. Сколько реселлеров и их клиентов должны жить в системе, нужны ли отдельные кабинеты, брендирование и изоляция данных.
- Сценарии диалогов. 5–10 типовых запросов и самые частые обращения, чтобы понять нагрузку и требования к качеству ответов.
- Источники знаний. Какие документы и базы бот должен использовать, в каком виде они хранятся и как часто меняются.
- Биллинг. Как считается потребление и что реселлер выставляет своему клиенту: подписка, объём запросов, лимиты по тенантам.
- Ограничения. Сроки запуска, внешние зависимости, доступы к системам и требования к хранению данных.
- Критерии приёмки. По каким метрикам вы поймёте, что решение работает: точность ответов, время отклика, доля запросов без оператора.
Этого набора хватает, чтобы назвать состав команды, вилку сроков и этапы. После разбора вы получите план работ с контрольными точками и понятной зоной ответственности — старт проекта не потребует дополнительных уточнений на бегу.
