LLMs with Ontology for Defect Detection in Additive Manufacturing

Laser powder bed fusion (LPBF) metal 3D printing has long been one of the most promising processes for manufacturing highly complex parts in aerospace, medical implants, and automotive components. The problem: when a defect appears—porosity, cracks, delamination—knowing exactly what caused it and how to fix it requires rare, specialised process expertise that is difficult to scale. A paper published on 6 May 2026 on arXiv proposes a concrete approach to tackle this bottleneck.

The work, available at arXiv:2605.01100, describes a decision support system that doesn't simply query a generic LLM. Instead, it builds a structured knowledge base with 27 types of LPBF defects organised hierarchically, with their causal relationships encoded in an ontology. The language model acts as a reasoning interface over that knowledge graph, not as a truth source on its own.

What the system does exactly

The architecture operates across three functional layers worth understanding separately:

• Knowledge retrieval through natural language queries: the operator can write an imprecise description of the observed symptom—a fuzzy query—and the system translates it into a structured search over the ontology. This removes the requirement for exact technical terminology from the end user.
• Traceable explanation with bibliographic backing: answers about causes and mitigation strategies aren't freely generated by the LLM; they're anchored to literature encoded in the knowledge base. Each diagnosis carries its explicit reasoning chain, allowing it to be audited.
• Multimodal image evaluation module: integrates vision foundation models to interpret defect micrographs. The system uses semantic alignment scoring to associate defect descriptors with image regions, rather than relying on closed-set classification.

The complete system was evaluated through qualitative comparisons against general-purpose vision-language models, an ablation study, and inter-rater reliability analysis. The researchers argue that ontology integration is what makes the difference compared to using an unstructured LLM: it reduces factual hallucinations in the domain and allows an expert to verify the reasoning step by step.

Why this approach matters

The underlying problem this work solves isn't unique to LPBF: it's how to make an LLM useful in safety-critical domains where error has real physical consequences. In aerospace or medical manufacturing, an incorrect defect diagnosis isn't a poorly written Wikipedia article; it can result in a part failing in service.

The strategy of anchoring LLM reasoning to an expert-verified ontology is one of the most robust answers research is currently offering to this problem. It's not new as a concept—ontology-based expert systems have existed for decades in knowledge engineering—but the novelty here lies in combining it with natural language interfaces and image analysis modules, making it operational for users who aren't knowledge engineers.

For those working on LLM integration in industrial environments, the paper offers a concrete reference schema: ontology as the truth layer, LLM as the reasoning and interface layer, and vision models as the perceptual layer. Each layer is relatively independently replaceable or upgradeable.

Who should care about this

This work is relevant to three distinct profiles. First, manufacturing engineering teams evaluating whether LLMs can assist with quality control without assuming explainability risks. Second, developers building RAG (Retrieval-Augmented Generation) systems in technical domains seeking architecture patterns where the retrieval source is an ontology rather than plain text corpora. Third, those defining validation criteria for AI in regulated environments: the inter-rater reliability approach as an evaluation metric is directly exportable to other domains.

The code and knowledge base aren't mentioned as public in the available summary, which is a relevant practical limitation if you want to replicate or extend the work.

---

From our perspective, the direction is right: less LLM as oracle, more LLM as interface over verifiable knowledge. The challenge now is getting this type of architecture out of the lab with enough documentation that industrial teams can adopt it without depending on the original authors.