Как проверить идею ИИ‑инструмента до разработки

Сведите идею к одному действию

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

Такая формулировка отвечает на три вопроса сразу: кто пользователь, в какой момент он обращается к инструменту и что именно получает. Если хотя бы на один ответа нет, разработку начинать рано.

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

Проверьте спрос раньше, чем напишете код

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

Что выясняется в этот день:

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

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

Стабильность важнее лучшего ответа

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

Проверьте три свойства:

• Повторяемость. Отправьте один и тот же запрос десять раз. Насколько расходятся ответы и приемлем ли этот разброс для вашего сценария.
• Поведение на краях. Пустой ввод, обрывок текста, текст в десять раз длиннее обычного, другой язык, опечатки, противоречивые данные. Инструмент должен предсказуемо отказываться, а не выдумывать.
• Воспроизводимость во времени. Закрепляйте конкретную версию модели, а не общее имя: общее имя указывает на текущий выпуск и меняется вместе с ним. Но и закреплённая версия не вечна. Anthropic, например, предупреждает о снятии модели минимум за 60 дней, после чего запросы к ней перестают выполняться. Дату окончания поддержки стоит внести в план так же, как срок действия договора.

Соберите набор примеров вместо впечатлений

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

Набор решает четыре задачи:

1. Даёт число вместо ощущения: доля приемлемых ответов на фиксированной выборке.
2. Позволяет сравнивать варианты — модели, формулировки запроса, способы подготовки данных — на одних и тех же случаях.
3. Ловит ухудшения после любых изменений, включая обновление модели на стороне поставщика.
4. Делает разговор о качестве предметным. «Стало хуже» превращается в «доля приемлемых ответов упала с восьмидесяти двух до шестидесяти процентов».

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

Посчитайте стоимость и задержку

Стоимость одного обращения умножается на частоту. Инструмент, который стоит копейки на демонстрации, может стать заметной статьёй расходов при тысяче обращений в день.

На что смотреть:

• Цена одного обращения с учётом реальной длины входных данных, а не короткого примера.
• Частота обращений в пиковый день, а не в среднем за месяц.
• Возможность обрабатывать простые случаи дешёвым способом, оставляя дорогой только для сложных.
• Задержка ответа. Три секунды приемлемы для черновика письма и неприемлемы для подсказки, которая должна появляться во время набора текста.

Определите границы и безопасность

До запуска ответьте на несколько вопросов, каждый из которых потом обходится дороже:

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

Что считать готовностью

Инструмент готов к выпуску, когда выполнены пять условий:

1. Набор примеров проходит с заранее согласованной долей приемлемых ответов.
2. Есть способ узнать о поломке раньше пользователя.
3. Есть откат: понятно, как люди работают, если инструмент недоступен.
4. У инструмента есть владелец, а не только автор.
5. Записано, что именно он не делает. Список ограничений экономит больше времени, чем список возможностей.

Инструмент отличается от демонстрации тем, что его поведение известно заранее.

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