Answers that follow the relationships.
Ordinary retrieval finds text that looks similar. Graph-RAG follows the relationships between entities, so a question about an obligation reaches the clause, the amendment that changed it and the party it binds. iLeaf applies this to contract intelligence, where a confident wrong answer is a liability rather than an inconvenience.
Ask Lia about rag & graph-ragWhat this includes
- Knowledge graph construction
- Entities, relationships and hierarchy extracted from your documents, so structure is queryable rather than implied.
- Hybrid retrieval
- Graph traversal combined with vector and keyword search, because each one fails on questions the others answer.
- Clause & obligation extraction
- Terms, dates, parties, liabilities and renewal windows pulled out with a citation back to the source clause.
- Amendment chains
- Which version actually governs today, and what changed it — the question flat retrieval reliably gets wrong.
- Obligation monitoring
- Renewal and notice dates surfaced before they lapse, rather than discovered afterwards.
- Cited answers
- Every answer points at the passage it came from, so a lawyer can verify it in seconds instead of trusting it.
How we run it
Every phase ships something usable on its own, so you are never holding a half-finished system waiting on the next milestone.
Model the domain first
We agree what the entities and relationships are — parties, agreements, obligations, amendments — before any indexing.
Build a graded question set
Real questions with known answers, including the ones current tooling gets wrong, become the measure of success.
Measure retrieval, not vibes
Retrieval accuracy is scored against that set before a single answer is generated on top of it.
Require citation
The system answers with sources or declines. In contract work an unsourced answer has no value.
What we build it with
- Neo4j
- pgvector
- PostgreSQL
- Python
- LangGraph
- Claude
- OCR pipelines
- Elasticsearch
- spaCy
- Model Context Protocol (MCP)
- Airflow
- Redis
Questions we get asked
Why not just use ordinary RAG?
Vector search retrieves passages that read similarly to the question, which fails when the answer depends on structure — which amendment supersedes which clause, or which entity a term binds. A graph encodes those relationships explicitly, so the retrieval step can traverse them instead of hoping the right paragraph happens to be nearby.
How accurate is clause extraction?
It depends on your documents, which is why we build a graded question set from your real contracts and measure against it before committing to an approach. Every extraction cites its source clause, so accuracy is verifiable by your team rather than taken on trust.
Does this replace our CLM system?
Usually it sits on top of one. A CLM stores and routes contracts; it rarely reasons across them. We integrate with what you have so the repository stays the system of record, and the intelligence layer answers the questions it cannot.
Let’s talk about rag & graph-rag.
Tell us what you are running and what it needs to do next. We will tell you honestly whether we are the right team for it.