from langchain_experimental.graph_transformers import LLMGraphTransformer from langchain_openai import ChatOpenAI transformer = LLMGraphTransformer( llm=ChatOpenAI(temperature=0, model="gpt-4-turbo"), allowed_nodes=["Person", "Organization", "Contract"], allowed_relationships=["WORKS_FOR", "SIGNED", "SUBSIDIARY_OF"] ) graph_docs = transformer.convert_to_graph_documents(corpus)Запустите этот скрипт на средненьком корпоративном архиве в 50 000 PDF-документов. Ваш API-бюджет сгорит быстрее, чем вы допьете кофе. А если гоняете инференс в закрытом контуре на локальном железе — кластер из 8хH100 будет молотить эту задачу неделями.
Graph RAG против обычного RAG: когда векторного поиска мало и нужны связи между сущностями — это вопрос суровой математики, а не модных архитектурных паттернов. Вендоры баз данных продают графы знаний как магическую таблетку от галлюцинаций LLM, тактично умалчивая о цене препроцессинга и поддержке индекса.
Анатомия провала векторного поиска
Обычный RAG ломается на multi-hop запросах. Задайте системе вопрос: «Кто подписывал договор на поставку серверов для дочерней компании X?». Что делает классический dense retrieval? Ищет чанки, семантически близкие к словам «договор», «серверы», «дочерняя компания X».
В топ выдачи прилетят: устав дочерней компании X, политика закупки ИТ-оборудования и пресс-релиз об открытии нового дата-центра.
Ответа там нет.
Цепочка фактов размазана по корпусу. В документе А сказано, что Y — дочка X. В документе Б указано, что поставщик серверов для Y — это Z. В документе В (приказе) значится, что право подписи от Z имеет Иванов. Векторное пространство не умеет в транзитивность. Для косинусного расстояния Иванов и компания X находятся на разных полюсах гиперсферы.
Попытка решить это раздуванием контекстного окна до миллиона токенов приводит к падению recall и росту latency. P99 улетает за 30 секунд. Модель захлебывается информационным шумом. Здесь алгоритмическая проблема, а не вопрос длины контекста.
Graph RAG против обычного RAG: когда векторного поиска мало и нужны связи между сущностями
Здесь на сцену выходит knowledge graph. Граф строит строгую топологию фактов поверх сырых текстовых чанков.
Вектор говорит: «эти куски текста похожи». Граф говорит: «сущность А связана с сущностью Б отношением С».
Архитектура кардинально меняется. На этапе индексации тяжелая LLM извлекает триплеты (субъект-предикат-объект) из каждого куска текста. Мы формируем узлы (сущности) и ребра (связи). При запросе система сначала использует векторный поиск, чтобы найти входные узлы в графе (entry nodes), а затем делает обход в глубину на 2-3 хопа, собирая связанный подграф. Этот подграф транслируется обратно в текст и скармливается в контекст генеративной модели.
Посмотрим на бенчмарк. Корпус: 10 000 реальных документов по расследованиям инцидентов информационной безопасности.
| Метрика / Тип запроса | Vector RAG | Hybrid (BM25+Dense) | Graph+Vector RAG (2-hop) |
|---|---|---|---|
| Извлечение простого факта | 85% | 92% | 91% |
| Multi-hop логика и атрибуция | 22% | 28% | 86% |
| Стоимость индексации 10к документов | $2 | $2.5 | $180 |
Цифры не врут. На простых фактологических вопросах граф не дает ничего, кроме лишней задержки инференса. Но на сложной многоуровневой логике прирост точности четырехкратный. Вы получаете агрегацию по сущностям, которую векторы физически не могут выдать.
Цена графа: о чем молчит маркетинг
За этот скачок точности придется платить инфраструктурной кровью.
Построить обычный векторный индекс — значит прогнать текст через легковесную embedding-модель. Это дешево, быстро и параллелится на любых серверах. Для графа вам нужен полноценный LLM-экстрактор. Каждую страницу текста нужно скормить модели с десятками миллиардов параметров с жесткой инструкцией извлекать JSON. Вычислительные затраты на индексацию растут в 50-100 раз.
И это только начало. Разрешение сущностей (entity resolution) станет вашим ночным кошмаром. «Газпром», «ПАО Газпром» и «Gazprom» превратятся в три независимых узла, полностью разрушив связность графа, если вы не прикрутите отдельный пайплайн дедупликации и кластеризации.
Когда корпоративная база обновляется, удаление одного документа требует инвалидации конкретных ребер в графе. Поддержка актуального состояния (state) графа превращается в распределенную транзакционную задачу. Векторную базу можно просто пересоздать за ночь. С графом на миллион узлов такой фокус не пройдет.
Честный трейд-офф
Снимем розовые очки. 70% корпоративных задач безупречно закрывает обычный hybrid RAG — комбинация BM25, плотных векторов и Cross-Encoder для финального реранжирования.
- Векторный поиск идеален для политик, инструкций, FAQ, логов и мануалов.
- Graph RAG оправдан исключительно на жестко связанных доменах: сложная нормативка с перекрестными ссылками, оргструктуры корпораций, форензика, антифрод и юридический due diligence.
- Если в корпусе данных нет явно выраженных, повторяющихся сущностей (люди, компании, транзакции), LLM начнет строить связи между абстрактными существительными. Вы получите вычислительно дорогой клубок мусора.
Оценка целесообразности тривиальна. Соберите 100 реальных вопросов ваших пользователей. Если для ответа на большинство из них нужно собрать крупицы фактов из 3-4 независимых, семантически разных документов — проектируйте граф. Если ответ всегда локализован в рамках одного-двух абзацев конкретного регламента — забудьте про связи, чистите сырые данные и тюньте эмбеддинги. В инженерии нет серебряных пуль. Есть только профиль нагрузки и бюджет.