За 48 часов можно проверить идею, но не доказать, что она окупится

«За 48 часов команда создала работающий прототип» звучит эффектно. Что на самом деле стоит за этой фразой?

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

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

Директор управления SMB и Digital «Софтлайн Решения» (ГК Softline) Иван Крутько
Фото: ГК Softline

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

Последний пункт я считаю самым недооцененным. За 48 часов какие-то части решения неизбежно заменяют заглушками, то есть временными упрощениями. Если команда сама показывает эти места, видно, что она понимает ограничения своего прототипа. А если заглушку находят при проверке, возникает вопрос, что еще осталось за кадром.

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

Демо, прототип, MVP, промышленная система: эти понятия нередко путают. Где между ними граница?

Путаница начинается, когда результат одного уровня оценивают по меркам другого. Например, от опытного образца ждут надежности промышленной системы, а презентацию принимают за работающий продукт. Хотя на самом деле демо, прототип, MVP и промышленная система отвечают на четыре разных вопроса.

Демо, то есть презентация, видео или макет интерфейса, объясняет, что предлагается и зачем, но доказать, что заявленный процесс действительно выполняется, оно не может. Для этого нужен прототип, или PoC: работающий «движок» без внешней отделки. Его командам и предстоит собрать на хакатоне. Прототип показывает, справляется ли выбранный подход с конкретной задачей в заданных условиях. Проверяют его на нескольких примерах, поэтому пока неизвестно, как он поведет себя на реальном потоке задач компании. Защита от взлома, устойчивость к массовой нагрузке и проработанный дизайн появятся позже, на этом этапе их никто и не обещает. А вот правила безопасной работы с данными действуют уже на хакатоне.

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

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

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

Двух суток хватит на что-то серьезное? Что можно успеть проверить?

Хватит, если правильно поставить вопрос. «Работает ли ИИ в нашей компании?» - за двое суток этого не выяснит никто. Зато можно проверить конкретные гипотезы, например, техническую: удается ли извлечь нужные поля из документов заказчика, найти ответ в его базе знаний, классифицировать обращения. Или архитектурную: какой из нескольких подходов лучше справляется с выбранным сценарием.

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

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

Сравнивать нужно результат одной и той же задачи в сопоставимых условиях. Число агентов, сложность архитектуры и выбор конкретной ИИ-модели сами по себе ничего не решают. Важно, что решение делает и чего это стоит.

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

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

Что за 48 часов проверить невозможно в принципе и какие вопросы заказчику придется решать уже после хакатона?

За два дня нельзя подтвердить эффект, который проявляется только через месяцы. Сколько часов сэкономят сотрудники? Снизится ли годовой отток клиентов? Вырастет ли прибыль? Это станет понятно не раньше пилота. Хакатон покажет другое: работает ли идея в принципе.

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

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

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

Хакатонные проекты часто так и остаются конкурсными. Что должно произойти, чтобы этого не случилось? И есть ли смысл в разработке, которая до внедрения не дойдет?

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

Для проектов, которые не займут призовых мест, предусмотрен «Путь к витрине»: организаторы отберут лучшие из решений, дошедших до рабочего состояния, команды доработают их до продукта и закрепят условия размещения отдельным договором. После этого проект можно будет разместить на витрине интернет-магазина экосистемы «Софтлайн Цифровой актив». Для меня это важная часть истории: хорошая разработка не должна теряться только потому, что на защите другая команда выступила сильнее.

Даже проект, который так и не дойдет до внедрения, принесет заказчику пользу. Он может показать, что данные для задачи непригодны, или обнаружить дорогую интеграцию раньше, чем на нее потратят бюджет. Может отсечь слабый подход, уточнить требования, дать возможность оценить команду в деле. Отрицательный результат за 48 часов обходится дешевле, чем тот же вывод через полгода проекта. По сути, хакатон дает бизнесу быстрый способ узнать правду о своей задаче до того, как в нее вложат серьезные деньги.

Автор: Иван Крутько, директор управления SMB и Digital «Софтлайн Решения» (ГК Softline)