ИИ-функция в действующем SaaS-продукте: поиск и помощник без утечки данных клиентов
Помощник отвечает только по данным того клиента, который его спросил, а качество измерено на его же вопросах
Проверяется: тест изоляции по арендаторам и выборка вопросов с эталоном
SaaS и продуктыРаботаем по NDA
В готовом SaaS-продукте хотят добавить помощника, который отвечает по данным клиента: документам, заявкам, истории. Проблемы две. Первая: помощник не должен увидеть данные другого клиента или то, на что у пользователя нет прав. Вторая: нужно понимать, сколько стоит один запрос и что будет при наплыве.
Что съедает срок и бюджет на самом деле
Интерфейс чата делается за дни. Дольше всего живёт то, что вокруг него.
Права применяются слишком поздно
если фильтр прав включается после выбора фрагментов, чужой текст уже попал в контекст модели. Фильтровать нужно до отбора.
Качество не мерили
без набора вопросов с эталонными ответами нельзя сказать, стало лучше после изменения или хуже. Спор о качестве остаётся мнением.
Стоимость запроса непредсказуема
длинные документы и повторные вопросы раздувают расход. Нужны лимиты на клиента, кэш и учёт использования в тарифе.
Функцию нельзя выключить
если сбой модели ломает основной продукт, выпуск опасен. Помощник должен отключаться без влияния на остальное.
Ограничение, которое определяет решение
Для данных ограниченного доступа облачные модели чаще всего не подходят по требованиям клиента, поэтому для таких клиентов нужен вариант с моделью на их серверах или в вашем контуре. Выбор между внешним интерфейсом модели и собственным развёртыванием зависит от данных, а не от моды. Персональные данные и условия договора с клиентом решает юрист заказчика.
Как проверить, что работа сделана
Тест изоляции: два клиента с похожими документами, вопросы одного не должны возвращать фрагменты другого, и это проверяется автоматически.
Выборка вопросов: набор реальных вопросов клиентов с эталонными ответами и указанием документа, система считается принятой по заранее согласованному порогу, который записан до начала.
Стоимость и отключение: расход на клиента виден в журнале, лимиты срабатывают, а отключение функции не влияет на остальной продукт.
О чём спросить любого подрядчика
- На каком этапе применяются права и как это проверяется.
- Как измеряется качество и кто составляет набор вопросов.
- Где работает модель и что происходит с данными клиента.
- Как ограничивается расход на клиента.
- Что видит пользователь, если помощник недоступен.
Как мы идём по этапам
На каждом этапе назван результат, который остаётся у заказчика. Остановиться можно после любого.
- Данные и праваОпределяем, что может видеть помощник, и описываем права клиента и пользователя. Результат: матрица доступа.
- Набор вопросовВместе с вашей поддержкой собираем реальные вопросы и эталоны. Результат: выборка для измерения качества.
- Поиск и ответСобираем поиск с фильтром прав и ответ с указанием источника. Результат: пилот на данных двух клиентов.
- Лимиты и журналУчёт расхода, лимиты, отключение функции. Результат: рабочие ограничения.
- Запуск для части клиентовВключаем функцию для группы клиентов, смотрим качество и расход, расширяем. Передаём код, набор вопросов и регламент.
Как это обычно устроено внутри
Типовая схема: данные каждого клиента индексируются в его области, запрос пользователя проходит проверку прав, поиск возвращает только разрешённые фрагменты, модель формулирует ответ по ним и указывает источник. Расход считается на клиента, лимиты проверяются до вызова модели, при сбое функция отключается без влияния на остальной продукт.
- PostgreSQL
- Векторный поиск
- Языковая модель
- REST API
- Журнал обращений
- Автоматические тесты
Похожая задача у вас?
Разберём её на созвоне за 40 минут: назовём объём работ, ограничения контура и по каким числам вы будете принимать результат. Если задача не наша — скажем прямо.