Buyer's Guide
RAG or Fine-Tuning: Change the Information Path or the Model Behavior?
Buy the change that addresses the demonstrated failure. Retrieval-augmented generation supplies selected external information in the inference context. Supervised fine-tuning adjusts model parameters using labeled examples. Either can affect task quality, and they can be combined. Separate evidence that the assistant receives the applicable information from evidence that it follows the required response convention; neither mechanism guarantees correct or authorized answers.
Follow external information into the inference request
Amazon Bedrock's unstructured-data example, checked on October 20, 2026, provides a concrete RAG path. Documents become text chunks. An embedding model represents those chunks numerically, and the representations enter a vector index with a mapping to the original documents.
At query time, the question is also represented as a vector. The index selects semantically similar chunks, and their text joins the question in the context sent to the answer-generating model. The model therefore receives information selected for that request. This is one documented retrieval arrangement, rather than a definition requiring every RAG system to use vector similarity.
Adding retrieved context does not itself retrain the answer-generating model. An embedding used to locate a passage is also different from that model learning the passage through training. The purchasing question is which source material reaches each request and whether it is useful for the task.
References: [DEW-RAG-01]
Follow labeled examples into changed parameters
Here fine-tuning means supervised adaptation of the answer-generating model. Bedrock describes training on labeled examples that associate inputs with desired outputs, adjusting model parameters in the process. That changes the model used for subsequent inference.
Training preparation consequently requires examples of the desired task, rather than simply a folder of reference documents. Bedrock's preparation guide distinguishes input prompts and expected completions and requires data appropriate to the selected model and customization method. The buyer needs to know what behavior the examples reward and which information they contain.
The distinction is broader than facts versus style. Training examples can contain factual answers and teach task decisions. Retrieved material can include instructions or examples that influence a response. Both paths can affect quality. Their different update mechanisms remain decisive: replacing a reference document is not a parameter update, and completing a training run does not create a current-source retrieval path.
References: [DEW-RAG-02][AWS-TRAIN-DATA]
Separate source availability from successful use
Bedrock's ingestion documentation separates raw data from the parsed, chunked and indexed representation used for retrieval. It says changes to connected sources must be ingested through synchronization, while qualifying that supported direct-ingestion routes can combine some of those steps. A document being present in storage alone does not establish its availability to a retrieval query.
Even a completed ingestion does not establish that a particular question selected the applicable passage. Bedrock separately exposes retrieval and combined retrieval-with-generation, making the distinction visible: returned source material and the resulting answer are different outputs.
For a buyer's evaluation, follow the applicable source revision through availability, selection and answer use. A passage can be indexed but missed. A selected passage can be irrelevant to the case. An applicable passage can reach the generator while the answer still misstates it.
Source references make those checks easier. A citation identifies material to inspect; it does not by itself prove that the source is current, its rule applies, or the answer follows it. Authorization for the requester remains a separate application requirement under either mechanism.
References: [AWS-INGEST][AWS-RETRIEVE]
Compare three candidates after an invented policy changes
Consider a fictional supplier, Northbank Components. Its invented ordinary return window changes from 20 days after receipt in revision R1 to 30 days after receipt in revision R2. R2 is stipulated to apply to every current-policy question in this example. Separately, the assistant should give a concise explanation and an escalation category. For the invented evaluation, ordinary in-window cases use Standard return; cases beyond the window use Policy review without promising an exception. These names, rules and categories are illustrative.
Give all three candidates the same task prompt requesting that response convention. Candidate A uses the unchanged base model and a retrieval corpus updated to R2, with no supervised adaptation. Its changed component is the external information path. A may follow the convention through the prompt; absence of fine-tuning does not establish a behavior failure. Its updated corpus still needs evidence of successful R2 retrieval and answer use.
Candidate B uses parameters adapted from examples containing the R1 policy and the desired convention. It has no current-source path and receives no R2 text in this comparison. B's changed component is the trained model. Its training history does not establish knowledge of the revision. It need not invariably answer 20 days, but a plausible 30-day answer alone would not demonstrate a reliable way to receive policy updates.
Candidate C combines the R2 retrieval corpus with a model adapted from supervised examples intended to teach the convention and use of supplied source material. Its examples include the policy context to be followed, rather than silently treating an old numerical answer as permanently applicable. This is a proposed candidate, with no stipulated success. The retrieval path and learned behavior can each fail, and their interaction needs evaluation.
The example exposes different purchases. A supplies a revised information path. B supplies an adapted model based on an older information set. C includes both changes and their integration. Their labels provide no result for the buyer's task.
Score current-policy fidelity separately from the convention
Use an original test question that distinguishes the revisions: an ordinary return requested 25 days after receipt. Under the stipulated R2 rule, the reference answer treats it as inside the 30-day window. A concise 20-day refusal could satisfy the presentation convention while failing policy fidelity. A correct 30-day explanation that omits the escalation category could pass the policy check while failing the convention.
For A and C, inspect whether the retrieved material includes the applicable R2 passage before assessing the generated answer. Then judge whether the answer uses that rule for the stated case. Include questions beyond 30 days and differently worded in-window requests, with agreed reference answers, so repeating one number cannot pass the whole comparison.
Assess the convention against its own rubric: concise explanation, appropriate category and no invented exception promise. For a separate check of adaptation, give the base and adapted models the same applicable policy context and task prompt on previously unseen questions. That controlled comparison helps distinguish behavior changes from differences in supplied information. Retain the complete end-to-end comparison as well.
Bedrock's evaluation documentation similarly distinguishes retrieval relevance and coverage from generated-answer correctness, faithfulness and citation measures. Those are separate dimensions, not interchangeable guarantees. The fictional rubric makes the enterprise requirement explicit instead of treating a single aggregate score as acceptance.
A combined candidate is justified when evidence shows that the combination meets the requirement. If the base model already follows the convention with reliable current context, fine-tuning needs another demonstrated benefit. If adaptation improves the convention but policy fidelity remains poor, that is an unresolved information or source-use problem.
References: [AWS-EVALUATION]
Compare the work retained by each arrangement
The documented retrieval path needs document preparation, embedding, an index, retrieval and generation. A source revision can create new ingestion and verification work even when the generator's parameters stay unchanged. Retrieved passages also add input for the generator to process. Evaluate the intended context and request load when comparing response time and resource use.
Supervised adaptation introduces training-data preparation, a training job, model artifacts and evaluation of the resulting model. A later revision requires an explicit decision about source updates, revised training examples or both. Placing a new policy document in storage does not automatically execute any of those changes.
Adapted parameters still need serving. Bedrock's custom-model inference guide treats setting up inference as work after custom-model creation. Its documented provisioned and on-demand routes illustrate that training completion and serving provision are distinct; the guide does not establish which route fits a particular model or buyer.
Compare the complete proposed operating arrangement: initial preparation, recurring source or training updates, evaluation, retrieval where used, and ongoing inference. Ask which components the software provider supplies and which an existing platform team operates. No universal GPU count, latency reduction or price follows from either label. A combined system retains both information and model-change responsibilities, even where one provider supplies them together.
References: [AWS-SERVING][AWS-INGEST][AWS-TRAIN-DATA]
Purchase the change supported by the failure evidence
When the model answers correctly with the applicable passage supplied, but the application fails to find that passage, prioritize the retrieval and source-update path. When the applicable context is already present and the base model repeatedly misses the required task behavior, compare prompting and supervised adaptation using the same context. When both problems occur, define and evaluate both changes.
Ask the software provider to identify the source revision available for inference, the model and training-data revisions, the task prompt, and the evidence for each required outcome. Include the next policy change in that discussion: who updates which component, what is reevaluated and how the team establishes that the revision reached the answer.
The related cache guide addresses reuse of prompt computation or prior answers, a separate purchase from supplying source passages or changing parameters. The memory and serving-layout guides address the selected model's execution requirements. Those decisions become meaningful once the application team has defined which change it needs.
Bring a separate equipment-installation need to the physical service
If the selected software arrangement also requires equipment receiving, rack integration, onsite installation or IT cabling, Leviathan's Complete Physical Deployment service provides a route to discuss that physical package. Bring a nonconfidential equipment list, locations, required connections and the team receiving the handoff to the linked project inquiry.
The service can combine agreed physical stages and records, with hardware QA where scoped and resourced. RAG design, training, application integration and managed inference remain with separately appointed software providers. The related service owns the physical installation inquiry; choosing either model mechanism does not itself establish a need for new equipment.
References: [L1]
Primary sources
- [DEW-RAG-01] Amazon Bedrock — How Amazon Bedrock knowledge bases workChecked 2026-10-20. Unstructured-document preprocessing and runtime query flow illustrate chunk, embedding, index and context roles. Other RAG architectures can use different retrieval methods.
- [DEW-RAG-02] Amazon Bedrock — Customize your model to improve its performance for your use caseChecked 2026-10-20. Supervised fine-tuning uses labeled examples and adjusts parameters. The mechanism establishes no task-specific improvement for a proposed buyer configuration.
- [AWS-TRAIN-DATA] Amazon Bedrock — Prepare data for fine-tuning your modelsChecked 2026-10-20. Training-data preparation and input/expected-output roles. Dataset formats and validation support depend on the selected model and method; no settings or quotas are adopted.
- [AWS-INGEST] Amazon Bedrock — Turning data into a knowledge baseChecked 2026-10-20. Unstructured-data ingestion, source synchronization and qualified direct-ingestion alternatives. Source modification alone establishes no retrieval or freshness outcome.
- [AWS-RETRIEVE] Amazon Bedrock — Retrieving information from data sources using Amazon Bedrock Knowledge BasesChecked 2026-10-20. Separate source retrieval and retrieval-with-generation, including source-chunk citations. Returned references remain evidence to inspect rather than proof of correctness.
- [AWS-EVALUATION] Amazon Bedrock — Use metrics to understand RAG system performanceChecked 2026-10-20. Retrieval relevance and coverage, answer correctness and faithfulness, and citation measures are distinct dimensions. A task-specific acceptance rubric remains necessary.
- [AWS-SERVING] Amazon Bedrock — Set up inference for a custom modelChecked 2026-10-20. Inference setup follows custom-model creation. The documented serving routes are platform examples, not a model-support, capacity or pricing recommendation.
- [L1] Leviathan Systems — Complete Physical Infrastructure DeploymentChecked 2026-10-20. Defined physical receiving, integration, installation, IT cabling and handoff scope. Included QA and resources are agreed for the engagement.