RAG Implementer
Build production-ready retrieval-augmented generation systems.
Core Principle
RAG = Retrieval + Context Assembly + Generation
Use RAG when you need LLMs to access fresh, domain-specific, or proprietary knowledge that wasn't in their training data.
⚠️ Prerequisites & Cost Reality Check
STOP: Have You Validated the Need for RAG?
Before implementing RAG, confirm:
Try These FIRST (Before RAG)
RAG is powerful but expensive. Try cheaper alternatives first:
1. FAQ Page / Documentation (1 day, $0)
- Create well-organized FAQ or docs
- Add search with Cmd+F
- Works for: <50 common questions, static content
- Test: Do users find answers? If yes, stop here.
2. Simple Keyword Search (2-3 days, $0-20/month)
- Use Algolia, Typesense, or PostgreSQL full-text search
- Good enough for 80% of use cases
- Works for: <100k documents, keyword matching sufficient
- Test: Do users get relevant results? If yes, stop here.
3. Manual Curation (Concierge MVP) (1 week, $0)
- Manually answer user questions
- Build FAQ from common questions
- Works for: <100 users, validating if users want AI
- Test: Do users value your answers enough to pay? If yes, consider RAG.
4. Simple Semantic Search (1 week, $30-50/month)
- Use OpenAI embeddings + Postgres pgvector
- Skip complex retrieval, re-ranking, etc.
- Works for: <50k documents, basic semantic search
- Test: Are embeddings better than keyword search? If no, stop here.
Cost Reality Check
Naive RAG (Prototype):
- Time: 1-2 weeks
- Cost: $50-150/month (vector DB + embeddings + API calls)
- When: Prototype, <10k documents, proof of concept
Advanced RAG (Production):
- Time: 3-4 weeks
- Cost: $200-500/month (hybrid search, re-ranking, monitoring)
- When: Production, 10k-1M documents, validated demand
Modular RAG (Enterprise):
- Time: 6-8 weeks
- Cost: $500-2000+/month (multiple KBs, specialized modules)
- When: Enterprise, 1M+ documents, mission-critical
Decision Tree: Do You Really Need RAG?
Do users need to search your content?
│
├─ No → Don't build RAG ❌
│
└─ Yes
├─ <50 items? → FAQ page ✅ ($0)
│
└─ >50 items?
├─ Keyword search enough? → Use Algolia ✅ ($0-20/mo)
│
└─ Need semantic understanding?
├─ <50k docs? → Simple semantic (pgvector) ✅ ($30/mo)
│
└─ >50k docs?
├─ Validated with users? → Build RAG ✅
└─ Not validated? → Test with Concierge MVP first ⚠️
Validation Checklist
Only proceed with RAG implementation if:
If any checkbox is unchecked: Go back to product-strategist or mvp-builder skills to validate first.
See also: PLAYBOOKS/validation-first-development.md for step-by-step validation process.
8-Phase RAG Implementation
Phase 1: Knowledge Base Design
Goal: Create well-structured knowledge foundation
Actions:
- Map data sources (internal: docs, databases, APIs / external: web, feeds)
- Filter noise, select authoritative content (prevent "data dump fallacy")
- Define chunking strategy: semantic chunking based on structure
- Add metadata: tags, timestamps, source identifiers, categories
Validation:
Common Chunking Strategies:
- Fixed-size: 500-1000 tokens, 50-100 token overlap
- Semantic: By paragraph, section headers, or topic boundaries
- Recursive: Split by structure (markdown headers, code blocks)
Phase 2: Embedding Strategy
Goal: Choose optimal embedding approach for semantic understanding
Actions:
- Select embedding model:
text-embedding-3-large (1536 dim) for general, domain-specific for specialized
- Plan multi-modal needs (text, code, images, tables)
- Decide on fine-tuning: use domain data if general embeddings underperform
- Establish similarity benchmarks
Validation:
Model Selection:
- General: OpenAI
text-embedding-3-large, text-embedding-3-small
- Code:
code-search-babbage-code-001 or StarEncoder
- Multilingual:
multilingual-e5-large
Phase 3: Vector Store Architecture
Goal: Implement scalable vector database
Actions:
- Choose vector DB (Pinecone, Weaviate, Qdrant, Chroma, pgvector)
- Configure index: HNSW for speed, IVF for scale
- Plan scalability: data growth and query volume
- Implement backup, recovery, security
Validation:
Vector DB Decision:
- Managed cloud → Pinecone
- Self-hosted, feature-rich → Weaviate
- Lightweight, local → Chroma
- Cost-conscious → pgvector (Postgres extension)
- High-performance → Qdrant
Phase 4: Retrieval Pipeline
Goal: Build sophisticated retrieval beyond simple similarity search
Actions:
- Implement hybrid retrieval: semantic search + keyword (BM25)
- Add query enhancement: expansion, reformulation, multi-query
- Apply contextual filtering: metadata, temporal constraints, relevance ranking
- Design for query types: factual (precision), analytical (breadth), creative (diversity)
- Handle edge cases: no relevant results found
Advanced Techniques:
- Re-ranking: Use cross-encoder after initial retrieval (e.g.,
cross-encoder/ms-marco-MiniLM-L-12-v2)
- Query routing: Route different query types to specialized strategies
- Ensemble methods: Combine multiple retrieval approaches
- Adaptive retrieval: Adjust top-k based on query complexity
Validation:
Phase 5: Context Assembly
Goal: Transform retrieved chunks into optimal LLM context
Actions:
- Rank and select: prioritize by relevance score, recency, source authority
- Synthesize: merge related chunks, avoid redundancy
- Compress: use LLMLingua or similar for token optimization
- Mitigate "lost in the middle": place critical info at start/end
- Adapt dynamically: adjust context based on conversation history
Context Engineering Integration:
- Blend RAG results with system instructions and user prompts
- Maintain conversation coherence across multi-turn interactions
- Implement context persistence for follow-up queries
- Balance context size vs. information density
Validation:
Phase 6: Evaluation & Metrics
Goal: Measure RAG system performance comprehensively
Retrieval Quality:
- Precision@K: Fraction of top-K results that are relevant
- Recall@K: Fraction of relevant docs in top-K
- MRR (Mean Reciprocal Rank): Average rank of first relevant result
- NDCG: Ranking quality with graded relevance
Generation Quality:
- Faithfulness: Generated content accuracy vs. sources
- Answer Relevance: Response relevance to query
- Context Utilization: How effectively LLM uses retrieved info
- Hallucination Rate: Frequency of unsupported claims
System Performance:
- End-to-End Latency: Query to answer (<3 seconds target)
- Retrieval Latency: Time to retrieve and rank (<500ms)
- Token Efficiency: Information density per token
- Cost Per Query: Combined retrieval + generation costs
Validation:
Phase 7: Production Deployment
Goal: Deploy with enterprise-grade reliability and security
Deployment:
- Containerize with Docker/Kubernetes
- Implement load balancing across RAG instances
- Add caching for frequent queries
- Graceful degradation: fallback to base model on component failure
Security:
- Role-based access controls for knowledge base
- Data masking and PII protection
- Audit logging for compliance
- Prompt injection defense
Monitoring:
- Real-time metrics dashboard (latency, cost, accuracy)
- Query analysis for patterns and failure modes
- Cost tracking and optimization alerts
- Performance profiling for bottlenecks
Validation:
Phase 8: Continuous Improvement
Goal: Establish processes for ongoing enhancement
Data Pipeline:
- Automated knowledge base updates (real-time or scheduled)
- Quality monitoring: detect data drift and degradation
- Source diversification: add new data sources
- Feedback integration: user corrections and preferences
Model Evolution:
- Evaluate and migrate to improved embeddings
- Fine-tune on domain data regularly
- Upgrade architecture: Naive → Advanced → Modular RAG
- Expand multi-modal support (images, audio, video)
Optimization:
- Analyze query patterns, optimize for common needs
- Improve cache hit rates
- Tune vector indices regularly
- Balance performance vs. costs
Validation:
Key RAG Principles
1. Relevance Over Volume
- Quality curation > massive datasets
- Remove outdated/low-quality content continuously
- Prioritize most relevant info to prevent "lost in the middle"
2. Semantic Understanding
- Use embeddings for true semantic matching, not just keywords
- Recognize query intent (factual, analytical, creative)
- Adapt retrieval strategy based on context
3. Multi-Modal Intelligence
- Handle text, images, code, tables, structured data
- Enable cross-modal retrieval (text query → image results)
- Preserve document structure and formatting
4. Temporal Awareness
- Prioritize recent info for time-sensitive topics
- Maintain historical access when relevant
- Integrate real-time data feeds for dynamic domains
5. Transparency & Trust
- Always provide source citations
- Indicate confidence levels
- Explain why specific information was selected
Standard RAG Response Format
{
"answer": "Generated response incorporating retrieved information",
"sources": [
{
"content": "Retrieved text chunk",
"source": "Document/URL identifier",
"relevance_score": 0.95,
"chunk_id": "unique_identifier"
}
],
"confidence": 0.87,
"retrieval_metadata": {
"chunks_retrieved": 5,
"retrieval_time_ms": 150,
"generation_time_ms": 800
}
}
Critical Success Rules
Non-Negotiable:
- ✅ Source attribution for every response
- ✅ Validate generated content against sources (prevent hallucination)
- ✅ Filter sensitive data before retrieval
- ✅ Respond within latency thresholds (<3 seconds)
- ✅ Monitor and optimize costs continuously
- ✅ Comply with security policies
- ✅ Graceful degradation on failures
- ✅ Comprehensive testing before production
Quality Gates:
- Before Production: >85% accuracy on evaluation dataset
- Ongoing: User satisfaction >4.0/5.0
- Performance: 95th percentile <5 seconds
- Reliability: 99.5% uptime
- Cost: Within 10% of budget
Advanced Patterns
Modular RAG Architecture
- Search Module: Query understanding and reformulation
- Memory Module: Long-term conversation persistence
- Routing Module: Query routing to specialized knowledge bases
- Predict Module: Anticipatory pre-loading based on context
Hybrid RAG + Fine-tuning
- RAG for dynamic, frequently changing knowledge
- Fine-tuning for domain-specific reasoning patterns
- Combine strengths for maximum effectiveness
Related Resources
Related Skills:
multi-agent-architect - For complex RAG orchestration
knowledge-graph-builder - For structured knowledge integration
performance-optimizer - For RAG system optimization
Related Patterns:
META/DECISION-FRAMEWORK.md - Vector DB and embedding selection
STANDARDS/architecture-patterns/rag-pattern.md - RAG architecture details (when created)
Related Playbooks:
PLAYBOOKS/deploy-rag-system.md - RAG deployment procedure (when created)
1---2name: rag-implementer3description: Implement retrieval-augmented generation systems. Use when building knowledge-intensive applications, document search, Q&A systems, or need to ground LLM responses in external data. Covers embedding strategy, vector stores, retrieval pipelines, and evaluation.4---5
6# RAG Implementer
7
8Build production-ready retrieval-augmented generation systems.
9
10## Core Principle
11
12**RAG = Retrieval + Context Assembly + Generation**
13
14Use RAG when you need LLMs to access fresh, domain-specific, or proprietary knowledge that wasn't in their training data.
15
16---
17
18## ⚠️ Prerequisites & Cost Reality Check
19
20### STOP: Have You Validated the Need for RAG?
21
22**Before implementing RAG, confirm:**
23
24- [ ] **Problem validated** - Completed `product-strategist` Phase 1 (problem discovery)
25- [ ] **Users need AI search** - Tested with simpler alternatives (see below)
26- [ ] **ROI justified** - Calculated cost vs benefit of RAG vs alternatives
27
28### Try These FIRST (Before RAG)
29
30RAG is powerful but expensive. Try cheaper alternatives first:
31
32**1. FAQ Page / Documentation (1 day, $0)**
33
34- Create well-organized FAQ or docs
35- Add search with Cmd+F
36- **Works for:** <50 common questions, static content
37- **Test:** Do users find answers? If yes, stop here.
38
39**2. Simple Keyword Search (2-3 days, $0-20/month)**
40
41- Use Algolia, Typesense, or PostgreSQL full-text search
42- Good enough for 80% of use cases
43- **Works for:** <100k documents, keyword matching sufficient
44- **Test:** Do users get relevant results? If yes, stop here.
45
46**3. Manual Curation (Concierge MVP) (1 week, $0)**
47
48- Manually answer user questions
49- Build FAQ from common questions
50- **Works for:** <100 users, validating if users want AI
51- **Test:** Do users value your answers enough to pay? If yes, consider RAG.
52
53**4. Simple Semantic Search (1 week, $30-50/month)**
54
55- Use OpenAI embeddings + Postgres pgvector
56- Skip complex retrieval, re-ranking, etc.
57- **Works for:** <50k documents, basic semantic search
58- **Test:** Are embeddings better than keyword search? If no, stop here.
59
60### Cost Reality Check
61
62**Naive RAG (Prototype):**
63
64- **Time:** 1-2 weeks
65- **Cost:** $50-150/month (vector DB + embeddings + API calls)
66- **When:** Prototype, <10k documents, proof of concept
67
68**Advanced RAG (Production):**
69
70- **Time:** 3-4 weeks
71- **Cost:** $200-500/month (hybrid search, re-ranking, monitoring)
72- **When:** Production, 10k-1M documents, validated demand
73
74**Modular RAG (Enterprise):**
75
76- **Time:** 6-8 weeks
77- **Cost:** $500-2000+/month (multiple KBs, specialized modules)
78- **When:** Enterprise, 1M+ documents, mission-critical
79
80### Decision Tree: Do You Really Need RAG?
81
82```
83Do users need to search your content?
84│
85├─ No → Don't build RAG ❌
86│
87└─ Yes
88 ├─ <50 items? → FAQ page ✅ ($0)
89 │
90 └─ >50 items?
91 ├─ Keyword search enough? → Use Algolia ✅ ($0-20/mo)
92 │
93 └─ Need semantic understanding?
94 ├─ <50k docs? → Simple semantic (pgvector) ✅ ($30/mo)
95 │
96 └─ >50k docs?
97 ├─ Validated with users? → Build RAG ✅
98 └─ Not validated? → Test with Concierge MVP first ⚠️
99```
100
101### Validation Checklist
102
103Only proceed with RAG implementation if:
104
105- [ ] Tested simpler alternatives (FAQ, keyword search, manual curation)
106- [ ] Users confirmed they need AI-powered search (not just you think they do)
107- [ ] Calculated ROI: cost of RAG < value users get
108- [ ] Have >50k documents OR complex semantic search requirements
109- [ ] Budget: $200-500/month for infrastructure
110- [ ] Time: 3-4 weeks for production implementation
111
112**If any checkbox is unchecked:** Go back to `product-strategist` or `mvp-builder` skills to validate first.
113
114**See also:** `PLAYBOOKS/validation-first-development.md` for step-by-step validation process.
115
116---
117
118## 8-Phase RAG Implementation
119
120### Phase 1: Knowledge Base Design
121
122**Goal**: Create well-structured knowledge foundation
123
124**Actions**:
125
126- Map data sources (internal: docs, databases, APIs / external: web, feeds)
127- Filter noise, select authoritative content (prevent "data dump fallacy")
128- Define chunking strategy: semantic chunking based on structure
129- Add metadata: tags, timestamps, source identifiers, categories
130
131**Validation**:
132
133- [ ] All data sources catalogued and prioritized
134- [ ] Data quality assessed (accuracy, completeness, freshness)
135- [ ] Chunking strategy tested with sample documents
136- [ ] Metadata schema validated for search effectiveness
137
138**Common Chunking Strategies**:
139
140- Fixed-size: 500-1000 tokens, 50-100 token overlap
141- Semantic: By paragraph, section headers, or topic boundaries
142- Recursive: Split by structure (markdown headers, code blocks)
143
144---
145
146### Phase 2: Embedding Strategy
147
148**Goal**: Choose optimal embedding approach for semantic understanding
149
150**Actions**:
151
152- Select embedding model: `text-embedding-3-large` (1536 dim) for general, domain-specific for specialized
153- Plan multi-modal needs (text, code, images, tables)
154- Decide on fine-tuning: use domain data if general embeddings underperform
155- Establish similarity benchmarks
156
157**Validation**:
158
159- [ ] Embedding model benchmarked on domain data
160- [ ] Retrieval accuracy tested with known query-document pairs
161- [ ] Storage and compute costs validated
162
163**Model Selection**:
164
165- General: OpenAI `text-embedding-3-large`, `text-embedding-3-small`
166- Code: `code-search-babbage-code-001` or StarEncoder
167- Multilingual: `multilingual-e5-large`
168
169---
170
171### Phase 3: Vector Store Architecture
172
173**Goal**: Implement scalable vector database
174
175**Actions**:
176
177- Choose vector DB (Pinecone, Weaviate, Qdrant, Chroma, pgvector)
178- Configure index: HNSW for speed, IVF for scale
179- Plan scalability: data growth and query volume
180- Implement backup, recovery, security
181
182**Validation**:
183
184- [ ] Vector store benchmarked under expected load
185- [ ] Index optimized for retrieval speed and accuracy
186- [ ] Backup and recovery tested
187- [ ] Security controls implemented
188
189**Vector DB Decision**:
190
191- Managed cloud → Pinecone
192- Self-hosted, feature-rich → Weaviate
193- Lightweight, local → Chroma
194- Cost-conscious → pgvector (Postgres extension)
195- High-performance → Qdrant
196
197---
198
199### Phase 4: Retrieval Pipeline
200
201**Goal**: Build sophisticated retrieval beyond simple similarity search
202
203**Actions**:
204
205- Implement hybrid retrieval: semantic search + keyword (BM25)
206- Add query enhancement: expansion, reformulation, multi-query
207- Apply contextual filtering: metadata, temporal constraints, relevance ranking
208- Design for query types: factual (precision), analytical (breadth), creative (diversity)
209- Handle edge cases: no relevant results found
210
211**Advanced Techniques**:
212
213- **Re-ranking**: Use cross-encoder after initial retrieval (e.g., `cross-encoder/ms-marco-MiniLM-L-12-v2`)
214- **Query routing**: Route different query types to specialized strategies
215- **Ensemble methods**: Combine multiple retrieval approaches
216- **Adaptive retrieval**: Adjust top-k based on query complexity
217
218**Validation**:
219
220- [ ] Retrieval accuracy tested across diverse query types
221- [ ] Hybrid retrieval outperforms single-method baselines
222- [ ] Query latency meets requirements (<500ms ideal)
223- [ ] Edge cases and fallbacks tested
224
225---
226
227### Phase 5: Context Assembly
228
229**Goal**: Transform retrieved chunks into optimal LLM context
230
231**Actions**:
232
233- Rank and select: prioritize by relevance score, recency, source authority
234- Synthesize: merge related chunks, avoid redundancy
235- Compress: use LLMLingua or similar for token optimization
236- Mitigate "lost in the middle": place critical info at start/end
237- Adapt dynamically: adjust context based on conversation history
238
239**Context Engineering Integration**:
240
241- Blend RAG results with system instructions and user prompts
242- Maintain conversation coherence across multi-turn interactions
243- Implement context persistence for follow-up queries
244- Balance context size vs. information density
245
246**Validation**:
247
248- [ ] Context relevance validated against human judgments
249- [ ] Token optimization maintains accuracy
250- [ ] Multi-turn conversations maintain coherence
251- [ ] Assembly latency <200ms
252
253---
254
255### Phase 6: Evaluation & Metrics
256
257**Goal**: Measure RAG system performance comprehensively
258
259**Retrieval Quality**:
260
261- **Precision@K**: Fraction of top-K results that are relevant
262- **Recall@K**: Fraction of relevant docs in top-K
263- **MRR (Mean Reciprocal Rank)**: Average rank of first relevant result
264- **NDCG**: Ranking quality with graded relevance
265
266**Generation Quality**:
267
268- **Faithfulness**: Generated content accuracy vs. sources
269- **Answer Relevance**: Response relevance to query
270- **Context Utilization**: How effectively LLM uses retrieved info
271- **Hallucination Rate**: Frequency of unsupported claims
272
273**System Performance**:
274
275- **End-to-End Latency**: Query to answer (<3 seconds target)
276- **Retrieval Latency**: Time to retrieve and rank (<500ms)
277- **Token Efficiency**: Information density per token
278- **Cost Per Query**: Combined retrieval + generation costs
279
280**Validation**:
281
282- [ ] Baseline metrics established
283- [ ] A/B testing framework for config comparisons
284- [ ] Automated evaluation pipeline deployed
285- [ ] Human evaluation protocols for ground truth
286
287---
288
289### Phase 7: Production Deployment
290
291**Goal**: Deploy with enterprise-grade reliability and security
292
293**Deployment**:
294
295- Containerize with Docker/Kubernetes
296- Implement load balancing across RAG instances
297- Add caching for frequent queries
298- Graceful degradation: fallback to base model on component failure
299
300**Security**:
301
302- Role-based access controls for knowledge base
303- Data masking and PII protection
304- Audit logging for compliance
305- Prompt injection defense
306
307**Monitoring**:
308
309- Real-time metrics dashboard (latency, cost, accuracy)
310- Query analysis for patterns and failure modes
311- Cost tracking and optimization alerts
312- Performance profiling for bottlenecks
313
314**Validation**:
315
316- [ ] Production handles expected traffic
317- [ ] Security prevents unauthorized access
318- [ ] Monitoring provides actionable insights
319- [ ] Incident response procedures tested
320
321---
322
323### Phase 8: Continuous Improvement
324
325**Goal**: Establish processes for ongoing enhancement
326
327**Data Pipeline**:
328
329- Automated knowledge base updates (real-time or scheduled)
330- Quality monitoring: detect data drift and degradation
331- Source diversification: add new data sources
332- Feedback integration: user corrections and preferences
333
334**Model Evolution**:
335
336- Evaluate and migrate to improved embeddings
337- Fine-tune on domain data regularly
338- Upgrade architecture: Naive → Advanced → Modular RAG
339- Expand multi-modal support (images, audio, video)
340
341**Optimization**:
342
343- Analyze query patterns, optimize for common needs
344- Improve cache hit rates
345- Tune vector indices regularly
346- Balance performance vs. costs
347
348**Validation**:
349
350- [ ] Automated improvement pipelines functioning
351- [ ] Performance trends show improvement
352- [ ] User satisfaction increasing
353- [ ] System adapts to changing needs
354
355## Key RAG Principles
356
357### 1. Relevance Over Volume
358
359- Quality curation > massive datasets
360- Remove outdated/low-quality content continuously
361- Prioritize most relevant info to prevent "lost in the middle"
362
363### 2. Semantic Understanding
364
365- Use embeddings for true semantic matching, not just keywords
366- Recognize query intent (factual, analytical, creative)
367- Adapt retrieval strategy based on context
368
369### 3. Multi-Modal Intelligence
370
371- Handle text, images, code, tables, structured data
372- Enable cross-modal retrieval (text query → image results)
373- Preserve document structure and formatting
374
375### 4. Temporal Awareness
376
377- Prioritize recent info for time-sensitive topics
378- Maintain historical access when relevant
379- Integrate real-time data feeds for dynamic domains
380
381### 5. Transparency & Trust
382
383- Always provide source citations
384- Indicate confidence levels
385- Explain why specific information was selected
386
387## Standard RAG Response Format
388
389```json
390{
391 "answer": "Generated response incorporating retrieved information",
392 "sources": [
393 {
394 "content": "Retrieved text chunk",
395 "source": "Document/URL identifier",
396 "relevance_score": 0.95,
397 "chunk_id": "unique_identifier"
398 }
399 ],
400 "confidence": 0.87,
401 "retrieval_metadata": {
402 "chunks_retrieved": 5,
403 "retrieval_time_ms": 150,
404 "generation_time_ms": 800
405 }
406}
407```
408
409## Critical Success Rules
410
411**Non-Negotiable**:
412
4131. ✅ Source attribution for every response
4142. ✅ Validate generated content against sources (prevent hallucination)
4153. ✅ Filter sensitive data before retrieval
4164. ✅ Respond within latency thresholds (<3 seconds)
4175. ✅ Monitor and optimize costs continuously
4186. ✅ Comply with security policies
4197. ✅ Graceful degradation on failures
4208. ✅ Comprehensive testing before production
421
422**Quality Gates**:
423
424- Before Production: >85% accuracy on evaluation dataset
425- Ongoing: User satisfaction >4.0/5.0
426- Performance: 95th percentile <5 seconds
427- Reliability: 99.5% uptime
428- Cost: Within 10% of budget
429
430## Advanced Patterns
431
432### Modular RAG Architecture
433
434- **Search Module**: Query understanding and reformulation
435- **Memory Module**: Long-term conversation persistence
436- **Routing Module**: Query routing to specialized knowledge bases
437- **Predict Module**: Anticipatory pre-loading based on context
438
439### Hybrid RAG + Fine-tuning
440
441- RAG for dynamic, frequently changing knowledge
442- Fine-tuning for domain-specific reasoning patterns
443- Combine strengths for maximum effectiveness
444
445## Related Resources
446
447**Related Skills**:
448
449- `multi-agent-architect` - For complex RAG orchestration
450- `knowledge-graph-builder` - For structured knowledge integration
451- `performance-optimizer` - For RAG system optimization
452
453**Related Patterns**:
454
455- `META/DECISION-FRAMEWORK.md` - Vector DB and embedding selection
456- `STANDARDS/architecture-patterns/rag-pattern.md` - RAG architecture details (when created)
457
458**Related Playbooks**:
459
460- `PLAYBOOKS/deploy-rag-system.md` - RAG deployment procedure (when created)