Compare Architectures
Side-by-side: use case, requirements, latency, cost, strengths, weaknesses, failure modes, example — and when to choose each.
Workflow vs AgentSingle agent vs Multi-agentRAG vs Fine-tuningVector search vs BM25Function calling vs MCPDirect API integration vs MCPPlan-then-execute vs ReActShort-term memory vs Long-term memoryLLM-as-judge vs Deterministic evaluatorsHuman-in-the-loop vs Human-on-the-loopSupervisor vs PipelinePrompt caching vs Semantic cachingRouter vs SupervisorFramework vs No framework
| RAG | Fine-tuning | |
|---|---|---|
| Use case | Injecting facts the model does not know, especially changing ones | Changing style, format, or behavior; teaching a narrow skill |
| Requirements | Ingestion pipeline, index, retrieval, grounding | Labeled dataset (hundreds to thousands of examples), training run, eval set |
| Latency | Adds a retrieval step (tens of ms) plus longer prompts | None at inference; can be lower with a smaller tuned model |
| Cost | Per-query: retrieval + extra input tokens | Upfront training plus retraining on every data change |
| Strengths | Fresh data, citations, per-tenant isolation, no retraining | Consistent tone / format; can shrink prompts |
| Weaknesses | Quality bounded by retrieval; long prompts | Does not reliably memorize facts; goes stale; hard to audit |
| Failure modes | Relevant-looking but wrong chunks; hallucinated citations | Overfitting, catastrophic forgetting, leaked training data |
| Example | Answering questions over an internal policy wiki | Producing radiology-report phrasing in a fixed house style |
| Choose this when | Choose RAG for knowledge: anything that changes, needs citing, or differs by tenant. | Choose fine-tuning for behavior: a consistent style or skill that prompting cannot reach, with an eval set ready. |