Выберите тему — соберём контекст
Формулируем гипотезу в проверяемом виде, договариваемся о метрике до написания кода, собираем прототип на ваших реальных данных и показываем результат на отложенной выборке. Если качество недостижимо — вы узнаёте об этом за месяц и без бюджета на полноценный проект.
Или сразу: +7 (962) 368-39-51 Telegram
Ошибки, из-за которых прототип впечатляет на презентации и разочаровывает в эксплуатации.
Команда показывает работающий прототип, заказчик смотрит на несколько примеров и говорит «вроде неплохо». Что означает «неплохо» — непонятно: 60% точности или 95%? Без числа, согласованного до старта, результат PoC невозможно ни принять, ни отклонить.
Отобранные вручную красивые документы и чистые изображения показывают потенциал технологии, но не её поведение на потоке. Реальные данные содержат мятые сканы, плохое освещение, нестандартные форматы — и качество на них отличается в разы.
Прототип живёт месяцами, обрастает доработками, в него вкладываются силы, и остановить его становится психологически невозможно. Это классический путь к проекту, который не имеет ни подтверждённой ценности, ни внятной архитектуры.
PoC показывает, что модель угадывает 92% случаев, но не отвечает на вопросы: кто разбирает оставшиеся 8%, сколько это занимает времени и как решение встроится в текущую систему. Без этих ответов переход в пилот превращается в новый проект.
Первая неделя уходит на согласование доступа, вторая — на выгрузку, и от четырёхнедельного срока остаётся полторы недели на собственно проверку. В результате либо качество не доводят, либо выводы делают на неполной выборке.
Четыре элемента, без которых проверка превращается в демонстрацию.
Переводим задачу в проверяемое утверждение с числовым порогом и способом измерения. Это самый короткий и самый важный этап.
Проверка идёт на фактических данных из ваших систем, включая «грязные» случаи, а не на отобранных вручную примерах.
Собираем минимально работающий конвейер: подготовка данных, модель, оценка. Без интерфейсов и интеграций — они не нужны для ответа на вопрос о качестве.
Заканчиваем не демонстрацией, а документом с цифрами и рекомендацией: что делать дальше и что для этого потребуется.
Четыре недели в стандартном случае, шесть — если данных много и требуется разметка.
Формулируем гипотезу, выбираем метрику, договариваемся о пороге успеха и о том, кто будет принимать решение по результату.
Получаем выгрузки, проверяем полноту и качество, при необходимости организуем разметку небольшой выборки вашими специалистами.
Собираем конвейер, пробуем несколько подходов, сравниваем с baseline на правилах, разбираем ошибки на конкретных примерах.
Фиксируем результат на отложенной выборке, оцениваем экономику и даём рекомендацию по пилоту — либо честный отказ от идеи.
Работающая гипотеза состоит из четырёх частей: данных, задачи, метрики и порога. Пример: «на истории обращений за 18 месяцев модель классификации тем достигнет точности не ниже 85% на отложенной выборке, при этом доля обращений, требующих ручного уточнения темы, не превысит 12%». Такая формулировка проверяема: по её окончании можно однозначно сказать, достигнут результат или нет.
Плохая гипотеза звучит как «внедрить AI-классификатор обращений» или «повысить качество обработки». Их нельзя проверить, потому что нет ни метрики, ни способа измерения. Часто оказывается, что заказчик и исполнитель по-разному понимают даже саму задачу — например, один имеет в виду маршрутизацию по отделам, а другой — определение приоритета. Формулировка гипотезы выявляет такие расхождения до того, как они станут дорогими.
Отдельно договариваемся о критерии остановки. Это значение метрики, ниже которого проект не имеет смысла: например, если точность классификации не превышает 70%, ручной разбор займёт больше времени, чем сейчас, и экономика не сойдётся. Наличие такого порога защищает обе стороны от проекта, который тянется без шансов на результат.
Самый распространённый способ обмануть себя — случайно разделить данные на обучающую и тестовую части. Если документы или транзакции из одного месяца попадают и туда, и туда, модель фактически видит почти те же примеры, что и при обучении. Метрика получается высокой, а на новых данных качество падает.
Мы всегда разделяем выборку по времени: обучаемся на более раннем периоде, проверяем на более позднем. Это честнее отражает реальность, в которой модель будет работать на данных, которых ещё не существовало в момент обучения. Если данных мало, используем скользящую схему проверки: несколько последовательных окон обучения и проверки, результат усредняется.
Дополнительно проверяем стабильность: качество по месяцам и по сегментам. Если в среднем метрика хорошая, но в одном сегменте провал, это важно знать до пилота. Часто выясняется, что модель отлично работает на типовых случаях и плохо — на тех самых сложных, ради которых проект и затевался.
Отчёт по PoC — это не презентация с примерами удачных срабатываний, а документ, по которому можно принять решение. В нём есть зафиксированная ранее метрика и фактическое значение на отложенной выборке, причём с разбивкой по сегментам. Есть сравнение с baseline: правилами, ручной работой или текущей системой. Есть разбор ошибок с конкретными примерами и объяснением, какие случаи система путает и почему.
Далее — экономика. Оценка доли случаев, которые уйдут на ручной разбор, стоимость одного прогноза и предположительные расходы на сопровождение. Эти цифры ещё неточные, но они позволяют понять порядок величин и не строить пилот на заведомо убыточной основе.
И последняя часть — план пилота: на каком объёме, в каком процессе, с какой контрольной группой, в какие сроки и по какой метрике будет измеряться эффект. Если PoC дал отрицательный результат, отчёт всё равно ценен: он объясняет, почему направление закрыто, и сохраняет эти выводы для будущих попыток, когда появятся данные или изменятся технологии.
PoC отвечает на вопрос «достижимо ли нужное качество на наших данных» и проводится вне бизнес-процесса: готовим данные офлайн, модель обучаем, метрики измеряем на отложенной выборке. Пилот отвечает на вопрос «работает ли это в реальном процессе» и включает интеграцию, пользователей, контрольную группу и измерение эффекта. Смешивать их нельзя: если пытаться делать и то, и другое сразу, сроки растягиваются, а критерий успеха размывается.
Обычный срок — четыре недели, при большом объёме данных и необходимости разметки — до шести. Стоимость зависит от сложности задачи и объёма подготовительных работ, но принципиально она на порядок ниже полного проекта, потому что не включает интеграцию, интерфейсы и вывод в эксплуатацию. Мы всегда называем фиксированную сумму и фиксированный срок до начала работ.
Это нормальный и полезный исход: вы потратили месяц вместо года и сохранили бюджет. В отчёте мы объясняем, чего не хватило — данных, разметки, качества изображений. Часто задача решается не отказом от идеи, а изменением подхода: сужением класса задач, улучшением съёмки, накоплением истории. Иногда вывод состоит в том, что задачу дешевле решить правилами, и это тоже результат.
Код прототипа обычно не переносится в продакшен напрямую: он написан для скорости проверки, а не для надёжности. Но результаты переносятся полностью — подготовка данных, подобранная архитектура модели, значения метрик, понимание сложных случаев. На пилоте мы переписываем конвейер в промышленном виде, уже зная, какое качество достижимо и где находятся основные риски.
Смежные задачи, которые обычно решаются в одном проекте с этой.
Опишите задачу и покажите образцы данных — сформулируем гипотезу с числовым критерием и проверим её на вашей выборке за несколько недель.
Cookie и аналитика
Мы используем необходимые cookie для работы сайта и форм. Аналитические cookie (Яндекс.Метрика, включая запись сессий) подключаем только с вашего согласия — от него можно отказаться. Подробнее: Политика использования cookie и обработка персональных данных.