Как мы работаем

AI-пилот за 4 недели: как собрать PoC, который реально решает задачу

Практический гайд по запуску AI-пилота: выбор задачи, подготовка данных, критерии успеха, типовые ошибки. С примерами из практики.

9 минут
Как мы работаем
Xencom · Блог
AI-пилот за 4 недели: как собрать PoC, который реально решает задачу

«Давайте сначала сделаем PoC, а потом решим» — самая рациональная фраза, которую можно услышать на первой встрече по AI-проекту. PoC за 3–4 недели стоит 300–600 тыс. ₽ и даёт честный ответ «окупится или нет» вместо полугодовой разработки вслепую. Разбираем, как спроектировать пилот, чтобы он реально работал, а не превратился в дорогую презентацию.

Что такое PoC — и что это не

PoC (Proof of Concept) — это работающий прототип на ваших реальных данных, с помощью которого можно замерить качество и принять решение: идём в production или нет.

PoC — это не:

  • Красивая демка на 10 вручную выбранных примерах.
  • Слайды «как будет».
  • Готовое production-решение.
  • Скрипт в Jupyter Notebook, запускаемый руками.

PoC должен быть достаточно реален, чтобы дать честные метрики, и достаточно простой, чтобы уложиться в 3–4 недели.

Шаг 1. Правильная формулировка задачи

Главная ошибка: «нам нужен PoC, чтобы посмотреть, что AI может». Такой PoC не даёт ответа ни на один бизнес-вопрос.

Правильная формулировка звучит так:

«Проверить гипотезу: LLM с RAG по нашей базе тикетов даёт точность ≥ 80% на типовых обращениях 1-й линии. Если да — запускаем полноценный проект, если нет — ищем другой сценарий».

Три обязательных элемента:

  1. Конкретный сценарий: не «AI для бизнеса», а «ассистент для 1-й линии поддержки».
  2. Измеримая метрика: точность, покрытие, время отклика, CSAT, ROI-прокси.
  3. Порог принятия решения: что значит «получилось» и «не получилось». Без порога любой результат можно интерпретировать как угодно.

Шаг 2. Подготовка данных

80% успеха PoC — это данные, которые ему скормите.

Минимально необходимо:

  • Чистый исторический датасет (100–1000 примеров для типовой задачи).
  • Эталонные ответы/метки (что считается правильным).
  • Тестовая выборка, которую модель не видит во время разработки.
  • Формат, пригодный для автоматической обработки (CSV/JSON, не сканы PDF с надписями от руки).

Чего часто не хватает:

  • Документации к процессу (никто не помнит, почему в 2019 так решили).
  • Единого справочника «правильных» ответов (разные операторы отвечают по-разному).
  • Чистых данных (в тикетах смешаны боль, эмоции и реальный запрос).

Если данных нет — первые 2 недели PoC уйдут на их подготовку. Это часть работы, которую лучше планировать заранее.

Шаг 3. Декомпозиция на 4 недели

Типовой график PoC:

Неделя 1 — Scoping и данные

  • Финализируем формулировку задачи и метрики.
  • Собираем и чистим исторический датасет.
  • Разделяем на train/test, фиксируем эталоны.
  • Поднимаем базовую инфраструктуру: LLM, векторная БД, API.

Неделя 2 — Первый прогон

  • Собираем baseline-пайплайн (RAG по документам, простой prompt).
  • Запускаем на тестовой выборке, считаем метрики.
  • Анализируем ошибки: где галлюцинирует, где не находит контекст, где путает.

Неделя 3 — Итерация

  • Улучшаем промпты, добавляем гардрейлы, тюним RAG (chunking, rerank).
  • При необходимости — упрощаем/меняем подход.
  • Перезапускаем на тесте, сравниваем с baseline.

Неделя 4 — Отчёт и решение

  • Финальный прогон на полной тестовой выборке.
  • Анализ: точность, стоимость per-запрос, оценка ROI в production.
  • Отчёт: что работает, что нет, какой путь к production.
  • Встреча с клиентом: go/no-go.

Шаг 4. Критерии успеха

Один из главных разговоров, который нужно провести до старта PoC: что мы считаем успехом.

Плохая формулировка: «будет впечатляюще работать». Хорошая:

  • Точность на тестовой выборке ≥ 80% (вместо 60% у текущего процесса).
  • Стоимость per-запрос ≤ X рублей (сравнимо или дешевле, чем ручная обработка).
  • Покрытие ≥ 70% типового потока запросов (остальное эскалируется людям).

Если хотя бы 2 из 3 метрик достигнуты — идём в production. Если 1 из 3 — разбираемся, можно ли дотянуть. Если 0 — честно сворачиваем.

Такие пороги делают решение go/no-go не субъективным.

Типовые ошибки PoC

1. Smoke-тест вместо PoC. «Работает на 5 подобранных примерах — значит, работает вообще». Нет, не значит. Нужен слепой тест на 200+ примерах.

2. Смешивание PoC и MVP. Пытаются за 4 недели сделать production-ready решение с интеграциями, аутентификацией и дашбордами. В итоге не получается ни PoC, ни MVP.

3. Отсутствие baseline. Нельзя оценить улучшение, если не знаешь исходную точку. До AI какая точность? Какая стоимость? Какой SLA?

4. Игнорирование стоимости инференса. PoC показал 92% точности, но стоит 40 ₽ за запрос. А у вас 500 тыс. запросов в месяц — это 20 млн ₽/мес. Без разговора об экономике проект мёртв.

5. Неправильный датасет. PoC тренировали на «чистых» запросах, а в проде приходят опечатки, эмоциональные жалобы, мультиязычные вставки. Качество рушится.

Как должен выглядеть отчёт по PoC

Полезный отчёт — 8–15 страниц, обязательно содержит:

  • Задача и критерии успеха (чтобы не было расхождений с ожиданиями).
  • Метрики на тестовой выборке (точность, покрытие, latency, стоимость).
  • Примеры удачных и неудачных кейсов (с объяснением «почему»).
  • Сравнение с текущим процессом (было / стало).
  • Оценка ROI для production (экономия, срок окупаемости, риски).
  • План реализации (если идём в прод: сроки, команда, бюджет).
  • Рекомендация: go / go с оговорками / no-go с объяснением.

Если отчёт — это 60 слайдов с маркетингом, PoC сделали неправильно.

Что делать с результатами

Go: пишем ТЗ на production-реализацию, формируем команду, идём в разработку. Обычно — 2–4 месяца до первого запуска.

Go с оговорками: нужен второй PoC (другая архитектура) или улучшение данных. Типично 2–4 недели дополнительной работы.

No-go: честно признаём, что задача не готова, и смотрим, что нужно изменить. Иногда это вопрос данных (накопить ещё 6 месяцев), иногда — бизнес-процесса (перестроить перед AI), иногда — выбрать другой сценарий.

Все три результата нормальны. PoC и придуман, чтобы сэкономить 6 месяцев разработки на неудачной идее.

Итог

Хороший AI-PoC — это 3–4 недели работы, 300–600 тыс. ₽ бюджета и честный ответ на вопрос «стоит ли вкладываться в production». Ключ — правильная формулировка задачи, чистые данные и заранее согласованные критерии успеха.

Если сомневаетесь, готова ли ваша задача к пилоту — за 30 минут разберём сценарий и подскажем, нужен ли PoC или уже можно делать MVP.

Читать дальше

Другие статьи

Как мы работаем
Xencom · Блог
Как выбрать подрядчика на AI-проект: 8 вопросов на первом звонке
20 января 2026 г. 7 минут

Как выбрать подрядчика на AI-проект: 8 вопросов на первом звонке

Сборник практических критериев для руководителей, которые выбирают студию или агентство для внедрения AI. Что спросить, чтобы отсеять хайп.

Читать
AI-ассистенты
Xencom · Блог
AI-агенты vs AI-ассистенты: чем они отличаются и какому бизнесу что реально нужно в 2026
18 мая 2026 г. 10 минут

AI-агенты vs AI-ассистенты: чем они отличаются и какому бизнесу что реально нужно в 2026

Разбираемся, в чём принципиальная разница между AI-ассистентом и AI-агентом, почему «агенты» — главный технологический тренд 2026 по версии Сбера и ФинТеха, и какие задачи стоит решать через одно, а какие — через другое. С таблицей, антипаттернами и расчётом бюджета.

Читать
Compliance
Xencom · Блог
152-ФЗ в 2026: оборотные штрафы 3%, обязательная УПД и ЭТТН — чек-лист малого бизнеса до сентября
16 мая 2026 г. 12 минут

152-ФЗ в 2026: оборотные штрафы 3%, обязательная УПД и ЭТТН — чек-лист малого бизнеса до сентября

Разбираем три самых жёстких регуляторных удара 2025–2026 года: оборотные штрафы до 3% выручки за утечку ПДн (с 30.05.2025), переход на УПД как единственный формат первички (с 01.01.2026) и обязательная электронная транспортная накладная (с 01.09.2026). Со ссылками на нормы, реальными штрафами 2026 и чек-листом по подготовке.

Читать

Обсудим ваш AI-проект?

Расскажите о задаче — на 30-минутном звонке подскажем, с чего начать и чего избегать.