Считать нужно результат, а не число запросов

У RAG-ассистента может быть много диалогов и почти ноль экономического эффекта — если сотрудники всё равно перепроверяют каждый ответ, исправляют неверные выдержки и поддерживают устаревшие документы. Поэтому полезная единица расчёта — не запрос к модели и не сгенерированный ответ, а обращение, которое действительно решено с приемлемым качеством и без лишней работы команды.

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

Модельный пример: 1 000 обращений в месяц

Предположим, небольшой сервисный отдел получает 1 000 типовых вопросов за месяц. После разбора выборки команда считает, что 60% из них относятся к утверждённым процедурам и продуктовым фактам, которые можно искать в базе. Это 600 потенциально подходящих запросов. Допустим также, что в пилоте 80% таких вопросов заканчиваются ответом, который пользователь принимает без исправления специалистом. Получается 480 самостоятельно решённых обращений.

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

Сравнивать нужно с фактическим сценарием «без ассистента». Если сотрудники отвечают не шесть минут, а две, потенциальный эффект заметно ниже. Если вопрос требует согласования, доступа к заказу или решения по исключению, генерация текста сама по себе не завершает процесс и минуты экономии нельзя засчитывать как закрытое обращение.

Формула полной стоимости

Для пилота достаточно прозрачной таблицы, а не сложной финансовой модели:

  • **Фиксированная часть:** внедрение, подготовка и очистка документов, подключение источников, настройка доступа, интеграция с чатом или CRM, базовая оценка качества.
  • **Индексация:** обработка новых и изменённых документов, эмбеддинги, расписание переиндексации и хранение индекса.
  • **Каждый диалог:** поиск, reranking при его использовании, объём найденного контекста, входные и выходные токены, повторные запросы и резервный вызов другой модели.
  • **Операционная часть:** мониторинг, логи, контроль прав, исправление источников, поддержка интеграций и дежурство при сбое.
  • **Человеческая часть:** проверка ответов, исправление базы, обработка эскалаций и управление изменениями процесса.

Условная формула: месячный TCO = фиксированные расходы периода + обновление базы + переменная стоимость запросов + трудозатраты на контроль и поддержку. Затем TCO делят на число обращений, которые действительно закрыты. Отдельно сравнивают это значение с полной стоимостью ручной обработки аналогичного обращения.

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

Как оценить качество без самообмана

Сначала зафиксируйте 50–100 реальных вопросов с обезличенными данными и ожидаемым правильным действием. Включите не только простые FAQ, но и вопросы с уточнением, устаревшей инструкцией, отсутствующим документом, конфликтующими версиями, запросом чужих данных и ситуацией, где правильный ответ — отказ или передача специалисту.

Результат полезно разложить на отдельные ступени:

  • **Нашёл ли поиск нужный источник?** Смотрите релевантность и полноту найденных фрагментов, отдельно отмечая вопросы, где правильного документа вообще нет.
  • **Опирается ли ответ на источник?** Проверяйте, нет ли утверждений, которых в найденном контексте нет, и ведут ли цитаты к актуальному фрагменту.
  • **Решает ли ответ задачу пользователя?** Правильная цитата ещё не означает понятный или полный ответ.
  • **Нужно ли вмешательство человека?** Записывайте, был ли ответ принят, исправлен, эскалирован или проигнорирован.
  • **Сколько это заняло?** Учитывайте задержку, повторные попытки, ручное ожидание и время на последующее обслуживание.

Документация Microsoft разделяет оценку шага поиска и оценку итогового ответа: отдельно рассматриваются извлечение документов, релевантность контекста, groundedness, релевантность и полнота ответа. Для точных метрик поиска нужны размеченные релевантные документы; без такой разметки можно начать с экспертной проверки небольшой выборки. Автоматический LLM-судья ускоряет сортировку, но не является безошибочной истиной — пограничные, дорогие или рискованные ответы стоит проверять человеком.

Недорогой план пилота

1. Выберите один узкий поток вопросов с повторяющимися ответами и ограниченным риском ошибки. Не начинайте с базы «всех документов компании».
2. Назначьте владельца источников. У каждой инструкции должны быть дата, версия, ответственный и понятный порядок снятия устаревшего материала.
3. Снимите исходную линию: число обращений, среднее время ответа, долю повторных контактов, эскалации и реальное время команды.
4. Соберите тестовую выборку и оцените качество поиска отдельно от качества генерации. На первом этапе достаточно ручной разметки небольшой выборки.
5. Ограничьте контекст: ищите только в нужном разделе, передавайте несколько наиболее полезных фрагментов и не запускайте повторные попытки бесконечно.
6. Запустите пилот с видимой ссылкой на источник, кнопкой «не помогло» и простым путём к специалисту.
7. После недели или двух сравните одинаковые типы обращений с исходной линией. Пересчитайте расходы по фактическим логам, а не по предполагаемому среднему числу токенов.

Когда вывод — не покупать RAG

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

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

Решение руководителя

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