AI-ассистент — это не чат. Это рабочий процесс

Что автоматизировать первым

Ищи задачи с повторяемой структурой: классификация заявок, первичный анализ документов, черновик ответа, поиск по базе знаний, подготовка отчёта. Чем стабильнее вход и критерии качества, тем быстрее появляется польза.

Минимальный AI-контур

У рабочего AI-контура есть пять частей: источник данных, инструкция, модель, проверка результата и логирование. Без логирования команда не понимает, где ассистент помогает, а где создаёт риск.

• Какие данные можно использовать?
• Как проверяется ответ?
• Что считается ошибкой?
• Кто отвечает за финальное решение?

Как выбрать первый процесс для автоматизации

Начинай не с вопроса “какую модель подключить”, а с повторяемого узкого места. Хороший кандидат возникает там, где сотрудник регулярно открывает заявку, ищет информацию в нескольких системах, классифицирует обращение, пишет черновик и передаёт его дальше. Чем стабильнее вход и критерии качества, тем быстрее получится проверить пользу.

Слабая постановка звучит так: “Сделаем AI для поддержки”. Рабочая формулировка: “Для обращений о возврате ассистент найдёт заказ, проверит статус и подготовит черновик ответа, а оператор подтвердит его или исправит”. Во втором варианте понятны вход, выход, границы и следующий шаг.

Контракт входа и выхода

До выбора модели собери несколько реальных примеров. Для каждого зафиксируй, что пришло на вход, какие поля доступны, какой ответ считается правильным и что должен сделать сотрудник. Это одновременно материал для промпта, тестовый набор и будущая документация. Без примеров команда спорит о качестве AI на уровне впечатлений.

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

• Источник: CRM, база знаний, таблица заказов или входящее письмо.
• Контекст: только нужные записи и документы с указанием даты.
• Модель: версия, параметры и лимиты стоимости.
• Проверка: схема ответа, правила бизнеса, ссылка на источник и human review.
• Логирование: вход, выход, версия, задержка, ошибка и итоговое действие.

Минимальный AI-контур

У рабочего контура есть пять слоёв: источник данных, инструкция, модель, проверка результата и логирование. Если убрать источник, ассистент отвечает общими словами. Если убрать проверку, ошибка выглядит так же аккуратно, как правильный ответ. Если убрать логирование, команда не понимает, почему качество изменилось после обновления промпта или модели.

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

Где нужен человек

Human-in-the-loop — не признание провала автоматизации. Это способ безопасно пройти участок, где ошибка дороже скорости. Оператор может принять, исправить или отклонить результат, а система сохранит причину. Так появляется обучающий материал и становится видно, какие ошибки повторяются.

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

• Низкая уверенность — отправить в очередь проверки.
• Противоречивые источники — показать конфликт, а не выбирать молча.
• Нет подходящего документа — честно ответить “не найдено”.
• Высокий риск действия — только подготовить предложение и ждать подтверждения.

RAG не заменяет оценку качества

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

Для пилота собери небольшой эталонный набор из реальных вопросов. Отметь ожидаемый документ, обязательные факты и недопустимые утверждения. Оцени отдельно retrieval и финальный ответ: иначе плохой поиск будет выглядеть как проблема промпта, а галлюцинация — как проблема базы знаний.

Какие метрики действительно нужны

Количество запросов и средняя длина ответа почти ничего не говорят о пользе. Для рабочего процесса нужны метрики на трёх уровнях: качество результата, операция и бизнес-эффект. Например, ассистент поддержки может быстро отвечать, но если операторы переписывают 60% черновиков, автоматизация не достигла цели.

Собирай базовую линию до запуска. Измерь, сколько времени занимает задача сейчас, сколько ошибок исправляют, какова стоимость одного случая и где образуется очередь. После пилота сравнивай не только модель с моделью, а процесс до и после.

Безопасность и границы данных

До пилота зафиксируй, какие данные можно передавать модели, где они хранятся, кто видит логи и как удаляются персональные данные. Не отправляй в тестовый контур секреты, лишние поля и целую базу, если для решения нужен один статус заказа. Минимизация данных полезна и для безопасности, и для качества: лишний контекст часто только путает модель.

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

План пилота на две недели

Пилот лучше ограничить одним типом задачи и одной командой. В первый день собери примеры и baseline, затем опиши контракт ответа и тестовый набор. После этого запусти режим “предложение без автоматического действия”: ассистент готовит результат, но существующий процесс продолжает работать. Только после сравнения качества и времени принимай решение о расширении.

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

• День 1–2: выбрать процесс, владельца, ограничения и baseline.
• День 3–4: собрать эталонный набор и контракт ответа.
• День 5–7: запустить shadow mode и собрать исправления.
• Неделя 2: измерить качество, стоимость, время и критические ошибки.
• Финал: расширить, изменить процесс или остановить пилот с зафиксированными выводами.

Модель, промпт или обычный код

Не всякая задача требует генеративной модели. Если правило можно выразить условием, справочником или SQL-запросом, детерминированный код обычно дешевле тестировать и проще объяснить. Модель стоит подключать там, где на входе есть неструктурированный текст, несколько возможных формулировок или необходимость подготовить черновик для человека.

Выбор модели делай после описания задачи. Сравни качество на одном эталонном наборе, задержку, стоимость, приватность, длину контекста и удобство мониторинга. Более крупная модель не является автоматически лучшей: если она добавляет 20% качества в редких сложных случаях, но вдвое увеличивает стоимость всей очереди, нужен порог эскалации, а не безусловный переход.

Мониторинг после запуска

Качество AI может падать без изменения кода. Меняются документы, распределение запросов, язык клиентов, сезонность и поведение сотрудников. Поэтому после запуска отслеживай не только среднюю оценку, но и срезы: тип задачи, источник, язык, сложность, модель и долю ручных исправлений. Среднее качество легко скрывает провал в одном важном сегменте.

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

• Доля пустых, невалидных и неполных ответов.
• Доля принятых, исправленных и отклонённых результатов.
• Время ответа, число повторных вызовов и стоимость случая.
• Ошибки по сегментам и версии источника.
• Расхождение между рекомендацией и финальным действием сотрудника.

Как посчитать стоимость процесса

Цена вызова модели — только часть расходов. Добавь стоимость хранения и поиска контекста, повторных запросов, интеграции, проверки человеком, исправления ошибок и поддержки. Если ассистент обрабатывает 10 000 заявок в месяц, даже небольшая доля ручного review может оказаться дороже самого API.

Сравнивай не “стоимость токена” с нулём, а стоимость процесса до и после. Если сейчас сотрудник тратит 12 минут на случай, а после запуска — 5 минут на проверку черновика, это хороший результат даже при наличии человека. Если модель генерирует текст за секунду, но оператор переписывает его полностью, процесс не ускорился.

Когда AI лучше не внедрять

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

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

Вывод

AI-ассистент — это рабочий процесс с ограниченными входами, проверяемым выходом и владельцем результата. Начни с узкой повторяемой задачи, зафиксируй baseline, оставь человеку понятную точку контроля и измеряй не восторг от демо, а изменение времени, качества и стоимости. Так пилот превращается в управляемую систему, а не в ещё один чат с красивым ответом.