如果你是按顺序学过来的这一篇应该正好是你从“会用大模型”跨到“会做大模型应用”的一篇。前两篇讲的是调用和提示词工程本质上还是在跟模型对话到了 RAG 和 LangChain 这你开始真正搭一套能落地的系统了。我先把 RAG 用一句话说清楚它等于给大模型装了一个“先查资料再回答”的外挂。而 LangChain 则是把这些“查资料”“拼提示词”“调模型”“整理答案”的动作封装成标准积木的工具框架。这篇笔记我按自己从零跑通一版 RAG 问答系统的真实顺序来写适合刚学完大模型基础、正准备做知识库问答或文档问答的开发者参考。1. RAG到底解决了什么问题1.1 大模型的三个死穴先说点实在的你光有一个很强的大模型是不够用的。我实际做项目时发现直接拿模型去回答业务问题几乎必然撞上三个墙。第一面墙是时效性。模型训练数据是有截止日期的你问它昨天的新闻、最新的产品政策它只能靠猜。第二面墙是幻觉这个最头疼模型回答得越流畅越容易把不存在的资料说得跟真的一样你在业务场景里完全不敢直接信。第三面墙是私域知识公司内部的制度、某个项目的历史决策、某个系统的使用手册这些内容根本不在模型的训练数据里你问它它只能给你一个“标准但没用”的答案。这三个问题放在一起你会发现单纯换一个更强的大模型也解决不了。比如你换一个参数更大的模型它的时效性还是停在训练截止日它还是不知道你们公司内部的流程甚至因为表达能力更强幻觉说得更理直气壮。这也就是为什么大模型落地不能只靠“模型”本身必须配合外部机制。RAG 的价值恰恰在这它不试图修改模型而是把模型当成一个“会阅读的生成器”。你先从外部知识库里把相关资料检索出来再把这些资料拼进提示词里让模型基于这些资料作答。答案有出处、知识能更新、私域内容也能覆盖三个死穴被同一个方案按住了。1.2 为什么先学RAG而不是急着微调很多人在这个岔路口会纠结到底应该做 RAG还是微调一个专属模型我用一张对比表把关键差异捋过一遍后心里的答案就清楚了。对比维度RAG微调新增知识直接往知识库丢文档即可即时生效需要准备训练数据重新训练周期长更新成本低换文档就行高每次知识变化都要重新调幻觉问题相对可控答案可追溯到检索片段仍然存在模型照样可能编硬件成本普通服务器加向量库即可通常需要专门的训练资源可解释性高能看到模型用了哪段资料低模型内部不可观测适用场景知识问答、文档分析、实时信息查询指令遵循、语气风格、特定任务能力我并不是说微调没用。如果你真的需要改变模型的行为方式比如让它用特定文风写周报、学会某种固定输出格式微调是更合适的。但如果你只是想“让模型知道一些它本来不知道的事情”RAG 是明显更划算的选择也是大多数人第一个应该掌握的生产级方案。从学习路线上说RAG 的每一项技术都是独立的文本处理、向量检索、提示词工程。即使你以后去学微调这些知识也不浪费。我个人的建议是先用 RAG 把完整链路跑通再根据实际瓶颈决定要不要上微调这个顺序最不劝退也最容易出成果。2. 拆解一条RAG流水线的五个核心环节2.1 文档加载第一步就容易被低估很多人以为 RAG 的第一步是“把 PDF 丢进去”。真做起来你会发现文档加载才是最琐碎但也最影响后面所有环节的那一步。你需要处理的问题包括PDF 是扫描件还是文字版扫描件要不要做 OCR表格要不要保留结构Word 文档里的批注和页眉页脚会不会污染正文网页抓下来的内容里导航、广告、版权声明这些噪音怎么过滤这些如果不在加载阶段处理干净后面垃圾进垃圾出检索出来的片段可能就是一堆乱码。我实际踩过的例子有一份产品手册正文里每个句子后面都跟着页眉信息切分完之后大量片段都包含“某公司内部资料 第X页”这种重复噪音检索时这些噪音还会干扰向量相似度计算。后来我在加载阶段加了清洗逻辑把页眉页脚、固定文案整体过滤掉整体检索质量立马上了一个台阶。2.2 文本切分chunk大小决定检索下限文档加载完下一步是切分。这一步决定的是“检索的最小单元”是什么。如果你把整本手册切成 500 个字符一段那模型每次回答只能看到一小段上下文信息可能不完整如果你切成 2000 个字符一段虽然信息全但塞进提示词里很容易超长而且一段里混了多个主题检索召回后噪声也大。切分要考虑的其实不是单纯的字数而是“语义完整性”。最好的切分策略是按文档结构切先按标题层级分块再对过长的块做二次切分。LangChain 里提供了按字符、按 token、按标题递归等多种切分器我常用的思路是标题优先正文里用重叠窗口让相邻片段保留部分重复内容避免一个完整句子或段落被拦腰截断。chunk 大小的具体数值没有标准答案。我做过一批对比测试领域是产品说明书最后发现 400-800 字左右、重叠 50-100 字的组合效果最好既能保证每段有完整含义又不至于让提示词爆炸。但换一个领域这个值可能完全不同所以一定要拿你自己的文档做实验不要直接抄网上的参数。2.3 向量化Embedding模型的选择逻辑切分完的文本片段要变成计算机能算“相似度”的东西这就是向量化。所谓 embedding就是把一段文字映射成一串数字语义相近的文字数字也相近。选择 embedding 模型时我建议关注三个点。一是维度维度越高能承载的信息越丰富但存储和计算成本也越高。二是最大输入长度如果你的文本片段超过模型能处理的上限就必须截断截断就意味着丢信息这又反过来影响切分策略。三是语言适配性如果你的文档是中文为主尽量选择在中文语料上表现好的模型用英文模型处理中文时相似度计算经常会出现“明明意思一样但分数很低”的情况。这里要特别提醒一个新手容易忽略的点你去索引文档和去查询问题必须用同一个 embedding 模型并且保持同一套参数。如果你换了模型旧向量全部要重新生成否则新旧向量之间没有可比性检索结果会一塌糊涂。2.4 向量存储与检索召回质量才是命门向量化的结果会存进向量数据库它干两件事一是把向量按索引结构存起来二是给你提供相似度查询接口。检索这一步是整个 RAG 的命门。如果检索召回的内容不对后面生成环节再努力也白搭。而检索质量并不只取决于向量数据库本身更取决于你之前几步做得怎么样文档清洗是否干净、切分是否合理、embedding 是否契合领域。我刚开始跑通 RAG 时检索出来的 top5 片段经常只有一两个是相关的当时我还以为是向量数据库不好后来逐一排查才发现问题在切分有些片段太短含义不完整有些片段是目录里的标题堆叠根本没有有效信息。清洗和切分调整之后同样的数据库召回质量明显改善。这说明检索是个系统问题不要一上来就怪某一个组件。2.5 生成把资料变成有依据的答案检索到相关资料后最后一个环节是生成。做法是把检索到的片段拼进提示词明确告诉模型“请根据以上资料回答如果资料里没有直接说不知道”。这一步的原理不难但有一个容易被忽略的点提示词的约束力度。如果你只说“参考以下资料”模型很可能还是会自由发挥把资料当背景板然后继续用自己的知识作答答案看着合理实际根本没依据。我通常会在提示词里写清楚“只允许使用资料中的信息资料中没有的内容必须坦白说明”还要在最后加一道“召回内容不够怎么办”的兜底逻辑比如抛出明确话术而不是让模型硬编一个答案。生成环节还有一个细节是来源标注就是把命中的文档名、章节、页码随答案一起返回。这解决了 RAG 可解释性的问题用户在系统里能看到“答案出自哪一份文档的哪一段”信任度会高很多也方便后续排查问题。3. 用LangChain组装一套可跑的RAG问答系统3.1 先把LangChain里的几个关键概念对齐LangChain 刚接触时容易觉得概念很多但只要跟前面的 RAG 流程对照起来其实一一对应。文档加载器负责导入文件文本切分器负责切块向量存储负责存和查向量检索器是向量存储的查询封装最后链条把上面所有东西串起来同一个链里还可以自由加入提示词模板和模型。我建议不要一上来就背 API而是先建立这个映射关系你已有的数据对应哪个组件你要做的检索对应哪个组件你要问模型的话对应哪个模板。概念先对齐后面写代码就是填空。LangChain 另一个值得利用的特点是它的组件抽象。你今天用的是某款开源向量库做存储下次想换成另一个向量库只需要改一小段初始化代码其余链路不用动。这种解耦在项目早期特别重要因为向量数据库的选型很可能在后期调整抽象好了切换成本就低。3.2 环境准备与安装在开始之前你需要准备好几样东西Python 环境、LangChain 库、一个向量存储组件、一个嵌入模型接口以及一个可调用的大模型接口。环境这块我建议用虚拟环境别直接装进系统 Python因为 LangChain 的依赖比较多不同版本之间偶尔会有冲突虚拟环境能让你随便折腾。安装完成之后配置好各个 API 的密钥或本地服务的地址。注意密钥别硬编码在业务代码里测试时可以用环境变量方便后面换配置。我最初把密钥写在脚本里后来重构时改了半天这个习惯早点养好能省很多事。3.3 落地代码从文档到问答一条链下面这一段是我整理过的最小可用实现逻辑顺序和前面的流程一一对应。这里我只用伪代码和关键步骤做演示具体模型和向量库用你自己的配置替换即可。# 1. 加载文档 loader YourDocumentLoader(你的文档路径) documents loader.load() # 2. 切分文本 splitter YourTextSplitter( chunk_size500, chunk_overlap50, ) chunks splitter.split_documents(documents) # 3. 生成向量并写入向量库 vector_store YourVectorStore.from_documents( chunks, embeddingYourEmbeddingModel(), ) # 4. 创建检索器 retriever vector_store.as_retriever( search_kwargs{k: 4} ) # 5. 定义提示词模板 prompt_template 你是一个企业内部知识库助手。请只使用下面提供的资料回答问题。 如果资料中没有相关信息请直接回答“资料库中未找到相关内容”不要编造答案。 资料 {context} 问题{question} # 6. 组装问答链 chain RetrievalQAChain( retrieverretriever, llmYourLLM(), prompt_templateprompt_template, ) # 7. 问一个问题 result chain.run(公司年假制度是怎么规定的) print(result)这段代码跑通之后你其实已经拥有一个最小可用的 RAG 问答系统了。我第一次跑通时是拿一份员工手册试的问了一个细则问题答案准确且带出了出处当时还是觉得挺神奇的。3.4 参数是怎么调出来的代码跑通只是开始真正要花时间的是调参。我总结几个最影响体验的参数供你参考。先说 top_k也就是每次检索返回多少个片段。太少了信息不够太多了噪声多且费 token我一般从 3-5 开始试。如果问题通常需要跨多段资料才能回答再往上加。然后是 temperature这是大模型生成的随机性参数。做知识问答时我建议调低尽量让模型忠实复述资料而不是发挥创造。0 到 0.3 之间比较稳妥太高容易编。最后是切分相关参数就是前面说的 chunk_size 和 overlap。这两个参数对检索质量影响最大也是最值得做对比测试的。我的方法是准备 5-10 个代表性业务问题分别用不同切分参数跑一遍看检索回来的片段能不能覆盖问题答案通过这种办法判断参数合不合适而不是凭感觉调。4. 我踩过的坑常见问题与排查手记4.1 检索召回了一堆无关内容这是最常见的故障现象。你以为向量检索很聪明它对语义理解其实并没有那么深。比如你问“员工怎么请年假”检索出来的可能是“年假制度的制定背景”这种主题相似但没有操作细则的内容看起来相关实际不能回答问题。我排查这类问题时第一件事是去看召回片段本身。把检索器单独拿出来不接生成环节直接打印召回内容和相似度分数。这时候一眼就能看出问题出在谁的头上如果召回片段本身就跑偏了那问题出在切分或 embedding 选择如果召回片段是对的但答案不对那问题出在生成环节要看提示词有没有约束住模型。4.2 外部知识库文档“查不到”另一个让人崩溃的问题是明显存在于文档里的内容系统却检索不到。这类问题大多出在切分上。比如一个表格被切成了碎片每一片都缺了表头单独看根本不知道在说什么又比如一个完整的流程被切成了几段每段都不完整。解决办法是给切分器加结构感知能力尽量按标题、章节来切而不是硬按字符数切。还有一种做法是给每个片段保留元数据比如来源文件名、章节标题、页码检索时优先显示这些信息至少能让你定位出问题片段。我处理过的一个典型案例某个制度的“适用范围”写在文档末尾的附录里因为切分策略把附录单独切成了一个小块正文里反而匹配不到。后来我把附录合并到相关章节的末尾这个内容就能正常查到了。4.3 批量入库慢到怀疑人生如果你要索引的文档很多一次性处理几千页单线程逐条生成向量会慢到无法接受。这个问题我建议从两个方向解决一是用批处理把向量生成请求按批次发送不要一条条来二是用并发多个文档并行处理速度能提升数倍。还有一个容易踩的坑是重复入库。很多人跑测试时反复执行建库脚本结果向量库里堆积了大量重复片段检索时旧内容不断干扰结果。我现在的做法是每次重建库之前清空旧索引或者在写入时用文档内容的哈希值做去重保证同一个文档不会重复入库。4.4 排查问题速查表现象可能原因优先检查点召回内容与问题无关文档噪音多 / 切分不合理 / embedding 选型差打印召回片段检查切分粒度答案凭空编造提示词约束不够 / 召回片段本来不完整强化提示词限制检查召回质量索引了但查不到切分破坏语义 / 元数据缺失检查文档结构按标题切分问答速度太慢检索慢 / 片段过多 / 模型响应慢优化向量库索引减少 top_k换了问题领域效果骤降文档风格差异大参数不适用重新调切分参数对比多组配置4.5 效果不稳定同样的词换个说法就查不到向量检索不等于关键词搜索但对相似表达的处理能力是有限的。你文档里写“报销审批流程”用户问“开发票的钱怎么报”两个问法语义接近但表达差距很大检索分数可能并不高。遇到这种情况一个实用的做法是扩展检索范围把 top_k 调高一点让更多候选进入生成环节让模型在多个片段里找答案。另一个做法是加同义词改写在问题进检索前先做一次扩展把“报账”“报销”“费用申请”这类常见说法一并检索。不过这种改写的利弊需要测试改写不好反而会引入噪声。5. 从Demo到生产差的不只是代码5.1 别指望一个向量检索打天下我把第一版 RAG 系统部署给同事试用后收到的反馈是“感觉还行就是不聪明”。问题在于纯向量检索有自己的上限尤其面对术语集中、表达方式固定的专业文档时向量相似度未必比得上关键词匹配。后来的优化方向是混合检索向量检索负责语义召回关键词检索负责精确匹配再把两部分结果做融合排序。这样既能理解“怎么走报销流程”这种语义化表达又能精确命中“RG-A07 号制度”这种包含编号的内容。你如果跟进 LangChain会发现它现在提供了很多检索器的组合方式可以先从简单的“向量召回 关键词召回 简单加权合并”开始。5.2 重排序是低成本高回报的一步检索召回之后、生成之前加一个重排序环节效果往往立竿见影。原理是先用向量检索快速召回几十个候选片段再用一个专门的排序模型逐条判断相关度重新打分后只保留最相关的几段。我第一次试用这个方案时最直观的感受是“答案的精准度上来了”。因为向量检索的第一轮召回可以允许粗一点把候选尽量都捞回来重排序再把真正有用的往前放。代价是多了一次模型调用但每次推理成本不高相比整体效果的提升完全值得。5.3 没有评估就没有优化做 RAG 最怕的是凭感觉调参。今天改了一下切分参数好像效果好了一点明天换了个向量库又觉得不如以前了。这种状态其实是在原地打转。我后来做了一个很简单的评估集找几十个典型业务问题每个问题标注好标准答案应该在哪些文档里跑一遍系统统计“答对的题数”和“答案引用来源是否正确”。每次改任何参数都用同一个评估集跑分对比。虽然这套办法很粗糙但它能稳定告诉你哪次改动是真进步哪次只是心理作用。5.4 学习路线建议如果你现在正卡在“代码跑通了但效果不好”的阶段我的建议是先别继续堆功能回到前面章节做三件事把文档加载清洗做好把切分策略对着你的真实文档重调一遍再建一个评估集量化当前水平。这三件事做下来效果提升通常会比换更贵的模型、更复杂的框架明显得多。我自己最大的体会是RAG 这类系统性的技术最难的不是理解概念而是接受“每个环节都需要反复调”。文档质量决定上限切分策略决定下限检索召回决定真实效果生成只是最后那道锦上添花的工序。先接受这个现实再投入时间做实验你的系统一定会一步步变好。
如果你是按顺序学过来的这一篇应该正好是你从“会用大模型”跨到“会做大模型应用”的一篇。前两篇讲的是调用和提示词工程本质上还是在跟模型对话到了 RAG 和 LangChain 这你开始真正搭一套能落地的系统了。我先把 RAG 用一句话说清楚它等于给大模型装了一个“先查资料再回答”的外挂。而 LangChain 则是把这些“查资料”“拼提示词”“调模型”“整理答案”的动作封装成标准积木的工具框架。这篇笔记我按自己从零跑通一版 RAG 问答系统的真实顺序来写适合刚学完大模型基础、正准备做知识库问答或文档问答的开发者参考。1. RAG到底解决了什么问题1.1 大模型的三个死穴先说点实在的你光有一个很强的大模型是不够用的。我实际做项目时发现直接拿模型去回答业务问题几乎必然撞上三个墙。第一面墙是时效性。模型训练数据是有截止日期的你问它昨天的新闻、最新的产品政策它只能靠猜。第二面墙是幻觉这个最头疼模型回答得越流畅越容易把不存在的资料说得跟真的一样你在业务场景里完全不敢直接信。第三面墙是私域知识公司内部的制度、某个项目的历史决策、某个系统的使用手册这些内容根本不在模型的训练数据里你问它它只能给你一个“标准但没用”的答案。这三个问题放在一起你会发现单纯换一个更强的大模型也解决不了。比如你换一个参数更大的模型它的时效性还是停在训练截止日它还是不知道你们公司内部的流程甚至因为表达能力更强幻觉说得更理直气壮。这也就是为什么大模型落地不能只靠“模型”本身必须配合外部机制。RAG 的价值恰恰在这它不试图修改模型而是把模型当成一个“会阅读的生成器”。你先从外部知识库里把相关资料检索出来再把这些资料拼进提示词里让模型基于这些资料作答。答案有出处、知识能更新、私域内容也能覆盖三个死穴被同一个方案按住了。1.2 为什么先学RAG而不是急着微调很多人在这个岔路口会纠结到底应该做 RAG还是微调一个专属模型我用一张对比表把关键差异捋过一遍后心里的答案就清楚了。对比维度RAG微调新增知识直接往知识库丢文档即可即时生效需要准备训练数据重新训练周期长更新成本低换文档就行高每次知识变化都要重新调幻觉问题相对可控答案可追溯到检索片段仍然存在模型照样可能编硬件成本普通服务器加向量库即可通常需要专门的训练资源可解释性高能看到模型用了哪段资料低模型内部不可观测适用场景知识问答、文档分析、实时信息查询指令遵循、语气风格、特定任务能力我并不是说微调没用。如果你真的需要改变模型的行为方式比如让它用特定文风写周报、学会某种固定输出格式微调是更合适的。但如果你只是想“让模型知道一些它本来不知道的事情”RAG 是明显更划算的选择也是大多数人第一个应该掌握的生产级方案。从学习路线上说RAG 的每一项技术都是独立的文本处理、向量检索、提示词工程。即使你以后去学微调这些知识也不浪费。我个人的建议是先用 RAG 把完整链路跑通再根据实际瓶颈决定要不要上微调这个顺序最不劝退也最容易出成果。2. 拆解一条RAG流水线的五个核心环节2.1 文档加载第一步就容易被低估很多人以为 RAG 的第一步是“把 PDF 丢进去”。真做起来你会发现文档加载才是最琐碎但也最影响后面所有环节的那一步。你需要处理的问题包括PDF 是扫描件还是文字版扫描件要不要做 OCR表格要不要保留结构Word 文档里的批注和页眉页脚会不会污染正文网页抓下来的内容里导航、广告、版权声明这些噪音怎么过滤这些如果不在加载阶段处理干净后面垃圾进垃圾出检索出来的片段可能就是一堆乱码。我实际踩过的例子有一份产品手册正文里每个句子后面都跟着页眉信息切分完之后大量片段都包含“某公司内部资料 第X页”这种重复噪音检索时这些噪音还会干扰向量相似度计算。后来我在加载阶段加了清洗逻辑把页眉页脚、固定文案整体过滤掉整体检索质量立马上了一个台阶。2.2 文本切分chunk大小决定检索下限文档加载完下一步是切分。这一步决定的是“检索的最小单元”是什么。如果你把整本手册切成 500 个字符一段那模型每次回答只能看到一小段上下文信息可能不完整如果你切成 2000 个字符一段虽然信息全但塞进提示词里很容易超长而且一段里混了多个主题检索召回后噪声也大。切分要考虑的其实不是单纯的字数而是“语义完整性”。最好的切分策略是按文档结构切先按标题层级分块再对过长的块做二次切分。LangChain 里提供了按字符、按 token、按标题递归等多种切分器我常用的思路是标题优先正文里用重叠窗口让相邻片段保留部分重复内容避免一个完整句子或段落被拦腰截断。chunk 大小的具体数值没有标准答案。我做过一批对比测试领域是产品说明书最后发现 400-800 字左右、重叠 50-100 字的组合效果最好既能保证每段有完整含义又不至于让提示词爆炸。但换一个领域这个值可能完全不同所以一定要拿你自己的文档做实验不要直接抄网上的参数。2.3 向量化Embedding模型的选择逻辑切分完的文本片段要变成计算机能算“相似度”的东西这就是向量化。所谓 embedding就是把一段文字映射成一串数字语义相近的文字数字也相近。选择 embedding 模型时我建议关注三个点。一是维度维度越高能承载的信息越丰富但存储和计算成本也越高。二是最大输入长度如果你的文本片段超过模型能处理的上限就必须截断截断就意味着丢信息这又反过来影响切分策略。三是语言适配性如果你的文档是中文为主尽量选择在中文语料上表现好的模型用英文模型处理中文时相似度计算经常会出现“明明意思一样但分数很低”的情况。这里要特别提醒一个新手容易忽略的点你去索引文档和去查询问题必须用同一个 embedding 模型并且保持同一套参数。如果你换了模型旧向量全部要重新生成否则新旧向量之间没有可比性检索结果会一塌糊涂。2.4 向量存储与检索召回质量才是命门向量化的结果会存进向量数据库它干两件事一是把向量按索引结构存起来二是给你提供相似度查询接口。检索这一步是整个 RAG 的命门。如果检索召回的内容不对后面生成环节再努力也白搭。而检索质量并不只取决于向量数据库本身更取决于你之前几步做得怎么样文档清洗是否干净、切分是否合理、embedding 是否契合领域。我刚开始跑通 RAG 时检索出来的 top5 片段经常只有一两个是相关的当时我还以为是向量数据库不好后来逐一排查才发现问题在切分有些片段太短含义不完整有些片段是目录里的标题堆叠根本没有有效信息。清洗和切分调整之后同样的数据库召回质量明显改善。这说明检索是个系统问题不要一上来就怪某一个组件。2.5 生成把资料变成有依据的答案检索到相关资料后最后一个环节是生成。做法是把检索到的片段拼进提示词明确告诉模型“请根据以上资料回答如果资料里没有直接说不知道”。这一步的原理不难但有一个容易被忽略的点提示词的约束力度。如果你只说“参考以下资料”模型很可能还是会自由发挥把资料当背景板然后继续用自己的知识作答答案看着合理实际根本没依据。我通常会在提示词里写清楚“只允许使用资料中的信息资料中没有的内容必须坦白说明”还要在最后加一道“召回内容不够怎么办”的兜底逻辑比如抛出明确话术而不是让模型硬编一个答案。生成环节还有一个细节是来源标注就是把命中的文档名、章节、页码随答案一起返回。这解决了 RAG 可解释性的问题用户在系统里能看到“答案出自哪一份文档的哪一段”信任度会高很多也方便后续排查问题。3. 用LangChain组装一套可跑的RAG问答系统3.1 先把LangChain里的几个关键概念对齐LangChain 刚接触时容易觉得概念很多但只要跟前面的 RAG 流程对照起来其实一一对应。文档加载器负责导入文件文本切分器负责切块向量存储负责存和查向量检索器是向量存储的查询封装最后链条把上面所有东西串起来同一个链里还可以自由加入提示词模板和模型。我建议不要一上来就背 API而是先建立这个映射关系你已有的数据对应哪个组件你要做的检索对应哪个组件你要问模型的话对应哪个模板。概念先对齐后面写代码就是填空。LangChain 另一个值得利用的特点是它的组件抽象。你今天用的是某款开源向量库做存储下次想换成另一个向量库只需要改一小段初始化代码其余链路不用动。这种解耦在项目早期特别重要因为向量数据库的选型很可能在后期调整抽象好了切换成本就低。3.2 环境准备与安装在开始之前你需要准备好几样东西Python 环境、LangChain 库、一个向量存储组件、一个嵌入模型接口以及一个可调用的大模型接口。环境这块我建议用虚拟环境别直接装进系统 Python因为 LangChain 的依赖比较多不同版本之间偶尔会有冲突虚拟环境能让你随便折腾。安装完成之后配置好各个 API 的密钥或本地服务的地址。注意密钥别硬编码在业务代码里测试时可以用环境变量方便后面换配置。我最初把密钥写在脚本里后来重构时改了半天这个习惯早点养好能省很多事。3.3 落地代码从文档到问答一条链下面这一段是我整理过的最小可用实现逻辑顺序和前面的流程一一对应。这里我只用伪代码和关键步骤做演示具体模型和向量库用你自己的配置替换即可。# 1. 加载文档 loader YourDocumentLoader(你的文档路径) documents loader.load() # 2. 切分文本 splitter YourTextSplitter( chunk_size500, chunk_overlap50, ) chunks splitter.split_documents(documents) # 3. 生成向量并写入向量库 vector_store YourVectorStore.from_documents( chunks, embeddingYourEmbeddingModel(), ) # 4. 创建检索器 retriever vector_store.as_retriever( search_kwargs{k: 4} ) # 5. 定义提示词模板 prompt_template 你是一个企业内部知识库助手。请只使用下面提供的资料回答问题。 如果资料中没有相关信息请直接回答“资料库中未找到相关内容”不要编造答案。 资料 {context} 问题{question} # 6. 组装问答链 chain RetrievalQAChain( retrieverretriever, llmYourLLM(), prompt_templateprompt_template, ) # 7. 问一个问题 result chain.run(公司年假制度是怎么规定的) print(result)这段代码跑通之后你其实已经拥有一个最小可用的 RAG 问答系统了。我第一次跑通时是拿一份员工手册试的问了一个细则问题答案准确且带出了出处当时还是觉得挺神奇的。3.4 参数是怎么调出来的代码跑通只是开始真正要花时间的是调参。我总结几个最影响体验的参数供你参考。先说 top_k也就是每次检索返回多少个片段。太少了信息不够太多了噪声多且费 token我一般从 3-5 开始试。如果问题通常需要跨多段资料才能回答再往上加。然后是 temperature这是大模型生成的随机性参数。做知识问答时我建议调低尽量让模型忠实复述资料而不是发挥创造。0 到 0.3 之间比较稳妥太高容易编。最后是切分相关参数就是前面说的 chunk_size 和 overlap。这两个参数对检索质量影响最大也是最值得做对比测试的。我的方法是准备 5-10 个代表性业务问题分别用不同切分参数跑一遍看检索回来的片段能不能覆盖问题答案通过这种办法判断参数合不合适而不是凭感觉调。4. 我踩过的坑常见问题与排查手记4.1 检索召回了一堆无关内容这是最常见的故障现象。你以为向量检索很聪明它对语义理解其实并没有那么深。比如你问“员工怎么请年假”检索出来的可能是“年假制度的制定背景”这种主题相似但没有操作细则的内容看起来相关实际不能回答问题。我排查这类问题时第一件事是去看召回片段本身。把检索器单独拿出来不接生成环节直接打印召回内容和相似度分数。这时候一眼就能看出问题出在谁的头上如果召回片段本身就跑偏了那问题出在切分或 embedding 选择如果召回片段是对的但答案不对那问题出在生成环节要看提示词有没有约束住模型。4.2 外部知识库文档“查不到”另一个让人崩溃的问题是明显存在于文档里的内容系统却检索不到。这类问题大多出在切分上。比如一个表格被切成了碎片每一片都缺了表头单独看根本不知道在说什么又比如一个完整的流程被切成了几段每段都不完整。解决办法是给切分器加结构感知能力尽量按标题、章节来切而不是硬按字符数切。还有一种做法是给每个片段保留元数据比如来源文件名、章节标题、页码检索时优先显示这些信息至少能让你定位出问题片段。我处理过的一个典型案例某个制度的“适用范围”写在文档末尾的附录里因为切分策略把附录单独切成了一个小块正文里反而匹配不到。后来我把附录合并到相关章节的末尾这个内容就能正常查到了。4.3 批量入库慢到怀疑人生如果你要索引的文档很多一次性处理几千页单线程逐条生成向量会慢到无法接受。这个问题我建议从两个方向解决一是用批处理把向量生成请求按批次发送不要一条条来二是用并发多个文档并行处理速度能提升数倍。还有一个容易踩的坑是重复入库。很多人跑测试时反复执行建库脚本结果向量库里堆积了大量重复片段检索时旧内容不断干扰结果。我现在的做法是每次重建库之前清空旧索引或者在写入时用文档内容的哈希值做去重保证同一个文档不会重复入库。4.4 排查问题速查表现象可能原因优先检查点召回内容与问题无关文档噪音多 / 切分不合理 / embedding 选型差打印召回片段检查切分粒度答案凭空编造提示词约束不够 / 召回片段本来不完整强化提示词限制检查召回质量索引了但查不到切分破坏语义 / 元数据缺失检查文档结构按标题切分问答速度太慢检索慢 / 片段过多 / 模型响应慢优化向量库索引减少 top_k换了问题领域效果骤降文档风格差异大参数不适用重新调切分参数对比多组配置4.5 效果不稳定同样的词换个说法就查不到向量检索不等于关键词搜索但对相似表达的处理能力是有限的。你文档里写“报销审批流程”用户问“开发票的钱怎么报”两个问法语义接近但表达差距很大检索分数可能并不高。遇到这种情况一个实用的做法是扩展检索范围把 top_k 调高一点让更多候选进入生成环节让模型在多个片段里找答案。另一个做法是加同义词改写在问题进检索前先做一次扩展把“报账”“报销”“费用申请”这类常见说法一并检索。不过这种改写的利弊需要测试改写不好反而会引入噪声。5. 从Demo到生产差的不只是代码5.1 别指望一个向量检索打天下我把第一版 RAG 系统部署给同事试用后收到的反馈是“感觉还行就是不聪明”。问题在于纯向量检索有自己的上限尤其面对术语集中、表达方式固定的专业文档时向量相似度未必比得上关键词匹配。后来的优化方向是混合检索向量检索负责语义召回关键词检索负责精确匹配再把两部分结果做融合排序。这样既能理解“怎么走报销流程”这种语义化表达又能精确命中“RG-A07 号制度”这种包含编号的内容。你如果跟进 LangChain会发现它现在提供了很多检索器的组合方式可以先从简单的“向量召回 关键词召回 简单加权合并”开始。5.2 重排序是低成本高回报的一步检索召回之后、生成之前加一个重排序环节效果往往立竿见影。原理是先用向量检索快速召回几十个候选片段再用一个专门的排序模型逐条判断相关度重新打分后只保留最相关的几段。我第一次试用这个方案时最直观的感受是“答案的精准度上来了”。因为向量检索的第一轮召回可以允许粗一点把候选尽量都捞回来重排序再把真正有用的往前放。代价是多了一次模型调用但每次推理成本不高相比整体效果的提升完全值得。5.3 没有评估就没有优化做 RAG 最怕的是凭感觉调参。今天改了一下切分参数好像效果好了一点明天换了个向量库又觉得不如以前了。这种状态其实是在原地打转。我后来做了一个很简单的评估集找几十个典型业务问题每个问题标注好标准答案应该在哪些文档里跑一遍系统统计“答对的题数”和“答案引用来源是否正确”。每次改任何参数都用同一个评估集跑分对比。虽然这套办法很粗糙但它能稳定告诉你哪次改动是真进步哪次只是心理作用。5.4 学习路线建议如果你现在正卡在“代码跑通了但效果不好”的阶段我的建议是先别继续堆功能回到前面章节做三件事把文档加载清洗做好把切分策略对着你的真实文档重调一遍再建一个评估集量化当前水平。这三件事做下来效果提升通常会比换更贵的模型、更复杂的框架明显得多。我自己最大的体会是RAG 这类系统性的技术最难的不是理解概念而是接受“每个环节都需要反复调”。文档质量决定上限切分策略决定下限检索召回决定真实效果生成只是最后那道锦上添花的工序。先接受这个现实再投入时间做实验你的系统一定会一步步变好。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
