RAG vs. Fine-Tuning vs. Prompt Engineering

One of the most important decisions when building a generative AI application is figuring out how to give a model what it needs to produce a useful response.

Sometimes the model already knows enough and simply needs better instructions. Sometimes it needs access to information that was not part of its original training. Sometimes the goal is to change the model's behavior itself.

Those situations can sound similar, especially when a scenario simply says that an organization wants to "customize" or "improve" a foundation model. But prompt engineering, Retrieval-Augmented Generation (RAG), and fine-tuning solve different problems.

Understanding that difference is one of the most useful skills you can develop for the AWS Certified AI Practitioner exam.

---

The Three Approaches at a Glance

Before getting into the details, start with the fundamental distinction:

Prompt engineering gives the model better instructions.

RAG gives the model relevant information at the time it generates an answer.

Fine-tuning uses additional training to change or specialize the model's behavior.

That sounds simple, but real-world scenarios can make the differences less obvious.

A useful mental model is:

Prompt engineering changes the instructions.

RAG changes the information available to the model.

Fine-tuning changes the model itself.

That last statement is intentionally simplified. Fine-tuning doesn't replace the foundation model or magically rewrite everything it knows. It uses additional training to adjust the model's learned parameters so that it behaves differently for a particular purpose.

This distinction becomes extremely valuable when working through AIF-C01 questions.

---

Prompt Engineering: Start With Better Instructions

The simplest way to influence a foundation model is to improve the prompt.

A prompt is the input provided to a model, including instructions and any relevant context supplied as part of the request.

Consider a simple request:

"Summarize this document."

The model may produce a perfectly reasonable summary.

But suppose you need something more specific:

"Summarize this document in five bullet points. Focus only on security risks. Assume the audience is a system administrator. Do not include recommendations."

The second prompt provides much more direction.

That's prompt engineering.

Prompt engineering is the process of designing and refining prompts to guide a model toward a desired output.

It does not require retraining the model.

It does not necessarily require changing the model.

It simply improves the way the application communicates with the model.

---

What Prompt Engineering Can Do

A well-designed prompt can help establish:

• The task the model should perform
• The desired format
• The audience
• The tone
• Constraints
• Instructions
• Examples of desired behavior
• Relevant context
• The role the model should play

For example:

"You are assisting a network administrator. Explain the following firewall rule in plain language. Keep the response under 100 words and identify any security concerns."

The model hasn't been retrained to become a network security expert.

You've simply provided clearer instructions about what you want it to do.

---

Zero-Shot and Few-Shot Prompting

Prompt engineering can range from a simple instruction to providing examples of the desired behavior.

Zero-shot prompting

A zero-shot prompt asks the model to perform a task without providing examples.

"Classify this email as either spam or legitimate."

No examples are provided.

Few-shot prompting

A few-shot prompt includes examples to demonstrate what the desired output should look like.

For example:

Email: "You've won a free vacation!"
Classification: Spam

Email: "Your monthly statement is ready."
Classification: Legitimate

Email: "Your account has been selected for a prize..."
Classification:

The examples help establish the expected pattern.

The model is still not being retrained. The examples are simply part of the prompt and therefore part of the information the model considers during the current interaction.

For AIF-C01, this distinction matters because a scenario that says an organization wants to improve a model's responses by providing better instructions or examples in the prompt is pointing toward prompt engineering, not fine-tuning.

---

When Prompt Engineering Is the Right Choice

Prompt engineering is often the first approach to consider when the model already has the capabilities and knowledge required to perform the task.

For example, suppose a company wants its chatbot to respond in a more professional tone.

It might not need a new model.

It might simply need better instructions:

"Respond in a professional but friendly tone. Keep responses concise and avoid technical jargon."

Likewise, if a model already knows how to summarize text but the organization wants summaries formatted as a table, prompt engineering may be enough.

This is one of the most important questions to ask:

Does the model already know how to do what I need, but I need to tell it more clearly how I want it done?

If the answer is yes, prompt engineering may be the simplest solution.

---

Retrieval-Augmented Generation: Give the Model Relevant Information

Prompt engineering has an important limitation.

A better prompt doesn't automatically give the model information it doesn't have.

Suppose a company has an internal employee handbook that was created after the model's training data was collected.

You could write an extremely detailed prompt asking:

"What does our employee handbook say about parental leave?"

But better wording won't give the model access to the handbook.

This is where Retrieval-Augmented Generation, commonly called RAG, becomes useful.

RAG combines information retrieval with generative AI.

Instead of expecting the model to already know the answer, the application retrieves relevant information and supplies it to the model as context.

A simplified RAG workflow looks like this:

User question

↓

Search for relevant information

↓

Retrieve relevant content

↓

Provide retrieved content to the model

↓

Generate an answer

The model can then use that information when producing its response.

---

Why RAG Is Useful

RAG is particularly useful when an application needs to work with information that is:

• Private
• Organization-specific
• Frequently updated
• Too specialized to expect the model to know
• Stored in documents or other external sources
• Not part of the model's original training data

Consider a company with thousands of internal technical documents.

The company doesn't necessarily want to retrain a foundation model every time a document changes.

Instead, it can make those documents available to a retrieval system.

When an employee asks:

"What is our procedure for rotating production credentials?"

the application can retrieve the relevant documentation and provide it to the foundation model as context.

The model then generates a response using that retrieved information.

---

RAG Does Not Retrain the Model

This is one of the most important distinctions in this entire topic.

When information is retrieved and supplied to a model as context, the model's underlying parameters have not necessarily changed.

The model is not learning the company's documentation through that interaction.

The information is being provided to the model at inference time.

This makes RAG particularly useful for information that changes frequently.

Imagine a company updates its employee handbook every month.

With RAG, the retrieval source can be updated as the handbook changes. The application can retrieve the latest relevant information without requiring the foundation model itself to be retrained every time the document changes.

This is exactly the kind of distinction an AIF-C01 scenario may test.

If the question emphasizes frequently changing information, proprietary documents, internal knowledge, or grounding responses in external sources, RAG should immediately come to mind.

---

Embeddings and Vector Search

RAG often involves another important concept: embeddings.

An embedding is a numerical representation of data that captures aspects of its meaning or relationships.

For example, the concepts:

"How do I reset my password?"

and

"I can't remember my login credentials."

use different words but have similar meanings.

An embedding system can represent those pieces of text in a way that allows a retrieval system to identify their semantic similarity.

A typical RAG system may therefore involve:

Documents

↓

Chunking

↓

Embeddings

↓

Vector store

↓

Similarity search

↓

Relevant content

↓

Foundation model

This allows the system to find information based on meaning rather than relying only on exact keyword matches.

You don't need to become a vector database expert for AIF-C01. What matters is understanding the role embeddings can play in a RAG architecture.

If a question describes converting content into numerical representations so that semantically similar information can be retrieved, embeddings are likely part of the answer.

---

RAG and Amazon Bedrock

RAG is especially relevant to AWS because Amazon Bedrock provides capabilities for building generative AI applications that work with external information.

Amazon Bedrock Knowledge Bases can help implement RAG by connecting foundation models with data sources so that relevant information can be retrieved and used to generate responses.

That gives you an important relationship to remember:

Knowledge Base → retrieve relevant information → provide context → foundation model generates response

If an AIF-C01 question describes a company wanting a generative AI application to answer questions using its internal documents, Amazon Bedrock Knowledge Bases may be relevant.

The key isn't simply recognizing the service name. Understand why the service is being used.

The requirement is to ground the model's response in external information.

---

Fine-Tuning: Change the Model's Behavior

Fine-tuning is different from both prompt engineering and RAG.

With fine-tuning, additional training data is used to further train an existing model for a particular purpose.

The goal is generally to specialize or modify the model's behavior.

For example, imagine an organization wants a model to consistently perform a specialized classification task using a particular style of output.

Instead of providing increasingly complicated instructions with every request, the organization might use fine-tuning to adapt the model to that task.

The model is still based on an existing foundation model, but additional training changes its learned parameters.

That is the key distinction:

Prompt engineering provides instructions. RAG provides information. Fine-tuning provides additional training.

---

What Fine-Tuning Is Good For

Fine-tuning can be useful when an organization needs a model to consistently behave in a particular way.

Potential use cases include:

• Specialized task behavior
• Consistent output formats
• Domain-specific terminology
• Specialized classification
• Particular response styles
• Adapting a model to a specialized dataset
• Improving performance for a particular task

The important thing is that fine-tuning is about changing model behavior through additional training, not simply giving the model information for one request.

---

Fine-Tuning Does Not Mean "Give the Model a Document"

This is another common misconception.

Suppose a company has a 500-page technical manual.

If the requirement is:

"We want the AI to answer questions using the latest version of this manual."

RAG is likely a better fit.

The organization can retrieve the relevant sections of the manual when users ask questions.

Now change the requirement:

"We want the model to consistently perform a specialized task using our organization's terminology and examples."

Now fine-tuning may be appropriate.

The difference is subtle but important:

RAG is primarily about providing relevant information.

Fine-tuning is primarily about adapting model behavior.

---

Keeping Information Current

This is one of the easiest ways to distinguish RAG from fine-tuning.

Imagine the information changes every week.

For example:

• Product catalogs
• Internal policies
• Pricing
• Inventory
• Employee documentation
• Technical documentation
• Current procedures

You generally don't want to repeatedly retrain a model just because the underlying information changed.

RAG can retrieve the current information when the application needs it.

This leads to a useful exam clue:

Frequently changing external information → think RAG.

On the other hand, if the organization wants to change the model's behavior so that it consistently performs a specialized task, the scenario may be pointing toward fine-tuning.

---

Prompt Engineering vs. RAG vs. Fine-Tuning

At this point, the differences can be summarized fairly simply.

Another way to think about it:

Prompt engineering

"Do this."

RAG

"Here is information you need."

Fine-tuning

"Learn to do this differently."

That distinction is simple enough to remember, but the real skill is recognizing which one a scenario is describing.

---

A Practical Example

Imagine a company has built an AI assistant for its IT department.

The assistant uses a foundation model.

The company wants to make three improvements.

Requirement 1

The assistant's responses are too long.

The company wants concise responses with three bullet points and no unnecessary explanation.

Prompt engineering

The model already knows how to answer the questions. The company simply needs to provide better instructions.

---

Requirement 2

The assistant needs to answer questions using the company's latest internal troubleshooting documentation.

RAG

The problem is access to current, private information.

The application can retrieve the relevant documentation and provide it to the model as context.

---

Requirement 3

The company wants the assistant to consistently perform a specialized classification task using its own terminology and examples.

Fine-tuning

The goal is to adapt the model's behavior for a specialized task through additional training.

---

The Same Application Can Use All Three

It's important not to think of these approaches as mutually exclusive.

A sophisticated generative AI application may use all three.

For example:

Prompt engineering

tells the model how to respond.

↓

RAG

provides the relevant company information.

↓

Fine-tuned model

provides specialized behavior.

↓

Foundation model

generates the final response.

This is why a question asking whether an organization should use "prompt engineering, RAG, or fine-tuning" cannot always be answered simply by identifying one technology in isolation.

The question is really asking:

What problem are they trying to solve?

---

Common Confusions

"The model needs new information."

Ask whether that information needs to become part of the model itself.

If the model simply needs access to external information during a request, RAG is likely the better fit.

If the organization wants the model to learn a new specialized behavior through additional training, fine-tuning may be appropriate.

---

"The model keeps giving the wrong format."

That doesn't automatically mean the model needs to be fine-tuned.

If the model already understands the task but isn't following the desired instructions consistently, improving the prompt may be the simplest first step.

Better instructions → prompt engineering.

---

"We need to use our private company documents."

Private information does not automatically mean fine-tuning.

If the application needs to retrieve information from those documents and use it when answering questions, RAG is a natural fit.

---

"We need the model to know our company's information."

Be careful with wording like this.

A scenario may use the word "know" loosely.

Ask what the organization actually needs.

If it needs the model to retrieve current information from company documents, think RAG.

If it needs to change the model's behavior through additional training, think fine-tuning.

The word "know" by itself doesn't tell you which approach is appropriate.

---

RAG vs. Fine-Tuning: The Information Question

One of the most useful distinctions is asking where the information lives.

With RAG:

The information remains in an external knowledge source and is retrieved when needed.

With fine-tuning:

Training data is used during additional training to adapt the model's learned parameters.

That means RAG is particularly attractive when the information changes frequently.

Fine-tuning can be attractive when the desired change is more about how the model behaves than about giving it access to a constantly changing collection of facts.

This distinction can help eliminate answers quickly on AIF-C01 questions.

---

RAG vs. Prompt Engineering: The Context Question

These two can also overlap.

A prompt can contain information.

For example:

"Using the following document, summarize the security requirements..."

That is still using information supplied as part of the prompt.

RAG adds a retrieval mechanism that finds relevant information from an external source rather than requiring the user or application to manually place all of the information into the prompt.

So the important distinction isn't simply:

"Does the prompt contain information?"

The better question is:

"How does the application obtain the information it needs?"

If relevant information is automatically retrieved from an external knowledge source, you're looking at a RAG architecture.

---

Why Not Just Fine-Tune Everything?

Fine-tuning can sound attractive because it seems like the most direct way to teach a model what an organization needs.

But it isn't automatically the best solution.

Additional training can require:

• Curated training data
• Computational resources
• Time
• Testing
• Evaluation
• Maintenance
• Ongoing updates when the underlying data changes

If the only problem is that the model needs access to information that changes regularly, repeatedly fine-tuning the model may be unnecessary.

RAG can separate the knowledge source from the model.

That can make the overall system easier to update as information changes.

For AIF-C01, this is an important reasoning pattern: don't choose the most complicated solution simply because it sounds more powerful. Look for the approach that directly addresses the requirement.

---

Choosing the Right Approach

When faced with a scenario, ask these questions in order.

1. Does the model already have the capability?

If yes, start by considering prompt engineering.

2. Does the model need access to external or changing information?

Consider RAG.

3. Does the organization need to change or specialize the model's behavior through additional training?

Consider fine-tuning.

This isn't a rigid decision tree. Real systems can combine approaches, and there are situations where multiple solutions could technically work.

But for an AIF-C01 scenario, identifying the primary requirement is often the fastest way to narrow the choices.

---

The AIF-C01 Scenario Pattern

AIF-C01 questions may not simply ask:

"What is RAG?"

Instead, you might get a scenario describing an organization, its data, its application, and the problem it is trying to solve.

The terminology may barely be mentioned.

That means you should learn to recognize the clues.

Look for these clues:

"Frequently changing information"

Think RAG.

"Internal company documents"

Think RAG, particularly if the application needs to retrieve information from them.

"Ground responses in proprietary information"

Think RAG.

"Improve instructions"

Think prompt engineering.

"Provide examples in the prompt"

Think few-shot prompting.

"Change the model's behavior"

Consider fine-tuning.

"Specialized task or terminology"

Consider fine-tuning.

"Additional training data"

Think fine-tuning.

"No model retraining required"

Think prompt engineering or RAG, depending on what the scenario needs.

These clues are more useful than memorizing three definitions because they help you recognize the answer when the question is written as a business scenario.

---

A Final Comparison

The table is useful for review, but don't let it replace the underlying concepts.

The most important distinction is:

Prompt engineering tells the model what you want.

RAG gives the model information it needs.

Fine-tuning changes how the model behaves.

---

The Mental Model to Keep

When you're deciding between these approaches, don't start by asking which technology sounds most advanced.

Start with the problem.

"The model understands the task, but I need to give it better instructions."

→ Prompt engineering

"The model needs information that exists somewhere outside the model."

→ RAG

"The model needs to learn a specialized behavior through additional training."

→ Fine-tuning

Once you understand that distinction, many seemingly complicated generative AI scenarios become much easier to reason through.

For the AWS Certified AI Practitioner exam, this is especially important because the correct answer is often hidden inside the business requirement rather than the terminology. Read the scenario carefully, identify what the organization is actually trying to accomplish, and then choose the approach that addresses that specific problem.