Split View: RAG vs Fine-tuning vs Prompt Engineering: 언제 무엇을 선택하는가

RAG vs Fine-tuning vs Prompt Engineering: The Complete Decision Framework

• The Question Every AI Product Team Asks
• What Are These Three Approaches?
• Comparison Table
• Decision Framework
  • Practical Notes on Each Branch
• Three Real-World Case Studies
  • 1. Customer Support Chatbot → RAG
  • 2. Medical Record Summarization → Fine-tuning
  • 3. Code Review Assistant → Prompt Engineering + Few-shot
• Real Cost Comparison
• Combining All Three
• Code: Simple Decision Helper
• Common Mistakes
• Conclusion: The Incremental Approach

The Question Every AI Product Team Asks

"We want to add AI to our product — which approach should we use?"

I've heard this question hundreds of times. From startup CTOs, enterprise dev leads, solo developers building side projects — everyone hits this same decision point. And most of them jump too fast to either "let's fine-tune a model" or "we need to build a full RAG pipeline."

Here's the honest answer: Start with Prompt Engineering. Add RAG when you need private/up-to-date knowledge. Fine-tune only as a last resort. Fine-tuning is needed far less often than people think.

This post gives you the real framework for making this decision — with actual cost numbers and production war stories.

What Are These Three Approaches?

Let's be precise about the definitions.

Prompt Engineering optimizes the input you give to an LLM. This includes writing effective system prompts, adding few-shot examples, and structuring Chain-of-Thought reasoning. The model's weights are never modified.

RAG (Retrieval-Augmented Generation) retrieves relevant documents from an external knowledge base and feeds them as context to the LLM. It gives the model access to knowledge it wasn't trained on — in real time.

Fine-tuning continues training a pre-trained LLM on domain-specific data. The model weights are directly modified, baking new knowledge and behavior into the model itself.

Comparison Table

The two most important columns are Knowledge updates and Hallucination risk. RAG has lower hallucination risk than fine-tuning because you can instruct the model to cite retrieved documents rather than generate from memory.

Decision Framework

Q1: Do you need current information or private/internal documents?
    YES → Consider RAG
    NO  → Next question

Q2: Do you need a specific output style, format, or domain-specific language?
    YES → Consider Fine-tuning
    NO  → Start with Prompt Engineering

Q3: You tried RAG but retrieval quality is consistently poor?
         (e.g., model can't understand domain-specific terminology)
    YES → RAG + Fine-tuning combination
    NO  → RAG alone is sufficient

Q4: Prompt Engineering output is inconsistent?
    YES → Add more few-shot examples, or consider Fine-tuning
    NO  → Stick with current approach

Practical Notes on Each Branch

"Internal documents" in Q1 means FAQs, product manuals, Confluence pages, Notion wikis, Slack archives — anything the base LLM wasn't trained on. RAG is required for this.

"Domain-specific language" in Q2 means medical abbreviation systems, specific legal document formats, your company's internal coding conventions. Normal technical writing and summarization usually work fine without fine-tuning.

Three Real-World Case Studies

1. Customer Support Chatbot → RAG

You're building AI-powered customer support for a B2B SaaS product. You have hundreds of FAQ documents, release notes, and user guides.

RAG is the right choice here. Reasons:

• Documents update frequently (every new feature release)
• You need accurate, product-specific information (hallucinations are unacceptable)
• The model doesn't need to learn a new writing style

If you chose fine-tuning instead, you'd need to retrain every time the docs update — a cost and time disaster.

2. Medical Record Summarization → Fine-tuning

You're building an automatic summarization system for EMR (Electronic Medical Records) in a hospital.

Fine-tuning is genuinely needed here. Reasons:

• Must correctly interpret medical abbreviations like Hx of HTN, DM2, CKD3
• Must follow the SOAP note format precisely (Subjective-Objective-Assessment-Plan)
• A general LLM will miss subtle differences in medical terminology

That said, this is often paired with RAG too — medical guideline documents as the retrieval base, with a fine-tuned model doing the generation.

3. Code Review Assistant → Prompt Engineering + Few-shot

You want an AI assistant to help with your team's code reviews.

Prompt Engineering with few-shot examples is sufficient. Reasons:

• LLMs already understand code very well
• 3-5 review examples in the prompt quickly teach your team's style
• There's no need for expensive fine-tuning or a complex RAG infrastructure

SYSTEM_PROMPT = """You are a senior engineer doing code review.
Review style: direct, constructive, with specific line references.

Example reviews:
---
[EXAMPLE 1]
Code: for i in range(len(items)): process(items[i])
Review: Use enumerate() instead — cleaner and more Pythonic:
  for i, item in enumerate(items): process(item)
---
[EXAMPLE 2]
Code: try: result = api_call() except: pass
Review: Never use bare except. Catch specific exceptions and log them:
  try: result = api_call()
  except RequestException as e: logger.error(f"API call failed: {e}"); raise
---
Now review the following code:"""

Real Cost Comparison

Let's assume a service handling 10,000 queries per day. Using GPT-4o pricing as a baseline:

Prompt Engineering only

• Average 1,000 tokens per query (800 input + 200 output)
• 3M queries/month × $0.005/1K tokens ≈ **~$150/month**
• Additional infrastructure: nearly zero

Adding RAG

• Token increase: ~2,000 additional tokens per query for retrieved context
• Token cost: ~$450/month (3x increase)
• Vector DB (e.g., Pinecone): ~$70/month
• Total monthly cost: ~$520/month

Fine-tuning

• Training cost (GPT-4o fine-tuning): ~$25 one-time for 1M tokens of data
• Inference cost: fine-tuned models cost 20-50% more than base models
• Total monthly cost: ~$180-225/month + retraining costs

The takeaway: RAG significantly increases token costs, but if you need private documents, you have no choice. Fine-tuning looks cheap on inference cost alone, but factor in periodic retraining and labeling labor and it's actually much more expensive.

Combining All Three

For enterprise-grade AI products, all three approaches together can produce excellent results:

[System Prompt]               <- Prompt Engineering
"You are a professional support agent for ACME Corp.
 Always be polite and respond in the user's language."

[Retrieved Context]           <- RAG
"Relevant doc: [FAQ #127] Return policy allows 30 days from..."

[User Query]
"I'd like to return a product I ordered."

[Fine-tuned Model]            <- Fine-tuning
Domain terminology understanding + company tone internalized

Why this combination excels:

• System prompt: defines role and constraints
• RAG: provides current, accurate information
• Fine-tuning: domain vocabulary understanding + consistent style

Be warned though — this combination is complex to build and operate. It's over-engineering for an MVP stage.

Code: Simple Decision Helper

def choose_approach(
    has_private_docs: bool,
    needs_latest_info: bool,
    has_training_data: bool,
    budget: str  # 'low', 'medium', 'high'
) -> str:
    """
    Returns recommended approach based on project characteristics.

    Args:
        has_private_docs: Do you have internal/proprietary documents?
        needs_latest_info: Does the system need up-to-date information?
        has_training_data: Do you have labeled training examples?
        budget: Development + ops budget level

    Returns:
        Recommended approach string
    """
    if has_private_docs or needs_latest_info:
        if has_training_data and budget == 'high':
            return "RAG + Fine-tuning (hybrid approach)"
        return "RAG"

    if has_training_data and budget in ['medium', 'high']:
        return "Fine-tuning (but try Prompt Engineering first)"

    return "Prompt Engineering (start here, iterate fast)"


# Usage examples
print(choose_approach(
    has_private_docs=True,
    needs_latest_info=True,
    has_training_data=False,
    budget='medium'
))
# Output: "RAG"

print(choose_approach(
    has_private_docs=False,
    needs_latest_info=False,
    has_training_data=True,
    budget='high'
))
# Output: "Fine-tuning (but try Prompt Engineering first)"

Common Mistakes

Mistake 1: Treating fine-tuning as the first option Fine-tuning is a last resort. A well-crafted system prompt for GPT-4o will get you most of the fine-tuning benefits without the complexity and cost.

Mistake 2: Thinking RAG is a silver bullet RAG is entirely dependent on retrieval quality. If your search doesn't return relevant documents, the best LLM in the world can't save you. Chunking strategy and embedding quality are critical — more on this in a follow-up post.

Mistake 3: Shipping without evaluation Whatever approach you choose, deploying based on "vibes" without quantitative evaluation is a mistake. Use tools like RAGAS to measure and iterate.

Conclusion: The Incremental Approach

1. Start with Prompt Engineering → Ship a first version in a day
2. Add RAG when you need internal documents → Buildable in a few days
3. Consider Fine-tuning only when domain specialization is truly necessary → Invest weeks only when justified

Don't fall into the trap of trying to build the perfect system from scratch. Start with Prompt Engineering, gather real user feedback, and incrementally increase complexity. That's the fastest path in practice.