Расширенные возможности RAG в продакшене: архитектура, инструменты и связанные с ними компромиссы.

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

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

Краткий обзор процесса

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

Загрузка данных

Локальные файлы. Python с библиотеками pathlib, PyPDF, python-docx, openpyxl и pandas позволяет экономично обрабатывать PDF-файлы, документы Word, таблицы, файлы CSV и простой текст, а также легко интегрироваться в пакетные задания. Однако каждый формат требует собственного парсера; сканированные и сложные PDF-файлы нуждаются в специализированных методах извлечения данных, а крупные задания — в параллельной обработке и поэтапном выполнении.

Хранилище объектов. Amazon S3, Google Cloud Storage и Azure Blob Storage обеспечивают надежное и масштабируемое хранение больших коллекций данных и идеально сочетаются с асинхронным захватом информации. Расходы связаны с настройкой облачных сервисов, реализацией механизмов контроля доступа, а также с самим хранением и передачей данных, которые увеличиваются по мере масштабирования.

Источники в формате Web и API. Инструменты вроде requests или httpx, BeautifulSoup, Playwright и Firecrawl обеспечивают актуальность базы знаний путем захвата контента с сайтов, API и динамических страниц. Структура сайтов может меняться, страницы с большим количеством JavaScript требуют автоматизации браузера, а процесс краулинга сопряжен с ограничениями по частоте запросов, наличием дубликатов и неравномерным качеством контента.

Анализ и извлечение

Unstructured поддерживает PDF, Word, HTML, PowerPoint, изображения и многое другое, выделяя такие элементы, как заголовки, абзацы и таблицы, что делает его хорошим универсальным инструментом. Он работает медленнее, чем простые методы извлечения текста, и с документами сложной структуры может потребоваться специальная обработка.

PyMuPDF быстро извлекает текст и метаданные из PDF-файлов с текстовой структурой и легко интегрируется в код на Python. Это не полноценная система понимания документов, поэтому для сканированных файлов требуется OCR, а сложные макеты или таблицы нуждаются в дополнительной обработке.

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

OCR и извлечение на основе визуального анализа

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

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

Модели, объединяющие визуальное восприятие и язык, такие как модели класса GPT-4, Gemini и семейство Qwen-VL, понимают текст, изображения, диаграммы и структуру страницы, что помогает в ситуациях, когда одного только OCR недостаточно для сохранения визуального контекста, и позволяет использовать мультимодальные подходы к обработке информации. Они стоят дороже классических OCR-систем, работают медленнее и генерируют недетерминистичные результаты, которые необходимо проверять.

Разбиение на фрагменты

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

• Рекурсивное разделение по символам (RecursiveCharacterTextSplitter из LangChain) — это надежный базовый вариант, который пытается соблюдать границы абзацев и предложений и легко настраивается. Он работает с синтаксисом, а не с смыслом, и фиксированный размер не подойдет для всех документов.
• Разделение на токены предусматривает формирование фрагментов по количеству токенов модели, что помогает соблюдать ограничения окна контекста. Границы токенов не всегда совпадают с семантическими границами.
• Семантическая фрагментация определяет смену тем на основе сходства, благодаря чему связанные идеи остаются вместе лучше, чем при использовании фиксированных размеров. Она требует больше вычислительных ресурсов, нуждается в эмбеддингах и зависит от установленного порога.

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

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

Метаданные

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

Эмбеддинги

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

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

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

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

Cohere Embed — это управляемый API с хорошими возможностями мультиязычного и корпоративного поиска в зависимости от версии модели; его легко развернуть. Однако он влечет за собой затраты на API и необходимость использования внешних зависимостей.

Jina embeddings — это модели, ориентированные на поиск; некоторые из них поддерживают длинные контексты и несколько языков. Их функциональность варьируется в зависимости от версии, а модели с открытым исходным кодом требуют инфраструктуры для хостинга.

Базы данных векторов

• pgvector добавляет возможность поиска векторов в PostgreSQL, объединяя реляционные данные, метаданные и векторы в одном месте, что отлично подходит, если приложение уже использует Postgres. Для очень больших объемов векторных данных могут потребоваться специализированные системы, а масштабирование становится сложнее при высокой нагрузке.
• Pinecone — это управляемая база данных векторов, которая масштабируется без необходимости настройки инфраструктуры и обеспечивает удобные инструменты фильтрации для производственного использования. Вы платите за услугу, полагаетесь на поставщика и теряете часть контроля над системой.
• Qdrant доступен в виде open source или как сервис в облаке, хорошо справляется с фильтрацией по метаданным, поддерживает плотный и гибридный поиск и подходит для самостоятельной развертки RAG. Самостоятельная развертка подразумевает необходимость в управлении операциями, а распределенные конфигурации требуют тщательного планирования мощностей.

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

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

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

Извлечение данных

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

BM25 — это мощный лексический метод, отлично подходящий для точных терминов, имен, идентификаторов и технических ключевых слов; к тому же он прост в использовании и понятен. Он не учитывает семантическое сходство, поэтому синонимы и парафразы могут остаться незамеченными.

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

Трансформация запросов

• Переписывание запроса преобразует разговорную или нечеткую информацию в формат, удобный для поиска, что способствует задаванию дополнительных вопросов. Некорректная переработка может привести к потере ключевой информации, а также увеличить задержку и затраты ИИ-модели.
• Поиск с несколькими запросами предполагает, что модель генерирует несколько альтернативных запросов и выполняет поиск для каждого из них, что повышает точность результатов и позволяет учитывать различные формулировки. Однако это влечет за собой большее количество запросов к системе поиска, увеличение задержек и затрат, а иногда — получение нерелевантных результатов.
• HyDE (Hypothetical Document Embeddings) генерирует вымышленный ответ и встраивает его в формат, подходящий для поиска, что может помочь при решении сложных задач или в ситуациях, когда лексика вопроса сильно отличается от лексики документов. Для этого требуется дополнительный вызов ИИ-модели, а плохо составленный вымышленный документ может исказить результаты поиска.

Слияние результатов

Слияние рангов по принципу взаимности объединяет ранги нескольких поисковых механизмов. Этот метод прост в реализации, надежен и хорошо работает как с плотными данными, так и с BM25; к тому же он не требует сопоставимости оценок из разных систем. Он добавляет этап формирования рангов, но при этом имеет параметры для настройки.

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

Переупорядочивание

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

Методы переранжирования с использованием кросс-энкодеров, такие как BGE Reranker, Cohere Rerank и Jina Reranker, оценивают каждую пару запрос-документ совместно, обычно показывая лучшие результаты, чем простое сравнение по эмбеддингам, и хорошо работают после гибридного поиска. Они дороже в использовании, чем векторный поиск, поэтому их следует применять только к ограниченному списку кандидатов.

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

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

Компрессия контекста

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

Генерация

Популярными вариантами для практического использования являются модели OpenAI, Anthropic Claude, Google Gemini, Meta Llama и Qwen. Они обеспечивают высокую способность к логическим рассуждениям, а запросы могут направляться в зависимости от стоимости, задержек и сложности задачи. Модели через API связаны с затратами и зависимостью от поставщика, открытые модели требуют инфраструктуры, а крупные модели увеличивают задержки и стоимость обработки.

Фреймворки

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

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

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

Продвинутые паттерны

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

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

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

Структурированные данные

Text-to-SQL позволяет модели преобразовывать вопросы на естественном языке в запросы к структурированным базам данных, что отлично подходит для анализа свежих данных. Однако генерируемый SQL может быть неверным или небезопасным, поэтому требуется извлечение схемы базы данных, ее проверка и контроль доступа.

Гибридный текст и SQL RAG использует векторное или поисковое по ключевым словам для обработки неструктурированных знаний и SQL для структурированных данных, позволяя работать с PDF-файлами, документами, CSV-файлами и базами данных в рамках одной системы. Это требует переключения между режимами, что затрудняет тестирование и обеспечение безопасности.

Оценка

Промышленная система требует оценки как на уровне поиска, так и на уровне генерации контента.

Показатели поиска (Recall@K, Precision@K, MRR, NDCG и коэффициент точности) позволяют определить, нашел ли поисковый механизм правильные доказательства. Показатели генерации (степень соответствия, релевантность ответа, корректность ответа, релевантность контекста, точность контекста и запоминание контекста) позволяют оценить, правильно ли модель использовала эти доказательства.

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

Наблюдаемость

LangSmith отслеживает цепочки операций, запросы к базе данных, промпты и результаты, помогая отлаживать работу пайплайнов и сравнивать эксперименты. Это управляемая платформа, при использовании которой необходимо учитывать затраты и вопросы конфиденциальности. Langfuse предоставляет возможности отслеживания, управления промптами и анализа метрик в формате с открытым исходным кодом для самостоятельной установки или использования в облаке; при этом ответственность за самостоятельную установку лежит на пользователе, а также требуется наличие соответствующих инструментов. OpenTelemetry — это открытый стандарт для отслеживания операций, анализа метрик и логов, позволяющий интегрировать технологию RAG в существующую инфраструктуру, но при этом требуется больше технических усилий, чем при использовании готовой платформы.

Кэширование и производительность

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

Безопасность

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

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

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

Загрязнение данных. Документы из ненадежных источников могут быть внесены с целью намеренного введения в заблуждение.

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

Развертывание

Типичными компонентами являются FastAPI для слоя API, Docker для пакетизации, Kubernetes для оркестрации в крупном масштабе, Redis для кэширования, PostgreSQL для хранения реляционных метаданных, S3, GCS или Azure Blob для хранения объектов, Prometheus для сбора метрик, Grafana для создания панелей управления, OpenTelemetry для отслеживания и MLflow для фиксации результатов экспериментов. Цель — создать систему RAG, которая будет воспроизводимой, наблюдаемой, масштабируемой и поддающейся обслуживанию, а не просто кажущуюся точной в ноутбуке.

Практический набор инструментов

Надёжная универсальная архитектура может оставаться довольно простой. Документы проходят обработку с использованием Unstructured, PyMuPDF или PaddleOCR, затем — разбиение на части с учётом структуры или рекурсивное разбиение, после чего применяются эмбеддинги от OpenAI, BGE, E5 или Cohere. Далее данные обрабатываются с помощью pgvector, Qdrant или Pinecone. Поиск осуществляется с использованием алгоритма BM25 в сочетании с плотным поиском; результаты объединяются с помощью алгоритма RRF, переупорядочиваются с помощью кросс-кодера, компрессируются и передаются в ЯЗЫК БОЛЬШИХ МОДЕЛЕЙ, при этом указываются цитаты для обоснования. Качество оценивается с помощью Ragas и человеческого рецензирования, в то время как LangSmith, Langfuse или OpenTelemetry отслеживают процесс выполнения.

Не каждой системе нужны все компоненты. Небольшая внутренняя база знаний может обойтись с PostgreSQL, pgvector, эмбеддингами и ЯЗЫКОМ БОЛЬШИХ МОДЕЛЕЙ. Гибридный поиск, переупорядочивание результатов, агентные циклы, поиск в графах и мультимодальная обработка добавляются только тогда, когда оценка показывает, что более простая архитектура недостаточна.

Выбор инструмента для задачи

• Простой текст в PDF: PyMuPDF. Смешанные типы документов: неструктурированный формат. Сканирование: PaddleOCR. Визуально сложные страницы: модель визуального понимания языка.
• Базовое разделение на части: рекурсивный разделяющий инструмент. Семантические границы: семантическое разделение. Родительский и дочерний контекст: поиск в рамках родительско-дочерних связей.
• Управляемые векторные представления: OpenAI или Cohere. Открытые векторные представления: BGE или E5.
• Уже доступно в PostgreSQL: pgvector. Управляемый хранилище векторов: Pinecone. Самостоятельное хранение: Qdrant. Прототипы: Chroma или FAISS.
• Поиск на основе смысла: плотные векторы. Точные ключевые слова: алгоритм BM25. Надежное покрытие данных: гибридный подход. Объединение рейтингов: алгоритм RRF. Повышение точности: кросс-кодер для переранжирования. Уменьшение количества дубликатов: алгоритм MMR.
• Сложные многоэтапные вопросы: агентный подход RAG. Связи между сущностями: Graph RAG. Таблицы и базы данных: преобразование текста в SQL.

Оценка: Раги. Отслеживание: LangSmith или Langfuse. Стандартная телеметрия: OpenTelemetry. API высокой масштабируемости: FastAPI с Docker или Kubernetes.

Начните с малого

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

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

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