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