В последние годы мы стали свидетелями настоящей революции в области искусственного интеллекта. Генеративные языковые модели, такие как GPT, Claude и другие, показали невероятные возможности в понимании и генерации текста. Однако у них есть существенное ограничение: они работают только с информацией, на которой были обучены, и не имеют доступа к актуальным данным или корпоративным знаниям. Именно здесь на сцену выходят RAG-агенты — технология, которая объединяет мощь больших языковых моделей с возможностью работы с реальными данными.
Что такое RAG-агенты?
RAG (Retrieval-Augmented Generation) — это архитектурный подход, который позволяет языковым моделям получать доступ к внешним источникам информации в реальном времени. Вместо того чтобы полагаться исключительно на знания, заложенные в модель во время обучения, RAG-агент сначала ищет релевантную информацию в базе знаний, документах или других источниках данных, а затем использует эту информацию для генерации ответа. По сути, это создает "память" для AI-системы, которая может быть постоянно обновляемой и специфичной для конкретной задачи или организации.
Для чего используются RAG-агенты?
Области применения RAG-агентов практически безграничны. Они используются в корпоративных чат-ботах, которые могут отвечать на вопросы о внутренней документации, политиках и процедурах компании. В сфере образования они помогают студентам находить информацию в учебных материалах и научных статьях. В медицине RAG-агенты могут анализировать медицинские записи и исследования для поддержки принятия решений. Юридические фирмы используют их для поиска прецедентов и анализа документов. Техническая поддержка, консалтинг, исследовательская деятельность — везде, где требуется работа с большими объемами структурированной и неструктурированной информации, RAG-агенты находят свое применение.
Почему RAG-агенты так популярны сейчас?
Популярность RAG-агентов объясняется несколькими ключевыми факторами. Во-первых, они решают проблему "застывших знаний" — языковые модели больше не ограничены информацией на момент их обучения. Во-вторых, они обеспечивают прозрачность: пользователь может видеть, откуда агент взял информацию, что критично для бизнес-приложений. В-третьих, RAG-агенты относительно просты в реализации по сравнению с дообучением моделей, что делает их доступными для компаний любого размера. Наконец, они позволяют создавать специализированные AI-системы без необходимости обучать собственную модель с нуля, что экономически выгодно и технически осуществимо. Помимо этого, RAG-агенты — самый дешевый вход в мир ИИ для компаний, которые не хотят или не могут загружать свои документы в облачные сервисы, а современные реалии требуют ускорения и оптимизации рабочего времени сотрудников. Для работы с RAG-агентами нужно не очень мощное железо, вполне достаточно и домашних десктопных решений на базе Ryzen 7950X (9950X) и видеокарт начиная даже с RTX 3090. Для работы агента при ответах на вопросы по загруженным базам знаний ее вполне достаточно, ведь для этого успешно используют модели всего на 7B параметров, которые занимают в памяти видеокарты всего 5,3 ГБ, и чипа RTX 3090 вполне достаточно, чтобы достаточно быстро обрабатывать их внутри себя. Но у нее есть существенный недостаток. По скорости загрузки документов в базу знаний RAG-агента она существенно уступает видеокартам RTX 4090 и RTX 5090. Это достаточно ресурсоемкий процесс, и если вам нужно поместить в базу знаний значительный объем информации, вы можете потратить на это не один час, день или даже неделю. Все зависит от типа загружаемых документов, их структуры, наличия ссылок на другие документы и т.д.
В этой статье мы подробно рассмотрим архитектуру RAG-агентов, их практическое применение, лучшие практики разработки и будущее этой технологии, которая уже сегодня меняет то, как мы взаимодействуем с информацией и искусственным интеллектом.
С чего начать.
Я как всегда начал с изучения уже доступной информации в интернете по RAG-агентам. Сразу приходит понимание что софт для реализации таких агентов очень быстро эволюционирует и делая такое решение в конце 2025 года нужно понять, в чем отличия первых реализаций и текущих. Основное отличие в том, как и при помощи чего происходит процесс embedding. Embedding это процесс векторизации или по другому загрузки ваших документов в векторную базу знаний.
Что такое процесс Embedding?
Embedding (встраивание, или векторизация) — это процесс преобразования текстовой информации в числовые векторы — последовательности чисел, которые математически представляют смысл и контекст текста. Представьте, что каждое слово, фраза или документ превращается в точку в многомерном пространстве, где близкие по смыслу тексты располагаются рядом друг с другом, а разные по содержанию — далеко.
Процесс embedding происходит с помощью специальных моделей — энкодеров, которые обучены понимать семантику языка. Когда вы загружаете документ в RAG-агент, он разбивается на небольшие фрагменты (чанки) — обычно это параграфы или предложения определенного размера (chunk size). Важным параметром при разбиении является chunk overlap — перекрытие между соседними чанками. Например, если chunk size составляет 500 токенов, а chunk overlap — 100 токенов, то второй чанк начнется с 400-го токена первого чанка, создавая перекрытие в 100 токенов. Это необходимо для того, чтобы не терять контекст на границах разбиения: информация, которая находится на стыке двух чанков, будет присутствовать в обоих, что повышает вероятность правильного поиска и понимания связей между фрагментами текста. Каждый фрагмент затем пропускается через модель embedding, которая преобразует его в вектор — массив чисел определенной размерности (dimension), например, из 384, 768 или 1536 чисел. Эта размерность определяет, сколько чисел будет в массиве, представляющем смысл текста. Эти числа не случайны: они кодируют смысловое содержание текста, его тематику, стиль и контекст.
Важно понимать, что качество embedding напрямую влияет на качество работы RAG-агента. Современные модели embedding, такие как OpenAI Embeddings, Cohere, или открытые решения вроде BGE, E5, способны улавливать тонкие смысловые связи между текстами. Например, они понимают, что фразы "автомобиль" и "машина" семантически близки, даже если это разные слова. Это позволяет системе находить релевантную информацию даже когда пользователь формулирует вопрос иначе, чем в исходных документах.
Что такое векторная база знаний?
Векторная база знаний (Vector Database) — это специализированная база данных, предназначенная для хранения и быстрого поиска векторных представлений документов. В отличие от традиционных реляционных баз данных, которые ищут точные совпадения по ключам или индексам, векторные базы данных используют математические операции для поиска похожих векторов.
Принцип работы векторной базы основан на вычислении расстояний между векторами в многомерном пространстве. Наиболее распространенные метрики — косинусное сходство, евклидово расстояние или скалярное произведение. Когда пользователь задает вопрос RAG-агенту, его запрос также преобразуется в вектор через ту же модель embedding. Затем векторная база ищет наиболее близкие по смыслу векторы из хранящихся документов, используя алгоритмы приближенного поиска ближайших соседей (ANN — Approximate Nearest Neighbor).
Популярные векторные базы данных включают Pinecone, Weaviate, Qdrant, Milvus, Chroma и другие. Каждая из них оптимизирована для быстрого поиска в больших объемах векторных данных, используя различные техники индексации — от инвертированных индексов до графовых структур и квантования векторов. Это позволяет находить релевантную информацию за миллисекунды даже в базах, содержащих миллионы документов.
Ключевое преимущество векторной базы знаний в контексте RAG-агентов — это способность находить семантически похожие документы, а не просто тексты с совпадающими ключевыми словами. Это означает, что система может найти ответ на вопрос, даже если в исходных документах используется другая формулировка, но тот же смысл. Именно это делает RAG-агенты такими мощными инструментами для работы с неструктурированной информацией.
Еще раз, давайте закрепим. В отличие от реляционных баз данных (таблицы Excel или SQL-базы данных) векторная база данных работает по-другому. При поиске в реляционных базах данных вы найдете только точные совпадения или текстовые паттерны, соответствующие вашему запросу. Если выполнять поиск по запросу "авто", то при удачном поиске вы найдете слова, содержащие эту подстроку: автомобиль, автосервис, автомастерская. Но если выполнить такой же поиск в векторной базе данных, вы можете найти семантически связанные понятия: водитель, сервис, замена резины, бензин, ДВС, коробка передач, полный привод — даже если в этих словах нет подстроки "авто".
Ключевое отличие заключается в принципе поиска: реляционные базы данных ищут по формальным признакам (точное совпадение, подстрока, регулярное выражение), а векторные базы данных ищут по смыслу, используя математические представления семантики текста. Это становится возможным благодаря тому, что каждый текст преобразуется в вектор через модель embedding, которая "понимает" смысловые связи между словами и понятиями. Поэтому векторная база может найти релевантную информацию даже тогда, когда в тексте используются совершенно другие слова, но с тем же смыслом.
Эволюция Embedding документов в RAG-агентах: от простого chunking до графовых решений
Эволюция методов embedding документов для RAG-агентов прошла несколько ключевых этапов, каждый из которых решал проблемы предыдущего подхода и открывал новые возможности для работы с информацией. Понимание этой эволюции критично для выбора правильного решения в зависимости от ваших задач и требований.
Этап 1: Простое разбиение на чанки с overlap
Первые RAG-агенты использовали максимально простой подход к обработке документов: механическое разбиение текста на фрагменты фиксированного размера (chunking) с небольшим перекрытием между соседними фрагментами (chunk overlap). Документ делился на части, например, по 500 токенов каждая, где каждый следующий чанк начинался с некоторым отступом от предыдущего, создавая перекрытие в 50-100 токенов. Каждый такой фрагмент затем преобразовывался в вектор через модель embedding и сохранялся в векторной базе данных. При запросе пользователя система находила наиболее похожие по смыслу чанки и передавала их в языковую модель для генерации ответа.
Основное преимущество этого подхода — простота реализации и низкие требования к вычислительным ресурсам. Однако у него были существенные ограничения: потеря контекста на границах разбиения, невозможность уловить связи между разными частями документа, отсутствие понимания иерархической структуры текста (заголовки, подзаголовки, списки). Если ответ на вопрос требовал информации из нескольких удаленных друг от друга частей документа, система могла его не найти или предоставить неполный ответ. Этот метод хорошо работал только для простых вопросов, ответы на которые содержались в одном небольшом фрагменте текста.
Этап 2: Иерархическое и рекурсивное разбиение документов
Следующим шагом эволюции стало понимание того, что документы имеют структуру, и ее нужно учитывать при разбиении. Появились методы иерархического (hierarchical) и рекурсивного (recursive) chunking, которые разбивали документы не просто по размеру, а по их логической структуре. Система сначала определяла структуру документа: заголовки, параграфы, списки, таблицы, затем создавала иерархию — от крупных разделов к мелким фрагментам. При поиске система могла сначала найти релевантный раздел, а затем углубиться в конкретные фрагменты внутри него.
Рекурсивное разбиение работало по принципу "сначала крупные куски, потом мелкие": документ сначала делился на крупные семантические блоки (например, по заголовкам), затем каждый блок рекурсивно делился на более мелкие части до достижения оптимального размера. Это позволяло сохранять контекст: при поиске система понимала, к какому разделу относится найденный фрагмент, и могла включить в ответ связанные части из того же раздела. Также появился метод "parent document", где мелкие чанки хранились вместе с указанием на родительский документ или раздел, что позволяло при необходимости извлекать более широкий контекст. Это значительно улучшило качество ответов для сложных вопросов, требующих понимания структуры документа.
Этап 3: Графовые RAG-решения — LightRAG
Переход к графовым решениям стал революционным шагом в развитии RAG-агентов. LightRAG от HKUDS представляет собой легковесную, но мощную систему, которая строит граф знаний из документов, извлекая сущности (entities), их атрибуты и отношения между ними. Вместо простого разбиения на чанки, LightRAG анализирует текст и создает структурированное представление знаний в виде графа, где узлы — это сущности (люди, организации, концепции, события), а ребра — отношения между ними.
Процесс работы LightRAG состоит из нескольких этапов: сначала система извлекает из документов ключевые сущности и их связи, строя граф знаний. Затем этот граф используется для более точного поиска: когда пользователь задает вопрос, система не просто ищет похожие по смыслу фрагменты текста, а анализирует граф, находит релевантные сущности и их связи, и извлекает контекст, связанный с этими сущностями. Это позволяет находить ответы на сложные вопросы, требующие понимания связей между различными концепциями, даже если эти связи не упоминаются явно в одном фрагменте текста. LightRAG особенно эффективен для работы с документами, содержащими много именованных сущностей и их взаимосвязей, таких как научные статьи, техническая документация или корпоративные базы знаний.
Этап 4: Графовые RAG-решения — RAGFlow GraphRAG
RAGFlow от InfiniFlow представляет собой более комплексное решение, которое объединяет передовые технологии RAG с агентными возможностями. GraphRAG в RAGFlow — это расширенная реализация графового подхода, которая не только строит граф знаний из документов, но и интегрирует его с глубоким парсингом документов через модуль DeepDoc. Система автоматически определяет структуру документов различных форматов (PDF, Word, Excel, PowerPoint, изображения с текстом), извлекает из них не только текст, но и таблицы, диаграммы, формулы, и строит многоуровневый граф знаний.
Отличительная особенность RAGFlow GraphRAG — это способность работать с разнородными документами и автоматически определять связи между различными типами информации. Система может связать данные из таблицы с текстовым описанием, найти связи между концепциями из разных документов, и создать единую базу знаний из множества источников. При поиске RAGFlow использует гибридный подход: комбинирует векторный поиск по embedding-векторам с графовым поиском по структуре знаний, что обеспечивает более высокую точность и релевантность результатов. RAGFlow также поддерживает агентные workflow, где специализированные агенты могут выполнять сложные многошаговые задачи, используя граф знаний для навигации между различными источниками информации и концепциями.
Этап 5: KAG (Knowledge Augmented Generation) — OpenSPG
Технология KAG (Knowledge Augmented Generation) от OpenSPG представляет собой наиболее продвинутый этап эволюции — переход от простого извлечения информации к построению полноценной семантической базы знаний с использованием технологий knowledge graph (граф знаний). В отличие от предыдущих решений, которые строят графы из документов "на лету", OpenSPG создает структурированную онтологию знаний, где каждая сущность и связь имеют четко определенную семантику и тип. Система использует семантический парсинг (semantic parsing) для преобразования неструктурированного текста в структурированные знания, которые затем хранятся в графовой базе знаний с поддержкой SPG (Semantic-enhanced Programmable Graph) модели.
Ключевое отличие KAG от предыдущих подходов — это использование предопределенных схем знаний (knowledge schemas), которые описывают типы сущностей, их атрибуты и возможные отношения. Это позволяет системе не просто извлекать информацию из документов, а понимать ее семантику и строить связи на основе логических правил, а не только статистических паттернов. При генерации ответов KAG использует не только найденные фрагменты текста, но и логические выводы на основе структуры графа знаний, что позволяет отвечать на вопросы, требующие рассуждений и вывода новых знаний из существующих. OpenSPG особенно эффективен для доменов с четко определенной терминологией и структурированными знаниями, таких как медицина, право, финансы, где важна точность и возможность логических выводов.
Сравнение и выбор решения
Каждый этап эволюции решает свои задачи и подходит для разных сценариев использования. Простое chunking с overlap достаточно для простых задач с небольшими документами и простыми вопросами. Иерархическое разбиение улучшает работу со структурированными документами, такими как техническая документация или книги. LightRAG эффективен для документов с множеством именованных сущностей и их связей. RAGFlow GraphRAG подходит для комплексных задач с разнородными документами и необходимостью агентной обработки. KAG от OpenSPG — это решение для задач, требующих глубокого понимания семантики и логических выводов, особенно в специализированных доменах. Выбор конкретного подхода зависит от типа ваших документов, сложности вопросов, требований к точности и доступных вычислительных ресурсов.
Ссылки:
В следующей статье разберем пример конкретной реализации RAG агента.
Подписывайтесь на телеграм канал: @n8naiagents