Contact

Vector Database and RAG in ERP Systems: Semantic Search, Embeddings, and Retrieval

Why would ERP need a vector database when SQL and classic search already exist? Because some questions do not ask for the exact field value of a record; they ask for meaning across scattered text. Getting that distinction right is the starting point for both useful search and a safe AI layer.

A vector database does not replace a relational database. RAG is not the claim that 'AI knows everything'; it is the discipline of finding appropriate context and grounding a response in it.

Table of contents

The Topic in Five Minutes

Structured search

Find the record with part code ABC-123.

Semantic search

Find maintenance records similar to machines stopped by bearing failure last year.

Structured search

Works through field values, filters, and relationships.

Semantic search

Finds candidate context through similarity of meaning.

Structured search

Strong for exact matching and transactional data.

Semantic search

Strong for researching narrative, documents, and experiential knowledge.

These searches are not competitors. A sound enterprise design often combines structured filters and semantic retrieval: similar maintenance notes can be searched within a specific site, date range, and access boundary.

Mental Model: From Data to Meaning

Preparing ERP data for semantic search

  1. 1

    ERP Data / Document

    A document, support record, or narrative knowledge.

  2. 2

    Text Representation

    Searchable text and meaningful metadata.

  3. 3

    Chunking

    Splitting text into small parts without losing context.

  4. 4

    Embedding Model

    Transforming text into a numerical representation of meaning.

  5. 5

    Vector Database

    An index and retrieval layer for similarity.

RAG query flow

  1. 1

    User Question

    A question in natural language.

  2. 2

    Embedding + Similarity Search

    Finding candidate context close to the question.

  3. 3

    Relevant Context

    Selected sources with access and filters preserved.

  4. 4

    LLM

    Explaining or summarising from the provided context.

  5. 5

    Grounded Answer

    A response with sources and visible uncertainty.

Keeping the Concepts Separate

Distinction

SQL search ≠ semantic search

What it means

One prioritises fields and relationships; the other prioritises similarity of meaning.

Distinction

Vector DB ≠ relational DB replacement

What it means

A vector index does not replace transaction integrity or master-record management.

Distinction

Embedding ≠ LLM response

What it means

An embedding is a numerical representation for search, not a user-facing answer.

Distinction

Retrieval ≠ generation

What it means

The first selects relevant context; the second expresses an answer using it.

Distinction

Similarity score ≠ factual certainty

What it means

It is a proximity signal; business correctness and source suitability need separate evaluation.

The value of RAG is not making a model speak more. It is helping it answer more cautiously, from the right scope, with traceable sources.

What Can It Solve in an ERP Context?

Semantic retrieval is especially useful across narrative and dispersed knowledge surfaces: technical-document research, maintenance history, service and quality records, project lessons learned, policy/procedure search, product descriptions, support records, and contract or enterprise-document research. These are conceptual examples, not customer cases. The real measure of value is whether a user can make a better, source-backed decision sooner.

  • Is the question looking for a similar experience or explanation rather than just one field?
  • Does returning to the source create value for the user?
  • Is the material narrative or knowledge content rather than transactional data?
  • Can access boundaries still be enforced at retrieval time?

Should Every ERP Record Go into a Vector Database?

The direct answer

No. Moving data to a vector database is a data-classification decision, not a default architecture.

Data type

Transaction data

First consideration

The relational layer remains primary for correctness, integrity, and exact queries.

Data type

Master data

First consideration

Business keys, filters, and reference integrity remain central.

Data type

Documents

First consideration

If text has meaning, it can be a candidate with chunking, metadata, and access control.

Data type

Narrative/text data

First consideration

A strong candidate for semantic search when context and freshness are designed.

Data type

Logs

First consideration

May help incident research, subject to retention and sensitive-data rules.

Data type

Knowledge content

First consideration

A common RAG candidate when citation and update flow are in place.

Instead of copying everything, consider references, reduced text, metadata, and access context. Data minimisation reduces both cost and exposure.

What Should I Examine?

  • What is the source, owner, and refresh rate of the data?
  • Does the chunking strategy preserve meaning and source reference?
  • If the embedding model changes, how will the existing index be renewed?
  • Does metadata carry filters such as date, document type, site, access, or version?
  • Is access control enforced during retrieval?
  • Is the similarity threshold evaluated with representative questions?
  • Are citations and hallucination boundaries visible to the user?
  • When should a structured query and semantic query work together?

Where Is It Commonly Misunderstood?

Anti-pattern

Indexing all data

Why it is risky

Purpose, cost, access, and update debt stay unclear.

Anti-pattern

Treating a score as truth

Why it is risky

Similarity does not establish business correctness or source quality.

Anti-pattern

No citations after retrieval

Why it is risky

The user cannot verify the answer and trust forms in the wrong place.

Anti-pattern

Applying permissions only in the UI

Why it is risky

The retrieval layer can leak information.

A successful RAG use case does not begin with the largest model. It begins by clarifying the knowledge source, access boundary, update process, and decision the answer is meant to support.

One Page Cheat Sheet

Concept

Embedding

Short version

A numerical representation of text meaning for retrieval.

Concept

Vector

Short version

The multi-dimensional numeric output of an embedding.

Concept

Chunking

Short version

Dividing a document into meaningful retrieval units.

Concept

Retrieval

Short version

Finding context candidates most relevant to the question.

Concept

RAG

Short version

Using retrieved context as the basis for generative answers.

Concept

Grounding

Short version

Tying an answer to visible, appropriate sources.

Mini glossary: semantic search = search by similarity of meaning; similarity = proximity between meaning representations; threshold = a boundary for candidate consideration; hallucination = unsupported generation not grounded in source material.

A Note for Those Researching TROIA

TROIA's public developer documentation includes a Vector Databases topic, showing that the concept also has a current counterpart in that ecosystem. This guide does not teach product commands or configuration; it explains the conceptual basis for semantic retrieval and RAG. Refer to the original documentation for current TROIA-specific detail.

Frequently asked questions

Does a vector database replace SQL?
No. Relational data remains central for transactions, master data, integrity, and precise filters. A vector layer complements that with meaning-based retrieval.
Can RAG still give a wrong answer?
Yes. Retrieval, source quality, access filters, and generation instructions must be designed together; sources and uncertainty should remain visible in the answer.
Is there one correct similarity threshold?
No. It needs evaluation against representative questions because data type, language, embedding model, and user needs all vary.

Related pages:

Sources and further reading

Vector Database and RAG in ERP Systems | Fatih Görgülü | Fatih Görgülü