AI-ассистент в компании: как понять, что им действительно пользуются

Корпоративный AI-ассистент легко показать как успешный проект: поднять чат поверх LLM, подключить базовые документы, разослать анонс и через месяц вынести на слайд красивое число запросов. Проблема в том, что такой счётчик почти ничего не говорит о реальной пользе. Один сотрудник мог проверить новинку, получить бесполезный ответ и больше не открыть её никогда. Формально запрос есть, но рабочий процесс не изменился.

Для инженерной команды важнее другой вопрос: какие метрики доказывают, что AI стал частью производственного контура, а не витринным экспериментом. Если ассистент не возвращает пользователей, не закрывает повторяемые задачи и не вытесняет старые способы работы, он остаётся демонстрацией технологии. Ниже — практичная схема оценки, которую можно применять к внутренним LLM-инструментам, knowledge base чатам, помощникам поддержки и разработческим ассистентам.

Почему количество запросов вводит в заблуждение

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

Есть ещё один эффект: первые недели после запуска почти всегда дают всплеск любопытства. Люди проверяют, умеет ли чат писать письма, резюмировать документы, искать регламенты или генерировать SQL. Часть этих действий не связана с настоящей работой. Если в отчёт попадает только суммарное число обращений, пилот выглядит живым даже тогда, когда повторных пользователей почти нет.

Поэтому счётчик запросов стоит оставить на уровне технического мониторинга, а для решения о развитии продукта использовать метрики поведения и результата.

Три вопроса вместо одного большого числа

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

Второй вопрос: сколько пользователей работает с инструментом регулярно спустя месяц. Здесь полезны недельные активные пользователи по когортам: кто начал пользоваться ассистентом в первую неделю, какая доля активна через 7, 14 и 30 дней. Для корпоративного инструмента важна не ежедневная зависимость, а устойчивое возвращение к задачам, где AI действительно экономит время.

Третий вопрос: что люди перестали делать по-старому. Это самая сильная метрика, потому что она связывает внедрение с изменением процесса. Например, сотрудники поддержки меньше ищут ответы вручную в wiki, разработчики реже дергают соседнюю команду за типовыми инструкциями, аналитики перестают копировать однотипные данные между таблицами, а менеджеры не пишут черновики статусов с нуля.

Если на третий вопрос нет ответа, проект рискует остаться надстройкой, которая добавляет ещё один интерфейс, но не убирает ни одной операции.

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

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

поиск релевантного регламента по вопросу сотрудника;
подготовка черновика ответа в первой линии поддержки;
суммаризация инцидента по логам и сообщениям из чата;
генерация первичного SQL-запроса по описанию отчёта;
объяснение ошибки CI по логам сборки и истории изменений.

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

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

Какие события логировать с первого дня

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

первое использование и повторный визит;
выбранный сценарий или тип задачи;
факт принятия, копирования, редактирования или отклонения ответа;
оценка полезности, если она встроена в интерфейс и не мешает работе;
переход к источнику, документу, тикету или runbook;
время до результата и количество уточняющих запросов.

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

Для инженерного контура полезно связать эти события с техническими метриками: latency, стоимостью токенов, ошибками модели, долей fallback-ответов, timeout и отказов retrieval-слоя. Иногда низкое удержание объясняется не продуктовой проблемой, а тем, что ответ приходит через 40 секунд или RAG регулярно не находит актуальные документы.

Что делать, если повторного использования нет

Низкое удержание не означает, что AI не нужен. Оно означает, что текущая упаковка не попала в рабочий процесс. Первое действие — разобрать сессии по сегментам. Пользователи из разных отделов могут решать совершенно разные задачи, и среднее значение скроет полезный сценарий для небольшой группы.

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

Третье действие — встроить AI туда, где уже идёт работа. Отдельный портал проигрывает интеграции в helpdesk, IDE, Slack/Teams, GitLab, Grafana или внутреннюю CRM. Чем меньше переключений контекста, тем выше шанс, что ассистента будут использовать не ради эксперимента, а потому что он ускоряет конкретное действие.

Когда проект можно считать успешным

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

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

Для homelab и небольших команд логика та же. Личный LLM-бот в документации, ассистент для Ansible-плейбуков или чат по заметкам Obsidian полезен не тогда, когда к нему отправили сотню вопросов за вечер, а когда через месяц он остаётся в регулярном workflow и заменяет ручной поиск.

Итог

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

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