Проверка ИИ-гипотез: пять этапов от идеи до внедрения

2026-10-21 20:24:32 Время чтения 8 мин 30

ИИ-проект стоит начинать не с разработки полноценного продукта, а с проверки конкретного предположения: какой процесс в компании можно улучшить, какой ожидается эффект и при каких затратах.

Для этого задачу можно разделить на пять этапов: PoC (Proof of Concept - проверка гипотезы), демонстрационная версия, тестирование, пилотная версия и работающий продукт (Production). Каждый этап должен отвечать на отдельный вопрос. Переход к следующему зависит от результата текущего.

Рассмотрим этот процесс на условном примере: B2B-поставщик хочет сократить время обработки заявок. Клиенты присылают списки товаров в Excel, PDF и тексте письма. Менеджер переносит позиции, ищет их в каталоге и готовит коммерческое предложение.

Гипотеза: ИИ сможет извлекать позиции и сопоставлять их с каталогом, а менеджер будет проверять результат и подтверждать подготовленный документ.

До начала: определить результат и ограничения

Формулировка «автоматизировать обработку заявок с помощью ИИ» не задаёт критериев успеха. Необходимо уточнить, какую часть работы должен выполнять сервис и как будет оцениваться результат.

Гипотеза
Автоматическое извлечение и сопоставление позиций сократит время подготовки коммерческого предложения без увеличения числа ошибок.

Для нашего примера гипотеза звучит так:

До разработки фиксируют:

  1. текущее время обработки заявки;
  2. форматы документов и категории товаров, входящие в проверку;
  3. допустимый уровень ошибок;
  4. предельную стоимость обработки;
  5. действия, которые остаются за менеджером;
  6. условия продолжения и остановки проекта.

Основной принцип — критерии определяют заранее. Иначе оценка рискует свестись к субъективному впечатлению от демонстрации.

Техническая основа: не начинать каждый проект с нуля

В предлагаемом процессе Claude Code, Codex или другой инструмент ИИ-разработки работает не с пустым проектом, а с подготовленным шаблонным репозиторием.

В нём закреплены:

  1. архитектура и технологический стек;
  2. структура приложения и правила написания кода;
  3. авторизация и управление доступом;
  4. подключение к данным;
  5. логирование и обработка ошибок;
  6. тестирование и конфигурация развёртывания.

Отдельно подготавливаются инструкции для ИИ-инструмента: какие решения разрешены, какие ограничения нужно соблюдать и как проверять изменения. Повторяемые процедуры можно описать в виде skills — инструкций для выполнения определённых типов задач.

Если такой основы нет, её необходимо создать. Это отдельная работа, которую нельзя считать временем проверки одной бизнес-гипотезы.

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

1. PoC: проверить техническую возможность

PoC — минимальная реализация для проверки ключевого предположения.

В нашем случае достаточно скрипта, который получает заявку, извлекает наименования, артикулы и количество, затем ищет соответствия в каталоге. Интерфейс и полноценная интеграция с CRM пока не нужны.

Claude Code или Codex получает ограниченную задачу: реализовать этот сценарий по правилам подготовленного проекта, с заданным форматом результата и проверками.

На этапе PoC оценивают:

  1. корректность извлечения данных;
  2. точность сопоставления товаров;
  3. обработку неоднозначных позиций;
  4. время и стоимость выполнения.

Проверять решение нужно не только на удобных примерах, но и на документах с ошибками, опечатками и нестандартными обозначениями.

Результат этапа — перечень ограничений и решение: продолжить, изменить подход или остановить работу. Например, если точное сопоставление возможно только по артикулам, область применения можно ограничить такими заявками.

2. Демо: проверить пользовательский сценарий

Успешная обработка документа ещё не означает, что решение удобно в работе.

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

Достаточно одного сквозного сценария:

  1. Загрузить документ.
  2. Проверить распознанные данные.
  3. Исправить или подтвердить найденные товары.
  4. Получить результат.

Здесь важно оценить не внешний вид приложения, а действия пользователя. Понятно ли, где система не уверена? Можно ли быстро исправить ошибку? Сохраняется ли связь с исходной заявкой?

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

3. Тестовый контур: подготовить ограниченный запуск

Работающее демо необходимо подготовить к использованию вне среды разработчика.

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

Для сервиса обработки заявок необходимо:

  1. подключить согласованный источник каталога;
  2. ограничить круг пользователей;
  3. определить сроки хранения документов;
  4. настроить логирование ошибок;
  5. проверить обработку повреждённых файлов;
  6. исключить отправку предложений без подтверждения менеджера.

Результат этапа — версия, которую можно передать участникам пилота.

4. Пилот: измерить эффект в реальной работе

На этапе пилота осуществляется проверка всего процесса.

 Группа менеджеров обрабатывает реальные заявки. Результаты сравнивают с исходными показателями, учитывая объём и сложность документов.

Основные метрики:

  1. время обработки с учётом проверки и исправлений;
  2. доля позиций, требующих ручного вмешательства;
  3. количество критических ошибок;
  4. стоимость обработки одной заявки;
  5. доля заявок, для которых сервис применим;
  6. регулярность использования сотрудниками.

Экономическую оценку строят с учётом расходов на модель, инфраструктуру, сопровождение и ручную проверку.

Результат пилота — решение о внедрении, доработке, сужении сценария или закрытии проекта. Технически работоспособное решение вполне может оказаться экономически нецелесообразным.

5. Промышленная эксплуатация: обеспечить устойчивую работу

После успешного пилота сервис включают в постоянный рабочий процесс.

На этом этапе определяют:

  1. ответственных за сопровождение;
  2. порядок устранения сбоев;
  3. правила обновления каталога, модели и инструкций;
  4. проверки качества после изменений;
  5. ограничения доступа и хранения данных;
  6. порядок работы при недоступности сервиса.

В нашем примере первоначальная версия может только готовить черновики предложений. Автоматическую отправку клиенту следует рассматривать как отдельное расширение процесса со своими требованиями и проверками.

Результат — не просто развёрнутое приложение, а сервис с понятной ответственностью и правилами эксплуатации.

Следующий шаг — техническая реализация

Такой процесс разделяет три разных вопроса: можно ли реализовать решение, удобно ли им пользоваться и оправдывает ли оно затраты.

Claude Code и Codex используются для разработки, но решение о продолжении проекта принимают по результатам каждого этапа.

В следующей статье перейдём к технической части: подготовим шаблонный репозиторий, закрепим архитектуру и правила разработки, настроим инструкции и skills. Затем на этой основе соберём PoC и демо приложение сервиса обработки заявок.