Как посчитать бюджет RAG и не переплатить за модель

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

Retrieval-Augmented Generation (RAG) соединяет поиск по внутренним материалам с языковой моделью. Система находит подходящий фрагмент, формирует ответ и прикладывает ссылку. Если в архиве нет порядка, помощник будет так же аккуратно цитировать устаревшие сведения.

Поэтому до выбора архитектуры стоит оценить две вещи: сколько времени уходит на консультации коллег и можно ли доверять исходным данным. Первое определяет экономику, второе — объём подготовки к пилоту.

Когда RAG оправдан и когда окупается

Я бы начал с одной темы, по которой регулярно повторяются запросы: например, про отпуска, компенсации или выдачу доступов. При 100 обращениях за 30 дней и семи минутах на каждое процесс забирает почти 12 часов специалиста.

Дальше считаем окупаемость: сэкономленные часы умножаем на полную стоимость часа. При ставке 2500 ₽ получаем около 30 000 ₽ в месяц. Пилот за 1,5 млн ₽ в таком сценарии будет окупаться более четырёх лет даже без учёта поддержки. Для проекта это слишком долгий срок возврата инвестиций.

Экономика сходится, когда один помощник закрывает несколько похожих тем, обращений значительно больше или время эксперта обходится дороже. Пять сравнимых потоков из нашего примера дадут годовой эффект 1,8 млн ₽ и окупят запуск примерно за 10–13 месяцев. С учётом сопровождения этот период ещё немного увеличится.

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

Из чего складывается бюджет

По рабочей оценке Qtim, RAG-пилот для одного процесса через внешний API стоит от 1,5–2 млн ₽. Это ориентир для ограниченного набора источников, простого интерфейса и базовых ролей. Сумму уточняют после разбора архива, интеграций и требований к безопасности.

Для локальной установки того же масштаба нижняя граница обычно составляет около 3 млн ₽ без закупки серверов и последующей эксплуатации. Точная вилка зависит от числа пользователей, SLA и правил защиты данных. Например, моделям gpt-oss требуется от 16 до 80 ГБ памяти ещё до учёта резерва и пикового трафика.

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

Как подготовить данные к поиску

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

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

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

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

Права доступа: что проверить до запуска

Разграничение прав настраивают до запуска векторного поиска по внутренним документам. Группы присваивают при индексации, а данные о пользователе получают из SSO или корпоративного каталога. Перед отбором отрывков система уже знает, какие материалы доступны конкретному сотруднику.

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

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

Как выбирать модель по цене ошибки

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

Способ обработки определяют по цене ошибки и аудитории ответа. Типовые внутренние вопросы берёт быстрая и экономичная модель. Спорные случаи отправляют на второй проход или передают юристу, финансисту или владельцу процесса.

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

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

Как провести пилот и понять результат

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

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

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

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

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

В кейсе Morgan Stanley внутренний помощник искал ответы в базе из 100 000 документов, а им пользовались более 98% команд финансовых консультантов. До масштабирования эксперты задавали реальные вопросы и проверяли, нашла ли система нужный источник и точно ли передала его смысл.

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