Задача: ответить по документам, не перепутав клиентов

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

В опубликованном Weaviate кейсе DocsBot описан как продукт основателя-одиночки Аарона Эдвардса. После резкого притока пользователей первоначальный подход к множеству отдельных индексов перестал устраивать по масштабируемости и затратам на обслуживание. Команде из одного человека требовались релевантный поиск по документам, изоляция клиентских данных и управляемая эксплуатация. Это история поставщика инфраструктуры о собственном клиенте, а не независимый аудит бизнеса.

Что действительно было сделано

Согласно кейсу, DocsBot сам принимает документы, разбивает их на фрагменты и создаёт эмбеддинги. Векторы и метаданные хранятся в Weaviate Cloud. При вопросе сервис выполняет семантический или гибридный поиск, передаёт найденный контекст языковой модели и формирует ответ. Мультитенантный механизм позволяет обслуживать множество изолированных наборов данных в одном кластере.

Weaviate сообщает о более чем 50 тысячах тенантов в одном кластере и более 6,1 млн обработанных клиентских вопросов за год. Это показатели из кейса поставщика: методика подсчёта, качество ответов, экономия времени операторов и окупаемость там не раскрыты. Их нельзя превращать в обещание для другой компании. Также агентные действия — например, маршрутизация обращения или запуск рабочего процесса — в кейсе описаны как дальнейшее развитие продукта, а не как подтверждённый результат внедрения.

Полезная деталь здесь не число тенантов само по себе. DocsBot выбрал облачную управляемую базу, потому что основателю было важнее развивать продукт, чем непрерывно обслуживать отдельную поисковую инфраструктуру. Для российского бизнеса с требованиями к защищённому контуру выбор может быть обратным, но стоимость собственных администраторов, резервирования и мониторинга тогда остаётся на стороне компании.

Почему один общий индекс не заменяет контроль доступа

RAG часто рисуют как короткую цепочку «документ — поиск — модель — ответ». В многоклиентском сервисе перед поиском появляется ещё один обязательный шаг: сервер должен установить, от имени какого клиента и какого пользователя выполняется запрос. Этот контекст нельзя принимать на веру из параметра, который может изменить браузер или интеграция. OWASP прямо рекомендует связывать контекст тенанта с проверенной учётной записью и отдельно проверять право доступа.

Даже если векторная база умеет разделять тенантов, защита должна пройти через всю цепочку:

  • загрузка присваивает документу проверенный идентификатор владельца и права;
  • обработка и повторная индексация не смешивают очереди разных клиентов;
  • извлечение ограничивается разрешённым тенантом до передачи фрагментов модели;
  • кэш, файлы, журналы и резервные копии сохраняют ту же границу;
  • удаление клиента удаляет или изолирует его данные по согласованному сроку хранения.

Иначе робот окажется удивительно усердным: аккуратно принесёт нужную папку, только из соседнего шкафа. Шутка годится для иллюстрации, но для теста доступа результат должен быть строгим нулём.

Что из кейса переносится в локальный контур

Российскому интегратору не требуется копировать облачную конфигурацию DocsBot или масштабировать пилот до 50 тысяч арендаторов. Переносимым является порядок решений. Сначала перечислить владельцев знаний: филиалы, дилеров, отдельные юридические лица или клиентов SaaS. Затем определить, какая граница нужна между ними — отдельная база, коллекция, тенант в коллекции либо более жёсткое физическое разделение. Выбор зависит от требований к доступу, объёма данных, нагрузки и допустимого «радиуса поражения» при ошибке.

Для пилота достаточно двух или трёх учебных тенантов с обезличенными, но заведомо разными документами. Пользователь А спрашивает о факте, который есть только у Б. Система обязана отказать или ответить, что данных нет; похожий по смыслу фрагмент Б не должен попасть ни в подсказку модели, ни в цитату ответа. Повторите проверку при повторной индексации, смене роли, истечении сессии, восстановлении из копии и работе кэша. Важно мерить не только точность ответа, но и долю найденных документов с неверным владельцем — целевой результат здесь ноль.

Нужны и обычные эксплуатационные метрики: время ответа на 95-м процентиле, доля ответов с проверяемым источником, число отказов из-за недостаточного контекста, стоимость обработки одного вопроса, объём индекса на одного клиента и время удаления данных. Локальная модель может быть уместна, если данные нельзя отправлять наружу или поток запросов достаточно предсказуем, но сама по себе локальность не исправит ошибку авторизации в поиске.

Экономика: считать весь путь вопроса

В кейсе нет открытой сметы DocsBot, поэтому вывод «так дешевле» был бы выдумкой. Для своей компании сравните хотя бы два сценария на одинаковом наборе вопросов: управляемый сервис и локальный контур. В расходы включите подготовку документов, эмбеддинги, векторное хранилище, вычисления для модели, резервное копирование, мониторинг, обновления и труд специалиста. Отдельно оцените ущерб от неверного разграничения данных: его нельзя прятать в среднюю цену токена.

Порог окупаемости не универсален. Если вопросов мало, а требования к данным позволяют внешнего поставщика, собственная инфраструктура может простаивать. Если запросов много и сведения должны оставаться внутри, локальный вариант может оказаться разумнее, но это нужно подтвердить измерением нагрузки и затрат на сопровождение. При сравнении фиксируйте одинаковые требования к доступности и качеству поиска, иначе таблица цен будет сравнивать разные продукты.

Следующий шаг без длинного проекта

Выберите один поток — например, ответы по инструкциям для двух дилеров — и составьте карту: кто загружает документы, кто задаёт вопросы, кто вправе видеть каждую папку и когда её надо удалить. На обезличенной выборке проверьте десять обычных вопросов и десять попыток обратиться к чужим данным. Если граница доступа выдержана и ответы ссылаются на разрешённые источники, расширяйте пилот. Если нет, отложите выбор модели и исправьте контур доступа. Так урок DocsBot превращается в проверяемое решение, а не в гонку за чужими масштабными цифрами.