Урок 13.2. Cognee: graph-first memory platform для агентов

План лекции

Сначала мы разберем Cognee как инструмент: что он обещает, какой класс memory systems представляет и почему он попал в отдельный deep-dive. Затем перейдем к архитектуре: relational store, vector store, graph store, session memory and permanent knowledge graph.

После этого посмотрим на жизненный цикл памяти в Cognee: remember, recall, forget, improve, ingestion, session learning and self-improvement. В конце обсудим, где Cognee хорошо подходит, где он может быть слишком тяжелым, какие риски проверять перед внедрением и как тестировать такую memory platform.

Цель лекции

Разобрать Cognee как open-source AI memory platform, которая строит долговременную память агента через knowledge graph, embeddings, provenance and retrieval pipelines.

Ожидаемый результат

Читатель понимает, почему Cognee относится к graph-first memory platforms, какие типы памяти он может закрывать, как устроены его основные data flows и какие архитектурные вопросы нужно проверить перед production use.

Короткая карточка инструмента

Cognee позиционируется как open-source AI memory platform for agents. Его важная особенность в том, что он не ограничивается vector search. Он соединяет relational metadata, vector embeddings and graph relationships.

Это делает Cognee хорошим примером архитектуры, где memory layer пытается быть не только поиском похожих chunks, но и слоем связей, provenance and long-term context.

Зачем это нужно

Многие memory tools начинают с простого паттерна:

message -> extract facts -> embed -> vector search later

Этот паттерн хорошо работает для персональных предпочтений and short factual recall. Но он начинает ломаться, когда агенту нужно понимать отношения:

• какой документ связан с каким проектом;
• какие решения относятся к конкретной migration;
• какие customer issues похожи не только текстом, но и причиной;
• какие события образуют timeline;
• какие источники подтверждают claim;
• какие entities повторяются в разных документах.

Cognee пытается закрыть именно этот класс задач: строить persistent memory, где данные searchable by meaning and connected by relationships.

Основная идея

Cognee стоит понимать как memory platform поверх трех типов storage:

Relational store отвечает за documents, chunks, metadata and provenance. Vector store дает semantic search. Graph store хранит entities and relationships. Вместе они дают agent memory, которая может искать по смыслу and переходить по структуре.

В терминах курса Cognee ближе всего к пересечению:

• world memory;
• semantic memory;
• episodic memory;
• hybrid vector-graph memory;
• enterprise context;
• shared knowledge memory.

Он не является просто RAG framework и не является только vector DB adapter. Это попытка собрать memory layer с ingestion, graph construction, session memory and retrieval.

Ключевые термины

Как устроена архитектура

В документации Cognee архитектура описывается через комбинацию relational, vector and graph storage. Это важный design point: ни одна база не закрывает все свойства памяти.

Relational store нужен не только как "табличка рядом". Он сохраняет provenance: откуда пришел fragment, к какому document он относится, как он связан с source and dataset. Без этого graph/vector retrieval легко становится недостоверным.

Vector store отвечает за похожесть. Если пользователь спрашивает "где мы обсуждали проблему с invoice sync?", vector search может найти chunks, где это описано другими словами.

Graph store отвечает за связи. Он позволяет хранить entities and relationships, например:

Customer -> reported -> Issue
Issue -> caused_by -> Sync Delay
Sync Delay -> affected -> Invoice System
Fix -> applied_to -> Customer Account

Вместе эти три слоя дают hybrid memory. Агент может найти похожие passages, затем уточнить context через relationships and provenance.

Data flows в Cognee

Cognee удобно рассматривать не как "одну функцию памяти", а как несколько pipelines.

Session learning

Session learning работает с conversation turns, feedback, traces and guidance. Это ближе к short-term/session memory. Важная идея: не все, что появилось в сессии, сразу становится permanent graph fact.

Сессионные записи быстрые and raw. Их можно позже distilled into curated memory. Это снижает риск записать весь шум диалога как долговременное знание.

Self-improvement

Self-improvement enriches existing memory. В документации Cognee эта линия связана с улучшением retrieval structures поверх уже созданного graph: triplet indexes, summaries and derived context structures.

В терминах курса это похоже на consolidation: память не только хранится, но и перерабатывается для будущего retrieval.

Ingestion

Ingestion принимает documents, conversations, records or external data. Данные chunked, entities and relationships extracted, embeddings indexed, provenance stored.

Это делает Cognee похожим на RAG pipeline, но с существенным отличием: результатом является не только vector index, а graph-backed permanent memory.

Основные операции

Cognee в README показывает четыре операции:

remember
recall
forget
improve

Эти операции полезно сопоставить с жизненным циклом памяти из Module 03.

Такое API хорошо демонстрирует mature memory thinking. В нем есть не только add and search, но и отдельные идеи forgetting and improvement.

Какие типы памяти закрывает Cognee

Cognee может участвовать в нескольких типах памяти, но не одинаково хорошо во всех.

Главная зона силы Cognee - graph-backed semantic/world memory. Для чистой personal preference memory он может быть тяжелее, чем более compact tools. Для agent-as-OS он не заменяет Letta-style runtime.

Storage and deployment

Cognee поддерживает lightweight local defaults and production backends. В README explicitly mentioned local development with SQLite, LanceDB and KuzuDB, а production options can include Postgres/pgvector, Neo4j/Neptune-like graph backends, Redis-like sessions and vector databases such as Qdrant, ChromaDB, Weaviate and Milvus via adapters.

Отдельно важна Postgres story. Cognee описывает возможность demo mode, где relational metadata, pgvector and graph state живут в одном Postgres-backed memory layer. Но documentation предупреждает, что production-ready Postgres-as-graph feature is licensed product, while demo mode should not be treated as full production graph backend.

Практический вывод:

Cognee можно начать локально,
но production architecture всё равно требует явного выбора storage backends.

Нельзя поставить Cognee и забыть про operational design. Нужно решить:

• где будет graph store;
• где будет vector store;
• где будет relational metadata;
• как работает cache/session layer;
• как делать backups;
• как делать deletion propagation;
• как разграничивать datasets and users.

Integrations

Cognee важен не только как Python package. В README and docs видны несколько integration surfaces:

• Python API;
• CLI;
• Docker and Docker Compose;
• MCP server;
• Claude Code plugin;
• OpenClaw plugin;
• Rust client;
• TypeScript client;
• Cognee Cloud or self-hosted server.

Для курса особенно важен MCP and coding-agent angle. Cognee plugin for Claude Code captures prompts, tool traces and assistant responses into session memory, injects relevant context on prompts and syncs session memory into permanent graph at session end.

Это пример полного memory loop:

agent work -> session memory -> context injection -> final sync -> permanent graph

В такой схеме memory не является отдельной кнопкой "save". Она встроена в lifecycle agent host.

Где Cognee особенно полезен

Cognee хорошо подходит, когда у вас есть много источников and relationships:

• research agents;
• enterprise knowledge agents;
• support agents with customer history;
• SQL copilots and expert-pattern reuse;
• project memory with documents, decisions and timelines;
• GraphRAG-style assistants;
• multi-agent systems with shared domain knowledge.

Например, support agent может использовать Cognee для связи:

customer -> past tickets -> known issue -> product area -> fix -> outcome

Research agent может использовать graph memory для связи:

paper -> claim -> evidence -> author -> dataset -> contradiction

В обоих случаях value возникает не только из semantic retrieval, но и из structure.

Где Cognee может быть лишним

Cognee может быть overkill, если:

• нужно хранить 20 user preferences;
• задача решается simple profile table;
• нет устойчивых entities and relationships;
• не нужен graph traversal;
• команда не готова поддерживать graph/vector/relational stack;
• нет observability для retrieval and memory write;
• продукту важнее low-latency voice loop than rich graph context.

Пример:

User prefers short answers.
User writes in Russian.
User uses Poetry.

Для такой памяти не нужен knowledge graph. Достаточно compact semantic profile, scoped records and clear update policy.

Риски

Риск 1: graph выглядит более точным, чем он есть

Knowledge graph дает ощущение структуры. Но relationships могут быть extracted from ambiguous text. Если source слабый или stale, graph traversal может уверенно вернуть неправильную цепочку.

Нужны:

• provenance;
• confidence;
• freshness;
• human review for critical facts;
• conflict detection.

Риск 2: operational complexity

Cognee объединяет несколько storage families. Это мощно, но увеличивает поверхность эксплуатации:

• migrations;
• backups;
• index rebuilds;
• graph consistency;
• vector index deletion;
• session cache expiration;
• queue/background jobs.

Для production нужно проверять не только API, но и runbook.

Риск 3: deletion propagation

Если пользователь удаляет dataset, deletion должна пройти через:

• relational records;
• vector embeddings;
• graph nodes/edges;
• session cache;
• summaries or derived indexes;
• logs and audit trail.

Любая derived memory structure может стать местом, где удаленная информация продолжает жить.

Риск 4: permissions and tenant isolation

Graph memory особенно чувствительна к leakage. Если graph traversal переходит через edge между tenants or teams, агент может получить context, который semantic search не должен был видеть.

Permission-aware retrieval должен применяться до context assembly.

Риск 5: benchmark overconfidence

Cognee README mentions benchmark results and frames them as directional. Это правильная осторожность. Для продукта benchmark не заменяет собственные сценарии:

• your documents;
• your user roles;
• your latency budget;
• your update/delete flows;
• your failures.

Как тестировать внедрение

Для Cognee-like graph memory нужно тестировать не только answer quality.

Хороший pilot должен иметь маленький golden dataset: documents, expected entities, expected relationships, allowed users and prohibited cross-scope queries.

Мини-кейс: Cognee для research memory

Представим research agent, который собирает обзор по agent memory frameworks.

Источники:

• GitHub READMEs;
• documentation pages;
• benchmark reports;
• issues about self-hosting;
• pricing pages;
• papers.

Обычный RAG может найти похожие chunks по запросу:

"Which tools support graph memory?"

Но research agent часто спрашивает иначе:

"Какие утверждения о temporal reasoning подтверждены документацией,
а какие только marketing claims?"

Для этого нужна структура:

Tool -> claims -> source -> evidence -> confidence -> contradiction

Cognee-like graph memory подходит, потому что может связать claims with sources and entities. Но агент все равно должен сохранять uncertainty: graph edge is not proof by itself.

Мини-кейс: Cognee для customer support memory

Support agent работает с customer history.

Данные:

• tickets;
• chat transcripts;
• product docs;
• billing events;
• previous fixes;
• account metadata.

Cognee может помочь построить graph:

Customer -> reported -> Ticket
Ticket -> mentions -> Product Area
Ticket -> caused_by -> Incident
Incident -> resolved_by -> Fix
Fix -> changed -> Account Setting

Тогда agent can recall not just similar tickets, but the path from customer issue to prior resolution.

Но enterprise version of this scenario requires:

• tenant filters;
• CRM as source of truth;
• audit logs;
• stale ticket handling;
• access control;
• user-visible source attribution.

Cognee может быть memory platform, но product governance остается вашей ответственностью.

Сравнение с соседними инструментами

Cognee стоит рассматривать, когда вам нужен graph-backed memory platform, а не просто long-term user profile or local history search.

Источники

• Cognee GitHub repository: https://github.com/topoteretes/cognee
• Cognee documentation: https://docs.cognee.ai/
• Cognee architecture docs: https://docs.cognee.ai/core-concepts/architecture
• Cognee data flows docs: https://docs.cognee.ai/core-concepts/data-flows
• Cognee release v1.4.2: https://github.com/topoteretes/cognee/releases/tag/v1.4.2

Краткое резюме

Cognee - это graph-first memory platform for agents. Его архитектурная идея: соединить relational provenance, vector semantic search and graph relationships в одном memory layer.

Он особенно полезен для agents, которым нужны documents, entities, relationships, provenance and hybrid retrieval. Но такая сила приходит вместе с operational complexity: graph quality, permissions, deletion, storage backends and observability нужно проектировать явно.

Вопросы для самопроверки

1. Почему Cognee нельзя считать просто vector database wrapper?
2. Какие роли играют relational, vector and graph stores в Cognee-like architecture?
3. Чем session learning отличается от ingestion into permanent memory?
4. Какие риски возникают при graph memory in enterprise settings?
5. Когда Cognee будет overkill по сравнению с simple profile memory?

Что дальше

В следующей лекции мы разберем Supermemory: memory/context engine and app/API, который представляет другой подход к agent memory - более API-oriented and personal/cross-app context layer.