做大模型应用开发以来我被问得最多的一个问题不是模型怎么选而是怎么让模型知道我们公司内部的知识。你问它报销流程是什么某型号设备怎么维护它要么一本正经地开始编要么直接说不会。一开始有人提议微调结果数据准备了一周效果依然不稳定更新一次还要重训成本高得吓人。后来我转向了检索增强生成RAG也就是把大模型和外部知识库结合起来的应用框架。这篇文章把我踩过的坑、验证过的做法、能直接跑起来的代码以及为什么某些方案会翻车的原因都整理出来希望能成为你入门 RAG 的一份可抄作业参考。1. 先从模型不会的题说起RAG 解决的真实痛点1.1 微调不是万能药很多做知识问答的人第一反应是微调这可以理解模型不会那就教它。但实际操作下来微调在知识型问答场景里有几个绕不开的问题。一是知识覆盖不可控。你准备 1000 条问答对模型看起来会答了但换一种问法可能又不会了。微调是在调整模型对参数空间的记忆它不像数据库查询那样可以做到精确命中。二是更新成本高。业务文档每个月都在变每次更新都要重新准备数据、重新训练、重新测试一个知识问答系统如果周五发现文档改了下周一就要上线新答案微调节奏完全跟不上。三是遗忘问题。微调过的模型可能在新增知识上表现不错但原有的通用能力会下降——这种现象行业内叫灾难性遗忘越是小模型越明显。把微调理解成让一个人去上大学课程可能更容易分清楚它改变的是这个人的长期能力而 RAG 是考试时允许翻参考书它不改变模型本身只是临时给模型提供参考资料。对于知识实时更新、答案需要溯源的场景翻参考书显然比给整个模型补课划算得多。1.2 长上下文窗口来了RAG 还有必要吗现在不少大模型支持很长的上下文窗口动辄几十万字。于是有人质疑既然能把整本手册直接塞进提示词何必还要检索这种想法在单文档、短文档的场景勉强成立但在真实知识库场景会撞墙。首先企业知识库通常是几百上千篇文档不是一篇长文上下文窗口再大也塞不下全部内容。其次token 成本不是线性的塞得越多单次调用越贵响应越慢。更微妙的问题是模型对长上下文的注意力并不均匀大量无关文字混进来时模型反而容易忽略真正关键的段落——这就是所谓的大海捞针困境。长上下文适合读一篇长报告RAG 适合在整个知识库里找答案两者是互补关系不是替代关系。1.3 一张表格看懂三种技术路线的取舍我把微调、RAG、长上下文三者的差异整理成了表格方便决策时快速对照。方案学习方式典型场景更新成本可解释性主要短板微调更新模型参数风格迁移、任务能力增强高每次需要重训低难以追溯依据数据准备重、容易遗忘、成本随版本累积RAG外挂知识库企业内部问答、实时知识检索低更新索引即可高可引用原始片段检索质量决定上限检索失败则全盘失败长上下文一次性塞入大量文本单份长文档阅读理解token 成本随长度急涨中可局部溯源无法覆盖大规模知识库噪声段落干扰注意力2. 拆开 RAG 的骨架索引、检索、生成三段式架构2.1 离线索引阶段知识入库前的三道工序RAG 的第一阶段发生在用户提问之前是把原始文档变成机器可查找格式的过程。这个阶段有三个环节任何一个做得粗糙都会在后续检索阶段暴露问题。第一是文档解析。PDF、Word、Markdown、HTML、扫描件每种的解析难度都不一样。很多 PDF 看着排版正常转出来之后文字是错乱的表格更是重灾区。我个人的经验是如果文档本身就是 Markdown 或结构化 HTML直接用如果是 Word尽量转成 Markdown 再处理如果是复杂排版的 PDF解析后一定要人工抽查几页不要盲目相信解析工具的输出。第二是文本切分。切分是 RAG 项目里最容易影响最终效果的一环。切得太粗一个块里既有背景介绍又有结论检索时会带进大量无关信息切得太细块与块之间语义断裂模型拿到的上下文不够完整。常见的做法是设置 chunk_size块大小和 chunk_overlap相邻块重叠长度。比如块大小 512 个 token重叠 64 个 token这样既保证语义相对完整又不会让边界处的句子被硬生生截断。我后面会详细聊切分踩坑这里先记住一个原则切分不是给程序看的是给模型看的要以语义完整为最高目标。第三是向量化入库。把切好的每个文本块通过嵌入模型转成向量然后写入向量数据库。这一步要额外考虑的是元数据每个块要带上文档编号、章节名、来源链接、更新时间、权限标签等信息。不要小看这些附带字段它们在做知识过滤时至关重要——比如只搜 2024 年之后的文档只搜市场部的资料没有元数据就只能全库一把梭。向量数据库里真正被检索的不止是向量本身元数据过滤往往是召回精度的隐藏功臣。2.2 在线检索阶段把用户问题变成一次模糊匹配用户提问时系统把问题文本转成向量然后在库里做相似度搜索召回最相关的若干文本块。这一步的核心是近似最近邻检索常用的索引结构是 HNSW分层可导航小世界图。听起来复杂思路其实很简单它把向量组织成一个多层图顶层是稀疏的高速公路底层是密集的小路查找时先从顶层粗定位再逐层细化用牺牲少量精度换取远超暴力搜索的速度。检索阶段最容易被忽略的是top-k 的设置。k 太小时容易漏掉正确内容k 太大时又把大量低相关片段混进生成提示干扰模型判断。我在实际项目里的惯用做法是粗召回 20 到 50 个候选块经过重排后只把最相关的 3 到 5 个块留给生成阶段。检索的目的不是把所有相关材料都呈现给模型而是优中选优把噪声压到最低。2.3 生成阶段上下文注入与约束输出召回完成后系统把选出的文本块拼接进 prompt再让大模型基于这些文本生成答案。这个阶段有两个关键设计。第一个是指令模板。模板写的松散还是严格会直接影响回答质量。我常用的基础指令框架是你是一位知识库问答助手。以下是从资料库中检索到的参考片段请依据这些片段回答用户问题。如果片段中没有相关信息请明确回答资料中未找到相关信息不要编造。模板里要显式告诉模型材料不足时如何表现这比单纯说不要编造效果更好。语言模型在明确的负面指令下倾向于说没有相关信息而不是强行给一个错误答案。第二个是引用来源。我通常会在每个参考块前加上编号然后要求模型在回答时用 [1]、[2] 这样的标记标注信息出处。这个设计在真实业务中非常有用用户如果对答案存疑可以直接点开原始文档核实。没有引用机制的 RAG 系统即便回答正确可信度也会大打折扣。3. 检索质量是 RAG 的生死线向量检索、BM25 与重排配合3.1 纯向量检索的短板语义相似不等于相关向量检索的原理是把语义相近的内容映射到高维空间中位置相近的点。它擅长处理用含义不同但语义相近的话提问的场景比如搜怎么报销能找到差旅费用申请流程。但向量模型面对精确标识符时经常失灵。举个例子用户搜DQ-502 型传感器如何校准向量模型会敏感地抓到传感器校准这类语义词召回的可能是其他型号传感器的校准文档而DQ-502这个字符串本身在语义空间里几乎没有权重。反观关键词检索对精确型号、错误代码、人名、缩写等字符串的匹配能力远强于向量检索。更麻烦的是向量模型还容易陷入语义表面相似但实质无关的陷阱。比如项目延期了怎么办和项目延期的原因分析报告两句话在语义空间距离很近但前者要的是处理办法后者是一份事故分析根本不是同一类信息。如果只用纯向量检索这种干扰几乎无法避免。3.2 BM25 与向量检索怎么搭配从并行召回说到 RRF 融合既然向量检索长于语义、短于精确匹配关键词检索长于精确、短于语义泛化那自然想到把两者结合。常见的做法是并行召回同一个 query 同时走向量检索和 BM25 关键词检索各取 top 若干条然后把两路结果混合起来。但混合不是简单的去重拼接因为两类得分的分布区间完全不同没法直接比较谁更优。业界常用的融合算法叫 RRF倒数排名融合公式是score Σ 1 / (k rank_i)其中 rank_i 是某篇文档在第 i 路检索中的排名k 通常取 60。这个公式没有用到具体得分只看排名所以天然规避了不同检索器打分尺度不一致的问题。举例来说一个文本块在向量检索里排第 2在 BM25 里排第 10融合分就是 1/62 1/70约等于 0.0294另一块在两路检索里都排第 30融合分只有 1/90 1/90约等于 0.0222。融合后明显更优。实践下来混合检索比单独任何一种检索都有质的提升尤其是涉及型号代码、政策编号的场景。这里的前提是你得同时维护两套索引BM25 可以直接基于原始文本块构建成本并不高。3.3 重排序召回可以糙精排必须准召回的候选块仍然可能有噪声于是需要重排序这一步。先想清楚两个概念向量检索模型属于双塔结构query 和文本块各自编码成向量后再算相似度。这种结构虽然没有编码交互无法在最后一层对齐 query 与文本块的细微关系但胜在速度快、能应对海量候选。重排序阶段则可以用交互式编码器业内常叫 cross-encoder它把 query 和文本块拼接在一起作为一个整体输入模型逐 token 交互后输出一个相关性打分。效果更准但计算量远大于双塔结构不可能对全库打分。所以工程上的标准做法是两段式检索先靠双塔模型快速筛选出几十个候选再用 cross-encoder 精排最后只把排名前几的块送入生成模块。实际项目里精排打分还有一个用途设置质量阈值。如果精排后最高分都很低说明知识库里可能压根没有相关内容此时就应该触发资料中未找到相关信息的分支而不是强行回答。这一步对压制幻觉非常有效我在 5.3 小节还会展开讲。4. 从零搭一个可用的 RAG 问答服务核心代码与工程选型说明4.1 环境准备与基础选型这一节提供的代码足够跑通一个最小可用系统覆盖文档切分、向量化入库、检索、重排列接口、生成问答完整链路。技术栈选型如下Python 3.10 以上sentence-transformers加载嵌入模型负责文本转向量faiss-cpu本地向量检索简单直接rank_bm25关键词检索实现一个用于精排的 cross-encoder 模型模型服务商提供生成式大模型接口代码里用占位函数表示先安装依赖pip install sentence-transformers faiss-cpu rank_bm25我自己在原型阶段偏好自己动手写而不是直接引入某个全功能框架原因很简单RAG 的每个环节都是可以单独调优的如果你一开始就被框架抽象掩盖了细节出了问题很难判断是哪一环的锅。先把核心逻辑手写完理解了每块的作用再考虑引入框架来减少重复劳动。需要解释一下向量库的选型。FAISS 更适合本地原型和个人项目如果做小型团队知识库想省事可以用带持久化的轻量向量库如果是企业级、数据量千万级、要求高并发则要考虑生产级分布式向量库支持多副本和滚动更新。选型时先看数据量和查询量不要一上来就上重武器。4.2 文档加载与切分假设我们有一份 Markdown 格式的产品手册先加载全文然后做递归字符切分。递归切分的核心逻辑是按预设的分隔符优先级从粗到细拆文本尽量保持段落和句子的完整。# -*- coding: utf-8 -*- from langchain_text_splitters import RecursiveCharacterTextSplitter text open(product_manual.md, encodingutf-8).read() splitter RecursiveCharacterTextSplitter( chunk_size512, # 块大小中文场景按字符计比较稳 chunk_overlap64, # 相邻块重叠保留边界上下文 separators[\n\n, \n, 。, , , , ] ) chunks splitter.split_text(text) print(f共切分为 {len(chunks)} 个文本块)很多文档切分教程用 token 数来算 chunk_size但在中文场景我建议直接按字符数再估 token 数。中文一个字对应 0.6 到 1 个 token 不等按 token 切容易在不同文本块间产生长度抖动。按字符切分更可控参数直觉也更直接。切分完成后抽查几个块确认没有在句子中断开这一步很笨但很有效。4.3 向量化与入库嵌入模型的选择直接影响检索效果。中文场景基本思路是选中文语料上表现好的开源向量模型。加载和编码代码如下from sentence_transformers import SentenceTransformer # 换成你选定的向量模型名称 embedder SentenceTransformer(your-embedding-model-name) dim embedder.get_sentence_embedding_dimension() print(f向量维度: {dim}) # normalize_embeddingsTrue 会把向量归一化便于用内积计算余弦相似度 vectors embedder.encode(chunks, normalize_embeddingsTrue, show_progress_barTrue)建索引时我用 FAISS 的 IndexFlatIP这是暴力精确检索数据量在几十万以内完全够用。如果想再快一点可以换成 HNSW 索引但原型阶段不必着急优化。import faiss import numpy as np dim vectors.shape[1] index faiss.IndexFlatIP(dim) index.add(vectors.astype(np.float32)) # 保存文本块列表和索引后续检索使用 with open(chunks.txt, w, encodingutf-8) as f: for i, c in enumerate(chunks): f.write(f{i}\t{c}\n) faiss.write_index(index, demo.index)要注意IndexFlatIP 配合归一化向量计算的就是余弦相似度分数范围在 -1 到 1 之间在实际检索时这个分数可以作为置信度的参考。4.4 关键词检索与混合召回关键词检索我用 rank_bm25直接对原始文本块做词频统计。中文需要先分词这里用了简单的 jieba 分词生产环境可以换成更规范的词表。import jieba from rank_bm25 import BM25Okapi tokenized_chunks [list(jieba.cut_for_search(c)) for c in chunks] bm25 BM25Okapi(tokenized_chunks) def bm25_search(query, top_k20): tokens list(jieba.cut_for_search(query)) scores bm25.get_scores(tokens) top_indices np.argsort(scores)[::-1][:top_k] return [(i, scores[i]) for i in top_indices]混合召回这里做一个便捷实现。向量检索拿到排名BM25 拿到排名用 RRF 融合后再取前 N 个候选。def vector_search(query, top_k50): qvec embedder.encode([query], normalize_embeddingsTrue) scores, indices index.search(qvec.astype(np.float32), top_k) return [(int(idx), float(score)) for idx, score in zip(indices[0], scores[0]) if idx 0] def rrf_fusion(vector_hits, bm25_hits, k60, top_n50): merged {} def _add(hits): for rank, (idx, score) in enumerate(hits): merged[idx] merged.get(idx, 0.0) 1.0 / (k rank 1) _add(vector_hits) _add(bm25_hits) sorted_hits sorted(merged.items(), keylambda x: x[1], reverseTrue) return sorted_hits[:top_n]召回上下文写在一起生成模块直接调用即可。这套逻辑虽然简单但已经是很多生产级检索系统的缩减版骨架。4.5 重排与生成重排阶段用 cross-encoder 对 query 和候选文本块逐一对打分。这里代码示意如下from sentence_transformers import CrossEncoder reranker CrossEncoder(your-cross-encoder-model-name) def rerank(query, candidates, top_n3): # candidates 是 [(idx, score)] 列表 pairs [(query, chunks[idx]) for idx, _ in candidates] scores reranker.predict(pairs) ranked sorted(zip(candidates, scores), keylambda x: x[1], reverseTrue) return [(idx, float(score)) for (idx, _), score in ranked[:top_n]]生成部分我们预留一个接口函数调用大模型你把它替换成任何一家模型服务的 SDK 或 HTTP 调用即可。这个位置刻意留白是为了让你聚焦在 RAG 流程本身。def ask_llm(prompt: str) - str: # 在这里接入你的大模型服务商接口 # 例如通过 HTTP 请求或 SDK 调用把 prompt 发送给模型返回生成的文本 raise NotImplementedError(替换为实际大模型调用即可)最终把检索、重排、生成串起来def rag_answer(question: str) - str: # 1. 向量召回 v_hits vector_search(question, top_k30) # 2. 关键词召回 b_hits bm25_search(question, top_k30) # 3. RRF 混合 fused rrf_fusion(v_hits, b_hits, top_n15) # 4. 重排最终只保留 3 条 final rerank(question, fused, top_n3) context_block \n\n.join( f[{i1}] {chunks[idx]} for i, (idx, score) in enumerate(final) ) prompt f你是企业知识库问答助手。请依据下面的资料片段回答用户问题。若资料无法支撑答案请直接回复资料中未找到相关信息。 资料片段 {context_block} 用户问题{question} 请你结合资料片段给出准确回答并在句末用 [编号] 标注来源。 return ask_llm(prompt)这套代码是一个完整的最小实现。把占位模型名换掉、把 ask_llm 接到你的模型接口上就可以跑起来。4.6 离线评测别凭感觉调参RAG 系统最忌讳感觉好就上线。我在项目里至少会建两套评测数据。第一套是检索评测集格式是问题 - 应该命中的文本块编号。跑完检索后计算命中率看正确块有没有进 final 列表。第二套是回答评测集每个问题配参考答案用一个大模型作为裁判打分或者直接人工审核。评测维度通常包括准确性、完整性、是否包含无关信息、引用是否对应。我自己的经验指标配置大概是这样指标建议目标说明向量检索命中率Recall2090% 以上正确块是否进入粗召回候选重排后命中率Recall370% 以上正确块是否进入生成上下文回答准确率85% 以上最终答案与标准答案是否一致回答覆盖率90% 以上问题是否都有合理回答不无故拒答P95 延迟3 秒以内用户体验底线没有评测集之前所有调参都是盲人摸象。建立评测集虽然是脏活累活但它是整个项目能持续迭代的基础。5. 踩坑实录切分粒度、上下文注入与幻觉回归5.1 切分粒度的两难太碎掉上下文太长稀释相关性我处理过一份某设备的维护手册按章节切块每块 3000 多字符结果用户问柜内温度传感器异常时先检查什么召回的是整个章节包含大量安装背景模型生成的回答被无关内容带偏。后来我把块调小到 400 字符又发现问题召回片段里出现该设备时因为没有前文模型根本不知道该设备指什么。这个两难问题的解法不是死磕一个万能 chunk_size而是要引入结构和父子信息。更合理的做法是先按章节拆出父块再在父块内部按段落或固定长度拆出子块。检索时在子块上做匹配但如果命中的子块来自某个父块可以同时把父块或相邻子块一并提供给模型保持上下文完整。这种粗块定位、细块召回的设计工程上叫父子切分实战中非常有效。另外一个容易踩的坑是切分与嵌入模型的 token 上限不匹配。如果嵌入模型最长支持 512 个 token你却切了 1000 个字符的块超出部分会被截断等于向量只编码了前半截信息。设置 chunk_size 前先查一下你的嵌入模型上限。5.2 上下文注入模板的隐藏影响prompt 模板对回答效果的影响经常被低估。我做过一次对比第一版模板写请严格根据资料回答不要使用你的既有知识模型变得极其保守很多常识性问题也回资料中未找到相关信息拒答率飙升第二版模板写请优先依据资料资料缺失时可用你的知识补充准确率上来了但幻觉也增加了因为模型会在资料不支持的情况下补出模棱两可的内容。折中方案是给模型分层授权资料相关度高时要求严格引用资料资料明显不足时先明确说资料不足再客观说明。更细腻一点的指令是不要模棱两可。模型最怕的是尽力回答这种指令——它会在没有依据的情况下尽力编造。宁可让它直接承认不知道也不要让它给一个看似合理但不可信的答案。5.3 幻觉回归检索到了但生成错了有一种幻觉非常隐蔽——知识库里明明有正确资料模型在生成时却答错了。比如资料里写系统默认超时时间为 30 秒用户问系统超时时间怎么调模型却回答超时时间为 60 秒可在配置文件中调整。这类问题通常出在三个环节一是上下文拼接时混入了其他相似但错误的内容比如库里有多个版本的配置说明新老版本同时被召回模型选错了二是 prompt 缺少严格基于资料约束三是精排分数没有设置阈值低质量上下文也被送进生成器。排查思路是先把检索和生成拆开测单独打印召回的三个片段人工判断资料是否已经覆盖答案。如果召回正确而回答错误问题在 prompt 或模型如果召回本身就错误问题在检索链路。常见做法是记录每次问答的检索片段和生成结果到日志出现幻觉后回查日志定位具体环节。5.4 索引更新、缓存与降级线上 RAG 系统除了算法问题还有一堆工程问题。文档更新频繁时最粗暴的做法是每天凌晨全量重建索引数据量不大时完全够用。数据量大且更新频繁时就需要增量入库给每个文本块算一个内容 hash入库前对比是否已存在同时保留文档 ID - 块 ID的映射方便文档删除时连带删除对应的向量。用 FAISS 做演示很方便但要注意 FAISS 的 IndexFlatIP 和部分索引结构不支持删除单条向量。如果业务有频繁删除需求建议换支持删除的向量库或者在应用层做软删除——检索结果过滤掉已删除文档的块。这个细节看起来小上线后遇到删了文档还能搜出来的投诉时你会后悔没早处理。缓存和降级同样不能忘。热点问题走缓存能省下大量生成调用向量库崩溃时至少要能返回当前知识库服务不可用而不是让用户面对一个 500 错误。降级的底线是可以答不了但不能瞎答。5.5 权限过滤企业落地绕不开的一关企业内部知识问答如果没有权限控制会出现灾难性事故。文档级别的权限通常记录在元数据里检索时除了算相似度还要加一道过滤条件用户所属部门可见的文档范围、文档密级标签等。更细的权限到段落级别时单纯靠过滤已经不够需要在入库前就区分密级块。我见过一个教训某个系统的检索结果把一份内部薪资政策的摘要混进普通员工的上下文里模型基于它回答了敏感问题虽然没有直接泄露全文但已经被安全团队约谈。做企业级 RAG权限体系在第一天就要设计而不是上线后再补。6. 一点个人经验收尾做了一轮 RAG 项目之后我自己的体会是这个技术架构的门槛不在代码而在于你有没有把每个环节都当做一个可评测、可优化的独立模块。索引阶段偷的懒会在检索阶段加倍还回来检索阶段省掉的重排会在生成阶段变成一本正经的胡话。整套系统里检索质量决定上限生成质量决定下限prompt 模板决定稳定性权限工程决定能不能上线。最后再分享一个小技巧每次调参不要只盯单条测试样本的效果要固定一套评测集批量跑分后再看分项指标。我在实际项目中没少因为单条样例很完美而误判整体效果最后都是靠评测集拉回正轨的。RAG 的应用空间还在快速扩展但核心逻辑没有变——让模型在正确的时间看到正确的资料。先把这一点做扎实后面的优化才有意义。 
长河君 · 2026/10/20 9:53:02 · 阅读 1.2k RAG知识库问答实战：从架构原理到代码实现，解决大模型企业知识检索难题
做大模型应用开发以来我被问得最多的一个问题不是模型怎么选而是怎么让模型知道我们公司内部的知识。你问它报销流程是什么某型号设备怎么维护它要么一本正经地开始编要么直接说不会。一开始有人提议微调结果数据准备了一周效果依然不稳定更新一次还要重训成本高得吓人。后来我转向了检索增强生成RAG也就是把大模型和外部知识库结合起来的应用框架。这篇文章把我踩过的坑、验证过的做法、能直接跑起来的代码以及为什么某些方案会翻车的原因都整理出来希望能成为你入门 RAG 的一份可抄作业参考。1. 先从模型不会的题说起RAG 解决的真实痛点1.1 微调不是万能药很多做知识问答的人第一反应是微调这可以理解模型不会那就教它。但实际操作下来微调在知识型问答场景里有几个绕不开的问题。一是知识覆盖不可控。你准备 1000 条问答对模型看起来会答了但换一种问法可能又不会了。微调是在调整模型对参数空间的记忆它不像数据库查询那样可以做到精确命中。二是更新成本高。业务文档每个月都在变每次更新都要重新准备数据、重新训练、重新测试一个知识问答系统如果周五发现文档改了下周一就要上线新答案微调节奏完全跟不上。三是遗忘问题。微调过的模型可能在新增知识上表现不错但原有的通用能力会下降——这种现象行业内叫灾难性遗忘越是小模型越明显。把微调理解成让一个人去上大学课程可能更容易分清楚它改变的是这个人的长期能力而 RAG 是考试时允许翻参考书它不改变模型本身只是临时给模型提供参考资料。对于知识实时更新、答案需要溯源的场景翻参考书显然比给整个模型补课划算得多。1.2 长上下文窗口来了RAG 还有必要吗现在不少大模型支持很长的上下文窗口动辄几十万字。于是有人质疑既然能把整本手册直接塞进提示词何必还要检索这种想法在单文档、短文档的场景勉强成立但在真实知识库场景会撞墙。首先企业知识库通常是几百上千篇文档不是一篇长文上下文窗口再大也塞不下全部内容。其次token 成本不是线性的塞得越多单次调用越贵响应越慢。更微妙的问题是模型对长上下文的注意力并不均匀大量无关文字混进来时模型反而容易忽略真正关键的段落——这就是所谓的大海捞针困境。长上下文适合读一篇长报告RAG 适合在整个知识库里找答案两者是互补关系不是替代关系。1.3 一张表格看懂三种技术路线的取舍我把微调、RAG、长上下文三者的差异整理成了表格方便决策时快速对照。方案学习方式典型场景更新成本可解释性主要短板微调更新模型参数风格迁移、任务能力增强高每次需要重训低难以追溯依据数据准备重、容易遗忘、成本随版本累积RAG外挂知识库企业内部问答、实时知识检索低更新索引即可高可引用原始片段检索质量决定上限检索失败则全盘失败长上下文一次性塞入大量文本单份长文档阅读理解token 成本随长度急涨中可局部溯源无法覆盖大规模知识库噪声段落干扰注意力2. 拆开 RAG 的骨架索引、检索、生成三段式架构2.1 离线索引阶段知识入库前的三道工序RAG 的第一阶段发生在用户提问之前是把原始文档变成机器可查找格式的过程。这个阶段有三个环节任何一个做得粗糙都会在后续检索阶段暴露问题。第一是文档解析。PDF、Word、Markdown、HTML、扫描件每种的解析难度都不一样。很多 PDF 看着排版正常转出来之后文字是错乱的表格更是重灾区。我个人的经验是如果文档本身就是 Markdown 或结构化 HTML直接用如果是 Word尽量转成 Markdown 再处理如果是复杂排版的 PDF解析后一定要人工抽查几页不要盲目相信解析工具的输出。第二是文本切分。切分是 RAG 项目里最容易影响最终效果的一环。切得太粗一个块里既有背景介绍又有结论检索时会带进大量无关信息切得太细块与块之间语义断裂模型拿到的上下文不够完整。常见的做法是设置 chunk_size块大小和 chunk_overlap相邻块重叠长度。比如块大小 512 个 token重叠 64 个 token这样既保证语义相对完整又不会让边界处的句子被硬生生截断。我后面会详细聊切分踩坑这里先记住一个原则切分不是给程序看的是给模型看的要以语义完整为最高目标。第三是向量化入库。把切好的每个文本块通过嵌入模型转成向量然后写入向量数据库。这一步要额外考虑的是元数据每个块要带上文档编号、章节名、来源链接、更新时间、权限标签等信息。不要小看这些附带字段它们在做知识过滤时至关重要——比如只搜 2024 年之后的文档只搜市场部的资料没有元数据就只能全库一把梭。向量数据库里真正被检索的不止是向量本身元数据过滤往往是召回精度的隐藏功臣。2.2 在线检索阶段把用户问题变成一次模糊匹配用户提问时系统把问题文本转成向量然后在库里做相似度搜索召回最相关的若干文本块。这一步的核心是近似最近邻检索常用的索引结构是 HNSW分层可导航小世界图。听起来复杂思路其实很简单它把向量组织成一个多层图顶层是稀疏的高速公路底层是密集的小路查找时先从顶层粗定位再逐层细化用牺牲少量精度换取远超暴力搜索的速度。检索阶段最容易被忽略的是top-k 的设置。k 太小时容易漏掉正确内容k 太大时又把大量低相关片段混进生成提示干扰模型判断。我在实际项目里的惯用做法是粗召回 20 到 50 个候选块经过重排后只把最相关的 3 到 5 个块留给生成阶段。检索的目的不是把所有相关材料都呈现给模型而是优中选优把噪声压到最低。2.3 生成阶段上下文注入与约束输出召回完成后系统把选出的文本块拼接进 prompt再让大模型基于这些文本生成答案。这个阶段有两个关键设计。第一个是指令模板。模板写的松散还是严格会直接影响回答质量。我常用的基础指令框架是你是一位知识库问答助手。以下是从资料库中检索到的参考片段请依据这些片段回答用户问题。如果片段中没有相关信息请明确回答资料中未找到相关信息不要编造。模板里要显式告诉模型材料不足时如何表现这比单纯说不要编造效果更好。语言模型在明确的负面指令下倾向于说没有相关信息而不是强行给一个错误答案。第二个是引用来源。我通常会在每个参考块前加上编号然后要求模型在回答时用 [1]、[2] 这样的标记标注信息出处。这个设计在真实业务中非常有用用户如果对答案存疑可以直接点开原始文档核实。没有引用机制的 RAG 系统即便回答正确可信度也会大打折扣。3. 检索质量是 RAG 的生死线向量检索、BM25 与重排配合3.1 纯向量检索的短板语义相似不等于相关向量检索的原理是把语义相近的内容映射到高维空间中位置相近的点。它擅长处理用含义不同但语义相近的话提问的场景比如搜怎么报销能找到差旅费用申请流程。但向量模型面对精确标识符时经常失灵。举个例子用户搜DQ-502 型传感器如何校准向量模型会敏感地抓到传感器校准这类语义词召回的可能是其他型号传感器的校准文档而DQ-502这个字符串本身在语义空间里几乎没有权重。反观关键词检索对精确型号、错误代码、人名、缩写等字符串的匹配能力远强于向量检索。更麻烦的是向量模型还容易陷入语义表面相似但实质无关的陷阱。比如项目延期了怎么办和项目延期的原因分析报告两句话在语义空间距离很近但前者要的是处理办法后者是一份事故分析根本不是同一类信息。如果只用纯向量检索这种干扰几乎无法避免。3.2 BM25 与向量检索怎么搭配从并行召回说到 RRF 融合既然向量检索长于语义、短于精确匹配关键词检索长于精确、短于语义泛化那自然想到把两者结合。常见的做法是并行召回同一个 query 同时走向量检索和 BM25 关键词检索各取 top 若干条然后把两路结果混合起来。但混合不是简单的去重拼接因为两类得分的分布区间完全不同没法直接比较谁更优。业界常用的融合算法叫 RRF倒数排名融合公式是score Σ 1 / (k rank_i)其中 rank_i 是某篇文档在第 i 路检索中的排名k 通常取 60。这个公式没有用到具体得分只看排名所以天然规避了不同检索器打分尺度不一致的问题。举例来说一个文本块在向量检索里排第 2在 BM25 里排第 10融合分就是 1/62 1/70约等于 0.0294另一块在两路检索里都排第 30融合分只有 1/90 1/90约等于 0.0222。融合后明显更优。实践下来混合检索比单独任何一种检索都有质的提升尤其是涉及型号代码、政策编号的场景。这里的前提是你得同时维护两套索引BM25 可以直接基于原始文本块构建成本并不高。3.3 重排序召回可以糙精排必须准召回的候选块仍然可能有噪声于是需要重排序这一步。先想清楚两个概念向量检索模型属于双塔结构query 和文本块各自编码成向量后再算相似度。这种结构虽然没有编码交互无法在最后一层对齐 query 与文本块的细微关系但胜在速度快、能应对海量候选。重排序阶段则可以用交互式编码器业内常叫 cross-encoder它把 query 和文本块拼接在一起作为一个整体输入模型逐 token 交互后输出一个相关性打分。效果更准但计算量远大于双塔结构不可能对全库打分。所以工程上的标准做法是两段式检索先靠双塔模型快速筛选出几十个候选再用 cross-encoder 精排最后只把排名前几的块送入生成模块。实际项目里精排打分还有一个用途设置质量阈值。如果精排后最高分都很低说明知识库里可能压根没有相关内容此时就应该触发资料中未找到相关信息的分支而不是强行回答。这一步对压制幻觉非常有效我在 5.3 小节还会展开讲。4. 从零搭一个可用的 RAG 问答服务核心代码与工程选型说明4.1 环境准备与基础选型这一节提供的代码足够跑通一个最小可用系统覆盖文档切分、向量化入库、检索、重排列接口、生成问答完整链路。技术栈选型如下Python 3.10 以上sentence-transformers加载嵌入模型负责文本转向量faiss-cpu本地向量检索简单直接rank_bm25关键词检索实现一个用于精排的 cross-encoder 模型模型服务商提供生成式大模型接口代码里用占位函数表示先安装依赖pip install sentence-transformers faiss-cpu rank_bm25我自己在原型阶段偏好自己动手写而不是直接引入某个全功能框架原因很简单RAG 的每个环节都是可以单独调优的如果你一开始就被框架抽象掩盖了细节出了问题很难判断是哪一环的锅。先把核心逻辑手写完理解了每块的作用再考虑引入框架来减少重复劳动。需要解释一下向量库的选型。FAISS 更适合本地原型和个人项目如果做小型团队知识库想省事可以用带持久化的轻量向量库如果是企业级、数据量千万级、要求高并发则要考虑生产级分布式向量库支持多副本和滚动更新。选型时先看数据量和查询量不要一上来就上重武器。4.2 文档加载与切分假设我们有一份 Markdown 格式的产品手册先加载全文然后做递归字符切分。递归切分的核心逻辑是按预设的分隔符优先级从粗到细拆文本尽量保持段落和句子的完整。# -*- coding: utf-8 -*- from langchain_text_splitters import RecursiveCharacterTextSplitter text open(product_manual.md, encodingutf-8).read() splitter RecursiveCharacterTextSplitter( chunk_size512, # 块大小中文场景按字符计比较稳 chunk_overlap64, # 相邻块重叠保留边界上下文 separators[\n\n, \n, 。, , , , ] ) chunks splitter.split_text(text) print(f共切分为 {len(chunks)} 个文本块)很多文档切分教程用 token 数来算 chunk_size但在中文场景我建议直接按字符数再估 token 数。中文一个字对应 0.6 到 1 个 token 不等按 token 切容易在不同文本块间产生长度抖动。按字符切分更可控参数直觉也更直接。切分完成后抽查几个块确认没有在句子中断开这一步很笨但很有效。4.3 向量化与入库嵌入模型的选择直接影响检索效果。中文场景基本思路是选中文语料上表现好的开源向量模型。加载和编码代码如下from sentence_transformers import SentenceTransformer # 换成你选定的向量模型名称 embedder SentenceTransformer(your-embedding-model-name) dim embedder.get_sentence_embedding_dimension() print(f向量维度: {dim}) # normalize_embeddingsTrue 会把向量归一化便于用内积计算余弦相似度 vectors embedder.encode(chunks, normalize_embeddingsTrue, show_progress_barTrue)建索引时我用 FAISS 的 IndexFlatIP这是暴力精确检索数据量在几十万以内完全够用。如果想再快一点可以换成 HNSW 索引但原型阶段不必着急优化。import faiss import numpy as np dim vectors.shape[1] index faiss.IndexFlatIP(dim) index.add(vectors.astype(np.float32)) # 保存文本块列表和索引后续检索使用 with open(chunks.txt, w, encodingutf-8) as f: for i, c in enumerate(chunks): f.write(f{i}\t{c}\n) faiss.write_index(index, demo.index)要注意IndexFlatIP 配合归一化向量计算的就是余弦相似度分数范围在 -1 到 1 之间在实际检索时这个分数可以作为置信度的参考。4.4 关键词检索与混合召回关键词检索我用 rank_bm25直接对原始文本块做词频统计。中文需要先分词这里用了简单的 jieba 分词生产环境可以换成更规范的词表。import jieba from rank_bm25 import BM25Okapi tokenized_chunks [list(jieba.cut_for_search(c)) for c in chunks] bm25 BM25Okapi(tokenized_chunks) def bm25_search(query, top_k20): tokens list(jieba.cut_for_search(query)) scores bm25.get_scores(tokens) top_indices np.argsort(scores)[::-1][:top_k] return [(i, scores[i]) for i in top_indices]混合召回这里做一个便捷实现。向量检索拿到排名BM25 拿到排名用 RRF 融合后再取前 N 个候选。def vector_search(query, top_k50): qvec embedder.encode([query], normalize_embeddingsTrue) scores, indices index.search(qvec.astype(np.float32), top_k) return [(int(idx), float(score)) for idx, score in zip(indices[0], scores[0]) if idx 0] def rrf_fusion(vector_hits, bm25_hits, k60, top_n50): merged {} def _add(hits): for rank, (idx, score) in enumerate(hits): merged[idx] merged.get(idx, 0.0) 1.0 / (k rank 1) _add(vector_hits) _add(bm25_hits) sorted_hits sorted(merged.items(), keylambda x: x[1], reverseTrue) return sorted_hits[:top_n]召回上下文写在一起生成模块直接调用即可。这套逻辑虽然简单但已经是很多生产级检索系统的缩减版骨架。4.5 重排与生成重排阶段用 cross-encoder 对 query 和候选文本块逐一对打分。这里代码示意如下from sentence_transformers import CrossEncoder reranker CrossEncoder(your-cross-encoder-model-name) def rerank(query, candidates, top_n3): # candidates 是 [(idx, score)] 列表 pairs [(query, chunks[idx]) for idx, _ in candidates] scores reranker.predict(pairs) ranked sorted(zip(candidates, scores), keylambda x: x[1], reverseTrue) return [(idx, float(score)) for (idx, _), score in ranked[:top_n]]生成部分我们预留一个接口函数调用大模型你把它替换成任何一家模型服务的 SDK 或 HTTP 调用即可。这个位置刻意留白是为了让你聚焦在 RAG 流程本身。def ask_llm(prompt: str) - str: # 在这里接入你的大模型服务商接口 # 例如通过 HTTP 请求或 SDK 调用把 prompt 发送给模型返回生成的文本 raise NotImplementedError(替换为实际大模型调用即可)最终把检索、重排、生成串起来def rag_answer(question: str) - str: # 1. 向量召回 v_hits vector_search(question, top_k30) # 2. 关键词召回 b_hits bm25_search(question, top_k30) # 3. RRF 混合 fused rrf_fusion(v_hits, b_hits, top_n15) # 4. 重排最终只保留 3 条 final rerank(question, fused, top_n3) context_block \n\n.join( f[{i1}] {chunks[idx]} for i, (idx, score) in enumerate(final) ) prompt f你是企业知识库问答助手。请依据下面的资料片段回答用户问题。若资料无法支撑答案请直接回复资料中未找到相关信息。 资料片段 {context_block} 用户问题{question} 请你结合资料片段给出准确回答并在句末用 [编号] 标注来源。 return ask_llm(prompt)这套代码是一个完整的最小实现。把占位模型名换掉、把 ask_llm 接到你的模型接口上就可以跑起来。4.6 离线评测别凭感觉调参RAG 系统最忌讳感觉好就上线。我在项目里至少会建两套评测数据。第一套是检索评测集格式是问题 - 应该命中的文本块编号。跑完检索后计算命中率看正确块有没有进 final 列表。第二套是回答评测集每个问题配参考答案用一个大模型作为裁判打分或者直接人工审核。评测维度通常包括准确性、完整性、是否包含无关信息、引用是否对应。我自己的经验指标配置大概是这样指标建议目标说明向量检索命中率Recall2090% 以上正确块是否进入粗召回候选重排后命中率Recall370% 以上正确块是否进入生成上下文回答准确率85% 以上最终答案与标准答案是否一致回答覆盖率90% 以上问题是否都有合理回答不无故拒答P95 延迟3 秒以内用户体验底线没有评测集之前所有调参都是盲人摸象。建立评测集虽然是脏活累活但它是整个项目能持续迭代的基础。5. 踩坑实录切分粒度、上下文注入与幻觉回归5.1 切分粒度的两难太碎掉上下文太长稀释相关性我处理过一份某设备的维护手册按章节切块每块 3000 多字符结果用户问柜内温度传感器异常时先检查什么召回的是整个章节包含大量安装背景模型生成的回答被无关内容带偏。后来我把块调小到 400 字符又发现问题召回片段里出现该设备时因为没有前文模型根本不知道该设备指什么。这个两难问题的解法不是死磕一个万能 chunk_size而是要引入结构和父子信息。更合理的做法是先按章节拆出父块再在父块内部按段落或固定长度拆出子块。检索时在子块上做匹配但如果命中的子块来自某个父块可以同时把父块或相邻子块一并提供给模型保持上下文完整。这种粗块定位、细块召回的设计工程上叫父子切分实战中非常有效。另外一个容易踩的坑是切分与嵌入模型的 token 上限不匹配。如果嵌入模型最长支持 512 个 token你却切了 1000 个字符的块超出部分会被截断等于向量只编码了前半截信息。设置 chunk_size 前先查一下你的嵌入模型上限。5.2 上下文注入模板的隐藏影响prompt 模板对回答效果的影响经常被低估。我做过一次对比第一版模板写请严格根据资料回答不要使用你的既有知识模型变得极其保守很多常识性问题也回资料中未找到相关信息拒答率飙升第二版模板写请优先依据资料资料缺失时可用你的知识补充准确率上来了但幻觉也增加了因为模型会在资料不支持的情况下补出模棱两可的内容。折中方案是给模型分层授权资料相关度高时要求严格引用资料资料明显不足时先明确说资料不足再客观说明。更细腻一点的指令是不要模棱两可。模型最怕的是尽力回答这种指令——它会在没有依据的情况下尽力编造。宁可让它直接承认不知道也不要让它给一个看似合理但不可信的答案。5.3 幻觉回归检索到了但生成错了有一种幻觉非常隐蔽——知识库里明明有正确资料模型在生成时却答错了。比如资料里写系统默认超时时间为 30 秒用户问系统超时时间怎么调模型却回答超时时间为 60 秒可在配置文件中调整。这类问题通常出在三个环节一是上下文拼接时混入了其他相似但错误的内容比如库里有多个版本的配置说明新老版本同时被召回模型选错了二是 prompt 缺少严格基于资料约束三是精排分数没有设置阈值低质量上下文也被送进生成器。排查思路是先把检索和生成拆开测单独打印召回的三个片段人工判断资料是否已经覆盖答案。如果召回正确而回答错误问题在 prompt 或模型如果召回本身就错误问题在检索链路。常见做法是记录每次问答的检索片段和生成结果到日志出现幻觉后回查日志定位具体环节。5.4 索引更新、缓存与降级线上 RAG 系统除了算法问题还有一堆工程问题。文档更新频繁时最粗暴的做法是每天凌晨全量重建索引数据量不大时完全够用。数据量大且更新频繁时就需要增量入库给每个文本块算一个内容 hash入库前对比是否已存在同时保留文档 ID - 块 ID的映射方便文档删除时连带删除对应的向量。用 FAISS 做演示很方便但要注意 FAISS 的 IndexFlatIP 和部分索引结构不支持删除单条向量。如果业务有频繁删除需求建议换支持删除的向量库或者在应用层做软删除——检索结果过滤掉已删除文档的块。这个细节看起来小上线后遇到删了文档还能搜出来的投诉时你会后悔没早处理。缓存和降级同样不能忘。热点问题走缓存能省下大量生成调用向量库崩溃时至少要能返回当前知识库服务不可用而不是让用户面对一个 500 错误。降级的底线是可以答不了但不能瞎答。5.5 权限过滤企业落地绕不开的一关企业内部知识问答如果没有权限控制会出现灾难性事故。文档级别的权限通常记录在元数据里检索时除了算相似度还要加一道过滤条件用户所属部门可见的文档范围、文档密级标签等。更细的权限到段落级别时单纯靠过滤已经不够需要在入库前就区分密级块。我见过一个教训某个系统的检索结果把一份内部薪资政策的摘要混进普通员工的上下文里模型基于它回答了敏感问题虽然没有直接泄露全文但已经被安全团队约谈。做企业级 RAG权限体系在第一天就要设计而不是上线后再补。6. 一点个人经验收尾做了一轮 RAG 项目之后我自己的体会是这个技术架构的门槛不在代码而在于你有没有把每个环节都当做一个可评测、可优化的独立模块。索引阶段偷的懒会在检索阶段加倍还回来检索阶段省掉的重排会在生成阶段变成一本正经的胡话。整套系统里检索质量决定上限生成质量决定下限prompt 模板决定稳定性权限工程决定能不能上线。最后再分享一个小技巧每次调参不要只盯单条测试样本的效果要固定一套评测集批量跑分后再看分项指标。我在实际项目中没少因为单条样例很完美而误判整体效果最后都是靠评测集拉回正轨的。RAG 的应用空间还在快速扩展但核心逻辑没有变——让模型在正确的时间看到正确的资料。先把这一点做扎实后面的优化才有意义。