1. 为什么我要花两周时间逆向六款开源RAG过去大半年我一直在带团队做企业级知识库问答系统。说实话自研RAG这件事一开始我们信心满满——不就是文档切片、向量化、检索、拼Prompt、丢给大模型生成吗真动手才发现每一个环节都有无数个“看起来能跑但一上生产就崩”的坑。最典型的一次客户上传了三百多份PDF合同检索出来的片段要么是页眉页脚要么是跨页断句回答质量惨不忍睹。痛定思痛我决定换个思路与其闭门造车不如把市面上成熟的开源RAG项目扒一遍。我选了六款有代表性的产品——有主打轻量级快速上手的有强调多路召回和重排序的有做知识图谱融合的也有专注文档解析精度的。前后花了将近两周把它们的架构图、核心模块、关键参数、甚至源码里的注释都翻了个遍。这个过程给我的冲击很大。很多我们团队争论不休的设计问题开源项目早就给出了答案而且是用一种极其务实的方式。比如“切片到底按字符还是按语义”比如“检索要不要加重排序”比如“多轮对话里历史信息怎么处理”。这些问题的答案不是拍脑袋想出来的而是被真实场景反复打磨出来的。这篇文章就是我把这六款产品的逆向笔记整理成一套可复用的自研RAG蓝图。我会讲清楚每个设计决策背后的“为什么”也会给出可以直接抄作业的参数和步骤。如果你正在做或者准备做RAG知识库不管是用现成框架还是纯自研这篇内容应该能帮你省下至少一个月的试错时间。2. 六款开源RAG的架构拆解与共性提炼2.1 我选的六款产品及选择理由先说明一下我选的样本。为了避免广告嫌疑我用代号来指代它们A项目主打极简部署适合快速验证B项目以多路召回和重排序见长检索质量很高C项目深度集成了知识图谱走的是结构化非结构化融合路线D项目在文档解析上下了大功夫表格和图片处理很细E项目强调智能体编排支持复杂任务分解F项目则是老牌框架生态最全但架构也最重。选这六个是因为它们基本覆盖了RAG系统的所有关键维度检索策略、文档处理、知识组织、任务编排、部署复杂度。而且它们都是活跃项目代码质量有保障不是那种跑个demo就废弃的玩具。我逆向的方式很简单先跑通官方demo然后读核心模块源码重点看数据流怎么走、参数怎么设、异常怎么处理。遇到看不懂的设计就去翻issue和PR往往能找到作者的真实意图。这个过程比读文档有用得多因为文档只告诉你“怎么用”源码才告诉你“为什么这么设计”。2.2 所有RAG都绕不开的四层架构扒完六个项目我发现一个很有意思的现象不管它们表面差异多大底层都逃不出四层架构。这四层分别是文档处理层、索引存储层、检索召回层、生成编排层。文档处理层负责把各种格式的原始文件变成干净的文本块。这层看起来简单实际上最考验工程能力。PDF里的表格、扫描件的OCR、Markdown的层级结构、HTML的噪声过滤每一个都是坑。B项目和D项目在这层投入最多D项目甚至专门训练了一个版面分析模型来识别表格和段落。索引存储层决定用什么方式组织数据。最常见的是向量索引但C项目额外加了图索引把实体和关系抽出来存成知识图谱。E项目则用了混合索引向量和关键词并存。这层的选择直接决定了检索的上限。检索召回层是RAG的核心。A项目只用单路向量检索简单但召回率有限。B项目用了向量关键词同义词扩展三路召回再用交叉编码器重排序效果提升非常明显。我实测下来多路召回重排序的组合在专业领域问答上比单路向量检索的准确率高出至少二十个百分点。生成编排层负责把检索结果和用户问题拼成Prompt调用大模型生成答案。这层的差异主要体现在Prompt模板设计、历史对话管理、以及是否支持智能体编排。E项目在这层最复杂支持多步推理和工具调用。2.3 从差异中提炼出的五个关键设计决策六款产品在具体实现上各有取舍但归结起来有五个设计决策是自研RAG必须想清楚的。第一个决策切片策略。是按固定字符数切还是按语义段落切还是按文档结构切A项目用固定字符数加重叠窗口简单粗暴但够用。B项目用语义分割模型效果好但成本高。我的建议是混合策略先按文档结构切大块再在块内按语义切小块最后加重叠窗口兜底。第二个决策检索方式。单路向量检索够不够如果你的知识库是通用领域够用。但如果是法律、医疗、金融这种专业领域单路向量检索的召回率会明显不够。B项目的多路召回方案值得借鉴向量检索负责语义相似关键词检索负责精确匹配同义词扩展负责覆盖变体表达。第三个决策要不要重排序。我的答案是只要你的检索结果超过五条就应该加重排序。重排序模型可以对检索结果做精细打分把真正相关的片段排到前面。B项目用的交叉编码器重排序延迟增加不多但效果提升显著。第四个决策知识组织方式。纯向量索引适合非结构化文本但如果你有大量结构化数据或者实体关系知识图谱能大幅提升检索精度。C项目的做法是先用向量检索找到相关片段再从图谱里拉出关联实体和关系一起送给大模型。这个思路在需要推理的场景下特别有用。第五个决策编排复杂度。简单的RAG就是“检索-拼接-生成”一条线。但复杂场景需要多步推理、工具调用、条件分支。E项目的智能体编排支持任务分解比如先判断问题类型再决定走哪条检索路径。这个设计在客服和数据分析场景下很有价值。3. 自研RAG蓝图的五个核心模块实现3.1 文档处理模块从原始文件到干净文本块文档处理是RAG的地基。地基没打好后面检索再花哨也是白搭。我逆向完D项目之后把文档处理拆成了四个步骤格式解析、内容清洗、结构识别、智能切片。格式解析这块PDF是最麻烦的。很多PDF是扫描件需要OCR有些PDF有复杂的表格和图表需要版面分析。D项目的做法是先用PyMuPDF提取文本和坐标信息再用版面分析模型识别表格区域最后用OCR补全扫描件内容。我实测下来这套组合拳对合同和报告类文档的解析准确率能到百分之九十以上。内容清洗主要是去噪声。页眉页脚、页码、水印、乱码这些都会污染检索结果。我的经验是不要用正则表达式硬匹配而是用位置信息来判断。比如页眉通常在页面顶部百分之十的区域页码通常在底部或角落。按位置过滤比按内容过滤准确得多。结构识别是很多人忽略的一步。Markdown的标题层级、PDF的章节编号、Word的样式信息这些都是宝贵的结构信号。B项目会把标题和正文分开处理标题作为元数据附加到每个文本块上。这样检索的时候不仅能匹配内容还能匹配章节标题召回精度提升很明显。智能切片是最后一步也是最关键的一步。我的策略是三层切片第一层按文档结构切比如按章节切第二层按语义切用句子边界检测把长段落切成语义完整的块第三层加重叠窗口防止跨块信息丢失。切片长度我建议控制在三百到五百个token之间重叠窗口设百分之十到百分之十五。这个参数不是拍脑袋定的是我对比了六款产品的默认值再结合自己实测效果调出来的。注意切片长度不是越短越好。太短会丢失上下文太长会引入噪声。三百到五百token是一个比较平衡的区间但具体还要看你的文档类型和问题类型。3.2 索引存储模块向量、关键词与图谱的混合方案索引存储决定了检索的上限。我一开始只用了向量索引后来发现两个问题一是专业术语的精确匹配不行比如“民法典第某某条”这种查询向量检索经常召回不相关的片段二是实体关系查询不行比如“某公司的子公司有哪些”向量检索根本处理不了。B项目的混合索引方案给了我很大启发。它的做法是同时建三套索引向量索引、关键词索引、同义词索引。检索的时候三路并行最后融合排序。我照着这个思路在自己的系统里加了关键词索引和同义词索引召回率提升了将近三十个百分点。向量索引的选型上我试过FAISS、Milvus和Qdrant。FAISS最轻量适合单机部署Milvus功能最全但运维成本高Qdrant在过滤查询上性能很好。如果你的数据量在百万级以下FAISS加一个持久化层就够了。如果上千万级建议直接上Milvus或者Qdrant。关键词索引我用的是Elasticsearch主要是看中它的分词和同义词功能。中文分词用IK分词器同义词表可以自己维护。这里有个小技巧把专业术语的同义词表单独维护比如“人工智能”和“AI”互为同义词“心肌梗死”和“心梗”互为同义词。这个表不需要很大但能显著提升召回率。图谱索引是C项目的核心创新。它用大模型从文档里抽取实体和关系存成图数据库。检索的时候先用向量检索找到相关片段再从图谱里拉出关联实体一起送给大模型。这个方案在需要多跳推理的场景下特别有用比如“某公司的CEO毕业于哪所大学”这种问题纯向量检索很难处理但图谱可以沿着“公司-CEO-大学”这条路径找到答案。提示图谱索引的构建成本很高不建议一开始就上。等你的向量检索和关键词检索跑通了再考虑加图谱。3.3 检索召回模块多路召回与重排序的工程实现检索召回是RAG最核心的模块。我逆向完B项目之后把检索流程拆成了四步查询理解、多路召回、结果融合、重排序。查询理解是第一步也是最容易被忽略的一步。用户的问题往往很模糊比如“那个合同里关于违约金的条款”。直接拿这句话去检索效果肯定不好。B项目的做法是先用大模型把查询改写成多个子查询比如“合同 违约金 条款”、“违约金 计算方式”、“违约金 上限”。每个子查询单独检索最后合并结果。这个改写步骤看起来简单但效果提升非常明显。多路召回是第二步。我目前用了三路向量召回、关键词召回、同义词召回。向量召回用嵌入模型把查询和文档块都转成向量算余弦相似度。关键词召回用BM25算法适合精确匹配。同义词召回用扩展后的查询词去匹配覆盖变体表达。三路召回各取前二十条合并后去重。结果融合是第三步。不同召回路径的分数不能直接比较需要归一化。我的做法是用倒数排名融合就是把每个结果的排名取倒数再相加。这个算法简单但有效不需要调参。重排序是第四步。我用的是一个轻量级的交叉编码器模型对融合后的结果做精细打分。重排序的延迟大概在几十毫秒但效果提升很明显。我实测下来加了重排序之后Top3的准确率从百分之六十五提升到了百分之八十二。这里有个坑要注意重排序模型的选择很关键。有些模型对中文支持不好有些模型太大导致延迟太高。我试了好几个最后选了一个六层的小模型效果和速度比较平衡。如果你不想自己部署模型也可以用大模型来做重排序但成本会高一些。3.4 生成编排模块Prompt设计与多轮对话管理生成编排是RAG的最后一公里。检索做得再好Prompt写得烂答案照样不行。我逆向完几个项目之后总结了一套Prompt模板设计原则。第一条原则明确角色和任务。不要只说“根据以下内容回答问题”要说“你是一个专业的知识库助手请根据提供的参考资料回答用户问题。如果参考资料中没有相关信息请明确告知用户”。这个角色设定能显著减少大模型的幻觉。第二条原则结构化输入。把检索结果按相关度排序每条带上来源和页码。这样大模型在生成答案时可以引用来源增加可信度。我的做法是在每条参考资料前加编号Prompt里要求大模型在答案中标注引用编号。第三条原则控制上下文长度。检索结果不是越多越好太多会稀释关键信息还会增加成本。我的经验是Top5到Top8比较合适。如果检索结果太长可以先做摘要再送给大模型。多轮对话管理是另一个难点。用户的问题往往依赖历史对话比如“那它的违约金是多少”。如果只拿这一句去检索肯定找不到。我的做法是维护一个对话历史窗口把最近三轮的问答拼成上下文再用大模型改写当前问题。改写后的查询包含了历史信息检索准确率会高很多。E项目的智能体编排给了我另一个思路把复杂问题拆成多个子任务每个子任务单独检索和生成最后汇总。比如“对比A合同和B合同的违约金条款”可以先分别检索两个合同的违约金条款再让大模型做对比。这个方案在复杂分析场景下很有价值但实现复杂度也高建议先把基础RAG跑通再考虑。3.5 评估与迭代模块怎么知道你的RAG好不好很多人做RAG做完就上线从来不评估。这是大忌。没有评估你根本不知道系统哪里有问题更不知道优化有没有效果。我参考了几个开源项目的评估方案总结了一套自己的评估流程。核心是三个指标召回率、准确率、答案质量。召回率衡量的是“该找的有没有找到”。构造一批测试问题每个问题标注应该召回哪些文档块。然后看系统实际召回的结果里有多少是标注的。这个指标反映检索模块的能力。准确率衡量的是“找到的对不对”。看Top3的结果里有多少是真正相关的。这个指标反映重排序模块的能力。答案质量衡量的是“生成的答案好不好”。这个比较主观可以用大模型来打分也可以人工评估。我通常用大模型对答案做三个维度的打分相关性、完整性、准确性。每个维度一到五分取平均。评估数据集怎么来我的做法是从真实用户问题里采样然后人工标注。一开始不用很多一百条左右就能看出问题。随着系统迭代逐步扩充到五百条以上。迭代的方向也很重要。如果召回率低优先优化切片策略和召回路径。如果准确率低优先优化重排序模型。如果答案质量低优先优化Prompt模板。不要同时改多个模块否则你根本不知道是哪个改动起了作用。4. 实操落地从零搭建一套可复用的RAG系统4.1 环境准备与技术栈选型说了这么多设计思路接下来讲具体怎么落地。我先列一下我用的技术栈你可以根据自己情况调整。文档处理用Python核心库是PyMuPDF和pdfplumber。PyMuPDF速度快适合提取文本和坐标pdfplumber对表格支持好适合处理复杂版面。OCR用PaddleOCR中文识别效果不错而且可以本地部署。向量化用BGE-M3这个模型支持多语言而且同时输出稠密向量和稀疏向量一路两用。向量数据库用Qdrant单机部署简单过滤查询性能好。关键词索引用Elasticsearch配IK分词器。重排序模型用BGE-Reranker-Base六层的小模型延迟低效果够用。大模型用Qwen2.5-14B本地部署用vLLM加速。如果不想本地部署也可以用API但成本会高一些。编排框架我建议先用LangChain或者LlamaIndex快速验证等跑通了再考虑自研。这两个框架生态全文档多遇到问题容易找到答案。但要注意框架抽象层多性能调优空间有限。如果对延迟和成本敏感最终还是要自研核心模块。注意不要一上来就追求全自研。先用框架跑通流程验证效果再逐步替换关键模块。这样风险最低迭代最快。4.2 文档入库流程的完整实现文档入库是第一步。我写了一个Pipeline分四个阶段解析、清洗、切片、索引。解析阶段先判断文件类型。PDF用PyMuPDF提取文本和坐标如果是扫描件就调OCR。Word用python-docx提取段落和样式。Markdown直接读文本保留标题层级。HTML用BeautifulSoup去标签保留正文。清洗阶段按位置过滤页眉页脚。我的做法是统计每页顶部和底部区域的文本出现频率出现频率高的就是页眉页脚。这个统计方法比硬编码位置更鲁棒能适应不同版式的文档。切片阶段先按文档结构切大块。比如Markdown按标题层级切PDF按章节编号切。然后在每个大块内用句子边界检测切小块。句子边界检测我用的是正则加规则中文按句号、问号、感叹号切英文按句点切。最后加百分之十的重叠窗口。索引阶段每个文本块同时写入向量索引和关键词索引。向量索引用BGE-M3生成稠密向量关键词索引用IK分词后写入Elasticsearch。文本块的元数据包括来源文件、页码、章节标题这些在检索时可以用来过滤和展示。整个Pipeline我封装成了一个类支持增量更新。新文档进来只处理新增部分不用全量重建索引。这个设计在实际使用中很重要因为企业知识库是持续增长的全量重建成本太高。4.3 检索服务的性能调优记录检索服务的性能调优我踩了不少坑。最大的坑是延迟。一开始三路召回加重排序端到端延迟到了两秒多用户体验很差。我先优化了向量检索。Qdrant默认用HNSW索引我调大了ef参数召回率上去了但延迟也上去了。后来发现把向量维度从1024降到768召回率只降了一个百分点但延迟降了将近一半。这个取舍很划算。然后优化了关键词检索。Elasticsearch默认返回全部字段我改成只返回需要的字段减少了网络传输。另外把分片数从默认的五片改成一片因为我的数据量不大多分片反而增加协调开销。重排序是延迟大头。我试了好几个模型最后选了一个六层的小模型延迟从八百毫秒降到了两百毫秒。另外把重排序的候选数从二十条降到十条延迟又降了一半效果几乎没影响。最后是并发优化。检索服务用FastAPI部署开了四个worker。向量检索和关键词检索并行执行用asyncio.gather合并结果。这样端到端延迟稳定在五百毫秒以内用户体验可以接受。提示性能调优要先测量再优化。用火焰图找出瓶颈不要凭感觉猜。很多时候瓶颈不在你以为的地方。4.4 生成服务的Prompt模板与参数配置生成服务的Prompt模板我改了十几版才稳定下来。核心结构是这样的系统角色设定、参考资料列表、用户问题、回答要求。系统角色设定要具体。我用的模板是“你是一个专业的知识库助手负责根据提供的参考资料回答用户问题。你的回答必须基于参考资料不得编造信息。如果参考资料中没有相关信息请明确告知用户‘根据现有资料无法回答该问题’。”参考资料列表要结构化。每条资料带编号、来源、页码。我要求大模型在答案中标注引用编号比如“根据资料[1]违约金上限为合同金额的百分之三十”。这样用户可以追溯答案来源增加可信度。回答要求要明确。我要求大模型先给出直接答案再补充细节。如果问题涉及多个方面分点回答。如果参考资料之间有冲突指出冲突并说明。参数配置上温度设零点一减少随机性。最大生成长度设一千token避免答案过长。Top_p设零点九平衡多样性和准确性。这些参数不是固定的要根据实际效果调整。多轮对话的处理我维护了一个历史窗口把最近三轮的问答拼成上下文。当前问题先用大模型改写把指代消解掉。比如“那它的违约金是多少”改写成“A合同的违约金是多少”。改写后的查询再去检索准确率高很多。5. 踩坑实录与常见问题排查5.1 文档解析阶段的五个典型坑第一个坑PDF表格跨页。很多合同PDF的表格跨页PyMuPDF提取出来是断开的。我的解决方案是用pdfplumber的表格检测功能先识别表格区域再合并跨页表格。如果表格太复杂就调OCR做版面分析。第二个坑扫描件OCR乱码。PaddleOCR默认模型对印刷体效果好但对手写体或者低质量扫描件效果差。我的做法是先做图像预处理二值化、去噪、纠偏再送OCR。如果还是不行就换更专业的OCR服务。第三个坑Markdown层级丢失。有些Markdown文件用多个井号表示标题层级但解析时容易丢失。我的做法是保留原始文本在切片时用正则识别标题行把标题作为元数据附加到后续文本块上。第四个坑HTML噪声太多。网页抓下来的HTML包含大量导航、广告、脚本。BeautifulSoup默认提取所有文本噪声很多。我的做法是先用Readability算法提取正文再用规则过滤剩余噪声。第五个坑编码问题。中文文档经常遇到GBK和UTF-8混用解析出来是乱码。我的做法是先用chardet检测编码再统一转成UTF-8。如果检测不准就尝试多种编码选乱码最少的那种。5.2 检索效果差的排查思路检索效果差先别急着换模型。按这个顺序排查切片是否合理、查询是否改写、召回路径是否覆盖、重排序是否有效。切片问题最常见。如果切片太长噪声多太短上下文丢失。我的排查方法是随机抽一批检索结果人工看切片边界是否合理。如果切片在句子中间断开说明切片策略有问题。查询改写问题也很常见。用户问题往往很模糊直接检索效果差。我的排查方法是把改写前后的查询都跑一遍对比召回结果。如果改写后召回率明显提升说明改写有效。召回路径覆盖问题要看你的查询类型。如果查询包含专业术语关键词召回很重要。如果查询是自然语言描述向量召回更重要。如果查询包含变体表达同义词召回不能少。我的做法是分别统计每路召回的命中率看哪路拖了后腿。重排序问题要看重排序模型的训练数据是否匹配你的领域。通用重排序模型在专业领域可能效果不好。我的做法是用领域数据微调重排序模型或者直接用大模型做重排序。5.3 生成质量不稳定的归因与解决生成质量不稳定通常有三个原因检索结果质量差、Prompt模板不合理、大模型本身能力不足。检索结果质量差是最常见的原因。如果检索出来的片段本身就不相关大模型再强也生成不出好答案。我的做法是先评估检索质量如果召回率和准确率都低优先优化检索模块。Prompt模板不合理是第二个原因。如果Prompt没有明确角色和任务大模型容易自由发挥。如果Prompt没有要求引用来源大模型容易编造信息。我的做法是反复迭代Prompt模板用一批测试问题验证效果。大模型能力不足是第三个原因。如果检索结果很好Prompt也很合理但答案还是不行那可能是大模型本身能力不够。我的做法是换更大的模型或者用领域数据微调。如果成本不允许就降低预期把答案质量要求从“完美”降到“可用”。5.4 常见问题速查表问题现象可能原因排查方法解决方案检索结果不相关切片太长或太短人工检查切片边界调整切片长度和重叠窗口专业术语召回差缺少关键词索引对比向量和关键词召回结果增加关键词索引和同义词表答案编造信息Prompt未要求引用来源检查Prompt模板要求大模型标注引用编号多轮对话指代错误未做查询改写对比改写前后检索结果用大模型改写查询消解指代端到端延迟高重排序模型太大用火焰图找瓶颈换小模型或减少候选数表格内容检索不到表格解析失败检查表格提取结果用版面分析模型识别表格扫描件OCR乱码图像质量差检查OCR输入图像图像预处理或换OCR服务答案太长或太短生成长度参数不合理检查max_tokens设置调整生成长度参数6. 从开源RAG学到的架构设计经验6.1 模块解耦比端到端优化更重要逆向完六款产品我最大的体会是模块解耦比端到端优化更重要。很多自研RAG一开始就追求端到端效果把所有模块揉在一起结果出了问题根本不知道是哪个环节的锅。开源项目的做法很聪明每个模块独立开发、独立测试、独立优化。文档处理模块只管把文件变成文本块检索模块只管把查询变成结果列表生成模块只管把结果变成答案。模块之间用清晰的接口通信互不干扰。这个设计的好处是你可以单独优化每个模块而不用担心影响其他模块。比如你觉得检索效果不好可以单独换重排序模型不用动文档处理和生成模块。这种灵活性在长期迭代中非常关键。我的建议是自研RAG一开始就要做好模块划分。每个模块定义好输入输出接口用配置文件管理参数。这样即使你后面换技术栈也不用重写整个系统。6.2 参数配置化是长期迭代的基础第二个体会是参数配置化是长期迭代的基础。我一开始把切片长度、召回数量、重排序阈值这些参数硬编码在代码里每次调整都要改代码、重新部署。后来改成配置文件调整参数只需要改配置、重启服务效率高了很多。开源项目在这方面做得很好。B项目的所有参数都在一个YAML文件里包括切片长度、召回路径权重、重排序模型路径。C项目的图谱构建参数也是配置化的包括实体类型、关系类型、抽取模型。我的做法是建一个config目录按模块分配置文件。文档处理配置切片长度和重叠窗口检索配置召回路径和权重生成配置Prompt模板和模型参数。所有配置支持环境变量覆盖方便不同环境部署。提示配置化不是万能的。有些参数需要动态调整比如根据查询类型选择不同的召回策略。这种逻辑还是要写在代码里不能全靠配置。6.3 评估驱动开发先建测试集再优化第三个体会是评估驱动开发。我一开始做RAG凭感觉优化今天调切片长度明天换重排序模型效果时好时坏根本不知道哪个改动起了作用。后来我学乖了先建测试集。从真实用户问题里采样一百条人工标注每个问题的标准答案和应该召回的文档块。然后每次优化都跑一遍测试集看召回率、准确率、答案质量的变化。只有指标提升的改动才保留指标下降的改动就回滚。这个做法看起来慢实际上快。因为你知道每个改动的效果不会在无效的方向上浪费时间。开源项目都有完整的评估脚本B项目甚至提供了评估数据集和评估指标的计算代码。这些都可以直接拿来用。测试集要持续扩充。随着系统上线收集真实用户问题人工标注后加入测试集。测试集越大评估越可靠。我的目标是最终达到五百条以上覆盖各种查询类型和边界情况。6.4 关于自研与开源的取舍建议最后一个体会是关于自研与开源的取舍。我的建议是核心模块自研外围模块用开源。什么是核心模块检索和生成是核心。检索决定了你能不能找到正确的信息生成决定了你能不能给出好的答案。这两个模块直接决定用户体验值得投入精力自研。什么是外围模块文档解析、向量数据库、关键词索引是外围。这些模块有成熟的开源方案自己造轮子性价比不高。用开源的把精力省下来优化核心模块。但要注意用开源不等于照搬。开源方案默认参数往往不适合你的场景需要根据实际情况调整。比如切片长度开源项目默认三百token但你的文档如果是法律合同可能需要五百token。这些调整需要你对业务有深入理解。另外开源方案也有坑。有些项目文档不全有些项目社区不活跃遇到问题没人解答。选开源项目时要看star数、最近提交时间、issue响应速度。这些指标比功能列表更能反映项目的可靠性。我个人在实际操作中的体会是自研RAG最难的不是技术而是对业务的理解。你知道你的用户会问什么问题你知道你的文档有什么特点你知道什么样的答案算好答案。这些理解是任何开源项目都给不了你的。开源项目给你的是工程实现的参考业务理解还得靠自己。