Граф знаний как память
Большинство RAG устроены так:
Repository → Chunks → Embeddings → Vector Search → LLM
Граф знаний (Helix) предлагает другое:
Knowledge Graph → Traversal → Context → LLM
Агент получает не похожие куски текста, а связанные понятия.
Обход вместо поиска
Векторный поиск говорит: дай похожие документы. Граф говорит: дай всё, что находится в радиусе 3 рёбер от Payment.
Payment → Invoice → Customer → Subscription
Это уже готовый, осмысленный контекст, а не набор совпадений по косинусной близости.
Это похоже на человеческое мышление
Человек редко думает «найди похожий текст». Он думает через связи:
Статья относится к Feed. Feed принадлежит User. User любит Rust. Поэтому…
Именно такие связи граф и сохраняет. Поэтому контекст, собранный обходом, ближе к тому, как рассуждает человек.
Агенты могут жить в графе
Во многих системах Agent → имеет Memory. В графе знаний естественнее обратное:
Memory → порождает Agent
Агент — не объект с памятью, а представление части графа. Bounded context Billing (Invoice, Payment, Refund, Tax) буквально становится миром агента через запрос MATCH Billing depth=2.
Это хорошо ложится на концептуальные модели DDD и на Knowledge-first архитектуру.
Почему лучше RAG
RAG теряет структуру: он не знает, что Article belongs_to Feed, Feed owned_by User. Граф передаёт агенту не текст, а смысловые цепочки. Поэтому граф как память — это не оптимизация поиска, а другая модель понимания.
Источники
- HelixDB — графовая база знаний, упоминаемая как реализация концептуальной памяти
- Контекст через обход vs RAG — из обсуждения; опирается на Fragments: June 16, 2026 и What Is Code?