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