Граф знаний или векторный поиск: что выбрать для памяти агента

Коротко: векторный поиск и граф знаний решают разные задачи памяти. Векторы находят «похожее по смыслу» — спасают, когда вопрос переформулирован. Граф хранит состояние и связи — отвечает «что решено», «что открыто», «что с чем связано». Для памяти агента нужны оба свойства, поэтому рабочий ответ — гибрид: граф как ядро состояния, смысловой поиск как способ находить в нём нужное.

Две разные задачи, которые мы называем «памятью»

Спор «граф против векторов» обычно буксует, потому что стороны решают разные задачи. Разведём их.

Задача поиска: «найди то, что похоже на этот вопрос». Пользователь спрашивает «как у нас устроена авторизация», а записано было «логин через JWT». Смысл совпадает, слова — нет.

Задача состояния: «какой сейчас статус задачи по миграции», «какое решение приняли по кэшу и почему», «какие баги открыты». Здесь нужен не «похожий текст», а точный актуальный факт и его связи.

Векторный поиск заточен под первую. Граф знаний — под вторую. Дальше разберём каждый честно, со слабыми местами.

Векторный поиск: где силён, где проваливается

Идея: текст превращается в вектор (набор чисел), близость векторов означает близость смысла. Поиск — по ближайшим соседям.

Сильные стороны:

• Перефразировки. «Авторизация» и «логин» окажутся рядом в векторном пространстве, даже если слова разные. Это главный козырь, и он настоящий.
• Неструктурированный корпус. Тысячи заметок, документов, сообщений — индексируются без ручной разметки.
• Порог входа низкий: взял эмбеддинг-модель, взял векторную базу — работает.

Слабые стороны:

• «Похоже» не значит «верно». Запрос «статус задачи X» найдёт пять текстов про задачу X: месячной давности, недельной, вчерашний. Вектор не знает, какой актуален. Для памяти агента это критично: устаревший факт хуже отсутствующего.
• Нет отрицаний и точных ограничений. «Мы НЕ используем Redis» и «мы используем Redis» — почти одинаковые векторы.
• Связей нет. «Какой баг блокирует релиз» — это обход графа, а не близость текстов.
• Невидимая цена: каждая запись — вызов эмбеддинг-модели, плюс переиндексация при смене модели.

Граф знаний: где силён, где проваливается

Идея: память — это сущности (проект, задача, решение, человек) и явные связи между ними («задача блокирует релиз», «решение принято владельцем»). Факты — атомарные наблюдения с датами, у багов и задач — статусы.

Сильные стороны:

• Точность на фактах. «Статус задачи X» — это поле статуса у конкретной сущности, а не похожий текст. Ответ либо есть, либо честно отсутствует.
• Состояние по построению. Открытые задачи, актуальные решения, история изменений — структура графа это и хранит. Сжатие контекста и смена сессии графу безразличны: он лежит вне окна (про compaction).
• Связи как граждане первого класса. «Что зависит от этого решения» — обход рёбер, а не надежда на смысловую близость.

Слабые стороны:

• Перефразировки — больное место. Если агент ищет «авторизацию», а сущность названа login-flow, простого текстового совпадения мало. Нужен либо дисциплинированный нейминг, либо смысловой поиск поверх графа.
• Структуру кто-то должен создавать. Факт надо записать как сущность и наблюдение, а не бросить простынёй. Это решается протоколом (агент пишет сам, по правилам), но это дисциплина, а не бесплатность.

Сравнение по осям

Чистый векторный подход — хороший поисковик по корпусу и плохая память состояния. Чистый граф — хорошее состояние и слабый поиск по переформулировкам. Таблица симметричная, и это не случайность: подходы покрывают слепые зоны друг друга.

Наш путь: гибрид

Мы строим MaxGraph с графом в ядре, потому что главная боль агента — состояние: решения, открытые задачи, «что делать дальше». Это то, что теряется между сессиями и при сжатии, и то, что дороже всего восстанавливать вручную.

Поверх графа работает ранжированный полнотекстовый поиск — он сглаживает главную слабость графа: находит сущности, даже когда запрос сформулирован иначе, чем записано. А там, где нужны настоящие смысловые перефразировки (большой корпус документов, «похожее по смыслу»), векторный индекс добавляется рядом — как слой поиска, а не как хранилище состояния.

Принцип, которым мы руководствуемся: состояние — в графе, поиск — поверх. Обратная архитектура (состояние в векторах) даёт агента, который уверенно цитирует месячной давности факты.

Экономика тоже играет за гибрид с графовым ядром. Запись в граф — это запись факта, без вызова эмбеддинг-модели на каждый чих; чтение состояния на старте сессии — один дайджест с фиксированным бюджетом. В наших замерах старт сессии с таким дайджестом стоит ~4 200 токенов против ~8 900 у чтения проекта с нуля.

Как выбрать под себя

• Вопросы в основном «найди похожее в документах» → векторный поиск, граф не обязателен.
• Вопросы в основном «что решили / что в работе / что изменилось» → граф в ядре.
• Ежедневная работа с агентом над живым проектом → гибрид: граф для состояния, смысловой поиск поверх для формулировок.

FAQ

Векторная память — это то же, что RAG? RAG — это схема «поиск + подстановка найденного в контекст», и чаще всего поиск там векторный. Векторная память — частный случай RAG, применённый к истории работы. Ограничения те же: похожесть вместо актуальности.

Можно ли хранить состояние в векторах, если аккуратно писать? Можно, но вы будете вручную решать то, что граф даёт бесплатно: версионирование фактов, статусы, связи. Обычно это заканчивается тем, что поверх векторной базы строят граф — только самодельный и на костылях.

Граф — это не слишком сложно для старта? Нет, если структуру ведёт агент, а не вы. По протоколу он сам создаёт сущности и записывает факты; ваша задача — проверять. Поднятие локального сервера: 10 минут для Claude Code или для Cursor.

Как это соотносится с Mem0, Zep и другими сервисами? У нас есть отдельный разбор: MaxGraph vs Mem0 и Zep — там про архитектуры, локальность и цены.

Что дальше

• Общая картина подходов: гид по памяти агентов.
• Термины из статьи: глоссарий памяти агентов.
• Замеры стоимости контекста: цена повторного контекста.