Пилот ИИ-агента за две недели: что реально успеть

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

День 0. Что мы отказываемся делать

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

Дни 1–3. Данные решают больше, чем модель

Три дня — жёсткий лимит на получение данных. Нужны четыре вещи: выгрузка реальных диалогов или заявок за последние 3–6 месяцев (минимум 500, лучше 2–5 тысяч), актуальная база знаний в любом виде (Confluence, Word-регламенты, страницы сайта, FAQ из головы старшего оператора), доступ к тестовому контуру целевой системы (amoCRM, Bitrix24, 1С, helpdesk) и один человек со стороны заказчика, который отвечает на вопрос «а как правильно» в течение часа, а не недели.

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

Если за три дня данные не получены — пилот останавливается, и это нормальный исход. Он означает, что компания организационно не готова, и никакая модель это не исправит. Лучше узнать это на третий день, чем на третий месяц.

Дни 4–6. Скучная архитектура, которая работает

Для пилота мы почти всегда собираем одну и ту же схему: RAG поверх базы знаний, один-два инструмента с побочным эффектом (создать сделку, поставить задачу, запросить статус заказа по API), детерминированный роутер намерений на входе и правило эскалации на выходе. Никакой мультиагентности, никаких «автономных» циклов рассуждений — это всё удорожает запрос в 5–10 раз и почти никогда не нужно на первой линии.

Выбор модели — по требованиям к данным, а не по бенчмаркам. Если данные могут покидать контур — Claude или OpenAI через API, они дают лучшее качество следования инструкциям на русском. Если нельзя — Qwen 2.5/3 72B или GigaChat в закрытом контуре; по нашим замерам на задачах поддержки они отстают на 3–6 п.п. точности, что для большинства процессов приемлемо. Оркестрация — Pydantic AI или OpenAI Agents SDK: оба дают типизированные инструменты и трассировку из коробки, что критично для разбора ошибок на следующем этапе.

Самый дорогой баг пилота — не галлюцинация модели, а плохо порезанный документ в индексе. 70% ошибок на первой итерации мы находим именно в retrieval.

Дни 7–10. Итерации на открытой половине набора

Прогоняем агента на первой половине размеченных обращений, получаем точность — обычно 60–75% на первом проходе — и начинаем разбирать ошибки по классам. Типичное распределение: 40% — не нашли нужный фрагмент в базе знаний (лечится чанкингом, метаданными, гибридным поиском), 25% — нашли, но ответили не тем тоном или не по формату (лечится промптом и few-shot примерами), 20% — вопрос вне зоны ответственности, а агент пытался ответить (лечится роутером и порогом уверенности), 15% — реальные ошибки модели. За три-четыре итерации точность на открытой половине поднимается до 85–90%.

Одновременно замеряем экономику: латентность p50/p95 (для чата приемлемо до 6 секунд p95), стоимость запроса в токенах и рублях, долю запросов, дошедших до вызова инструмента. Если стоимость обращения выходит дороже целевой — это сигнал менять модель или архитектуру сейчас, а не после запуска.

Дни 11–13. Отложенная выборка и живой трафик

Финальный прогон — на той половине набора, которую никто не видел. Разрыв между открытой и отложенной выборкой показывает, насколько мы «переобучили» промпт под известные вопросы; нормальный разрыв — 2–4 п.п., если больше 8 — итерации шли не туда. Параллельно, если заказчик готов, включаем агента в теневом режиме на живом трафике: он отвечает, оператор видит ответ и либо отправляет, либо правит. Доля отправленных без правок — самая честная метрика, которую можно получить за две недели.

День 14. Три исхода, и все три — результат

• Масштабируем. Метрики достигнуты, экономика сходится. Пилотный код становится основой продакшна — мы изначально пишем его так, чтобы не выбрасывать.
• Дорабатываем узкое место. Точность 80% вместо 88%, и мы точно знаем, какой класс ошибок за это отвечает. Ещё одна-две недели с конкретным планом.
• Закрываем. Данные слишком грязные, процесс слишком вариативный или экономика не сходится. Заказчик потратил две недели вместо полугода и знает, что чинить в процессе до возвращения к теме.

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