PoC (proof of concept) отвечает на один вопрос: достижимо ли требуемое качество на ваших реальных данных. Он не должен быть красивым, интегрированным или функционально полным — его единственная задача дать основание продолжить или остановиться, пока вложено мало. PoC, который невозможно провалить, бесполезен: проверка имеет смысл, только если отрицательный результат заранее считается допустимым.
Чем PoC не является
Путаница с терминами обходится дорого, потому что от названия зависят ожидания и бюджет.
PoC — не демонстрация. Демо показывает, что технология в принципе умеет; PoC проверяет, справится ли она с вашей задачей на ваших материалах. Красивое демо на подготовленных примерах не говорит о вашем процессе ничего.
PoC — не MVP. MVP — это работающий продукт с минимальным набором функций, которым уже можно пользоваться. PoC пользоваться нельзя и не нужно: у него нет интерфейса, интеграций и обработки исключений. Требовать от PoC удобства — значит платить за то, что, возможно, будет выброшено.
PoC — не пилот. Пилот запускается в живом процессе и отвечает на организационный вопрос: пользуются ли решением люди. PoC отвечает на технический: получается ли нужный результат. Пилот идёт после PoC и стоит дороже.
Из этого следует главное правило: всё, что не помогает ответить на вопрос о достижимости качества, из PoC исключается. Интерфейс, авторизация, интеграции, обработка редких случаев — потом.
Критерий успеха формулируется до старта
Это ключевой пункт, который чаще всего пропускают. Если критерий не зафиксирован заранее, результат PoC оценивается впечатлением, а впечатление всегда подстраивается под уже принятое решение: заказчик, который хочет проект, увидит успех, а скептик — провал, глядя на одни и те же ответы.
Критерий должен отвечать на три вопроса:
- Что считается правильным ответом. Формулируется настолько конкретно, чтобы два разных человека, глядя на один ответ, одинаково его оценили. Если этого не может сформулировать даже опытный сотрудник, автоматизировать пока нечего — сначала нужно понять сам процесс.
- Какая доля ошибок допустима. Стопроцентная точность не бывает ни у модели, ни у человека. Вопрос в том, какой процент ошибок процесс переносит с учётом того, что результат проверяется.
- На какой выборке проверяем. Количество примеров и, что важнее, их происхождение.
Критерий фиксируется письменно до начала работ и не меняется по ходу. Изменение критерия после того, как увидели результат, — это уже не проверка, а подгонка.
Главная ошибка: проверка на идеальных данных
Самый распространённый способ провести бесполезный PoC — собрать выборку из показательных примеров. Логика понятна: хочется проверить на том, что точно должно работать. Результат такой проверки предсказуемо положительный и не значит ничего.
Причина в том, что реальный поток отличается от отобранного не количеством, а составом. В нём есть документы плохого качества, нестандартные формулировки, устаревшие версии регламентов, обращения не по теме и случаи, которые не предусмотрел никто. Именно на них решение и ломается, а в подготовленную выборку они не попадают по определению — их отсеяли, когда собирали «нормальные примеры».
Правильная выборка — случайный срез реального потока за период. Не лучшие примеры и не худшие, а обычные, со всеми дефектами. Часто именно на этом шаге и выясняется главное: что регламенты существуют в нескольких редакциях, а данные противоречат друг другу. Это неприятное, но крайне ценное открытие — сделанное до разработки, оно экономит проект.
Что входит в PoC и что не входит
Входит Не входит Ядро решения: получение ответа на реальном запросе Пользовательский интерфейс Случайная выборка реальных данных Интеграции с внутренними системами Замер качества по заданному критерию Авторизация и разграничение прав Замер размера контекста и ответа для расчёта стоимости Обработка редких сценариев Список обнаруженных проблем с данными Оптимизация скорости Оценка достижимого потолка качества Документация для пользователейПравая колонка не означает «не нужно никогда» — она означает «не нужно сейчас». Всё это появится, если PoC покажет, что продолжать имеет смысл.
Три исхода и что делать с каждым
PoC не бывает просто «успешным» или «неуспешным». Практически всегда результат — один из трёх.
Качество достигнуто. Критерий выполнен на случайной выборке. Проект переходит к расчёту экономики и пилоту. Важно не переоценить результат: качество на выборке — это верхняя оценка, в живом потоке оно обычно немного ниже.
Качество недостижимо из-за данных. Самый частый исход, и он не отрицательный. Модель не может ответить правильно, потому что правильного ответа нет в материалах: документы устарели, противоречат друг другу или не содержат нужной информации. Проект не закрывается, а меняет содержание — сначала приведение данных в порядок, потом ИИ. Как это делается — в статье «Подготовка базы знаний для ИИ».
Качество недостижимо по сути задачи. Требуется то, чего вероятностная система дать не может: юридически значимое решение без проверки, ответ там, где нет однозначно правильного ответа. Это честный отрицательный результат, и он стоит дёшево ровно потому, что получен на PoC. Задача либо переформулируется под то, что достижимо, либо снимается.
Отдельно стоит смотреть на характер ошибок, а не только на их долю. Ошибки, при которых система уверенно выдаёт неверный ответ, опаснее ошибок, при которых она честно отвечает «не знаю»: первые незаметны и потому дороже. Почему модель уверенно ошибается — разобрано в статье «Почему нейросеть выдумывает ответы».
Сколько длится и сколько стоит
PoC должен быть коротким по конструкции. Его смысл — быстро и дёшево снять неопределённость, и растянутый PoC теряет своё единственное преимущество. Обычно это недели, а не месяцы; если проверка занимает столько же, сколько разработка, значит, в неё включили лишнее.
Стоимость PoC несопоставимо ниже стоимости проекта, и правильно рассматривать её не как часть разработки, а как страховку от неё. Разумная схема работы с подрядчиком — оплатить проверку отдельным этапом с явным правом не продолжать. Заказчик покупает не решение, а обоснованный ответ на вопрос, стоит ли решение делать.
Когда PoC не нужен
Не каждая задача требует проверки. PoC можно пропустить, если:
- задача типовая и подрядчик уже делал такое на схожих данных — тогда проверка подтвердит известное;
- цена всего проекта сопоставима со стоимостью самого PoC — проверять дороже, чем сделать;
- решение собирается из готовых сервисов без обработки собственных документов.
Во всех остальных случаях — особенно когда система должна отвечать по вашим документам — PoC экономит больше, чем стоит.
Частые вопросы
Чем PoC отличается от пилота?
PoC отвечает на технический вопрос: достижимо ли нужное качество на реальных данных. Он проводится без интерфейса и интеграций, силами подрядчика, за недели. Пилот отвечает на организационный вопрос: работает ли решение в живом процессе и пользуются ли им сотрудники. Пилот идёт после PoC, требует участия людей и времени на накопление статистики.
Какого размера должна быть выборка для PoC?
Достаточной, чтобы доля ошибок была устойчивой, а не случайной, и обязательно случайной по составу. Гораздо важнее размера — происхождение: выборка должна быть срезом реального потока со всеми его дефектами, а не набором показательных примеров. Небольшая честная выборка полезнее большой отобранной.
Что делать, если PoC показал плохой результат?
Разобраться в причине, потому что причин три и решения у них разные. Если дело в данных — проект превращается в задачу их подготовки, после которой к ИИ можно вернуться. Если требование недостижимо по сути — задача переформулируется или снимается. Отрицательный результат PoC не провал, а сэкономленный бюджет разработки.
Можно ли делать PoC своими силами?
Можно, если есть кому: нужен человек, понимающий, как устроена работа модели с документами, и способный честно замерить качество. Основной риск самостоятельного PoC не технический, а методический — проверка на удобной выборке и оценка результата впечатлением. Если критерий зафиксирован заранее, а выборка случайна, своими силами PoC вполне реален.
Нужно ли включать в PoC интеграции с нашими системами?
Нет. Интеграции — это работа с предсказуемым результатом: она либо возможна, либо нет, и выясняется это изучением документации, а не экспериментом. PoC тратится на то, что нельзя предсказать, — на качество ответов. Включение интеграций в проверку увеличивает её стоимость и срок, ничего не добавляя к ответу на главный вопрос.
Что дальше
PoC — второй этап внедрения; общий порядок работ разобран в статье «Этапы внедрения ИИ в компании». Перед проверкой нужно выбрать процесс — «Как выбрать процесс для первого ИИ-проекта», а параллельно с ней считается экономика — «Сколько стоит эксплуатация ИИ-решения». Полная картина — в опорной статье «Внедрение ИИ в бизнес».
Проверка достижимости на ваших данных — это этап discovery в работе по разработке и внедрению ИИ; начать можно с аудита процессов.