Почему токен — плохая единица бюджета

В RAG пользователь задаёт вопрос, система ищет фрагменты в базе знаний и модель формирует ответ со ссылками. В счёте провайдера заметнее всего токены, поэтому бюджет часто строят как «средняя длина запроса × цена модели». Такой расчёт пропускает подготовку документов, обновление индекса, хранение, поиск, rerank, повторы и человеческую проверку.

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

Формула проста:

**Стоимость подтверждённого ответа = все затраты RAG за период / число принятых ответов.**

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

Шесть строк реального счёта

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

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

**Хранение.** Оплачиваются или резервируются векторы, текстовые фрагменты, metadata, индексы фильтров, реплики, резервные копии и журналы. Qdrant отдельно показывает память векторов, payload и payload-индексов; каждый индекс фильтра занимает RAM и диск.

**Поиск.** На каждый вопрос создаётся embedding, выполняется фильтрация по правам, векторный или гибридный поиск и чтение фрагментов. В serverless-моделях стоимость может зависеть от операций и размера пространства поиска. Например, документация Pinecone разделяет read units, write units и storage.

**Rerank и генерация.** Reranker повышает релевантность, но добавляет вычисления. Затем модель получает системный промпт, историю и найденные фрагменты. Слишком большой top-k раздувает контекст и плату за вход, хотя качество может не вырасти.

**Контроль качества.** Низкая уверенность, отсутствие источника или чувствительный вопрос ведут к проверке человеком. Повторный вопрос и эскалация — часть себестоимости, а не «исключение за рамками AI».

Постоянные и переменные расходы

Для управления полезно разделить месячный счёт.

Постоянные затраты почти не меняются от числа запросов в пределах имеющейся мощности:

  • поддержка коннекторов и владельцев данных;
  • сервер или минимальная облачная ёмкость;
  • резервирование и мониторинг;
  • тестовый набор и регрессионные прогоны;
  • время инженера и администратора базы знаний.

Переменные растут с нагрузкой:

  • embedding пользовательского вопроса;
  • чтение и поиск;
  • rerank кандидатов;
  • входные и выходные токены;
  • автоматические повторы;
  • минуты ручной проверки и эскалации.

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

Модельный расчёт для базы знаний

Рассмотрим компанию с 10 000 вопросами сотрудников в месяц. Это иллюстрация, а не рыночная котировка. Все числа нужно заменить фактическими тарифами и полной стоимостью труда.

Месячные постоянные допущения:

  • подготовка источников и работа владельцев данных — 25 000 рублей;
  • индексация и плановые обновления — 8 000;
  • векторная база, хранение и резервирование — 12 000;
  • мониторинг и тестовые прогоны — 8 000;
  • десять часов инженера по 2 500 рублей — 25 000.

Итого постоянная часть — **78 000 рублей**.

Переменные допущения на один пользовательский вопрос:

  • embedding, поиск и чтение — 0,8 рубля;
  • rerank — 1,2 рубля;
  • генерация и автоматическая проверка — 1,5 рубля;
  • ручная быстрая проверка: 20% запросов × 3 минуты × 900 рублей в час — 9 рублей в среднем на каждый запрос;
  • эскалация эксперту: 10% × 8 минут × 900 рублей в час — 12 рублей.

Переменная часть — **24,5 рубля на запрос**, или 245 000 рублей в месяц. Общий расход равен 323 000 рублей.

Пусть 75% ответов приняты без повторного обращения: 7 500 полезных исходов. Стоимость подтверждённого ответа равна **43,1 рубля**. Если смотреть только на генерацию и поиск, получилось бы 3,5 рубля — занижение более чем в двенадцать раз.

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

Почему объём меняет цену нелинейно

При тех же допущениях 2 000 запросов дают 49 000 рублей переменной части и 127 000 общего расхода. При 75% принятия стоимость результата — около **84,7 рубля**: постоянная инфраструктура распределяется на малый поток.

При 50 000 запросов общий расход составит 1 303 000 рублей, а при 37 500 принятых ответов — около **34,7 рубля** за результат. Но такая линейная модель справедлива лишь пока хватает мощности и человеческая очередь сохраняет проценты и скорость.

В реальности возникают ступени:

  • новый сервер или реплика векторной базы;
  • отдельный rerank-сервис;
  • увеличение команды проверки;
  • более частая индексация;
  • рост резервного хранения;
  • длинные хвосты запросов и пиковая нагрузка.

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

Доля принятия важнее дешёвой генерации

Предположим, команда сократила контекст и сэкономила 0,7 рубля на генерации. При 10 000 запросов это 7 000 рублей. Если агрессивное сокращение снизило принятие с 75% до 68%, полезных ответов стало 6 800, а стоимость результата выросла, несмотря на меньший счёт модели.

Оптимизировать нужно совместно:

  • стоимость одного запроса;
  • долю ответов с корректными источниками;
  • долю принятых результатов;
  • повторные вопросы в течение рабочего окна;
  • время до ответа;
  • минуты человека на проверку.

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

Как размер индекса попадает в экономику

Векторная база — не безразмерное хранилище. Расход определяют число фрагментов, размер вектора, payload, репликация и индексы фильтров. Дубли документов и слишком мелкая нарезка одновременно увеличивают storage, индексацию и число кандидатов.

Qdrant рекомендует создавать payload-индексы только для полей, используемых в фильтрах: они ускоряют поиск, но занимают дополнительную память и диск. Фильтры по отделу, типу документа и уровню доступа имеют ценность; индексировать каждое редкое metadata-поле «на будущее» невыгодно.

Quantization снижает память векторов, но меняет компромисс между recall, скоростью и сжатием. Решение принимают после теста на своём золотом наборе, а не только по коэффициенту экономии RAM.

Практические рычаги:

  • удалять дубли до embedding;
  • обновлять только изменённые документы;
  • хранить хэш содержимого и версии pipeline;
  • выбирать chunk size по качеству, а не по максимальному числу фрагментов;
  • индексировать только реально используемые фильтры;
  • отделять горячие коллекции от архивных;
  • измерять стоимость полного восстановления индекса.

Когда rerank окупается

Reranker добавляет отдельный вызов модели или вычислительный сервис. Его нельзя включать автоматически во все маршруты. Сначала сравните базовый поиск и rerank на одинаковом наборе вопросов.

Для каждой конфигурации фиксируйте:

  • recall источника в top-k;
  • долю правильного первого фрагмента;
  • качество цитирования;
  • входные токены генерации;
  • задержку;
  • эскалации человеку;
  • стоимость подтверждённого ответа.

Rerank экономически полезен, если добавленная стоимость меньше сокращения лишнего контекста, повторов и проверки. Для простых точных запросов его можно пропускать; для неоднозначных — включать по маршрутизатору.

Какие события журналировать

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

  • идентификатор сценария и отдела;
  • версии индекса, embedding, retriever, reranker и LLM;
  • число кандидатов и переданных фрагментов;
  • входные и выходные токены;
  • время и стоимость каждого этапа;
  • сработавшие фильтры доступа;
  • результат автоматической проверки;
  • эскалацию, минуты человека и итоговое принятие.

Из этих событий строится отчёт не «сколько токенов потратили», а «сколько стоил принятый ответ по каждому процессу». Общие серверы и команды распределяют по измеряемому потреблению либо заранее описанному правилу.

Пилот с финансовыми воротами

**Ворота 1 — качество поиска.** На 100–300 реальных вопросах источник должен попадать в кандидаты с заданной полнотой. Иначе генерация маскирует проблему retrieval.

**Ворота 2 — полезный исход.** Сотрудники отмечают принятие, повтор и эскалацию. Только принятый ответ попадает в знаменатель.

**Ворота 3 — полный счёт.** Инфраструктура, данные, токены и человек собраны в одной модели. Разовые затраты на запуск показываются отдельно и амортизируются на выбранный срок.

**Ворота 4 — сравнение с процессом без RAG.** Измеряются время поиска сотрудником, стоимость ошибки и пропущенные обращения. Окупаемость появляется только относительно этой базы.

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

Управленческий вывод

Стоимость RAG нужно считать не по миллиону токенов, а по подтверждённому ответу. Включите в числитель подготовку и обновление данных, хранение, поиск, rerank, генерацию, повторы и время экспертов; в знаменатель — только принятые результаты.

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