Services · Ontology
Your retrieval is not inaccurate. Your knowledge is unstructured.
The most common reason a RAG deployment answers badly has nothing to do with the model. It is that the same concept has four names, the relationships between concepts were never written down, and every department has its own version of the truth. That is fixable, and fixing it is finite work.
01 / Symptom
What it looks like from the outside
- The system answers fluently and is wrong often enough that nobody trusts it.
- It finds the document a person would have found by searching the obvious word, and misses the one they would have found by knowing the business.
- Accuracy improves when you change the embedding model, then regresses on a different question set, and no one can explain either movement.
- Every fix is a prompt change, and the prompt is now two pages long.
These are symptoms of retrieval failing upstream of generation. If the right passage never entered the context, no amount of model quality recovers it — the model will simply produce a confident answer from the wrong passage.
02 / Root causes
Three causes, in the order we usually find them
1. Terminology was never controlled
The same customer is a client in sales documents, an account in the billing system, and a counterparty in contracts. Embeddings absorb some of that, but they do not absorb in-house abbreviations, part-number formatting drift, or a product code that means two different things depending on the decade. When the question uses one word and the document uses another, the similarity score drops, and the right passage never makes the cut.
2. Relationships between concepts are undefined
To answer which process step produced this defect on this product, retrieval has to walk product to part to process to defect. If that chain exists only in an engineer’s head, vector search cannot walk it. It can only return documents that look similar to the question, which is a different operation and a much weaker one.
3. Departments have quietly forked the meaning
Two systems both have a field called status. They do not mean the same thing, they were never reconciled, and each department is locally correct. Merged into one index, they produce answers that are wrong in a way that is very hard to notice.
03 / Method
Five steps, and none of them start with a model
1 INVENTORY what exists, and where it lives
|
v
2 TERMINOLOGY one term per concept. synonyms
| mapped, homonyms split apart
v
3 STRUCTURE classes, and the relations
| between them
v
4 CONSTRAINTS what must hold. what cannot
| co-exist
v
5 MEASURED build the graph, then score it
against a fixed gold set.
improvement becomes a number
The retrieval we build on top of that structure follows one philosophy, and it is the same one our own product runs on: find the passage first, then expand from what was actually found — along the relations the ontology defines — so every answer keeps a trace back to its source. Vector search has a place in that design, and in client work we add it where it earns one; what we do not build is a system whose only path to an answer is similarity, because a similarity-only answer cannot explain itself. Neo4j, vector stores and the rest are implementation choices in service of that philosophy, not the philosophy.
An ontology is the specification; the knowledge graph is the instance built to that specification. The ontology says a company employs a person. The graph says TechJapan employs Kyono. Building the graph without the specification is how a graph accumulates contradictions in proportion to how much data you load into it.
Step five is the one that makes this an engineering exercise rather than a taxonomy exercise. We fix a gold set of representative questions with known correct passages, score retrieval against it before and after, and report the number. If the number does not move, the work did not work, and that should be visible to you rather than arguable.
04 / Scope and price
What is included
- Knowledge asset inventory: what exists, where it lives, who maintains it
- Ontology design: classes, relations, constraints, controlled terminology
- Knowledge graph construction on Neo4j or an equivalent store
- Evidence-first retrieval: the passage first, then expansion along defined relations — every answer keeps its trace. Vector search where it earns its place, never as the only path
- Quantitative retrieval accuracy evaluation against a fixed gold set
- Handover of the operating and maintenance process, so the vocabulary keeps being maintained after we leave
| Price | Quoted in writing per agreed scope, tax excluded. No published floor |
|---|---|
| First consultation | Free |
| Starting size | A single scoped process, not a company-wide dictionary. A company-wide dictionary is how these projects die |
| Typical first result | Terminology control alone usually removes the largest single cause of retrieval misses, before any graph work begins |
Where this is usually applied
- Internal knowledge search and internal RAG
- Structuring laws, internal regulations and contracts
- Integrating product, parts and technical information across systems
- Rebuilding an existing RAG deployment that is not accurate enough
05 / Why us
We run this method against our own product
Hadano AI Cabinet is a retrieval engine we built and measured: a character-trigram index ranked by BM25, then a one-hop graph walk seeded by at most three matched chunks, scoring nDCG@10 of 0.58 on SciFact for its keyword stage — a public benchmark, published as a floor rather than a comparison. The published record at h-c.ai also states which of its features are designed and not connected.
Separately, our chunking comparison reports where the boundaries actually landed across several domains, and the ontology design notes set out the same five steps in more detail.