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

Демонстрация генерации, дополненной поиском (RAG), способна увлечь кого угодно.

Берется несколько документов компании, помещаются в поисковую систему, релевантные фрагменты отправляются большой языковой модели (LLM), и задается вопрос. Ответ возвращается за считанные секунды, часто со ссылками на источники.

Затем систему подключают к реальным данным компании.

И вот тут начинается самое интересное.

Документы противоречат друг другу. Некоторые из них устарели. Полезная информация спрятана в электронных таблицах и отсканированных PDF-файлах. У разных сотрудников разные уровни доступа. Поисковый запрос, который безупречно работал на 10 000 документах, начинает вести себя совершенно иначе по мере роста базы знаний.

Именно здесь и начинается основная инженерная работа.

RAG остается практичным способом связать LLM с корпоративной информацией. Однако внедрение RAG в промышленную эксплуатацию — это не просто векторная база данных за текстовым запросом. Это вопросы качества данных, поиска, безопасности, оценки, актуальности, стоимости и эксплуатации.

Сама модель — это лишь одна из частей системы.

Поиск необходимо воспринимать как инфраструктуру

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

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

Корпоративные данные обычно устроены иначе.

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

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

Когда качество поиска падает, смена модели эмбеддингов кажется очевидным первым шагом.

Иногда это помогает.

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

Действия, которые необходимо предпринять:

• Определить, какой документ является авторитетным.

• Знать, когда старая политика была заменена новой.

• Исправить таблицы или другой контент, который был извлечен некорректно.

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

В противном случае вы рискуете построить систему, которая с впечатляющей семантической точностью извлечет не тот документ. И результат все равно останется неверным.

Чанкинг — это архитектурное решение

К разбиению на чанки (фрагменты) часто относятся как к простой настройке конфигурации.

Этого делать нельзя.

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

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

Универсального идеального размера чанка не существует. Структура источника должна определять то, как он индексируется.

• Руководствам по продуктам может пойти на пользу сохранение заголовков и разделов.

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

• Схемы баз данных могут иметь больше смысла в виде структурированных связей, а не обычного текста.

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

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

Векторный поиск полезен, но его недостаточно

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

Однако корпоративному поиску зачастую требуется большая точность.

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

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

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

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

• Концептуальные вопросы → семантический поиск работает хорошо.

• Точные идентификаторы → критически важно сопоставление по ключевым словам.

• Смешанные сценарии использования → комбинирование обоих подходов может быть более целесообразным.

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

Тестируйте поиск отдельно от финального ответа

Одна из самых распространенных ошибок при разработке RAG — судить о системе исключительно по ее финальному ответу.

Ответ может звучать убедительно даже в том случае, если была извлечена неверная информация.

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

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

• Изначальные данные были неверными?

• Документ был некорректно распарсен?

• Чанкинг уничтожил важный контекст?

• Поиск не смог найти релевантный фрагмент?

• Правильный фрагмент оказался слишком низко в выдаче?

• Найденные документы противоречили друг другу?

• Или модель просто не справилась, несмотря на наличие необходимых данных?

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

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

Кейс компании Ring показывает, что происходит при столкновении RAG с реальными данными

Система поддержки производства компании Ring служит отличным наглядным примером.

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

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

Интерес представляет вовсе не список продуктов AWS.

Интересна сама архитектура.

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

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

Управление правами доступа становится критически важным, когда система RAG подключается к внутренней информации компании.

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

С точки зрения поиска — это успех.

С точки зрения безопасности это может обернуться серьезным провалом.

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

• Личность пользователя должна проверяться до того, как защищенные данные попадут в контекст.

• Правила авторизации должны сопровождать поисковые запросы.

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

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

Актуальность данных — это операционная задача

Корпоративные знания постоянно меняются.

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

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

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

• Какие источники требуют обновления в режиме, близком к реальному времени?

• Как быстро изменения доходят до индекса?

• Что происходит при удалении авторитетного документа?

• Как обрабатываются устаревшие версии?

• Могут ли инженеры отследить, какая именно версия документа повлияла на ответ?

В основном это вопросы работы с данными и инфраструктурой, но они напрямую влияют на качество всей ИИ-системы.

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

Существует еще один компромисс, который легко упустить из виду на этапе прототипирования.

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

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

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

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

Что на самом деле необходимо производственной RAG-системе

Зрелую архитектуру RAG проще всего представить в виде нескольких взаимосвязанных уровней (слоев).

• Уровень источников (Source layer) — связывает корпоративные системы и отслеживает происхождение данных.

• Уровень обработки (Processing layer) — распознает, очищает и структурирует поступающий контент.

• Уровень индексации (Indexing layer) — создает представления, необходимые для поиска.

• Уровень поиска (Retrieval layer) — комбинирует семантические, ключевые или специализированные доменные сигналы.

• Уровень политик (Policy layer) — применяет правила идентификации и доступа до того, как информация с ограниченным доступом попадет к модели.

• Уровень оценки (Evaluation layer) — оценивает поиск и генерацию по отдельности.

• Уровень наблюдаемости (Observability layer) — фиксирует достаточно информации для безопасной диагностики сбоев.

• Уровень генерации (Generation layer) — превращает выбранный контекст в ответ или действие агента.

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

Главный вопрос звучит проще: кто отвечает за каждый отдельный компонент и как команда узнает о его сбое?

Главный вопрос вовсе не в том, умер ли RAG

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

Для корпоративных команд это, пожалуй, не самый полезный вопрос.

Гораздо важнее спросить себя: способна ли система стабильно доставлять правильную информацию нужной модели для правильного пользователя в нужный момент времени?

Иногда ответом будет классический RAG.

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

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

Никакая LLM не сможет компенсировать недостатки системы, которая скармливает ей неверную информацию.

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

RAG никогда не сводился исключительно к поиску.

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

Абдулла Сайяд (Abdullah Sayyad) — технический писатель и исследователь

Добро пожаловать в сообщество VentureBeat!

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

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