RAG 入门实战：一个 Demo 讲清楚检索增强生成

一、先看一个问题大模型为什么需要查资料假设你问 ChatGPT“知行科技 2025 年的年会主题是什么”如果你之前从没告诉过它这家公司的任何信息它会怎么回答大概率是一本正经地编一个——因为它的知识截止在训练数据日期它不知道 2025 年的事更不知道一家它没见过的公司。这不是 ChatGPT 的问题。这是所有大语言模型的共同局限它们只知道训练时见过的内容不知道你手里的私有文档。传统解决方案是微调Fine-tuning——把新知识背进模型参数。但微调有三个致命缺陷每次更新知识都要重新训练、无法快速追加新数据、模型学会编得更像真的而不是说不知道。RAGRetrieval-Augmented Generation检索增强生成换了一个思路不靠背靠查。让模型在回答问题之前先去一个专门的知识库里检索相关文档然后把查到的内容拼进 Prompt再让模型基于这些资料回答。这个思路的核心公式只有八个字先查资料再答题。二、RAG 是怎么工作的RAG 的工作流程分为四个步骤步骤做什么类比1. 索引Indexing把文档切成段落用 Embedding 模型转成向量存入向量数据库把书拆成纸条贴上标签放进分类柜2. 检索Retrieval用户提问时把问题也转成向量在向量数据库中找最相似的 Top-K 个段落拿着关键词去柜子里翻出最相关的几条纸条3. 增强Augmentation把检索到的段落拼接到用户的原始问题后面组成一个完整的 Prompt把纸条贴在问题上一起递给答题人4. 生成GenerationLLM 基于增强后的 Prompt 生成答案可以标注引用来源答题人看完纸条给出有据可查的答案为什么步骤 2 要用向量数据库而不是普通的关键词搜索因为向量相似度能理解语义。当你问公司多少人时传统关键词搜索可能只匹配含人或多少的句子但向量搜索能找出团队规模、员工数量这种用词不同但意思相同的段落。这是 RAG 区别于传统全文搜索的关键。在实际项目中有几个关键设计选择直接影响效果Chunk Size分块大小太小丢失上下文“根据第3条”——第3条是什么太大检索精度下降。典型值是 512-1024 个字符。Embedding 模型中文场景推荐 BGE/M3E 系列英文推荐 text-embedding-3。维度越高表达能力越强但检索速度越慢。检索策略纯向量检索有精度损失混合检索向量 BM25 关键词 重排序是生产级 RAG 的标配。三、一个能跑起来的 Demorag_demo理论讲完了我们看一个能真正跑起来的项目。代码在 https://gitee.com/XiaoYRecluse/rag_demo.git 技术栈是FastAPI ChromaDB 多提供商 LLM/Embedding。3.1 项目做了什么这个 Demo 实现了一个完整的 RAG 系统把一份公司的员工手册约 9000 字做成了可问答的知识库。核心特性FastAPI REST API提供/api/v1/ask问答、/api/v1/upload文档上传、/api/v1/health健康检查等接口多提供商架构LLM 和 Embedding 都可以在 DeepSeek API / LM Studio / Ollama / SentenceTransformers 之间自由切换——本地跑还是用云端 API改一个环境变量就行ChromaDB 向量存储持久化到本地文件夹无需额外安装数据库服务64 题自动化测试套件覆盖 8 个检索维度可复现的量化评估3.2 三层架构┌─────────────────────────────────────┐ │ API 层 (FastAPI) │ ← 接收 HTTP 请求 │ /ask /upload /docs /health │ └───────────────┬─────────────────────┘ │ ┌───────────────▼─────────────────────┐ │ 业务逻辑层 │ │ QueryPipeline IngestionPipeline │ ← 编排查询和摄入流程 └───────────────┬─────────────────────┘ │ ┌───────────────▼─────────────────────┐ │ 核心服务层多提供商 │ │ LLMService EmbeddingService │ ← 适配 4 种 LLM 4 种 Embedding │ RetrievalService → ChromaDB │ └─────────────────────────────────────┘最巧妙的设计是provider 切换——只需要修改.env文件中的一个配置项场景EMBEDDING_PROVIDERLLM_PROVIDER网络纯本地离线sentence_transformerslm_studio离线本地 APIollamaollama本地云端deepseekdeepseek需要这种设计的实际意义开发时用免费的本地模型调试上线后切换到更精准的云端 API——代码一行不改。3.3 真实测试数据这个 Demo 不是能跑就行的玩具——它配了一套 64 题的测试集覆盖精确事实、概括总结、多段落推理等 8 个维度。最新一轮测试结果指标数值解读检索命中率67.2%(43/64)64 题中有 43 题找到了正确答案所在的段落答案正确率48.4%(31/64)找到段落后LLM 能正确回答的有 31 题平均延迟4057ms/题本地 Qwen3.5-9B RTX 509067.2% 的检索命中率暴露了 Naive RAG 的核心瓶颈检索不到正确段落后续的增强和生成都是空中楼阁。这也是为什么生产级 RAG 需要混合检索 重排序——这些正是下文要谈的扩展方向。四、从 Demo 到生产五个扩展方向这个 Demo 是一个干净的起点。如果你想让它在真实场景中可用以下是五个递进的扩展方向。扩展 1混合检索难度低效果显著当前状态只用了向量相似度检索ChromaDB query→ Top-K 段落。问题纯向量检索对精确匹配人名、日期、编号不敏感——你问第 3.2 条是什么它可能返回完全不相关的段落。方案加入 BM25 关键词检索作为补充两路结果通过 RRFReciprocal Rank Fusion合并再用一个轻量级 Reranker 模型二次排序。预期提升检索命中率 67% → 85%扩展 2文档格式支持难度低当前状态只支持 Markdown 文档摄入按##标题分块。扩展加入 PDFPyMuPDF、Wordpython-docx、网页抓取trafilatura的支持覆盖更多真实文档来源。扩展 3对话历史记忆难度中当前状态每次问答独立没有上下文记忆。用户追问那第二条呢“系统不知道那指什么。方案加入对话历史管理——将最近 N 轮对话压缩后注入 Prompt同时支持基于之前的回答继续追问”。这是从单轮问答到对话式 RAG的跨越。扩展 4多文档知识库难度中当前状态只有一个 collectiondocuments所有文档混在一起。扩展支持创建多个 collection如员工手册、“技术文档”、“规章制度”用户提问时可以指定检索范围或者让系统自动路由到最相关的 collection。扩展 5Agentic RAG难度高当前状态固定流程——提问 → 检索 → 拼接 Prompt → 生成。Agentic RAG让 LLM 自己决定检索策略。“这个问题需要去哪个知识库查”、“第一次检索结果不够精确换一个角度再查”、“用户问的是对比性问题需要从两个知识库各取一段”——Agent 自主规划多步检索而不是被动的单次查询。这是 RAG 的最终形态不是给模型查资料而是模型自己去查资料。五、总结RAG 解决的是一个朴素但关键的问题大模型不知道怎么回答它没学过的东西。与其让它背下来微调不如让它去查检索增强。这个 Demo 把 RAG 的核心 pipeline 完整落地了——从文档分块到向量检索到 LLM 生成所有环节都可配置、可测试。67.2% 的检索命中率不是终点而是告诉你下一步该往哪走的起点。如果你拿到这个 Demo建议的改动优先级先加混合检索让检索更准→ 再支持 PDF/Word让文档来源更广→ 然后加对话记忆让交互更自然→ 最后探索 Agentic RAG让系统更智能。以上的优化方向已经在项目中规划了正在实施中更强大的v2.0版本敬请关注下一篇我们讲讲如何实现Agentic RAG