# Как вывести AI PoC в продакшн: 90 дней по фазам Почему AI-пилоты не доезжают до продакшна и как это чинить: Golden Set, eval-пайплайн, интеграция с корпоративным контекстом, LLMOps и чек-лист готовности. > For the index of this section of the site, see [llms.txt](https://anetlab.ru/llms.txt) 16 октября 2026 г.12 мин чтения # Как вывести AI PoC в продакшн: 90 дней по фазам Почему AI-пилоты не доезжают до продакшна и как это чинить: Golden Set, eval-пайплайн, интеграция с корпоративным контекстом, LLMOps и чек-лист готовности. [Виктор Бузин](https://anetlab.ru/about.md) · Founder & Principal Engineer, AnetLab 16+ лет в enterprise-разработке: .NET, AI/LLM-системы, RAG, MCP. Автор материала и практик в студии. ## Пропасть между демо и деплоем У вас есть рабочее демо. 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 дней | Фаза | Пункт | Условие Go/No-Go | Владелец | | --- | --- | --- | --- | | **P1** | **Golden Set** | 50+ кейсов проверены экспертами (SME) | AI PM | | **P1** | **Eval Pipeline** | У каждого изменения промпта есть авто-оценка | AI Engineer | | **P1** | **Трассировка** | Видны промпт, контекст и результат каждого шага | DevOps | | **P1** | **Базовая Latency** | P95 задокументирована и приемлема для UX | AI Engineer | | **P1** | **Skeleton Prod** | Приложение запущено в продакшн-VPC | DevOps | | **P1** | **Security Audit** | Проведен аудит прав доступа и приватности | Security | | **P1** | **Red Teaming** | Тесты на взлом не выявили критических утечек | AI Engineer | | **P1** | **Cost model** | Стоимость на 1к юзеров просчитана и одобрена | Delivery Lead | | **P2** | **Обработка ошибок** | Реализованы Retries/Timeouts/Fallbacks | SW Engineer | | **P2** | **Тюнинг RAG** | Chunking и Indexing оптимизированы по скорости | Data Engineer | | **P2** | **Фильтрация PII** | Персональные данные удаляются до отправки в API | Security | | **P2** | **Цитаты в UI** | Ответы ссылаются на исходные документы | PM / UX | | **P2** | **Фидбэк-петля** | Thumbs Up/Down сохраняются в логи | SW Engineer | | **P2** | **Гибридный поиск** | Результаты Vector + Keyword объединены | Data Engineer | | **P2** | **Бюджет токенов** | Жесткие лимиты на макс. токены на запрос | AI Engineer | | **P2** | **SLA определен** | Цели по аптайму и скорости зафиксированы | Delivery Lead | | **P3** | **Семантический кэш** | Слой кэша активен для экономии и скорости | SW Engineer | | **P3** | **Cost Guardrails** | Лимиты бюджета и авто-отключение активны | Delivery Lead | | **P3** | **Мониторинг дрифта** | Еженедельный авто-прогон по Golden Set | AI Engineer | | **P3** | **HITL Дашборд** | Интерфейс для ручного разбора ошибок AI | AI PM | | **P3** | **A/B Тестирование** | Фреймворк для тестов промптов на трафике | DevOps | | **P3** | **Юр. согласование** | Финальное одобрение по безопасности и токсичности | Legal | | **P3** | **Обновление моделей** | Описан процесс миграции на новые версии LLM | AI Engineer | | **P3** | **Готовность** | Подписано стейкхолдерами для полного раскатывания | Delivery Lead | * * * ## 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 пунктов для продакшна](https://anetlab.ru/blog/production-rag-checklist.md) * [Архитектура enterprise AI: четыре решения, которые всё определяют](https://anetlab.ru/blog/enterprise-ai-architecture.md) * [.NET и Azure для AI-систем: референсная архитектура](https://anetlab.ru/blog/dotnet-azure-ai-architecture.md) * [Инженерное лидерство в AI-продуктах: оценка, роли, поставка](https://anetlab.ru/blog/engineering-leadership-ai.md) ## Готовы к выходу в продакшн? Перевод AI PoC в продакшн требует больше, чем удачный промпт. Нужна повторяемая машина доставки. **Виктор Бузин** — технолог, специализирующийся на интеграции AI в корпоративный сектор. Чтобы провести аудит вашей дорожной карты AI-готовности, [свяжитесь со мной](https://anetlab.ru/contact.md). Читайте также 20 октября 2026 г.AI/LLM ### [Оценка качества RAG на .NET: Recall@5, MRR и гейт релиза](https://anetlab.ru/blog/rag-evaluation-dotnet.md) Как измерять качество RAG на .NET: Golden Set из 50–100 вопросов, расчёт Recall@5 и MRR, измерение faithfulness и eval-как-гейт-релиза в CI. [Читать разбор](https://anetlab.ru/blog/rag-evaluation-dotnet.md) [.NET](https://anetlab.ru/blog/?tag=.NET)[RAG](https://anetlab.ru/blog/?tag=RAG.md)[Оценка качества](https://anetlab.ru/blog/?tag=%D0%9E%D1%86%D0%B5%D0%BD%D0%BA%D0%B0%20%D0%BA%D0%B0%D1%87%D0%B5%D1%81%D1%82%D0%B2%D0%B0.md) 18 октября 2026 г.AI/LLM ### [Архитектура enterprise AI: четыре решения, которые всё определяют](https://anetlab.ru/blog/enterprise-ai-architecture.md) Практическое руководство по архитектуре корпоративных AI-систем: RAG против дообучения, агенты против workflows, оценка качества и governance. [Читать разбор](https://anetlab.ru/blog/enterprise-ai-architecture.md) [Архитектура](https://anetlab.ru/blog/?tag=%D0%90%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0.md)[Оценка качества](https://anetlab.ru/blog/?tag=%D0%9E%D1%86%D0%B5%D0%BD%D0%BA%D0%B0%20%D0%BA%D0%B0%D1%87%D0%B5%D1%81%D1%82%D0%B2%D0%B0.md)