В MVP ИИ-сервиса входит один сценарий с измеримым результатом, эталон качества с прогоном одной командой, права и разделение данных клиентов, учёт стоимости каждого запроса с потолками, очередь спорных случаев для человека, тариф со счётом и журнал без текстов запросов. Откладывают остальные сценарии, дообучение, настройки клиента, автоматические действия в чужих системах и тонкие роли.
В отличие от обычного MVP, здесь нельзя вычеркнуть проверки качества и стоимости: без них непонятно, работает ли сервис и не убыточен ли он на каждом клиенте. Общий принцип отбора функций описан в статье «Как сделать SaaS MVP», услуга — на странице «Создать ИИ-сервис». Здесь только то, что специфично для ИИ.
Три списка: включаем, делаем вручную, откладываем
Объём первой версии удобно задать тремя списками. Сомнительные пункты по умолчанию идут в «вручную» или «позже», а не в «включаем».
| Часть сервиса | Включаем в MVP | Делаем вручную | Откладываем |
|---|---|---|---|
| Сценарий | Один сценарий с одним измеримым результатом | Подготовка нестандартных входов силами вашего эксперта | Второй и третий сценарии, конструктор сценариев |
| Качество | Эталон, прогон одной командой, порог, отказ при нехватке данных, ссылка на источник | Первичная разметка эталона экспертом | Автоматическое пополнение эталона из отзывов |
| Модель | Одна модель за общим интерфейсом, версия модели в журнале | Сравнение вариантов на эталоне перед выбором | Маршрутизация между моделями, дообучение |
| Клиенты и права | Организации, одна-две роли, права на сервере, тест изоляции | Подключение организации по заявке | Роли, настраиваемые клиентом, вход через каталог клиента |
| Стоимость | Запись каждого действия ИИ, потолки, отчёт для владельца | Недельная проверка расходов по клиентам | Панель расходов для клиента, докупка пакетов в интерфейсе |
| Человек | Очередь спорных случаев и подтверждение действий | Разбор очереди экспертом | Автоматическое решение по части случаев |
| Тариф | Пакет в тарифе, счёт, выгрузка для бухгалтерии | Выставление счёта вручную | Автоматические списания, возвраты, закрывающие документы |
Сценарий: один и измеримый
Первая версия решает одну задачу. Проверка простая: сценарий описывается одной фразой в форме «кто получает какой результат и как понимает, что он верен». Если в фразе два результата, это два сценария. Если «как понимает» нет, сценарий не измерим и принять его будет нечем.
Измеримый результат выглядит по-разному для разных видов сервиса. Для ответов по документам это верный ответ со ссылкой на документ и страницу или честный отказ. Для извлечения полей это совпавшие поля с отметкой уверенности. Для генерации черновиков это доля черновиков, принятых экспертом без правок или с мелкими. Для прогноза это качество на отложенной выборке данных клиента. Какие бывают виды сервисов и чем они рискуют, показано на странице «Создать ИИ-сервис».
Качество внутри MVP: эталон, порог и отказ
Эталон не украшение, а условие приёмки. В первую версию входят:
- Набор примеров с верными ответами, размеченный экспертом предметной области. Начинать можно с нескольких десятков примеров, включая спорные и такие, где верный ответ «данных недостаточно».
- Прогон одной командой при сборке и при смене модели, шаблона запроса или данных. Результат сравнивается с порогом, выкладка при падении ниже порога останавливается.
- Порог, который назвал владелец продукта. Исполнитель порог не выбирает: он не знает, сколько стоит ошибка для вашего клиента.
- Отказ вместо выдумки. Если в документах нет ответа, сервис так и говорит. Для этого в эталоне есть примеры без ответа.
- Источник в каждом ответе. Пользователь должен иметь возможность проверить, откуда взят ответ.
Подробнее об оценке — на странице оценки качества LLM-систем. Автоматическое пополнение эталона, метрики по сегментам и сравнение трёх моделей одновременно откладываем.
Человек в цепочке: что делает эксперт, пока программа не готова
Человек в первой версии не признак слабого продукта, а способ выпустить его раньше. Важно записать, что именно он делает и когда это перестанет быть нужным.
| Что делает человек | Почему пока не автоматизируем | Когда можно автоматизировать |
|---|---|---|
| Проверяет ответы с низкой уверенностью | Нет данных о том, где модель ошибается | Когда по журналу видно, на каких типах входов ошибок мало и их цена невелика |
| Подтверждает действия в системах клиента | Ошибка стоит дороже, чем минута проверки | Для обратимых действий с откатом и с журналом |
| Разбирает отклонённые пользователем ответы | Причины разные: данные, шаблон, ожидания | Когда набралось достаточно примеров для повторяющихся причин |
| Настраивает нового клиента | Нет двух одинаковых клиентов, форма настройки неизвестна | После трёх-четырёх клиентов, когда повторяются одни и те же шаги |
Очередь спорных случаев нужна и клиенту: он видит, что сервис признаёт неопределённость, а не выдаёт её за уверенный ответ.
Что нельзя откладывать: безопасность и разделение клиентов
Экономить на этом пункте дорого: исправлять разделение данных в работающем сервисе сложнее, чем заложить его с первого дня. В MVP остаются:
- Права на сервере. Каждый запрос проверяет пользователя, организацию и роль. Спрятанная кнопка ничего не защищает.
- Фильтр по организации в поиске. Для векторного хранилища это обязательное условие на стороне хранилища, а не пост-фильтрация в коде приложения.
- Организация в ключе кэша. Иначе одинаковый вопрос двух клиентов получит ответ из документов первого.
- Журнал без текстов запросов. Тексты, если они нужны для разбора, лежат в отдельном хранилище с ограниченным доступом и сроком жизни.
- Защита от инструкций в документах. Загруженный клиентом документ может содержать текст, который читается как команда для модели. Права на действия проверяются вне модели, а вывод модели считается недоверенным вводом. Об этом — в статье «Что такое prompt injection».
- Тест изоляции. От имени клиента B пытаемся получить документы клиента A через поиск, кэш, фоновые задачи и прямые адреса. Тест входит в приёмку.
Копии с пробным восстановлением и оповещение о недоступности тоже входят в первую версию; регламент проверок и нагрузочные испытания относятся к выводу в эксплуатацию.
Стоимость в MVP: что считать с первого дня
Цена обращения к модели переменная, поэтому сервис без учёта легко становится убыточным на одном-двух клиентах. В первую версию входит минимум: запись каждого действия ИИ (организация, функция, версия модели, объём входа и выхода, время, исход), единица учёта с весом, потолки на задачу и организацию и еженедельный отчёт для владельца продукта.
Тариф в MVP может быть простым, но обязан опираться на этот журнал. Считать нужно стоимость принятого результата: весь расход вместе с отказами и повторами, делённый на число принятых результатов. Формулы и пример с условными единицами — в статье «Себестоимость ИИ-сервиса». Суммы за модели и оборудование здесь не называем: они зависят от нагрузки.
Критерии успеха и остановки: записываем до запуска
MVP проверяет гипотезу, поэтому у неё должны быть условия, при которых вы продолжаете, меняете курс или останавливаетесь. Пороги называет владелец продукта, исполнитель их не придумывает.
| Вопрос | Показатель | Если ответ плохой |
|---|---|---|
| Платят ли? | Число организаций, оплативших первый период | Меняем аудиторию или тариф; проверяем, кто принимает решение о покупке |
| Возвращаются ли? | Доля организаций, использующих сервис во втором и третьем периодах | Переделываем сценарий или встраиваем его в рабочий процесс пользователя |
| Работает ли качество? | Результат прогона эталона и доля ответов, исправленных пользователями | Улучшаем данные и шаблоны; если порог недостижим, меняем сценарий |
| Окупается ли запрос? | Стоимость принятого результата в сравнении с тарифом | Пересчитываем тариф, потолки и выбор модели |
| Хватает ли людей? | Часы эксперта на очередь спорных случаев на один период | Автоматизируем повторяющиеся случаи или сужаем сценарий |
Если на главный вопрос ответ «нет» повторяется на нескольких организациях, останавливаемся. Остановка по заранее записанному правилу — результат эксперимента, а не провал.
Четыре ошибки при определении объёма ИИ-MVP
- Берут «самую сильную» модель и считают на этом работу завершённой. Модель дополняет сервис, но права, учёт и оценка качества определяют, можно ли его продавать.
- Включают несколько сценариев «для широты». Каждый требует своего эталона, шаблонов и проверок, и ни один не доводится до качества, за которое платят.
- Откладывают тест изоляции до запуска. К этому моменту индекс, кэш и журнал уже устроены так, что переделывать приходится основу.
- Дают агенту писать в системы клиента без подтверждения. Первая же ошибка меняет чужие данные, а откатить её нечем.
Если в вашем списке «включаем» больше семи пунктов, часть из них, скорее всего, относится к выводу в эксплуатацию. Тогда её переносят в следующий этап, а не в первую версию.
Что делаем мы и с чего начать
Начинаем с обследования: 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 ₽ и сопровождение от 20 000 ₽ в месяц. Исходный код лежит в вашем репозитории с первого коммита, остановиться можно после любой ступени. Цены — на странице «Тарифы».
Частые вопросы
Что входит в MVP ИИ-сервиса?
Один сценарий с измеримым результатом, эталон и прогон, права и разделение данных клиентов с тестом, учёт стоимости с потолками, очередь спорных случаев, тариф со счётом, журнал без текстов запросов, копии с пробным восстановлением.
Сколько стоит MVP ИИ-сервиса и сколько времени занимает?
Первая версия стоит 400 000–1 200 000 ₽ и занимает 2–3 месяца, в тарифах это тяжёлый пилот. Перед ней обследование за 200 000 ₽ (350 000 ₽ при нескольких системах), оно вычитается из первого этапа, если продолжаете с нами.
Чем MVP ИИ-сервиса отличается от обычного SaaS MVP?
В нём нельзя вычеркнуть оценку качества и учёт стоимости запросов, а разделять надо не только таблицы, но и индекс, кэш, журнал и примеры в запросах. Остальной объём отбирается так же: пять вопросов к каждой функции, ручной режим, готовые части.
Можно ли делать MVP без эталона?
Можно, но тогда нечем принимать работу и сравнивать изменения: качество оценивается на глаз. Эталон из нескольких десятков примеров собирается быстро и окупается уже при выборе модели и шаблонов.
Нужно ли дообучение модели в первой версии?
Обычно нет. Сначала проверяют, хватает ли поиска по документам и хороших шаблонов запросов, а решает замер на эталоне. Использовать данные клиента для улучшения сервиса без его письменного согласия нельзя.
Должен ли агент в MVP менять данные в системах клиента?
Лучше начать с чтения и черновиков. Действия с записью добавляются позже, с правами не шире, чем у пользователя, подтверждением человеком и журналом.
Нужна ли онлайн-оплата в MVP?
Не обязательно. Если первые клиенты платят по счёту, достаточно тарифа в системе и выгрузки для бухгалтерии. Платёжного провайдера подключаем, когда оплата нужна для сценария; договор с провайдером заключаете вы, данные карт хранит провайдер.
Что делать, если MVP не сработал?
Смотреть на критерии, записанные до запуска. По ним ясно, менять ли аудиторию, тариф, сценарий или остановиться. Сделанное остаётся у вас по акту, исходники в вашем репозитории.