Cognee – Turn RAG and GraphRAG into custom dynamic semantic memory

Hacker News

Share card

Cognee – Turn RAG and GraphRAG into custom dynamic semantic memory

Hey there HN! We’re Vasilije, Boris, and Laszlo, and we’re excited to introduce cognee, an open-source Python library that approaches building evolving semantic memory using knowledge graphs + data pipelines Before we built cognee, Vasilije(B Economics and Clinical Psychology) worked at a few unicorns (Omio, Zalando, Taxfix), while Boris managed large-scale applications in production at Pera and StuDocu. Laszlo joined after getting his PhD in Graph Theory at the University of Szeged. Using LLMs to connect to large datasets (RAG) has been popularized and has shown great promise. Unfortunately, this approach doesn’t live up to the hype. Let’s assume we want to load a large repository from GitHub to a vector store. Connectingfiles in larger systems with RAG would fail because a fixed RAG limit is too constraining in longer dependency chains. While we need results that are aware of the context of the whole repository, RAG’s similarity-based retrieval does not capture the full context of interdependent files spread across the repository. This approach allows cognee to retrieve all relevant and correct context at inference time. For example, if `function A` in one file calls `function B` in another file, which calls `function C` in a third file, all code and summaries that further explain their position and purpose in that chain are served as context. As a result, the system has complete visibility into how different code parts work together within the repo. Last year, Microsoft took a leap published GraphRAG - i.e. RAG with Knowledge Graphs. We think it is the right direction. Our initial ideas were similar to this paper and this got some attention on Twitter ( https://x.com/tricalt/status/1722216426709365024 ) Over time we understood we needed tooling to create dynamically evolving groups of graphs, cross-connected and evaluated together. Our tool is named after a process called cognification. We prefer the definition that Vakalo (1978) uses to explain that cognify represents "building a fitting (mental) picture" We believe that agents of tomorrow will require a correct dynamic “mental picture” or context to operate in a rapidly evolving landscape. To address this, we built ECL pipelines, where we do the following: - Extract data from various sources using dlt and existing frameworks - Cognify - create a graph/vector representation of the data - Load - store the data in the vector (in this case our partner FalkorDB), graph, and relational stores We can also continuously feed the graph with new information, and when testing this approach we found that on HotpotQA, with human labeling, we achieved 87% answer accuracy ( https://docs.cognee.ai/evaluations ). To show how the approach works we did an integration with continue.dev and built a codegraph Here is how codegraph was implemented: We're explicitly including repository structure details and integrating custom dependency graph versions. Think of it as a more insightful way to understand your codebase's architecture. By transforming dependency graphs into knowledge graphs, we're creating a quick, graph-based version of tools like tree-sitter. This means faster and more accurate code analysis. We worked on modeling causal relationships within code and enriching them with LLMs. This helps you understand how different parts of your code influence each other. We created graph skeletons in memory which allows us to perform various operations on graphs and power custom retrievers. If you want to integrate cognee into your systems or have a look at codegraph, our GitHub repository is ( https://github.com/topoteretes/cognee ) Thank you for reading! We’re definitely early and welcome your ideas and experiences as it relates to agents, graphs, evals, and human+LLM memory.