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 — check back soon.
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
Context lives in the relationships
Jessica Talisman has been building knowledge systems since 1997, when Steven Spielberg's Shoah Foundation hired her to catalog Holocaust survivor testimony, on VHS, into two-to-six-minute segments. Twenty-five years of library science and enterprise information architecture later (Amazon, Adobe, Overstock, and the Department of Justice among them), she watches the AI industry rediscover her discipline and hand it to the marketing department. Her central claim in this episode: context is a property, not an object. It lives in the relationships between things, and the document you paste into a window carries none of them, which is why a bigger window changes nothing. She walks through the Ontology Pipeline, her iterative alternative to the big-bang ontology project: define a controlled vocabulary, test it against your LLM, earn the SKOS taxonomy, then the metadata schemas and lightweight ontologies, with a shippable artifact at every stage. Along the way: why roughly three quarters of your organization's context never made it into the database, why taxonomy is the early readiness test for whether you can operationalize an ontology at all, why this is not a data problem, and why you augment before you automate. All from a guest who named her company Contextually years ago and now cringes at the word.
Bring the graph to the data
A citizen in Italy asks a public chatbot when their civil-service exam is. The honest answer keeps moving: dates get corrected, sessions get cancelled, and amendments pile up across official notices. Ask a language model alone and it answers confidently, sometimes with a date it picked at random, sometimes with a session that no longer exists. Giuseppe Futia built the knowledge graph that keeps the answer current. It does the deterministic cross-document work an LLM cannot be trusted with, matching each amendment to the exam it modifies, superseding old versions, cascading cancellations, and staying auditable throughout, inside a production pipeline behind a chatbot he says serves close to a million citizens. A former La Stampa journalist with a PhD from Politecnico di Torino, and the first European guest on the show, he also opens up the regulated side of his work: healthcare data that cannot leave the country, inference that runs on premise, and patient records he is not allowed to move even inside his own infrastructure. His portable lesson is the entry point. Prove value on one well-defined task the institution already needs, then earn the right to expand.
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.