What is RAG? Thai document search with AI you can verify

RAG has AI retrieve relevant documents first, then answer with sources. Building it for Thai: segmentation, hybrid search, evaluation, permissions, PDPA.

By UNIXDEV Team · 15 min read
Original published 2026-11-02 · English edition 2026-11-02

Retrieval-Augmented Generation (RAG) is a way to have AI first retrieve the relevant documents from an organisation's own collection, then generate an answer from that content with references to the sources. Users can check which document an answer came from, and when a policy or manual changes, you re-index it instead of retraining a model.

This guide is for IT managers, development teams and data owners considering a question-answering system over internal documents. It covers how RAG differs from fine-tuning and from AI agents, why Thai text needs special care in the search layer, how to measure accuracy, how to handle permissions and Thailand's Personal Data Protection Act (PDPA), and whether to run on premises or in the cloud. Product details and references were checked on 1 November 2026.

In short: RAG suits questions whose answers live in documents that change often. Answer quality depends on retrieval as much as on the model. For Thai, get word segmentation right, use hybrid search (keyword plus vector) and tune the dictionary with your organisation's own terms. Filter by permission at retrieval time, before anything reaches the LLM. Evaluate retrieval and generation separately with real questions, and let the system say "not found" when the documents do not contain the answer.

What is RAG, and how does it differ from fine-tuning?

RAG supplies retrieved content alongside the question at answer time; fine-tuning trains the model further on domain data. RAG addresses "the model doesn't know"; fine-tuning addresses "the model knows but behaves inconsistently".

The term comes from Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks by Patrick Lewis and colleagues, first posted to arXiv on 22 May 2020 and published at NeurIPS 2020. The paper describes RAG models as combining two kinds of memory: parametric knowledge in a pre-trained sequence-to-sequence model, and a dense vector index of Wikipedia accessed through a pre-trained neural retriever. Its motivation was that language models have limited ability to access and precisely manipulate knowledge, and that providing provenance for their answers and updating their knowledge were still open problems. In the experiments, RAG produced more specific, diverse and factual language than a parametric-only baseline.

Enterprise RAG systems today follow the same idea without copying the paper's architecture. OpenAI's Optimizing LLM Accuracy guide defines RAG as retrieving content to augment the prompt before generating an answer, giving the model domain-specific context, and separates two kinds of problem.

Choosing RAG or fine-tuning by symptom, summarised from OpenAI's Optimizing LLM Accuracy guide
Symptom	Better fit
The model lacks the knowledge: not in its training data, out of date, or proprietary	Context optimisation, such as RAG
Inconsistent output format, wrong tone or style, or reasoning not followed consistently	LLM optimisation, such as fine-tuning

OpenAI describes fine-tuning as continuing to train the LLM on a smaller, domain-specific dataset, to improve accuracy on a specific task or to gain efficiency through fewer tokens or a smaller model. It also notes that RAG only solves in-context problems; when the model has to learn to perform a task consistently, fine-tuning is the tool.

For questions over regulations, manuals or contracts, the documents change constantly and users need to know which version an answer came from. RAG is usually the better starting point because an edited document can be re-indexed straight away and its source can be shown. Consider fine-tuning later, if format or style problems remain that prompting cannot fix.

How is RAG different from an AI agent?

RAG retrieves documents and answers from them. An AI agent is a system in which an AI model chooses steps and calls tools to achieve a goal, for example looking up data across systems and drafting a result for a person to review. An agent may use RAG as one of its tools, but when the job is to search documents and answer from them, RAG alone is usually enough.

The distinction matters for risk. RAG only reads data, so the exposure is answer accuracy and data leakage. Once an agent can call tools that change data or trigger other systems, it needs much more permission control, human approval and testing. How to choose a pilot and judge whether it pays off is covered in AI agents in business: where to start and how to measure value.

How does a RAG system work?

A RAG system has two phases. Preparation runs once and again whenever documents change; answering runs on every question.

Extract text: read files from the document sources, such as file shares, the intranet or databases. Convert PDF and Office files to text, run OCR on scans, and keep the metadata you will need later: title, version, date, owner and permissions.
Chunk: split documents into passages short enough to send to the model but still self-contained, ideally along headings or clauses and never through the middle of a table.
Index: store each passage in a keyword index (after Thai word segmentation) and as a vector from an embedding model.
Retrieve and filter: for each question, search both indexes, keep only documents the asker is allowed to see, then merge and re-rank the results.
Generate: send the question and the retrieved passages to the LLM with instructions to answer only from them, cite the source, and say when the documents do not contain an answer.
Log and evaluate: record which question retrieved which documents and what was answered, under your log retention policy, for review and improvement.

Why is Thai harder, and how does hybrid search help?

Thai is written without spaces between words, so the search layer has to segment words correctly first. Poor segmentation breaks keyword search, and vector search on its own can miss terms that must match exactly. Combining the two suits Thai enterprise documents.

Thai word segmentation

OpenSearch's thai tokenizer documentation states that because Thai words are not separated by spaces, the tokenizer must find word boundaries with language-specific rules. Its example splits a sentence meaning "I like to travel to Chiang Mai" into six words: I / like / go / travel / at / Chiang Mai. The common options are:

The thai tokenizer (Elasticsearch/OpenSearch): Elastic's documentation says it uses the Thai segmentation algorithm bundled with Java, is not configurable and may not be supported by every JRE; for portability Elastic recommends the ICU tokenizer instead. OpenSearch also ships a ready-made thai analyzer built from the thai tokenizer with lowercase, decimal_digit, Thai stop and keyword filters.
The ICU tokenizer: the analysis-icu plugin segments on Unicode word boundaries (UAX #29) and uses a dictionary-based approach for Thai, Lao, Chinese, Japanese and Korean.
PyThaiNLP: word_tokenize defaults to the newmm engine, dictionary-based maximum matching, and also offers learning-based engines such as attacut and deepcut. It fits Python preprocessing, such as segmenting before chunking or checking segmentation output.

Whichever you choose, words missing from the dictionary remain the weak point: agency names, internal system names, abbreviations and mixed Thai-English technical terms. List them from real documents and check that they segment correctly before indexing the whole collection.

Hybrid search: BM25 plus vectors

Hybrid search runs keyword and semantic (vector) search in one request and merges the results into a single ranking. Elastic describes it this way and recommends merging with Reciprocal Rank Fusion (RRF). OpenSearch has supported hybrid search since version 2.11, merging results in a search pipeline by score normalisation, and added RRF-based merging in 2.19.

Keyword side: BM25 is the default similarity in Elasticsearch. It is strong on terms that must match exactly, such as document numbers, product codes, proper nouns and abbreviations, but depends on segmentation quality.
Vector side: it catches questions worded differently from the document but meaning the same thing, yet it can return something that is "close in meaning" when an exact match was needed, such as a similar regulation instead of the one asked about.
Merging: RRF scores each document as the sum of 1/(k + rank) across result sets. Elastic says it needs no tuning and the individual relevance scores do not have to be comparable.

The two methods fail in different ways, so combining them narrows each one's gaps. A re-ranker can then reorder the passages before they go to the LLM. Measure the actual effect against your own question set; benchmark numbers from other languages do not transfer.

Can an enterprise search engine such as Fess be the base for RAG?

Yes, and it saves work, because text extraction, indexing and permission filtering are what an enterprise search engine already does. Fess is Apache-licensed open source that you run on your own infrastructure, built on OpenSearch.

It crawls websites, file systems, Windows shared folders and databases, and extracts text from HTML, PDF and Microsoft Office files.
It supports single sign-on (Active Directory, SAML) and permission-aware results, with editable user and synonym dictionaries.
Its default index mapping defines a thai_analyzer for Thai fields using the thai tokenizer with thai_stop and thai_keywords filters.
According to the release notes, 15.8.0 added a chunking and embedding pipeline used to select context for RAG chat and as a semantic branch of regular search. 15.9.0 (15 October 2026) adds engine-side rank fusion, lets RAG Chat restrict itself to permitted roles and labels, and adds OCR for images and scanned PDFs during crawling.

UNIXDEV installs Fess with an OpenSearch backend, configures crawlers, tunes the synonym dictionary, adjusts the Thai analyzer so the organisation's own terms segment correctly (for example switching to the ICU tokenizer from the analysis-icu plugin where the default thai tokenizer splits domain terms badly) and connects permissions to Active Directory/LDAP. Whether to use Fess's own RAG Chat or use Fess as the retrieval layer for a separately built RAG application depends on the requirements; test both against real documents before deciding.

How do you measure RAG accuracy?

Measure the two halves separately: did retrieval find the right documents, and does the answer agree with them? OpenAI's guide names two failure points. Retrieval can supply the wrong context, or so much irrelevant context that it drowns out the real information and causes hallucinations. The model can receive the right context and still do the wrong thing with it.

The Ragas evaluation library has metrics that separate the two.

Common RAG metrics, from the Ragas documentation
Metric	What it measures	Half
Context Precision	How well the retriever ranks relevant passages above irrelevant ones	Retrieval
Context Recall	How many of the relevant documents or pieces of information were retrieved	Retrieval
Faithfulness	The share of claims in the answer supported by the retrieved context (0 to 1; an answer is faithful when every claim is supported)	Generation
Answer Relevancy	How relevant the answer is to the user's question (0 to 1)	Generation

Metrics are only as good as the test set. Collect real questions from users, with correct answers and source documents confirmed by the people who own them, and include three groups that are often forgotten:

Questions the documents cannot answer: the system must say it found nothing rather than invent an answer.
Questions answered only in documents the asker may not see: the system must not reveal that content, directly or indirectly.
Questions where documents conflict: for example an old and a new version of a regulation. The system must choose the version in force or show both with their dates.

On the prompt side, Anthropic's guidance on reducing hallucinations applies directly: allow the model to say "I don't know", have it quote the source for each claim, and have it retract any claim it cannot support with a quote. Whenever you change the model, the prompt, the segmentation or the chunking, re-run the same test set before release. Moving from pilot to production is covered in AI and LLMs in Thai enterprise systems: moving from pilot to production.

What about document permissions and the PDPA?

Filter by permission at retrieval time, before any text reaches the LLM. Telling the model in the prompt "do not reveal this" is not a control: once content is in the prompt, nothing guarantees the model will keep it out of the answer.

Filter at the document level

OpenSearch: document-level security (DLS) determines which documents a role can retrieve during read operations such as search and get; it does not restrict writes.
Elasticsearch: document level security limits which documents users can read. Watch for the trap: a role that does not specify document-level permissions grants access to all documents in the index.
Fess: role-based search filters results by the role, group or user set in the crawl configuration. A user without the required role will not see the document, even with the same query.

Index permissions must keep up with the source. When someone leaves a group or a folder's permissions change, know when the index will reflect it, and keep a test case that proves revoked access really is revoked.

What the PDPA requires that affects RAG

Many internal documents contain personal data, such as personnel files, requests and contracts, so a RAG system that reads them falls under the Personal Data Protection Act B.E. 2562 (2019), published in the Royal Gazette, vol. 136, part 69 Kor, on 27 May 2019. The directly relevant sections are:

Section 6: defines personal data as information relating to a person that enables the identification of that person, directly or indirectly, and separates the data controller (who decides on collection, use or disclosure) from the data processor (who acts on the controller's orders or on its behalf).
Section 26: sensitive data, such as health data, criminal records, religious beliefs, biometric and genetic data, may not be collected without explicit consent except under the listed exceptions. Keep such documents out of the RAG collection or put them under stricter access control.
Section 28: when personal data is sent or transferred abroad, the destination country must have adequate data protection standards under the Committee's rules, except in the listed cases. This applies directly when passages are sent to an LLM API processed outside Thailand.
Section 37(1): the controller must provide appropriate security measures against unauthorised or unlawful loss, access, use, alteration, correction or disclosure, and review them when necessary or when technology changes; permission filtering in a RAG system is part of this.
Section 37(2): when data is given to others, the controller must prevent its unauthorised use or disclosure.
Section 37(4): requires notifying the Office of the Personal Data Protection Committee of a breach without delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to risk people's rights and freedoms; high-risk breaches must also be notified to the data subjects.
Section 40: a processor must act only on the controller's instructions, provide appropriate security measures and notify the controller of breaches, and keep records of processing activities (small businesses may be exempted under the Committee's rules). The controller must have an agreement governing the processor's work, so an API provider or contractor processing documents for you should be covered by one.

This section summarises the relevant provisions and is not legal advice. Have your data protection officer (DPO) or legal adviser review the design before going live. The Personal Data Protection Committee also publishes an English translation, which is unofficial.

On premises or a cloud API?

There is no single answer. It depends on how sensitive the documents are, rules on transferring data abroad, whether your team can run the infrastructure, and how well the chosen model answers in Thai. Compare the options with the same test set.

Where to run a RAG system
Option	Fits when	Extra responsibilities
Cloud LLM API	Documents are not highly sensitive, and you want a model with strong Thai without running servers	Check the provider's data-processing terms and DPA, where processing happens (section 28) and the agreement under section 40
Self-hosted	Documents must not leave the organisation, or data residency rules apply	Servers and GPUs, serving the model with tools such as Ollama or vLLM, updates and security, and testing that the self-hosted model handles Thai well enough
Hybrid	You want the document store and indexes in-house but an external model for some data	Classify documents clearly and define which classes may be processed externally

Every option still needs permission filtering, logging and a test set. Running in-house reduces data transfer concerns, but it does not make the system secure by itself.

Data readiness checklist before starting RAG

The question: who asks, about what, and what counts as a usable answer. Pick one for the pilot.
Document scope: where the relevant documents are, who owns them, and which version is in force.
File formats: can text be extracted; are there scans needing OCR, or tables and images carrying key information?
Permissions: where permission data lives (file shares, AD/LDAP, a document system) and how the search layer will read it.
Personal data: whether personal or section 26 sensitive data is mixed in, and whether to remove, mask or restrict it.
Vocabulary: a list of agency names, system names, abbreviations and technical terms for segmentation and synonym dictionaries.
Test set: real questions with answers and sources confirmed by their owners, including unanswerable questions and questions the asker may not see answered.
Updates: how often documents change and how quickly the index must catch up.

Start with a data readiness assessment

UNIXDEV designs and builds RAG for Thai documents, from text extraction, segmentation, hybrid retrieval and re-ranking to answer evaluation with Thai question sets and integration with existing permissions, as part of our AI agent and RAG engineering service. We can build on an external API, fully on premises or as a hybrid, and compare the options on the same test set before you commit.

We recommend starting with an assessment of your documents, permissions and use case, so you know which collection to start with and how to measure it. You can send the details through the project brief form.

Assess your data readiness for RAG →

References and further reading

By the UNIXDEV Team · 1 November 2026 · Product details and references were checked on the date of writing (1 November 2026) and may change. The legal sections summarise statutory provisions and are not legal advice.