Спор «граф или векторы» обычно ведётся на уровне вкуса: одним нравится структура, другим — простота. У него есть объективный критерий, и он формулируется одной фразой: сколько переходов между сущностями нужно сделать, чтобы ответить на вопрос.
Если ноль или один — работает поиск, граф не нужен. Если два и больше — поиск не справится в принципе, потому что ни одного документа с готовым ответом не существует.
Факты о сторонних подходах в этом тексте проверялись 26.08.2026.
#Как считать глубину связи
Возьмите вопрос и разберите, из чего складывается ответ.
Ноль переходов — ответ целиком лежит в одном фрагменте: «что я говорил про отпуск». Достаточно найти фрагмент.
Один переход — нужно найти сущность и что-то про неё: «чем занимается Олег». Тоже решается поиском, если про Олега где-то написано прямо.
Два перехода — «с кем из моих коллег пересекается человек, которого я встретил на конференции». Здесь нет документа, где написан ответ. Есть документ про встречу, документ про коллегу и общее третье лицо, которое связывает их. Ответ рождается на соединении, а не находится.
Три и больше — «какие проекты сейчас затронуты решением, которое мы приняли в марте». Цепочка «решение → проект → люди → текущие задачи» не лежит нигде целиком.
Критерий проверяемый: возьмите двадцать своих реальных вопросов и разметьте их по числу переходов. Если многошаговых меньше пятой части — граф вам не нужен, и вся аргументация ниже про то, почему.
#Что делает векторный поиск, и делает хорошо
Векторный поиск отвечает на вопрос «покажи фрагменты, похожие на этот запрос», — это шаг извлечения в конвейере, разобранном в статье о том, что такое RAG простыми словами. Он не знает, что такое человек, проект или дата, — он знает только близость точек на карте смыслов, и этого достаточно для огромного класса задач.
Его сильные стороны:
- Нулевая стоимость подготовки. Не нужно решать, какие сущности бывают и какими связями они соединяются. Текст кладётся как есть.
- Устойчивость к беспорядку. Плохо структурированная переписка индексируется так же, как аккуратный документ.
- Отсутствие ошибок извлечения. Он ничего не извлекает, а значит, не может извлечь неправильно.
Последний пункт — недооценённое преимущество, и о нём в следующем разделе.
#Что делает граф, и чем платит
Граф хранит не тексты, а тройки: субъект, отношение, объект. «Олег — работает в — Контур». «Проект блога — принадлежит — Олегу». Ответ на многошаговый вопрос получается обходом рёбер, а не поиском.
Цена начинается там же, где польза: тройки надо откуда-то взять. Из текста их извлекает языковая модель, и она ошибается тремя способами.
Неправильные сущности. «Он», «это», «пользователь» становятся узлами графа. В Persona это лечится грубо — списком стоп-слов в app/knowledge_graph.py, куда входят местоимения и общие слова; всё, что в него попало, узлом не становится.
Разные имена одной сущности. «Олег», «Олег Петров», «Петров» — три узла вместо одного. Полноценное разрешение сущностей — отдельная сложная задача; в Persona её нет, есть только нормализация имени по пробелам и длине.
Разные формулировки одного отношения. «работает в», «Работает_В», «работает в» — потенциально три разных ребра между теми же узлами. Здесь решение простое и работает: отношение нормализуется перед сравнением и перед вставкой — приводится к нижнему регистру, подчёркивания заменяются пробелами, пробелы схлопываются. Повторная тройка не создаёт дубль, а увеличивает вес существующего ребра.
Итого граф добавляет к системе класс ошибок, которого у поиска нет: ошибку извлечения. Поиск может не найти нужное; граф может уверенно утверждать неверное. Второе хуже, потому что незаметно.
#Таблица: какой вопрос кому
| Тип вопроса | Пример | Кто решает |
|---|---|---|
| Найти фрагмент | «что я писал про дедлайн» | поиск |
| Факт о сущности | «где работает Олег» | поиск |
| Все связи одной сущности | «всё, что связано с проектом X» | граф или поиск по имени |
| Пересечение двух сущностей | «что общего у Олега и проекта Y» | граф |
| Цепочка через посредника | «кто из моих коллег знает того человека» | граф |
| Агрегат по связям | «с кем я чаще всего обсуждаю деньги» | граф |
| Хронология изменений | «как менялось моё мнение о Y» | ни то ни другое, нужна временнáя разметка |
Третья строка — пограничная и потому важная. «Всё про проект X» кажется задачей для графа, но на практике поиск по имени проекта решает её не хуже, если имя редкое. Граф выигрывает, только когда имя в тексте не упоминается, а связь есть через посредника.
Последняя строка честно говорит, что оба инструмента не покрывают: изменение факта во времени — отдельное измерение, и его решают не структурой связей и не близостью векторов, а датами валидности у каждой записи.
#Пример многошагового вопроса, разобранный по шагам
Вопрос: «кто ещё из моих контактов работает над тем же, чем занят Олег?»
Что делает векторный поиск: находит фрагменты, похожие на «Олег работает», то есть тексты про Олега. Ответа среди них нет — про других людей там не сказано.
Что делает граф:
- Найти узел «Олег».
- Пройти по рёбрам типа «работает над» → получить узел «миграция биллинга».
- Пройти по обратным рёбрам того же типа → получить узлы «Ольга», «Пётр».
- Отфильтровать исходный узел.
Ответ: Ольга и Пётр. Ни в одном документе этого предложения не было.
Критически важная деталь: результат верен только если тройки извлечены верно. Если модель на шаге индексации записала «Олег — работает над — задача» вместо конкретного проекта, обход пройдёт мимо. Проверять это надо не на выдаче, а на самих рёбрах — глядя на граф глазами. Как он устроен и что в нём видно, разобрано в статье про граф памяти.
#Как это устроено в Persona
Граф здесь — надстройка над курируемой памятью, а не отдельное хранилище знаний. Порядок такой: сначала из диалога извлекается durable-факт и кладётся в личную память, и только из уже сохранённого факта извлекаются тройки. Сущности пишутся в свою таблицу, связи — в свою, с типом отношения и весом.
Три свойства этой конструкции стоит назвать явно:
- Рёбра би-темпоральны, как и факты. Ребро не удаляется, а помечается недействительным с определённого момента; актуальным считается то, у которого метка пуста. История связи сохраняется.
- Граф следует за памятью. Если факт заменён более новым, поддержка рёбер, державшаяся только на устаревшей версии, снимается в той же транзакции.
- Извлечение требует локальной модели со схемой ответа. Тройки вытаскиваются через ответ по строгой JSON-схеме, которую поддерживает Ollama. С облачным провайдером этот путь просто не выполняется — тихо, без ошибки. То есть граф у вас будет наполняться только при локальной модели.
Последнее — существенное ограничение, и оно из той же семьи, что векторный поиск и переранжирование: опциональная надстройка, которая при отсутствии условий не работает и не жалуется.
#Где граф объективно проигрывает
Симметрично разделу про векторы — честно про слабости той стороны, которую граф представляет.
Стоимость сопровождения. Граф надо чистить: дубли сущностей, мусорные узлы, устаревшие связи. Векторный индекс не требует ничего, кроме переиндексации при смене модели.
Хрупкость к качеству извлечения. На слабой локальной модели тройки получаются шумными, и качество графа падает быстрее, чем качество поиска на той же модели. Поиску вообще не нужна модель для индексации, кроме эмбеддера.
Плохо ловит нюанс. Всё, что не сводится к тройке — оценки, сомнения, условия, — в графе не представлено. «Олег скорее всего уйдёт из проекта, если не решится вопрос с бюджетом» — это не ребро.
Не отвечает на вопросы «про текст». «Как я формулировал ту мысль про архитектуру» — вопрос к формулировке, а не к связям. Здесь граф бесполезен, а точнее всего сработает связка ключевых слов и векторов, разобранная в материале про гибридный поиск.
Поэтому практическая рекомендация — не «граф вместо поиска», а «поиск, а граф сверху, если многошаговых вопросов действительно много». Общая схема слоёв памяти, куда встраивается и то и другое, описана в статье о том, как работает память у ИИ, а место графа в архитектуре ассистента — в разборе агентной архитектуры Persona.
#Частые вопросы
#Что такое GraphRAG и нужен ли он мне?
Так называют схемы, где поверх графа строятся сводки по кластерам связей, а поиск идёт по ним. Это заметно дороже обычного RAG — нужен и граф, и дополнительный слой обобщений. Для персонального масштаба оправдано редко: многошаговых вопросов у одного человека обычно мало.
#Можно ли построить граф без языковой модели?
Частично: связи, заданные структурой данных — автор сообщения, участники встречи, теги, — извлекаются правилами и получаются надёжнее, чем через модель. Модель нужна только для связей, выраженных в свободном тексте.
#Как проверить качество графа?
Не по ответам, а глазами по рёбрам. Возьмите три десятка связей и проверьте каждую: верна ли она, не дублирует ли другую, не мусорный ли узел на одном из концов. Доля ошибок в этой выборке и есть качество вашего извлечения — на выдаче она размывается и не видна.
#Заменяет ли граф провенанс?
Нет. Ребро само по себе не говорит, откуда взялась связь; чтобы ей можно было доверять, у неё должна быть ссылка на источник. Почему это обязательное требование к любой автоматически записанной информации, разобрано в материале про провенанс памяти.
#С чего начинать, если хочется и то и другое?
С поиска. Он даёт результат сразу и не требует решений о схеме. Граф добавляйте, когда накопите список конкретных вопросов, на которые поиск не отвечает, и убедитесь, что все они — многошаговые. Если в списке окажутся в основном одношаговые, чинить надо поиск, а не строить граф.
#Вывод
Разметьте свои двадцать вопросов по числу переходов между сущностями. Если многошаговых мало — берите поиск, он дешевле в разы и не приносит ошибок извлечения. Если многошаговых много и они важные — граф оправдан, но заложите бюджет на его чистку и проверяйте рёбра выборочно вручную: граф ошибается тихо и уверенно, а это худший вид ошибки в памяти о человеке.