Most AI assistants over company documents rely on vector search: text is turned into embeddings, and a question retrieves the passages whose embeddings are closest to it. It is a powerful technique for finding text that means something similar to the question, even when the wording differs.
Manufacturing questions are often of a different kind. Which parts use this material? Which revision of this drawing was released when that lot was produced? Which supplier delivered the batch named in this nonconformance? Which inspections were performed on this characteristic? These questions are about specific entities and the relationships between them, and similarity is not the right tool for exact identity.
This article compares the two approaches on the questions manufacturers actually ask, explains what each one is good at, and describes why the strongest designs use a governed knowledge graph for entities, relationships and permissions, and vector search for passages.
What vectors do well
Similarity is the right tool for prose
Vector search earns its place wherever the question is about meaning rather than identity.
Embeddings capture what a passage is about. A question about a recurring vibration problem can retrieve a maintenance report that describes resonance in a pump bearing, even though the two share few words. That is valuable over procedures, work instructions, failure narratives, audit observations and any other content where people describe things in their own words.
Vector search is also forgiving. It needs little upfront modeling, copes with varied writing styles, and can be pointed at a new collection of documents quickly. For exploratory questions, where the user does not yet know which document or which entity they are looking for, it is often the best first step.
Its limits come from the same property. Similarity is continuous, not exact. Two part numbers that differ by one character are nearly identical as text and completely different as parts. Two revisions of a specification can be almost the same passage. A supplier name can appear in a certificate, a contract and a complaint, and vector search has no way to know that these refer to the same organization, or that a similarly named one is a different company.
What graphs do well
Identity, relationships and constraints
A knowledge graph stores entities and the explicit relationships between them, so questions about which, where and how many become precise.
In a graph, a part is a node with an identifier, attributes and links: to the drawings that define it, the revisions of those drawings, the assemblies that use it, the suppliers that deliver it, the certificates that accompany each batch and the inspections performed on it. A question such as which released assemblies use a part delivered by a given supplier is a traversal across those links, and the answer is a complete list rather than the handful of passages that happened to rank highest.
Graphs handle constraints that similarity cannot. Filter to released revisions only. Exclude superseded documents. Restrict to a site, a program or a time window. Count, compare and enumerate. These are the operations behind most quality, engineering and procurement questions, and they need structure to be answered reliably.
The graph is also the natural place for governance. Each node and relationship can carry its lineage, its classification and the permissions inherited from its source system. When an assistant queries the graph on behalf of a user, the query can be limited to what that user may see before any content is retrieved, which is much harder to enforce over an undifferentiated pool of text chunks.
Combining them
Graph for entities, vectors for passages
The useful question is not which method to choose but which job each one does in the same retrieval path.
A combined design typically resolves the entities in a question first. The part number, drawing, supplier or lot mentioned by the user is matched to nodes in the graph, and the relevant relationships are followed: the released revision, the related inspections, the certificates for the batch. This produces a precise, permission-filtered set of facts and the documents they came from.
Vector search then works inside that scope. Instead of searching the whole archive for passages similar to the question, it searches the notes, reports and procedures linked to the resolved entities. The passages it returns are relevant by meaning and correct by identity, because they are attached to the right part and revision. Where a question has no clear entity, vector search can run first, and the graph can be used to expand or check what it found.
The model then receives two kinds of context: structured facts with their source locations, and supporting passages that explain them. It can answer precisely where precision is possible, explain where explanation is needed, and cite both. When the answer depends on a fact that is missing from the graph, the system can say so instead of filling the gap from a similar passage.
In practice
Four manufacturing questions, two retrieval paths
The difference shows most clearly when the same questions are run through each path.
Which part? A user asks about a mounting bracket by its description. Vector search over drawings and reports finds passages that mention similar brackets. The graph resolves which of them is the part the user means, using its identifier, its assembly and its material, and returns that part with its drawings and the documents that reference it.
Which revision? The graph answers directly from revision records and their release status, then vector search retrieves the change notes that explain what changed and why. Without the graph, the assistant has to infer the current revision from text, which is exactly where errors creep in unnoticed.
Which supplier, and which inspection? Both are relationship questions. The supplier is linked to the batch through certificates and receipts, and the inspection to the part, the lot and the characteristic. The graph returns complete, permission-filtered lists, and vector search adds the narrative from inspection remarks or supplier correspondence that helps a person interpret them.
How sDEN approaches it
Retrieval designed around the question
sDEN Foundation builds the governed knowledge graph that combined retrieval depends on, and keeps vector search where it belongs.
Within this scope
Entities resolved across systems
Parts, drawings, suppliers, lots and inspections are resolved across documents and systems, then linked with their sources, lineage and access rules.
Within this scope
Passages attached to entities
Prose from reports, procedures and notes stays searchable by meaning and is linked to the entities it describes, so passage retrieval can be scoped to the right part and revision.
Within this scope
Permissions before retrieval
Existing permissions travel with the data into the graph, so every query is limited to what the user may see before any content reaches a model.
What good looks like
Precise where it must be, flexible where it can be
A good manufacturing assistant returns complete lists for list questions, exact values for value questions and explanations for open questions, each with its source.
Users stop seeing the typical failures of vector-only retrieval: an answer that mentions the right part but quotes the wrong revision, or a list that silently omits matching items because they did not rank. Structured questions get structured answers, and the assistant is explicit about what it found and where.
Engineering, quality and procurement teams can use the same graph for different questions without building separate indexes. The graph also feeds analytics, dashboards and the systems of record, so the effort spent on modeling entities serves people and applications, not only AI.
Because the graph holds the knowledge and models consume it, the retrieval layer is not tied to a particular model or vendor. Private open-weight models can be replaced as better ones appear, and the governed graph remains.
Questions
Manufacturing knowledge, answered.
Is a knowledge graph better than vector search?
Neither is better in general. Vector search is the right tool for finding passages by meaning. A knowledge graph is the right tool for exact identity, relationships, constraints and permissions. Manufacturing questions usually need both, so the strongest designs use the graph to resolve entities and scope the question, and vectors to retrieve supporting text.
Why does vector search confuse similar part numbers or revisions?
Embeddings represent meaning, and two identifiers that differ by a single character, or two revisions with nearly identical wording, look almost the same as text. Similarity cannot tell them apart reliably. A graph stores each part and each revision as a distinct entity with its own attributes and status.
Do we need to model our entire business before building a graph?
No. A graph can start with the entities a priority set of questions depends on, for example parts, drawings, revisions and suppliers for an engineering use case, and grow as new questions are added. The schema is defined with your subject matter experts around the decisions it supports.
How are permissions handled in a combined design?
Permissions inherited from the source systems are attached to entities and documents in the graph. A query on behalf of a user is limited to what that user may see before passages are retrieved, so neither the structured facts nor the supporting text include content outside their access.
Does the graph tie us to one AI model?
No. The graph holds governed, source-linked knowledge, and models read from it. Models can be replaced without rebuilding the graph, which is one reason to invest in the data layer rather than in model-specific tuning.
