ИИ внедрили, а денег всё нет: 5 распространенных ошибок при работе с технологическими продуктами в 2026 году

— Я запускал карпулинг (совместные поездки на личном автомобиле, когда водитель и пассажиры с общим маршрутом делят расходы на бензин и дорогу. — Прим. ред.) в «Ситимобил», где алгоритмы подбирали попутчиков с пересекающимися маршрутами, чтобы поездка была дешевле, а водитель не терял заработок.

— В это же время я развивал Radlogics, ИИ-платформу для анализа КТ-снимков, которая помогала врачам быстрее проводить исследования и не пропускать патологии.

Затем мы поступили на MBA (Master of Business Administration — магистр делового администрирования. — Прим. ред.) в UCLA Anderson School of Management (Школа менеджмента Андерсона, Калифорнийский университет в Лос-Анджелесе. — Прим. ред.) и год занимались исследовательским проектом на стыке ИИ и робототехники: изучали, как беспилотные роботы в сельском хозяйстве могут обмениваться данными и координировать работу в поле. Мы знаем, как искусственный интеллект действует не только в цифровых продуктах, но и в физическом мире, —управляет техникой, складами, потоками данных с датчиков. Поэтому затем мы пошли в компании, где ИИ ежедневно управляет тысячами физических операций и цена ошибки стремится в космос. Так мы оказались в Walmart и Amazon, где создаем продукты с искусственным интеллектом, и готовы поделиться наработанным опытом.

— Когда мы начинали работать с большими языковыми моделями, хотелось встроить их в каждый процесс. Я тогда управлял корпоративными поездками, логично было делегировать агенту составление отчетов. Это автоматизировало документацию, но на тот момент модель не была готова полноценно отвечать на вопросы, а корпоративные клиенты требовали максимальной включенности.

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

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

Мы поняли, что главный вопрос на старте должен звучать иначе: «Какой рабочий процесс мы хотим улучшить прямо сейчас?» Надо понять:

• как сократить время поиска информации;

• как уменьшить число ошибок в заявках;

• как разгрузить поддержку.

Еще один пример переоценки ИИ из работы в американском ретейле. Мы готовили продвинутую модель для распознавания документов для приема товара. На стадии подготовки нам казалось, что грядет революция для линейного персонала. Но в работе модель стала дописывать данные, которых в документе не было. Это называется галлюцинации — и чем более интеллектуальна модель, тем они выглядят увереннее. Ошибки в расчетах уходили дальше по цепочке к другим отделам, появились проблемы с закупками.

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

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

— Например, в VK Cloud я тестировал агента для клиентского B2B-сервиса в сфере сервисных решений. На тестовых запросах ассистент хорошо подбирал ресурсы и программы для клиента, а в реальности клиенты использовали ИТ-диалект, ошибались в словах, и сами не знали, что хотят. Агент учитывал только часть условий и предлагал конфигурацию, которая формально подходила, но ей было далеко до среднего клиентского менеджера. Затем мы переобучили модель с помощью новых данных и результаты были намного лучше.

Опыт показал, что качество нужно проверять перед запуском на сложных кейсах (с опечатками, с нестандартными названиями, с пробелами в данных, с узконаправленными подтемами и с ловушками на темы, которых вообще нет).

Как мы это исправили.

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

• Перешли на масштабирование частями, отдельно отслеживаем редкие сценарии (они могут потеряться в среднем качестве). Новую версию продукта сначала получает одна команда, затем 5% пользователей, затем 25%, и только после них — остальные, с заранее заданным критерием отката на каждом шаге.

• Ввели правило пересборки набора кейсов при каждом обновлении модели (раз в несколько месяцев).

— Во время пандемии я руководил продуктом в Radlogics, и мы делали ИИ-агента для анализа результатов КТ. Коронавирус делал разработку крайне актуальной, я летал по России и интегрировал систему в сотни клиник. Но мы не сразу учли, что появлялись новые штаммы вируса, и модель стала ошибаться. Позже мы это заметили и исправили, научившись при этом переосмысливать работу модели с каждым обновлением.

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

У Claude Haiku это $1 против $5 за 1 млн токенов, у Claude Opus $5 против $25, у GPT-5.6 $5 против $30. Считаешь по входным — занижаешь бюджет в разы.

К тому же у рассуждающих моделей внутренние «размышления» тоже оплачиваются как выходные токены, то есть по самому дорогому тарифу. Разрыв в цене между моделями доходит до 100 раз — Gemini Flash-Lite стоит $0,1 за миллион входных токенов, Claude Fable 5 — $10, при том что большинство запросов к ассистенту простые. А пользователю вообще не нужен токен: ему нужен ответ на вопрос.

Вот что мы делаем, чтобы расчеты были объективными.

• Разбиваем входные и выходные токены, суммируем все вызовы и делим на долю успешно закрытых задач. Типичный вопрос про наличие товара — это около десяти вызовов, примерно 30 тыс. входных и 5 тыс. выходных токенов: на Claude Haiku вход стоит 3 цента, выход — 2,5 цента, итого 5–6 центов. Та же задача на флагмане выйдет около 30 центов.

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

• Сокращаем контекст — мы перестали отправлять всю историю переписки в каждый вызов, оставили короткое резюме диалога.

• Поставили ограничения на стоимость модели и оповещения на лимиты. В Amazon действует следующий принцип: сначала выбирать самый простой и дешевый инструмент, который решает задачу, и усложнять решение только при необходимости. У нас несколько уровней защиты: потолок токенов на один запрос, дневной и месячный бюджет на сценарий, оповещение при 80% бюджета и автоматическое переключение на дешевую модель. Отдельный лимит на пользователя, чтобы один активный клиент не потратил весь бюджет.

— Даже качественно внедренный ИИ в проектах иногда дает неверные ответы. Особенно опасно это в клиентских продуктах, финансах, поддержке и операционных процессах. Например, в январе 2025 года Apple приостановила ИИ-сводки новостных уведомлений после жалобы BBC: на масштабе миллионов устройств функция начала искажать заголовки и приписывать изданиям то, чего они не писали.

Автоматизируем смело только там, где ошибку можно дешево исправить — например, при подготовке черновиков текста. Что еще сделали:

• собрали эталонный набор из сотни реальных случаев с правильными ответами, специально включили самые неудобные;

• зафиксировали порог качества для запуска: не дотянули, значит не масштабируем, даже если сроки горят;

• составили реестр решений, которые принимает или готовит система, и разметили их по цене ошибки: что можно исправить дешево, а что — необратимо;

• завели еженедельную сверку прогноза с фактом, где причину сначала ищем во входных данных, а не в алгоритме.

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

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

Теперь мы выстраиваем единый вход для всех ИИ-проектов:

• общие сервисы доступа и безопасности;

• проверка соответствия внутренним правилам;

• оркестрация;

• контроль расходов.

Команды по-прежнему отвечают за свои данные и прикладные сценарии.