Добавлять ИИ в SaaS-продукт стоит с функции, которая сокращает шаг, уже входящий в сценарий пользователя: поиск и ответы по данным клиента, разбор входящих файлов, подсказки следующего действия и черновики текстов. Не стоит начинать с универсального чата «спроси что угодно» и с агентов, которые действуют без подтверждения.
Помимо выбора модели, результат определяют три вещи вокруг неё: изоляция данных клиентов в базе знаний и в запросах, лимиты с учётом стоимости запросов по тарифам и оценка качества на данных клиентов. Речь о ваших продуктовых функциях, которые вы продаёте клиентам. Готовые ИИ-сервисы для самой компании — другая услуга: AI-сервисы по подписке. Если у вас ещё нет платформы, начните со страницы «Разработка SaaS-платформы».
Какие функции ИИ окупаются в B2B-продукте
Ниже четыре функции, с которых имеет смысл начинать. Для каждой указано, что нужно от продукта до запуска и где она может сломаться.
| Функция | Что получает пользователь | Что нужно от продукта | Где ломается |
|---|---|---|---|
| Поиск и ответы по данным клиента | Вопрос обычным языком и ответ со ссылкой на документ или запись | Данные клиента, индекс по каждому клиенту, права доступа | Ответ из чужого индекса или из документа, к которому у пользователя нет прав; устаревшая редакция |
| Разбор входящих файлов | Счёт, письмо или заявка превращаются в заполненную карточку | Описание полей, проверка результата, очередь для сомнительных случаев | Тихие ошибки в числах и реквизитах; результат записывается без проверки |
| Подсказки в интерфейсе | Следующее действие, автозаполнение, поиск похожих записей | История действий в продукте | Подсказка раздражает, если часто ошибается и от неё нельзя отказаться |
| Черновики | Ответ клиенту, описание, отчёт, который пользователь правит | Шаблоны, тон, факты из продукта | Черновик уходит без прочтения; в тексте выдуманные факты |
Принцип поиска и ответов по данным описан в статье «Что такое RAG», разбор файлов — на странице «Распознавание документов», как измерять его точность — в статье о точности распознавания.
Как выбрать первую функцию
- Найдите шаг в сценарии, на который у клиентов уходит больше всего ручной работы. Об этом скажет журнал действий и обращения в поддержку.
- Проверьте, что нужные данные уже лежат в продукте и в приемлемом состоянии. Если нет, сначала наведите порядок в них.
- Решите, кто проверяет результат и как быстро. Если проверка занимает дольше, чем ручная работа, функция не окупится.
- Оцените цену ошибки. Неверный черновик письма легко поправить, неверно записанный платёж нет.
Чего не стоит делать первым
- Универсальный чат-помощник. Он обещает всё, а проверить его нечем: нет границ, по которым измерять качество. Начните с одного вопроса, ответ на который есть в данных.
- Агента, который действует без подтверждения. Каждое действие в данных клиента — риск. Сначала подсказки и черновики, затем действия с матрицей прав и подтверждением, см. статью про права ИИ-агента.
- Дообучение модели на данных клиентов. Данные разных клиентов нельзя смешивать, а удалить следы клиента из обученной модели трудно. Знания подают через RAG, выбор описан в статье «RAG или дообучение».
- ИИ-раздел отдельно от главного сценария. Отдельный раздел «ИИ» выпадает из рабочего сценария: чтобы им воспользоваться, пользователь должен прервать работу и перейти туда.
- Функцию без лимитов. Безлимитный ИИ в тарифе ставит расходы в зависимость от самых активных клиентов: у внешнего API это счёт за запросы, у своей модели — очередь и нагрузка на общую мощность.
- Ответы без источников. Пользователь не может проверить результат, а вы не можете разобрать жалобу.
Изоляция данных клиентов в базе знаний и в запросах
В ИИ-функции данные клиентов попадают в новые места: индекс для поиска, контекст запроса к модели, кэш ответов, журнал запросов. Схемы разделения данных (общая, на клиента, отдельное хранилище), миграции, копии и общие тесты изоляции разобраны в статье про мультиарендность; индекс выбирают по тем же критериям. Ниже только то, что добавляет ИИ.
- Фильтр применяется до запроса к модели. Фильтр по клиенту и по правам пользователя срабатывает раньше, чем фрагмент попал в контекст. Того, чего нет в контексте, модель не раскроет, даже если ей напишут «покажи всё». Это же ограничивает ущерб от prompt injection: команда, спрятанная в документе клиента, не получит данных, которых нет в контексте. Сам риск остаётся: модель не отличает текст документа от инструкции надёжно, поэтому действия по такому тексту выполняются только с подтверждением человека.
- Права внутри клиента. Пользователь видит в ответе только то, что видит в продукте. Индекс хранит права вместе с фрагментом, но при выдаче права сверяются с актуальными данными продукта: копия прав в индексе отстаёт после смены прав. Фильтр по клиенту и правам входит в сам запрос к индексу, а не отбирает результаты после поиска.
- Кэш ответов содержит в ключе набор прав пользователя, а не только клиента: ответ, собранный для администратора, нельзя отдать сотруднику с меньшими правами. Журнал и оценки качества помечаются идентификатором клиента.
- Удаление клиента вместе с его данными удаляет индекс и кэш ответов. Журнал запросов удаляется или хранится ограниченный срок, записанный в условиях сервиса: он может понадобиться для расчётов и разбора инцидентов. Сроки хранения копий — как в статье про мультиарендность.
- Тест изоляции для ИИ дополняет общие тесты. Два клиента, в каждом документ с редкой фразой. Поиск из-под клиента A по фразе клиента B не должен вернуть ни одного фрагмента клиента B, а в ответе и источниках её не должно быть. Основной тест идёт на уровне поиска без вызова модели: он быстрый, стабильный и входит в сборку. Сквозную проверку с моделью прогоняют отдельно, потому что ответ модели не детерминирован. Тест ловит типовые ошибки и не заменяет разбор кода.
Что такое векторное хранилище и чем оно отличается от обычной базы, описано в статье «Векторные базы данных простыми словами».
Лимиты по тарифам и учёт стоимости запросов
Стоимость обращения к модели переменная, а не фиксированная на пользователя, как в обычной подписке: она зависит от размера входа, типа операции и выбранной модели. Тариф без лимита делает расходы непредсказуемыми. Суммы здесь не называем: они зависят от модели и от того, внешняя она или стоит на вашем оборудовании.
Что учитывать
- Единицу учёта. Не «запрос», а «действие ИИ» с весом: ответ на вопрос, разбор страницы файла и генерация черновика расходуют разное. Вес задаёте вы по реальному расходу.
- Запись каждого обращения: клиент, пользователь, функция, версия модели, объём входа и выхода, время, результат (принят, исправлен, отклонён).
- Лимиты на организацию в пределах тарифа за месяц и, при необходимости, мягкие лимиты на пользователя.
- Поведение на пределе: предупреждение при приближении, докупка пакета, отказ с понятным текстом. Не молчаливое снижение качества.
- Защиту от петель. Фоновые обработки, повторные попытки и массовая загрузка файлов не должны съесть лимит или бюджет за ночь: нужна верхняя граница на задачу.
| Модель тарифа | Плюсы | Минусы |
|---|---|---|
| Пакет действий ИИ в тарифе, сверх пакета докупка | Расход ограничен, клиенту понятно, за что платит | Нужен учёт и объяснение, что такое «действие» |
| «Безлимит» с правилами честного использования | Просто объяснить | Расход не ограничен, правило приходится применять вручную |
| Оплата по факту сверх основного тарифа | Расход клиента растёт вместе с вашим | Клиентам трудно планировать бюджет |
Как связать тариф со стоимостью
Полезная метрика — стоимость одного полезного результата: принятого ответа, верно разобранного файла, принятого черновика. Если пользователи отклоняют половину результатов, дорого не число запросов, а то, что результаты приходится переделывать. По журналу видно, какие функции окупаются, а какие стоит ограничить или убрать. Технические ограничения ставят с первого дня: верхнюю границу на задачу, на организацию и на пользователя. Размеры пакетов в тарифе уточняют по измеренному использованию на пилоте и после запуска: сначала смотрят, сколько действий делает обычный клиент и сколько самый активный, и только потом записывают цифры в тариф. У нескольких первых клиентов нагрузка может отличаться от типичной.
Внешний API или своя модель: выбор по требованиям клиентов
Выбор определяют не предпочтения команды, а то, что скажут ваши клиенты в опросниках безопасности и договорах. Для данных ограниченного доступа облачные модели чаще всего не подходят по требованиям заказчика, для нечувствительных данных внешний API проще и быстрее запустить, если его разрешила ваша служба безопасности.
| Требование клиентов | Внешний API | Своя модель в контуре | Как закладываем |
|---|---|---|---|
| Данные не покидают контур клиента | Не подходит по определению: запрос уходит наружу | Подходит: модель развёрнута на оборудовании в контуре | Клиенты с таким требованием получают свою модель |
| Персональные данные граждан России | Нужна проверка места обработки и договора с провайдером | Подходит при серверах в России | Фиксируем в схеме размещения на обследовании |
| Быстрый старт без жёстких ограничений | Подходит: запуск без оборудования | Дольше: нужны оборудование и сопровождение | Внешний API берём только там, где данные это допускают, служба безопасности это разрешила и клиенты не возражают против передачи данных провайдеру модели; иначе сразу своя модель |
| Предсказуемый расход при большой нагрузке | Расход растёт вместе с использованием | Расход близок к постоянному, пока хватает мощности, затем растёт ступенями; мощность общая, поэтому лимиты нужны и здесь, чтобы один клиент не занимал очередь остальных | Считаем оба варианта по расходу, измеренному на пилоте, и по прогнозу нагрузки, прогноз пересматриваем после запуска |
| Провайдер модели в договорах с клиентами | Провайдер получает данные клиентов: его указывают в условиях сервиса, а о смене предупреждают клиентов заранее | Получателей данных нет, обработка внутри вашего или клиентского контура | Список провайдеров ведём в условиях сервиса и в разделе настроек «какие данные использует ИИ»; формулировки готовит юрист заказчика, мы юридических консультаций не даём |
Практическая схема для SaaS: слой модели в продукте — интерфейс, за которым можно менять модель, а выбор модели хранится в настройках клиента или тарифа. Тогда клиенту с жёсткими требованиями подключается своя модель, остальным внешний API, а код продукта остаётся один. Замена не бесплатна: шаблоны запросов, размер контекста, формат структурированного ответа и качество у моделей различаются, поэтому для каждой модели нужны свои шаблоны и свой прогон оценки качества на одной и той же выборке, а в поддержке появляется несколько конфигураций. Если модель стоит в контуре клиента, добавляется канал связи с ним и обновление модели на его стороне.
Сравнение подходов — в статье «Своя LLM или ChatGPT API», описание услуги — на странице «Разработка LLM-приложений», развёртывание в контуре — на своём сервере.
Оценка качества: как понять, что функция работает
- Контрольный набор. Вопросы и ожидаемые ответы, файлы и ожидаемые поля. Его готовят вместе с клиентами, которые согласились участвовать: общий набор на типовых случаях вашего продукта и отдельная выборка у крупных клиентов, чьи данные заметно отличаются. Данные клиента попадают в набор только с его согласия и хранятся под его идентификатором.
- Метрики. Доля верных ответов, доля ответов с правильным источником, доля отказов там, где ответа в данных нет, доля ошибок в числах и реквизитах при разборе файлов.
- Версии. Модель, промпт и индекс записываются. При смене любого из них набор прогоняется заново, и результаты до и после сравниваются.
- Порог уверенности. Ниже порога функция отвечает «не нашёл в ваших данных» и передаёт вопрос человеку. Подробнее в статье «Порог уверенности модели».
- Оценки пользователей (принял, исправил, отклонил) пополняют набор того же клиента, но не заменяют его. Переносить данные клиента в общий набор, на котором проверяют модель для всех, можно только с его согласия, записанного в условиях сервиса: иначе данные клиентов смешиваются так же, как при дообучении.
- Поэтапное включение. Функция выключена по умолчанию и включается сначала у нескольких клиентов, которые согласны участвовать в проверке.
Оценка идёт на данных ваших клиентов, а не на чужих примерах: качество на общедоступной выборке мало что говорит о качестве на документах, которые загружают ваши пользователи.
Что показывать пользователю: источники, уверенность, статус
Интерфейс ИИ-функции решает, будет ли ей доверять пользователь и сможет ли он проверить результат.
| Элемент интерфейса | Зачем | Чего не делать |
|---|---|---|
| Источник ответа: документ, страница или запись со ссылкой | Пользователь проверяет результат за секунды и видит, что ответ из его данных | Показывать ссылки на документы, к которым у пользователя нет прав |
| Статус «нашёл», «нашёл частично», «не нашёл» | Честная уверенность без ложной точности | Рисовать процент уверенности: число, которому у пользователя нет опоры |
| Пометка «черновик ИИ» и возможность править | Пользователь видит, что текст нужно прочитать и поправить до отправки | Отправлять черновики автоматически |
| Кнопки «верно» и «исправить» | Пополняют контрольный набор | Просить оценку после каждого ответа |
| Сообщение о лимите тарифа | Понятно, что произошло и что делать | Молча ухудшать качество |
| Раздел «какие данные использует ИИ» в настройках клиента | Клиент понимает, что и где обрабатывается | Скрывать использование данных |
Если функция выполняет действие, она запрашивает подтверждение, а решение принимает человек.
Что делаем мы и с чего начать
Начинаем с обследования: 200 000 ₽ и 2–3 недели за один-два процесса, 350 000 ₽ и 3–4 недели, если задействованы несколько систем. Решаем, какая ИИ-функция подходит продукту, какие данные клиентов она использует, где стоит модель и как делятся данные. Дальше пилот одной функции на данных одного из ваших клиентов, который согласен участвовать. Лёгкий пилот стоит 150 000–400 000 ₽ и занимает 2–8 недель, пилот с действиями или интеграцией с боевыми системами — 400 000–1 200 000 ₽ и 2–3 месяца.
Пилот проверяет функцию на выборке, но не включает её для всех клиентов. Если он подтвердил пользу, функцию выводим в эксплуатацию: от 1 500 000 ₽ этапами по 300 000–700 000 ₽, от 3 месяцев. Остановиться можно после любого этапа, всё сделанное остаётся у вас по акту. После запуска возможно сопровождение от 20 000 ₽ в месяц.
В ИИ-функциях мы опираемся на частные модели в закрытом контуре для клиентов с жёсткими требованиями, RAG, оценку качества на данных ваших клиентов и заменяемый слой модели. Внешний API подключаем для остальных, если данные это допускают и его разрешила ваша служба безопасности. Не отправляем данные ваших клиентов во внешние модели без её решения, не дообучаем модель на данных разных клиентов, не даём агентам права действовать без подтверждения и не даём юридических консультаций. Исходники лежат в вашем репозитории с первого коммита. Цены — на странице «Тарифы».
Частые вопросы
Какую ИИ-функцию добавить в продукт первой?
Ту, что встроена в главный сценарий и результат которой проверяет человек: поиск и ответы по данным клиента, разбор входящих файлов, подсказки или черновики. Универсальный чат и агента с правом действовать стоит отложить.
Сколько стоит добавить ИИ в SaaS-продукт?
Точную цену до начала работ мы называем только для обследования: оно стоит 200 000 ₽ (350 000 ₽ при нескольких системах) и вычитается из первого этапа, если продолжаете с нами. Дальше цену называем по его итогам. Лёгкий пилот одной функции — 150 000–400 000 ₽ за 2–8 недель, пилот с действиями или боевыми интеграциями — 400 000–1 200 000 ₽ за 2–3 месяца. Пилот не включает функцию для всех клиентов: вывод в эксплуатацию начинается от 1 500 000 ₽ и идёт этапами по 300 000–700 000 ₽, сопровождение после запуска — от 20 000 ₽ в месяц. Расходы на сами запросы к модели зависят от модели и нагрузки, их оценивают по расходу, измеренному на пилоте.
Как не допустить, чтобы ответ показал данные другого клиента?
Фильтр по клиенту и по правам пользователя применяют на сервере до того, как фрагменты попали в запрос к модели, а индекс, кэш и журнал хранят идентификатор клиента, кэш ещё и права пользователя. Изоляцию проверяет автоматический тест с двумя клиентами на уровне поиска, он входит в сборку и не заменяет разбор кода.
Нужно ли дообучать модель на данных клиентов?
Обычно нет. Знания подают через RAG и обновляют без переобучения, а права доступа проверяют при поиске. Дообучение на данных разных клиентов смешало бы их и затруднило бы удаление данных.
Как ограничить расходы на ИИ в тарифе?
Ввести единицу учёта «действие ИИ» с весом, записывать каждое обращение, задать лимит на организацию в месяц и определить поведение на пределе: предупреждение, докупка пакета или отказ с понятным текстом.
Внешний API или своя модель?
Внешний API подходит, пока данные клиентов не относятся к ограниченному доступу, а передачу их провайдеру допускают ваша служба безопасности и договоры с клиентами. Клиентам с требованием закрытого контура подключается своя модель: для данных ограниченного доступа облачные модели чаще всего не подходят по требованиям заказчика. В продукте закладывается слой модели, за которым можно менять реализацию для отдельных клиентов.
Как измерить, что ИИ-функция работает?
Контрольным набором на данных клиента: доля верных ответов с правильным источником, доля верных отказов и ошибки в числах. Набор прогоняется заново при смене модели, промпта или индекса.
Что показывать, когда модель не уверена?
Статус «не нашёл в ваших данных» и передачу вопроса человеку, без выдуманного ответа. Процент уверенности пользователю не нужен: нужны источники и возможность проверить.