cognee

lding RAGs we saw that we can’t find the data we need and that there are too many knobs to turn in RAG frameworks. We had to tweak many parameters and also could not specify the rules we wanted the data to follow. No ontologies, no rulesets, no state or good data engineering practices and a lot of manual work. That’s why cognee cognee builds memory that combines graph, vector, and relational stores. Here is how it works: Adding data: When you use cognee with your AI App, it can take in any message, string, S3 bucket or even a relational database and automatically ingest it Managing information: cognee sorts this information into semantic graph: - It extracts entities and connections between things. - It embeds the data in the vector store, It enriches data with custom ontologies you provide, that help ground the graphs and make them more reliable. - The overall information is stored in many layers of a graph and vector store that allows for finding similar information later using a variety of types of searches. Retrieving data: When given an input query, cognee searches for and retrieves related stored information by leveraging a combination of graph traversal techniques, vector similarity, and COT techniques. It can use the internal benchmarking system to make sure that your pipelines are returning only accurate data when you need it. --- cognee introduces a self-improving group of memory layers that cover various topics, data sources and can be customized. This reduces the need to build everything from scratch, and you can use our primitives to get started and move more quickly. On the other hand, you can do everything yourself, from start to end. We’ve designed the system to be modular and extensible. We’ve open-sourced cognee —specifically the framework and various vector and graph database adapters, as well as our default data pipeline, cognify—under the Apache 2.0 license. This includes the ability to add, cognify, and retrieve data within your AI applications and also extend it with custom components that are just pure Python. However, many keep features that are optimized for production use, as a part of our paid platform. We release these functionalities too, including in the last few weeks permission management + distributed pipelines(dev). These are a part of our open-source package and are available to those who in production environments need things like rate limiting and credential management. We will release a paid offering for developers to get easy API access to our platform. Our automation tooling allows us to optimize the pipelines and find the best combination of parameters that answer questions our stakeholders have. We’d love to hear what you think! Please feel free to try our demo, check out the code, read the research paper, and share thoughts or suggestions with us. Your feedback will help shape where we take cognee from here!

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.