最近如果你在关注大模型方向一定没少听到RAG这个词。RAG全称Retrieval-Augmented Generation也就是检索增强生成核心思路其实一句话就能讲明白先检索再生成。大模型有再强的推理能力遇到不知道的知识也只会一本正经地胡说八道RAG就是给它外挂一个可随时查询的知识库让模型在回答之前先去库里捞证据再基于证据作答。这篇文章我准备从零开始把这个技术栈完整过一遍从RAG要解决什么问题讲起到环境搭建、知识库构建、检索链路、代码实现再到参数调优和踩坑实录全程带代码。不管你是刚接触RAG的新手还是已经在做AI应用开发、想把手里的私有知识库接进大模型的工程师这篇文章都值得你花半小时认真读完。我尽量不堆术语用大白话把原理和实操讲透保证你看完能直接上手写一个能用的RAG系统。1. 先搞清楚RAG到底在解决什么问题1.1 大模型的三个短板以及为什么大家开始聊RAG做AI应用时间长了你会发现大模型本身有很明显的三个短板。第一个是知识时效性问题。模型训练一次成本很高训练完成之后知识就固定了。今天刚发布的新闻、公司内部的规章制度、项目实施文档这些内容模型不可能知道。你问它一个刚发生的事件它要么答不上来要么按照旧知识瞎编。第二个是幻觉问题。大模型的本质是预测下一个词它并不真正理解事实和编造之间的边界。在它不确定的领域里它倾向于用一种非常自信的语气编出看起来合理的答案。在专业场景里这种幻觉是致命的没人敢拿一个可能瞎编的模型去做法律咨询或医疗问答。第三个是隐私与数据隔离问题。很多企业有大量的私有文档——客户数据、技术手册、内部流程文件这些数据不能拿去训练通用大模型但业务上又确实需要模型能理解并使用这些数据。数据出域和模型能力之间天然存在矛盾。RAG就是针对这三个问题被大量采用的方案。它的做法是模型本体不动在模型外面接一个知识库。用户提问时先从知识库里把最相关的文档片段检索出来拼进提示词里再让模型基于这些检索到的材料组织答案。知识更新了就更新知识库不需要重新训练模型回答都有出处幻觉被大幅压制私有数据始终在自己的存储里只把检索到的片段传给模型接口可控性高得多。用生活里的例子类比。RAG给大模型配了一个开卷考试的机会。模型本身不是百科全书但考试时允许它翻资料——考什么查什么查到了再答。对比之下微调Fine-tuning就像是让模型把整本教材背下来成本高、更新慢背完之后考试范围变了还得重新背。1.2 RAG整体链路拆解离线建库与在线问答整个RAG系统可以从时间维度拆成两条链路离线知识库构建链路和在线问答推理链路。离线链路负责把原始文档变成可检索的向量索引。流程大致是文档加载从PDF、Word、网页里抽出文本→ 文本清洗去掉页眉页脚、特殊符号→ 文本切分把长文档切成适合检索的片段也叫Chunk→ 向量化用Embedding模型把每个片段转换成一串浮点数向量→ 索引存储把向量和原始文本写进向量数据库。这一步做完知识库就建好了接下来所有问答都建在它上面。在线链路负责处理用户请求。流程是用户提问 → 把问题也向量化 → 在知识库里做相似度检索取出最相关的TopK个片段 → 把片段和问题组装成提示词 → 调用大模型生成答案 → 返回结果。理解这两条链路是掌握RAG的关键后面每一节我都是在围绕这两个链路展开。你可以把离线链路理解为整理书架在线链路理解为查资料写报告整个RAG系统就是这么简单的逻辑骨架。1.3 什么时候该用RAG什么时候别硬上我见过不少团队把RAG当成万能药啥都往上套。但其实RAG不是所有场景的最优解搞清楚边界能帮你省很多事。适合用RAG的场景有几个特征知识是静态或低频更新的文档型数据对答案时效性和准确性有明确要求私有数据不能出域但需要模型理解答案需要追溯原始出处。不适合硬上RAG的场景也有如果知识库很小几百条规则就能覆盖不如直接把规则写进提示词系统提示词里如果问题需要多步推理和复杂计算比如帮我算一下这个季度各项目组的投入产出比RAG检索出来的片段可能帮不上忙更好的方案是让模型调用工具去查数据库做计算如果数据是高度结构化的表格用 Text-to-SQL 或直接查询数据库往往比RAG更可靠。另外我特别想说一句RAG解决的是模型不知道的问题解决不了逻辑抽风的问题。如果模型本身推理能力太弱接多少知识库都没用。选型时先评估模型能力再决定要不要上RAG。2. 从零搭建RAG的技术选型与代码骨架2.1 极简技术栈模型接口、向量存储与代码框架怎么选动手写第一版RAG时建议把所有组件拆成三块Embedding模型负责向量化文本、大语言模型负责生成答案、向量存储负责存向量和检索。Embedding模型的作用是把文本变成一串数字向量让语义相近的句子在向量空间里距离更近。选型标准主要看三点一是中文效果好不好二是向量维度是否稳定三是Embedding服务是否方便接入。中文场景下目前有不少开源Embedding模型效果已经很能打我建议优先找一个在中文语义相似度评测上表现稳定的开源模型部署成本低数据也不必送到外部。至于具体用哪个厂商的不在这篇里点名你自己在开源社区里按评测榜单挑一个即可。大语言模型的选择跟你的场景强相关。如果对隐私要求高就部署本地开源模型如果对效果要求高且允许数据出域可以选商用API。我见过很多团队用同一个接口兼容层把本地和云端模型都包起来切换只改一个环境变量这个思路强烈推荐。它让你在调试阶段先用云端模型验证效果确定了方向再迁移到本地避免反复改代码。向量存储在入门阶段我建议别急着上重量级的向量数据库服务。先用本地的近似最近邻检索库甚至极端情况下自己算余弦相似度都行逻辑完全一样。等到数据量级上来了、需要持久化和并发查询了再迁移到专门的向量数据库。一上来就引一堆分布式组件只会让你排查问题时多十几层干扰。代码框架方面社区里现在有两套主流工具链一套偏组件化封装文档多、上手快但抽象层次高出了问题你不太容易看到底层在做什么另一套偏灵活组合自由度更高但你需要自己串流程。我的建议是学习阶段尽量少用框架自己手写一遍全链路把每一步的数据形态和计算逻辑摸清楚。当你踩过一轮坑之后再上框架就是如虎添翼而不是黑盒猜谜。2.2 核心代码骨架面向接口编程别被框架绑死不管用不用框架RAG的代码骨架高度一致。我习惯把四个核心能力写成独立模块每个模块只暴露一个函数# rag 系统四大核心模块接口 def load_document(path: str) - str: 读取源文档返回纯文本内容 pass def split_text(text: str, chunk_size: int, overlap: int) - list[str]: 把长文本切分成片段列表 pass def embed_texts(texts: list[str]) - list[list[float]]: 将文本片段批量向量化返回向量列表 pass def search(query_vector: list[float], doc_vectors: list[list[float]], top_k: int) - list[int]: 在文档向量中检索最相似的 top_k 个索引 pass这四个函数就是整个RAG流程的主干。好处很明显调试时每一层输入输出都是清晰的Python数据结构你可以单独打印某个函数的结果看看是否符合预期上线后哪一层慢了就优化哪一层哪一层出错了就单测哪一层。我强烈建议你保持这种模块化结构后面所有优化换向量库、加Rerank、加缓存都能在不改整体流程的情况下插进去。2.3 动手前需要准备的数据与环境准备一套最小的开发环境其实很简单一台能跑Python的机器就行8GB内存起步不需要GPU。如果你用外部API接口连显卡都可以省掉如果要本地部署开源模型那就得看模型参数规模来定硬件了。数据方面建议第一批先用你自己的项目文档、产品手册这类文本质量较高的材料。不要一上来就塞乱七八糟的网页抓取内容文本质量差会让你分不清是RAG流程的问题还是数据的问题。先把流程跑通再逐步增加数据源的复杂度。环境配置我习惯用一个.env文件管理密钥和接口地址用pydantic或python-dotenv加载不要在代码里硬编码。这个习惯可以让你在切换本地和云端模型时只需改一行配置# .env 示例 EMBED_ENDPOINThttp://localhost:8000/v1/embeddings LLM_ENDPOINThttp://localhost:8000/v1/chat/completions3. 离线知识库构建文档加载、切分与向量化3.1 文档加载与清洗不同格式的坑文档加载是整个流程里最脏最累的活也是决定RAG效果上限的隐藏因素。很多人把重心放在调检索参数上结果效果不好一查发现是原始文本里全是乱码和重复内容。不同格式有各自的问题。PDF看起来规整但很多PDF的文本层是坏的用解析工具抽出来可能是一行行的碎片表格变成乱序文本Word文档里常带修订记录、批注这些都要清掉网页抓取的内容更麻烦导航、广告、页脚会混进正文扫描件则需要先做OCR而OCR识别的错别字会直接影响检索质量。我第一版系统里吃过的亏是直接用PDF解析库默认参数抽文本结果表格里的数字被拆得七零八落检索时根本匹配不上。后来固定了一套处理流程先统一转成纯文本再用正则和规则清理噪声——去掉页眉页脚、去掉连续空白、去掉参考文献列表最后人工抽查几个文件的切分结果。不要跳过这一步宁可在清洗上多花一小时不然检索调试阶段会多花一整天。3.2 文本切分chunk_size、overlap与切分策略文本切分是RAG系统里最需要认真对待的参数环节。切多大、怎么切直接决定检索能不能命中正确信息。切分的基本逻辑是chunk_size决定每个片段包含多少字符overlap决定相邻片段之间有多少字符重叠。为什么要重叠因为一个完整的知识点可能恰好被切分点从中间截断前后各剩一半。重叠可以保证跨切分点的信息至少在一侧的片段里是完整的。切太小比如100个字符导致每个片段信息量太少检索可能命中一个残缺的上下文切太大比如2000个字符导致一个片段包含多个主题向量化的结果被平均化检索精度下降而且会浪费宝贵的上下文窗口。一个常见的中文起步配置是chunk_size512、overlap64但这不是标准答案跟你的文档类型强相关。切分策略从粗到细有三种纯字符切分、按标点/段落切分、按语义结构切分。纯字符切分最简单但有截断句子的风险按段落切分能保留语义完整性但段落长短不一需要做二次合并按语义切分是让模型判断哪里是语义边界效果最好但成本也最高。务实一点的做法是先按段落做基准切分再把超过chunk_size的段落下钻到句子级别切短段落合并到邻近片段。我在实际项目里就是这么处理的效果远好于无脑按字符数硬切。这段代码演示了一个可用的切分配置按段落优先、超长再切def smart_split(text: str, max_chunk: int 512, overlap: int 64) - list[str]: import re # 按段落拆分 paragraphs re.split(r\n\s*\n, text.strip()) chunks [] buffer for para in paragraphs: para para.strip() if not para: continue # 超长段落按句子二次切分 if len(para) max_chunk: if buffer: chunks.append(buffer) buffer sentences re.split(r(?[。]), para) tmp for sent in sentences: if len(tmp) len(sent) max_chunk: chunks.append(tmp) tmp sent else: tmp sent if tmp: chunks.append(tmp) else: if len(buffer) len(para) max_chunk: chunks.append(buffer) buffer para else: buffer \n para if buffer: chunks.append(buffer) # 合并过短的相邻片段并添加重叠 merged [] for c in chunks: if len(c) 50 and merged: merged[-1] \n c else: merged.append(c) if overlap 0: final [] for i, c in enumerate(merged): if i 0: prev_tail merged[i - 1][-overlap:] c prev_tail \n c final.append(c) return final return merged3.3 向量化与索引存储从手写余弦相似度说起向量化是让机器理解语义的关键一步。Embedding模型接收一段文本吐出一个固定长度的数字列表比如768维或1024维。语义相近的文本向量在空间里的距离就近。我建议入门时先不引入任何向量数据库直接用一个二维数组把所有向量存下来检索时手写余弦相似度。这个做法的好处是让你彻底理解向量检索的本质——就是算向量间的距离。理解这一点后你再去看向量数据库的ANN近似最近邻索引、PQ量化、HNSW这些概念就不会觉得玄乎了。下面这段代码就是向量化的核心封装调用一个兼容接口的Embedding服务import requests, os, numpy as np from dotenv import load_dotenv load_dotenv() EMBED_ENDPOINT os.getenv(EMBED_ENDPOINT) def embed_texts(texts: list[str]) - list[list[float]]: resp requests.post(f{EMBED_ENDPOINT}/v1/embeddings, json{input: texts}) resp.raise_for_status() data resp.json()[data] # 按输入顺序排列结果 data.sort(keylambda x: x[index]) return [d[embedding] for d in data]然后是手写余弦相似度检索把所有向量存成一个Numpy矩阵def build_index(doc_vectors: list[list[float]]) - np.ndarray: # 转成二维数组并归一化方便后续计算余弦相似度 mat np.array(doc_vectors, dtypefloat32) mat mat / np.linalg.norm(mat, axis1, keepdimsTrue) return mat def search(query_vector: list[float], index_mat: np.ndarray, top_k: int 5) - list[int]: q np.array(query_vector, dtypefloat32) q q / np.linalg.norm(q) scores index_mat q # 矩阵乘法一次算出所有余弦相似度 top_idx np.argsort(scores)[::-1][:top_k] return top_idx.tolist(), scores[top_idx].tolist()这里有一个关键点余弦相似度等价于归一化后的点积。提前把所有文档向量归一化检索时把query也归一化一次矩阵乘法就能算出全部相似度。这个原理理解透了后面看任何向量数据库的文档都会很轻松。工程上当你的文档量超过十万级别线性扫描的耗时就会变得不可接受这时候才需要引入ANN索引。但在入门阶段几万个片段用Numpy矩阵乘法检索速度其实已经很快了——先用最朴素的方法把流程跑通再按照性能瓶颈逐个优化这个顺序很重要。4. 在线检索问答链路召回、重排与生成4.1 检索召回从暴力搜索到近似最近邻在线链路的第一步是召回。用户输入问题后把它向量化然后去知识库向量里找最相似的TopK个片段。召回阶段最核心的一个直觉是先保证别把正确答案漏掉至于多召回几个不相关的片段可以后面再过滤。所以TopK的初始设置可以稍微大一点比如10到20个后面再靠重排和模型筛选。如果一开始就设成3个正确答案在第4个位置就被漏掉了后面再怎么优化生成都没用。召回方式除了向量检索还有关键词检索。向量检索擅长语义匹配——用户说怎么退款文档里写退款流程就能命中关键词检索擅长精确匹配——用户输入一个专有名词或编号向量检索可能因为语义漂移找不着关键词匹配一搜一个准。两者结合混合检索在实战中几乎是必选项我在第5章会详细讲。4.2 命中知识注入提示词模板的设计要点把检索到的片段注入提示词这一步看起来简单但有几个容易被忽略的细节。首先你必须明确告诉模型哪些内容是检索材料并要求它只基于这些材料作答。否则模型可能无视你给的资料凭自己的记忆回答幻觉又回来了。我常用的提示词模板长这样你是一个智能问答助手。请基于以下文档片段回答用户问题。 规则 1. 如果文档片段包含答案请严格基于片段内容回答并标注信息来源。 2. 如果文档片段不包含答案请直接说根据现有资料无法回答不要编造。 3. 回答时语言自然流畅不要出现根据文档片段之类的表述。 文档片段 ----- [片段1] ----- [片段2] ----- 用户问题{question} 请回答其次是信息源标注。在把片段拼进去之前给每个片段编号并要求模型在回答里引用编号。这一点看似繁琐但在真实业务场景里极其重要——落地的时候业务方一定会问这个结论是哪份文档说的没有溯源能力的RAG系统很难让业务方信任。第三是控制注入量。不要把TopK的所有片段都塞进去。上下文窗口有限片段太多会稀释关键信息也会让模型困惑。我通常的做法是先按TopK20召回经过重排和过滤后只把最高的5到8个片段填入提示词。这比直接填20个片段的效果好很多。4.3 完整RAG代码示例从知识库到回答问题把前面所有模块串起来就是一个可运行的完整RAG系统。这个Demo拿你的本地文档建库然后用一个问题走完整链路输出带出处的回答。import os import requests from dotenv import load_dotenv load_dotenv() LLM_ENDPOINT os.getenv(LLM_ENDPOINT) EMBED_ENDPOINT os.getenv(EMBED_ENDPOINT) # ---------- 模块1文档加载 ---------- def load_document(path: str) - str: with open(path, r, encodingutf-8) as f: return f.read() # ---------- 模块2文本切分 ---------- # 使用3.2节的 smart_split 函数此处略 from splitter import smart_split # ---------- 模块3向量化 ---------- def embed_texts(texts: list[str]) - list[list[float]]: resp requests.post(f{EMBED_ENDPOINT}/v1/embeddings, json{input: texts}) resp.raise_for_status() data resp.json()[data] data.sort(keylambda x: x[index]) return [d[embedding] for d in data] # ---------- 模块4构建索引与检索 ---------- import numpy as np def build_index(doc_vectors): mat np.array(doc_vectors, dtypefloat32) mat mat / np.linalg.norm(mat, axis1, keepdimsTrue) return mat def search(query_vector, index_mat, top_k20): q np.array(query_vector, dtypefloat32) q q / np.linalg.norm(q) scores index_mat q top_idx np.argsort(scores)[::-1][:top_k] return top_idx.tolist(), scores[top_idx].tolist() # ---------- 模块5调用大模型生成答案 ---------- def generate_answer(question: str, contexts: list[str]) - str: context_block \n.join( f[片段{i1}] {text} for i, text in enumerate(contexts) ) prompt f你是一个智能问答助手。请基于以下文档片段回答用户问题。 规则 1. 如果文档片段包含答案请严格基于片段内容回答并在回答末尾用[1][2]标注引用来源。 2. 如果文档片段不包含答案请直接说根据现有资料无法回答不要编造。 文档片段 ----- {context_block} ----- 用户问题{question} 请回答 resp requests.post( f{LLM_ENDPOINT}/v1/chat/completions, json{ model: your-model-name, messages: [{role: user, content: prompt}], temperature: 0.2, }, ) resp.raise_for_status() return resp.json()[choices][0][message][content] # ---------- 主流程 ---------- if __name__ __main__: # 1. 加载并切分文档 text load_document(./docs/product_manual.txt) chunks smart_split(text, max_chunk512, overlap64) print(f切分得到 {len(chunks)} 个片段) # 2. 向量化并建索引 chunk_vectors embed_texts(chunks) index_mat build_index(chunk_vectors) # 3. 处理用户问题 question 产品的退款政策是什么 q_vec embed_texts([question])[0] top_idx, scores search(q_vec, index_mat, top_k20) # 4. 取前5个片段注入提示词 selected [chunks[i] for i in top_idx[:5]] for i, score in zip(top_idx[:5], scores[:5]): print(f命中片段 {i} | 相似度 {score:.4f}) # 5. 生成答案 answer generate_answer(question, selected) print(回答\n, answer)这个代码就是一个最小可用RAG系统不需要任何重型依赖跑通之后你就拥有了完整的建库-召回-生成闭环。代码里scores打印可以帮助你直观看到检索质量——如果最高相似度只有0.5甚至更低说明知识库里有用的东西没被切对或没被向量化好要回到第3章找原因。5. 效果优化关键参数调优与进阶玩法5.1 调参实战chunk_size、top_k、overlap怎么调一个RAG系统做完基础版本之后接下来就是持续调优的过程。我总结了一个调参顺序效率比较高先调切分参数再调TopK最后调提示词。chunk_size的调整逻辑要看你的文档形态。如果你的文档是问答对形式问题答案答案通常比较短那chunk_size可以设小一点比如256便于精确命中单个问答对。如果你的文档是长篇论述一个知识点需要前后文才能理解那chunk_size可以设到800甚至1000。判断标准很简单去看检索结果的相似度分数分布。如果前几名相似度都低大概率是切分太碎正确答案被切成残片如果高相似度命中的片段里混杂了太多无关主题可能是切分太大一个片段装了好几个话题。top_k的影响同样直观。TopK太小容易漏TopK太大会把噪声带进提示词。我建议先用20做召回看检索到的前20个片段里有多少是真正相关的。如果真正相关的最多只有三四个说明召回本身没问题只是后续生成阶段要控制只注入这几个如果前20个里面没几个相关的先别急着调TopK回过去看切分和向量化。overlap的作用是防止切分点切断语义。但overlap也不是越大越好重叠的内容相当于在一个片段里重复出现如果overlap太大会导致相邻片段高度重合检索时可能返回一排几乎一模一样的片段白白浪费召回名额。我一般控制在chunk_size的10%到20%。调参时的正确工作方式不是拍脑袋改而是记录每次改动的检索结果和答案质量对比后再决定下一步。我自己的习惯是建一个小评测集准备20到50个有标准答案的问题每次改动后跑一遍统计命中率和答案正确率。没有评测集的调参就是盲人摸象。5.2 混合检索 重排把召回质量拉满的成熟方案单靠向量检索在实际业务里经常会遇到一个问题语义匹配能理解意思相近的表述但理解不了精确编号和专有名词。比如用户搜故障代码E1024向量检索可能把E1024的含义匹配到某个语义相关的句子但最精确的那个E1024故障处理片段反而没排第一。解决方案就是混合检索把向量检索和关键词检索的结果合并再用重排模型把合并后的结果重新打分。流程是向量检索取TopK50关键词检索取TopK50两个结果做去重合并然后交给一个打分模型综合排序最后取前5到8个。关键词检索在工程上可以直接用全文索引也可以简单实现一个TF-IDF或BM25算法。重排这一步可以用一个专门的排序模型也可以用一个LLM来打分——让模型判断这个片段对回答这个问题有多大帮助。用LLM重排在中小数据量下效果很惊艳就是延迟和成本偏高。我的建议是先用一个轻量级方法比如在提示词里让模型只从给定片段里挑相关片段跑通之后再引入独立的重排模型。重排之后的效果通常比单独向量检索高出不止一个档次。原因是向量检索擅长给你一批相关的但排序不够精准重排模型专门学过怎么把最相关的排前面。两者结合召回精度才能达到生产可用的水平。5.3 如何科学评估RAG效果指标与评测集很多人做RAG调优全靠感觉回答变好了这是最大的坑。没有量化指标你根本分不清是参数变化带来的提升还是运气好碰上了几个问题。评估RAG要从两个层面看检索质量和生成质量。检索质量最常用的指标是召回率K和准确率K。做法是准备一组问题每个问题标注出知识库里哪些片段是真正包含答案的标准命中片段。对每个问题跑检索看TopK结果里是否包含标准命中片段。比如10个问题里有8个能在Top10里命中标准片段召回率10就是80%。这个指标不需要调用大模型成本低反馈快非常适合日常调参。生成质量评估就复杂一些通常分三块答案正确性内容是否准确、忠实度答案是否严格基于检索材料、有没有自己编、覆盖率标准答案的要点是否都答到了。忠实度是最容易出问题的模型经常自己加戏这也是RAG系统上线后最需要盯的指标。评估生成质量有两种做法一是人工打分建立一套评分标准找几个人分别打分取平均二是用大模型当裁判让一个评测模型按评分标准给另一个模型的答案打分。后者成本可控、可以批量跑但要注意评测模型的偏好偏差。我个人的经验是日常迭代用检索指标自动化评测上线前做一轮人工抽测两者结合最稳。5.4 上下文压缩与多路召回随着场景深入你还会遇到两个进阶问题检索到的片段太长、来源太杂。上下文压缩的思路是在注入提示词之前先对片段做一次瘦身。还是得靠一个轻量模型来判断这个片段里哪些句子是回答当前问题需要的把无关句子删掉再注入。这样最大的好处是你可以放心地用TopK20的范围做召回而不用为了省上下文窗口把TopK压得很小。召回范围大了漏召回的概率就低了。多路召回则是面向复杂问题的策略。用户的问题可能同时涉及多个方面比如这个产品的价格和售后服务怎么样单一路径检索可能只找到价格信息找不到售后信息。做法是把问题拆解成多个子查询分别检索合并结果。注意多路召回不是简单的多条query跑一遍而是要针对每条子路径做独立的检索参数和过滤规则最后统一汇总。这两个技巧都属于数据量上来、问题变复杂之后才需要的进阶优化。入门阶段先把5.1和5.2做好效果已经能覆盖绝大多数场景。6. 常见问题与避坑实录6.1 检索结果质量差的排查清单我做了那么多次RAG调试总结了一份排查顺序按出现概率从高到低排列。第一优先查文本切分是否符合语义。最常见的问题是切分后一个完整的QA对被打散到两个片段里检索时只命中半个答案自然残缺。解决方式是在smart_split里加入根据换行和标题做结构感知切分。第二查Embedding模型选型。有些Embedding模型在中文长文本上效果极差换一个评测更好的模型立竿见影。判断方式是把两个语义高度相似但不完全相同的句子拿去算相似度如果得分很低说明模型本身就不适配你的文本风格。第三查数据清洗是否干净。我之前遇到过一个诡异的问题检索价格,里面出现了价格的页面但完整答案在另一个很远的地方。最后发现是原始文档里有个表格被解析歪了价格这个词被单独抽成了孤零零的一行干扰了检索结果。数据清洗不到位检索再强也白搭。第四查重排是否引入噪声。有些重排模型对长文本有偏差可能把过于冗长的片段排到前面。这个要结合具体case排查不要一上来就怀疑重排环节。6.2 幻觉仍然存在的根源很多人在RAG上线后发现模型还是偶尔答出知识库里没有的内容非常困惑。我把幻觉残留的根源归成三类。第一类是提示词约束不够硬。如果你的提示词没有明确要求不基于材料就拒绝回答模型默认还是会走能答就答的路子。规则表述要强硬例如如果材料不包含答案必须拒绝回答禁止编造。第二类是注入材料里混入了错误信息。当你用TopK20做大范围召回时很可能混入不相关或低质的片段模型会被这些噪声误导。解决方案是注入前做重排过滤只保留置信度高的片段。第三类是模型自身倾向性太强。有些模型在训练时被鼓励尽量给用户一个答案哪怕没有材料支撑也要硬答。这类问题靠提示词不好完全压制可以在生成后加一道校验用一个评分模型判断答案的关键断言是否都能在注入材料里找到找不到就拒绝输出或提示用户。这属于生成后校验是最后一层防线。6.3 成本与延迟优化心得RAG系统的成本大头在Embedding调用和LLM生成延迟大头在检索和LLM生成。Embedding成本优化最简单批量调用不要一条一条请求。文本以百为单位批量向量化价格和时间都能省一个量级。另外离线构建的知识库如果只需要更新增量文档可以只对新文档做向量化不需要每次全量重算。LLM延迟优化有几个思路。第一个是缩短注入片段长度用上下文压缩把每个片段从500字缩到150字生成token数直接下降。第二个是考虑做答案缓存——相同或相似的问题直接命中缓存不再走模型生成。第三个是在业务允许的范围内给检索接口加一层先用轻量模型判断是否有把握回答没把握再调大模型的兜底逻辑。这条在流量大时能卡掉很多无效请求。另外如果延迟敏感且数据量大检索环节该上向量数据库的就要上不要再用Numpy矩阵硬扛。向量数据库的HNSW索引在几十万向量规模下能把检索延迟从几十毫秒压到个位数毫秒投入产出比很高。6.4 容易忽略的细节最后分享几个容易踩的细节坑都比较小但都真实影响过系统表现。向量维度的一致性。换Embedding模型时向量维度可能会变旧的索引和新的向量无法共用必须全量重建索引别偷懒只增量更新。这个坑我踩过一次线上索引和线上模型维度不匹配检索结果直接乱套。同义词和简繁体的归一化。很多文档里混合使用账户和帐户、设定和设置这类近义写法切分和检索阶段如果不做归一化可能出现关键词检索漏命中的情况。建议在清洗阶段统一做一次词典替换。数据权限问题。如果你是多用户系统检索必须带权限过滤否则A用户可能通过恰好检索到的方式看到B用户的私有文档。向量数据库大多支持元数据过滤检索时把部门可见级别作为强制过滤条件。这个不处理好出了事就是事故。日志与可观测性。每个用户查询的检索片段、相似度分数、最终答案最好都记录下来。线上出问题时靠这些日志才能三分钟内定位是哪一层出了问题而不是对着屏幕猜。我在系统里会给每个请求生成一个链路ID贯穿查询到响应的每一步排查问题效率能翻好几倍。整合输出的时候还有一个小技巧在真实项目里我习惯把检索到的原始片段和最终答案一起返回给前端让业务方看得见证据链。这既提高了信任度也为后续数据反馈和评测集扩充提供了素材——用户认为哪些片段有用记录下来就是天然的标注数据。这个循环跑起来你的RAG系统才会越用越准。