Сопротивление воздуха: почему дешевый ИИ обходится так дорого

Я Алексей Арустамов, директор компании‑разработчика low-code платформы продвинутой аналитики.

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

Я замечаю это потому, что через мои руки прошло достаточно проектов, успешных и провальных, поэтому я неплохо представляю, как выглядит реальное внедрение изнутри. Мы более 25 лет занимались сложной аналитикой, где нейросети и машинное обучение уже были привычными рабочими инструментами, и уже несколько лет внедряем ИИ в реальные бизнес-задачи клиентов — от очистки данных до автоматизации поддержки. Поэтому я знаю, что за кадром остается то, что и определяет реальную цену: ИИ-генерация стоит копейки в сравнении с бюджетом традиционной разработки, но одна-единственная галлюцинация может подорвать доверие клиента и прибавить работы юристам; модель генерирует ответ очень быстро, а бизнес-процесс, который она «оптимизировала», придется восстанавливать, возможно, несколько дней. Что-то мне подсказывает, что если такую рекламную генерацию превратить в ТЗ, останется только подсчитывать, во сколько раз вырос бюджет проекта.

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

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

Издержки, которых нет в демо

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

Апологеты «чистого» ИИ предлагают нам летать над Землей как в вакууме. Они недоумевают, почему их решения не работают в проде. А не работают они потому, что в реальной атмосфере, где есть сопротивление среды в виде 152-ФЗ, жестких бизнес-процессов, таймаутов и клиентов, которые уходят после череды ошибок, — наш «самолет» начинает гореть.

Давайте разберем, из чего состоит эта «атмосфера». 

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

• Один и тот же промпт сегодня возвращает валидный JSON, завтра может вернуть что-то другое. Формат плавает, парсер падает, и в результате инженеры тратят часы на написание жестких схем валидации.

• Модель может случайно «проболтаться» персональными данными. Этот риск далеко не теоретический: Роскомнадзор уже выносит предписания за передачу ПДн в публичные нейросети. Штрафы по 152-ФЗ за утечки уже достигают 10–15 млн рублей, а с мая 2025 года действуют оборотные штрафы до 3% от выручки. 

• Модель не знает регламентов и поэтому может «оптимизировать» решение и с легкостью потерять обязательный шаг, например, запись в БД или отправку уведомления в службу безопасности, потому что для нее условие «отправить уведомление» — это просто текст, а не обязательное действие с юридическими последствиями. А учитывая локальную оптимизацию, обязательные шаги вне промпта для модели не существуют. На выходе мы получаем не только несогласованные данные и невозможность провести аудит, но и нарушение compliance и связанные штрафы, и даже разрывы бизнес-процессов, потому что пропущенные шаги не фиксируются.

• Модель стремится максимизировать заданный KPI, игнорируя здравый смысл, например, отправляет десятки пушей в день ради «вовлеченности». В результате вы теряете не копейки за отправку, а клиента, который просто «прибивает» или банит назойливое приложение.

• Модель может «оптимизировать» договор и выкинуть оговорку о форс-мажоре, потому что у нее нет концепции цены ошибки, а разгребать последствия придется юристам.

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

Недавно мы делали проект по очистке клиентских данных.

Казалось бы — идеальная задача для ИИ.

Сначала мы попытались обойтись регулярками и жесткими правилами, но не вытянули из-за слишком большого объема неформатного текста. Тогда решили: нафиг правила, давай все на ИИ. Запустили на реальном объеме и замерили скорость: в темпе «чистой» модели процесс, который занимал один день, растягивался на два месяца. В 50 раз медленнее! Разумеется, ждать два месяца никто не стал — эксперимент мы свернули.

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

Мы ожидали, что правила будут делать свое дело, а модель — свое. Но оказалось, что части усиливают друг друга.

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

Вот тогда мы окончательно убедились, что «чистый» ИИ в корпоративных задачах — это «корабль», спроектированный для «вакуума», который развалится при входе в «атмосферу». 

Что делает ИИ, а что — не ИИ

Мы постарались сформулировать для себя правило для использования ИИ: мы стараемся делать жестко все, что можно формализовать и где цена ошибки высока, а все, что требует интерпретации, языка и вариативности — отдаем модели. Я убежден, что граница должна проходить именно так — не по принципу «что моднее», а по цене ошибки и степени вариативности. Чтобы было нагляднее, вот как мы в компании распределяем обязанности между моделью и жестким контуром в реальных задачах: 

Получается, ИИ не удаляется из системы, а занимает свое место — там, где нужна творческая составляющая. Вокруг ИИ строится жесткая обвязка (часто собранная на Low-Code или классических пайплайнах), которая «бьет» ИИ по рукам там, где «руки» тянутся нарушить процесс.

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

Да, именно так. И издержки, судя по всему, это не баг, а фича. Устранить их нельзя, но можно перенести. Куда? Этот ответ я нашел в экономике — о нем ниже.

Почему издержки не исчезают

К концу XIX века экономисты-неоклассики — Вальрас, Маршалл, Парето — довели до математической безупречности идеальные модели рынка, в рамках которых все транзакции проходили как по-маслу: нашел, договорился, получил, не затратив каких-либо дополнительных ресурсов (frictionless transaction). Но в реальности они не работали идеально, потому что в таких моделях жил homo economicus — человек, который принимает решения без издержек. Кстати, именно эти модели и посыпались в XX веке.

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

В 1991-м, через 54 года, за эту мысль ему дали Нобелевку. Потому что оказалось: игнорировать транзакционные издержки — все равно что игнорировать трение в физике.

Позднее экономисты Дуглас Норт и Джон Уоллис показали: транзакционные издержки в принципе неустранимы: они не исчезают, они перемещаются.

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

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

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

Жесткое и мягкое: «композитный» ИИ

Этот поиск баланса между жестким контуром и вариативной моделью мы в итоге назвали композитным подходом. К тому времени я уже видел достаточно наших систем, чтобы заметить повторяющуюся картину: внутри всегда две принципиально разные части: жесткую, куда на входе подал «барана», а на выходе получил «колбасу» (и ни разу «мотоцикл»), и мягкую, где работает ИИ. 

Но примирить эти две части в голове у меня долго не получалось. Они противоречат друг другу, и я постоянно спотыкался об это противоречие. Выглядело это как тупик: усилить обе стороны сразу нельзя, отказаться от любой из них — тоже. Я долго крутил это в голове и не мог подобрать слово для того, что получается на пересечении. Говорил «обвязка», «каркас», «то, что бьет по рукам» — но это были названия частей, а не целого.

А потом я стал замечать, что мы не одни с этой идеей.

Я прочитал работу исследователей из Intel Labs, представленную на ICML 2025. Они заходят совсем с другой стороны — изучают безопасность моделей. И приходят к тому же: ни один инструмент безопасности не дает достаточных гарантий в изоляции. Нужна композиция разнородных методов, которые покрывают слабости друг друга. Они называют это Composite AI Safety. И хотя они думают про безопасность модели, а мы про архитектуру бизнес-процесса, но принцип рифмуется: один инструмент не решает.

Чтобы математически доказать эффективность своего подхода, авторы работы взяли классическую задачу компьютерного зрения — детекцию объектов. И посмотрите на результаты:

• YOLOv8: 0,068 млрд параметров, 71,5 FPS, AP на LVIS = 7,1

• Florence 2: 0,822 млрд параметров, 2,9 FPS, AP на LVIS = 2,3

• Gemini 2.0 Flash: AP на LVIS = 4,9

• GenerateU: 0,896 млрд параметров, 1,5 FPS, AP = 25,5

Компактный специализированный детектор (YOLO) — в 12 раз меньше и в 25 раз быстрее — обходит большие генеративные модели на конкретной задаче. И делает он это не потому что «умнее», а потому что не пытается быть всем для всех.

Но настоящий прорыв показывает GenerateU: модель, в которой детекционная сеть соединена с языковой (т. е. жесткая специализация плюс язык), — гибрид. 

Я для себя это понял так: универсальный “мозг” хорош в демо, а в конкретной задаче выигрывает конвейер с одной творческой вставкой, т. е. жесткость там, где нужна жесткость, и вариативность там, где без нее нельзя.

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

И если что-то можно сделать детерминировано, нет смысла перекладывать это на ИИ и надеяться, что модель «догадается» сделать правильно. Зачем, например, объяснять модели правило, что нельзя давать кредиты несовершеннолетним (за что может прилететь), если это можно явно прописать? В одном случае мы надеемся, что модель правильно поймет, а в другом полностью уверены, что всё верно. Если уж учитывать издержки, то совершенно непонятно, ради чего увеличивать риск?

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

Цена архитектурного компромисса или кто платит за галлюцинацию?

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

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

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

Почему так много вопросов именно по безопасности ИИ, особенно когда речь идет об агентах? Разве люди не ошибались? Конечно, ошибались! Но дело в том, что прежде сотрудник вместе с правом принятия решений получал в комплекте и ответственность за них. Есть конкретные способы воздействия, вплоть до уголовных. А в случае применения ИИ-агентов возможность выполнять действия появилась, но ответственность за последствия повисла в воздухе.

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

Вместо заключения

В этой статье я пытался собрать в кучу и систематизировать свои мысли и полученный опыт. Мы решили, что можем контролировать издержки за счет обвязки: валидации, логирования, фолбэков, таймаутов и маршрутизации. Расскажите, как все устроено у вас? Какой процент строк кода в вашем ИИ-проекте — это сама модель, а какой — обвязка? Где вы провели границу между тем, что отдаете модели, и тем, что оставляете в детерминированном конвейере? Что оказалось самым дорогим — не в деньгах за токены, а в днях, людях и нервах? А может у вас есть своя история о том, как «бесплатный» ИИ оказался совсем не бесплатным?