我先做个自我检查我是资深博主只拿到一个项目标题要产出一篇高信息密度、可直接复现的工程实践文章。输入标题很明确是一个典型的“逆向工程”类技术主题核心受众应该是正在做企业知识库、智能问答或者自研RAG系统的工程师。下面我按“架构规律→逐层拆解→自研蓝图→踩坑排查→落地清单”的脉络来写把六款开源产品的共性规律当作主线落成一套能直接照做的自研方案。1. 为什么我要拆解六款开源RAG重新认识“检索增强生成”这件事先说背景。我去年接手一个内部知识问答项目需求不复杂把公司散落在 Wiki、产品手册、工单记录里的文档统一起来做一个既能精确匹配、又能语义泛化的问答入口。第一反应肯定是直接部署一套开源方案但实际测下来发现一个问题——通用开源产品完成度很高可一旦要接内部权限体系、定制文档解析规则、调整生成风格就变得非常别扭。与其花大量时间在别人的框架里打补丁不如拆一套自己的。于是我给自己定了一个硬任务把社区里最具代表性的六款开源RAG相关产品全部拉下来逐个跑通、读源码、画架构然后反向总结出一套可以复用的自研蓝图。这六款产品我在正文里统一用代号称呼有面向个人知识库的轻量工具有面向企业级多租户的平台型方案有侧重云原生的部署方案有面向搜索引擎优化的工作流框架也有纯后端能力的服务化工具还有在多模态扩展上走得比较前的实验型项目。选择它们不是因为它们最流行而是这六款刚好覆盖了RAG系统常见的产品形态和技术路线足够提炼出共性规律。拆完之后我有个很直接的感受RAG系统的技术难度不在任何一个单点而在“全链路的数据流如何闭环”。单纯把向量检索做得再好文档解析一塌糊涂生成质量照样崩Prompt写得出神入化检索召回一堆噪声回答依然是胡编。这套系统本质上是一条流水线瓶颈永远出现在最弱的那个环节。本文要做的就是把这条流水线逐段拆开告诉你哪一段最值得投入、哪一段可以先用最笨的办法顶上以及如何在资源有限的情况下做出一套属于你自己的、能上生产的RAG系统。如果你正面临同样的问题——开源方案不够定制、从零做起又怕踩坑那么这篇内容就是为你准备的。我用六个产品的代码做底把它们的共性和差异全部摊开最后落到一张可以直接对照实施的功能清单上。读完之后你至少能回答三个问题自研RAG的边界在哪里架构上必须保留哪些模块第一步做什么才不会白干2. 拆完六款产品之后我发现RAG的架构早就不再是秘密2.1 六款产品定位差异很大但骨架高度一致我先把六款产品的定位和关键特性放在一张表里方便你对标。需要说明的是以下信息基于我对源码行为和公开技术文档的综合观察不代表任何官方结论只为讲清架构规律。代号产品形态目标用户技术侧重点部署方式产品A个人知识库问答独立开发者、小团队快速接入、轻量检索Docker单机产品B企业级知识平台中大型团队多租户、细粒度权限集群部署产品C云原生知识服务云基础设施成熟团队Kubernetes编排、弹性伸缩Helm/云原生产品D搜索工作流引擎对检索效果要求高的团队混合检索、多路召回服务集群产品E后端功能库有自研能力的开发团队接口灵活、可编程性强嵌入内部服务产品F多模态知识实验研究型团队图像/表格/语音混合问答实验环境看完这张表你会发现这六款产品在用户界面、部署形态、扩展方式上的差异非常大几乎不是一个量级的产品。但我把每个项目的源码目录结构和核心调用链拉出来之后发现它们的骨架惊人一致都需要先做文档导入与格式识别再做内容切分与向量化处理然后建索引、实现检索接口最后把检索结果喂给大模型生成答案。换句话说不同方案的差异不是“模块不同”而是“每个模块的实现精度和工程深度不同”。2.2 五段式架构是我逆向工程最重要的结论如果把这六款产品的通用部分抽出来就会得到一条五段式链路数据接入 - 索引构建 - 检索召回 - 结果重排 - 生成回答。无论产品表面上是聊天机器人还是搜索框无论用的是商用大模型接口还是私有化部署的开源模型最终都会落在这五个环节里。你可以把这条链路理解成一条生产流水线。第一段“数据接入”负责把原材料各类文档变成标准零件可处理的文本块第二段“索引构建”负责给零件贴标签、入库第三段“检索召回”是按需取出候选零件第四段“结果重排”是从候选里挑出最合适的几个第五段“生成回答”是把零件组装成最终产品。任何一段出了流程问题修复的成本都会顺延到末端——生成器只会忠实地放大前端的缺陷而不是修复它。我之所以要先讲这个结论是因为很多自研项目一上来就陷入局部优化选了某个优秀的向量库就觉得万事大吉或者花了几个星期调Prompt结果数据接入层根本没处理干净。五段式架构的意义在于帮你在项目开始前就建立一个全局视图——哪些地方是必须自研的核心能力哪些地方可以直接借助开源组件以及每一段需要什么粒度的数据输入心里都有数。3. 一张可复用的自研架构蓝图从数据接入到答案生成的完整拆解3.1 数据接入层先解决文档先天不干净的问题六款产品里的任何一款都在数据接入层投入了相当大的代码量。表面上这层只是“读文件”实际要做的事包括文件格式识别PDF、Word、Markdown、扫描件、文本抽取内置解析器或外部OCR服务、版面结构还原标题层级、表格关系、以及增量同步机制。很多使用者在初期忽略这个环节直接在PDF上按页截断做向量化结果回答时经常出现一句话被拦腰截断的情况。我在自研方案里给数据接入层定的核心准则是宁可前置解析多做一步也不要让脏数据流到下游。具体的落地方式分几步第一步统一转成标准格式把原始文档转成结构化的简化文档格式保留最小集的元信息第二步做增量感知每次导入时计算文档哈希文件不变就直接跳过第三步是权限预清洗在文本块入库时就把权限标签一并写入避免检索阶段再做复杂过滤。这样一来下游的索引层永远只面对干净输入。关于OCR如果文档里有大量扫描件我的建议是先接入一个外部OCR服务或开源OCR模型把图像转成文字后再走标准链路。不要试图在自研第一阶段自己造OCR轮子这部分性价比很低。3.2 索引构建层切分粒度决定检索质量的边界索引层是五段式链路里最容易“过度设计”的地方。六款产品里有的采用固定长度切分有的采用递归字符切分有的引入了基于语义边界的小模型切分。它们的共性是很谨慎地控制每个文本块的长度基本维持在200~1000 token之间而不是把一个章节直接塞进去。切分粒度这件事我实测下来的经验是没有一种万能策略。固定长度切分简单稳定但容易切断语义递归字符切分对代码和结构化文本比较友好语义切分效果最好但依赖额外模型推理性能开销明显。实际落地方案通常是一个组合策略先按文档结构切出大块标题、段落再对长段落做二次递归切分确保每块不超过设定的最大token数同时保持块间有少量重叠防止检索时漏掉边界内容。索引构建还有一个容易忽略的指标——embedding的维度与距离度量。常见的文本向量模型维度从384到1536不等选什么取决于数据规模、存储成本和相似度计算开销。小规模知识库选低维模型完全够用大规模场景就要综合考虑内存占用和检索延迟。另一点是自研时不要只建向量索引建议同时保留一段原始文本及其元数据核心原因会在后面“混合检索”部分讲。3.3 检索召回层向量检索与关键字检索不是二选一六款产品里绝大多数在检索层都做了“混合检索”一路走向量相似度另一路走关键词匹配然后把两路候选结果合并。最初我以为这属于冗余设计后来试验了纯向量检索后才发现问题向量检索处理“语义相似”很强处理“精确词匹配”却很弱。比如用户问“退款政策”如果知识库里恰好有一篇文档标题是《退款政策V3》向量检索可能把它排到第十名开外但这明明是最相关的答案。混合检索的合并策略六款产品里常见的主要有两种一种是加权分数求和给向量分和关键词分各配一个权重另一种是竞速排序先取两路各自的Top K再用融合算法重新排序。实操中我用得最多的是融合算法因为它不需要调权重直接把两路排名做倒数融合稳定性很好。在兼顾工程复杂度和效果的前提下这是一个成本极低的方案。但混合检索只是召回层的起点真正的精度提升要靠重排阶段。这一步通常会用更强的模型如跨编码器重排模型对候选结果逐条打分把真正相关的内容排到最前面。只要候选数控制在几十条以内重排的计算开销完全可以接受。最关键的是重排阶段大模型不是必需品用一个开源重排模型就足够了这样能显著降低自研成本。3.4 生成回答层Prompt模板不是越多越好到生成层所有产品都做类似的事把检索到的文本块拼装成上下文连同用户问题一起交给大模型。但我观察到六款产品在Prompt设计上有个共同趋势——控制上下文规模而不是把所有检索结果全塞给模型。一个容易被忽略的事实是大模型的注意力机制决定了它会平均分配注意力给所有输入。如果把大量低相关文本块塞进Prompt模型很容易被噪声带偏回答反而更差。实测下来检索召回百余条候选经过重排后只取前3~5个文本块进Prompt这个数量在大多数场景下效果最好。在自研蓝图中生成层需要严控两件事上下文总量和引用格式。引用格式是RAG系统是否可信的分水岭。我强烈建议无论答案生成的结果怎样都要让模型在回答时按索引编号标注引用来源。虽然不能百分之百保证引用绝对正确但至少能提升结果的可用性让用户有迹可循。更重要的是引入“无法回答”机制——当检索相关性低于阈值时让模型明确回答“知识库中未找到相关信息”而不是强行编造答案。这一点在客服和内部知识场景下是非常必要的。4. 自研过程中最容易踩的五个坑以及对应的排查手段4.1 切分策略过于粗暴语义被生硬截断很多人都遇到过这种场景问“如何配置SSL证书”模型回答的是“SSL证书是一种用于加密数据传输的协议证书配置方式取决于服务器环境……”看起来没错但就是没有直接回答“如何配置”。检查数据后发现问题通常出在切分上——文档里配置步骤被硬切分到不同文本块检索召回了前半个步骤后半个步骤在另一个文本块里没有被召回。我推荐的排查方式是先把召回结果拉出来看确认正确答案在第几位如果正确答案在候选里但排名靠后问题出在重排如果根本没进候选那就一定是切分或embedding的问题。切分调整的经验是在段落边界处优先切分、对长代码块或长表格单独处理最后再设置块间重叠保留20~50个token的上下文衔接。这套组合策略实测下来基本能覆盖大多数文档类型。4.2 盲目用大型模型向量化硬件成本成倍增加在自研初期很容易把“效果更好”等同于“模型更大”。引入高维模型后索引构建时间、内存占用和查询延迟都会明显上升但小规模知识库上的效果提升却感知不强。经过多轮对比我可以负责任地说在几十万文本块的规模下开源中文向量模型与商用大模型的检索效果差距并不大真正的效果瓶颈往往在切分、重排和文档解析上而非embedding本身。我的建议是采用“分阶段模型策略”MVP阶段用推理资源占用小、速度快的模型等数据规模上来之后再把模型升级到更大规格。同时索引构建和查询阶段可以共用同一个模型减少重复部署。向量维度不必追求最高精度和成本的平衡点才更重要。4.3 只做向量检索忘记关键词兜底方案关键词搜索被很多人误以为过时了但在RAG系统里它其实是很好的“精确匹配兜底”。比如产品型号、订单编号、法律条款这类强标识信息向量检索很难保证精确命中而关键词检索可以做到百分之百匹配。混合检索的自研实现也就多了约一两百行代码效果提升却立竿见影。实现很简单用开源的全文检索引擎建立倒排索引与向量检索并行执行。查询到达后分别从两路拿回候选集做分数融合再进重排阶段。如果前期不想引入重型引擎也可以先基于简洁的内存索引做最简单版本后续再平滑迁移。至少我在实践中从未见过纯向量检索在混合场景下能打赢向量加关键词的组合方案。4.4 Prompt模板越攒越多维护成本失控一开始我会针对不同问题类型写不同的Prompt模板比如“价格类”“操作类”“故障类”各一套。结果模板一变多维护成本增长很快——新增一个文档类型就要同步修改好几个Prompt而且很难判断是哪条Prompt导致回答风格漂移。六款开源产品的做法反而很克制大多数只维护一套核心系统模板把差异化的诉求通过检索结果和额外指令来承载。我后来的做法是只保留一条基准模板规定回答风格、引用格式和拒答策略把业务差异放到数据元信息里让模型根据元信息自行调整。这种设计极大地降低了迭代成本而且效果比多模板更稳定。如果你发现Prompt逻辑越来越复杂通常是数据侧应该负责的语义没有被解析出来而不是Prompt写得不够多。4.5 没有离线评测集就开始调优前方一片模糊RAG系统最难的还不是实现而是“怎么知道改完变好了还是变坏了”。没有评测集一切调优都是凭感觉。这里说的评测集不是几十条手工用例而是把线上真实用户问题沉淀成几百条带标准答案的验证集至少覆盖常见问答、模糊表述、跨文档组合、明显无答案四类情况。在自研蓝图中评测集应该和开发同步建设。每次改动后都跑一遍评测集统计准确率、召回相关性和拒答正确率。手动评一遍几百条数据虽然耗时但在MVP阶段换来的是稳定的可迭代基线。等后续有精力可以把评测流程自动化但前提是先有数据。如果连评测集都没有就不要谈效果优化。5. 拿来即用的自研RAG实施路线从MVP到生产环境5.1 最小可行产品阶段能跑通就是胜利自研RAG的MVP不需要做得大而全我的建议是聚焦一个垂直文档域比如内部员工手册。MVP阶段需要具备的能力是文档导入与文本抽取、段落切分、向量化与存储、关键词索引、混合检索、重排、Prompt生成与回答展示。不需要做权限体系不需要流式输出也不需要多租户隔离。技术栈选择上MVP阶段可以用轻量级方案本地或单机向量库做存储开源文本向量模型做embedding开源全文检索引擎做关键词索引开源重排模型做精排后端API调用大模型做生成。跑通标准是用户上传10份文档后对预置的50个问题至少能做到“大部分直接命中、不会虚构答案”。这一步大约需要一到两周集中开发。5.2 生产环境演进阶段稳定性和权限才是关键MVP验证了效果之后进入生产环境前需要做三件核心增强第一是权限过滤索引中增加权限标签检索阶段先行过滤避免数据越权访问第二是缓存层在查询和检索两个环节分别加缓存高并发场景下能显著降低接口延迟同时节省大模型调用成本第三是异步索引流水线新上传文档进入消息队列处理不阻塞用户操作配合增量更新机制保证回答内容是新版本文档。生产环境的监控体系建议至少包含两类指标检索环节的召回率变化和生成环节的答案采纳率。通过用户反馈逐步修正切分策略和重排模型。做这部分我不建议一次性铺开而是每两个迭代周期集中处理一个薄弱环节。5.3 自研RAG功能清单与优先级分配规划落地时把功能按优先级排出下表就能避免团队陷入局部优化优先级功能模块核心目标建议投入占比P0文档解析与切分保证数据可用20%P0混合检索与重排保证查得准25%P0答案生成与引用保证答得稳20%P1权限过滤与隔离保证数据安全10%P1增量索引与缓存保证体验快10%P2评测集与自动化保证可迭代10%P2运营分析看板保证可观测5%P0部分全部做完已经可以支撑一个内部工具上线。P1和P2部分则根据实际使用反馈决定优先顺序。多数场景下检索质量和生成稳定性比权限隔离更先暴露问题所以建议先把P0打磨透。我个人在自研过程中的体会是开源RAG产品最大的价值不是拿来直接部署而是它们用各自的方式验证了“五段式链路”的正确性。拆六个产品的过程相当于让十几个架构理念在同一个表格里互相碰撞。与其纠结于“要不要从零写向量检索”这种问题不如承认通用组件的作用——自研的核心是数据接入规则、切分策略、检索融合方式和生成约束这四件事其他环节用成熟组件拼装即可。最后再分享一个小技巧每改一次切分策略或者检索逻辑不要只看一两个样例而是立刻跑评测集里的几十道经典问题观察整体正确率的增量。这个方法能让你在前期每一步都走得很扎实。按照上面这条路线走哪怕团队只有两三个人也能在几周内交付一套内部可用、后续可持续演进的RAG系统。
我先做个自我检查我是资深博主只拿到一个项目标题要产出一篇高信息密度、可直接复现的工程实践文章。输入标题很明确是一个典型的“逆向工程”类技术主题核心受众应该是正在做企业知识库、智能问答或者自研RAG系统的工程师。下面我按“架构规律→逐层拆解→自研蓝图→踩坑排查→落地清单”的脉络来写把六款开源产品的共性规律当作主线落成一套能直接照做的自研方案。1. 为什么我要拆解六款开源RAG重新认识“检索增强生成”这件事先说背景。我去年接手一个内部知识问答项目需求不复杂把公司散落在 Wiki、产品手册、工单记录里的文档统一起来做一个既能精确匹配、又能语义泛化的问答入口。第一反应肯定是直接部署一套开源方案但实际测下来发现一个问题——通用开源产品完成度很高可一旦要接内部权限体系、定制文档解析规则、调整生成风格就变得非常别扭。与其花大量时间在别人的框架里打补丁不如拆一套自己的。于是我给自己定了一个硬任务把社区里最具代表性的六款开源RAG相关产品全部拉下来逐个跑通、读源码、画架构然后反向总结出一套可以复用的自研蓝图。这六款产品我在正文里统一用代号称呼有面向个人知识库的轻量工具有面向企业级多租户的平台型方案有侧重云原生的部署方案有面向搜索引擎优化的工作流框架也有纯后端能力的服务化工具还有在多模态扩展上走得比较前的实验型项目。选择它们不是因为它们最流行而是这六款刚好覆盖了RAG系统常见的产品形态和技术路线足够提炼出共性规律。拆完之后我有个很直接的感受RAG系统的技术难度不在任何一个单点而在“全链路的数据流如何闭环”。单纯把向量检索做得再好文档解析一塌糊涂生成质量照样崩Prompt写得出神入化检索召回一堆噪声回答依然是胡编。这套系统本质上是一条流水线瓶颈永远出现在最弱的那个环节。本文要做的就是把这条流水线逐段拆开告诉你哪一段最值得投入、哪一段可以先用最笨的办法顶上以及如何在资源有限的情况下做出一套属于你自己的、能上生产的RAG系统。如果你正面临同样的问题——开源方案不够定制、从零做起又怕踩坑那么这篇内容就是为你准备的。我用六个产品的代码做底把它们的共性和差异全部摊开最后落到一张可以直接对照实施的功能清单上。读完之后你至少能回答三个问题自研RAG的边界在哪里架构上必须保留哪些模块第一步做什么才不会白干2. 拆完六款产品之后我发现RAG的架构早就不再是秘密2.1 六款产品定位差异很大但骨架高度一致我先把六款产品的定位和关键特性放在一张表里方便你对标。需要说明的是以下信息基于我对源码行为和公开技术文档的综合观察不代表任何官方结论只为讲清架构规律。代号产品形态目标用户技术侧重点部署方式产品A个人知识库问答独立开发者、小团队快速接入、轻量检索Docker单机产品B企业级知识平台中大型团队多租户、细粒度权限集群部署产品C云原生知识服务云基础设施成熟团队Kubernetes编排、弹性伸缩Helm/云原生产品D搜索工作流引擎对检索效果要求高的团队混合检索、多路召回服务集群产品E后端功能库有自研能力的开发团队接口灵活、可编程性强嵌入内部服务产品F多模态知识实验研究型团队图像/表格/语音混合问答实验环境看完这张表你会发现这六款产品在用户界面、部署形态、扩展方式上的差异非常大几乎不是一个量级的产品。但我把每个项目的源码目录结构和核心调用链拉出来之后发现它们的骨架惊人一致都需要先做文档导入与格式识别再做内容切分与向量化处理然后建索引、实现检索接口最后把检索结果喂给大模型生成答案。换句话说不同方案的差异不是“模块不同”而是“每个模块的实现精度和工程深度不同”。2.2 五段式架构是我逆向工程最重要的结论如果把这六款产品的通用部分抽出来就会得到一条五段式链路数据接入 - 索引构建 - 检索召回 - 结果重排 - 生成回答。无论产品表面上是聊天机器人还是搜索框无论用的是商用大模型接口还是私有化部署的开源模型最终都会落在这五个环节里。你可以把这条链路理解成一条生产流水线。第一段“数据接入”负责把原材料各类文档变成标准零件可处理的文本块第二段“索引构建”负责给零件贴标签、入库第三段“检索召回”是按需取出候选零件第四段“结果重排”是从候选里挑出最合适的几个第五段“生成回答”是把零件组装成最终产品。任何一段出了流程问题修复的成本都会顺延到末端——生成器只会忠实地放大前端的缺陷而不是修复它。我之所以要先讲这个结论是因为很多自研项目一上来就陷入局部优化选了某个优秀的向量库就觉得万事大吉或者花了几个星期调Prompt结果数据接入层根本没处理干净。五段式架构的意义在于帮你在项目开始前就建立一个全局视图——哪些地方是必须自研的核心能力哪些地方可以直接借助开源组件以及每一段需要什么粒度的数据输入心里都有数。3. 一张可复用的自研架构蓝图从数据接入到答案生成的完整拆解3.1 数据接入层先解决文档先天不干净的问题六款产品里的任何一款都在数据接入层投入了相当大的代码量。表面上这层只是“读文件”实际要做的事包括文件格式识别PDF、Word、Markdown、扫描件、文本抽取内置解析器或外部OCR服务、版面结构还原标题层级、表格关系、以及增量同步机制。很多使用者在初期忽略这个环节直接在PDF上按页截断做向量化结果回答时经常出现一句话被拦腰截断的情况。我在自研方案里给数据接入层定的核心准则是宁可前置解析多做一步也不要让脏数据流到下游。具体的落地方式分几步第一步统一转成标准格式把原始文档转成结构化的简化文档格式保留最小集的元信息第二步做增量感知每次导入时计算文档哈希文件不变就直接跳过第三步是权限预清洗在文本块入库时就把权限标签一并写入避免检索阶段再做复杂过滤。这样一来下游的索引层永远只面对干净输入。关于OCR如果文档里有大量扫描件我的建议是先接入一个外部OCR服务或开源OCR模型把图像转成文字后再走标准链路。不要试图在自研第一阶段自己造OCR轮子这部分性价比很低。3.2 索引构建层切分粒度决定检索质量的边界索引层是五段式链路里最容易“过度设计”的地方。六款产品里有的采用固定长度切分有的采用递归字符切分有的引入了基于语义边界的小模型切分。它们的共性是很谨慎地控制每个文本块的长度基本维持在200~1000 token之间而不是把一个章节直接塞进去。切分粒度这件事我实测下来的经验是没有一种万能策略。固定长度切分简单稳定但容易切断语义递归字符切分对代码和结构化文本比较友好语义切分效果最好但依赖额外模型推理性能开销明显。实际落地方案通常是一个组合策略先按文档结构切出大块标题、段落再对长段落做二次递归切分确保每块不超过设定的最大token数同时保持块间有少量重叠防止检索时漏掉边界内容。索引构建还有一个容易忽略的指标——embedding的维度与距离度量。常见的文本向量模型维度从384到1536不等选什么取决于数据规模、存储成本和相似度计算开销。小规模知识库选低维模型完全够用大规模场景就要综合考虑内存占用和检索延迟。另一点是自研时不要只建向量索引建议同时保留一段原始文本及其元数据核心原因会在后面“混合检索”部分讲。3.3 检索召回层向量检索与关键字检索不是二选一六款产品里绝大多数在检索层都做了“混合检索”一路走向量相似度另一路走关键词匹配然后把两路候选结果合并。最初我以为这属于冗余设计后来试验了纯向量检索后才发现问题向量检索处理“语义相似”很强处理“精确词匹配”却很弱。比如用户问“退款政策”如果知识库里恰好有一篇文档标题是《退款政策V3》向量检索可能把它排到第十名开外但这明明是最相关的答案。混合检索的合并策略六款产品里常见的主要有两种一种是加权分数求和给向量分和关键词分各配一个权重另一种是竞速排序先取两路各自的Top K再用融合算法重新排序。实操中我用得最多的是融合算法因为它不需要调权重直接把两路排名做倒数融合稳定性很好。在兼顾工程复杂度和效果的前提下这是一个成本极低的方案。但混合检索只是召回层的起点真正的精度提升要靠重排阶段。这一步通常会用更强的模型如跨编码器重排模型对候选结果逐条打分把真正相关的内容排到最前面。只要候选数控制在几十条以内重排的计算开销完全可以接受。最关键的是重排阶段大模型不是必需品用一个开源重排模型就足够了这样能显著降低自研成本。3.4 生成回答层Prompt模板不是越多越好到生成层所有产品都做类似的事把检索到的文本块拼装成上下文连同用户问题一起交给大模型。但我观察到六款产品在Prompt设计上有个共同趋势——控制上下文规模而不是把所有检索结果全塞给模型。一个容易被忽略的事实是大模型的注意力机制决定了它会平均分配注意力给所有输入。如果把大量低相关文本块塞进Prompt模型很容易被噪声带偏回答反而更差。实测下来检索召回百余条候选经过重排后只取前3~5个文本块进Prompt这个数量在大多数场景下效果最好。在自研蓝图中生成层需要严控两件事上下文总量和引用格式。引用格式是RAG系统是否可信的分水岭。我强烈建议无论答案生成的结果怎样都要让模型在回答时按索引编号标注引用来源。虽然不能百分之百保证引用绝对正确但至少能提升结果的可用性让用户有迹可循。更重要的是引入“无法回答”机制——当检索相关性低于阈值时让模型明确回答“知识库中未找到相关信息”而不是强行编造答案。这一点在客服和内部知识场景下是非常必要的。4. 自研过程中最容易踩的五个坑以及对应的排查手段4.1 切分策略过于粗暴语义被生硬截断很多人都遇到过这种场景问“如何配置SSL证书”模型回答的是“SSL证书是一种用于加密数据传输的协议证书配置方式取决于服务器环境……”看起来没错但就是没有直接回答“如何配置”。检查数据后发现问题通常出在切分上——文档里配置步骤被硬切分到不同文本块检索召回了前半个步骤后半个步骤在另一个文本块里没有被召回。我推荐的排查方式是先把召回结果拉出来看确认正确答案在第几位如果正确答案在候选里但排名靠后问题出在重排如果根本没进候选那就一定是切分或embedding的问题。切分调整的经验是在段落边界处优先切分、对长代码块或长表格单独处理最后再设置块间重叠保留20~50个token的上下文衔接。这套组合策略实测下来基本能覆盖大多数文档类型。4.2 盲目用大型模型向量化硬件成本成倍增加在自研初期很容易把“效果更好”等同于“模型更大”。引入高维模型后索引构建时间、内存占用和查询延迟都会明显上升但小规模知识库上的效果提升却感知不强。经过多轮对比我可以负责任地说在几十万文本块的规模下开源中文向量模型与商用大模型的检索效果差距并不大真正的效果瓶颈往往在切分、重排和文档解析上而非embedding本身。我的建议是采用“分阶段模型策略”MVP阶段用推理资源占用小、速度快的模型等数据规模上来之后再把模型升级到更大规格。同时索引构建和查询阶段可以共用同一个模型减少重复部署。向量维度不必追求最高精度和成本的平衡点才更重要。4.3 只做向量检索忘记关键词兜底方案关键词搜索被很多人误以为过时了但在RAG系统里它其实是很好的“精确匹配兜底”。比如产品型号、订单编号、法律条款这类强标识信息向量检索很难保证精确命中而关键词检索可以做到百分之百匹配。混合检索的自研实现也就多了约一两百行代码效果提升却立竿见影。实现很简单用开源的全文检索引擎建立倒排索引与向量检索并行执行。查询到达后分别从两路拿回候选集做分数融合再进重排阶段。如果前期不想引入重型引擎也可以先基于简洁的内存索引做最简单版本后续再平滑迁移。至少我在实践中从未见过纯向量检索在混合场景下能打赢向量加关键词的组合方案。4.4 Prompt模板越攒越多维护成本失控一开始我会针对不同问题类型写不同的Prompt模板比如“价格类”“操作类”“故障类”各一套。结果模板一变多维护成本增长很快——新增一个文档类型就要同步修改好几个Prompt而且很难判断是哪条Prompt导致回答风格漂移。六款开源产品的做法反而很克制大多数只维护一套核心系统模板把差异化的诉求通过检索结果和额外指令来承载。我后来的做法是只保留一条基准模板规定回答风格、引用格式和拒答策略把业务差异放到数据元信息里让模型根据元信息自行调整。这种设计极大地降低了迭代成本而且效果比多模板更稳定。如果你发现Prompt逻辑越来越复杂通常是数据侧应该负责的语义没有被解析出来而不是Prompt写得不够多。4.5 没有离线评测集就开始调优前方一片模糊RAG系统最难的还不是实现而是“怎么知道改完变好了还是变坏了”。没有评测集一切调优都是凭感觉。这里说的评测集不是几十条手工用例而是把线上真实用户问题沉淀成几百条带标准答案的验证集至少覆盖常见问答、模糊表述、跨文档组合、明显无答案四类情况。在自研蓝图中评测集应该和开发同步建设。每次改动后都跑一遍评测集统计准确率、召回相关性和拒答正确率。手动评一遍几百条数据虽然耗时但在MVP阶段换来的是稳定的可迭代基线。等后续有精力可以把评测流程自动化但前提是先有数据。如果连评测集都没有就不要谈效果优化。5. 拿来即用的自研RAG实施路线从MVP到生产环境5.1 最小可行产品阶段能跑通就是胜利自研RAG的MVP不需要做得大而全我的建议是聚焦一个垂直文档域比如内部员工手册。MVP阶段需要具备的能力是文档导入与文本抽取、段落切分、向量化与存储、关键词索引、混合检索、重排、Prompt生成与回答展示。不需要做权限体系不需要流式输出也不需要多租户隔离。技术栈选择上MVP阶段可以用轻量级方案本地或单机向量库做存储开源文本向量模型做embedding开源全文检索引擎做关键词索引开源重排模型做精排后端API调用大模型做生成。跑通标准是用户上传10份文档后对预置的50个问题至少能做到“大部分直接命中、不会虚构答案”。这一步大约需要一到两周集中开发。5.2 生产环境演进阶段稳定性和权限才是关键MVP验证了效果之后进入生产环境前需要做三件核心增强第一是权限过滤索引中增加权限标签检索阶段先行过滤避免数据越权访问第二是缓存层在查询和检索两个环节分别加缓存高并发场景下能显著降低接口延迟同时节省大模型调用成本第三是异步索引流水线新上传文档进入消息队列处理不阻塞用户操作配合增量更新机制保证回答内容是新版本文档。生产环境的监控体系建议至少包含两类指标检索环节的召回率变化和生成环节的答案采纳率。通过用户反馈逐步修正切分策略和重排模型。做这部分我不建议一次性铺开而是每两个迭代周期集中处理一个薄弱环节。5.3 自研RAG功能清单与优先级分配规划落地时把功能按优先级排出下表就能避免团队陷入局部优化优先级功能模块核心目标建议投入占比P0文档解析与切分保证数据可用20%P0混合检索与重排保证查得准25%P0答案生成与引用保证答得稳20%P1权限过滤与隔离保证数据安全10%P1增量索引与缓存保证体验快10%P2评测集与自动化保证可迭代10%P2运营分析看板保证可观测5%P0部分全部做完已经可以支撑一个内部工具上线。P1和P2部分则根据实际使用反馈决定优先顺序。多数场景下检索质量和生成稳定性比权限隔离更先暴露问题所以建议先把P0打磨透。我个人在自研过程中的体会是开源RAG产品最大的价值不是拿来直接部署而是它们用各自的方式验证了“五段式链路”的正确性。拆六个产品的过程相当于让十几个架构理念在同一个表格里互相碰撞。与其纠结于“要不要从零写向量检索”这种问题不如承认通用组件的作用——自研的核心是数据接入规则、切分策略、检索融合方式和生成约束这四件事其他环节用成熟组件拼装即可。最后再分享一个小技巧每改一次切分策略或者检索逻辑不要只看一两个样例而是立刻跑评测集里的几十道经典问题观察整体正确率的增量。这个方法能让你在前期每一步都走得很扎实。按照上面这条路线走哪怕团队只有两三个人也能在几周内交付一套内部可用、后续可持续演进的RAG系统。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
