AI for Tech Certification
Proficient · M23 · lesson 23 of 30 · queued
Preview — browse every lesson free. Enroll to mark lessons complete, open partner links and save your progress. Login & enroll →
RAG, Fine-Tuning, and Custom Models: The Decision Tree
📖
now learning

RAG, Fine-Tuning, and Custom Models: The Decision Tree

15 min

The Knowledge Integration Decision: Which Approach Pays Off?

You need AI to understand your domain. Your knowledge is proprietary: internal systems, business rules, customer contexts, pricing structures. Claude doesn't know any of this. Neither does GPT. No public model does.

Three paths exist: feed it knowledge at inference time (RAG), train it on examples (fine-tuning), or build your own model from scratch (custom). Each has dramatically different costs, implementation timelines, maintenance burden, and ROI.

The decision determines whether you spend $10k and get results in 4 weeks, or spend $5M and wait 18 months. It's a CTO decision with real capital implications.

The Cost and Timeline Framework

RAG: $10-80k total cost, 2-6 week implementation, ongoing document maintenance. Knowledge freshness: real-time (update docs, model immediately has access). Effort to maintain: low (curator role, 0.25-0.5 FTE).

Fine-tuning: $50-500k total cost, 4-12 week implementation, requires periodic retraining. Knowledge freshness: quarterly or semi-annual (requires full retraining). Effort to maintain: medium (data collection, quality control, retraining pipeline).

Custom model: $1-10M+ total cost, 12-36 month implementation, massive ongoing operational burden. Knowledge freshness: expensive (retraining costs $100-500k). Effort to maintain: extremely high (team of ML engineers, compute infrastructure).

For 95% of companies, the answer is RAG, possibly adding fine-tuning. Custom models are only justified for companies where the model itself is the product (AI companies) or where you have petabytes of proprietary training data (not terabytes, petabytes).

Strategic Truth: Custom models cost $1-10M and take 12-36 months. Most companies that build them regret it. A Series C fintech spent $3M on a custom model and got a worse result than GPT-4 API plus $100k RAG setup. Don't confuse "wanting control" with "needing a custom model." Use RAG for fresh knowledge, fine-tuning for style, and save the $5M for something else.

Decision Dimension 1: Freshness Requirement

How often does your knowledge change?

Weekly: Product features launch weekly. Pricing changes weekly. Your knowledge base is constantly stale if not updated. RAG is perfect here. Update docs daily, model has fresh access within hours.

Monthly: Business rules change monthly. SLAs shift. Rarely, you retrain fine-tuned models. Fine-tuning becomes viable.

Annually or never: Your domain knowledge rarely changes. Tax code, legal precedent, physics. Train once, accuracy is stable. Fine-tuning becomes unnecessary (base model suffices).

This dimension alone determines 70% of your choice. Weekly changes → RAG. Monthly → Fine-tuning. Never → neither (don't add complexity).

RAG: For Knowledge That Changes Frequently

How It Works

Store your domain knowledge (documents, code, best practices, FAQs) in a vector database. When a user asks a question, retrieve the most relevant documents and include them in the prompt to Claude. Claude reads the documents and answers based on them. Knowledge is updated continuously without model retraining.

Cost Breakdown

Vector database setup (Pinecone, Weaviate, Postgres pgvector): $500-5k setup, $100-500/month. Engineering (API integration, retrieval tuning): 2-4 weeks (1 engineer). Ongoing maintenance (document curation, quality control): 0.25 FTE. Total first-year cost: $20-50k.

The Retrieval Problem

RAG's biggest weakness: retrieval accuracy. A question about "billing issues" might match docs about "financial statements" instead of "invoicing problems." These are related but wrong. The model gets bad documents and gives a bad answer. RAG quality is entirely determined by retrieval quality.

Retrieval Accuracy Thresholds

Simple use cases (FAQ matching): Vector similarity works. "How do I reset password?" matches "Password Reset" doc 95% of the time. Success.

Complex use cases (nuanced domain questions): Requires semantic understanding. "What's our revenue recognition policy for annual contracts?" needs to match complex revenue docs that might not mention "annual contracts" explicitly. Vector similarity alone is 60-70% accurate. Adding keyword filtering, document metadata, and multi-stage ranking improves to 85-95%.

Failure Case: Poor Document Organization

A company built RAG on 500 PDFs (product manuals, support tickets, internal memos). No structure. When a customer asked "How do I troubleshoot connectivity errors?", the system retrieved 5 documents, 3 of which were irrelevant internal notes. The retrieved context was confusing, model gave a mediocre answer. Adoption was poor. The fix: invest in document curation (label docs, organize by topic, remove outdated docs, add metadata). Cost: 200 hours. With better structure, retrieval improved to 90%+ and user satisfaction jumped from 40% to 82%.

When to Use RAG

Use RAG when: knowledge changes weekly or monthly, you have 50+ structured documents, retrieval can be made accurate (documents are well-organized and labeled), speed to market is critical (you need results in weeks).

Good use cases: customer support, documentation lookup, help desk, knowledge base Q&A, company-specific FAQs.

Fine-Tuning: For Style, Tone, and Specific Tasks

How It Works

You collect examples of your desired behavior (customer support responses, documentation, code, analysis). The model learns to replicate that style and reasoning. Fine-tuning teaches the model both what to do and how to do it in your voice.

Example: You provide 200 customer support responses (user question + best answer, written in your support team's voice). Fine-tune Claude. Result: a Claude variant that sounds like your team, uses your terminology, and handles your specific issues well.

Cost-Benefit Analysis

Data collection and labeling: 100-500 examples at 0.5 hours per example = 50-250 hours. Cost: $10-50k. Fine-tuning infrastructure: $100-500. Ongoing maintenance (collect new examples, retrain quarterly): 0.5-1 FTE. Total first-year cost: $60-150k. Year 2+: $30-60k annually.

When Fine-Tuning Pays For Itself

Support use case: You have 50K support tickets annually. Without fine-tuning, AI support quality is 70% (good enough for simple tickets, requires human review for complex ones). With fine-tuning, quality improves to 85% (fewer escalations to humans). 15% improvement × 50K tickets = 7,500 fewer human-hour reviews. At $30/hour, that's $225k saved. Fine-tuning cost: $80k. ROI: 2.8x payback in year 1.

Code generation use case: Your codebase has specific patterns (naming conventions, error handling, architecture). A fine-tuned model generates code that matches your style, reducing review time. 1 FTE code review time saved: $120k. Fine-tuning cost: $100k. ROI: 1.2x payback (breakeven).

Writing use case: You generate marketing copy, documentation, internal communications. A fine-tuned model writes in your brand voice. Reduces editing time. 0.5 FTE saved: $60k. Fine-tuning cost: $60k. ROI: 1x payback (breakeven).

Failure Case: Stale Fine-Tuned Model

A company fine-tuned a model on 300 support responses from 2023. It worked great. Then their product changed (new features, deprecated old features). The fine-tuned model kept recommending old features. New support team members were trained on AI responses that referenced deprecated features. The model had codified obsolete knowledge. Lesson: fine-tuning + RAG is more resilient. Use fine-tuning for style, RAG for current facts. When product changes weekly, pure fine-tuning is fragile.

Best Practice Pattern: Use RAG + fine-tuning together. RAG keeps knowledge current (update docs daily, model has access). Fine-tuning teaches style and patterns (train once, update quarterly). This combination beats either approach alone. RAG without fine-tuning gives generic answers. Fine-tuning without RAG gives well-styled obsolete answers. Together, you get current knowledge in your brand voice.

When to Use Fine-Tuning

Use when: style and tone matter, you're doing a specific task repeatedly (classification, support responses, documentation), you can collect 100+ quality examples, accuracy on your domain is critical, knowledge changes slowly (quarterly or annually, not weekly).

Good use cases: customer support with brand voice, code generation with your patterns, writing in your style, domain-specific classification tasks.

Custom Models: Only for Specific Edge Cases

How It Works

You train a model from scratch on your data using transformer architectures (or use open-source models like Llama and fine-tune them extensively). You control everything: training data, model size, architecture, training process.

Real Cost Analysis

Initial development: $1-5M (team of 5-10 ML engineers for 12-18 months, compute infrastructure, data engineering). Annual operating cost: $500k-2M (compute, maintenance, retraining, team salaries). This is 10-100x more expensive than RAG or fine-tuning.

Data requirements: You need petabytes (1000+ TB) of high-quality training data. Most companies have terabytes, not petabytes. Terabytes of proprietary data don't justify a custom model. Petabytes do.

When Custom Models Make Sense

Scenario 1: You're an AI company. Your model is your product. OpenAI, Anthropic, Stability AI. You're building to compete with other foundation models. Cost is justified.

Scenario 2: You have unique competitive data. A financial services company with 20 years of proprietary trading data (terabytes). A healthcare company with 10M patient records (multiple terabytes). A search company with 100B+ web pages. These companies have enough data to justify custom training. Cost: $5-20M. Value: competitive models that outperform public models on your specific domain.

Scenario 3: Data privacy is non-negotiable. You can't send data to any vendor (legal, regulatory, security constraints). Custom model on-premises is the only option. Cost: $1-5M. Value: full data ownership, compliance, security.

The Real Story: Why Most Companies Fail at Custom Models

A Series C company decided to build a custom model "because we want control and data privacy." They invested $3M, hired 8 ML engineers, spent 18 months building. Result: a model that was 15% worse than GPT-4 on their domain because they didn't have enough data (only 50TB, not 1000TB+). The model was also slower and less flexible. They spent $3M to build something worse than a $50/month API subscription + $100k RAG setup. The mistake: they confused "we want a custom model" with "we need a custom model." They needed RAG + data privacy, not a custom model. They should have used on-premises Claude or open-source models with privacy-preserving RAG.

When to Use Custom Models

Use only when: (1) you have petabytes of proprietary training data, (2) the AI model itself is your product or core competitive advantage, (3) you're willing to invest $1-10M and accept 12-36 month timelines, (4) you have (or can hire) world-class ML teams, (5) data privacy requirements are non-negotiable and RAG doesn't satisfy them.

Good use cases: AI companies, financial services with proprietary trading data, healthcare with unique patient datasets, search engines with billions of web pages. Most companies should not build custom models.

Decision Framework: Side-by-Side Comparison

Dimension
RAG
Fine-Tuning
Custom Model

Cost (Year 1)
$15-80k
$60-400k
$1-10M

Timeline
2-6 weeks
6-16 weeks
12-36 months

Knowledge Freshness
Real-time (daily updates)
Quarterly (retraining)
Stale (expensive to update)

Maintenance Effort
0.25 FTE (document curation)
0.5-1 FTE (data + retraining)
5-10 FTE (team of ML engineers)

Setup Effort
Organize documents, label metadata
Collect 100-500 labeled examples
Assemble petabyte dataset, recruit experts

Accuracy (Best Case)
85-95% (if retrieval works)
90-98% (on specific tasks)
95-99% (with massive data)

Risk of Failure
Low (fast iteration)
Medium (data quality risk)
High ($millions and 18 months wasted)

The Decision Framework

Decision 1: How often does your knowledge change?

Weekly → RAG (update docs continuously, model has fresh access). Monthly or slower → Fine-tuning becomes viable. Add fine-tuning if style matters. Annual or never → Base model might be sufficient.

Decision 2: How important is style and tone?

Critical (customer-facing brand voice) → Add fine-tuning to RAG. Nice-to-have (internal tools) → RAG alone is fine.

Decision 3: Do you have petabytes of proprietary data and a $10M budget?

Yes → Consider custom. Everyone else → No.

Decision Path for Most Companies

Start with RAG. 2-6 weeks, $20-50k. Test on 50-100 real questions. If accuracy is >85%, ship it. If accuracy is 70-85%, add fine-tuning (another 8 weeks, $80-150k). If accuracy is still <70%, either RAG retrieval is poor (fix document organization) or you need more specific training data. Never jump to custom models as a fix for accuracy problems. Fix retrieval or add fine-tuning first.

The Optimal Approach for Most Companies: RAG + Fine-Tuning

RAG for Facts (knowledge that changes)

Store your documentation, FAQs, product info, knowledge base. When a user asks a question, retrieve relevant documents. This layer gives the model current information.

Fine-Tuning for Style (approach that doesn't change)

Collect 100-300 examples of your desired response style (support responses, documentation, code, analysis). Fine-tune once. This layer teaches the model to sound like you and handle your specific patterns.

Combined Result

The model has current knowledge (RAG) and your brand voice (fine-tuning). This combination outperforms either approach alone.

Case Study: RAG + Fine-Tuning Pays For Itself

A B2B SaaS company deployed RAG + fine-tuning for customer support. Month 1-2: built RAG on 300 support docs (cost: $25k). Accuracy: 70% (knowledge was there but style was generic). Month 3-4: collected 200 support response examples, fine-tuned Claude (cost: $60k). Accuracy: 85%. Final metrics: 85% of support questions self-resolved, 15% escalated to humans. Previous state: all questions required human review, 3 FTE support engineers. New state: 1 FTE support engineer (handles escalations). Saved: 2 FTE = $200k/year. Cost: $85k first year. ROI: 2.35x payback in year 1. Year 2: only retraining costs ($30k/year), support team stays at 1 FTE.

When This Goes Wrong: Stale Fine-Tuned Knowledge

A company fine-tuned a support model on 300 response examples. It worked for months. Then their product changed (new features, deprecated old ones). The fine-tuned model kept recommending old features. Newer support reps got trained on outdated AI responses. The model had codified obsolete knowledge. Lesson: fine-tuning encodes what was true when data was collected. If your product changes frequently, RAG is more resilient. Always pair fine-tuning with RAG for current facts. When product features change, update RAG docs. When support style changes, retrain fine-tuned model.

What to Do Monday Morning

  • Define your use case and success metrics. What problem are you solving? Success = 85% accuracy? Cost 85%, ship it and iterate.** You're done. Monitor for degradation. Update docs as knowledge changes.
    - If RAG accuracy is 70-85%, add fine-tuning. Collect 100-200 examples of your desired response style. Fine-tune. This adds 6-8 weeks and $60-150k, but often pushes accuracy to 90%+.
    - If RAG + fine-tuning still doesn't work, diagnose why. Is retrieval poor? Add metadata filtering, hybrid search (semantic + keyword), multi-stage ranking. Is data quality the issue? Get better training examples. Never jump to custom models. Fix the simpler approaches first.
    - Build a cost/benefit analysis before considering anything more complex. Will RAG + fine-tuning save 1 FTE? That's $120k/year in value. Cost: $80k year 1. ROI: 1.5x. Proceed. Will it save 0.1 FTE? That's $12k/year. Cost: $80k. ROI: 0.15x. Don't do it. Use simpler approaches.

FAQ: Tactical Questions

Q: How do I decide between RAG and fine-tuning?

A: Ask: Does your knowledge change weekly? Yes → RAG. Is style important? Yes → Add fine-tuning. Is knowledge stable but style critical? Pure fine-tuning (quarterly updates). Is everything stable? Base model (no RAG, no fine-tuning).

Q: How much data do I need for fine-tuning?

A: Start with 50-100 examples. Measure accuracy. At 100 examples, you'll see 70-80% of the final improvement. 200-300 examples gives 90%+ of improvement. Beyond 500 examples, diminishing returns. Cost-benefit: collect examples up to the point where additional data stops moving accuracy meaningfully (usually 150-300 examples).

Q: If I fine-tune, do I skip RAG?

A: No. Fine-tuning teaches style. RAG gives current facts. A fine-tuned model without RAG has outdated information. A RAG system without fine-tuning has generic style. Use both. The combination is more powerful than either alone.

Q: How often do I retrain a fine-tuned model?

A: If your domain changes weekly, retrain monthly. If monthly, retrain quarterly. If annually, retrain annually. Monitor accuracy. If accuracy drops >10%, retrain immediately. Cost of retraining: $10-50k depending on data size and compute.

Q: Should I use open-source models instead of Claude or GPT?

A: Open-source (Llama, Mistral) is cheaper at scale and gives you full control. But requires managing your own infrastructure (servers, updates, security). Claude and GPT are managed services (no infrastructure), but locked to vendor pricing. For most companies starting out, use managed services (Claude, GPT). Optimize to open-source later if scale justifies it.

Q: What if my RAG retrieval is poor?

A: 1) Organize documents better (add metadata, clear naming, remove duplicates). 2) Use hybrid search (semantic similarity + keyword matching). 3) Add reranking (retrieve top 10 documents, rerank by relevance). 4) Implement multi-stage retrieval (broad search, then narrow). Cost to improve retrieval: $20-80k in engineering. Most companies achieve 90%+ retrieval accuracy with proper organization.

Q: How do I measure RAG/fine-tuning effectiveness?

A: Hold out 10% of your data (don't use for RAG docs or fine-tuning examples). Test on this held-out set. Measure: (1) Accuracy: did the model give the right answer? (2) Relevance: did retrieval find relevant docs? (3) Hallucination rate: did the model make things up? (4) Cost per request: are you within budget? (5) Latency: does it meet SLA? If all pass, ship. If any fail, diagnose and iterate.

Q: When should I consider building a custom model?

A: Only when: (1) RAG + fine-tuning achieves

The Core Principle

RAG is for knowledge (facts that change frequently). Fine-tuning is for behavior (style and patterns that change slowly). Custom models are for companies where the model itself is a product. Most organizations: start with RAG + fine-tuning (total cost: $80-200k, timeline: 8-16 weeks). This achieves 85-95% accuracy on most tasks. Only move beyond this if business requirements demand it and budgets justify it.

On This Page

Watch the Lecture
RAG Approach
Fine-Tuning
Custom Models
Side-by-Side Comparison
Decision Tree
Hybrid Approaches
Monday Morning Action
FAQ

Chapter Details

Part ofChapter 6