ВЕБ ШТУРМ
Обсудить →

LightRAG vs RAG vs GraphRAG: какой выбрать для документации компании

Веб Штурм
  • LightRAG
  • RAG
  • knowledge-graph
  • self-hosted
  • PostgreSQL

«Просто RAG» работает хорошо ровно до момента, пока документация не становится связной — когда один договор ссылается на другое ТЗ, ТЗ — на спеку, а спека — на отчёт. Векторный поиск находит «похожие куски», но теряет смысловую сеть. LightRAG в hybrid-режиме закрывает эту дыру и обходится дешевле GraphRAG от Microsoft.

Контекст

У нас в боевом контуре LightRAG живёт уже больше полугода. Через него прошли:

При этом без передачи персональных данных в OpenAI/Anthropic, что критично для 152-ФЗ.

Чем «просто RAG» не справляется

Классический RAG (vector-only) — это: текст → embedding → similarity search → top-k chunks в промпт. Работает, пока документы независимы.

Реальная проблема возникает, когда нужно ответить на вопрос вроде «какие реквизиты ООО Веб Штурм по договору № 28-11». Vector-only вытащит чанк с реквизитами, но если в той же базе есть пять договоров и три версии политики ПД — вернёт хаотичный микс. У него нет понятия «договор № 28-11 → его реквизиты-блок → актуальная редакция».

Microsoft GraphRAG решает это извлечением сущностей и связей в отдельный граф, но платит за это: тяжёлый pipeline на LLM-вызовах при индексации, специфичный формат хранения, сложная установка. Для команды из 1-3 человек overhead избыточен.

Что делает LightRAG hybrid-mode

LightRAG в режиме mix совмещает оба подхода в одном движке:

# Как мы вызываем через MCP в Claude Code
response = lightrag_query(
    query="Реквизиты ООО Веб Штурм: ИНН, ОГРН, КПП, юр.адрес",
    mode="mix"
)
# Возвращает structured ответ + список source documents с цитатами

Entity extraction делается автоматически при lightrag_insert(text, source) — никаких ручных аннотаций. Через час после загрузки 50 документов у вас уже работающий граф «Договор → Сторона → Реквизиты → Адрес».

Self-hosted цена vs OpenAI API

Прямое сравнение по нашему профилю использования:

ПараметрLightRAG self-hostOpenAI Assistants API
EmbeddingBge-M3 multilingual через Ollamatext-embedding-3-large
Стоимость embed 150 doc$0 (CPU)~$0.50 единоразово
Стоимость 1000 запросов в месяцэлектричество (~$3 GPU idle)~$15-40 (gpt-4o-mini + embed)
Где хранятся данныесвой PostgreSQL на 185.179.188.145OpenAI servers (US)
152-ФЗ соблюдениеданет (трансграничная передача)
SetupDocker Compose, ~30 минутAPI-ключ, ~5 минут
Поддержка graph-traversalда (mix mode)нет (только vector)

Для коммерческой компании с РФ-юридическим адресом второй столбец фактически не вариант — это юридический риск 1-18 млн ₽ при работе с ПД клиентов. Третий столбец просто не существует.

Гочи self-host

При развёртывании столкнулись с двумя вещами, которые не очевидны из README:

  1. OpenAI 403 country-block при попытке использовать GPT-4o-mini как extractor с российского IP. Решили sidecar-контейнером socks-http-bridge (gost) через xraycore SOCKS5: Docker NAT → TUN на хосте → outbound. Альтернатива — заменить extractor на локальную модель через Ollama, что мы и сделали для embedding.
  2. Кодировка cp1251 на Windows — Python скрипты загрузки документов ломаются на кириллице в путях и содержимом. Зафиксировали как глобальное правило: всегда sys.stdout.reconfigure(encoding='utf-8') + open(path, encoding='utf-8') + json.dump(data, f, ensure_ascii=False).

Что мы из этого вынесли

  1. Hybrid > pure-vector для связной документации. Если у вас юридические/технические документы со ссылками друг на друга — LightRAG mix даст качественно другой ответ, чем чистый векторный поиск.
  2. Self-host не означает «дороже». При нашем объёме (150 doc, 5-50 запросов в день) self-host дешевле API; при этом данные не выходят за периметр, что закрывает 152-ФЗ.
  3. Entity extraction делать при insert, не при query. Если строить граф на каждом запросе — latency убьёт UX. LightRAG это правильно делает: тяжёлая работа один раз при загрузке.

Ссылки