B.3 Техническая грамотность (без углубления в код)

Понимание разницы между ML, DL и GenAI. Нужно четко различать:

· Классический ML (CatBoost, XGBoost): предсказание чисел (скоринг, отток).

· LLM/GenAI (GPT, Kandinsky): создание текста, кода, картинок.

Для РП критично понимать, что LLM требует другого подхода к инфраструктуре (GPU vs CPU) и безопасности (prompt injection).

Prompt Engineering как компетенция команды. Если вы внедряете LLM без fine-tuning (дообучения), ваш РП (или аналитик) должен уметь писать промпты. Это новая форма требований (requirements), которая пишется на естественном языке, но требует структурированности.

Проблема «галлюцинаций» (Hallucinations). Модель может уверенно выдавать ложную информацию. РП должен уметь выявлять сценарии, где цена ошибки высока (High-Risk Scenarios), и внедрять технические решения (RAG - Retrieval-Augmented Generation, ограничение ответов по базе знаний), чтобы минимизировать этот риск.

Разница между On-Premise, API и Private Cloud. Нужно знать, когда нужно покупать лицензированные GPU и ставить модель локально (из-за безопасности данных, как в ПСБ или госсекторе), а когда можно использовать API облачных провайдеров (Yandex Cloud, SberCloud, GigaChat API) для скорости запуска.

B.4 Безопасность, право и этика

ИИ не может быть владельцем процесса (Accountable). Согласно методологиям (например, COBIT) и законодательству (в РФ готовятся поправки, 152-ФЗ), ответственным за решение, принятое ИИ, всегда остается человек. В проектной документации нужно четко прописывать зоны ответственности: «ИИ рекомендует, оператор утверждает».

Защита от инъекций и отравления данных. Это кибербезопасность в AI. Злоумышленники могут отравить данные обучения (data poisoning) или использовать промпт-инъекции, чтобы заставить чат-бота нарушать правила. В план внедрения нужно закладывать пентесты (AI Red Teaming).

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

B.5 Бизнес и управление изменениями

ROI считается иначе. Экономика AI проектов часто строится на предотвращенных потерях (не упустил клиента, не нарушил нормативку) или утилизации времени (освободил 1000 часов рутины). РП должен уметь считать не «количество фич», а «стоимость сэкономленного внимания сотрудника».

B.5.1 Экономика AI-проектов: как считать ROI иначе

Классический ROI (Return on Investment) считают через прямую выручку или прямую экономию. Но AI-проекты часто окупаются через предотвращение потерь и освобождение внимания сотрудников - то, что не попадает в стандартные финансовые отчёты. Если считать только «фичи», проект убьют на первом же бюджетном комитете.

Проблема классического подхода к ROI

Классическая формула для IT-проектов:

ROI = (Выгода - Затраты) / Затраты × 100%

где «Выгода» обычно это:

· Рост выручки

· Прямая экономия (уволили людей, сократили сервера)

· Сокращение времени на операции

Для AI-проектов эта формула часто не работает по трём причинам:

Ключевой инсайт

Если вы придёте к финансовому директору с таблицей «мы добавили 15 новых фич», он спросит: «И сколько это принесло денег?» И если ответ - «никак, но стало удобнее» - проект закроют.

Два новых типа экономии для AI-проектов

1. Предотвращённые потери (то, чего не случилось)

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

Пример расчёта

Задача: AI-модерация комментариев в банковском приложении

Без AI:

3 скандала в год, каждый обходится в 5 млн ₽ (юристы, PR, отток клиентов)

С AI:

0 скандалов

Предотвращённые потери = 3 × 5 млн = 15 млн ₽ в год

Затраты на AI = 2 млн ₽ (разработка + инференс)

ROI = (15 - 2) / 2 = 650%

2. Освобождение внимания сотрудника (самый недооценённый ресурс)

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

Метафора

Представьте, что вы позвали дорогого хирурга мыть полы. Хирург моет полы хуже уборщицы, а его час стоит в 20 раз дороже. AI - это способ заставить хирурга заниматься хирургией, а полы отдать уборщице.

Что значит «освободить внимание»

Суммарно: 830 + 1500 + 250 = 2580 ₽/день. За 22 рабочих дня ≈ 56 760 ₽ в месяц экономии на одном сотруднике.

Важное уточнение

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

Как считать стоимость сэкономленного внимания

Формула

Экономия = (Время_рутины_в_часах × Ставка_сотрудника_в_час) + (Ценность_освобождённого_времени_для_бизнеса)

Где «ценность освобождённого времени» - это то, что сотрудник теперь делает вместо рутины (продаёт, развивает продукт, общается с важными клиентами).

Цель - не точность до копейки, а понимание порядка. Ошибка в 2 раза - допустима.

Пример с поддержкой клиентов

ROI считаем так

Прямая экономия от освобождения времени:

15 часов × 800 ₽ × 22 дня = 264 000 ₽/месяц

Плюс дополнительная выручка: +200 000 ₽/месяц

Итого выгода: 464 000 ₽/месяц

Затраты на AI: 100 000 ₽/месяц (токены, GPU, поддержка)

ROI = (464 - 100) / 100 = 364%

Важное отступление. Про ROI для L2 и L3

Всё, что мы посчитали выше (освобождённое внимание, предотвращённые потери), - это про L1 (ассистент). Человек в контуре, риски минимальны.

Для L2 (супервайзер) и L3 (автомат) классический ROI не работает. Потому что вы теперь отвечаете за ошибки модели.

Формула для L2/L3

Экономический эффект = (Потенциальная выгода) − (Вероятность ошибки × Стоимость ошибки) − (Затраты на контроль и переобучение)

Пример: модель работает с точностью 99,9%. На миллионе операций - 1000 ошибок. Если каждая ошибка стоит компании 1000 рублей - это минус 1 млн рублей. Если 1 млн рублей - минус 1 млрд. ROI становится отрицательным на любом горизонте.

Правило

L2 и L3 имеют смысл только там, где цена ошибки близка к нулю (рекомендательные системы, типовые ответы), либо где есть внешнее страхование (госзаказ, регуляторная гарантия). Во всех остальных случаях HITL - не трусость, а признание того, что вероятностные системы требуют вероятностного финансирования, а не линейного ROI.

ROI vs Risk-Adjusted Value

Что должен уметь считать РП (руководитель проекта)

Контрольный список для РП при защите AI - проекта

· Посчитал, сколько часов рутины убирает AI в день на одного сотрудника

· Перевёл часы в деньги по реальной ставке сотрудника (не минимальной)

· Оценил, на что сотрудник потратит освободившееся время (и во что это оценивает бизнес)

· Нашёл 2-3 сценария предотвращённых потерь и оценил их стоимость

· Учел эксплуатационные затраты (токены, GPU, поддержка) - не только разработку

· Подготовил ответ на вопрос: «А почему мы не можем сделать то же самое без AI?»

В AI-проектах ROI считают не по «сделанным фичам», а по освобождённому вниманию сотрудников (перевели рутину в часы и умножили на ставку) и предотвращённым потерям (посчитали, сколько стоят штрафы, скандалы и уход клиентов, которых AI не допустил). РП, который приходит на бюджетный комитет с количеством фич, проигрывает. РП, который приходит с таблицей «сэкономили 1000 часов внимания старших разработчиков» - получает бюджет.

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

B.5.2. MLOps вместо DevOps

Классический DevOps (CI/CD) не работает для моделей. Нужно понимать, что такое MLOps:

· CI: непрерывная интеграция данных и кода.

· CD: непрерывная доставка модели (а не просто кода).

· CT: непрерывное обучение (Continuous Training) для предотвращения дрейфа концепции (concept drift).

В классической разработке у вас есть детерминированный код:

· Написали if salary > 1000: approve().

· Закоммитили.

· Прогнали тесты.

· Задеплоили.

Всё работает одинаково всегда.

В ML/AI у вас есть модель, обученная на данных

Модель - это просто бинарный файл (веса), который зависит от данных.

Данные меняются. Поведение клиентов меняется. Мир меняется.

Модель, которая работала вчера, может сегодня врать, хотя код (пайплайн инференса) не менялся.

DevOps отвечает на вопрос

«Как быстро и безопасно доставить код до сервера?»

MLOps отвечает на вопрос

«Как быстро и безопасно доставить правильную модель до сервера и убедиться, что она не устарела?»

Разбор трех компонентов MLOps

CI (Continuous Integration) - Непрерывная интеграция

В классическом DevOps CI означает: «закоммитил код → прогнали юнит-тесты → собрали артефакт».

В MLOps CI шире. Это интеграция

Пример из практики

У вас модель кредитного скоринга. Входные данные - поле возраст. В какой-то момент разработчики CRM поменяли формат: вместо числа 35 стали передавать строку 35 лет. Код не упал (типизация слабая), но модель начала выдавать кашу. CI в MLOps должен был отловить это через тест на соответствие схемы.

CD (Continuous Delivery / Deployment) - Непрерывная доставка

В классическом DevOps CD означает: «доставили артефакт (jar, docker image) в продакшен».

В MLOps CD означает доставку МОДЕЛИ, а не только кода

Здесь есть важное различие:

Что появляется в CD для MLOps

Model Registry (Реестр моделей):

· Каждая обученная модель получает версию (v1.0, v1.1, v2.0).

· В реестре хранятся не только веса, но и метаданные: на каких данных обучена, какая точность (accuracy) на тесте, когда обучена, кто обучал, гиперпараметры.

· Это «единый источник правды». Без этого вы быстро запутаетесь, какая модель сейчас в продe.

Автоматическое тестирование модели перед деплоем

Нельзя просто закатить новую модель, даже если она «показывает хорошую метрику на тесте».

Нужно прогнать её на репрезентативном срезе живых данных (shadow mode - см. ниже) и убедиться, что она не хуже текущей.

Shadow Mode (теневой режим) - важнейший инструмент

· Новая модель запускается параллельно с текущей, но её решения не используются для клиентов.

· Она «наблюдает» за реальным трафиком, а мы сравниваем её ответы с текущей моделью или с решениями операторов.

· Только после накопления статистики в shadow mode - деплоим.

CT (Continuous Training) - Непрерывное обучение

Это самое важное отличие MLOps от DevOps. В классической разработке код не «стареет». В ML модели стареют всегда.

Concept Drift (Дрейф концепции) - что это

· Модель обучена на исторических данных.

· Мир меняется: изменились тарифы, кризис, новый закон, пандемия.

· Связь между признаками и целевой переменной (той, что мы предсказываем) изменилась.

· Модель начинает ошибаться системно, хотя её код и веса не менялись.

Пример дрейфа концепции

Модель оттока клиентов обучена на данных 2023 года. В 2024 году банк запустил новую программу лояльности. Теперь клиенты, которые раньше уходили (модель их маркировала как «уйдут»), остаются. Модель начинает выдавать ложные срабатывания. Это не «сломался код» - это изменилась реальность.

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

Рисунок. Цикл MLOps для LLM (MLOps Lifecycle)

Обратите внимание на Feedback Loop: без сбора фактических значений (ушел клиент или нет) переобучение невозможно. MLOps - это не просто деплой кода, это управление жизненным циклом данных и моделей.

CT решает эту проблему

Что нужно РП для организации CT

Мониторинг дрейфа

Автоматические алерты, когда распределение входных признаков (data drift) или качество предсказаний (concept drift) выходят за допустимые границы.

Автоматический пайплайн обучения

Нет такого, что «Саша-датасайентист запустил ноутбук в Jupyter и залил модель вручную». Всё должно быть автоматизировано: от вытяжки данных до регистрации новой модели в Model Registry.

Обратный контур (Feedback Loop)

Система должна получать фактические значения того, что предсказывала модель. Если модель предсказала «клиент уйдёт», нужно знать, ушёл ли он на самом деле через 30 дней. Без этого CT невозможен.

Сравнительная таблица: DevOps vs MLOps глазами РП

Что РП должен требовать от команды

Если вы РП по внедрению ИИ, вот минимальные требования к MLOps-инфраструктуре, без которых проект будет неуправляемым:

Model Registry

Где хранятся версии моделей с метаданными? Без этого вы не сможете ответить на вопрос: «А какая модель сейчас в проде и когда её обучили?»

Shadow Mode

Есть ли возможность развернуть новую модель в режиме наблюдения, не влияя на клиентов? Если нет - каждый релиз будет «полетом вслепую».

Автоматический мониторинг дрейфа

Есть ли дашборды, которые показывают, не изменилось ли распределение входных данных и не упало ли качество предсказаний? Без этого вы узнаете о проблеме от жалоб бизнеса (через 2 недели, когда уже нанесён ущерб).

Feedback Loop

Собирается ли «правда» (фактические значения) для предсказаний? Если модель предсказывает, а мы никогда не узнаём, угадала ли она - CT невозможен.

Воспроизводимость обучения

Может ли датасайентист, который уйдёт в отпуск, передать пайплайн обучения коллеге, чтобы тот запустил переобучение одной кнопкой? Если обучение происходит в Jupyter Notebook на локальной машине - это не MLOps, это ремесленничество.

Пример из практики: антифрод-система

Допустим, вы внедряете антифрод (обнаружение мошеннических транзакций). Без MLOps вы столкнётесь с:

Месяц 1:

Модель работает отлично (99% точности).

Месяц 3:

Мошенники изменили паттерны (concept drift). Модель пропускает новые типы атак (False Negative растёт).

Реакция:

Вы узнаёте об этом от службы безопасности, когда уже списаны деньги.

Причина:

Не было мониторинга дрейфа и автоматического переобучения.

С MLOps:

Мониторинг каждые 4 часа проверяет распределение признаков и падение precision/recall.

Алерт уходит в чат команды при первых признаках дрейфа.

Автоматический триггер запускает пайплайн переобучения на свежих данных (включая данные о новых успешных атаках).

Новая модель проходит shadow mode, сравнивается с текущей, и после подтверждения качества автоматически деплоится.

Время реакции: часы, а не недели.

Резюме для РП

Главная мысль

В DevOps вы доставляете код, который работает всегда одинаково. В MLOps вы доставляете модель, которая живёт своей жизнью, стареет, требует наблюдения и переобучения. Как РП, вы должны управлять не только релизами, но и циклом жизни данных и моделей. Без MLOps AI-проект - это игрушка, которая рано или поздно сломается в самый неподходящий момент.

Дрейф данных (Data Drift) и дрейф концепции (Concept Drift)

Модель, которая работала отлично в январе, может «посыпаться» в марте, потому что изменилось поведение клиентов (например, из-за изменения тарифов или внешних экономических факторов). РП должен планировать бюджет и время на постоянный мониторинг и переобучение моделей (retraining).

Гибридизация команды

В AI проекте редко бывает «чистый проджект». Часто РП должен уметь фасилитировать споры между Data Scientist (который хочет «поиграть» с архитектурой нейросети) и Data Engineer (которому нужна стабильность пайплайнов), а также бизнесом (которому нужна «магия» вчера). Успех зависит от умения переводить вероятностные метрики модели на язык бизнес-рисков и выгоды.

Если вас спрашивают: «Когда сделаем?», вы должны отвечать не «через 2 месяца», а:

· Когда соберем данные?

· Когда разметим?

· Когда получим baseline (первую версию)?

· Как будем измерять качество?

· Как будем деплоить с учетом HITL (человек в контуре)?

В.5.3 SLA для недетерминированных систем: от «точности» к «доверию»

Классический IT-контракт требует четких метрик: «Система должна работать с uptime 99.9% и выдавать корректный ответ в 100% случаев». Для LLM такое требование - самоубийство. Если вы подпишете SLA с гарантией 100% фактологической точности, вы обанкротитесь на первых же штрафах.

Как же заключать договоры на ИИ? Нужно менять язык контракта с детерминированного на вероятностный.

1. Три уровня метрик в SLA

Разделите обязательства на три категории, каждая со своей ответственностью:

А. Инфраструктурный SLA (Техническая часть)

Здесь всё как в обычном IT. Вы гарантируете доступность сервиса.

Метрика: Uptime API, Latency (p95 < 2 сек), Throughput (токенов/сек).

Ответственность: Полная. Если сервер упал - вы платите.

Б. Процессуальный SLA (Гигиена данных и безопасности)

Вы гарантируете не результат, а процесс его получения.

Метрика: 100% запросов проходят через фильтр PII (персональных данных); 100% ответов генерируются на основе документов из векторной БД (для RAG); наличие логов для аудита.

Ответственность: Полная. Если модель утекла персональные данные или сослалась на несуществующий документ - это ваш брак.

В. Качественный SLA (Бизнес-метрики)

Самая сложная часть. Здесь нельзя писать «Точность 95%». Используйте составные метрики:

Task Success Rate (TSR): Доля задач, решенных без участия человека (или с подтверждением человека). Пример: «80% типовых запросов обрабатываются автоматически».

Fallback Rate: Доля запросов, переданных человеку (эскалация). Пример: «Не более 15% запросов требуют вмешательства оператора».

Hallucination Cap (Потолок галлюцинаций): Допустимый процент фактических ошибок в выборке. Пример: «Не более 2% критических фактических ошибок в ежемесячной аудиторской выборке из 1000 ответов».

Важно: SLA по качеству всегда должен иметь оговорку: «Метрики измеряются на репрезентативной выборке за период N дней, утвержденной обеими сторонами». Иначе клиент будет присылать вам самые сложные и каверзные вопросы и требовать штрафов.

2. Юридические «подушки безопасности»

Чтобы защитить компанию от исков за ошибки ИИ, внедрите в продукт и договор три механизма:

1. Дисклеймер «Человек в контуре» (HITL Clause) В договорах B2B и пользовательских соглашениях четко пропишите: «ИИ является ассистирующим инструментом. Финальное решение, имеющее юридические или финансовые последствия, принимается уполномоченным сотрудником Заказчика». Это переносит ответственность за финальный акт с разработчика ИИ на оператора, который нажал кнопку «Подтвердить».

2. Право на объяснение (Explainability Right) Для регулируемых отраслей (банки, медицина, HR) включите в SLA обязательство предоставлять «Цепочку обоснования»:

Какие документы были использованы (ссылки на источники в RAG).

Какой был промпт и температура.

Лог мыслей агента (если используется ReAct). Это защищает вас от обвинений в «черном ящике» и дискриминации.

3. Механизм «Safe Harbor» (Безопасная гавань) Пропишите процедуру реагирования на инциденты:

Если обнаружена критическая ошибка (галлюцинация, токсичность), Заказчик обязан уведомить Исполнителя в течение 24 часов.

Исполнитель обязан исправить промпт/дообучить модель в течение 3–5 дней.

Штрафы начисляются только если Исполнитель не устранил проблему в срок. Это превращает ошибки из повода для суда в рабочий процесс доработки.

Однако даже идеально посчитанный ROI и выверенная экономика проекта разобьются о реальность, если пытаться управлять ИИ-разработкой по старым лекалам.

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

Вы не можете просто «сдать и забыть» вероятностную систему, как обычный софт.Именно поэтому нам нужна новая методология управления - AI PDLC (Artificial Intelligence Product Development Life Cycle).

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

Давайте разберем, как выстроить этот процесс так, чтобы команда не сошла с ума от хаоса экспериментов, а продукт действительно дожил до продакшена.