做知识密集型应用的时候最头疼的问题之一就是模型一本正经地胡说八道。我前前后后试过堆prompt、做微调最后发现真正能快速落地、见效最稳的还是RAGRetrieval-Augmented Generation检索增强生成。简单说RAG就是在模型回答之前先从外部知识库里检索出相关内容把检索结果拼进上下文里再让模型基于这些材料生成答案。这个思路解决了大模型“知识过时”“缺乏私有数据”“回答不确定”三大痛点也是目前企业里做智能问答、知识库助手、客服机器人最主流的方案。这篇内容我不打算复述官方文档而是把实际操作中踩过的坑、选型时的取舍、以及一套可以直接照着搭的流程整理出来。适合正在做知识库问答、想要给模型接入私有数据、或者是刚接触RAG准备选型的人。不管你是用LangChain、LlamaIndex还是自己写检索逻辑核心原理都是通用的理解透了才不会在后续调优时绕圈子。1. RAG整体设计与思路拆解1.1 为什么不是微调而是RAG很多人一上来就问我有几百篇文档想让模型学会里面的知识是不是得微调一个模型我的经验是除非你的文档数量极大、知识格式高度固定、且对回答的措辞有严格风格要求否则微调的性价比远低于RAG。微调的本质是改变模型参数里的权重分布让它“背下来”一部分知识。但有三个现实问题第一模型参数空间有限新知识和原本的通用知识会互相挤压学得多反而忘得快第二每次知识更新都要重新训练成本高到普通团队难以承受第三微调后模型依然无法溯源它告诉你的答案你看不出依据在哪里出了错也无从追责。RAG回避了以上所有问题。它的逻辑很朴素答案不是模型“想出来”的而是“找出来”的。模型扮演的是一个“阅读者”和“总结者”它会根据检索到的片段组织语言同时只要检索片段里注明了来源回答就可以精确溯源。知识更新时你只需要重新索引新文档不需要动模型本身。这也是为什么RAG被叫做“知识检索增强”——增强的不是模型参数而是每一次调用时的输入上下文。1.2 RAG的标准流程到底在做什么一个完整的RAG流程可以拆成“写索引”和“读索引”两个阶段。写索引阶段就是把原始文档转换成模型和检索器都能理解的表示。原始文档是PDF、Word、Markdown等等它们不能被直接丢进向量库。你需要先加载文档、清洗格式、按一定策略切分成小块然后对每一块做向量化。向量化就是把一段文字映射成一组浮点数让语义相近的文本在向量空间里距离更近。读索引阶段发生在用户提问时。用户输入query后系统先把query也向量化再到向量库里做相似度搜索找出最相关的TopK片段比如Top5或Top10。然后把用户问题这些片段一个系统提示词一起拼成完整的prompt交给LLM。LLM的任务就是“根据提供的资料回答问题不要编造”。这个流程看着简单但每个环节都有大量可调的空间。很多人第一次搭RAG恨不得马上写代码跑通一个demo结果demo是通了一问细节问题就答非所问。原因通常不在代码而在前期设计分块切得合不合理、字段有没有保留、检索策略选对没有。1.3 从技术选型看RAG框架的定位目前比较主流的RAG框架有LangChain、LlamaIndex也有更底层的Haystack以及国内一些闭源平台。我的个人体会是如果项目刚起步、团队对Python比较熟LangChain资料最多生态最全遇到问题搜索一下基本都有答案LlamaIndex更偏向“文档检索”场景索引机制设计得更细腻适合做文档级问答如果是在生产环境需要自己控制每个环节直接用原生的向量库客户端加上自己的查询逻辑反而更可控。框架不是越重越好。RAG的瓶颈往往不是框架能力而是数据质量和检索质量。你选哪个框架只决定你写代码的舒服程度不决定效果上限。效果上限由你的分块策略、embedding模型、重排序策略、LLM能力等因素共同决定。所以我的建议是先把流程吃透再用框架省力不要本末倒置。2. 核心细节解析与实操要点2.1 知识库类型向量库、结构化库和图谱库怎么选RAG热词里经常出现“向量知识库”“结构化知识库”“KG知识库”“ontology RAG”很多人会混为一谈。其实这三类知识库的存储结构、适用场景、检索方式完全不同选错了后面会非常别扭。向量知识库存储的是文本块的embedding向量适合做“非结构化文档的语义检索”。比如你有一堆PDF、手册、历史工单你不知道用户会问什么只能靠语义相似度帮用户找到相关段落。它的优势是灵活不需要预先定义数据模型劣势是精度受限于embedding模型和分块效果对于精确的数值、条件判断、多跳关系推理不够强。结构化知识库一般指关系型数据库或表结构的数据比如订单表、设备参数表、员工信息表。这类数据有明确的字段和关系更适合用SQL查询而不是向量检索。如果硬把表格数据切成文本块丢进向量库很多带限定条件的查询会出错比如“找出上个月销售额大于十万的所有客户”文本检索很难精确做到。KG知识库Knowledge Graph则把实体和关系显式地建模成图结构适合多跳推理、关系查询。比如“某人的同事的上级是谁”这类问题需要在实体关系链上跳转树状的文本切片做不到。KG搭配RAG时通常先用LLM抽取query里的实体和关系再到图谱中查询子图把子图路径作为上下文喂给LLM。ontology RAG则更进一步它会利用本体论定义的概念层级和约束关系让检索结果更加逻辑严密。ontology和KG适合企业知识体系清晰、关系复杂度高、对准确率要求苛刻的场景但构建成本也高出好几个量级。实际项目中大部分场景一个“向量库关键词混合检索”就够用了。只有当查询里频繁出现“关系链”类问题或者业务数据天然是图结构时再引入KG。不要为了跟风上图谱建模和维护成本会让你怀疑人生。2.2 文档加载与分块策略最容易忽视的细节文档加载阶段有个容易踩的坑PDF里的表格、页眉页脚、图片文字混排直接解析出来经常是乱序的。我遇到过一份产品手册解析后所有表格内容错位检索出的上下文驴唇不对马嘴。建议先按页面布局做区域识别把标题、正文、表格拆开表格部分单独处理转成HTML或Markdown表格后保留结构再切分。文本加载不是“能读出来就行”而是“读出来的顺序和结构必须保留语义”。分块策略直接决定检索的粗细。分块太小语义不足分块太大噪声太多且容易超过LLM上下文限制。我的经验是一般问答场景chunk_size选300~500字符overlap设50~100字符如果是技术文档、法律条文这种本身段落结构清晰的可以按Markdown标题层级切割以保证每个chunk内部主题完整。这里有一个容易被忽略的点overlap不只是用来衔接上下文还能避免一个完整句子被从中间切开导致向量化时语义断裂。分块后建议在chunk的元数据里保留来源路径、文档标题、页码、甚至章节标题。这样在给LLM的上下文里可以带上引用信息回答时可以自动标注“根据XX文档第XX页”大大提升可信度。我见过不少团队把这块省掉后期做溯源审计时痛苦不堪。2.3 嵌入模型选型别只盯着效果还要看维度Embedding模型的核心作用是把文本映射到向量空间语义相近的文本向量距离近。市面上的选择非常多OpenAI的text-embedding-3-small、BGE系列、M3E、E5等。选型的核心指标不是越快越好而是和你query的领域分布匹配。通用场景下text-embedding-3-small的语义理解力和泛化性都很强但它有一个隐患知识库如果包含大量专业术语比如医疗、法律、金融通用embedding可能分不清术语间的细微差别。此时应该用领域微调过的embedding模型或者至少在业务数据上做效果评测。换个思路如果你的文本是中文为主用中文语料训练的BGE-large-zh可能比英文模型好不少。还有一个参数值得注意向量维度。text-embedding-3-small默认支持缩短维度你可以用1536维也可以缩到512维。维度越高语义区分度越强但存储和检索开销也越大。实际操作时建议先用默认维度跑通再对比降维后的效果不要一上来为了省空间强行降维很可能检索召回率明显掉下来。2.4 检索不是只有向量搜索混合检索与rerank向量搜索擅长语义相似匹配但它有个致命短板对关键词、专有名词、编号、型号这种精确匹配不敏感。比如用户问“A100显卡的显存带宽是多少”向量检索可能把A100识别成了其他语义相近的型号。这时候必须加上BM25或者TF-IDF这种关键词检索再做结果融合也就是混合检索。混合检索的融合策略有几种常见方案加权和、倒数排名融合RRF、或者用学习排序模型。落地最简单的是RRF它不依赖分数绝对值而是按排名倒数相加对向量和关键词两类得分尺度不一致问题不敏感。我建议先跑一轮候选取两类检索结果的Top50用RRF融合后取Top10再交给reranker。Rerank是提升准确率最有效的一招。简单说Retriever负责粗召回Reranker负责精排序。Cross-encoder类的rerank模型会把query和每个候选段落拼接起来逐对计算相关度分数精度比双塔向量检索高很多。代价是速度慢一些但因为只对几十个候选排序整体延迟可控。实践中加了rerank之后回答的准确率往往能提升10到20个百分点这是性价比极高的一个环节。3. 实操过程与核心环节实现3.1 在Mac上从零搭一套RAG知识库网上搜索“怎么在mac上搭建rag知识库”说明很多新手卡在了环境配置上。其实macOS是相当适合做RAG开发的尤其是M系列芯片跑embedding模型和本地LLM都算顺畅。我建议的起步方案是用Python虚拟环境搭配LangChain Chroma向量库 一个开源embedding模型LLM先用本地Ollama跑一个7B或13B模型或者接OpenAI的API。这里给出一套可以直接照抄的环境搭建步骤。# 1. 创建虚拟环境 python3 -m venv rag-env source rag-env/bin/activate # 2. 安装核心依赖 pip install langchain langchain-community langchain-chroma chromadb pip install sentence-transformers pypdf markdownify pip install openai这里解释一下为什么选Chroma它是轻量级本地向量数据库不需要单独启动服务数据可以持久化到本地目录适合原型验证。生产环境再换成Milvus、Weaviate或者PGVector也不冲突。接下来准备好你的数据目录。假设你有几份Markdown或PDF文件放在./docs目录下。下面是完整的索引构建代码from langchain_community.document_loaders import DirectoryLoader, TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma loader DirectoryLoader(./docs, glob**/*.md, loader_clsTextLoader) docs loader.load() splitter RecursiveCharacterTextSplitter( chunk_size400, chunk_overlap80, separators[\n\n, \n, 。, , , , , ], keep_separatorTrue ) chunks splitter.split_documents(docs) embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-large-zh-v1.5) vectorstore Chroma.from_documents(chunks, embeddings, persist_directory./chroma_db)这段代码里有两个值得讲的地方。第一个是separators参数我按“段落、换行、句号、感叹号、问号、逗号、空格”的顺序逐级切分目的是优先保留完整句子实在句子太长才往标点处切。这比默认只按换行切出来的chunk质量高不少。第二个是embedding模型我用了BGE的轻量版它在中文语义检索上表现稳定而且支持本地推理不需要联网。索引构建完成后查询部分只需要做三件事向量检索、拼prompt、调用LLM。一个最简版本如下query 产品的保修政策是什么 retriever vectorstore.as_retriever(search_kwargs{k: 5}) relevant_docs retriever.invoke(query) context \n\n.join([doc.page_content for doc in relevant_docs]) prompt f请根据以下资料回答问题。如果资料中没有相关内容请直接说“资料中未找到相关信息”不要编造。 资料 {context} 问题{query} 答案然后把这个prompt交给LLM。如果用Ollama本地模型from langchain_community.llms import Ollama llm Ollama(modelqwen2.5:7b, temperature0.1) print(llm.invoke(prompt))这里temperature一定要控制在0.1以下否则模型容易自由发挥。我之前用一个默认temperature0.7的模型测试好多次答案比资料原文还丰富全是幻觉后来调到0.1后明显规整了。3.2 混合检索与Rerank的落地实现上述最简版本只有向量检索实际项目准确率往往不够。我来演示加上BM25和rerank的完整做法。先用rank_bm25计算关键词得分然后和向量得分融合。这里我用RRF融合import numpy as np from rank_bm25 import BM25Okapi # 假设docs_chunks是之前切分好的文本列表 tokenized_chunks [list(chunk) for chunk in chunks_list] bm25 BM25Okapi(tokenized_chunks) bm25_scores bm25.get_scores(list(query)) # 向量检索取top50 vec_results vectorstore.similarity_search_with_score(query, k50) # 构建doc_id - rank vector_rank_map {doc.metadata[id]: idx for idx, (doc, score) in enumerate(vec_results)} # bm25同样取前50的rank这里仅做原理示例RRF公式是score sum(1 / (k rank))其中k一般取60。这样无论两类检索的相似度分数尺度如何都能有效融合。融合后先取Top20再用cross-encoder的rerank模型精排。Rerank部分推荐sentence-transformers的cross-encoder/ms-marco-MiniLM-L-6-v2或者中文场景用bge-reranker-basefrom sentence_transformers import CrossEncoder reranker CrossEncoder(BAAI/bge-reranker-base) query_doc_pairs [(query, doc.page_content) for doc in top_candidates] scores reranker.predict(query_doc_pairs) top_docs [doc for _, doc in sorted(zip(scores, top_candidates), keylambda x: x[0], reverseTrue)][:5]把rerank后的Top5作为上下文喂给LLM。这一套流程跑下来我直观感受是回答的“命中感”强了很多不再经常出现检索到无关段落、结果驴唇不对马嘴的情况。3.3 结构化知识库与图谱库在什么时机介入如果你发现向量检索在数值、条件、关系类问题上频繁出错这时候才需要重新评估知识结构。举个例子某团队做设备运维问答用户会问“哪台设备最近七天故障次数最多”。这种问题本质上是一个计数排序查询向量检索几乎不可能精准返回。正确做法是把设备状态存到数据库表里用NL2SQL把用户query转换成SQL执行然后把查询结果转成描述文本再馈给LLM生成解释。这也是结构化知识库配合RAG的典型形态。KG知识库的介入时机更晚。只有当你的知识模型存在多跳关系比如“某部门经理负责的项目分布在哪些城市”并且这种关系被反复查询时才值得构建图谱。图谱构建需要定义实体类型、关系类型、属性以及实体消歧。一个折中的方案是“向量图谱混合”先通过向量检索找出可能的实体再到图谱上做子图扩展最后把子图包含的路径信息作为额外上下文。ontology RAG则是图谱的加强版在实体关系之上再定义概念层级和约束。比如在医学场景中“高血压”和“血压升高”的关系需要本体来约束否则图谱容易把两个概念当成独立实体。Ontology的构建需要领域专家参与成本很高在垂直领域知识密度非常大的场景才会考虑。4. 常见问题与排查技巧实录4.1 RAG瓶颈上下文污染与幻觉RAG最常被诟病的安全区问题就是检索到的内容虽然有但里面夹杂了无关信息模型被“带偏”。我称之为“上下文污染”。比如用户问A检索出Top5里有一篇讲A和B对比的文档模型可能顺带把B的内容也答进来。解决这个问题的核心在rerank和阈值控制对检索结果做一个最低相关度分数过滤如果得分普遍很低干脆返回“资料中未找到”。我建议给检索环节加一个监控日志每次查询记录top文档的相关性分数。如果发现很多分数低于0.4不同embedding分数范围不同先观察分布那大概率是分块不合适或embedding质量不足而不是LLM的问题。这一步很关键很多人一发现回答质量差就调prompt其实问题在更上游。4.2 分块大小和overlap的影响我实测过一个很典型的case同一份合同文本chunk_size200时检索到的合同条款常常不完整模型无法判断条款的上下文限制chunk_size1000时每个chunk包含太多不同条款模型容易被干扰。正确的做法是先做“检索评测集”构造20~30个真实用户问题标记每个问题的标准答案所在段落然后跑不同分块参数对比检索命中率。如果你没有评测集调优基本是靠感觉效果忽好忽坏。这个评测集不用很大但覆盖查询类型要全面事实型、对比型、列表型、步骤型。有了它后面调embedding、调rerank都能量化比较。4.3 图片和表格内容怎么处理RAG知识库能存储图片吗这个热词搜索频率很高。直接说是可以的但不是把原始图片存进去而是需要先把图片中的信息提取出来。如果图片里有文字用OCR比如PaddleOCR识别成文本如果图片本身是图表、流程图还要额外做图表理解或者由多模态模型生成图的描述文本再把描述文本向量化存储。检索时匹配的是描述文本而不是像素数据。表格的处理类似不要直接丢进向量库。建议把表格转成markdown表格或HTML然后在分块时保留结构。如果表格特别大先按行拆分每行带上表头字段名这样检索一条“某字段满足某条件”的记录时向量能匹配到对应的字段上下文。我见过不少项目因为表格处理粗糙导致答案里数值张冠李戴这种问题靠调prompt是救不回来的。4.4 常见问题速查表让你少走弯路现象可能原因解决方向回答找不到资料内容分块过大/embedding不匹配缩小chunk增加overlap换领域embedding回答总是多出额外信息上下文包含无关chunk加rerank降低TopK加相关度阈值数值和条件查询不准向量检索不适配结构化查询改为SQL检索或NL2SQL方案模型照抄资料里的错字文档清洗不到位增加文本清理和纠错流程检索速度慢向量库并发/维度太高换索引HNSW考虑降维或换库专业术语识别差通用embedding不覆盖领域微调embedding或在prompt里加术语映射4.5 一点避坑心得最后分享一个实操中非常容易踩的坑RAG上线前一定要做“否定测试”。也就是故意问一些知识库里不存在的问题看模型是否敢于回答“不知道”。如果模型硬答说明你的系统提示词里没有约束或者temperature太高。一个好的RAG系统应该既有“答得出”的能力也有“拒答”的能力。拒答不是产品缺陷恰恰是可信度的体现。另外千万别忽略日志。每次查询记录下检索到的文档ID、相关度分数、模型输出。这样出问题时能快速定位是哪一环节而不是对着一个“不准确的回答”干瞪眼。我自己的项目里日志里90%的问题最终都指向数据清洗和检索质量真正要调模型参数的极少。这个结论也印证了RAG的核心价值决定天花板的不是大模型而是你喂给它的知识和检索质量。按照这套思路你可以把RAG从一个“能跑的demo”升级成一个“能用的系统”。多花时间在分块策略、embedding评测、检索融合和否定测试上效果提升会比换更强的LLM明显得多。
做知识密集型应用的时候最头疼的问题之一就是模型一本正经地胡说八道。我前前后后试过堆prompt、做微调最后发现真正能快速落地、见效最稳的还是RAGRetrieval-Augmented Generation检索增强生成。简单说RAG就是在模型回答之前先从外部知识库里检索出相关内容把检索结果拼进上下文里再让模型基于这些材料生成答案。这个思路解决了大模型“知识过时”“缺乏私有数据”“回答不确定”三大痛点也是目前企业里做智能问答、知识库助手、客服机器人最主流的方案。这篇内容我不打算复述官方文档而是把实际操作中踩过的坑、选型时的取舍、以及一套可以直接照着搭的流程整理出来。适合正在做知识库问答、想要给模型接入私有数据、或者是刚接触RAG准备选型的人。不管你是用LangChain、LlamaIndex还是自己写检索逻辑核心原理都是通用的理解透了才不会在后续调优时绕圈子。1. RAG整体设计与思路拆解1.1 为什么不是微调而是RAG很多人一上来就问我有几百篇文档想让模型学会里面的知识是不是得微调一个模型我的经验是除非你的文档数量极大、知识格式高度固定、且对回答的措辞有严格风格要求否则微调的性价比远低于RAG。微调的本质是改变模型参数里的权重分布让它“背下来”一部分知识。但有三个现实问题第一模型参数空间有限新知识和原本的通用知识会互相挤压学得多反而忘得快第二每次知识更新都要重新训练成本高到普通团队难以承受第三微调后模型依然无法溯源它告诉你的答案你看不出依据在哪里出了错也无从追责。RAG回避了以上所有问题。它的逻辑很朴素答案不是模型“想出来”的而是“找出来”的。模型扮演的是一个“阅读者”和“总结者”它会根据检索到的片段组织语言同时只要检索片段里注明了来源回答就可以精确溯源。知识更新时你只需要重新索引新文档不需要动模型本身。这也是为什么RAG被叫做“知识检索增强”——增强的不是模型参数而是每一次调用时的输入上下文。1.2 RAG的标准流程到底在做什么一个完整的RAG流程可以拆成“写索引”和“读索引”两个阶段。写索引阶段就是把原始文档转换成模型和检索器都能理解的表示。原始文档是PDF、Word、Markdown等等它们不能被直接丢进向量库。你需要先加载文档、清洗格式、按一定策略切分成小块然后对每一块做向量化。向量化就是把一段文字映射成一组浮点数让语义相近的文本在向量空间里距离更近。读索引阶段发生在用户提问时。用户输入query后系统先把query也向量化再到向量库里做相似度搜索找出最相关的TopK片段比如Top5或Top10。然后把用户问题这些片段一个系统提示词一起拼成完整的prompt交给LLM。LLM的任务就是“根据提供的资料回答问题不要编造”。这个流程看着简单但每个环节都有大量可调的空间。很多人第一次搭RAG恨不得马上写代码跑通一个demo结果demo是通了一问细节问题就答非所问。原因通常不在代码而在前期设计分块切得合不合理、字段有没有保留、检索策略选对没有。1.3 从技术选型看RAG框架的定位目前比较主流的RAG框架有LangChain、LlamaIndex也有更底层的Haystack以及国内一些闭源平台。我的个人体会是如果项目刚起步、团队对Python比较熟LangChain资料最多生态最全遇到问题搜索一下基本都有答案LlamaIndex更偏向“文档检索”场景索引机制设计得更细腻适合做文档级问答如果是在生产环境需要自己控制每个环节直接用原生的向量库客户端加上自己的查询逻辑反而更可控。框架不是越重越好。RAG的瓶颈往往不是框架能力而是数据质量和检索质量。你选哪个框架只决定你写代码的舒服程度不决定效果上限。效果上限由你的分块策略、embedding模型、重排序策略、LLM能力等因素共同决定。所以我的建议是先把流程吃透再用框架省力不要本末倒置。2. 核心细节解析与实操要点2.1 知识库类型向量库、结构化库和图谱库怎么选RAG热词里经常出现“向量知识库”“结构化知识库”“KG知识库”“ontology RAG”很多人会混为一谈。其实这三类知识库的存储结构、适用场景、检索方式完全不同选错了后面会非常别扭。向量知识库存储的是文本块的embedding向量适合做“非结构化文档的语义检索”。比如你有一堆PDF、手册、历史工单你不知道用户会问什么只能靠语义相似度帮用户找到相关段落。它的优势是灵活不需要预先定义数据模型劣势是精度受限于embedding模型和分块效果对于精确的数值、条件判断、多跳关系推理不够强。结构化知识库一般指关系型数据库或表结构的数据比如订单表、设备参数表、员工信息表。这类数据有明确的字段和关系更适合用SQL查询而不是向量检索。如果硬把表格数据切成文本块丢进向量库很多带限定条件的查询会出错比如“找出上个月销售额大于十万的所有客户”文本检索很难精确做到。KG知识库Knowledge Graph则把实体和关系显式地建模成图结构适合多跳推理、关系查询。比如“某人的同事的上级是谁”这类问题需要在实体关系链上跳转树状的文本切片做不到。KG搭配RAG时通常先用LLM抽取query里的实体和关系再到图谱中查询子图把子图路径作为上下文喂给LLM。ontology RAG则更进一步它会利用本体论定义的概念层级和约束关系让检索结果更加逻辑严密。ontology和KG适合企业知识体系清晰、关系复杂度高、对准确率要求苛刻的场景但构建成本也高出好几个量级。实际项目中大部分场景一个“向量库关键词混合检索”就够用了。只有当查询里频繁出现“关系链”类问题或者业务数据天然是图结构时再引入KG。不要为了跟风上图谱建模和维护成本会让你怀疑人生。2.2 文档加载与分块策略最容易忽视的细节文档加载阶段有个容易踩的坑PDF里的表格、页眉页脚、图片文字混排直接解析出来经常是乱序的。我遇到过一份产品手册解析后所有表格内容错位检索出的上下文驴唇不对马嘴。建议先按页面布局做区域识别把标题、正文、表格拆开表格部分单独处理转成HTML或Markdown表格后保留结构再切分。文本加载不是“能读出来就行”而是“读出来的顺序和结构必须保留语义”。分块策略直接决定检索的粗细。分块太小语义不足分块太大噪声太多且容易超过LLM上下文限制。我的经验是一般问答场景chunk_size选300~500字符overlap设50~100字符如果是技术文档、法律条文这种本身段落结构清晰的可以按Markdown标题层级切割以保证每个chunk内部主题完整。这里有一个容易被忽略的点overlap不只是用来衔接上下文还能避免一个完整句子被从中间切开导致向量化时语义断裂。分块后建议在chunk的元数据里保留来源路径、文档标题、页码、甚至章节标题。这样在给LLM的上下文里可以带上引用信息回答时可以自动标注“根据XX文档第XX页”大大提升可信度。我见过不少团队把这块省掉后期做溯源审计时痛苦不堪。2.3 嵌入模型选型别只盯着效果还要看维度Embedding模型的核心作用是把文本映射到向量空间语义相近的文本向量距离近。市面上的选择非常多OpenAI的text-embedding-3-small、BGE系列、M3E、E5等。选型的核心指标不是越快越好而是和你query的领域分布匹配。通用场景下text-embedding-3-small的语义理解力和泛化性都很强但它有一个隐患知识库如果包含大量专业术语比如医疗、法律、金融通用embedding可能分不清术语间的细微差别。此时应该用领域微调过的embedding模型或者至少在业务数据上做效果评测。换个思路如果你的文本是中文为主用中文语料训练的BGE-large-zh可能比英文模型好不少。还有一个参数值得注意向量维度。text-embedding-3-small默认支持缩短维度你可以用1536维也可以缩到512维。维度越高语义区分度越强但存储和检索开销也越大。实际操作时建议先用默认维度跑通再对比降维后的效果不要一上来为了省空间强行降维很可能检索召回率明显掉下来。2.4 检索不是只有向量搜索混合检索与rerank向量搜索擅长语义相似匹配但它有个致命短板对关键词、专有名词、编号、型号这种精确匹配不敏感。比如用户问“A100显卡的显存带宽是多少”向量检索可能把A100识别成了其他语义相近的型号。这时候必须加上BM25或者TF-IDF这种关键词检索再做结果融合也就是混合检索。混合检索的融合策略有几种常见方案加权和、倒数排名融合RRF、或者用学习排序模型。落地最简单的是RRF它不依赖分数绝对值而是按排名倒数相加对向量和关键词两类得分尺度不一致问题不敏感。我建议先跑一轮候选取两类检索结果的Top50用RRF融合后取Top10再交给reranker。Rerank是提升准确率最有效的一招。简单说Retriever负责粗召回Reranker负责精排序。Cross-encoder类的rerank模型会把query和每个候选段落拼接起来逐对计算相关度分数精度比双塔向量检索高很多。代价是速度慢一些但因为只对几十个候选排序整体延迟可控。实践中加了rerank之后回答的准确率往往能提升10到20个百分点这是性价比极高的一个环节。3. 实操过程与核心环节实现3.1 在Mac上从零搭一套RAG知识库网上搜索“怎么在mac上搭建rag知识库”说明很多新手卡在了环境配置上。其实macOS是相当适合做RAG开发的尤其是M系列芯片跑embedding模型和本地LLM都算顺畅。我建议的起步方案是用Python虚拟环境搭配LangChain Chroma向量库 一个开源embedding模型LLM先用本地Ollama跑一个7B或13B模型或者接OpenAI的API。这里给出一套可以直接照抄的环境搭建步骤。# 1. 创建虚拟环境 python3 -m venv rag-env source rag-env/bin/activate # 2. 安装核心依赖 pip install langchain langchain-community langchain-chroma chromadb pip install sentence-transformers pypdf markdownify pip install openai这里解释一下为什么选Chroma它是轻量级本地向量数据库不需要单独启动服务数据可以持久化到本地目录适合原型验证。生产环境再换成Milvus、Weaviate或者PGVector也不冲突。接下来准备好你的数据目录。假设你有几份Markdown或PDF文件放在./docs目录下。下面是完整的索引构建代码from langchain_community.document_loaders import DirectoryLoader, TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma loader DirectoryLoader(./docs, glob**/*.md, loader_clsTextLoader) docs loader.load() splitter RecursiveCharacterTextSplitter( chunk_size400, chunk_overlap80, separators[\n\n, \n, 。, , , , , ], keep_separatorTrue ) chunks splitter.split_documents(docs) embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-large-zh-v1.5) vectorstore Chroma.from_documents(chunks, embeddings, persist_directory./chroma_db)这段代码里有两个值得讲的地方。第一个是separators参数我按“段落、换行、句号、感叹号、问号、逗号、空格”的顺序逐级切分目的是优先保留完整句子实在句子太长才往标点处切。这比默认只按换行切出来的chunk质量高不少。第二个是embedding模型我用了BGE的轻量版它在中文语义检索上表现稳定而且支持本地推理不需要联网。索引构建完成后查询部分只需要做三件事向量检索、拼prompt、调用LLM。一个最简版本如下query 产品的保修政策是什么 retriever vectorstore.as_retriever(search_kwargs{k: 5}) relevant_docs retriever.invoke(query) context \n\n.join([doc.page_content for doc in relevant_docs]) prompt f请根据以下资料回答问题。如果资料中没有相关内容请直接说“资料中未找到相关信息”不要编造。 资料 {context} 问题{query} 答案然后把这个prompt交给LLM。如果用Ollama本地模型from langchain_community.llms import Ollama llm Ollama(modelqwen2.5:7b, temperature0.1) print(llm.invoke(prompt))这里temperature一定要控制在0.1以下否则模型容易自由发挥。我之前用一个默认temperature0.7的模型测试好多次答案比资料原文还丰富全是幻觉后来调到0.1后明显规整了。3.2 混合检索与Rerank的落地实现上述最简版本只有向量检索实际项目准确率往往不够。我来演示加上BM25和rerank的完整做法。先用rank_bm25计算关键词得分然后和向量得分融合。这里我用RRF融合import numpy as np from rank_bm25 import BM25Okapi # 假设docs_chunks是之前切分好的文本列表 tokenized_chunks [list(chunk) for chunk in chunks_list] bm25 BM25Okapi(tokenized_chunks) bm25_scores bm25.get_scores(list(query)) # 向量检索取top50 vec_results vectorstore.similarity_search_with_score(query, k50) # 构建doc_id - rank vector_rank_map {doc.metadata[id]: idx for idx, (doc, score) in enumerate(vec_results)} # bm25同样取前50的rank这里仅做原理示例RRF公式是score sum(1 / (k rank))其中k一般取60。这样无论两类检索的相似度分数尺度如何都能有效融合。融合后先取Top20再用cross-encoder的rerank模型精排。Rerank部分推荐sentence-transformers的cross-encoder/ms-marco-MiniLM-L-6-v2或者中文场景用bge-reranker-basefrom sentence_transformers import CrossEncoder reranker CrossEncoder(BAAI/bge-reranker-base) query_doc_pairs [(query, doc.page_content) for doc in top_candidates] scores reranker.predict(query_doc_pairs) top_docs [doc for _, doc in sorted(zip(scores, top_candidates), keylambda x: x[0], reverseTrue)][:5]把rerank后的Top5作为上下文喂给LLM。这一套流程跑下来我直观感受是回答的“命中感”强了很多不再经常出现检索到无关段落、结果驴唇不对马嘴的情况。3.3 结构化知识库与图谱库在什么时机介入如果你发现向量检索在数值、条件、关系类问题上频繁出错这时候才需要重新评估知识结构。举个例子某团队做设备运维问答用户会问“哪台设备最近七天故障次数最多”。这种问题本质上是一个计数排序查询向量检索几乎不可能精准返回。正确做法是把设备状态存到数据库表里用NL2SQL把用户query转换成SQL执行然后把查询结果转成描述文本再馈给LLM生成解释。这也是结构化知识库配合RAG的典型形态。KG知识库的介入时机更晚。只有当你的知识模型存在多跳关系比如“某部门经理负责的项目分布在哪些城市”并且这种关系被反复查询时才值得构建图谱。图谱构建需要定义实体类型、关系类型、属性以及实体消歧。一个折中的方案是“向量图谱混合”先通过向量检索找出可能的实体再到图谱上做子图扩展最后把子图包含的路径信息作为额外上下文。ontology RAG则是图谱的加强版在实体关系之上再定义概念层级和约束。比如在医学场景中“高血压”和“血压升高”的关系需要本体来约束否则图谱容易把两个概念当成独立实体。Ontology的构建需要领域专家参与成本很高在垂直领域知识密度非常大的场景才会考虑。4. 常见问题与排查技巧实录4.1 RAG瓶颈上下文污染与幻觉RAG最常被诟病的安全区问题就是检索到的内容虽然有但里面夹杂了无关信息模型被“带偏”。我称之为“上下文污染”。比如用户问A检索出Top5里有一篇讲A和B对比的文档模型可能顺带把B的内容也答进来。解决这个问题的核心在rerank和阈值控制对检索结果做一个最低相关度分数过滤如果得分普遍很低干脆返回“资料中未找到”。我建议给检索环节加一个监控日志每次查询记录top文档的相关性分数。如果发现很多分数低于0.4不同embedding分数范围不同先观察分布那大概率是分块不合适或embedding质量不足而不是LLM的问题。这一步很关键很多人一发现回答质量差就调prompt其实问题在更上游。4.2 分块大小和overlap的影响我实测过一个很典型的case同一份合同文本chunk_size200时检索到的合同条款常常不完整模型无法判断条款的上下文限制chunk_size1000时每个chunk包含太多不同条款模型容易被干扰。正确的做法是先做“检索评测集”构造20~30个真实用户问题标记每个问题的标准答案所在段落然后跑不同分块参数对比检索命中率。如果你没有评测集调优基本是靠感觉效果忽好忽坏。这个评测集不用很大但覆盖查询类型要全面事实型、对比型、列表型、步骤型。有了它后面调embedding、调rerank都能量化比较。4.3 图片和表格内容怎么处理RAG知识库能存储图片吗这个热词搜索频率很高。直接说是可以的但不是把原始图片存进去而是需要先把图片中的信息提取出来。如果图片里有文字用OCR比如PaddleOCR识别成文本如果图片本身是图表、流程图还要额外做图表理解或者由多模态模型生成图的描述文本再把描述文本向量化存储。检索时匹配的是描述文本而不是像素数据。表格的处理类似不要直接丢进向量库。建议把表格转成markdown表格或HTML然后在分块时保留结构。如果表格特别大先按行拆分每行带上表头字段名这样检索一条“某字段满足某条件”的记录时向量能匹配到对应的字段上下文。我见过不少项目因为表格处理粗糙导致答案里数值张冠李戴这种问题靠调prompt是救不回来的。4.4 常见问题速查表让你少走弯路现象可能原因解决方向回答找不到资料内容分块过大/embedding不匹配缩小chunk增加overlap换领域embedding回答总是多出额外信息上下文包含无关chunk加rerank降低TopK加相关度阈值数值和条件查询不准向量检索不适配结构化查询改为SQL检索或NL2SQL方案模型照抄资料里的错字文档清洗不到位增加文本清理和纠错流程检索速度慢向量库并发/维度太高换索引HNSW考虑降维或换库专业术语识别差通用embedding不覆盖领域微调embedding或在prompt里加术语映射4.5 一点避坑心得最后分享一个实操中非常容易踩的坑RAG上线前一定要做“否定测试”。也就是故意问一些知识库里不存在的问题看模型是否敢于回答“不知道”。如果模型硬答说明你的系统提示词里没有约束或者temperature太高。一个好的RAG系统应该既有“答得出”的能力也有“拒答”的能力。拒答不是产品缺陷恰恰是可信度的体现。另外千万别忽略日志。每次查询记录下检索到的文档ID、相关度分数、模型输出。这样出问题时能快速定位是哪一环节而不是对着一个“不准确的回答”干瞪眼。我自己的项目里日志里90%的问题最终都指向数据清洗和检索质量真正要调模型参数的极少。这个结论也印证了RAG的核心价值决定天花板的不是大模型而是你喂给它的知识和检索质量。按照这套思路你可以把RAG从一个“能跑的demo”升级成一个“能用的系统”。多花时间在分块策略、embedding评测、检索融合和否定测试上效果提升会比换更强的LLM明显得多。
