Microsoft OmniRAG
It’s Azure Cosmos DB extended to support graph traversal as a first-class retrieval strategy alongside vector search and direct database queries.
The technical centerpiece is something they call OmniRAG: a retrieval router that selects the right retrieval method based on query intent. Ask “what is Flask?” and you get a database lookup. Ask “what are its dependencies?” and you get graph traversal. If you ask “what other libraries did this author write?” you get graph again. The system decides at inference time, not at design time. This is a structural insight that the RAG community has been circling for a while, but rarely implements cleanly: retrieval strategy should be a function of query semantics, not a fixed architectural choice.
What is interesting is that a knowledge graph is no longer positioned as a standalone analytical asset, sitting in a separate triple store and queried by specialists. It’s being positioned as part of the retrieval substrate for AI alongside vectors and documents, activated dynamically when relational reasoning is required. That’s a meaningful shift in where graphs sit in the AI stack. Not as an alternative to vector search or as a visualization layer. As the layer that handles the questions vectors structurally cannot answer: paths, hierarchies, dependencies, indirect connections.
They identify three query types: complex relationships, hierarchical structures, contextual paths. It’s where flat embeddings usually fail. You cannot embed “what are all the downstream dependencies of this component?” into a similarity score, you need a traversal. The graph is not a preference; it’s the only coherent answer.
Not everything is bliss, of course. What this doesn’t yet resolve: entity resolution, schema stability as corpora evolve, and the question of who curates the graph structure in the first place. Building the graph is not the same as maintaining it under real-world document drift.