Understand what each method changes
RAG supplies retrieved material to a model when it answers. Microsoft’s documentation describes it as a way to ground responses in private or changing information and provide source references. It does not, by itself, guarantee that the retrieved material is relevant or that the resulting answer is correct.[1]
Fine-tuning performs additional training that adjusts a pretrained model’s weights. Microsoft describes uses such as more consistent output structure and task-specific behaviour, while warning that improvements are not guaranteed. Its guidance calls for held-out evaluation and notes that training and hosting add costs.[2]
The decision process below is Kooya’s analysis for buyers and operators. It is not a claim that one method is universally cheaper, more accurate or more suitable for Philippine languages.
Run the supplied-evidence test first
Take a small set of real, permitted business questions that currently fail. For each, have the task owner prepare the correct answer and the evidence needed to produce it. Then give the baseline model that evidence directly, with clear instructions, and record what happens. This is a diagnostic exercise before choosing a retrieval system or a training project.
If the answer improves when the right evidence is supplied, investigate how the application finds and delivers that evidence. If the model still applies the wrong rule or produces an unusable result, investigate instructions, examples and task definition. Some failures will have both causes. Preserve that distinction in the review sheet instead of assigning every error to the model.
- Missing evidence: the answer requires a policy or record the model did not receive.
- Wrong evidence: the application supplies an outdated or irrelevant passage.
- Execution failure: adequate evidence is present, but the model applies it incorrectly.
- Ambiguous task: reviewers disagree on what a correct answer should contain.
Choose retrieval when the business fact must remain editable
Imagine a Philippine distributor whose staff need answers about product availability, delivery zones and return policies. These are hypothetical examples, not Kooya client results. The first question is where each fact is maintained and how quickly a change must reach the assistant. A current inventory value may require an authorized system lookup; a return-policy explanation may use document retrieval.
Kooya recommends asking the team to demonstrate a controlled change: replace an obsolete policy, repeat the same question and show the source supporting the new answer. Also test withdrawal. If a document is removed or a user loses access, the application should not continue serving that material through a stale index or cached response.
Microsoft’s RAG guidance distinguishes access to current information from changing model behaviour. Treat that distinction as a starting point, then test the specific data flow in your application.[1]
Use the company-document knowledge-base guide to plan permissions, freshness and source handling for the retrieval path.
Consider fine-tuning for a stable, demonstrated behaviour gap
Consider a support operation that already supplies the correct case facts, but needs a dependable internal handover format. First define the required fields, provide examples and add deterministic validation where possible. If the remaining failure is repeated and measurable, the team has a more specific training proposal than “teach the AI our business.”
Prepare examples of the behaviour you want, including difficult cases and acceptable abstentions. Keep evaluation cases separate from training examples. For English, Filipino or Taglish workflows, have capable reviewers assess the actual language mix; do not infer improvement in one language from results in another. These are Kooya’s evaluation recommendations, not promised fine-tuning outcomes.
Microsoft explicitly notes that fine-tuning does not replace retrieval for current information or application-level safety controls. A successful format test therefore does not establish that the system can access a restricted record or approve an action.[2]
Make the comparison fair enough to inform a purchase
Write down the baseline model, instructions, source snapshot, permitted tools and review rubric. Compare alternatives on the same held-out tasks. If you change the model, evidence and prompt simultaneously, the result may improve, but you will not know which change earned the extra complexity.
For each candidate, record whether the answer is usable, whether its evidence is correct, how much correction a reviewer performs and whether it respects the task boundary. Include no-answer cases, contradictory documents and inputs outside the intended scope. Report the results by task type so a strong average does not hide a weak high-consequence category.
- Baseline: clear instructions and approved examples, without a new training job.
- Retrieval candidate: the same task with a measured evidence-delivery path.
- Fine-tuning candidate: a documented training set and an untouched evaluation set.
- Combined candidate: only when separate tests show both an evidence gap and a behaviour gap.
Include the data decision in the architecture decision
NPC Advisory No. 2024-04, dated 19 December 2024, applies Philippine data-protection obligations when AI development or deployment processes personal data, including training and testing. It addresses lawful basis, transparency, security and data-subject rights. Choosing RAG instead of fine-tuning does not create an exemption.[3]
Before copying customer conversations into either a training set or a retrieval store, have the responsible privacy owner assess the actual purpose and data flow. Map the source record, derived datasets, indexes, provider uploads, logs and retained outputs. Decide what is needed for the experiment rather than importing the entire archive because it is available.
Ask how corrections and removal requests propagate through that map. Removing a source file is not evidence that every derived copy or trained artifact has been addressed. Require the supplier to explain the available controls and limitations for the selected implementation, then have the appropriate owner decide whether those controls meet the use case.
Price the update cycle and the exit
Ask for an operating estimate with explicit assumptions: expected questions, typical context size, document changes, review workload, training iterations and support ownership. Compare a month with stable demand and a month with a major policy or product change. Avoid a single cost-per-answer number that excludes the work needed to keep answers usable.
For retrieval, ask who repairs failed ingestion and verifies that a changed source is reflected. For fine-tuning, ask who curates examples, reruns evaluation and decides whether a new training job is justified. For both, ask what happens when the model or provider changes and how the team returns to the last acceptable version.
Record a reversible decision
End the trial with a short decision record: the failure being addressed, options tested, observed results, unresolved risks, ongoing owner and conditions for revisiting the choice. Keep a route back to the baseline. Do not make a training commitment merely because the organization wants to say it owns a custom model.
A useful outcome may be better prompts, a cleaner source system or a narrower task. It may also be retrieval, fine-tuning or a combination. The point of the comparison is to earn the next layer of complexity with evidence, while keeping the resulting system operable.