RAG, search, or fine-tuning: which does your AI application need?

Begin with the result your user needs

Suppose an employee asks, ‘Which installation guide applies to this product?’ Returning the correct guide may solve the problem. If the employee asks, ‘What differs between these two installation procedures?’ an evidence-backed comparison could be more useful. If every answer must follow a specialized classification scheme that a well-designed prompt still handles inconsistently, model adaptation may deserve investigation.

These are hypothetical examples. They illustrate three different jobs: locating information, composing from information, and improving a repeated behavior. A team can spend heavily on fine-tuning while its actual problem is stale documents. It can also build elaborate retrieval when a single maintained reference would fit comfortably into the request.

Search can deliver the complete answer

Keyword search is useful when names, identifiers, and exact terminology matter. Semantic search can retrieve related meaning even when the wording differs. Hybrid search combines these approaches. OpenSearch's documentation describes combining keyword and semantic results through a search pipeline, including score normalization or rank-based combination. The right weighting depends on the queries and documents you actually have.

A good search interface also needs filters, useful excerpts, and a clear way to open the original record. In a hypothetical parts catalog, a semantically similar item with the wrong compatibility could be worse than no match. Treat mandatory constraints as explicit product rules; do not expect a relevance score to establish eligibility.

Build a query set from real questions and specify which sources should appear. Inspect failures by category: the information was absent, ingestion missed it, filters removed it incorrectly, or ranking buried it. Those diagnoses lead to more useful changes than repeatedly replacing the language model.

RAG adds a generation step to retrieval

Retrieval-augmented generation usually retrieves relevant passages or records, provides them to a language model alongside the request, and asks it to produce an answer. The retrieval step can use keyword search, semantic search, structured queries, or a combination. OpenAI's retrieval documentation explains semantic search over indexed information and filtering by file attributes; those are building blocks, not a complete business application.

For a hypothetical procedure assistant, the application might retrieve the current approved guide, include its version and effective date, and ask for a short explanation with source references. The interface should let the employee inspect the cited material. If the guide does not address the question, the useful response may be to identify the gap and ask a clarifying question.

Grounding reduces dependence on remembered information, but a supplied source does not make every generated sentence correct. Check whether the cited passage supports the claim, whether important exceptions survived summarization, and whether competing versions were resolved correctly. Evaluate retrieval and answer composition separately so you can tell which part failed.

Fine-tuning needs a demonstrated behavioral problem

Supervised fine-tuning trains a model on examples of desired inputs and outputs. OpenAI's guidance describes uses such as improving instruction following, formatting, and task-specific behavior. It also emphasizes establishing evaluations before investing in training. A collection of documents is not automatically a useful training dataset; examples need to demonstrate the behavior you want.

Consider a hypothetical organization with an unusual support taxonomy. After testing prompts and examples, it might still see consistent classification errors. A curated training set and a separate evaluation set could establish whether fine-tuning improves those decisions. Keep duplicates and near-duplicates from leaking across the split, or the results may exaggerate performance on unfamiliar work.

Changing prices, access permissions, and live availability still require an authoritative source at request time. A fine-tuned model can work alongside retrieval, but training should not become your mechanism for distributing every operational update. OpenAI's accuracy guidance treats context and behavior as different dimensions to diagnose.

Grounding includes permissions and freshness

Decide which records a person may retrieve before sending them to the model. Apply access checks in application services, and carry the same scope through search indexes, citations, downloads, and caches. A document being relevant does not authorize its disclosure. Test with users who have different roles and with records whose access changes after indexing.

Define how edits, deletions, and superseded versions reach the retrieval system. Store stable source identifiers so a citation can lead back to the right document. Plan what the interface shows while an update is still being indexed. The acceptable delay for an internal handbook may differ from the acceptable delay for current inventory.

Use an architecture that keeps responsibilities clear

LAYIQ provides a concrete example of this separation. PostgreSQL holds canonical product records. OpenSearch supports filtered retrieval. LightGBM models rank opportunities using preference signals, while Fit Analysis separately checks generated output against candidate and role evidence. LightGBM is a recommendation model in this system, distinct from language-model fine-tuning.

For your application, write down the question each component answers. Which records are valid? Which are relevant? What explanation is supported? What action is allowed? Then test those responsibilities independently and together. Choose the next engineering change from the observed failure: missing evidence, weak retrieval, inconsistent behavior, or an unclear workflow. That produces a defensible architecture and a more informative prototype.