Инженер UseBead предложил графовую архитектуру RAG, преодолевающую узкие места многошагового логического вывода при векторном поиске

Репортаж от Wedoany，На фоне ускоренного внедрения корпоративных ИИ-приложений в производственную среду всё более очевидными становятся ограничения стандартной архитектуры Retrieval-Augmented Generation (RAG). Инженер-программист UseBead Даулет Амирханов недавно опубликовал в VentureBeat техническую статью, в которой системно представил архитектурный паттерн графовой RAG, сочетающий семантическую гибкость векторного поиска со структурной определённостью графовых баз данных для решения проблемы потери контекста при многошаговом логическом выводе в традиционном векторном поиске.

Основной процесс стандартной RAG-архитектуры — разбиение документов на фрагменты, внедрение в базу данных векторов, поиск Top-K результатов по косинусному сходству — эффективен при неструктурированном семантическом поиске, но часто даёт сбои в сценариях с сильно связанными корпоративными данными, такими как цепочки поставок, финансовый комплаенс и обнаружение мошенничества. Амирханов отмечает, что векторные базы данных хорошо улавливают семантику, но отбрасывают топологическую структуру. После разбиения документов на фрагменты и их векторизации явные связи, такие как иерархические отношения, зависимости и отношения владения, часто уплощаются или полностью теряются. Типичный сценарий в цепочке поставок иллюстрирует эту модель отказа: в структурированных данных SQL-база чётко определяет, что «Поставщик A поставляет компонент X на завод Y»; в неструктурированных данных новостная статья сообщает, что «наводнение в Таиланде остановило производство на заводе поставщика A». Векторный поиск может найти эту новость, но не может связать новостное событие с производством на заводе Y. LLM получает текст новости, но не имеет контекста для ответа на бизнес-вопрос «какие downstream-заводы находятся под угрозой», и в итоге либо угадывает цепочку связей, либо отвечает «невозможно ответить», хотя данные уже существуют.

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

В статье Амирханов также опубликовал эталонную реализацию на основе Python, Neo4j и OpenAI. В реализации определена графовая схема, связывающая неструктурированные события риска со структурированными сущностями цепочки поставок, а с помощью языка запросов Cypher демонстрируется ключевое отличие гибридного поиска: система не просто возвращает Top-K текстовых фрагментов, а сначала находит сущности, семантически соответствующие запросу (например, узел поставщика), а затем расширяет поиск вниз по путям отношений цепочки поставок (поставщик → компонент → завод → клиент), пока не будет установлена полная связь с потенциально затронутыми бизнес-подразделениями клиента.

Исследование команды Milvus указывает на то, что фундаментальное препятствие, с которым сталкивается стандартный RAG при многошаговых вопросах, заключается в том, что ответ зависит от отношений сущностей, «невидимых» для векторного поиска — связующая сущность, соединяющая вопрос и ответ, часто не упоминается в самом вопросе. Это подтверждается и данными многочисленных технических оценок: при запросах, включающих более 3 шагов, точность традиционного RAG снижается на 57% по сравнению с простыми запросами, а полнота не достигает 40%; в то время как GraphRAG может за один обход графа выстроить полную цепочку рассуждений: компания → холдинговые отношения → дочерняя компания → руководитель → судебные записи, повышая точность на 42% по сравнению с традиционным решением. Оценка Microsoft показывает, что в корпоративных сценариях полнота ответов GraphRAG увеличивается на 72–83%, а фактическая точность возрастает в 3,4 раза.

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

Данный материал скомпилирован платформой Wedoany. При цитировании материалов, созданных с помощью искусственного интеллекта (ИИ), необходимо обязательно указывать источник — «Wedoany». В случае выявления нарушения прав или иных проблем просим своевременно информировать нас. Сайт оперативно внесёт изменения или удалит материал.Электронная почта: news@wedoany.com