Retrieval-augmented generation (RAG) is a way to make an AI assistant answer from your company's own documents instead of only from what a language model learned during training. Before answering, the system searches your knowledge base for relevant passages and hands them to the model, so replies are grounded in your policies, manuals and product data, and can point to where they came from.
Why business owners are hearing about RAG
Large language models (LLMs) such as GPT or Claude write fluent answers, but on their own they have no idea what is in your price list, your HR handbook or last month's SOP update. Ask them anyway and they may produce a confident, plausible and wrong answer, often called a "hallucination".
RAG fixes this without training a new model: you index your documents and let the model read the relevant parts when a question is asked. For an SME, business knowledge usually lives in PDFs, shared drives, LINE chats and a few senior people's heads. RAG makes it searchable in plain language, in Thai or English.
How RAG works, step by step
1. Collect and clean the documents
Sources can include PDFs, Word files, spreadsheets, web pages, support tickets and database records. Scanned paper needs OCR first. This step decides answer quality more than any other: outdated or contradictory documents produce outdated or contradictory answers.
2. Chunking
Long documents are split into smaller passages ("chunks"), often a few hundred words each, sometimes with a small overlap so sentences are not cut in half. Good chunking follows the structure of the document (headings, clauses, table rows) rather than cutting at a fixed character count.
3. Embeddings
An embedding model converts each chunk into a vector: a list of numbers that represents its meaning. Passages about "leave entitlement" and "annual holidays" end up close to each other even when they share no words. For Thai content, choose a multilingual embedding model that handles Thai well and test it on your own documents.
4. Vector database
The vectors are stored in a database that can search by similarity, for example PostgreSQL with the pgvector extension, or dedicated engines such as Weaviate, Pinecone or Chroma. Metadata such as department, document date and access level is stored alongside so results can be filtered.
5. Retrieval
When someone asks a question, it is embedded the same way and the system fetches the most similar chunks. Many production systems combine vector search with keyword search ("hybrid search") and add a re-ranking step. Keyword search is especially useful for product codes, invoice numbers and Thai text, where words are not separated by spaces.
6. Generation
The retrieved chunks and the question go to the LLM with instructions such as "answer only from the sources provided, and say so if the answer is not there". The model writes the reply and, ideally, links to the source documents so people can check it.
Practical use cases
| Use case | Who uses it | Typical sources |
|---|---|---|
| Internal knowledge base | Staff and new hires | HR policies, SOPs, IT guides |
| Customer support assistant | Customers on the web or LINE | FAQs, product manuals, shipping and return policies |
| Document Q&A | Sales, legal, procurement | Contracts, tenders, technical specifications |
| Sales enablement | Sales team | Price lists, product comparisons, proposal templates |
| Field and operations lookup | Warehouse staff, technicians | Equipment manuals, troubleshooting guides |
A customer-facing assistant usually lives in a channel your customers already use. Our guide to LINE chatbots for business covers that side of the picture.
What RAG cannot do
RAG is useful, but it is not magic. Plan for these limits:
- Garbage in, garbage out. If two documents disagree, the model may quote either one. Someone has to own and maintain the content.
- Retrieval can miss. If the right chunk is not retrieved, the model cannot use it. Testing with real questions is essential.
- Hallucinations are reduced, not eliminated. Instructions to refuse when sources are missing, plus visible citations, help a lot. High-stakes answers (legal, medical, financial) still need human review.
- Weak at aggregate questions. "What was our revenue by region last quarter?" is a database query, not a document search. Connect the AI to structured data or reports for that.
- Ongoing cost. Every question uses LLM tokens, and the index must stay in sync as documents change.
RAG vs fine-tuning
Fine-tuning means training an existing model further on your own examples to change how it behaves. The two solve different problems.
| RAG | Fine-tuning | |
|---|---|---|
| Best for | Answering from facts that change | A consistent style, format or narrow task |
| Updating knowledge | Re-index documents | Retrain the model |
| Citing sources | Straightforward | Not natural |
| Upfront effort | Moderate | Needs a curated set of training examples |
| Access control | Filter by user permissions at retrieval time | Hard, because knowledge is baked into the model |
For most business knowledge problems, start with RAG. Fine-tuning becomes worth a look when you need a very specific output format or tone at high volume, and the two can be combined later.
Data privacy and on-premise options
Business owners rightly ask where their documents go. A few principles keep a RAG system safe:
- Know the data flow. With a cloud LLM API, the retrieved chunks are sent to the provider for each question. Read the provider's data-retention and training policies, and prefer business terms that exclude your data from model training.
- Enforce access rights. Store permissions with each chunk and filter at retrieval, so a sales employee cannot pull payroll documents just by asking the right question.
- Comply with the PDPA. Thailand's Personal Data Protection Act applies to personal data inside your documents. Index only what you need, mask personal data where it adds nothing, and keep an audit log of questions and answers.
- Self-hosting is possible. The vector database, document store and application can run on your own servers or a private cloud, and the model can be an open-weight LLM (including Thai-focused models such as Typhoon) on your own GPUs. The trade-off is more infrastructure work and, often, somewhat lower answer quality than the largest hosted models.
A common middle path is to keep documents, embeddings and logs in your own infrastructure and send a hosted LLM only the few chunks needed for each answer.
How to start a RAG project
- Pick one narrow use case with a clear owner, such as HR policy questions.
- Collect 50 to 100 real questions people actually ask, with the correct answers. This becomes your test set.
- Clean the source documents and remove outdated versions.
- Build a pilot, measure accuracy against the test set, and tune chunking and retrieval.
- Roll out to a small group, gather feedback, then expand.
Vectorkub builds RAG search, OCR pipelines and LINE chatbots as part of our AI solutions service. Projects start at 44,999 THB, and the final price depends on your requirements.
FAQ
Do I need a lot of data to use RAG?
No. A few dozen well-written, current pages are enough to start.
Can RAG answer in Thai?
Yes, as long as the embedding model and the LLM handle Thai well. Test with real Thai questions from your team, and consider hybrid search, because Thai text has no spaces between words.
Is RAG the same as ChatGPT?
No. ChatGPT is a general-purpose assistant. RAG is an architecture built around an LLM so that it answers from your own sources and follows your access rules.
How long does a RAG pilot take?
It depends mostly on how clean your documents are. A focused pilot usually takes weeks rather than months; complex permissions or lots of scanned paper add time.
Next step
If your team keeps asking the same questions about a pile of documents, that is usually a strong first RAG candidate. Tell us about your use case and we will suggest a pilot scope and a privacy setup that fits your data.