Как вывести AI PoC в продакшн: 90 дней по фазам

Пропасть между демо и деплоем

У вас есть рабочее демо. LLM отвечает на вопросы по вашей внутренней документации, стейкхолдеры впечатлены, а руководство хочет видеть систему «в бою» к следующему кварталу. Это самый опасный момент для любого AI-проекта.

Переход от Proof of Concept (PoC) к системе промышленного уровня — это место, где погибает большинство AI-инициатив. И дело редко в том, что «модель недостаточно умная». Почти всегда причина в том, что система, созданная для демо — это хрупкий прототип для стерильных условий, а продакшн — это хаотичная, агрессивная среда с высокими ставками. В PoC уровень ошибок 5% считается «многообещающим». В продакшене 5% ошибок — это PR-катастрофа или многомиллионные риски.

Тезис: Разрыв между рабочим AI-демо и продакшн-системой — это не техническая проблема, а проблема доставки (delivery). Этот процесс имеет повторяемую структуру, которая не зависит от используемой технологии — будь то GPT-4, Llama 3 или кастомный трансформер. Успех требует перехода от «промптинга» к «инженерии» и от «ручного тестирования» к «автоматизированной оценке (evaluation)». Этот плейбук описывает 90-дневный путь преодоления этого разрыва.

Почему AI PoC ломаются в продакшене: четыре корня проблем

Чтобы решить проблему доставки, нужно понять, почему она возникает. Большинство команд пытаются применить традиционный SDLC (Software Development Life Cycle) к недетерминированным AI-моделям. Это приводит к четырем типичным сценариям провала.

1. Ловушка «счастливого пути» (Happy Path Fallacy)

• Как проявляется: В ходе разработки PoC команда (и лояльные альфа-тестеры) неосознанно подают «чистые» входные данные. Они задают четкие вопросы в рамках контекста. В реальном мире пользователи вводят белиберду, используют сленг, вставляют огромные куски несвязного текста, спрашивают о конкурентах или активно пытаются «взломать (jailbreak)» систему.
• Первопричина: PoC строился для доказательства возможности (может ли система делать X?), а не надежности (может ли она делать X для всех, всегда и под давлением?). «Длинный хвост» поведения пользователей не моделировался.
• Предотвращение: Внедряйте майндсет «Red Team» с первого дня. Используйте состязательные промпты (adversarial prompting), чтобы найти точки отказа системы до того, как это сделают пользователи.

2. Оценка вслепую (Evaluation Blindness)

• Как проявляется: Разработчик меняет промпт, чтобы улучшить точность в конкретном кейсе. В ручных тестах всё выглядит отлично. Однако это изменение незаметно ломает три других кейса. Команда узнает об этом только через три недели после жалобы клиента.
• Первопричина: Отсутствие «Золотого набора данных» (Golden Set) или пайплайна автоматической оценки. Команда полагается на «vibe checks» — просмотр 5-10 ответов глазами — вместо статистической, повторяемой оценки. AI недетерминирован; его нельзя «протестировать» как кусок кода. Его нужно «оценивать» как статистическую модель.
• Предотвращение: Создайте систему оценки до того, как начнете полировать промпты. Если вы не можете измерить влияние изменений на весь массив данных — вы просто гадаете.

3. Трение при интеграции (Ловушка ноутбуков)

• Как проявляется: PoC живет в Python-ноутбуке или скрипте на локальной машине. Перенос в корпоративную инфраструктуру (Azure, AWS, CI/CD, VPC) создает огромные сложности. Внезапно возникают вопросы Managed Identities, правил файрвола, задержек сети между приложением и LLM API и строгих правил приватности.
• Первопричина: Техническая среда PoC была оторвана от ограничений продакшн-среды. То, что работает в Jupyter-ноутбуке, часто падает в микросервисе под нагрузкой.
• Предотвращение: Начните Фазу 1 со «скелетного деплоя» (Skeleton Deployment). Сразу разверните версию «Hello World» в реальном VPC, чтобы выявить инфраструктурные блокировщики.

4. Операционный долг (Проблема 2-го дня)

• Как проявляется: Система запущена, но расходы выходят из-под контроля. Команда упирается в лимиты (rate limits) провайдера, из-за чего 50% запросов падают. Разработчики тратят по 40 часов в неделю на ручной разбор логов, пытаясь понять, почему модель «ведет себя странно».
• Первопричина: Игнорирование «Ops» в LLMOps. Традиционный мониторинг ищет ошибки 200 vs 500; AI-мониторинг должен отслеживать токсичность, стоимость запроса, семантический дрифт и качество поиска (retrieval).
• Предотвращение: Внедрите семантическое кэширование, надежную наблюдаемость (OpenTelemetry) и стоимостные ограничения к концу Фазы 2.

Отсюда же растёт первое правило всей 90-дневной программы: каждая фаза заканчивается работающей мерой, а не отчётом. Если к концу Фазы 1 у вас нет числа «до/после» по качеству и стоимости, дальше вы не измеряете прогресс, а пересказываете ощущения.

В пилоте, который доехал до прода за 90 дней, это правило проявилось буквально. Основное время ушло не на промпт, не на выбор модели и не на eval — на подключение к корпоративному контексту: кто пользователь, какие документы ему доступны, как отозвать доступ и что это значит для retrieval и для кэша. В демо этот слой отсутствует: у пользователя один набор документов, права не меняются, и вопрос «кому это видно» просто не возникает.

Фреймворк 90-дневной доставки

Успех — это не пункт назначения, а 90-дневная последовательность снижения рисков. Мы делим процесс на три фазы.

Фаза 1: Стабилизация (Дни 1–30) — Инженерный фундамент

Первые 30 дней посвящены тому, чтобы убрать «магию» из PoC и заменить её инженерной строгостью. Мы не добавляем новые функции, а стабилизируем ядро.

Цель: Создать измеримый базовый уровень (baseline) и воспроизводимую среду разработки.

Недели 1-2: Создание «Золотого набора» (Golden Set)

Вы не можете оптимизировать то, что не можете измерить. Golden Set — это коллекция из 50-100 разнообразных пар «Запрос» и «Ожидаемый ответ» (Ground Truth).

• Разнообразие критично: Включите короткие запросы, длинные тексты, краевые случаи и вопросы «вне компетенции».
• Human-in-the-loop: Ожидаемые ответы должны быть проверены экспертами (SME — Subject Matter Experts). Этот набор станет вашим мерилом на следующие 90 дней.

Неделя 3: Инфраструктура и инструментарий

Выносим код из ноутбуков.

• Трассировка: Внедрите трассировку через OpenTelemetry или инструменты вроде LangSmith. Вы должны видеть, какой контекст был извлечен, как выглядел финальный промпт и сколько времени занял каждый шаг (retrieval, embedding, generation).
• Skeleton Deployment: Разверните базовую API-версию в продакшн-облаке. Убедитесь, что она может достучаться до базы данных и LLM API через корпоративный файрвол.

Неделя 4: Петля оценки (Evaluation Loop)

Настройте автоматический пайплайн, который прогоняет Golden Set через систему при каждом изменении промпта или параметров поиска. Используйте метрики:

• Exact Match (EM): Для структурированных ответов.
• ROUGE/METEOR: Для суммаризации текстов.
• LLM-as-a-judge: Используйте более мощную модель (например, GPT-4o), чтобы оценивать работу продакшн-модели по рубрикатору (точность, тон, полезность).

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

Фаза 2: Интеграция (Дни 31–60) — Контекст предприятия

Когда ядро стабильно, его нужно интегрировать в экосистему компании. Здесь мы работаем с «недетерминированной» природой LLM и сложностью реальных данных.

Цель: Превратить AI из изолированного сервиса в надежную часть продукта.

Недели 5-6: Укрепление API

LLM — это удаленный, сторонний и нестабильный сервис. Ваш код должен учитывать вероятность отказа.

• Retries и Timeouts: Используйте библиотеки типа Polly (.NET) или Tenacity (Python) для обработки временных сбоев и лимитов.
• Стратегии Fallback: Что если LLM недоступна? Возвращаем кэшированный ответ, сообщение «система занята» или переключаемся на локальную компактную модель.
• Streaming UX: Если задержка (latency) высока, реализуйте стриминг ответа, чтобы пользователь сразу видел прогресс.

Неделя 7: Оптимизация RAG (Retrieval-Augmented Generation)

Если вы используете RAG, этап поиска (Retrieval) — это то, где система чаще всего дает сбой.

• Стратегия нарезки (Chunking): Оптимизируйте разбиение документов. Слишком мелкие куски теряют контекст, слишком крупные — размывают ответ.
• Гибридный поиск: Комбинируйте семантический поиск (векторный) с ключевыми словами (BM25). Это гарантирует нахождение специфических терминов или ID продуктов.
• Re-ranking: Используйте модель-реранкер (например, от Cohere), чтобы выбрать топ-20 документов и отсортировать их по релевантности перед передачей в LLM.

Неделя 8: Слой управления и безопасности

• Маскирование PII: Слой, который удаляет персональные данные до того, как они попадут в API провайдера.
• Moderation API: Блокировка токсичных запросов и ответов.
• Проверка галлюцинаций: Базовые проверки того, что ответ LLM действительно подтверждается найденным контекстом.

Веха: К 60-му дню система интегрирована в UI, корректно обрабатывает ошибки и соблюдает границы данных.

Фаза 3: Управление (Дни 61–90) — Операционное совершенство

Последние 30 дней посвящены долгосрочному выживанию. Система без мониторинга либо деградирует, либо разорит вас.

Цель: Обеспечить масштабируемость и путь непрерывного улучшения.

Недели 9-10: LLMOps и наблюдаемость

• Мониторинг затрат: Разбивка расходов по пользователям, фичам и отделам. Настройте автоматические «kill switches» при аномальных всплесках затрат.
• Семантическое кэширование: Сохраняйте пары вопрос-ответ в кэше (например, Redis). Это снижает затраты на 30–50% и сокращает задержку до миллисекунд.
• Дрифт производительности: Golden Set не статичен. Отслеживайте, как меняется качество ответов по мере изменения ваших данных.

Неделя 11: Пайплайны деплоя

Вывод нового промпта или модели должен быть таким же строгим, как деплой кода.

• A/B тестирование: Направьте 10% трафика на новый промпт и сравните оценки и фидбэк.
• Shadow Deployments: Запускайте новый промпт в фоновом режиме на реальном трафике, не показывая результат пользователям. Сравнивайте его «теневую» работу с живой системой.

Неделя 12: Петля обратной связи

• Неявный фидбэк: Следите за поведением пользователей. Скопировали ли они ответ? Перешли ли по ссылке?
• Явный фидбэк: Thumbs up/down. Собирайте их и автоматически добавляйте «плохие» ответы в Golden Set для дальнейшего обучения и калибровки.

Веха: К 90-му дню система самосовершенствуется, защищена от перерасходов и прозрачна операционно.

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

Из этого следует поправка к самому плану: Фазу 2 «Интеграция» нельзя закладывать такой же по длине, как Фазу 1, только потому что «интеграция — это connect». В нашем пилоте именно она заняла основную часть срока, и именно из неё выросли работы по разбору прав на документы, по ключу кэша и по отзыву доступа. Если отложить это на Фазу 3, в последний момент придётся переделывать и retrieval, и кэш — и делать это уже после того, как архитектура объявлена рабочей.—

Формирование команды доставки

Команда доставки AI — это не классическая IT-команда. Она требует баланса между «научным» поиском и «индустриальным» исполнением.

• 1. Delivery Lead (техлид доставки)

  • Роль: Владеет 90-дневным планом. Управляет ожиданиями стейкхолдеров (успокаивает, когда кажется «медленно», и бьет тревогу, когда хотят пропустить этап оценки).
  • Метрика: Readiness Score (готовность по чек-листу).

• 2. AI Engineer (промпты и оценка)

  • Роль: Связующее звено между Data Science и Software Engineering. Пишет промпты, создает рубрики оценки, выбирает модели и управляет Golden Set.
  • Метрика: Точность по Golden Set.

• 3. Platform/DevOps Engineer (платформа и масштабирование)

  • Роль: Создает контейнеры, настраивает VPC, управляет векторной базой и стеком наблюдаемости.
  • Метрика: P95 Latency и аптайм.

• 4. AI Product Manager (Эксперт по продукту)

  • Роль: Определяет, что такое «хорошо». Работает с экспертами над Golden Set. Проектирует петли фидбэка в интерфейсе.
  • Метрика: Удовлетворенность пользователей и ROI по токенам.

Типичные ошибки по фазам

Ошибки Фазы 1: Ловушка преждевременной оптимизации Команды тратят недели на дообучение (fine-tuning) или полировку промпта еще до того, как построена система оценки. Это как тюнинговать двигатель без спидометра.

• Решение: Никаких правок в системных промптах, пока не готовы Golden Set и Eval Loop.

Ошибки Фазы 2: Интеграция «черного ящика» Отношение к LLM как к простому REST API. В отличие от кода, ответ LLM может измениться по длине, формату и точности из-за одного лишнего символа в промпте.

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

Ошибки Фазы 3: «Запустил и забыл» Вера в то, что если AI работает на 90-й день, он будет так же работать на 180-й. Контекст меняется, провайдеры обновляют веса моделей, ожидания пользователей растут.

• Решение: Автоматические еженедельные проверки дрифта по Golden Set.

Артефакт: Чек-лист готовности к продакшену на 90 дней

FAQ

1. Достаточно ли 50 примеров в Golden Set? Для старта — да. Лучше иметь 50 качественных, проверенных экспертами примеров, чем 500 зашумленных. По мере нахождения багов в продакшене, обязательно добавляйте их в набор. К концу первого года набор обычно вырастает до 500+ элементов.

2. Стоит ли начинать с дешевой модели для экономии? Нет. Начинайте с самой мощной (например, GPT-4o). Ваша цель — установить «верхнюю планку» качества. Когда вы достигнете высокого скора, пробуйте заменить модель на GPT-4o-mini или Llama 3 8B и смотрите, сохраняется ли качество.

3. В чем главный риск при доставке AI-продукта? Отсутствие кнопки «Стоп». Команды так увлекаются «интеллектом» системы, что забывают про защитные механизмы. Если вы не можете выключить AI отдельно от всего продукта, вы не готовы к продакшену.

4. Как бороться с недетерминированностью? С ней не борются, её принимают. Используйте метрики оценки (например, «точность 92% на тестовом наборе») и доносите это до стейкхолдеров. Используйте UX-паттерны, сообщающие пользователю, что ответ сгенерирован AI и требует проверки.

Похожие статьи

• Production RAG: чек-лист из 50 пунктов для продакшна
• Архитектура enterprise AI: четыре решения, которые всё определяют
• .NET и Azure для AI-систем: референсная архитектура
• Инженерное лидерство в AI-продуктах: оценка, роли, поставка

Готовы к выходу в продакшн?

Перевод AI PoC в продакшн требует больше, чем удачный промпт. Нужна повторяемая машина доставки.

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