Векторная база — хороший старт для памяти AI-агента, но плохая финальная архитектура, если агент должен помнить не только тексты, а отношения между людьми, проектами, решениями и сроками. Я упёрся в это на Digital Shadow: Qdrant отлично находил похожие фрагменты, но реальная жизнь не хотела раскладываться по аккуратным коллекциям.

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

Где сломался чистый вектор

Сначала память Digital Shadow была разложена по коллекциям: проекты, партнёры, крипта, личное. На схеме красиво. В жизни — нет. Один партнёр участвует в двух проектах. Одно решение из личного разговора влияет на бизнес. Один документ относится сразу к нескольким контекстам.

Чтобы связи не терялись, приходилось дублировать данные. Я писал жёсткие промпты, добавлял правила маршрутизации, настраивал инструменты. Агент всё равно иногда путал: бизнес-встреча улетала в личное, личная тема попадала в проектную память.

Проблема была не в промпте. Проблема была в модели данных.

“Vector search retrieves information by semantic meaning, not just exact keyword matches.” — Qdrant Documentation

Это сильная сторона векторной базы. Она отлично ищет «похожее по смыслу»: документацию, FAQ, инструкции, фрагменты встреч. Но «похожее» и «связанное» — разные вещи. Запрос про партнёра может требовать не похожий текст, а цепочку отношений: человек → проект → встреча → решение → дедлайн → документ.

Почему бизнес-контекст — это граф

Операционная память компании состоит из связей. Кто с кем говорил. Когда. По какому проекту. Что обещал. Почему отказались от варианта. Какое решение зависело от другого решения.

В графовой модели это естественно: есть сущности, связи и свойства. Человек связан с проектом, проект — с документом, документ — с риском, риск — с задачей, задача — с дедлайном.

“Nodes represent entities or discrete objects in a domain. Relationships represent a connection between a source node and a target node.” — Neo4j Documentation

Это почти идеальный язык для памяти ассистента. Не потому что Neo4j или любой другой граф «моднее», а потому что бизнес-вопросы часто звучат как обход связей: «что мы обещали этому клиенту после той встречи?», «почему выбрали этот стек?», «какие решения зависят от поставщика X?»

Что изменилось в Digital Shadow

Я перешёл к связке Graphiti + FalkorDB для графовой памяти и PostgreSQL для точных сущностей. Вечерняя рефлексия теперь превращается не просто в заметку, а в набор эпизодов, фактов и связей: кто упоминался, к какому проекту относится, какое решение появилось, что изменилось по сравнению с прошлым состоянием.

Graphiti описывает это как Context Graph — temporal knowledge graph, то есть граф сущностей, отношений и фактов, который меняется во времени. Для ассистента это важнее статичной базы: отношения в бизнесе не вечны. Партнёр меняет роль, проект закрывается, дедлайн переносится, договор обновляется.

“Graphiti helps you create and query Context Graphs that evolve over time.” — Graphiti Documentation

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

Роль PostgreSQL: факты без поэзии

LLM может красиво объяснить, но не должна быть источником истины для операционных фактов. Векторный поиск может найти похожую заметку, но не обязан знать текущий статус задачи. Граф может показать связь, но не заменяет транзакционную систему.

PostgreSQL хорош для того, что требует структуры и проверяемости: foreign keys, транзакции, статусы, дедлайны, права доступа, аудиторские записи. Официальная документация PostgreSQL подчёркивает поддержку SQL, foreign keys, triggers, views и transactional integrity — именно такие свойства нужны для операционного слоя.

Новая проблема: памяти стало слишком много

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

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

Практическая схема памяти AI-агента

Рабочая архитектура выглядит так:

  • Векторная база: документы, заметки, фрагменты встреч, поиск по смыслу.
  • Графовая база: люди, проекты, компании, решения, события и связи между ними.
  • PostgreSQL: задачи, дедлайны, статусы, права, настройки, журналы.
  • LLM: интерфейс рассуждения и объяснения, но не единственный источник фактов.
  • Policy layer: правила доступа, приоритеты, свежесть, что можно показывать пользователю.

Такой подход сложнее, чем «закинем всё в векторную базу». Но он ближе к реальности. Бизнес не состоит только из документов. Он состоит из документов, людей, решений, сроков и связей между ними.