RAG в ЗАКРОМА: интеллектуальный поиск по корпоративным данным

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

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

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

Для пилотирования такого сценария клиентам ЗАКРОМА доступна бесплатная превью-версия RAG-модуля в составе ЗАКРОМА.Хранение.

Корпоративные документы, смысловой поиск и возможности LLM 

Что такое RAG?

RAG расшифровывается как Retrieval-Augmented Generation, то есть «генерация, дополненная поиском».

В основе RAG лежит языковая модель, или LLM (Large Language Model). Это нейросеть, обученная работать с текстом: понимать запросы на естественном языке, находить связи между фрагментами информации и формулировать связный ответ. Именно LLM отвечает пользователю в привычной диалоговой форме. К таким моделям относятся, например, GigaChat и Qwen. 

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

RAG решает эту задачу в несколько этапов. Сначала система ищет в корпоративной базе фрагменты документов, которые наиболее близки к вопросу пользователя по смыслу. Затем найденный контекст передаётся языковой модели. LLM анализирует вопрос вместе с этими фрагментами и формирует ответ.

Например, сотрудник спрашивает: «Какой срок хранения первичной документации?». В документах компании может использоваться другая формулировка, например «срок хранения закрывающих документов». RAG ищет совпадение не только по отдельным словам, но и по смыслу, находит соответствующий фрагмент и передаёт его LLM.

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

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

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

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

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

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

Где применяется RAG

RAG особенно полезен там, где сотрудники регулярно ищут ответы в большом массиве внутренних материалов.

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

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

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

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

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

Анализ проектной документации. Команды быстрее находят решения, требования и ограничения в технических заданиях, протоколах, отчётах и проектных материалах.

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

Один из прикладных сценариев: интеллектуальный поиск по системе «1С:Документооборот»

Один из прикладных сценариев ЗАКРОМА.Хранение — интеллектуальный поиск по документам «1С:Документооборот», который дает возможность искать информацию не только по названию и реквизитам документа, но и по его содержанию.

Вместо просмотра нескольких договоров, служебных записок и приложений можно задать вопрос: «Какой срок исполнения согласован с контрагентом?», «В каких документах описан порядок приёмки?» или «Какие обязательства предусмотрены по этому проекту?».

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

Как это работает? 

При интеграции файлы документов сохраняются в S3-бакете ЗАКРОМА.Хранение. После загрузки объекта штатный webhook уведомляет RAG-модуль. Он извлекает текст, разбивает его на чанки, создаёт векторные представления и сохраняет их в PostgreSQL с расширением pgvector.

В такой архитектуре информационная система остаётся основной системой работы с документами и их реквизитами, а ЗАКРОМА.Хранение отвечает за S3-хранение файлов и предоставляет RAG-модулю данные для смыслового поиска.

Почему S3 подходит для базы знаний

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

S3-хранилище удобно использовать как базовый слой для таких данных. Документы остаются в исходном виде, а приложения получают доступ к ним через стандартный S3 API.

В архитектуре ЗАКРОМА.Хранение исходные документы находятся в S3-бакете. При появлении или изменении объекта хранилище формирует событие, которое запускает обработку в RAG-модуле. Сам файл остаётся первоисточником, а PostgreSQL с pgvector хранит подготовленный индекс для смыслового поиска.

Такое разделение позволяет независимо масштабировать хранение и AI-сервисы. Исходные документы не приходится переносить при замене embedding-модели или LLM. Один и тот же набор объектов можно использовать в разных конвейерах обработки, а загрузка нового файла автоматически запускает его индексацию.

Получается понятное разделение ролей: ЗАКРОМА.Хранение принимает и хранит данные, RAG-модуль занимается их подготовкой и поиском, PostgreSQL с pgvector хранит векторный индекс, а embedding-модель и LLM выполняют AI-часть обработки.

Как устроен RAG-модуль ЗАКРОМА.Хранение

Архитектура решения начинается с S3-хранилища. Документы находятся в выбранном бакете, а штатный механизм webhooks сообщает RAG-модулю о загрузке или изменении объекта.

RAG-модуль получает документ, извлекает из него текст и разбивает его на чанки. Затем каждый фрагмент передаётся embedding-модели, которая создаёт его векторное представление.

Векторы и связи с исходными файлами сохраняются в PostgreSQL с расширением pgvector. Когда пользователь задаёт вопрос, система выполняет обратную операцию: превращает вопрос в вектор, находит ближайшие фрагменты, формирует из них контекст и передаёт его вместе с вопросом в LLM.

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

Веб-интерфейс может работать как отдельное приложение или встраиваться в существующую корпоративную систему.

Индексация документов

Когда пользователь или бизнес-приложение загружает объект в выбранный бакет, ЗАКРОМА.Хранение сохраняет его и формирует событие. Webhook передаёт информацию о новом объекте RAG-модулю.

Модуль обращается к файлу, извлекает текст, разбивает его на чанки и передаёт их embedding-модели. Полученные векторы сохраняются в pgvector вместе со связью с исходным объектом.

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

В текущей версии RAG-модуль извлекает текст из PDF, DOCX, PPTX, XLSX, TXT и HTML. OCR не выполняется, поэтому скан-копии PDF и изображения без текстового слоя требуют предварительного распознавания внешним сервисом.

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

Как формируется ответ

Пользователь задаёт вопрос в веб-чате. RAG-модуль преобразует его в вектор с помощью embedding-модели и ищет наиболее близкие фрагменты в PostgreSQL.

Найденные чанки становятся контекстом для LLM. Модель получает вопрос и только ту часть корпоративных данных, которая относится к нему, после чего формирует ответ.

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

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

Облачные и локальные модели

RAG-модуль не привязан к одной embedding-модели или LLM. В превью-версии проверена работа с GigaChat и Qwen. Также можно подключить корпоративную модель, развёрнутую on-premises.

ЗАКРОМА.Хранение, RAG-модуль и PostgreSQL разворачиваются в инфраструктуре заказчика. Исходные документы и векторный индекс при этом остаются внутри корпоративного контура.

Где именно обрабатываются данные embedding-моделью и LLM, зависит от выбранной интеграции. При использовании облачного API необходимо учитывать требования информационной безопасности и правила передачи данных. Локальная модель позволяет выполнять обработку внутри инфраструктуры организации.

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

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

Что доступно в превью-версии

Превью-версия предназначена для пилотирования RAG на реальных документах клиента. Она предоставляется клиентам ЗАКРОМА бесплатно.

В неё входит автоматическая индексация документов из одного S3-бакета, обработка PDF с текстовым слоем, DOCX, PPTX, XLSX, TXT и HTML, настройка размера и перекрытия чанков, хранение векторов в PostgreSQL с pgvector и повторная векторизация изменённых файлов.

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

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

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

Что получает организация

RAG-модуль ЗАКРОМА.Хранение превращает корпоративные документы в источник знаний, с которым можно работать через обычный диалог.

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

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

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

ЗАКРОМА.Хранение в этой архитектуре становится основой для работы с корпоративными данными: хранит исходные объекты, передаёт события в RAG-модуль и предоставляет S3-интерфейс для бизнес-приложений. Поверх этого слоя можно подключать собственные embedding-модели и LLM, выбирая их с учётом требований к данным, инфраструктуре и качеству ответа.

Так корпоративное S3-хранилище превращается из места, где документы просто лежат, в основу для поиска, анализа и диалоговой работы с корпоративными знаниями.