[
15
.
04
.
2026
]

Как проверять гипотезы для LLM-решений перед запуском: опыт Napoleon IT

Napoleon IT
Разработчик AI-решений для бизнеса
LLM
Искусственный интеллект
Компьютерное зрение
link
Большинство команд, которые создают продукты на основе языковых моделей, начинают с одной и той же точки: есть технология и идея ее применения, значит, нужно делать продукт. Это логика, которая редко приводит к реальным продажам.

При запуске «Наполеон Документы» – платформы для интеллектуальной обработки документов, мы намеренно пошли в другом направлении: сначала исследовали рынок, потом приступили к разработке продукта. В этой статье рассказываем, как мы проверяли гипотезы перед стартом.

Сначала отсечь лишнее, потом идти вглубь

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

Первый шаг — сегментация. Десять отраслевых сегментов, по каждому четыре вопроса: размер рынка, конкурентное окружение, зрелость автоматизации, барьеры входа. Результат — приоритизированная матрица. Пять сегментов из десяти отрезали сразу: в одних уже стояли зрелые решения, в других боль существовала, но была недостаточно острой, чтобы за неё платили. «Было бы удобно» и «готовы купить» — принципиально разные вещи.

Как проверяли гипотезы

С людьми из трёх приоритетных сегментов команда разговаривала лично — не презентовала продукт, которого ещё не было, а разбиралась в том, как устроена работа респондентов. Мы провели более 20 глубинных JTBD-интервью (Jobs To Be Done – методология для анализа поведения пользователей и прогнозирования их решений). Интервью занимали 60–90 минут, мы спрашивали про реальные процессы, конкретные ошибки и их последствия.

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

Параллельно с финальными интервью руководитель пресейла посетил отраслевую конференцию с конкретной задачей: проверять гипотезы. Каждый контакт проходил через закрытый опросник, привязанный к предположениям о рынке. Это дало количественный слой поверх качественного и одновременно конвертировало часть контактов в полноценные интервью.

Как устроен анализ интервью

Каждое интервью обрабатывалось в структурированный документ: сегмент респондента, описание каждой рабочей задачи (контекст, триггер, текущее решение, барьеры, желаемый результат), оценка силы проблемы по 10-балльной шкале, ключевые цитаты с таймкодами. Это не просто конспект разговора, а аналитический материал, с которым работает вся команда.

Важный нюанс: силу проблемы оценивает аналитик, а не респондент. Люди склонны преувеличивать или преуменьшать. Оценка калибруется по контексту: сколько людей задействовано в процессе, каковы финансовые последствия ошибки, пробовали ли уже как-то решать.

По мере накопления интервью они синтезировались в сводные документы: таблица всех респондентов, граф JTBD-работ, приоритизированная карта задач, повторяющиеся паттерны и противоречия, профили пользовательских сегментов. Благодаря этому можно видеть картину целиком.

Проверка реальностью

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

1. Гипотеза об автоматизации «из коробки». 

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

2. Гипотеза о размере рынка. 

Один из сегментов казался крупным. Интервью показали, что значительная часть целевой аудитории решает задачу через аутсорс и не является покупателем продукта. Это существенно сузило реальный рынок. Лучше узнать это на этапе исследования, чем после запуска.

3. Гипотеза «все хотят цифровизацию». 

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

Что оказалось неожиданным

Доступ к респондентам. Ожидалось, что договориться на часовое интервью с руководителями в консервативной отрасли будет сложно. На практике — наоборот. Люди, которые каждый день сталкиваются с нерешённой проблемой, готовы говорить о ней. Главное — показать, что цель разговора — разобраться в предмете, а не продать «универсальное решение».

Конкурентное окно. При анализе ключевых игроков в целевой отрасли выяснилось, что подобных решений на рынке нет. Существующие продукты закрывают смежные задачи — документооборот, управление проектами, учёт — но не те, которые мы собирались взять за основу при разработке.  Несколько респондентов подтвердили это независимо друг от друга. Это одновременно вдохновляет и вызывает опасения: инновационное решение может долго оставаться непонятным, прежде чем станет нормой.

Советы для тех, кто запускает продукты на основе языковых моделей

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

Проверяйте гипотезы, не доверяйте им. Часть гипотез не подтвердится, часть подтвердится с существенными уточнениями. Каждая неподтверждённая гипотеза — это сэкономленные ресурсы.

Предметная область важнее модели. Заказчику неважно, какая технология используется под капотом. Ему важно, что продукт понимает его терминологию, нормативы, логику процессов и форматы документов. Перед исследованием в незнакомой отрасли стоит потратить 2–3 дня на погружение: прочитать нормативку, разобрать пример реального документа, поговорить с кем-то неформально. Это окупается.

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

Вывод

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

Эти исследования помогли нам запустить «Наполеон Документы» — платформу для интеллектуальной обработки документов, которая читает, проверяет и сверяет документы так, чтобы решения принимались за минуты. Платформа распознаёт любые форматы — сканы, PDF, фотографии с телефона и автоматически извлекает ключевые данные из договоров, актов, УПД, кредитных досье и других документов. «Наполеон Документы» сверяет цифры и условия между связанными документами, сигнализирует о расхождениях и проверяет комплектность пакета ещё до отправки на согласование, а также может генерировать новые документы на основе обработанных данных. Каждая из этих функций выросла из конкретной жалобы, услышанной на интервью.

Живые разговоры с людьми, которые каждый день сталкиваются с проблемой, дают то, чего не даёт никакая аналитика: понимание разрыва между «было бы удобно» и «я готов за это платить». Именно этот разрыв определяет, будет ли у продукта будущее.

[
предыдущая
]
Как принимать LLM-проекты: почему чек-листы больше не работают
[
следующая
]
LLM в бизнесе: варианты использования больших языковых моделей
Мы используем cookies. Продолжая просматривать сайт, вы соглашаетесь с этим. Узнать больше
OK
обсудить проект
обсудить проект