The invisible problem
Divya Singh runs a semantic error-code knowledge graph in production at Dell, grounding technical-support agents across roughly 80,000 articles and twenty product lines. She splits the failures into two kinds. The visible ones are ranking problems: the right article exists but comes back fourth, and you can see that and go fix it. The invisible ones arrive confident, fluent and correctly cited, and are simply wrong, and those are the ones that reach a customer. Her answer sits earlier than most teams put it, with a domain expert validating the graph itself rather than a reviewer checking answers at the end.
This episode hasn't aired yet — get notified the moment it drops.
Divya Singh
A data engineering leader working on knowledge graphs, enterprise data architecture and applied machine learning, with work spanning graph-based search, entity resolution, recommendation systems and AI-driven decision support in large enterprise environments. At the Knowledge Graph Conference 2026 she presented on KG-grounded AI agents for technical support, built on a semantic error-code knowledge graph.
What we'll cover
- 01The use case in full: error codes, symptoms and resolutions across roughly 80,000 support articles and twenty product lines, with the same code reused across different products.
- 02Where plain RAG stopped working, and the specific retrieval failure that made a knowledge graph necessary rather than preferable.
- 03Visible versus invisible failure, the ranking bug you can see and fix, against the confident, cited, wrong answer that reaches the customer.
- 04Why LLMs changed knowledge-graph work at the build stage rather than the query stage, replacing handwritten ontologies and brittle regex rules.
- 05Choosing a labelled property graph over RDF for this problem, and the conditions under which she says that choice would flip.
- 06Maintenance at scale: daily article updates, selective refresh rather than full rebuild, alerting and pipeline monitoring as first-class work.
- 07Handling conflicting and stale facts in a corpus large enough that contradictions are inevitable.
- 08The counterintuitive one: domain experts validating and curating the graph itself, upstream, not reviewing answers downstream.
- 09Her advice to a CTO: stop treating your data as opaque strings and start treating it as a semantically rich domain with real relationships.
Related episodes
Relationships should be the product
Himanshu Singh has built knowledge graphs three times at three very different scales: a politics subgraph inside Microsoft's Satori, a zero-to-one product graph at eBay, and now Netflix's Entertainment Knowledge Graph, where he leads engineering. The line he keeps returning to is that relationships should be the product. Node count is not the measure, and a graph that duplicates what already lives in your CRM or your warehouse is mostly cost. He is notably relaxed about technology choice, pointing out that Netflix built its own real-time graph abstraction over a key-value store because no native graph database could absorb their write volume. What he is not relaxed about is data quality at the point of entry, because once bad data is in a graph and connected to everything else, undoing it is very hard.
Every silo is its own context
Dave McComb has been building enterprise systems for fifty years and running Semantic Arts for twenty-five. His rule of thumb is one application for every ten employees, so a hundred-thousand-person company is running ten thousand databases that each name, structure and identify everything differently. That is also his answer to the age of context: the problem was never a shortage of it, it is that every silo has its own. Along the way he explains why an LLM will hand you an ontology that opens cleanly in Protégé and looks like exactly what you asked for, why that is the trap rather than the win, and what he found when he put semantic lenses back on his own accounting system after twenty years of not looking at it.
An ontology fits on a Post-it note
Casey Hart is a rare thing: an actual ontologist. A philosophy PhD who answered a job ad from Cycorp and spent a decade building knowledge for machines under Doug Lenat and then at Olive, Amazon, Gro Intelligence, and Ford, he spends this episode deflating the word everyone is suddenly selling. An ontology, he argues, is just a summary of what your business cares about and how those things relate — you can start one on a Post-it note. He separates the machine-learning "system one" from the deterministic "system two" that ontologies supply, makes the case for a hybrid, and walks through building one from the ground up: taxonomies, relationships, turtle files and triple stores — or just the metadata, so you get value before migrating a single row. Along the way: why "hallucination" flatters a text generator doing exactly what it was built to do, the open-world versus closed-world assumption, and why vibe-coding an ontology out of an LLM is a fine way in but not a finished asset.