1. 内容整体设计与思路拆解1.1 先搞明白ChatGPT 这类模型为什么会“不懂你的文档”很多同学第一次接触到 RAGRetrieval-Augmented Generation检索增强生成时都会以为“把文档丢给 AI 就完事了”。你的想法很朴素模型不知道的东西我喂给它不就行了结果文档上传了一堆问出来的答案还是驴唇不对马嘴这会带来一个灵魂拷问我的 AI 是不是个傻子其实问题不在 AI 智商而在于“喂”的方式错了。大语言模型的本质是“根据已知文本做概率预测”它训练时学的是海量的公开语料不包含你公司的技术手册、内部报表、独家产品文档。你把 PDF 拖进聊天框模型确实能看到这部分文字但对于动辄几百页的文档模型一次“能看”的上下文窗口有限超过长度后系统自动做截断或压缩关键信息可能被切掉了。更隐蔽的问题在于语言模型的注意力机制长文本里越靠中间、越琐碎的段落越容易被忽略真正决定答案准确性的句子反而被漏掉了。这就解释了第一个真相普通上传功能不等于有效的知识增强。你需要的不是“把文档塞进去”而是“先把文档里最有用的片段精准捞出来再喂给模型”。这就是 RAG 的核心思路也是我这几年做企业级 AI 问答落地时最有价值的经验之一。如果你要让 AI 基于内部知识库好好说话不是在聊天窗里拖文件而是要搭一条检索管线。1.2 RAG 是怎么“按住”AI 不让它胡说的RAG 的思路不复杂但理解它你会少走大量弯路。它的全称是检索增强生成拆开来看“检索”指从你的文档资料中找出相关段落“增强”指把这些段落拼进给模型的提示里“生成”指模型基于检索到的证据来写答案。用生活化的方式理解你去咨询领域专家之前会把病历、体检报告、历史用药记录先整理好放在桌面上。专家看材料的时候不会凭想象给你开药而是瞄一眼报告找到关键指标再结合经验给出判断。RAG 就是那个整理桌面的人——它负责从几百份文档里把最相关的那几段材料递给模型让模型在“有据可依”的前提下回答问题。这带来的好处是看得见的答案更准模型不用瞎猜检索到的段落本来就围绕问题幻觉率直线下降。可溯源回答可以附上“依据来自文档第 X 页第 X 段”读者自己就能验证。知识可更新公司文档变了你只需要重建索引不需要重新训练模型。对绝大多数场景来说比微调省事太多。但请记住一句从业者忠告RAG 不是开箱即用的银弹它是一套需要对原件拆解、对切分参数调优、对检索策略反复验证的工程流程。你遇到“AI 还在胡说八道”往往不是模型不行而是 RAG 管线里某个环节没做好。1.3 从“能跑”到“能信”衡量 RAG 效果的三个指标在正式动手之前我建议你先建立一套衡量标尺否则调了半天也不知道自己做得好不好。做 AI 问答落地这三年我主要看三个指标第一个是召回率它衡量“问题对应的正确答案片段有没有被检索环节捞出来”。一篇文章有十处涉及某产品参数如果你只捞出来三处那就算模型再聪明也答不好。第二个是精确率衡量捞出来的片段里真正和问题有关的有多少。捞了十个片段八个是无关目录和广告页模型会被噪音带跑偏回答里混入“上下文无关”的内容。第三个是忠实度说白了就是模型写的每句话有没有事实依据。评估方式是逐句判断“这句话能从检索到的原文里找到支持吗”找得到算忠找不到哪怕看着合理也算编。做 RAG 优化时我的习惯是先用一批标准问题构建评测集跑出基线然后每次改一个变量切分策略、检索方式、提示词模板重新评测。有了数据优化就不再是玄学。很多团队调了两版就放弃就是因为没建立这套基准效果好坏全靠“感觉”。2. 核心细节解析与实操要点2.1 文档解析这一步决定了 80% 的上限RAG 管线的最前端不是切片也不是向量化而是文档解析。你可能觉得这有什么好说的PDF 转文本不就行了真做了才发现坑全在这。PDF 分为文本型 PDF 和扫描型 PDF。文本型 PDF 可以直接抽取文字但很多是双栏排版、带页眉页脚、有表格和图片注释直接抽取出来的文字顺序是乱的。扫描型 PDF 根本抽不出文字必须 OCR 识别识别错一个字检索结果就错一段。我的建议是按文档类型分不同处理方案文本型 PDF推荐用pdfplumber或PyMuPDFfitz提取文字和位置信息。优先保留版面结构双栏文档要先按坐标分栏再按阅读顺序拼接。扫描型 PDF用pymupdf先做图像裁剪再交给OCRmyPDF或 Tesseract 识别识别后还要做简单的错字纠正。Word 和 Markdown保留标题层级和列表结构切分时可以按章节作为天然边界效果远好于按固定字数硬切。表格类内容最简单的处理是把表格转成 Markdown 格式或者“字段: 值”的键值对文本这样向量检索时才能命中语义。这里有一个经典教训有个客户上传了一堆设备维护手册AI 一问“某型号设备的工作温度范围”它总是答成另一型号的参数。我们排查后发现解析器把两栏文本的顺序搞错了B 型号的参数混进了 A 型号的段落里切分后相互污染。后来在解析阶段加入坐标排序问题当场消失。可以说解析这一步不做扎实后面调切分、调检索都是白费劲。2.2 切分Chunking把文档切成模型能消化的黄金粒度解析完成后的文本是长文档你得切块术语叫 Chunking。切块粒度直接关系到检索命中的质量。切太大一块里面塞了太多无关信息向量表示的语义被稀释切太小一段话表达不完整检索到的碎片缺乏上下文。我干活时的经验参数是常规文档按 300~500 字切块重叠 50~100 字。重叠的作用是避免语义在切分边界处断开比如一个关键句子一半在上块、一半在下块重叠能确保无论哪块先被检索到都能看到完整信息。固定字数的切分只是保底方案。更优雅的做法是结构感知切分利用文档的标题层级识别出“第一章”“1.1”“1.1.2”这类结构标记以小节为最小单位。如果小节过长再按段落和字数二次切分如果小节太短则和下一个同层级小节合并。这样做的优势是每个切块都自带逻辑完整性向量化之后语义更集中检索召回率明显更高。还有一类特殊文档——代码和日志。这类内容对切分更敏感建议按函数或代码块切分不要让一条函数体被切断。我在日志检索场景里的做法是先按行解析识别时间戳和严重级别再按一个请求会话聚合成块。总之切分策略没有万能模板唯一确定的原则是切完的块应该是人类阅读时能理解的最小完整单元。2.3 嵌入模型与向量库的选型思路文档切好后要把每块文本变成向量。不同嵌入模型对中文的支持、对不同领域的语义理解差距很大。免费场景我常推荐开源的bge-m3或m3e-base中文效果不错可以在本地部署不依赖外部 API预算充足或对英文场景友好的场景可以选 OpenAI 的text-embedding-3-small或text-embedding-3-large。这里有个非常重要的点嵌入模型一旦定下来索引阶段和查询阶段必须用同一个千万别混着用。不同模型输出的向量不在同一个语义空间混用会导致检索结果直接崩盘。这是我见过最频繁的低级错误。向量数据库的选择则要区分场景数据量在百万级以下追求简单用Chroma或FAISS就够了。数据量超过百万需要持久化存储和复杂过滤用Milvus或pgvector。如果你的知识库有明确的租户隔离需求比如不同部门的数据不能串优先选pgvector因为它能结合 PostgreSQL 的权限体系做行级过滤。选型不必一步到位我个人的建议是先用 Chroma 快速验证效果跑到瓶颈再迁移。很多人一上来就上 Milvus 集群结果调优复杂度反而拖垮了项目进度。2.4 提示词工程给 AI 加上“不许编”的紧箍咒RAG 的最后一步是用提示词把检索到的片段和用户问题组装起来。提示词模板决定模型怎么使用证据、敢不敢发散。我常用的模板结构大致如下你是一个严谨的技术问答助手。 请根据以下检索到的资料片段回答问题。资料可能包含多个来源请综合判断。 【资料片段】 {context} 【用户问题】 {question} 要求 1. 回答必须严格基于资料片段不得补充资料中没有的内容。 2. 如果资料中没有足够信息直接回答“当前资料中未找到相关信息”。 3. 回答可以包含引用格式为[来源n]n对应资料片段的编号。 4. 不要编造数字、规格、型号或结论。这个模板里有几个容易被忽视的细节。第一“如果资料中没有足够信息直接回答找不到”——这一句非常关键它给了模型一个说“不知道”的出口。很多 AI 胡说八道是因为它没有不回答的选项你必须在提示里明确允许它拒答。第二引用格式放在“要求”里后面做答案溯源时才有据可查。第三system prompt 里还可以加一句“如果资料片段之间存在矛盾请指出矛盾并在回答中标注”。实际项目里提示词模板的调整经常带来 10%~20% 的准确率变化这个杠杆比换模型还大。3. 实操过程与核心环节实现3.1 从零搭一个本地知识问答 RAG 管线Python 示例纸上谈兵没意思我直接用一段代码走通完整流程从文档加载到问答闭环。这里以 LangChain 生态为例依赖库包括langchain、langchain-community、chromadb、bge-m3的 embedding 封装以及pypdf。第一步加载文档并解析from langchain_community.document_loaders import PyPDFLoader loader PyPDFLoader(产品手册_2025.pdf) documents loader.load() print(f共加载 {len(documents)} 页)loader.load()返回的每个 Document 对象里包含page_content和metadatametadata 里有页码信息。注意这里只是最基础的加载没有处理双栏和扫描版实际项目中要按前面说的方法做更细致的解析。第二步切分。用结构感知的方式先看page_content的标题再配合字数做二次切分from langchain_text_splitters import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size400, chunk_overlap80, separators[\n\n, \n, 。, , , , ], length_functionlen, ) chunks text_splitter.split_documents(documents) print(f切分为 {len(chunks)} 个块)separators参数指定了优先在段落、句子边界处断开避免硬切。顺序很重要先按双换行切没有双换行再按单换行再按句号逐级退让。这样切出来的块语义完整度远高于固定长度硬切。第三步生成向量并写入 Chromafrom langchain_community.embeddings import HuggingFaceBgeEmbeddings from langchain_community.vectorstores import Chroma embedding_model HuggingFaceBgeEmbeddings( model_nameBAAI/bge-m3, model_kwargs{device: cpu}, encode_kwargs{normalize_embeddings: True}, ) vectorstore Chroma.from_documents( documentschunks, embeddingembedding_model, persist_directory./chroma_db, ) retriever vectorstore.as_retriever(search_kwargs{k: 5})这里有个细节encode_kwargs里设置normalize_embeddingsTrue如果你后面要做余弦相似度和点积的换算归一化能保持一致的排序结果。k值代表每个问题召回几个片段一般 4~8 个比较合适太少信息不足太多干扰项多。第四步用检索结果拼提示词from langchain.prompts import ChatPromptTemplate prompt_template ChatPromptTemplate.from_messages([ (system, ( 你是一个严谨的技术问答助手。\n 请根据以下检索到的资料片段回答问题。\n 资料可能包含多个来源请综合判断。\n 如果资料中没有足够信息直接回答当前资料中未找到相关信息。\n 回答中的关键结论必须标注来源编号[来源n]n对应资料片段的编号。\n\n {context} )), (human, 问题{question}), ]) def build_prompt(question, chunks): context \n\n.join( f[来源{i1}] {chunk.page_content} for i, chunk in enumerate(chunks) ) return prompt_template.format(contextcontext, questionquestion)第五步接入大模型生成答案。以 OpenAI 兼容接口为例from langchain_openai import ChatOpenAI chat_model ChatOpenAI( modelgpt-4o-mini, temperature0.1, ) def ask(question): chunks retriever.invoke(question) prompt build_prompt(question, chunks) answer chat_model.invoke(prompt) return answer.content, chunks answer, chunks ask(这款设备的工作温度范围是多少) print(answer) for i, chunk in enumerate(chunks): print(f\n[来源{i1}] {chunk.page_content})temperature0.1是把创造性压到很低保证回答尽量贴着资料走。如果你用的是开源本地模型比如qwen2.5-7b-instruct同样可以用这套模板只是把模型底座换一下。到这里一个能跑的 RAG 最小闭环就完成了。但代码能跑只是及格线接下来我会讲我在实际项目中怎么排查“AI 还在胡说八道”的具体问题。3.2 想让答案更可信加一个引用和溯源机制上面的代码里提示词已经要求模型标注[来源n]但模型输出的引用不可靠它可能编一个“[来源3]”而实际证据来自[来源1]。要做可信的溯源不能只靠提示词必须做一层硬校验。我的做法是把答案按句子拆开对每个句子做相似度或关键词匹配找出它最可能来自哪几个检索片段。如果句子和所有检索片段的相关度都低于阈值判定该句为“无依据内容”在界面上标红提示用户。这一步可以用简单的 TF-IDF 相似度实现也可以用轻量模型做 embedding 相似度计算。实践中这个“逐句溯源”机制非常有效。我们上线过一个人工复核工具操作员每看一条回答旁边就列出对应的原文片段答得不对的当场标记反馈数据再反哺检索参数优化。做了一阵后最直观的变化就是——胡说率肉眼可见地往下掉因为“在哪个文档哪一页看到的”这个问题让模型没法蒙混过关。3.3 检索不到正确内容时怎么干预混合检索与重排序纯向量检索有个众所周知的短板对大篇幅的数字、型号、专有名词不敏感。你问“设备型号 ABC-2000 的额定电压”向量检索可能把 “ABC-2000” 拆得面目全非召回结果反而被无关内容占满。这种时候光调 embedding 模型不一定有效更好的方案是上混合检索。混合检索简单说就是同时跑一路关键词检索BM25和一路向量检索再把两路结果合并排序。关键词检索擅长精确匹配型号、编号、人名向量检索擅长语义相近的表达。合并时可以用加权和也可以用 RRFReciprocal Rank Fusion算法。RRF 的公式不复杂对于每个文档统计它在各检索结果列表中的排名累加分数1/(rank k)k 一般取 60。相加后按总分排序。这种方法不需要调权重对参数不敏感稳定好用。我在项目中实际测试混合检索比纯向量检索的召回率通常在 10%~20% 左右提升遇到数字型问题提升更明显。重排序是另一层优化召回 20 个候选块用一个跨编码器模型如bge-reranker-v2-m3对“问题 - 候选块”做精细打分只取前 5 个进提示词。重排序的计算成本比向量检索高但好处是能粗筛掉低相关块模型看到的都是高相关内容回答质量自然提升。如果你对准确率要求高建议把重排序加进来如果追求低延迟可以先不加。3.4 多轮对话里的“老毛病”上下文污染单轮问答做好不难多轮对话才是翻车重灾区。很多 RAG 问答在第二轮就开始胡说原因往往不是检索失败而是模型把前几轮的历史对话和当前轮检索到的资料混在一起分不清哪些是“过去的问答内容”哪些是“当前问题的依据”。我处理多轮对话的标准做法是每一轮都重新检索检索时只使用当前问题、必要时加上历史问题改写后的关键词但喂给模型的资料片段只放当前这一轮的检索结果。历史对话记录可以保留给模型做上下文连贯但绝不能让历史聊天内容混进资料片段里。还有一个常见问题是用户追问“那第二点呢”如果只看当前这句话检索完全失效。此时需要先对用户输入做“指代消解”把“第二点”改写为“产品手册里第二点优势是什么”再拿去检索。LangChain 有现成的HistoryAwareRetriever组件可以做核心原理就是先用一个辅助 LLM 调用把对话历史压缩成一条独立的检索查询。处理多轮对话时核心原则是区分“检索的查询”和“回答的上下文”。查询要干净、独立上下文可以携带历史信息但证据只能来自最新检索结果。4. 常见问题与排查技巧实录4.1 典型故障清单与排查路径我把我踩过的坑整理成一张速查表你在调试时遇到问题可以直接对照排查。故障现象可能原因排查与解法答案明显与资料冲突切分边界把关键信息切断检查切分块内容增大重叠度或改用结构感知切分检索出来全是无关片段嵌入模型与数据领域不匹配换中文领域模型改用混合检索答案中一半有依据一半是编的提示词没有限制“不知道就拒答”加入拒答指令开启逐句溯源专有名词频繁识别错向量检索对精确词不敏感加 BM25 关键词检索路用 RRF 合并多轮对话第二轮开始乱历史聊天内容混入证据片段区分检索查询与回答上下文检索结果有但模型没用提示词结构过于复杂简化为系统提示词把资料放人类消息开头切片块数量太多导致超时k 值取太大且没有重排限制候选数,加粗筛后的重排序答案有引文但引文是编的模型生成的引用不受控用相似度做逐句溯源按阈值判定来源4.2 两个我自己踩过的大坑第一个坑是“索引阶段不重名”的坑。有次我在一个项目里改造检索体验索引阶段是用bge-m3生成的向量到查询阶段为了省事换成了另一个 embedding 模型结果线上问答质量断崖式下跌。原因就在两个模型向量空间不一致相似度计算完全失真。后来我规范了流程把 embedding 模型名称写进索引 meta 信息里查询时校验不匹配直接报错。这件事让我长记性嵌入模型的版本管理要和业务代码同等严格。第二个坑是“让模型直接抓文档链接”。早期版本为了让 AI 回答更完整我在提示词里塞了“你可以浏览网页获取更多信息”这句话。结果模型经常开始自由发挥甚至编造一些根本不存在的网页结论。排查之后我把 RAG 的回答范围严格锁定在检索片段内关掉了联网能力模型反而稳定了。很多“AI 胡说”的问题本质上是边界没设清楚模型的自由度越大幻觉率越高。4.3 几个能够显著提准的隐藏技巧再补几条常规文档里不怎么写但极好用的技巧。第一在切分时把文档标题和元数据拼进切块内容里。比如一个百科条目块你可以在正文前加上“条目名称XX 设备”这样一个前缀向量化后检索“XX 设备相关问题”时这个前缀能起到明显的语义锚定作用。第二对检索片段按出版物时间加权。如果知识库里同一主题有旧文档、也有新版文档检索结果要优先展示新版本。做法不复杂在 metadata 里存发布日期合并排序时给新文档加一个时间加权系数。这个技巧在合规资料更新频繁的场景里特别实用。第三针对“不知道”场景单独设计话术。很多系统做不到完美召回当检索为空或得分极低时不要让模型硬答而是走一条专门的兜底流程——提示“资料库中暂无相关信息建议联系人工客服或补充文档”。这一步看似简单却能把用户体验从“答得离谱”救回到“诚实到让人放心”。4.4 从“能跑”到“好用”上线前的评测小册子最后分享一个我一直在用的评测方法当你建立了评测习惯之后RAG 调试不再靠运气而是一步步接近可靠。我会在每个项目里准备一份至少 50 条问题的评测集问题分布在四个类型直接问答如某参数值、多条件查询如某型号在某某环境下的表现、综合归纳如总结某文档的三大要点、边界测试如文档中根本没有答案的问题。每条问题标记标准答案或期望行为回答或拒答。跑评测时针对每一条记录四类指标召回是否正确、答案是否忠实、引用是否真实、是否误拒答。跑完一轮改一个变量再跑一轮。坚持下来你就会看到准确率一点点往上爬直到稳定在一个让人放心的水平。我个人做 RAG 最大的体会是这个系统没有一次调完就能永远不出错的时刻但它是一个越用越懂你的文档的“整理师”。它最重要的能力不是“会说”而是“知道自己知道什么也清楚自己不知道什么”。把“我不知道”作为允许输出的答案把“依据来源”作为强制要求把“检索命中率”作为每次迭代的核心指标你的 AI 就很难再满嘴跑火车。最后再分享一个小小的实操偏好凡是做企业级知识库问答我一定会在每个回答底下挂出“依据片段”哪怕产品经理说界面丑也不要省。这个设计表面上是给用户一个验证入口内里其实是给系统自己的每一次生成打上了信任标记。用户信了系统才能用得起来AI 胡说八道的问题才算真正落地解决。 从RAG到可信问答：构建企业级知识库检索增强生成实战解析
1. 内容整体设计与思路拆解1.1 先搞明白ChatGPT 这类模型为什么会“不懂你的文档”很多同学第一次接触到 RAGRetrieval-Augmented Generation检索增强生成时都会以为“把文档丢给 AI 就完事了”。你的想法很朴素模型不知道的东西我喂给它不就行了结果文档上传了一堆问出来的答案还是驴唇不对马嘴这会带来一个灵魂拷问我的 AI 是不是个傻子其实问题不在 AI 智商而在于“喂”的方式错了。大语言模型的本质是“根据已知文本做概率预测”它训练时学的是海量的公开语料不包含你公司的技术手册、内部报表、独家产品文档。你把 PDF 拖进聊天框模型确实能看到这部分文字但对于动辄几百页的文档模型一次“能看”的上下文窗口有限超过长度后系统自动做截断或压缩关键信息可能被切掉了。更隐蔽的问题在于语言模型的注意力机制长文本里越靠中间、越琐碎的段落越容易被忽略真正决定答案准确性的句子反而被漏掉了。这就解释了第一个真相普通上传功能不等于有效的知识增强。你需要的不是“把文档塞进去”而是“先把文档里最有用的片段精准捞出来再喂给模型”。这就是 RAG 的核心思路也是我这几年做企业级 AI 问答落地时最有价值的经验之一。如果你要让 AI 基于内部知识库好好说话不是在聊天窗里拖文件而是要搭一条检索管线。1.2 RAG 是怎么“按住”AI 不让它胡说的RAG 的思路不复杂但理解它你会少走大量弯路。它的全称是检索增强生成拆开来看“检索”指从你的文档资料中找出相关段落“增强”指把这些段落拼进给模型的提示里“生成”指模型基于检索到的证据来写答案。用生活化的方式理解你去咨询领域专家之前会把病历、体检报告、历史用药记录先整理好放在桌面上。专家看材料的时候不会凭想象给你开药而是瞄一眼报告找到关键指标再结合经验给出判断。RAG 就是那个整理桌面的人——它负责从几百份文档里把最相关的那几段材料递给模型让模型在“有据可依”的前提下回答问题。这带来的好处是看得见的答案更准模型不用瞎猜检索到的段落本来就围绕问题幻觉率直线下降。可溯源回答可以附上“依据来自文档第 X 页第 X 段”读者自己就能验证。知识可更新公司文档变了你只需要重建索引不需要重新训练模型。对绝大多数场景来说比微调省事太多。但请记住一句从业者忠告RAG 不是开箱即用的银弹它是一套需要对原件拆解、对切分参数调优、对检索策略反复验证的工程流程。你遇到“AI 还在胡说八道”往往不是模型不行而是 RAG 管线里某个环节没做好。1.3 从“能跑”到“能信”衡量 RAG 效果的三个指标在正式动手之前我建议你先建立一套衡量标尺否则调了半天也不知道自己做得好不好。做 AI 问答落地这三年我主要看三个指标第一个是召回率它衡量“问题对应的正确答案片段有没有被检索环节捞出来”。一篇文章有十处涉及某产品参数如果你只捞出来三处那就算模型再聪明也答不好。第二个是精确率衡量捞出来的片段里真正和问题有关的有多少。捞了十个片段八个是无关目录和广告页模型会被噪音带跑偏回答里混入“上下文无关”的内容。第三个是忠实度说白了就是模型写的每句话有没有事实依据。评估方式是逐句判断“这句话能从检索到的原文里找到支持吗”找得到算忠找不到哪怕看着合理也算编。做 RAG 优化时我的习惯是先用一批标准问题构建评测集跑出基线然后每次改一个变量切分策略、检索方式、提示词模板重新评测。有了数据优化就不再是玄学。很多团队调了两版就放弃就是因为没建立这套基准效果好坏全靠“感觉”。2. 核心细节解析与实操要点2.1 文档解析这一步决定了 80% 的上限RAG 管线的最前端不是切片也不是向量化而是文档解析。你可能觉得这有什么好说的PDF 转文本不就行了真做了才发现坑全在这。PDF 分为文本型 PDF 和扫描型 PDF。文本型 PDF 可以直接抽取文字但很多是双栏排版、带页眉页脚、有表格和图片注释直接抽取出来的文字顺序是乱的。扫描型 PDF 根本抽不出文字必须 OCR 识别识别错一个字检索结果就错一段。我的建议是按文档类型分不同处理方案文本型 PDF推荐用pdfplumber或PyMuPDFfitz提取文字和位置信息。优先保留版面结构双栏文档要先按坐标分栏再按阅读顺序拼接。扫描型 PDF用pymupdf先做图像裁剪再交给OCRmyPDF或 Tesseract 识别识别后还要做简单的错字纠正。Word 和 Markdown保留标题层级和列表结构切分时可以按章节作为天然边界效果远好于按固定字数硬切。表格类内容最简单的处理是把表格转成 Markdown 格式或者“字段: 值”的键值对文本这样向量检索时才能命中语义。这里有一个经典教训有个客户上传了一堆设备维护手册AI 一问“某型号设备的工作温度范围”它总是答成另一型号的参数。我们排查后发现解析器把两栏文本的顺序搞错了B 型号的参数混进了 A 型号的段落里切分后相互污染。后来在解析阶段加入坐标排序问题当场消失。可以说解析这一步不做扎实后面调切分、调检索都是白费劲。2.2 切分Chunking把文档切成模型能消化的黄金粒度解析完成后的文本是长文档你得切块术语叫 Chunking。切块粒度直接关系到检索命中的质量。切太大一块里面塞了太多无关信息向量表示的语义被稀释切太小一段话表达不完整检索到的碎片缺乏上下文。我干活时的经验参数是常规文档按 300~500 字切块重叠 50~100 字。重叠的作用是避免语义在切分边界处断开比如一个关键句子一半在上块、一半在下块重叠能确保无论哪块先被检索到都能看到完整信息。固定字数的切分只是保底方案。更优雅的做法是结构感知切分利用文档的标题层级识别出“第一章”“1.1”“1.1.2”这类结构标记以小节为最小单位。如果小节过长再按段落和字数二次切分如果小节太短则和下一个同层级小节合并。这样做的优势是每个切块都自带逻辑完整性向量化之后语义更集中检索召回率明显更高。还有一类特殊文档——代码和日志。这类内容对切分更敏感建议按函数或代码块切分不要让一条函数体被切断。我在日志检索场景里的做法是先按行解析识别时间戳和严重级别再按一个请求会话聚合成块。总之切分策略没有万能模板唯一确定的原则是切完的块应该是人类阅读时能理解的最小完整单元。2.3 嵌入模型与向量库的选型思路文档切好后要把每块文本变成向量。不同嵌入模型对中文的支持、对不同领域的语义理解差距很大。免费场景我常推荐开源的bge-m3或m3e-base中文效果不错可以在本地部署不依赖外部 API预算充足或对英文场景友好的场景可以选 OpenAI 的text-embedding-3-small或text-embedding-3-large。这里有个非常重要的点嵌入模型一旦定下来索引阶段和查询阶段必须用同一个千万别混着用。不同模型输出的向量不在同一个语义空间混用会导致检索结果直接崩盘。这是我见过最频繁的低级错误。向量数据库的选择则要区分场景数据量在百万级以下追求简单用Chroma或FAISS就够了。数据量超过百万需要持久化存储和复杂过滤用Milvus或pgvector。如果你的知识库有明确的租户隔离需求比如不同部门的数据不能串优先选pgvector因为它能结合 PostgreSQL 的权限体系做行级过滤。选型不必一步到位我个人的建议是先用 Chroma 快速验证效果跑到瓶颈再迁移。很多人一上来就上 Milvus 集群结果调优复杂度反而拖垮了项目进度。2.4 提示词工程给 AI 加上“不许编”的紧箍咒RAG 的最后一步是用提示词把检索到的片段和用户问题组装起来。提示词模板决定模型怎么使用证据、敢不敢发散。我常用的模板结构大致如下你是一个严谨的技术问答助手。 请根据以下检索到的资料片段回答问题。资料可能包含多个来源请综合判断。 【资料片段】 {context} 【用户问题】 {question} 要求 1. 回答必须严格基于资料片段不得补充资料中没有的内容。 2. 如果资料中没有足够信息直接回答“当前资料中未找到相关信息”。 3. 回答可以包含引用格式为[来源n]n对应资料片段的编号。 4. 不要编造数字、规格、型号或结论。这个模板里有几个容易被忽视的细节。第一“如果资料中没有足够信息直接回答找不到”——这一句非常关键它给了模型一个说“不知道”的出口。很多 AI 胡说八道是因为它没有不回答的选项你必须在提示里明确允许它拒答。第二引用格式放在“要求”里后面做答案溯源时才有据可查。第三system prompt 里还可以加一句“如果资料片段之间存在矛盾请指出矛盾并在回答中标注”。实际项目里提示词模板的调整经常带来 10%~20% 的准确率变化这个杠杆比换模型还大。3. 实操过程与核心环节实现3.1 从零搭一个本地知识问答 RAG 管线Python 示例纸上谈兵没意思我直接用一段代码走通完整流程从文档加载到问答闭环。这里以 LangChain 生态为例依赖库包括langchain、langchain-community、chromadb、bge-m3的 embedding 封装以及pypdf。第一步加载文档并解析from langchain_community.document_loaders import PyPDFLoader loader PyPDFLoader(产品手册_2025.pdf) documents loader.load() print(f共加载 {len(documents)} 页)loader.load()返回的每个 Document 对象里包含page_content和metadatametadata 里有页码信息。注意这里只是最基础的加载没有处理双栏和扫描版实际项目中要按前面说的方法做更细致的解析。第二步切分。用结构感知的方式先看page_content的标题再配合字数做二次切分from langchain_text_splitters import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size400, chunk_overlap80, separators[\n\n, \n, 。, , , , ], length_functionlen, ) chunks text_splitter.split_documents(documents) print(f切分为 {len(chunks)} 个块)separators参数指定了优先在段落、句子边界处断开避免硬切。顺序很重要先按双换行切没有双换行再按单换行再按句号逐级退让。这样切出来的块语义完整度远高于固定长度硬切。第三步生成向量并写入 Chromafrom langchain_community.embeddings import HuggingFaceBgeEmbeddings from langchain_community.vectorstores import Chroma embedding_model HuggingFaceBgeEmbeddings( model_nameBAAI/bge-m3, model_kwargs{device: cpu}, encode_kwargs{normalize_embeddings: True}, ) vectorstore Chroma.from_documents( documentschunks, embeddingembedding_model, persist_directory./chroma_db, ) retriever vectorstore.as_retriever(search_kwargs{k: 5})这里有个细节encode_kwargs里设置normalize_embeddingsTrue如果你后面要做余弦相似度和点积的换算归一化能保持一致的排序结果。k值代表每个问题召回几个片段一般 4~8 个比较合适太少信息不足太多干扰项多。第四步用检索结果拼提示词from langchain.prompts import ChatPromptTemplate prompt_template ChatPromptTemplate.from_messages([ (system, ( 你是一个严谨的技术问答助手。\n 请根据以下检索到的资料片段回答问题。\n 资料可能包含多个来源请综合判断。\n 如果资料中没有足够信息直接回答当前资料中未找到相关信息。\n 回答中的关键结论必须标注来源编号[来源n]n对应资料片段的编号。\n\n {context} )), (human, 问题{question}), ]) def build_prompt(question, chunks): context \n\n.join( f[来源{i1}] {chunk.page_content} for i, chunk in enumerate(chunks) ) return prompt_template.format(contextcontext, questionquestion)第五步接入大模型生成答案。以 OpenAI 兼容接口为例from langchain_openai import ChatOpenAI chat_model ChatOpenAI( modelgpt-4o-mini, temperature0.1, ) def ask(question): chunks retriever.invoke(question) prompt build_prompt(question, chunks) answer chat_model.invoke(prompt) return answer.content, chunks answer, chunks ask(这款设备的工作温度范围是多少) print(answer) for i, chunk in enumerate(chunks): print(f\n[来源{i1}] {chunk.page_content})temperature0.1是把创造性压到很低保证回答尽量贴着资料走。如果你用的是开源本地模型比如qwen2.5-7b-instruct同样可以用这套模板只是把模型底座换一下。到这里一个能跑的 RAG 最小闭环就完成了。但代码能跑只是及格线接下来我会讲我在实际项目中怎么排查“AI 还在胡说八道”的具体问题。3.2 想让答案更可信加一个引用和溯源机制上面的代码里提示词已经要求模型标注[来源n]但模型输出的引用不可靠它可能编一个“[来源3]”而实际证据来自[来源1]。要做可信的溯源不能只靠提示词必须做一层硬校验。我的做法是把答案按句子拆开对每个句子做相似度或关键词匹配找出它最可能来自哪几个检索片段。如果句子和所有检索片段的相关度都低于阈值判定该句为“无依据内容”在界面上标红提示用户。这一步可以用简单的 TF-IDF 相似度实现也可以用轻量模型做 embedding 相似度计算。实践中这个“逐句溯源”机制非常有效。我们上线过一个人工复核工具操作员每看一条回答旁边就列出对应的原文片段答得不对的当场标记反馈数据再反哺检索参数优化。做了一阵后最直观的变化就是——胡说率肉眼可见地往下掉因为“在哪个文档哪一页看到的”这个问题让模型没法蒙混过关。3.3 检索不到正确内容时怎么干预混合检索与重排序纯向量检索有个众所周知的短板对大篇幅的数字、型号、专有名词不敏感。你问“设备型号 ABC-2000 的额定电压”向量检索可能把 “ABC-2000” 拆得面目全非召回结果反而被无关内容占满。这种时候光调 embedding 模型不一定有效更好的方案是上混合检索。混合检索简单说就是同时跑一路关键词检索BM25和一路向量检索再把两路结果合并排序。关键词检索擅长精确匹配型号、编号、人名向量检索擅长语义相近的表达。合并时可以用加权和也可以用 RRFReciprocal Rank Fusion算法。RRF 的公式不复杂对于每个文档统计它在各检索结果列表中的排名累加分数1/(rank k)k 一般取 60。相加后按总分排序。这种方法不需要调权重对参数不敏感稳定好用。我在项目中实际测试混合检索比纯向量检索的召回率通常在 10%~20% 左右提升遇到数字型问题提升更明显。重排序是另一层优化召回 20 个候选块用一个跨编码器模型如bge-reranker-v2-m3对“问题 - 候选块”做精细打分只取前 5 个进提示词。重排序的计算成本比向量检索高但好处是能粗筛掉低相关块模型看到的都是高相关内容回答质量自然提升。如果你对准确率要求高建议把重排序加进来如果追求低延迟可以先不加。3.4 多轮对话里的“老毛病”上下文污染单轮问答做好不难多轮对话才是翻车重灾区。很多 RAG 问答在第二轮就开始胡说原因往往不是检索失败而是模型把前几轮的历史对话和当前轮检索到的资料混在一起分不清哪些是“过去的问答内容”哪些是“当前问题的依据”。我处理多轮对话的标准做法是每一轮都重新检索检索时只使用当前问题、必要时加上历史问题改写后的关键词但喂给模型的资料片段只放当前这一轮的检索结果。历史对话记录可以保留给模型做上下文连贯但绝不能让历史聊天内容混进资料片段里。还有一个常见问题是用户追问“那第二点呢”如果只看当前这句话检索完全失效。此时需要先对用户输入做“指代消解”把“第二点”改写为“产品手册里第二点优势是什么”再拿去检索。LangChain 有现成的HistoryAwareRetriever组件可以做核心原理就是先用一个辅助 LLM 调用把对话历史压缩成一条独立的检索查询。处理多轮对话时核心原则是区分“检索的查询”和“回答的上下文”。查询要干净、独立上下文可以携带历史信息但证据只能来自最新检索结果。4. 常见问题与排查技巧实录4.1 典型故障清单与排查路径我把我踩过的坑整理成一张速查表你在调试时遇到问题可以直接对照排查。故障现象可能原因排查与解法答案明显与资料冲突切分边界把关键信息切断检查切分块内容增大重叠度或改用结构感知切分检索出来全是无关片段嵌入模型与数据领域不匹配换中文领域模型改用混合检索答案中一半有依据一半是编的提示词没有限制“不知道就拒答”加入拒答指令开启逐句溯源专有名词频繁识别错向量检索对精确词不敏感加 BM25 关键词检索路用 RRF 合并多轮对话第二轮开始乱历史聊天内容混入证据片段区分检索查询与回答上下文检索结果有但模型没用提示词结构过于复杂简化为系统提示词把资料放人类消息开头切片块数量太多导致超时k 值取太大且没有重排限制候选数,加粗筛后的重排序答案有引文但引文是编的模型生成的引用不受控用相似度做逐句溯源按阈值判定来源4.2 两个我自己踩过的大坑第一个坑是“索引阶段不重名”的坑。有次我在一个项目里改造检索体验索引阶段是用bge-m3生成的向量到查询阶段为了省事换成了另一个 embedding 模型结果线上问答质量断崖式下跌。原因就在两个模型向量空间不一致相似度计算完全失真。后来我规范了流程把 embedding 模型名称写进索引 meta 信息里查询时校验不匹配直接报错。这件事让我长记性嵌入模型的版本管理要和业务代码同等严格。第二个坑是“让模型直接抓文档链接”。早期版本为了让 AI 回答更完整我在提示词里塞了“你可以浏览网页获取更多信息”这句话。结果模型经常开始自由发挥甚至编造一些根本不存在的网页结论。排查之后我把 RAG 的回答范围严格锁定在检索片段内关掉了联网能力模型反而稳定了。很多“AI 胡说”的问题本质上是边界没设清楚模型的自由度越大幻觉率越高。4.3 几个能够显著提准的隐藏技巧再补几条常规文档里不怎么写但极好用的技巧。第一在切分时把文档标题和元数据拼进切块内容里。比如一个百科条目块你可以在正文前加上“条目名称XX 设备”这样一个前缀向量化后检索“XX 设备相关问题”时这个前缀能起到明显的语义锚定作用。第二对检索片段按出版物时间加权。如果知识库里同一主题有旧文档、也有新版文档检索结果要优先展示新版本。做法不复杂在 metadata 里存发布日期合并排序时给新文档加一个时间加权系数。这个技巧在合规资料更新频繁的场景里特别实用。第三针对“不知道”场景单独设计话术。很多系统做不到完美召回当检索为空或得分极低时不要让模型硬答而是走一条专门的兜底流程——提示“资料库中暂无相关信息建议联系人工客服或补充文档”。这一步看似简单却能把用户体验从“答得离谱”救回到“诚实到让人放心”。4.4 从“能跑”到“好用”上线前的评测小册子最后分享一个我一直在用的评测方法当你建立了评测习惯之后RAG 调试不再靠运气而是一步步接近可靠。我会在每个项目里准备一份至少 50 条问题的评测集问题分布在四个类型直接问答如某参数值、多条件查询如某型号在某某环境下的表现、综合归纳如总结某文档的三大要点、边界测试如文档中根本没有答案的问题。每条问题标记标准答案或期望行为回答或拒答。跑评测时针对每一条记录四类指标召回是否正确、答案是否忠实、引用是否真实、是否误拒答。跑完一轮改一个变量再跑一轮。坚持下来你就会看到准确率一点点往上爬直到稳定在一个让人放心的水平。我个人做 RAG 最大的体会是这个系统没有一次调完就能永远不出错的时刻但它是一个越用越懂你的文档的“整理师”。它最重要的能力不是“会说”而是“知道自己知道什么也清楚自己不知道什么”。把“我不知道”作为允许输出的答案把“依据来源”作为强制要求把“检索命中率”作为每次迭代的核心指标你的 AI 就很难再满嘴跑火车。最后再分享一个小小的实操偏好凡是做企业级知识库问答我一定会在每个回答底下挂出“依据片段”哪怕产品经理说界面丑也不要省。这个设计表面上是给用户一个验证入口内里其实是给系统自己的每一次生成打上了信任标记。用户信了系统才能用得起来AI 胡说八道的问题才算真正落地解决。