Knowledge graph architecture moves into enterprise AI infrastructure
Shan Rizvi of Thumos Care says graphs can give AI systems traceable reasoning, but latency and data modeling remain production constraints.
By Wei-Lin Zhao · AI Correspondent
· 3 min read
Knowledge graph architecture is becoming production infrastructure for enterprise AI, according to Shan Rizvi, founder and context architect at Thumos Care. In an interview with John Furrier on SiliconANGLE Media’s theCUBE, Rizvi argued that companies using graphs as an intelligence layer can retain more control over the reasoning their AI systems generate, rather than treating retrieval as a search problem.
Rizvi’s argument centers on the limits of retrieval-augmented generation. RAG systems can fetch relevant passages from documents, but Rizvi said they do not by themselves reason through relationships, show how an answer follows from evidence or build up reusable knowledge with each interaction. He described graph-based systems, when paired with a domain ontology, as a better fit for representing how decisions are structured from premises to reasoning to conclusions.
What is knowledge graph architecture in enterprise AI?
Knowledge graph architecture organizes entities, relationships and rules in a connected model that software can traverse. For enterprise AI, the pitch is that agents can use those links to follow evidence across systems, rather than only matching a prompt against document fragments.
Rizvi pointed to a truck-parts maintenance use case to explain the distinction. A startup building AI for that field needed to identify substitutes for a specific part, while also filtering for manufacturers that met several requirements at once. Across millions of SKUs, Rizvi said a search-based approach has difficulty following that kind of relational path, while a graph database can move through connected records and repeat that traversal across multiple routes until it finds a better answer.
That recursive path-following is useful only if the infrastructure can respond fast enough. Rizvi said latency is the main production issue for enterprise graph deployments. Thumos Care built a medical knowledge graph with Neo4j that connects diseases, symptoms, drugs and clinical guidance, and Rizvi said the work showed that some graph database platforms do not reliably handle millions of nodes at acceptable response times.
His recommended pattern is selective reasoning. Simpler questions should use faster, single-hop retrieval, while recursive graph traversal should be reserved for cases that require multi-step relationship analysis. That is a practical constraint for operators evaluating graph-backed agents: the architecture may support richer answers, but every additional hop can create a performance cost.
What data should go into the graph?
Rizvi also cautioned against treating the knowledge graph as a replacement for every enterprise database. Structured systems with data that changes frequently should usually remain where they are, he said. In that setup, the graph represents the ontology, so an AI agent understands what those systems contain and when to query them.
Unstructured material is a more direct candidate for graph ingestion, according to Rizvi. Slack conversations, meeting transcripts and chat logs can be extracted into graph form, where their context can be attached to customers, products, decisions or other domain entities over time.
The ownership claim is the more durable part of the argument. Rizvi said companies need ontologies for their domain, knowledge, cognition and decision-making if they want the intelligence created by their AI systems to remain an asset they control. That claim was made in theCUBE’s AI Luminaries interview series, for which SiliconANGLE disclosed that theCUBE is a paid media partner with Neo4j and said sponsors do not control editorial content.
This story draws on original reporting from SiliconANGLE.
