Knowledge graphs intro
Vector search returns the chunks most similar to a question. For a lot of real production questions that's not enough. You get similar text, but not how the pieces connect. And similar isn't the same as relevant.
One thing that helps here is representing your knowledge as a graph. A knowledge graph stores information as entities and the relationships between them, instead of flat chunks of text. You build it by extracting your content into nodes and edges (usually with an LLM doing the preprocessing) and storing that, either yourself or with a dedicated system that handles the extraction and storage for you.
Why I like graphs for this, with a few examples from customer support:
- Categorized information. Every node has a type, so you can query by category. Messages can be classified as requests, resolutions or other relevant categories. Then you can search specifically across similar requests, instead of every message in every thread.
- Relationships. Connections between entities are stored directly, so it's easy to find related entities and answer multi-hop questions with a pointed traversal. In customer support, you can also connect requests to their resolutions, so when you find a similar request, you can retrieve how it was resolved.
- Inference. A reasoning engine can derive new facts from the ones already in the graph. If a customer uses a feature affected by a bug, you can flag them as potentially affected, even if they haven’t reported it.
- Conflicting knowledge. Contradictions can get surfaced and resolved. One support response mentions a feature is available in all plans, another one says it’s available only on Enterprise. Linking those claims to the same feature can help surface the contradiction and start the resolution process.
- Explainability. Every answer traces back to specific nodes and edges. For example, when suggesting a resolution, you can show which similar requests it resolved.
Graphs are not free. The extraction needs to get right the categories and connections, and you either have to keep the graph up to date as your content changes or maintain a consistent way to build it on-demand. Stick with vector search when one passage answers the request and explore graphs when the answer depends on how concepts connect, like finding similar past requests and following each to its resolution.
I'll be posting more about it. For now, a couple of resources I liked:
Semantica - knowledge graphs with ontologies, temporal intelligence, and conflict detection. The docs are great and they cover the fundamentals well: https://docs.getsemantica.ai/concepts/
uni-db - a graph database with built-in logic programming, formal reasoning, and simulation in one process. One example I liked in particular, where it fuses vector x graph x lexical search in a single query, with RRF at the end. This example from their announcement is really cool:
MATCH (d:Doc)-[:REFERENCES]->(policy:Policy)
WHERE similar_to(d.embedding, 'access control violations') > 0.8
RETURN d.title,
similar_to([d.embedding, d.content],
[$query_vector, 'SOC 2 compliance'], {fusion: 'rrf'}) AS score
ORDER BY score DESC
https://blog.dragonscale.ai/the-ai-reasoning-layer-your-agents-are-missing/