Banks in Singapore, property groups in Dubai and logistics firms in Riyadh are asking the same question: how do we get an AI assistant to answer using our policies, contracts and product data? There are two main answers, retrieval-augmented generation (RAG) and fine-tuning. Picking the wrong one is the most common reason AI pilots stall, and in regulated markets it can also create compliance headaches.
What RAG actually does
RAG leaves the model untouched. When someone asks a question, the system searches your knowledge base, pulls the most relevant passages and gives them to the model along with the question. The model writes an answer grounded in those passages and can cite where each fact came from.
- Fresh by default: update a document and the next answer reflects it, with no retraining.
- Traceable: every answer can link to its source, which compliance teams in financial services and government-linked companies will ask for.
- Access-aware: retrieval can respect user permissions, so staff only see answers from documents they are allowed to read.
- Easier to keep in-region: documents and embeddings can sit in a Singapore, UAE or Saudi cloud region you control.
What fine-tuning actually does
Fine-tuning changes the model itself by training it on examples of the inputs and outputs you want. It is good at teaching behaviour: a tone of voice, a strict output format, a classification scheme or domain shorthand. It is poor at teaching facts, because knowledge baked into the model cannot be cited, is hard to update and is hard to delete if a customer asks for their data to be removed.
Why this matters under PDPA and the Gulf data laws
Singapore's PDPA, the UAE's Personal Data Protection Law and Saudi Arabia's PDPL all give individuals rights over their personal data and restrict where it can be sent. With RAG, personal data stays in a database you can query, correct and delete from. Once personal data is trained into a model, honouring those rights becomes much harder. For most knowledge assistants, that alone points to RAG.
A simple way to decide
- If the problem is "the model doesn't know our information", start with RAG.
- If the problem is "the model knows enough but answers in the wrong format or style", consider fine-tuning.
- If content changes often, or answers must be auditable, RAG is almost always the better fit.
- If you need low latency at high volume on a narrow task, a fine-tuned smaller model can cut running costs.
Bilingual knowledge bases
Many Gulf companies keep documents in both Arabic and English, and Singapore firms often have material in English and Chinese. Modern multilingual embedding models let one RAG system search across languages, so a question in English can find the answer in an Arabic policy document. Test this on your own documents early, as quality varies between models.
Where projects go wrong
Most failed RAG systems fail at retrieval, not generation. Scanned PDFs, missing metadata and poor chunking mean the model never sees the right passage. Before choosing a model, clean and structure your content and build a test set of real questions with known answers. Our RAG and LLM development team starts every project this way, so you can see accuracy on your own documents before committing to a full build.
