Три минуты до черновика — и неизмеренные часы на проверку.
Три минуты вместо тридцати. Это измерение стоит в центре почти каждого бизнес-кейса по ИИ, который я видела, и это не то число.
Лучшая его версия пришла сразу с опровержением внутри. Имтеазу Ахамеду из Reckitt, в разговоре о генеративном ИИ в товарах повседневного спроса, нужно было объяснить многорукие бандиты руководителю. Он попросил у ChatGPT объяснение, потом промпт для Midjourney, потом сгенерировал картинку. Три минуты. Без помощи — около тридцати. Совсем новый аналитик — двадцать.
И тут же, на том же дыхании, стандарт, который он на самом деле применяет к результату: вы когда-нибудь просили джуна выгрузить данные? Хорошая отправная точка, а дальше надо разбираться, что там внутри.
Три минуты — это время до черновика. Не время до того, что можно показать клиенту.
Я пошла искать того, кто не согласен, и не нашла. Брайан Гилденберг, ведущий того же разговора, превращает это в вопрос про адаптацию сотрудника: вы же не дадите новичку действовать «сразу, без взрослого присмотра». Юджин Ян описывает лестницу проверки — сначала дешёвое и детерминированное, потом дорогое и оценочное — и в другом месте доказывает, что LLM-судья продукт не спасёт, потому что провал в процессе вокруг судьи, а не в судье. Анита Уоткинс из Insights Association ограничивает синтетических респондентов стадией, а не качеством. Чарльз Чейз из SAS встроил человеческую проверку прямо в продукт.
Разные словари, одна позиция: проверка обязательна, а живой спор идёт только о том, как сделать её дешёвой. Ровно здесь и лежит денежный вопрос, и туда не заходит никто из них.
Два столбца, а не один
| Время до результата | Время до проверенного результата | |
|---|---|---|
| Слайд про многорукие бандиты | 3 мин | ? |
| ваш сценарий |
Каждый бизнес-кейс, который я читала, заполняет левый столбец. Правый не заполнил ни один.
Арифметика хуже, чем кажется. Допустим, проверка занимает двенадцать минут. Против базы в тридцать минут это экономия 50%, а не 90% со слайда. И она не масштабируется: проверить десять результатов не в десять раз легче, чем их создать, — дорогая часть проверки в том, чтобы загрузить контекст, а загружаете вы его каждый раз заново. Где-то эта кривая загибается. Где именно, никто не публиковал.
В этом же и честный предел всего, что ниже. Во всей этой истории существует одно измерение, и оно покрывает один слайд. Направление, а не величина. Считать по нему экономию я бы никому не позволила.
Три способа удешевить проверку
Расставьте проверки по цене. Детерминированные тесты раньше оценочных.
У детерминированного теста есть один правильный ответ и никакого мнения о нём. Разбирается ли JSON. Сходятся ли столбцы в итог. Есть ли этот SKU в справочнике. Попадает ли дата в отчётный период. Он выполняется за миллисекунды, ничего не стоит запустить снова и каждый раз выносит один и тот же вердикт.
Оценочная проверка требует, чтобы кто-то составил мнение. Точен ли этот пересказ. Разумна ли эта рекомендация для этого клиента. Звучит ли это как мы. Это человеческое время либо ещё один вызов модели плюс человек, выборочно её проверяющий, — и в обоих случаях это дорогой столбец.
Гоняйте дешёвые первыми, и дорогие увидят только то, что выжило. Это снижает стоимость обязательной проверки, а не отменяет её. А когда оценочная проверка проваливается, виноват почти никогда не инструмент, который оценивает, — виноват процесс вокруг: разметка, гипотеза, эксперимент, и всё это человеческая работа, за которую кто-то платит.
Проводите границу по последствиям, а не по точности. Пускайте машину туда, где ошибка обратима; оставляйте человека в контуре там, где нет. Ответить на это гораздо дешевле, чем на «достаточно ли хороша модель», потому что обратимость — свойство решения, и вы знаете его ещё до старта.
Сделайте проверку обучающим сигналом. Система планирования, которая учится на исторических правках самого планировщика, не выводит его из контура — контур и есть вход. Проверка перестаёт быть накладными расходами ровно в тот момент, когда начинает накапливаться.
Куда на самом деле уходят деньги
Вот часть, которая мне важна, и она моя, а не чья-то ещё.
Если проверка обязательна и стоит денег, ценность возникает не там, где модель быстрее. Она возникает там, где проверка дешевеет. А это переносит вложения с модели на леса вокруг неё:
- Сначала детерминированные тесты. Всё, что ловится регуляркой, проверкой схемы или суммой, не должно доходить до человека.
- Узкий формат вместо свободного текста. Структурированное поле проверяется за секунды. Абзац надо прочитать.
- Прослеживаемая ссылка на источник. Большая часть времени проверки уходит на выяснение, реально ли утверждение. Если результат несёт своё происхождение, это время схлопывается.
Доведите мысль до конца — и получите неудобный вывод. Модель, которая на 5% лучше по бенчмарку и отдаёт свободный текст, проигрывает худшей модели, отдающей проверяемую структуру. Говорить такое поставщику непопулярно, и на переговорах о закупке я этого не слышала ни разу.
Аналогия с джуном тянет слишком много
К ней тянутся все, и я тоже. Это аналогия, а не измерение.
Никто не показал, что ошибки модели распределены как ошибки младшего аналитика. Подозреваю, что они реже и опаснее: приходят с большей уверенностью и без опознавательных знаков. Заминка, оговорка, «вы это имели в виду?». Джуна вы научитесь читать за месяц. Здесь читать нечего.
Для второго столбца это важно: проверка, откалиброванная по тому, как часто ошибается джун, будет откалибрована неверно.
Проверка
Один вопрос, и он помещается в любой разбор бизнес-кейса:
Где второе число?
Если его нет, кейс не посчитан. Он нарисован.