1. 为什么我要做这个专栏从三次翻车说起去年秋天我帮一个做工业设备维保的团队搭知识库问答系统。他们的需求听起来特别朴素把三千多份PDF格式的检修手册、故障案例、备件清单灌进去让一线工程师用自然语言提问系统给出准确答案和出处。我当时信心满满觉得RAG嘛LangChain加个向量库两天就能跑通Demo。结果第一版上线当天就被打脸——工程师问3号机组液压泵异响怎么处理系统返回的是一段关于液压泵安装扭矩的段落出处标注还是另一台设备的章节。召回率看着有七成但真正能用的答案不到三成。那次之后我意识到RAG这个东西Demo和产品之间隔着一整个太平洋。后来我又陆续参与了两个项目一个是给律所做合同条款检索一个是给电商团队做售后话术库。三次下来踩的坑几乎不重样——切分策略、Embedding选型、检索重排、评测缺失、知识库更新机制每一个环节都能让系统从看起来能用变成实际不能用。这个专栏就是把这些年我在RAG实战里摔过的跤、验证过的方案、以及那些文档里不会写的经验系统地整理出来。它不是一篇入门科普也不是框架API的搬运工。我想聊的是当你手里有一个真实业务场景怎么从零设计一套能扛住评测、能持续迭代的RAG架构。适合已经跑通过Demo、但卡在效果上不去阶段的开发者也适合正在做技术选型、需要判断自研还是用现成方案的架构师。关键词里的RAG、架构设计、自研、MVP、评测会贯穿整个专栏的每一条主线。2. 专栏要解决的核心问题RAG的瓶颈到底在哪2.1 大多数RAG项目死在哪一步我观察过一个现象网上关于RAG的教程百分之八十的篇幅花在怎么把文档灌进向量库和怎么调LangChain的链上但真实项目里这两步恰恰是最不容易出问题的。真正让项目翻车的往往是后面那些没人讲的环节。拿我那个工业维保项目举例。第一版用的是最朴素的固定长度切分512个字符一刀切。问题出在检修手册的结构上——很多故障处理步骤是跨段落甚至跨页的一刀切下去步骤三和步骤四被切到两个chunk里检索时只召回其中一个答案自然残缺。后来改成按标题层级切分再对超长段落做语义切分召回质量立刻上了一个台阶。这个改动没有任何框架层面的黑科技纯粹是对业务文档结构的理解。再比如Embedding模型的选择。很多人默认用OpenAI的text-embedding-ada-002但在中文专业领域尤其是工业术语密集的场景它的表现并不理想。我实测过几个中文优化的模型在同样的测试集上Top-5召回率能差出十五个百分点。这个差距在Demo阶段看不出来因为Demo的query都是你精心设计的但真实用户的提问方式千奇百怪差距就会被放大。2.2 评测缺失是最大的隐形杀手如果说只能给RAG项目提一条建议我会说先建评测集再写代码。听起来反直觉但这是我三次项目里最深刻的教训。没有评测集的时候你改一个参数、换一个模型根本不知道是变好了还是变坏了。只能靠感觉——找几个问题试试觉得答案还行就上线了。这种感觉驱动的迭代方式在项目初期还能凑合一旦知识库规模上去、query分布变复杂就完全失控了。我在律所那个项目里吃过这个亏。当时团队花了大量时间优化检索策略但因为没有评测集每次改动都是这个case好像好了一点那个case好像差了一点折腾了两周整体效果原地踏步。后来我们花三天时间从真实用户日志里抽了200条query人工标注了标准答案和应召回的文档片段建了一个最小可用的评测集。有了它之后迭代效率完全不一样了——每次改动跑一遍评测指标涨了还是跌了一目了然两周内把Top-5召回率从六成出头提到了八成五。这个专栏会把评测集的构建方法作为重点来讲包括怎么从日志里挖query、怎么标注、怎么设计指标、怎么避免评测集过拟合。这些内容在关键词里对应的是评测和agent评测集构建但我会讲得更具体、更可操作。2.3 自研还是用现成方案一个被低估的决策关键词里有自研和MVP这其实是一个很现实的决策问题。市面上有太多开箱即用的RAG平台从LangChain到各种低代码工具看起来都能快速搭起来。但我在实际项目里的体会是MVP阶段可以用现成方案快速验证但一旦进入生产迭代自研核心链路几乎是必然选择。原因不复杂。现成方案为了通用性把很多环节封装成了黑盒。你不知道它怎么切分、怎么检索、怎么重排出了问题只能干瞪眼。而RAG的效果恰恰高度依赖这些细节——你的文档结构、你的query分布、你的业务术语都需要针对性地调整。黑盒方案给不了你这个灵活性。我在电商售后那个项目里一开始用的是某个开源RAG框架的默认链路效果一直卡在及格线。后来把检索和重排两个环节拆出来自己实现只用了不到一周准确率就提了二十多个百分点。核心改动其实很简单把默认的向量相似度检索换成了向量召回关键词召回的混合策略再加了一个轻量的重排模型。这些改动在框架里也能做但你需要深入理解框架的内部机制才能改对那还不如自己写。专栏会专门用一个章节讲自研RAG的架构设计包括哪些环节值得自研、哪些可以用现成组件、怎么设计模块边界让系统可替换可迭代。这不是鼓吹什么都自己写而是帮你建立一套判断标准。3. 专栏内容架构从MVP到生产级的完整路径3.1 模块划分与学习路径整个专栏我打算按从能跑到好用的逻辑来组织大致分五个模块每个模块对应RAG系统的一个关键环节。不是那种第一章介绍RAG是什么的教科书式结构而是直接切入实战问题。第一个模块讲知识库构建核心是文档解析和切分策略。这部分会覆盖PDF、Word、HTML、Markdown等常见格式的处理重点讲怎么根据文档结构设计切分规则而不是无脑按字数切。还会聊到图片和表格的处理——关键词里有人问rag知识库能存储图片嘛答案是能但怎么存、怎么检索、怎么和文本关联这里面有很多细节。第二个模块讲检索与召回这是RAG效果的分水岭。会详细对比向量检索、关键词检索、混合检索的适用场景讲Embedding模型的选型方法讲怎么用重排模型提升Top-K精度。关键词里的rag检索增强和rag瓶颈主要对应这个模块。第三个模块讲生成与答案组织包括Prompt设计、上下文窗口管理、引用标注、幻觉抑制。这部分很多人觉得简单但实际上同样的检索结果不同的Prompt组织方式答案质量能差出一大截。第四个模块讲评测与迭代这是我认为整个专栏最有价值的部分。会讲怎么从零建评测集、怎么设计指标、怎么做A/B测试、怎么定位badcase的根因。关键词里的agent评测集构建和评测会在这里展开。第五个模块讲架构设计与工程化包括自研vs现成的决策、模块边界设计、知识库更新机制、性能优化、成本控制。关键词里的架构设计、自研、MVP主要落在这里。3.2 每个模块的交付物我不想把这个专栏做成读完就忘的科普。每个模块我都会配一个可运行的代码示例基于一个统一的业务场景——就用我那个工业维保的案例脱敏之后作为贯穿始终的示例。这样你学完一个模块就能直接在自己的项目里复现。比如知识库构建模块我会给一个完整的文档处理pipeline从PDF解析到切分到入库代码可以直接跑。检索模块会给一个混合检索的实现包含向量召回、BM25召回和重排的完整链路。评测模块会给一个评测框架你只需要准备自己的query和标注数据就能跑出指标。这些代码不会依赖某个特定框架的魔法核心逻辑都是显式写出来的方便你理解和修改。关键词里的langchain4j easy rag和ollama 简易本地rag知识库我也会涉及但定位是作为对比方案而不是唯一正确答案。4. 关键技术选型那些我踩过坑才明白的事4.1 切分策略别让固定长度毁掉你的知识库切分是RAG里最被低估的环节。大多数人直接用框架的默认切分器按字符数或token数一刀切然后就不管了。但切分质量直接决定了检索的上限——切得不好再好的Embedding和重排也救不回来。我在工业维保项目里的做法是这样的先按文档的标题层级做一级切分把每个章节独立出来然后对超长的章节按段落做二级切分但保留段落之间的重叠最后对特别短的段落向上合并到相邻段落避免产生大量无意义的碎片。这套规则听起来简单但需要你对业务文档的结构有深入理解。还有一个细节切分时要保留元数据。每个chunk除了文本内容还要带上它所属的章节标题、文档来源、页码、甚至表格的列名。这些元数据在检索时可以用来过滤在生成时可以用来标注引用。我见过太多项目chunk里只有纯文本检索出来根本不知道出自哪里用户一看就不信任。关键词里有人问有没有本地的rag文本拆解工具我的建议是工具可以用但切分规则一定要自己定。通用工具能帮你处理格式解析但切分策略必须结合你的文档结构来设计。专栏里我会给一个基于规则的切分器实现你可以直接改成适合自己文档的版本。4.2 Embedding选型中文场景下的实测对比Embedding模型的选择直接决定了向量检索的质量。我在三个项目里实测过多个模型这里分享一些结论。在中文通用场景下BGE系列和M3E系列的表现都比较稳。但在专业领域比如工业术语、法律条文、医疗术语密集的场景通用模型的优势就不明显了。我试过用领域数据对BGE做微调在工业维保的测试集上Top-5召回率比原版提升了大约八个百分点。微调的成本没有想象中高几千条领域语料就能看到效果。另一个容易被忽略的点是向量维度。高维向量检索精度更高但存储和计算成本也更高。我在电商项目里做过对比768维和1024维在最终效果上的差距不到三个百分点但存储成本差了近一倍。对于知识库规模在十万级chunk以内的项目768维通常够用超过百万级才需要认真考虑维度带来的成本问题。还有一点Embedding模型要和检索方式匹配。如果你用的是混合检索向量召回只是其中一路那Embedding模型的绝对精度就没那么关键更重要的是它和关键词召回的互补性。这个思路在专栏的检索模块会详细展开。4.3 重排模型小投入大回报的环节如果只能在一个环节投入优化资源我会选重排。原因很简单向量召回是粗筛重排是精排精排的质量直接决定了最终给到生成模型的上下文质量。我常用的重排方案有两种一种是基于Cross-Encoder的重排模型比如BGE-Reranker系列精度高但速度慢另一种是基于LLM的重排用Prompt让模型对候选文档打分灵活但成本高。实际项目里我通常先用Cross-Encoder做第一轮重排把Top-50压到Top-10如果对精度要求极高再用LLM做第二轮精排。重排带来的提升是立竿见影的。在律所项目里加了重排之后Top-3准确率从五成出头提到了七成五。这个提升幅度比换Embedding模型或者调切分参数都来得大。而且重排模型的部署成本不高一个中等规模的模型就能跑出不错的效果。关键词里的rag框架和rag实战在重排这部分会有大量实操内容包括怎么训练自己的重排模型、怎么评估重排效果、怎么平衡精度和延迟。5. 评测体系让RAG迭代从玄学变成工程5.1 评测集怎么建从日志里挖金矿评测集是RAG迭代的指南针。没有它所有的优化都是盲人摸象。但很多人不知道评测集怎么建觉得要人工造几百条query太费劲。其实有更高效的方法。我的做法是从真实用户日志里挖query。系统上线初期哪怕效果不好也会有用户试用。把他们的提问记录下来去掉重复和无效的剩下的就是最真实的评测素材。这些query的分布比你自己拍脑袋想的要准确得多。有了query之后需要标注两部分一是标准答案二是应该召回的文档片段。标准答案可以由业务专家来写也可以从现有文档里摘取。应召回的片段标注更关键因为它直接决定了召回率指标的计算。我通常会让标注人员标出所有相关的片段而不只是最相关的那一个这样能更全面地评估召回质量。评测集的规模不需要很大。我的经验是200到500条query就能覆盖大部分场景关键是query的多样性和代表性。太少会过拟合太多则标注成本太高。专栏里会给一个评测集构建的完整流程包括query采样、标注规范、质量校验。5.2 指标设计召回率之外还要看什么召回率是最常用的指标但它不是全部。我在实际项目里会同时看几个指标指标含义适用场景Top-K召回率前K个结果中包含相关文档的比例评估检索环节MRR第一个相关结果排名的倒数均值评估排序质量答案准确率生成答案与标准答案的匹配程度评估端到端效果引用准确率答案引用的出处是否正确评估可信度拒答率无法回答时正确拒答的比例评估鲁棒性这几个指标要结合起来看。比如召回率高但答案准确率低说明问题出在生成环节召回率低但答案准确率高可能是评测集太简单。我在电商项目里就遇到过这种情况召回率看着不错但用户满意度很低后来发现是引用标注经常出错用户看到出处不对就不信任答案了。关键词里的agent评测集构建和评测在这个章节会展开讲包括怎么设计自动化评测流程、怎么用LLM做辅助标注、怎么避免评测集过拟合。5.3 Badcase分析定位问题的根因评测跑完之后最重要的是分析badcase。我通常会按错误类型分类是没召回、召回了但排序不对、还是召回了也排序对了但生成错了。不同类型的错误修复方向完全不同。没召回的情况要检查切分是否合理、Embedding是否适合领域、query和文档的表述差异是否太大。召回了但排序不对要检查重排模型是否有效、是否需要加入关键词召回。生成错了要检查Prompt是否清晰、上下文是否太长导致模型迷失、是否需要加入few-shot示例。这个分析过程听起来繁琐但它是RAG迭代的核心。我在工业维保项目里就是通过badcase分析发现很多错误集中在跨章节的故障处理流程上于是针对性地调整了切分策略把相关章节做了关联问题就解决了大半。6. 自研RAG的架构设计模块边界与可迭代性6.1 为什么我建议核心链路自研市面上的RAG框架很多从LangChain到LlamaIndex再到各种低代码平台看起来都能快速搭起来。但我在实际项目里的体会是MVP阶段可以用框架快速验证但生产迭代阶段核心链路自研几乎是必然选择。原因有三。第一框架的抽象层太厚出了问题很难定位。你不知道它内部怎么切分、怎么检索、怎么拼Prompt只能靠猜。第二框架的默认策略是为通用场景设计的你的业务场景越特殊默认策略的效果就越差。第三框架的迭代速度和你项目的迭代速度不匹配你需要的功能它可能没有它更新的功能你可能用不上。自研不等于什么都自己写。我的做法是核心链路自研外围组件用现成的。比如文档解析可以用开源库向量库可以用Milvus或QdrantLLM可以调API但切分策略、检索逻辑、重排逻辑、Prompt组织这些直接影响效果的环节自己实现。这样既保证了灵活性又不用重复造轮子。6.2 模块边界怎么划自研RAG的架构设计核心是模块边界的划分。我的经验是按数据流来分解析层、切分层、索引层、检索层、重排层、生成层、评测层。每一层有明确的输入输出层与层之间通过标准接口通信。这样分的好处是每一层都可以独立替换和迭代。比如你想换Embedding模型只需要改索引层和检索层其他层不受影响。你想加一个新的重排策略只需要在重排层加一个实现不影响检索层。这种可替换性是RAG系统能持续迭代的基础。我在律所项目里就是按这个架构重构的。重构之前所有逻辑混在一个大文件里改一处经常影响另一处。重构之后每个模块独立测试、独立部署迭代效率提升了很多。关键词里的架构设计和自研在这个章节会详细展开包括接口设计、数据格式、配置管理。6.3 知识库更新一个容易被忽略的工程问题知识库不是一次建好就完事的。业务文档会更新新的故障案例会加入旧的条款会废止。怎么让知识库持续更新同时不影响线上服务是一个很现实的工程问题。我的做法是增量更新版本管理。每次文档更新时只处理变化的文档重新切分、重新Embedding、更新索引。同时保留历史版本出问题时可以回滚。对于删除的文档不是直接删索引而是标记为失效检索时过滤掉。这样既保证了更新的实时性又避免了全量重建的开销。还有一个细节更新时要考虑chunk的稳定性。如果切分策略变了同一个文档切出来的chunk会变之前标注的评测数据就对不上了。所以切分策略的变更要谨慎最好在评测集上验证之后再上线。7. 一些实操心得和常见问题7.1 关于Ollama和本地部署关键词里有人问ollama 简易本地rag知识库和怎么在mac上搭建rag知识库。本地部署RAG确实是一个很实用的场景尤其是对数据隐私要求高的团队。Ollama跑本地LLM配合本地的向量库和Embedding模型可以搭出一套完全离线的RAG系统。但本地部署有几个坑要注意。第一本地LLM的生成质量通常不如云端大模型尤其是在复杂推理和长上下文场景下。第二本地Embedding模型的选择有限中文领域的效果可能不如云端模型。第三本地部署的维护成本不低模型更新、硬件资源管理都需要投入。我的建议是如果数据隐私不是硬性要求优先用云端模型如果必须本地部署把LLM和Embedding分开考虑Embedding可以用云端API只传文本不传原文LLM用本地模型。这样能在隐私和效果之间找到一个平衡。7.2 关于RAG和知识库的区分关键词里有人问kg知识库、rag知识库和结构知识库区分以及应用场景。这个问题很典型我简单说一下我的理解。RAG知识库是非结构化文档向量检索的组合适合文档量大、结构松散、查询方式灵活的场景。KG知识库是实体关系图谱图查询的组合适合关系复杂、需要推理的场景。结构化知识库是数据库SQL查询的组合适合数据规整、查询明确的场景。实际项目里这三者往往不是互斥的而是互补的。我在工业维保项目里就用了混合方案设备参数用结构化数据库故障案例用RAG设备之间的关联关系用KG。查询时根据问题类型路由到不同的知识源。这种混合架构比单一方案的效果好很多。7.3 关于RAG的瓶颈和未来RAG的瓶颈我认为主要在三个地方检索精度、上下文窗口、生成可控性。检索精度受限于Embedding模型和切分策略上下文窗口受限于LLM的能力生成可控性受限于Prompt设计和模型的对齐程度。这三个瓶颈短期内都不会有根本性的突破。所以RAG的优化更多是在工程层面做权衡和组合。比如检索精度不够就用混合检索和重排来补上下文窗口不够就用摘要和分层检索来压缩生成可控性不够就用引用标注和拒答机制来兜底。这个专栏不会给你一个银弹但会给你一套完整的工程方法论帮你在自己的场景里找到最优解。关键词里的rag教程、rag实战、rag项目这些最终都要落到具体的工程决策上。8. 写在最后一些个人体会做RAG这几年我最大的体会是这个领域没有捷径但有方法。捷径是那些三行代码搭建RAG的教程看起来很美但一到真实场景就露馅。方法是理解每个环节的原理建立评测驱动的迭代习惯根据业务场景做针对性的设计。我见过太多团队在Demo阶段信心满满在生产阶段举步维艰。区别不在于用了什么框架、什么模型而在于有没有建立起一套工程化的迭代体系。评测集、badcase分析、模块化架构、持续更新机制这些听起来不酷但它们是RAG从能用到好用的关键。这个专栏会把这些方法系统地讲清楚配上可运行的代码和真实的案例。如果你正在做RAG项目或者准备做希望这些内容能帮你少走一些弯路。毕竟我踩过的坑你没必要再踩一遍。