Компании собирают RAG за дни. Но сделать его достаточно надёжным для бизнеса куда сложнее

Поиск — часть инфраструктуры

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

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

Новая модель эмбеддингов не исправит данные

Когда качество поиска падает, первым делом может захотеться заменить модель эмбеддингов. Но проблема бывает проще: в одном документе продукт назван «Enterprise Security Gateway», в другом — «ESG», а в третьем — просто «шлюз». При этом действующие ограничения конфигурации могут лежать в таблице, которую система некорректно обработала.

Что нужно сделать:

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

Иначе система будет с впечатляющей семантической точностью находить не тот документ — и всё равно ошибаться.

Разбиение на фрагменты — архитектурное решение

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

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

Универсального размера фрагмента нет: способ индексации должен учитывать структуру источника.

Исследование корпоративного RAG за 2024 год показало, что даже сравнительно простые изменения содержимого базы знаний могут влиять на работу системы. Авторы также отметили важность наблюдения за ней и оценки результатов людьми.

Фрагменты нужно формировать по смыслу информации, а не по произвольному числу токенов.

Векторного поиска недостаточно

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

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

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

Это не значит, что каждой компании нужно сразу отказываться от векторного поиска. Разным запросам нужны разные способы поиска:

Архитектуру должен определять характер задач.

Оценивайте поиск отдельно от ответа

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

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

У неверного ответа может быть несколько причин:

Для каждой причины нужны свои исправления. Например, документация по оценке RAG в Amazon Bedrock разделяет оценку только поиска и оценку поиска вместе с генерацией. Среди метрик — релевантность контекста, охват, правильность, полнота и соответствие ответа источникам.

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

Опыт Ring с реальными данными

Рабочая система поддержки Ring показывает, как RAG ведёт себя на корпоративных данных.

В техническом материале за март 2026 года AWS описала систему RAG для поддержки клиентов Ring на нескольких языках и в 10 международных регионах. Задача была не только в переводе материалов: в каждом регионе отличались конфигурации продуктов, требования и сведения для поддержки.

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

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

Безопасность должна быть встроена в поиск

Права доступа особенно важны, когда RAG подключают к внутренним данным компании.

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

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

Безопасность должна быть частью самого поиска, а не очисткой ответа после генерации.

Актуальность — задача эксплуатации

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

Для рабочей системы нужно заранее определить:

Это в основном вопросы работы с данными и эксплуатации, но от них напрямую зависит качество системы ИИ.

Стоимость и задержка влияют на архитектуру

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

Больше контекста не всегда означает лучший контекст.

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

Из чего состоит рабочая RAG-система

Зрелую архитектуру RAG удобно рассматривать как набор связанных слоёв:

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

Главное — определить, кто отвечает за каждый слой и как команда поймёт, что он работает неправильно.

Нужен ли RAG по-прежнему

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

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

Архитектуру нужно подстраивать под задачу работы с информацией, а не наоборот. Языковая модель не исправит систему, которая передаёт ей неверные данные.

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

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

Абдулла Сайяд — автор и исследователь в области технологий.