Fixing RAG With an Ontology and Knowledge Graph in Semiconductor Docs

Where plain RAG goes wrong

A first retrieval-augmented generation prototype over product documentation usually looks encouraging. A vector store goes in, the documents get chunked, a few queries run, and the answers sound plausible. Then a verification engineer asks which methodology to use for power-aware verification on a given block, and the system replies, with total confidence, about functional verification methodology. The content is accurate on its own terms and wrong for the question.

The cause is vocabulary. In semiconductor verification, "methodology" isn't an everyday word. It points to specific verification approaches, each linked to particular tools, stages and execution artifacts. The pipeline retrieved text but not knowledge. That makes it a meaning problem and not a retrieval problem, and a better embedding model wouldn't repair it. A semantic layer does. What follows is how such a layer gets designed and built for an EDA documentation set: the ontology, the knowledge graph, the hookup to RAG, and the measured results.

Documentation as a knowledge desert

The setting is enterprise verification software, with thousands of DITA XML topics across several product lines, covering tool configuration, execution workflows and methodology guidance. The material exists, but as plain text instead of structured knowledge. Verification stages, methodologies and tools sit in separate documents and are tied together only by what a reader already knows. A veteran engineer with ten years of context copes. An LLM hunting for the right chunk walks through a minefield.

The aim was a fix that serves several needs at once: RAG, enterprise search, content discovery and long-term content governance.

Framing the problem first

Weeks of conversation came before any ontology code, with product managers, verification experts, documentation leads, search engineers and the data science team behind the GenAI assistant. Three questions guided those talks.

First, which business outcomes matter? The answers were better search accuracy, a canonical grounding layer for LLM assistants and unified data across product lines. Second, what does failure look like now? Keyword search returns irrelevant hits, users send follow-up queries because the first answer missed the context, and manual content linking can't keep up. Third, what would success look like? Retrieval should understand that a query on dynamic verification of power-managed designs needs content tied to one methodology, at one verification stage, involving particular tools, and not simply any document containing those keywords.

This groundwork heads off ontology bloat, the habit of modeling everything that seems intellectually interesting instead of what the business needs.

Discovering concepts and designing the ontology

Ontology design starts with knowledge discovery, not with Protégé or a Turtle file. Four inputs fed it:

• Interviews with verification engineers, who described how they think about tool relationships, execution order and decision points, which differs from how the tools work
• Existing documentation and tool interfaces, whose recurring terms revealed concepts that had stayed stable for years
• Logs, configuration files and pipeline definitions, which showed the true links between tools, stages and outputs and often disagreed with the documentation
• Search logs and support tickets, which exposed the distance between how engineers ask and how the docs answer

The result was a core set of stable domain concepts, effectively a taxonomy, and it was captured first in Excel on purpose. Ontology work is collaborative, and the people who must check the model, domain experts and product managers, don't read Turtle. A spreadsheet lets them validate and refine it, and build shared understanding, well before formal encoding begins.

Once the model settled over several review rounds, it was formalized with semantic web standards:

• RDF expresses every entity and relationship as triples
• OWL supplies class hierarchies, property constraints and logical rules
• SKOS standardizes terminology across product lines through controlled vocabularies
• Schematron checks correct ontology use during authoring in Oxygen XML

The ontology itself lives in TTL files, while the Schematron rules plug straight into the authoring environment. Authors therefore can't introduce concepts that break the ontology, so governance is part of the workflow and not an afterthought. Every mapping is enforced through prolog metadata in DITA XML and controlled vocabularies, with no freeform tags and no "close enough."

The knowledge graph architecture

The ontology needs a place to live, a graph that can be queried and traversed. The design splits into layers:

• Schema layer: ontology definitions in TTL files
• Terminology layer: SKOS-based vocabulary
• Instance layer: RDF triples produced from content metadata
• Infrastructure layer: Neo4j for storage and querying

Around those layers sit semantic ingestion pipelines that convert authored content into graph-ready triples and load them into Neo4j, query and retrieval APIs that expose the graph to consumers such as the RAG pipeline, and Azure cloud infrastructure for scale and integration with existing platform services.

The pipeline from authoring to graph is what lifts this beyond an ontology exercise. Authors write DITA in Oxygen XML. Schematron enforces ontology-compliant metadata as they type. Content publishes through Adobe Experience Manager. The semantic metadata survives that trip intact and is ingested into Neo4j, where search, analytics and AI systems can query it. It's architectural ownership of the full data flow, from the authoring tool through the graph to the API layer.

Plugging the semantic layer into RAG

This is where the effort pays off. Standard RAG chunks documents, embeds the chunks, stores them in a vector database, retrieves by similarity and feeds the hits to an LLM. It works, but it's blind to meaning, and three failure modes keep recurring:

1. Context confusion, where retrieval finds the right concept in the wrong context, like the verification stage mismatch described earlier
2. Vocabulary mismatch, where engineers use shorthand and the documentation uses formal terms, so relevant content gets missed
3. Hallucination through ambiguity, where unclear terms in a chunk let the LLM fill gaps with plausible but wrong domain knowledge

With the knowledge graph acting as the grounding layer, retrieval changes in four ways.

Ontology rules constrain what gets retrieved. When a query names a verification methodology, retrieval first resolves the term against the ontology, then limits the search to content tagged with that methodology and its valid relationships. Vector search still runs, but on a semantically filtered subset.

A canonical vocabulary gets enforced. User queries map to controlled terms before retrieval, so "power-aware sim" resolves to the formal term for power-aware simulation, and the right content comes back however the engineer phrased the question.

Chunks follow ontology boundaries instead of a fixed size. A passage on one tool's role in one verification stage stays whole and isn't cut mid-concept.

Invalid combinations are filtered out. The ontology records which tool, methodology and stage combinations are legitimate, so a chunk implying an invalid one gets demoted or dropped before the LLM sees it.

The gains showed up directly. Answers rest on verified, ontology-tagged content instead of the model's guesses about semiconductor verification. Narrowing what the model can see eliminated a class of hallucinations caused by ambiguous or context-free retrieval. Every retrieved chunk carries ontology metadata, so the system can explain its choice: which entity, which relationship, which constraint. And agentic workflows can traverse the graph to plan multi-step verification tasks from real entity relationships and not just text similarity.

The technology stack

• Authoring: Oxygen XML with DITA
• Validation and governance: Schematron and Schematron Quick Fix
• Ontology encoding: RDF, OWL and SKOS in Turtle files
• Knowledge graph: Neo4j
• Publishing: Adobe Experience Manager
• Cloud: Microsoft Azure
• RAG integration: custom retrieval APIs combining Neo4j and vector search
• LLM layer: a proprietary enterprise GenAI assistant

Results

Four metrics told the story after deployment:

• Follow-up queries fell by 30%. The documentation now acts as a high-fidelity ground truth for the AI assistants, and users get the right answer first time much more often. This was the key metric because it mirrors retrieval quality directly.
• Content reuse rose by 25%. With semantic tags and relationship awareness, the same content can appear across several product lines without manual copies.
• Manual linking time dropped by 60%. AEM's Related Content features now run on the graph, so links once curated by hand are generated from ontology relationships. Self-service for users improved by 25% as well.
• Manual content audit cycles shrank by 40%. Schematron rules derived from the ontology catch problems in Oxygen while authors work, so quality shifts left.

Lessons for similar projects

Model the domain before choosing technology. Teams often jump to Neo4j or a vector database before they can say what their entities and relationships are. That's building a house before drawing the floor plan. Spend the early time in a spreadsheet with domain experts. It lacks glamour, yet it's where the value originates.

Treat governance as structure. An ontology without governance decays fast, since each new author, product or edge case erodes consistency. Build validation into the authoring workflow so it happens automatically, instead of through periodic audits that always arrive late.

RAG without semantics is search with extra steps. Vector similarity is necessary but falls short for enterprise retrieval. When a domain has structured relationships, hierarchies and constraints, as most enterprise domains do, a semantic layer shifts retrieval from finding similar text to finding relevant knowledge.

Measure what the business cares about. "We built a knowledge graph" isn't a business outcome. "Follow-up queries dropped 30% because retrieval got more accurate" is. Each architectural choice should connect to a metric that people outside the team value.

What comes next

The semantic layer is the foundation and not the ceiling. The ontology keeps evolving, with new concepts tested, validated and merged without breaking existing semantics, and advances in LLM tooling, graph-AI convergence and agentic architecture can build on top of it. The wider lesson is that in the rush toward GenAI, the most underrated investment isn't a better model or a larger context window. It's a better semantic foundation. Models come and go, while meaning persists.