RAG技术栈全景从向量数据库到LLM上篇我们聊了RAG是什么这篇我们直接上硬菜把RAG技术栈的每一个组件拆开看清楚。不夸张地说90%的人做RAG卡住都是因为组件选型没想清楚就开干。看完这篇你至少能画出自己系统的架构图。大家好我是黒漂技术佬。一、一张图看清RAG全貌先把全景图甩出来。一个企业级RAG系统包含6个核心层┌─────────────────────────────────────────────────┐ │ 【应用层】 │ │ 问答对话 │ 文档搜索 │ 数据助手 │ 标注平台 │ ├─────────────────────────────────────────────────┤ │ 【生成层】 │ │ Prompt模板 │ 上下文组装 │ 流式输出 │ 引用追溯 │ │ │ │ │ LLM大语言模型 │ │ GPT-4 │ DeepSeek │ Qwen │ 私有部署模型 │ ├─────────────────────────────────────────────────┤ │ 【检索层】 │ │ 混合检索 │ Query改写 │ 重排序 │ 结果过滤 │ ├─────────────────────────────────────────────────┤ │ 【向量层】 │ │ Embedding模型 │ 向量数据库 │ 索引管理 │ ├─────────────────────────────────────────────────┤ │ 【数据层】 │ │ 文档解析 │ 文本分块 │ 元数据提取 │ 数据清洗 │ ├─────────────────────────────────────────────────┤ │ 【基础设施层】 │ │ Python/FastAPI │ Docker │ Redis │ MinIO │ └─────────────────────────────────────────────────┘看起来层很多别慌我们一层层拆。二、数据层垃圾进垃圾出RAG系统有一条铁律知识库的质量上限 你喂进去的文档质量。LLM再强检索算法再精妙如果文档本身就是一坨——表格乱码、图片丢失、层级全乱——那最终答案能好才见鬼了。文档解析引擎不同格式需要不同的解析器文档格式推荐工具难点PDF文字型PyMuPDF / pdfplumber表格提取、双栏布局PDF扫描型Tesseract OCR pdf2image手写体、印章遮盖Word (.docx)python-docx嵌入图片、复杂表格Markdown直接读文本无HTMLBeautifulSoup导航栏、广告等噪音飞书/语雀各自API HTML解析富文本嵌套微信群聊记录正则解析大量表情、无关消息实操建议优先用pdfplumber它比 PyMuPDF 更擅长处理中文表格扫描件必须过OCR但别期望太高——扫描质量差的文档 OCR 准确率不到 80%能用Markdown就别用Word——未来你的知识库一定是日积月累的让员工从源头上用结构化的格式文本分块Chunking解析出纯文本后不能整篇喂给Embedding模型——那就像把一本书扔进搜索框。需要切块。常用的分块策略策略1固定长度分块naive不推荐 按 500 字切一块遇到句号才断。 问题可能在「第3章……第4章」中间一刀砍断。 策略2语义分块推荐 按标题层级切一二级标题作为独立块正文段落聚合到对应标题下。 工具LangChain 的 RecursiveCharacterTextSplitter MarkdownHeaderTextSplitter 策略3滑窗重叠折中方案 每块 500 字相邻两块重叠 100 字。 好处不会因为切在句子中间而丢掉语义。我的实战经验中文文档块大小 300~500 字比较合适太短缺少上下文太长稀释语义每个块必须带元数据来源文件名、页码、章节标题、更新时间元数据在检索时会派上大用场——比如「只搜 2024 年后的技术文档」三、向量层RAG的发动机上一篇文章讲了Embedding是把文字变成数字数组。这层有两个关键选型。Embedding 模型怎么选截至 2026 年中文 Embedding 模型已经卷得不成样了。选型核心看三点语义质量、推理速度、向量维度。模型维度中文效果特点text-embedding-3-small (OpenAI)1536⭐⭐⭐云端调用付费效果好但数据要流出bge-large-zh-v1.5 (BAAI)1024⭐⭐⭐⭐开源中文顶流本地部署m3e-large (moka-ai)1024⭐⭐⭐⭐开源中英双语社区活跃stella-large-zh (infgrad)1024⭐⭐⭐⭐开源速度快jina-embeddings-v31024⭐⭐⭐⭐支持 8192 token 长文本GTE-Qwen2-7B-instruct3584⭐⭐⭐⭐⭐大模型做Embedding效果最好但资源吃紧我的选择公司内部用bge-large-zh-v1.5效果和速度都OK如果预算充足且对数据安全没那么敏感text-embedding-3-small的 API 调用是零运维成本的选择。详细评测同一份测试集、同一检索任务下的 mAP10 对比留到第 5 篇再展开。向量数据库怎么选向量数据库是RAG的记忆仓库。市面上的选择大致分三类类型代表产品适用场景轻量级向量库Chroma开发测试、Demo、单机小规模专用向量数据库Milvus / Qdrant / Weaviate百万级以上向量、需要分布式全文向量融合Elasticsearch 8.x已有ES基础设施、需要混合检索具体选哪个我们放到第 6 篇详细对比。这里只给结论Demo 阶段用 Chroma 最快跑通生产环境优先看 Milvus 或带向量能力的 ES 8.x。四、检索层让系统真正懂你检索层是RAG的大脑也是调优空间最大的环节。几个核心技术1. 混合检索Hybrid Search单独用向量检索有一个经典问题你问张三的报销单向量可能匹配到一堆讲报销流程的文档但就是找不到张三那份具体的报销单。原因在于向量擅长语义类比但不擅长精确匹配人名、工号、金额这类实体。所以企业级RAG几乎都用「混合检索」用户问题 │ ├──→ 向量检索语义召回 → Top 20 │ └──→ 关键词检索BM25/ES→ Top 20 │ └──→ RRF倒数排名融合/ 加权融合 → Top 10 │ └──→ 重排序Reranker→ Top 5 → 送给LLM2. Query 改写用户不会写完美的搜索查询。他们可能会问“上次那个关于代码评审的就是那个谁来着你说要加的那个检查项……”这种问题直接向量化几乎搜不到任何东西。所以需要Query改写——在检索之前用一个小型的LLM把用户的模糊问题重写为检索友好的形式原文“上次那个关于代码评审的检查项”改写后“代码评审Code Review检查项清单 规范”3. 重排序Reranker向量检索返回的 Top-K 只是大概相关还需要一个更强的模型重新打分排序。推荐用bge-reranker-large它在 MTEB 中文排行榜上长期霸榜。流程向量检索出 20 条 → Reranker 精排后取前 5 条 → 送给 LLM。五、生成层把材料变成答案生成层看似最简单——把文档片段拼进Prompt就行。但实际上Prompt写得好不好答案质量差一个档次。一份好的RAG Prompt 至少包含【角色设定】你是一个企业知识库助手服务于XX公司内部员工。 【核心规则】 1. 只根据提供的文档内容回答文档中没有的信息明确说不知道 2. 回答末尾必须标注引用的文档名称和页码 3. 如果文档中有矛盾信息如实指出并说明分别来自哪份文档 【相关文档】由检索系统自动填充 ... 【用户问题】用户的原话LLM 选型模型适用场景成本GPT-4o最高质量复杂推理$$DeepSeek-V3性价比极高中文友好$Qwen2.5-72B私有化部署首选自建GPUGLM-4中文效果好$实操建议内部问答场景用 DeepSeek 完全够用成本只有 GPT-4o 的十分之一不到如果数据安全要求高部署一个 Qwen2.5-32B 本地跑也不是不行。六、企业级架构全景附带一张真实部署图讲完所有组件来看一张我实际部署的企业级RAG架构┌─────────────┐ │ Nginx │ 负载均衡 SSL └──────┬──────┘ │ ┌───────────┴───────────┐ │ │ ┌──────▼──────┐ ┌──────▼──────┐ │ FastAPI │ │ FastAPI │ API服务多副本 │ (问答API) │ │ (管理API) │ └──────┬──────┘ └──────┬──────┘ │ │ ┌─────────┼───────────────┬───────┼─────────┐ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │Milvus│ │Redis │ │ LLM │ │Embed│ │MinIO │ │向量库│ │ 缓存 │ │ 服务 │ │ ding│ │文件存│ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘ 文档源 (PDF/Word/MD)关键设计点向量库独立部署Milvus 跑在独立服务器上不跟 API 服务耦合Redis 做两层缓存问题→答案缓存完全相同的提问秒回 Embedding 结果缓存节省反复调 Embedding 服务的开销MinIO 存原始文件文档的原始 PDF/Word 存在对象存储里方便追溯原文异步文档处理上传文档后走消息队列Redis Stream / RabbitMQ解析→分块→向量化→入库全部异步上传秒回七、这里选型最容易踩的3个坑坑1上来就搞微服务Demo 阶段一个 FastAPI Chroma SQLite 完全够用。不要一上来就拆微服务、搞 K8s、配服务网格——你连用户到底怎么用都还没搞清楚。先跑通一个单机的端到端流程再考虑架构拆分。坑2Embedding 模型随便选选了英文优化的模型贴到中文场景上语义检索基本等于随机猜。中文必须选中英双语或纯中文优化的模型。坑3文档不处理就直接扔“我试了试把 200 页的 PDF 直接 Embedding效果不好。”——那是当然的。文档必须经过解析→清洗→分块的流水线。跳过这一步就是在给后续所有环节埋雷。 你的技术栈选好了吗Embedding 模型和向量数据库准备用哪个评论区分享一下我帮你参谋参谋