Разрыв между ожиданиями CEO и реальностью разработки

Разрыв между ожиданиями CEO и реальностью разработки, image #1

Лид

Инженер смотрит на метрики: латентность 3500 мс, время ответа P95 — 8 с, стоимость запроса — $0,02. CEO смотрит на слайды презентации: «на базе ИИ», «прорыв», «смена парадигмы». Между ними — пропасть понимания, которую не преодолеть красивыми маркетинговыми терминами. Эта статья о том, что происходит, когда требования бизнеса встречаются с физикой серверов, счетами за облако и законами Мерфи.

Когда генеральный директор видит демо ChatGPT, он видит будущее: мгновенные ответы, автоматизация рутины, сокращение штата на 30%. Когда инженер-программист интегрирует ту же технологию в продакшен, он видит миллионы запросов по $0,02 каждый, таймауты, недетерминированные ответы и архитектуру, которая держится на честном слове и молитве.

Две реальности

Для бизнес-пользователя ИИ — это магия. Задаёшь вопрос — получаешь ответ. Что тут оптимизировать? Работает же.

Для разработчика ИИ — это:

  • Латентность: 2–5 секунд на простой запрос против 50 мс у обычного API
  • Стоимость: $10–100 за 1 млн токенов против практически нуля у собственных решений
  • Надёжность: 95% доступности по SLA у OpenAI против 99,99% у собственного бэкенда
  • Недетерминизм: один и тот же запрос выдаёт разные ответы

Математика не сходится

CEO слышит: «ИИ заменит программистов». Инженер считает: чтобы заменить младшего разработчика ($5 тыс./месяц), нужно сделать ~25 млн запросов к GPT-4. Это примерно 100 тыс. запросов в день. Один промпт-инженер на замену стоит не меньше.

Экономика масштаба работает в обратную сторону. Чем больше пользователей у вашей ИИ-фичи, тем быстрее вы разоритесь. Обычный софт масштабируется почти бесплатно — копии кода ничего не стоят. ИИ масштабируется линейно с каждым пользователем.

Производительность как она есть

Классический endpoint:

POST /api/user → 20 мс CPU, 5 мс БД → 25 мс суммарно

ИИ-дополненный endpoint:

POST /api/user + GPT → 20 мс CPU, 5 мс БД, 3500 мс ИИ → 3525 мс суммарно

Вы только что добавили 140-кратную задержку ради фичи, которую 80% пользователей не найдут. Но в квартальном отчёте это звучит как «функции на базе ИИ».

Кэширование не спасает

«Закэшируем ответы!» — скажет архитектор. Проблема: ИИ хорош именно тем, что даёт уникальные ответы на уникальные вопросы. Процент попаданий в кэш в реальных сценариях использования — 5–15%. Вы строите распределённый кэш на Redis для пользователей, которые всё равно будут промахиваться.

Латентность убивает UX

200 мс — предел, когда пользователь замечает задержку. 1 секунда — мысль «что-то тормозит». 3 секунды — «сломалось».

ИИ-фичи в продакшене — это всегда 3+ секунды. Можно добавить индикатор загрузки, скелетоны экранов, оптимистичный UI — но ощущение вялости никуда не девается. Особенно на мобильных устройствах с нестабильным интернетом.

Стоимость запроса: скрытая бомба замедленного действия

$0,02 за запрос кажется мелочью. Давайте посчитаем:

  • 100 тыс. ежедневных активных пользователей
  • 10 ИИ-запросов на пользователя
  • $0,02 × 1 млн запросов = $20 тыс./день = $600 тыс./месяц

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

Недетерминизм — ад при отладке

Традиционная разработка ПО строится на воспроизводимости. Баг → логи → воспроизведение → исправление.

С ИИ: баг → логи → попытка воспроизведения → другой ответ → тот же баг не воспроизводится → что фиксить?

Инженеры проводят часы в попытках понять, почему модель возвращает X вместо Y. Ответ: потому что случайность, температура, тонкие изменения в контексте. Это не инженерия, это экзорцизм.

Compliance и security — кошмар

CEO видит: «ИИ анализирует конфиденциальные данные». Юристы видят GDPR, HIPAA, SOC2.

Отправляете ли вы персональные данные в OpenAI? Где данные физически хранятся? Можно ли выполнить требование о забвении данных, когда модель обучалась на них? В обычном софте эти проблемы можно решить. С облачным ИИ остаётся только молиться и надеяться.

Порочный круг «добавим ИИ»

  1. Бизнес требует «добавить ИИ»
  1. Инженеры интегрируют GPT API
  1. Латентность растёт, стоимость растёт
  1. Бизнес требует «оптимизировать»
  1. Инженеры строят кэширование, батчинг, квантование моделей
  1. Качество падает, сложность растёт
  1. Бизнес требует «добавить ещё фичей»
  1. Возврат к шагу 2

Через год у вас команда из 5 человек занимается исключительно сопровождением и оптимизацией стоимости ИИ-фичи, которую используют 3% опытных пользователей.

Когда ИИ имеет смысл

Не всё плохо. ИИ работает в:

  • Помощь, а не замена: copilot, а не автопилот
  • Никсовые сценарии: code review, где «достаточно хорошо» — это ок

Проблема не в технологии. Проблема в том, что её применяют везде бездумно.

Разрыв в восприятии

CEO читает TechCrunch: «Компания X выросла на 50% благодаря ИИ». История молчит о том:

  • сколько они потратили на инфраструктуру
  • какая рентабельность выручки
  • что через год они уволили половину ИИ-команды после аудита расходов

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

Итог

ИИ не делает софт быстрее. Он делает его медленнее, дороже и менее надёжным. Взамен вы получаете возможности, которых раньше не было.

Вопрос не «добавить ли ИИ». Вопрос «стоит ли компромисс». Иногда — да. Часто — нет. Но этот ответ должны давать инженеры, а не спикеры на конференции.

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

P.S. Через два года появится статья «Почему мы ушли от облачного ИИ к собственным моделям». Экономический цикл повторится, как это было с облаком против собственного дата-центра десять лет назад.

Словарь терминов

API (Application Programming Interface) — программный интерфейс, через который разные программы общаются друг с другом. Обычный API отвечает за миллисекунды, ИИ — за секунды.

Backend — серверная часть приложения, которая работает «под капотом». Пользователь её не видит, но именно там происходит вся логика.

Батчинг (batching) — обработка данных группами, а не по одному. Например, отправка 10 000 email-рассылок за раз.

Кэш (cache) — временное хранилище часто используемых данных, чтобы не вычислять их каждый раз. Проблема ИИ в том, что его ответы редко повторяются.

Copilot — помощник, который советует, но не принимает решения за вас. В отличие от автопилота, который действует автономно.

DAU (Daily Active Users) — количество ежедневных активных пользователей продукта.

Детерминизм — свойство системы выдавать одинаковый результат при одинаковых входных данных. ИИ-модели недетерминированы: один и тот же запрос может дать разные ответы.

Endpoint — точка входа в API, конкретный URL, который вызывает клиент. Например, POST /api/user.

Fallback — запасной вариант, когда основной способ не сработал. В ИИ часто используют fallback на более простую модель.

GDPR, HIPAA, SOC2 — стандарты и регуляции по работе с личными данными и информационной безопасностью. Несоблюдение — огромные штрафы.

Hit rate — процент случаев, когда кэш находит нужные данные. Hit rate 90% = 9 из 10 запросов берутся из кэша.

Инференс (inference) — процесс работы уже обученной модели: выдача ответа на входные данные.

Латентность (latency) — задержка между запросом и ответом. Чем ниже — тем лучше.

LLM (Large Language Model) — большая языковая модель, вроде GPT-4. «Разговаривает» на естественном языке.

Оптимистичный UI — приём в разработке: интерфейс показывает результат мгновенно, хотя на самом деле запрос ещё обрабатывается. Если что-то пошло не так — откатывает изменение.

P95 — 95-й процентиль времени ответа. Это значит, что 95% запросов обрабатываются быстрее этого времени. P95 response time 8 с = 95% запросов отвечают быстрее 8 секунд.

Персональные данные (PII) — имя, email, телефон, адрес и т.п.

Power users — опытные пользователи, которые используют все возможности продукта. Обычно 3–5% от базы.

Prayer-based engineering — сленговый термин: код, который работает, но никто не понимает, почему. Молимся, чтобы не сломалось.

Продакшен (production) — рабочая версия ПО, которой пользуются реальные клиенты. В отличие от development (разработка) и testing (тестирование).

Квантование (quantization) — техника оптимизации ИИ-моделей: уменьшение точности чисел для экономии памяти и ускорения работы. Компромисс: качество немного падает.

Воспроизводимость — возможность воспроизвести баг снова, чтобы его исправить. С ИИ это часто невозможно.

Право на забвение (right to be forgotten) — право пользователя на удаление своих личных данных. Требование GDPR.

Скелетоны экранов (skeleton screen) — серые «скелеты» интерфейса, которые показываются вместо контента во время загрузки. Психологически пользователи воспринимают это лучше, чем спиннер загрузки.

SLA (Service Level Agreement) — соглашение об уровне сервиса. Обычно включает гарантии доступности.

Спиннер (spinner) — крутящийся индикатор загрузки. Символ «подождите, мы думаем».

Температура (temperature) — параметр ИИ-модели, который контролирует случайность ответов. Низкая температура = более предсказуемые ответы.

Токен (token) — единица текста для ИИ: может быть словом, частью слова или символом. Английское слово ≈ 1 токен, русское ≈ 2 токена.

Uptime — время, когда система работает и доступна. 95% uptime = 1,8 дня простоя в месяц.

#DI3S #искусственныйинтеллект #разработка #продакшен
#itархитектура #облачныесервисы #стартапы #технологии #ai

5 views·2 shares