RAG для бизнеса: как выбрать архитектуру, оценить качество и не переплатить за сложность

Разбираем, что влияет на качество, скорость и стоимость AI-решения. Статья поможет понять, как устроена RAG-система, подходит ли она под ваши задачи и что учесть, чтобы сократить затраты на разработку.

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

Сократить время поиска до нескольких минут помогают AI-решения на основе RAG. LLM подключается к корпоративным источникам и отвечает по ним на запросы пользователей.

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

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

Какие задачи решает RAG и всегда ли он нужен

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

Сегодня RAG — основа LLM-агентов, которые работают с корпоративными данными. У этого метода есть преимущества по сравнению с обычной генерацией, когда модель отвечает по исходному датасету. Так компании, которые используют RAG, решают следующие задачи:

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

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

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

Типы RAG-пайплайнов и как выбрать подходящий

Глобально RAG делят на классический и агентский. Оба пайплайна работают с каталогом данных, но по-разному управляют поиском и контекстом для генерации ответа.

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

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

Агентский RAG более гибкий и адаптивный. Может отвечать как на простые, так и на сложные аналитические запросы, для которых нужно объединить несколько фактов из разрозненных источников.

Сравнение типов RAG

Критерий	Классический	Агентский
Скорость и стоимость	Быстрее отвечает. Дешевле и проще в разработке, тестировании и поддержке	Работает медленнее. Сложнее архитектура и проверка качества, больше возможных точек отказа
Тип запросов	Подходит для простых вопросов, ответ на которые есть в одном-двух фрагментах	Лучше справляется со сложными запросами, где нужно связать несколько фактов
Работа с источниками	Выполняет поиск по заранее заданной схеме	Итерактивный цикл с обратной связью, которым управляет LLM
Стабильность	Проще воспроизвести результат и предсказать поведение системы	Есть уязвимости: избыточный поиск или ложный выбор простого пути для сложного запроса
Проверка ответа	В базовой схеме нет самопроверки и повторного поиска	Может проверить результат, скорректировать вид поиска и запустить новую итерацию

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

«Обычно используют такую SOTA-стратегию: в систему добавляют маршрутизатор, который  направляет простые вопросы в классический RAG, а сложные — в агентский. Чаще всего это соотношение 80 и 20% соответственно. Это позволяет не запускать более дорогой агентский цикл без необходимости», — Екатерина Пославская, ML-разработчик KTS.

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

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

Сначала система извлекает из документов текст, таблицы и другие данные. Затем делит эти материалы на чанки — фрагменты, по которым будет искать информацию.

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

Размер чанка зависит от содержания документов и запросов пользователей. Это всегда компромисс между точностью и полнотой контекста. Для коротких вопросов, например о расположении банкоматов или обновлении приложения, может быть достаточно 200 токенов. В рабочих системах обычно используют чанки размером 512–1024 токена, а для насыщенных информацией материалов, например юридических документов, — 1024–2048 токенов.

Между соседними чанками обычно оставляют пересечение — около 10% от их размера. Оно помогает сохранить смысл на границе фрагментов.

Далее система с помощью embedding-модели преобразует чанки в векторы и сохраняет их в хранилище. Так формируется векторный индекс: упорядоченный каталог корпоративных данных.

Как работает поиск в RAG и какой подход выбрать

Когда пользователь задаёт вопрос, система обрабатывает его и обращается к индексу. Она находит релевантные чанки, ранжирует их и формирует ТОП-N — это контекст для языковой модели.

Алгоритм поиска определяется структурой индекса и задачей:

• векторный находит чанки, близкие к запросу по смыслу;
• полнотекстовый (BM25) ищет точные совпадения слов;
• гибридный объединяет векторный и полнотекстовый поиск;
• графовый учитывает сущности и связи между ними;
• мультимодальный позволяет искать по текстам, таблицам, формулам и изображениям.

Подход	Как работает	Для каких задач подходит	Ограничения
Векторный	Находит близкие к запросу векторы в хранилище	Вопросы на естественном языке с разными формулировками	Хуже справляется с точными терминами и названиями
Полнотекстовый (BM25)	Находит точные совпадения слов из запроса и учитывает частотность	Вопросы с отраслевыми терминами, названиями и ID	Не всегда распознаёт смысловую близость и разные формулировки одной мысли
Гибридный	Комбинирует векторный и полнотекстовый поиск, сводит результаты в общий ТОП	Учитывает одновременно смысл запроса и важные ключевые слова	Требует поддерживать две структуры данных, не учитывает связи между найденными чанками
Графовый	Выделяет сущности и отношения из чанков и извлекает связи между ними	Для сложных аналитических запросов, где важно учитывать разрозненные факты	Сложнее и дороже в разработке и поддержке
Мультимодальный	Хранит материалы разных форматов в едином индексе	Учитывает данные из текста, таблиц и изображений	В чистом виде пока редко встречается в рабочих системах

 

Лучше начинать с гибридного индекса — это оптимальный вариант по точности и стоимости. Графовый поиск стоит подключать, когда уровень качества ответов неудовлетворительный и тесты показали, что причина не в исходных данных.

Схематическое изображение графа

 

«Графовый поиск может быть альтернативой агентскому RAG для сложных аналитических запросов. Например, когда в одной статье указаны условия кредита, а в другой — есть информация о льготах. Он найдёт эту связь и объединит информацию.

Но создавать графовые базы сложнее и дольше. Появилась новая статья, и нам нужно перестроить весь граф. Это влияет на стоимость разработки и поддержки. Частые обновления обходятся дорого», — добавляет Екатерина Пославская.

Генерация: как управлять ответом LLM

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

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

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

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

На результат также влияют параметры генерации:

• Temperature: определяет вариативность ответа. Для фактологических задач обычно устанавливают значение от 0 до 0,3, чтобы результаты были более предсказуемыми.
• Max tokens: ограничивает максимальное количество токенов, которое можно потратить. Это помогает контролировать расходы на генерацию.
• Citation enforcement: требует, чтобы модель подтверждала информацию ссылками на источники и приводила цитаты при необходимости.

Дополнительно можно проверять ответы с помощью LLM, которая выступает в роли судьи. Она оценивает черновик, созданный основной моделью, по параметру faithfulness — соответствие найденному контексту. Это помогает обнаружить утверждения, которых не было в переданных чанках, и снизить риск галлюцинаций.

Как оценивать качество RAG-системы: практический подход

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

На практике оценку качества RAG упрощают и ускоряют. Для этого используют связку LLM-as-a-judge + экспертная валидация и проходят несколько этапов.

1. Собирают репрезентативный набор запросов. Обычно достаточно 50–200 типовых вопросов и ответов. Например, реальные обращения из службы поддержки или HR.

2. Прогоняют набор через RAG-систему. Сохраняют найденные чанки, ссылки на источники и ответы модели. Эти данные понадобятся для проверки.

3. Оценивают качество ответов.  LLM-судья проверяет результаты по заранее заданным критериям. Например, таким:

• correctness — правильно ли система ответила по существу;
• completeness — полностью ли раскрыла вопрос;
• groundedness — насколько опирается на предоставленный контекст без фантазий;
• conciseness — много ли воды в ответе;
• citation quality — если требуется цитирование.

Обычно для оценки используют бинарную шкалу «хорошо — плохо». Но наш опыт показывает, что лучше выставлять баллы от 1 до 10. Это позволяет анализировать качество ответов по разным критериям и помогает понять, где есть узкие места.

4. Эксперт проверяет результаты. На этапе предпродакшена специалист заказчика оценивает всю выборку и правит ответы. Это занимает намного меньше времени, чем составление эталонного датасета с нуля.

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

В продакшене продолжают следить за уровнем качества работы RAG-системы. Эксперт вручную проверяет 10–20% выборки. Например, разбирает сложные кейсы или случаи, когда LLM-судья поставила от 4 до 6 баллов. Специалист определяет причины низких оценок, и команда разработки устраняет недостатки.

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

5 реальных проблем RAG-систем и как их исправить

Из практики сотрудников компании KTS собрали основные сложности, с которыми компании сталкиваются после запуска:

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

Чтобы поддерживать качество, нужна гигиена данных. Раньше такая работа требовала значительных ресурсов со стороны заказчика. Сейчас часть процесса можно автоматизировать с помощью ИИ. Например, мы в KTS используем Data Validator: он находит дубли и возможные противоречия в базе знаний. Эксперт оценивает результаты проверки и решает, какие данные нужно исправить, объединить или удалить.

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

2. Низкое качество ответов. Сначала проверяют, попал ли нужный факт в найденные чанки. Если нет, проблема в поиске. Чтобы её исправить, расширяют и структурируют запрос, меняют параметры ранжирования и делят базу на тематические разделы.

Если дело не в поиске, дорабатывают генерацию: промпт, температуру, правила цитирования и самопроверку.

3. Медленные и дорогие ответы. Снизить затраты помогают кэширование одинаковых и похожих запросов, маршрутизация вопросов и оптимизация контекста. Например, можно уменьшить количество чанков в ТОП-N или разбить слишком крупные фрагменты, чтобы LLM не получала лишние данные.

4. Галлюцинации и вымышленные цитаты. Сегодня LLM стали значительно умнее, поэтому чаще проблема в исходных данных. Например, модель отвечает по реальному документу, но в нём есть опечатка или неактуальная информация.

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

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

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

Чтобы ускорить разработку AI-решений на основе RAG, KTS использует AI Platform  это единый стек из трёх платформ для работы с агентами, данными и LLM. Готовые компоненты позволяют быстрее переходить от прототипа к продакшену и запускать новых агентов на общей инфраструктуре.