RAG or Fine-tuning? A Decision Matrix for Enterprise Turkish Documents
How do you connect your company's documents to a language model? RAG and fine-tuning compared on freshness, citations, KVKK and cost, plus three pitfalls specific to Turkish text.
In short: if you want to give a language model knowledge from your company documents, use RAG; if you want to change the model's behaviour or output format, use fine-tuning. For document sets that change often, RAG is both the cheaper and the more traceable place to start.
Retrieval-Augmented Generation (RAG) is a method in which a language model pulls relevant passages from your own document pool into its context before it writes an answer. Fine-tuning is retraining the model's weights on your data. The first gives the model a library; the second changes the model itself.
In most enterprise projects the difference comes down to one question: how often do the documents change? For a changing document set, fine-tuning means retraining after every update. In RAG, the same update is just indexing a new passage.
How do RAG and fine-tuning compare?
| Criterion | RAG | Fine-tuning |
|---|---|---|
| Documents change often | Good fit: new passages are indexed | Weak: retraining after every update |
| Answers must cite a source | Good fit: you know which passage an answer came from | Weak: knowledge blends into the weights and cannot be traced |
| Data must stay in-house (KVKK) | Good fit: can run fully closed | Depends on the training infrastructure |
| Tone or output format must change | Partly: through the prompt | Good fit: its main use |
| Very dense domain jargon | Partly: depends on retrieval quality | Good fit |
| Set-up cost | Low | High |
| Running cost | Retrieval on every query, longer context | Low once training is done |
Rule of thumb: RAG to add knowledge, fine-tuning to change behaviour. They are not rivals. In most production systems knowledge comes from RAG, and tone and format come from the prompt.
What decides answer quality in RAG?
The most common mistake is building RAG as "upload the documents and let the model answer". Answer quality depends less on the model than on which passage reaches it. If the retrieval layer brings the wrong passage, even the strongest model cannot know more than that passage says.
At GG Tech Teknoloji we built retrieval for a knowledge-base assistant in one of our internal tools like this: embeddings are stored in PostgreSQL with pgvector as 1536-dimensional vectors, similarity search runs on an HNSW index using cosine distance, and keywords sit in a separate GIN index. When semantic search returns fewer than three results, keyword matching steps in as a fallback.
Having both is deliberate. With vector search alone, proper names, product codes and abbreviations can slip through: a term like "GG Beacon SDK" can pull in a passage that is close in meaning but about something else. With keywords alone, a user who asks the same question in different words gets nothing. Hybrid retrieval combines the two, and which runs first and when the other steps in is a decision you make by measuring.
What makes RAG harder for Turkish documents?
- Agglutination: "yazılımın", "yazılımdan" and "yazılımlarımızdan" share one root but are different words on the surface. If the keyword side does no stemming, those three queries return three different results.
- Language balance in embedding models: multilingual models are trained mostly on English, so two spellings of the same Turkish sentence can produce vectors that are further apart than expected. Choose the model by testing it on Turkish questions.
- Character normalisation: Turkish maps "İ/ı" and "I/i" differently from English. Lower-casing with the wrong locale turns "İSTANBUL" into an unexpected form, and the match fails silently.
Matching errors like these raise no error message. In our own SEO dashboard, the regular expression that separates brand queries missed the spelling "gg tech" because an escape character was lost. We only saw it when the results were compared against real data. The same rule holds for RAG: you cannot know retrieval quality without measuring it against a test set.
When is fine-tuning the right answer?
- When the output format must be fixed, for example every answer must return a specific JSON schema.
- When the domain language is so specialised that a general model misuses its terms.
- When latency is critical and there is no time or budget for retrieval on every query.
- When the document set is frozen and changes about once a year.
If none of these four holds, starting with RAG and measuring is cheaper. Fine-tuning can be added later to solve a problem you have measured.
Frequently asked questions
- Can RAG and fine-tuning be used together?
- Yes. In most production systems knowledge comes from RAG, and tone and output format come from the prompt or from light fine-tuning. They solve different problems.
- Does RAG need a separate vector database?
- Not necessarily. PostgreSQL's pgvector extension stores vectors and runs similarity search on an HNSW index, which is often enough for small and mid-sized document pools.
- How do you measure whether a RAG system works?
- Measure retrieval before the model's answer: build a test set from real user questions and check whether the right passage comes back in the first few results. When retrieval is right, answer quality largely follows.
If you chose RAG, the next decision
RAG chunking strategy: size, overlap and split boundariesService
RAG and LLM integrationIf you are thinking of connecting your document pool to an assistant, the first question is not "which model" but "how will retrieval be evaluated". RAG built without measurement is no better than search built without measurement.
Author: Gürhan Elçiçek, founder of GG Tech Teknoloji.