If you’ve ever tried to build a knowledge graph for your enterprise, you know the feeling. You spend months designing a beautiful schema. You map every business rule to nodes and edges. You launch with a sense of triumph — only to realize your system still can’t answer basic questions like “What’s the cancellation policy for this product?”
The dirty secret: most knowledge graphs are overengineered solutions to a problem that’s far simpler than we admit.
I learned this the hard way. I worked on a real enterprise knowledge graph — one that serves complex telecom products like “Tianyi Cloud Eye” (a surveillance camera service). Users ask things like “How do I sign up for the camera?” But internally, that product has a dozen aliases: “camera,” “monitor,” “cloud eye.” The system needs to map all those names to the same product before it can retrieve the right documents.
We started with a grand vision: every rule, every relationship, every constraint in the graph. A perfect model of business logic. Then we hit reality.
Here’s what we discovered: the graph’s highest-value use case is just normalizing names. Not storing complex rules.
Our architecture now looks like this: MongoDB stores raw documents and governance metadata. Milvus handles semantic search — finding “how to cancel” when the user says “I want to stop this service.” Elasticsearch does keyword matching for precise terms. And NebulaGraph? It mostly stores product entities and their alias relationships. That’s it.
We call it a “thin graph.” And it’s delivering 80% of the value with a fraction of the complexity.
Why does this work? Because the rules aren’t locked in graph edges. They live in document chunks — paragraphs that describe conditions, limits, and policies. When a user asks a question, the system uses the graph to resolve the entity (“camera” → “Tianyi Cloud Eye”), then retrieves the relevant document chunks via Milvus/ES, and finally lets a language model synthesize the answer.
The twist: you don’t need to store every rule in the graph. You just need to know who you’re talking about.
Most teams fall into the trap of over-engineering graph schemas. They try to encode “product applies to customer segment” or “promotion is valid in region” as edges. They build beautiful taxonomies. But the real bottleneck is entity disambiguation — mapping “1000M broadband” to “Gigabit Broadband” so the right FAQ gets pulled.
If you’re evaluating a knowledge graph system right now, don’t ask “does it use NebulaGraph?” Ask these questions instead:
- What are your node types? Just Product and Alias — or do you have Activity, Rule, Region, Channel?
- What are your edge types? Only alias_of — or also applies_to, valid_in, available_channel?
- Where do your business rules live? In graph nodes — or in document chunks retrieved by RAG?
- Can you trace every graph relationship back to a specific source document chunk?
If you can’t answer those clearly, you don’t have a knowledge graph. You have a graph database bolted onto a RAG system.
And that’s okay. In fact, it’s probably smarter. Because the moment you try to stuff all your rules into graph edges, you create a maintenance nightmare. Rules change. Policies get replaced. And suddenly your beautiful schema is a tangled mess that nobody dares touch.
Our roadmap is clear: keep the graph thin for now — focus on P0: product aliases. Then gradually add high-value relationships: product-to-promotion, promotion-to-customer-segment. But only when the entity disambiguation is rock-solid first.
The most dangerous thing you can do is build a perfect graph before you’ve solved the naming problem.
Stop over-engineering. Start with a thin graph and a good RAG pipeline. You’ll ship faster, frustrate your engineers less, and actually answer your users’ questions.
FAQ
Q: But doesn't a knowledge graph need to store all business rules to be useful?
A: No. Most rules are context-dependent and change frequently. Storing them in graph edges creates maintenance overhead. Instead, keep rules in document chunks and retrieve them via RAG. The graph's job is solely to disambiguate entities — once you know which product the user means, the language model can extract the right rule from the source text.
Q: What's the practical benefit of a thin graph approach for my team?
A: You'll ship months faster. Instead of spending six months debating schema design, you build a minimal graph that maps aliases, then connect it to your existing retrieval pipeline. The system becomes useful immediately — users get correct answers about product policies. You can always add more graph edges later when the entity resolution is proven.
Q: Isn't this just a glorified RAG system with a graph database?
A: Yes — and that's the point. Pure RAG without entity resolution fails on name variance (e.g., 'camera' vs 'cloud eye'). Pure graph without RAG fails on unstructured rules. The hybrid pattern gives you the best of both: graph for identity, RAG for context. Calling it a 'knowledge graph' is fine, but don't pretend your nodes hold all the wisdom. They hold the keys to the right documents.