简介面向希望搭建私有知识库问答系统的开发者这份源代码以ChatGLM、MOSS等大模型为底座解决文档检索增强生成的实际问题适合用于企业内训、学术资料问答等场景也可用于个人知识管理。压缩包共73个文件包含39个pickle预处理数据、22个Python脚本、4个docx知识库示例文档含基础与多份补充主题另附readme、png流程示意图、txt依赖说明等整体大小约17.3MB。目前已有216人学习下载。代码按agent、configs、loader、textsplitter、chains等模块组织loader支持PDF、图片及文本加载从文档加载、中文文本分割、向量数据库存储到大模型生成回答的链路完整命令行与Web演示程序均可直接启动体验。模型模块提供MOSS、ChatGLM两套大模型调用封装pickle文件便于快速加载文本向量docx文档可直接充当知识库语料既适合验证效果也方便替换语料或接入私有数据是一份很适合上手的RAG落地参考。 这些年接手过不少知识库问答的项目从最早的基于关键词匹配的检索系统到后来引入向量化检索再到如今直接对接大模型做生成式问答技术路线换了一茬又一茬。这次要拆解的这套基于大模型的知识库问答源代码本质上是一个完整的RAG检索增强生成落地实现解决的问题很直接让企业内部文档、产品手册、专业资料这些非结构化数据能够通过自然语言对话的方式被快速查询和利用。这套代码适合谁三类人。第一类是刚接触RAG的开发者想看看一个最小可用的问答系统到底由哪些模块组成第二类是已经在用Dify、AnythingLLM这类现成工具、但想知道底层原理、准备自己定制流程的人第三类是做技术选型的技术负责人需要评估从零搭建的成本和可行性。下面我从架构设计讲到具体实现再聊聊我实际踩过的坑。1. 项目概述与整体思路1.1 核心需求拆解知识库问答这个需求看起来很直白但真正落地时你会发现它隐含了三个层面数据层面要处理格式各异的文档可能是PDF、Word、Markdown也可能是网页抓取下来的HTML检索层面要能从海量文本中快速找到和问题相关的片段这直接决定答案质量的上限生成层面要让大模型基于检索到的片段组织出通顺、准确、有据可查的回答而不是凭空编造。这套源代码围绕这三层展开整体流程可以概括为文档加载 - 文本切分 - 向量化 - 向量存储 - 相似度检索 - 提示词组装 - 大模型生成。我把每一步都做成了独立的模块方便单独替换和调试。比如你想把默认的向量库从Chroma换成Milvus只需要改存储层一个接口不需要动其他代码。1.2 为什么是RAG而不是微调很多人在做知识库问答时都会纠结一个问题到底是微调大模型还是用RAG我的经验是绝大多数场景下RAG是更合理的选择。微调的本质是改变模型的参数让模型记住特定领域的知识。但知识库里的内容往往是高频更新的——产品文档改版、政策条款变更、技术方案迭代如果都靠微调去跟意味着每次更新都要重新准备训练数据、重新跑训练流程成本高且周期长。RAG则不同它的核心思想是检索生成模型本身的知识能力不变我们只是把最新的文档切碎、索引、存起来问答时先检索出相关内容塞进上下文让模型基于这些内容作答。文档更新了只需要重新跑一遍索引流程分钟级搞定。另外从效果角度看RAG天然具备可解释性——模型回答时引用了知识库里的哪段原文是可以追溯到具体位置的。这在企业场景里太重要了总不能模型给客户报了个错误参数你连来源都说不清楚。所以除非你的场景是模型需要内化某种能力或风格否则我建议优先考虑RAG。2. 技术选型与原理解析2.1 嵌入模型的选择逻辑嵌入模型Embedding Model负责把文本转换成向量这是RAG链路中最容易被低估的环节。很多人随便选一个模型就跑结果检索效果一塌糊涂还以为是检索逻辑写错了。选择嵌入模型时我主要看三个指标第一是语义理解能力能不能区分近义词在不同语境下的差异第二是向量维度维度越高理论上表达能力越强但存储和计算开销也越大第三是中文支持程度这一点尤其重要很多英文模型在中文语料上表现大打折扣。以这套源代码默认使用的通义千问text-embedding-v3为例它的向量维度是1024在中文语义理解上表现不错同时也兼容英文内容适合中英文混合的知识库。如果你完全在本地运行、不想调用外部API也可以换成BGE系列或者M3E这类开源嵌入模型代码里我留了统一的Embedding接口切换成本很低。2.2 向量数据库的选型对比向量数据库负责存储嵌入向量并提供相似度检索。这个领域现在非常卷FAISS、Chroma、Milvus、Qdrant、Weaviate各有各的定位。我给这套代码设计了可插拔的存储层默认接Chroma因为它在轻量级场景下最省事pip安装就能跑支持持久化适合单机部署和原型验证。但如果你要上生产环境我建议认真评估一下Milvus或Qdrant。Chroma在数据量超过百万级向量时检索延迟和稳定性会明显下降而且它的事务能力和多租户支持都比较弱。选型时有一个简单的判断标准如果知识库文档总量在10万篇以内、单机部署、追求快速上线Chroma足够如果数据量更大、需要分布式扩展或高并发查询直接上Milvus省得后面迁移。2.3 大模型推理方案的权衡生成环节的大模型选择直接决定了回答质量的下限和单次调用的成本。这套源代码支持两种模式一种是调用云端API比如通义千问、智谱GLM的接口优点是效果稳定、无需维护推理环境缺点是数据要出域对数据安全要求高的场景不适合另一种是通过Ollama部署本地开源模型比如Qwen2.5、Llama系列数据完全在内网流转但需要一台配置不错的GPU服务器。注意如果你选择本地部署模式8B以下的小模型在复杂推理和长文本理解上的表现会明显弱于云端大模型。做知识库问答时我建议至少用7B~14B参数量级的模型并且开启量化如Q4_K_M在效果和显存占用之间找一个平衡点。3. 核心实现与实操细节3.1 文档加载与切分策略文档加载是RAG链路的第一环也是最容易被忽视的一环。不同类型的文档有不同的解析方式PDF需要考虑布局和表格Word需要处理分页和样式HTML需要剥离标签提取正文。我在代码里封装了统一的DocumentLoader用LangChain的文档加载器做底层解析遇到扫描版PDF时会自动尝试OCR兜底。文本切分是整个流程中对最终效果影响最大的环节之一这里我踩过不少坑。最初我按固定长度500字硬切结果经常把一个完整的段落切断导致语义不完整。后来改成分隔符优先策略先按章节标题切再按段落切最后按句子切每一步控制块大小。默认参数是块大小800字符、重叠200字符这个配置在大多数业务文档上表现都不错。块大小的选择有个基本原则太小则上下文信息不足模型容易答偏太大则检索粒度太粗还可能把多段不相关的内容揉在一起干扰模型的判断。3.2 向量化与检索链路切分完成后每段文本会通过嵌入模型转换成向量并写入向量库。检索阶段用户的提问同样会做一次向量化然后在库里做相似度查找。这里有一个关键细节直接拿用户的原话去检索效果往往不好。口语化提问和文档里的书面表达之间存在明显的语义鸿沟比如用户问产品支不支持并发访问文档里写的是系统具备高并发处理能力两者向量相似度可能并不高。我在代码里加了一个查询改写模块先让大模型把用户的问题改写成适合检索的形式提取核心实体和关键词再做向量检索。实测下来这个改写步骤能让命中率提升20%以上。检索时我同时使用向量相似度和关键词BM25加权做混合检索再合并排序。纯向量检索在专有名词和编号类查询上经常翻车混合检索能有效弥补这个短板。检索的核心实现大致如下def search(query: str, top_k: int 5) - list[Document]: # 查询改写提取核心关键词生成检索式 rewritten rewrite_query(query) # 向量检索 query_vec embed_model.embed(rewritten) vec_results vector_store.similarity_search(query_vec, top_k) # 关键词检索BM25 bm25_results bm25_index.search(rewritten, top_k) # 结果融合加权合并去重后返回 merged fusion(vec_results, bm25_results) return merged[:top_k]3.3 问答生成与提示词设计检索到相关片段后接下来就是组装提示词把上下文交给大模型生成回答。提示词的设计直接影响回答质量我一开始的提示词写得非常简陋就是根据以下内容回答问题结果模型经常脱离给定的上下文自由发挥。后来我调整了策略提示词里明确了几件事回答必须基于给定的上下文片段不能凭空编造如果上下文不足以回答问题要明确说知识库中没有相关信息回答需要标注引用的文档片段编号。代码里对应的提示词模板大概是这个风格PROMPT_TEMPLATE 你是企业内部知识库的智能助手。 请基于以下检索到的文档片段回答用户问题 1. 只使用给定的片段作为依据不得使用片段以外的知识。 2. 如果片段不足以回答问题请明确回答知识库中暂未找到相关信息。 3. 回答末尾标注引用的片段编号格式如[来源1][来源2]。 文档片段 {context} 用户问题{question} 这个提示词模板是一个很好的起点但它更像是基线版本。实际使用中你还要根据领域特点调整。比如我做法律合同场景时会额外要求模型区分事实描述与法律结论做客服场景时会要求模型先给结论再给依据语气简洁友好。4. 常见问题排查与优化4.1 检索质量差的定位思路检索不到正确答案是知识库问答最让人头疼的问题而且原因往往不在检索本身。排查时我的习惯是先做模块隔离跳过向量检索把数据库里某段已知的原文直接塞给大模型如果回答正确说明生成链路没问题问题出在检索如果回答还是不对那要先检查提示词和模型。确认是检索问题后再逐层排查。先看切分是否合理比如长文档是否被均匀切分、重要内容有没有被拦腰截断再看嵌入模型是否适合当前语料中文文档用了英文优化的模型会很吃亏最后看检索参数top_k设置太小可能漏掉关键信息设置太大又会引入噪声。我把这个排查路径总结成一个检查清单每次调优直接照着过一遍效率高很多。排查环节常见问题检查方法文本切分块过小导致语义不全随机抽检10个块看内容是否完整嵌入模型语种不匹配或模型过弱用标准测试集跑一遍召回率检索参数top_k不合适对比不同top_k下的回答质量查询改写改写丢失关键实体打印改写结果人工核对4.2 幻觉问题的缓解措施幻觉是生成式问答绕不开的话题。模型给出了看起来很像那么回事、但知识库里根本没这个说法——这种错误在企业场景里是致命的。我总结了几条有效的缓解手段按优先级排列第一是前面提到的提示词约束明确禁止编造这个成本最低但效果有限第二是检索增强确保喂给模型的上下文足够贴题上下文相关度越高模型越不容易自由发挥第三是来源标注让回答携带引用信息用户在业务使用时会自然形成监督第四是阈值拒绝当检索结果的相关度分数低于某个阈值时直接不调用生成模型回答未找到匹配信息。这套源代码里我实现了前三种措施阈值拒绝逻辑也预留了接口。实际项目里我建议组合使用单靠任何一种都很难根除幻觉问题。另外可以做一个离线评测集存放几十组真实问答对每次改动后自动跑一遍对比回答质量的得分变化防止优化一个问题的同时破坏另一个问题。4.3 性能优化与工程化建议性能问题通常在从原型走到生产时集中爆发。我遇到过两种典型情况一是文档量上来后全量索引时间太长二是并发查询时单机向量库撑不住。索引慢的解决办法是增量索引只处理新增和变更的文档配合定时任务在业务低峰期执行。并发问题的处理思路更直接把向量库和大模型推理拆开向量库可以加只读副本分担查询压力大模型如果走本地推理则需要考虑多卡部署或上推理框架做并发调度。另外有一点容易被忽略Embedding操作频繁调用外部API时网络延迟会成为瓶颈。单篇文档几百个块串行向量化可能耗时几十秒。我建议用线程池做并发向量化同时做好失败重试机制。实测下来并发度设为8时能在不影响准确率的前提下把索引速度提升5倍以上。5. 实际操作中的体会代码写到这里整套知识库问答系统已经具备了一个线上可用项目应有的完整度。回顾下来如果说有什么特别值得分享的经验我觉得是不要一上来就追求全流程自动化。最初我自己做RAG项目时总想着端到端自动化文档扔进去答案就出来结果在检索质量上反复碰壁。后来调整了思路先做成半自动索引流程跑完后抽样检查切分质量和检索命中情况确认无误后再开放问答。看起来多了一步人工环节实际上省去了大量反复调试的时间。另外一个小建议把回答的历史记录和用户反馈都存下来。知识库问答系统的优化永远依赖真实使用数据你收集到的这个问题答得不好的反馈比任何评测集都更宝贵。有了这些反馈后续无论是调整检索策略、优化提示词还是补充知识库文档都有了明确的方向。这套系统的代码我后续也会持续迭代目前计划中的改进包括支持多轮对话的上下文管理以及从知识库内容中自动挖掘高频问题、生成推荐问题列表感兴趣的朋友可以顺着这个方向继续扩展。本文还有配套的精品资源点击获取
基于大模型的知识库问答系统：RAG全流程实现与优化
简介面向希望搭建私有知识库问答系统的开发者这份源代码以ChatGLM、MOSS等大模型为底座解决文档检索增强生成的实际问题适合用于企业内训、学术资料问答等场景也可用于个人知识管理。压缩包共73个文件包含39个pickle预处理数据、22个Python脚本、4个docx知识库示例文档含基础与多份补充主题另附readme、png流程示意图、txt依赖说明等整体大小约17.3MB。目前已有216人学习下载。代码按agent、configs、loader、textsplitter、chains等模块组织loader支持PDF、图片及文本加载从文档加载、中文文本分割、向量数据库存储到大模型生成回答的链路完整命令行与Web演示程序均可直接启动体验。模型模块提供MOSS、ChatGLM两套大模型调用封装pickle文件便于快速加载文本向量docx文档可直接充当知识库语料既适合验证效果也方便替换语料或接入私有数据是一份很适合上手的RAG落地参考。 这些年接手过不少知识库问答的项目从最早的基于关键词匹配的检索系统到后来引入向量化检索再到如今直接对接大模型做生成式问答技术路线换了一茬又一茬。这次要拆解的这套基于大模型的知识库问答源代码本质上是一个完整的RAG检索增强生成落地实现解决的问题很直接让企业内部文档、产品手册、专业资料这些非结构化数据能够通过自然语言对话的方式被快速查询和利用。这套代码适合谁三类人。第一类是刚接触RAG的开发者想看看一个最小可用的问答系统到底由哪些模块组成第二类是已经在用Dify、AnythingLLM这类现成工具、但想知道底层原理、准备自己定制流程的人第三类是做技术选型的技术负责人需要评估从零搭建的成本和可行性。下面我从架构设计讲到具体实现再聊聊我实际踩过的坑。1. 项目概述与整体思路1.1 核心需求拆解知识库问答这个需求看起来很直白但真正落地时你会发现它隐含了三个层面数据层面要处理格式各异的文档可能是PDF、Word、Markdown也可能是网页抓取下来的HTML检索层面要能从海量文本中快速找到和问题相关的片段这直接决定答案质量的上限生成层面要让大模型基于检索到的片段组织出通顺、准确、有据可查的回答而不是凭空编造。这套源代码围绕这三层展开整体流程可以概括为文档加载 - 文本切分 - 向量化 - 向量存储 - 相似度检索 - 提示词组装 - 大模型生成。我把每一步都做成了独立的模块方便单独替换和调试。比如你想把默认的向量库从Chroma换成Milvus只需要改存储层一个接口不需要动其他代码。1.2 为什么是RAG而不是微调很多人在做知识库问答时都会纠结一个问题到底是微调大模型还是用RAG我的经验是绝大多数场景下RAG是更合理的选择。微调的本质是改变模型的参数让模型记住特定领域的知识。但知识库里的内容往往是高频更新的——产品文档改版、政策条款变更、技术方案迭代如果都靠微调去跟意味着每次更新都要重新准备训练数据、重新跑训练流程成本高且周期长。RAG则不同它的核心思想是检索生成模型本身的知识能力不变我们只是把最新的文档切碎、索引、存起来问答时先检索出相关内容塞进上下文让模型基于这些内容作答。文档更新了只需要重新跑一遍索引流程分钟级搞定。另外从效果角度看RAG天然具备可解释性——模型回答时引用了知识库里的哪段原文是可以追溯到具体位置的。这在企业场景里太重要了总不能模型给客户报了个错误参数你连来源都说不清楚。所以除非你的场景是模型需要内化某种能力或风格否则我建议优先考虑RAG。2. 技术选型与原理解析2.1 嵌入模型的选择逻辑嵌入模型Embedding Model负责把文本转换成向量这是RAG链路中最容易被低估的环节。很多人随便选一个模型就跑结果检索效果一塌糊涂还以为是检索逻辑写错了。选择嵌入模型时我主要看三个指标第一是语义理解能力能不能区分近义词在不同语境下的差异第二是向量维度维度越高理论上表达能力越强但存储和计算开销也越大第三是中文支持程度这一点尤其重要很多英文模型在中文语料上表现大打折扣。以这套源代码默认使用的通义千问text-embedding-v3为例它的向量维度是1024在中文语义理解上表现不错同时也兼容英文内容适合中英文混合的知识库。如果你完全在本地运行、不想调用外部API也可以换成BGE系列或者M3E这类开源嵌入模型代码里我留了统一的Embedding接口切换成本很低。2.2 向量数据库的选型对比向量数据库负责存储嵌入向量并提供相似度检索。这个领域现在非常卷FAISS、Chroma、Milvus、Qdrant、Weaviate各有各的定位。我给这套代码设计了可插拔的存储层默认接Chroma因为它在轻量级场景下最省事pip安装就能跑支持持久化适合单机部署和原型验证。但如果你要上生产环境我建议认真评估一下Milvus或Qdrant。Chroma在数据量超过百万级向量时检索延迟和稳定性会明显下降而且它的事务能力和多租户支持都比较弱。选型时有一个简单的判断标准如果知识库文档总量在10万篇以内、单机部署、追求快速上线Chroma足够如果数据量更大、需要分布式扩展或高并发查询直接上Milvus省得后面迁移。2.3 大模型推理方案的权衡生成环节的大模型选择直接决定了回答质量的下限和单次调用的成本。这套源代码支持两种模式一种是调用云端API比如通义千问、智谱GLM的接口优点是效果稳定、无需维护推理环境缺点是数据要出域对数据安全要求高的场景不适合另一种是通过Ollama部署本地开源模型比如Qwen2.5、Llama系列数据完全在内网流转但需要一台配置不错的GPU服务器。注意如果你选择本地部署模式8B以下的小模型在复杂推理和长文本理解上的表现会明显弱于云端大模型。做知识库问答时我建议至少用7B~14B参数量级的模型并且开启量化如Q4_K_M在效果和显存占用之间找一个平衡点。3. 核心实现与实操细节3.1 文档加载与切分策略文档加载是RAG链路的第一环也是最容易被忽视的一环。不同类型的文档有不同的解析方式PDF需要考虑布局和表格Word需要处理分页和样式HTML需要剥离标签提取正文。我在代码里封装了统一的DocumentLoader用LangChain的文档加载器做底层解析遇到扫描版PDF时会自动尝试OCR兜底。文本切分是整个流程中对最终效果影响最大的环节之一这里我踩过不少坑。最初我按固定长度500字硬切结果经常把一个完整的段落切断导致语义不完整。后来改成分隔符优先策略先按章节标题切再按段落切最后按句子切每一步控制块大小。默认参数是块大小800字符、重叠200字符这个配置在大多数业务文档上表现都不错。块大小的选择有个基本原则太小则上下文信息不足模型容易答偏太大则检索粒度太粗还可能把多段不相关的内容揉在一起干扰模型的判断。3.2 向量化与检索链路切分完成后每段文本会通过嵌入模型转换成向量并写入向量库。检索阶段用户的提问同样会做一次向量化然后在库里做相似度查找。这里有一个关键细节直接拿用户的原话去检索效果往往不好。口语化提问和文档里的书面表达之间存在明显的语义鸿沟比如用户问产品支不支持并发访问文档里写的是系统具备高并发处理能力两者向量相似度可能并不高。我在代码里加了一个查询改写模块先让大模型把用户的问题改写成适合检索的形式提取核心实体和关键词再做向量检索。实测下来这个改写步骤能让命中率提升20%以上。检索时我同时使用向量相似度和关键词BM25加权做混合检索再合并排序。纯向量检索在专有名词和编号类查询上经常翻车混合检索能有效弥补这个短板。检索的核心实现大致如下def search(query: str, top_k: int 5) - list[Document]: # 查询改写提取核心关键词生成检索式 rewritten rewrite_query(query) # 向量检索 query_vec embed_model.embed(rewritten) vec_results vector_store.similarity_search(query_vec, top_k) # 关键词检索BM25 bm25_results bm25_index.search(rewritten, top_k) # 结果融合加权合并去重后返回 merged fusion(vec_results, bm25_results) return merged[:top_k]3.3 问答生成与提示词设计检索到相关片段后接下来就是组装提示词把上下文交给大模型生成回答。提示词的设计直接影响回答质量我一开始的提示词写得非常简陋就是根据以下内容回答问题结果模型经常脱离给定的上下文自由发挥。后来我调整了策略提示词里明确了几件事回答必须基于给定的上下文片段不能凭空编造如果上下文不足以回答问题要明确说知识库中没有相关信息回答需要标注引用的文档片段编号。代码里对应的提示词模板大概是这个风格PROMPT_TEMPLATE 你是企业内部知识库的智能助手。 请基于以下检索到的文档片段回答用户问题 1. 只使用给定的片段作为依据不得使用片段以外的知识。 2. 如果片段不足以回答问题请明确回答知识库中暂未找到相关信息。 3. 回答末尾标注引用的片段编号格式如[来源1][来源2]。 文档片段 {context} 用户问题{question} 这个提示词模板是一个很好的起点但它更像是基线版本。实际使用中你还要根据领域特点调整。比如我做法律合同场景时会额外要求模型区分事实描述与法律结论做客服场景时会要求模型先给结论再给依据语气简洁友好。4. 常见问题排查与优化4.1 检索质量差的定位思路检索不到正确答案是知识库问答最让人头疼的问题而且原因往往不在检索本身。排查时我的习惯是先做模块隔离跳过向量检索把数据库里某段已知的原文直接塞给大模型如果回答正确说明生成链路没问题问题出在检索如果回答还是不对那要先检查提示词和模型。确认是检索问题后再逐层排查。先看切分是否合理比如长文档是否被均匀切分、重要内容有没有被拦腰截断再看嵌入模型是否适合当前语料中文文档用了英文优化的模型会很吃亏最后看检索参数top_k设置太小可能漏掉关键信息设置太大又会引入噪声。我把这个排查路径总结成一个检查清单每次调优直接照着过一遍效率高很多。排查环节常见问题检查方法文本切分块过小导致语义不全随机抽检10个块看内容是否完整嵌入模型语种不匹配或模型过弱用标准测试集跑一遍召回率检索参数top_k不合适对比不同top_k下的回答质量查询改写改写丢失关键实体打印改写结果人工核对4.2 幻觉问题的缓解措施幻觉是生成式问答绕不开的话题。模型给出了看起来很像那么回事、但知识库里根本没这个说法——这种错误在企业场景里是致命的。我总结了几条有效的缓解手段按优先级排列第一是前面提到的提示词约束明确禁止编造这个成本最低但效果有限第二是检索增强确保喂给模型的上下文足够贴题上下文相关度越高模型越不容易自由发挥第三是来源标注让回答携带引用信息用户在业务使用时会自然形成监督第四是阈值拒绝当检索结果的相关度分数低于某个阈值时直接不调用生成模型回答未找到匹配信息。这套源代码里我实现了前三种措施阈值拒绝逻辑也预留了接口。实际项目里我建议组合使用单靠任何一种都很难根除幻觉问题。另外可以做一个离线评测集存放几十组真实问答对每次改动后自动跑一遍对比回答质量的得分变化防止优化一个问题的同时破坏另一个问题。4.3 性能优化与工程化建议性能问题通常在从原型走到生产时集中爆发。我遇到过两种典型情况一是文档量上来后全量索引时间太长二是并发查询时单机向量库撑不住。索引慢的解决办法是增量索引只处理新增和变更的文档配合定时任务在业务低峰期执行。并发问题的处理思路更直接把向量库和大模型推理拆开向量库可以加只读副本分担查询压力大模型如果走本地推理则需要考虑多卡部署或上推理框架做并发调度。另外有一点容易被忽略Embedding操作频繁调用外部API时网络延迟会成为瓶颈。单篇文档几百个块串行向量化可能耗时几十秒。我建议用线程池做并发向量化同时做好失败重试机制。实测下来并发度设为8时能在不影响准确率的前提下把索引速度提升5倍以上。5. 实际操作中的体会代码写到这里整套知识库问答系统已经具备了一个线上可用项目应有的完整度。回顾下来如果说有什么特别值得分享的经验我觉得是不要一上来就追求全流程自动化。最初我自己做RAG项目时总想着端到端自动化文档扔进去答案就出来结果在检索质量上反复碰壁。后来调整了思路先做成半自动索引流程跑完后抽样检查切分质量和检索命中情况确认无误后再开放问答。看起来多了一步人工环节实际上省去了大量反复调试的时间。另外一个小建议把回答的历史记录和用户反馈都存下来。知识库问答系统的优化永远依赖真实使用数据你收集到的这个问题答得不好的反馈比任何评测集都更宝贵。有了这些反馈后续无论是调整检索策略、优化提示词还是补充知识库文档都有了明确的方向。这套系统的代码我后续也会持续迭代目前计划中的改进包括支持多轮对话的上下文管理以及从知识库内容中自动挖掘高频问题、生成推荐问题列表感兴趣的朋友可以顺着这个方向继续扩展。本文还有配套的精品资源点击获取
