1. 为什么做本地私有RAG以及这篇复盘会讲什么最近我花了两周时间从零搭了一套“本地私有RAG”出来。起因其实特别朴素公司内部有一堆产品手册、FAQ、解决方案文档散落在各个共享盘和协作工具里业务同事每次找资料都要翻半天问AI吧又不敢把内部资料传去云端。我就想能不能用RAG在本地起一个知识库问答把数据完全留在内网模型也用本地开源模型一分钱API费用不花。做完之后效果超出预期也踩了不少坑所以决定开一个“从零搭建本地私有RAG全复盘”系列把完整过程记录下来。这篇是系列的第01篇重点解决“从零起步”的问题本地私有RAG到底由哪些部分组成、怎么选型、文档怎么切块、向量化怎么做、检索和问答链路怎么串起来。我会把整套流程用“最小可用方案”跑通再讨论表格数据怎么入库、切块参数怎么调、检索效果不好怎么排查。适合正在考虑自建RAG的工程师、对本地部署感兴趣的产品经理以及想低成本做企业知识库的个人开发者。先说结论本地私有RAG完全可行而且成本比很多人想象中低。一套可以日常使用的方案只需要一台16GB内存的电脑、几个开源模型、几个免费开源组件就能把“文档问答”这件事做得比较稳。如果你想了解的不是原理而是“怎么跑起来”这一篇可以直接照着操作。2. 整体设计思路先界定问题再谈技术选型2.1 RAG到底解决什么问题不解决什么问题很多人刚开始接触RAG容易把它当成“万能问答系统”。实际上RAG解决的核心问题只有一个让大模型在回答时能引用外部知识而不是只靠参数里记的东西。它把“检索”和“生成”两件事拼在一起先从知识库里找出与问题相关的片段再把片段塞进提示词让模型基于这些片段作答。这样做的直接好处是知识可以随时更新不用重新训练模型回答还可以追溯到来源这在企业场景里非常重要。但RAG不解决所有问题。比如高频的重复性咨询用规则或FAQ系统反而更快需要多表关联的复杂数据统计RAG做起来很吃力往往要结合Text2SQL涉及大量短文本、强逻辑推理的需求纯向量检索会显得机械可能要上升到Agentic RAG。我一开始踩的坑就是把所有问题都往RAG上放结果有些场景效果很勉强。后来我给自己定了一个判断标准如果答案在文档里能直接找到而且问题模式相对固定那就适合用RAG如果答案需要跨多份文档推理、汇总、对比RAG也能做但要把检索和提示词设计得更精细。回到“本地私有”这个关键词。为什么一定要强调本地私有最直接的原因是数据安全。企业内部资料一旦经过外部API哪怕只是传一个片段去检索合规层面都很难交代。本地私有意味着数据从加载、切块、向量化到检索生成全流程都不出内网。这一点在银行、医疗、制造等对数据敏感度极高的行业几乎是硬性要求。即使你只是个人用户有些笔记、合同、个人文档也不适合传到云端那么本地RAG就是一个非常自然的解法。2.2 最小可用架构五件套缺一不可本地私有RAG的完整链路本质上是一条流水线。我最初以为只要装个模型、丢几份文档进去就能问答结果发现远远不够。拆开来看一套能用的方案至少包含五层数据加载层读取PDF、Word、Markdown、Excel、网页等不同格式的文档转成纯文本。这一层容易出问题因为PDF有扫描版、有表格、有双栏排版稍不注意内容就是乱的。切块层把长文档切成适当大小的chunk方便后续向量化和检索。切得太小语义不完整切得太大检索噪音多这一步是效果好坏的分水岭。向量化层用Embedding模型把文本块转成向量。同一个知识库用的Embedding模型直接决定了“语义相似”到底准不准。检索层把用户问题也转成向量在向量库里做相似度搜索召回最相关的chunk。这里还涉及TopK选择、重排rerank等操作。生成层把召回片段和原始问题拼接成提示词交给本地LLM生成最终答案。有了这个五件套的概念你就不会一上来被各种名词搞晕。后续所有调优本质上都在调这五层里的某个环节。举个例子如果你发现回答“牛头不对马嘴”问题可能出在切块层也可能出在向量化层而不是LLM本身差。理解这条流水线后续排查故障会快很多。2.3 技术选型向量库、模型、框架怎么配选型这件事网上资料很多但容易把人绕晕。我实际对比之后给出一个适合本地方案的推荐组合Ollama负责加载和运行本地大模型bge-m3做EmbeddingChroma作为向量数据库Python LangChain做编排。这套组合的好处是全部免费、开源、社区活跃而且对机器性能要求不高。如果你追求极简甚至可以不装LangChain直接用Chroma的API手写完整流程后面我会给出这种写法。向量库的选型是很多人纠结的地方。我对比过Chroma、Qdrant、Milvus三款简单说结论数据量在百万级向量以下Chroma足够它支持持久化、内存模式安装就是一个pip包对新手极其友好Qdrant性能更强但需要单独起服务虽然也有本地模式Milvus适合百万级以上的生产环境功能完整但部署复杂度高。个人项目或中小型企业内部工具别一上来就上Milvus维护成本会让你怀疑人生。大模型的选择也很有讲究。本地方案里7B到14B参数量的模型是性价比最高的一档。7B模型对显存要求低普通消费级显卡就能跑日常问答够用14B模型理解力更强但显存占用和推理速度要权衡。我自己常用的是Qwen系列中文能力扎实对RAG场景的指令理解也很稳。Embedding模型方面bge-m3是目前中文综合能力很能打的选择支持8192长度输入对长文档切块非常友好如果机器资源紧张可以用更轻的模型比如text2vec-base但检索精度会下降一些。下面这张表是我当时做选型时整理的对比基本可以照抄组件推荐方案备选方案说明本地LLMQwen2.5-7B-InstructLlama3.1-8B、Phi-3中文效果好显存需求低Embeddingbge-m3text2vec-large-chinese中文语义理解强支持长文本向量库ChromaQdrant、Milvus轻量、免部署、够用编排框架LangChainLlamaIndex、手写生态好组件齐全模型运行Ollamallama.cpp、vLLM安装简单自带管理命令你可能会问为什么不直接推荐LlamaIndex不是它不好而是LangChain在RAG周边的工具链更丰富比如文档加载器、文本分割器、检索后处理模块遇到问题搜资料也方便。LlamaIndex在“索引”这件事上做得更专精如果你要处理的是超大批量文档可以再研究一下。但第一篇复盘我不想让你陷入框架之争先把一套跑通后面再演进不迟。3. 核心细节解析文档清洗、切块、向量化一个都不能省3.1 文档加载不是“读文件”那么简单文档加载阶段很多人以为调用一个loader就结束了。实际执行中PDF的噩梦你会很快体会到。我第一天测试时丢进去一份扫描版PDF加载出来的全是乱码检索答案自然是乱七八糟。后来才搞清楚扫描版PDF本质是图片必须先做OCR否则任何解析工具都拿不到文字。本地OCR我推荐PaddleOCR或TesseractPaddleOCR中文识别效果明显更好缺点是首次下载模型比较慢但一劳永逸。另一个高频问题是双栏排版和页眉页脚干扰。论文、手册、行业报告经常用双栏排版如果按普通单栏文本解析两栏文字会混在一起切出来的chunk语义完全错乱。解决办法是解析时开启layout分析或者干脆用Markdown格式的源文档。我现在的习惯是能用Markdown或Word源文件就优先用源文件只有格式实在无法获取时才依赖PDF而且PDF一定要先检查解析结果别拿乱码文档往下游传。表格文件的处理更特殊。Excel或Word里的表格直接转成纯文本会丢掉行列关系导致语义信息缺失。比如一份产品参数表型号、尺寸、功率放在不同列转成纯文本后所有值连成一串检索时完全没法对齐。这个我在第3.4节会专门给出一种可行的入库方案直接把表格转成结构化描述或问答对效果比硬塞纯文本好得多。3.2 切块策略固定长度、递归切分与语义切分的选择切块chunking是RAG项目里最容易被低估的一步。我最初图省事直接用固定长度切比如每100个字符切一块。结果问题来了一句话被从中间截断语义碎得没法看检索出来的片段经常是半句话。后来换成递归字符切分器通过分隔符优先级来减少切断语义的概率效果立刻改善不少。具体参数上我推荐chunk_size设置在300到600个字符之间overlap设置在50到100之间。过大的chunk虽然语义完整但检索时会把太多无关信息带进提示词稀释答案精度过小的chunk则语义不完整检索容易漏。这里有一个很直观的类比切块就像切西瓜切太小一嘴吃不到多少果肉切太大一口又啃不完。overlap是让相邻块之间有重叠区域保证跨块的信息不丢失。更进阶的做法是基于语义切分比如用嵌入向量检测主题突变点来分块或者用LLM判断段落边界。这类方法效果好但计算成本高不适合文档量很大的场景。我的实践心得是先跑通固定策略再针对效果不好的文档单独调参。RAG项目百分之八十的检索问题靠仔细调整切块参数就能解决一大半不用急着上复杂方案。3.3 Embedding模型选型和向量化细节Embedding模型是RAG的“翻译官”它把人类语言翻译成向量空间里的坐标。bge-m3是目前中文场景很值得推荐的选择它对中文长文本的支持和小文件检索的稳定度都相当不错。使用Ollama可以直接拉取bge-m3模型一条命令就能启动Embedding服务方便得很。向量化时有个细节容易忽略文本长度。Embedding模型一般有最大输入长度限制bge-m3支持8192但大部分Embedding模型在512到1024之间。如果你的chunk超过模型上限会被截断语义就残缺了。所以在切块时就要考虑Embedding模型的长度约束。另一个细节是向量归一化。有些检索实现里归一化能提升余弦相似度的区分度Chroma会自动处理大部分情况但你做手写检索时要注意。我实测bge-m3在中文产品文档上的检索准确率明显好过之前用的text2vec。如果你用英文文档多也可以考虑开源的英文Embedding模型但中文场景优先bge-m3这个结论目前还是比较稳的。向量维度方面bge-m3默认输出1024维相比传统模型会占更多内存但换来的是更细粒度的语义区分个人项目完全值得。3.4 系列产品表格怎么存入RAG知识库热搜词里有人问“系列产品表格怎么存入rag知识库”这个问题特别典型。我实际处理过一份多系列产品参数表横竖都有关联直接切块后检索效果惨不忍睹。经过几次调整我总结出一套可行做法先把表格转成“描述性文本”再按产品维度拆分成多个文本块入库。举个例子原表格是这样的系列型号功率(W)电压(V)特点A系列A1100220静音A系列A2150220高压B系列B1200380防爆不要试图把整张表塞进一个chunk而是按型号逐条转成自然语言描述“型号A1属于A系列功率100W额定电压220V特点是静音运行。”这样每个型号都是一个独立的语义单元检索“哪款静音”时能精确命中A1。如果知识库的查询模式经常是“对比两个型号”可以额外生成一些对比摘要块。对于数据量很大、查询很复杂的表格建议直接走Text2SQL路径让模型生成SQL去查数据库而不是靠RAG硬扛。这个思路在很多场景都通用遇到结构化数据先考虑“如何转成适合检索的文本形态”而不是“直接往里塞”。RAG本质上是文本检索结构化数据需要做一层“语义化”转换才能发挥向量检索优势。3.5 本地ERP与LLM结合的产品检索场景热搜里有“本地erp rag llm 产品检索 semantic kerner 实例”虽然这个表述有些乱但背后的需求很实际把ERP系统里的产品数据、物料描述、历史报价、客户反馈等放到RAG知识库让内部人员用自然语言检索。我做过一个类似的验证场景把某个产品线的规格、安装说明、常见故障、售后记录都导入本地RAG然后问“这个型号的安装要注意什么”“客户反馈最多的问题是哪些”系统能基于内部文档给出答案同时附上来源文件。这个场景和纯文档问答的区别在于数据源更杂有结构化数据、半结构化日志、非结构化文档需要先做数据整合和清洗再入库。如果你用的是类似Semantic Kernel的编排框架也可以把RAG封装成一个“产品检索技能”外部聊天机器人或内部系统通过统一接口调用。也就是说RAG不是一个孤立产品它是LLM应用里的一个“记忆增强组件”。这个思路对后续扩展特别重要后面第5.4节我还会细讲。4. 实操过程从安装环境到跑通第一个问答4.1 环境准备安装Ollama、Python依赖和向量库实操部分我按自己验证过的顺序来写。假设你用的是Windows或macOS/Linux思路都一样。第一步是安装Ollama它负责管理本地模型安装完成之后命令行执行ollama pull qwen2.5:7b ollama pull bge-m3第一条命令下载并运行大模型第二条是Embedding模型。Ollama会把模型管理得很好不需要手动配置CUDA之类的环境前提是你的机器上装了显卡驱动。如果你只有CPU也能跑就是慢一些。7B模型量化后差不多4到5GB空间16GB内存的机器跑起来比较稳。第二步是创建Python虚拟环境安装依赖。我推荐用conda或venv避免把系统Python环境搞乱。核心依赖就几个pip install chromadb langchain langchain-community sentence-transformers pypdf这里Chroma是向量库LangChain负责文档加载和切分sentence-transformers用来做Embedding如果你的流程不通过Ollama调Embedding。pypdf用于解析PDF。实际安装时要注意版本兼容我建议不要一次装太多最新版本锁定主版本号避免API变动导致代码报错。4.2 文档导入加载、切块、向量化、入库文档导入是整个RAG流程里最“重”的一步。我写了一个脚本把目标目录下的所有文档逐个加载、切块、向量化然后写入Chroma持久化目录。下面是一个精简版本你可以直接参考import os from langchain_community.document_loaders import DirectoryLoader, TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma # 1. 加载文档 loader DirectoryLoader(./docs, glob**/*.txt, loader_clsTextLoader) docs loader.load() print(f加载文档数: {len(docs)}) # 2. 切块 splitter RecursiveCharacterTextSplitter( chunk_size400, chunk_overlap80, separators[\n\n, \n, 。, , , , , ] ) chunks splitter.split_documents(docs) print(f切块数量: {len(chunks)}) # 3. 向量化使用Ollama里的bge-m3 embeddings OllamaEmbeddings(modelbge-m3) # 4. 写入Chroma vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db ) print(入库完成)切块参数中我加了一组中文分隔符这是非常关键的经验。默认的splitter对中文支持一般分隔符里有“。”和“”之后切块才更符合中文语义边界。另外chunk_size我设的是400按中文字符数计算实际体验下来这个长度在“语义完整”和“检索精准”之间取得了不错平衡。如果你的文档比较短可以调小文档很长且主题单一可以调大一点。4.3 检索问答先召回再生成附上来源文档入库之后问答环节就简单了。核心是两步先做相似度检索再拼接提示词交给LLM。我写的问答函数如下from langchain_community.llms import Ollama from langchain.chains import RetrievalQA # 加载已有向量库 vectorstore Chroma( persist_directory./chroma_db, embedding_functionOllamaEmbeddings(modelbge-m3) ) # 创建检索器 retriever vectorstore.as_retriever(search_kwargs{k: 5}) # 创建LLM llm Ollama(modelqwen2.5:7b, temperature0.2) # 组装问答链 qa RetrievalQA.from_chain_type( llmllm, chain_typestuff, retrieverretriever, return_source_documentsTrue ) # 提问 result qa.invoke({query: 这个型号的安装需要注意什么}) print(result[result]) print(来源文档) for doc in result[source_documents]: print(-, doc.metadata.get(source), doc.page_content[:50])有个关键点把temperature设低一点比如0.1到0.3之间。RAG场景里你希望模型尽量遵循检索到的内容而不是自由发挥temperature太高容易“编造”。另外TopK我设的是5因为7B模型上下文有限塞太多chunk反而干扰判断。如果你的文档比较细碎可以适当提高到8或10但要留意生成长度和模型上下文窗口。来源文档的展示也很重要。RAG在企业里能不能被信任很大程度上取决于“答案能不能溯源”。我在这个脚本里直接打印了来源文件名和片段实际产品里可以做成交互式链接点一下就能跳到原文。这是企业知识库最基本的需求不能省。4.4 首次跑通后的效果复盘我第一次跑通时用了一份约50页的产品手册总共切出180多个chunk。提问“这个产品支持哪些通讯协议”系统准确找出了手册中关于通讯协议的章节回答列出了Modbus、Profinet和EtherNet/IP并且给出来源页码。这个过程带给我很直观的感受RAG不像传统搜索引擎那样只把关键词命中的句子堆给你它能组织成自然语言答案而且限定在给定资料范围内。这种体验对内部知识库来说已经足够日常使用了。不过第一次跑通后的效果也是“初步可用”距离我真正放心把它交给业务同事还差不少打磨。比如有些问题答案被切块拆散检索召回的片段只覆盖了一半回答就漏了关键信息。还有一些专业缩写Embedding模型理解不到位检索时找不到对应内容。这些问题的排查方法我放在第5章详细讲。4.5 进阶调优重排、元数据过滤与提示词约束基础链路跑通后如果想让效果更上一层楼有三个性价比很高的优化点。第一个是重排rerank。向量检索是先粗召回把TopK个候选捞出来然后用一个专门的重排模型对候选重新打分。这一招对提升准确率非常明显尤其当知识库里相似文档很多时。常见的做法是接一个rerank模型例如bge-reranker它会综合语义和相关性给出更精细的排序。第二个是元数据过滤。入库时给每个chunk打上来源、日期、类型、部门等标签检索时先按条件过滤再向量搜索。比如只查“2024年之后的售后记录”就不至于把老文档一起召回。元数据过滤在做企业知识库时几乎必备否则跨年份、跨部门的内容混在一起答案会很含糊。第三个是提示词工程。我最初只是简单地把检索片段拼到问题前面后来发现效果一般。改进后的做法是在提示词里明确告诉模型“只基于提供的资料作答资料中没有提到的内容直接回答‘未找到相关信息’不要编造。”这简单的一句话能把幻觉比例大幅压下来。如果你做的是企业内部知识库这句话基本是标配。5. 常见问题与排查技巧实录5.1 检索不到内容或者答案明显偏题这是最常遇到的问题。排查顺序我建议是先看检索召回片段是否相关再决定要不要动切块或Embedding。怎么判断“片段是否相关”把用户问题单独拿出来直接打印检索出的chunk看前几名是不是和问题有关。如果召回都不相关那就是检索阶段有问题跟生成阶段无关。常见的诱发原因有三个。一是切块太大或太小太大导致chunk里无关信息太多相似度被稀释太小导致语义残缺根本匹配不上。二是Embedding模型与文档语言不匹配比如中文文档却用英文Embedding模型效果一定差。三是文档本身有大量噪音比如页眉页脚、目录页、表格错乱这些内容被切进来后干扰检索。排查时按这个顺序走大部分问题能定位。5.2 模型回答出现“幻觉”资料里没有的内容也敢编大模型天生有“补全”倾向RAG场景下的幻觉大多来自提示词约束不到位。我实测下来最有效的一条是显式加上“未找到相关内容时如实说明”同时降低temperature。另一个原因是TopK取得太大混进了不相关的chunk模型把它们也当成事实依据。还有一个小技巧如果知识库答案以“是/否”或简单枚举为主可以在提示词里要求模型“先引用原文再给结论”这样模型会不自觉地贴近检索内容减少自由发挥。另外尽量别让模型回答超出检索范围的问题。实际产品里可以配置一个“兜底”逻辑当检索相似度低于某个阈值时直接不调用LLM生成而是提示“知识库中未找到相关内容”。这样至少不会一本正经地胡说八道。5.3 本地资源占用高运行卡顿怎么办本地RAG对资源的消耗主要集中在三块Embedding模型、LLM推理、向量库索引。我一开始贪方便把7B模型常驻显存跑一条问答要等十几秒后来发现是检索环节和生成环节串行导致的。优化思路有四个一是把Embedding模型和LLM分别部署或者用CPU跑EmbeddingGPU跑LLM避免抢占显存二是控制同时检索的chunk数量减少给模型的上下文长度缩短生成时间三是用量化版本模型比如Q4_K_M量化显存占用能降低一半左右速度还快四是向量库的数据量如果很大可以给Chroma开启持久化索引避免每次启动都重新加载。5.4 常见问题速查表症状可能原因建议处理方式检索结果不相关切块参数不合理、Embedding模型不匹配调小chunk、增加overlap、换bge-m3答案漏掉关键点TopK太小、切块破坏了语义增大TopK、检查切块边界回答凭空编造事实temperature过高、提示词约束弱降到0.10.3增加“基于资料回答”约束速度慢模型常驻显存、chunk过多用量化模型、减少检索TopK、分开部署表格内容检索混乱表格直接转文本丢失结构转成描述性文本或问答对再入库扫描版PDF乱码缺少OCR处理先跑OCR再解析这张表我只列了最典型的六类实际项目中大概率还会遇到更多奇怪问题但排查思路是相通的从数据入口开始检查确认数据没坏再看切块和向量化最后才是模型和提示词。很多人一出问题就怀疑LLM选型其实大多数RAG故障都出在数据侧这是我复盘下来最大的一个感受。6. 进阶方向RAG与MCP、Agentic RAG和多轮对话设计6.1 RAG和MCP到底有什么区别最近“rag和mcp区别”这个话题被讨论得很多。我自己的理解是RAG是一种记忆增强方案解决的是“模型不知道私有知识”的问题MCP则是工具调用的标准化协议解决的是“模型无法操作外部系统”的问题。一个是管“知识输入”一个是管“动作输出”两者不是二选一而是可以配合使用。在实际系统里你可以先用RAG让模型理解文档内容再通过MCP调用内部系统去执行某些操作。比如用户问“帮我查一下这个客户的订单状态”先通过RAG找到这个客户对应的订单编号规则和业务文档再让模型通过MCP去订单系统查询。这样组合出来的系统才有真正的业务价值而不是一个只能聊天的问答机器人。这个理解对做企业内部AI助手非常重要。6.2 Agentic RAG从“一次检索”到“多步推理”传统RAG是“检索一次生成一次”比较机械。Agentic RAG则是让模型拥有更多决策权它可以判断当前信息是否足够不够就继续检索、改写问题、筛选chunk甚至同时调用多个检索源再综合答案。你可以把它看作把RAG链路交给一个Agent来编排。我在实践中最受益的一点是“历史用例检索与实例化适配”这个思路它其实很适合Agentic架构。比如售后场景里知识库存了大量历史故障处理用例上面提到一部分用户在使用过程中遇到了一种提示系统自动把历史相似案例召回然后结合当前设备的实际参数做适配最终生成的解决步骤比单纯匹配文档更符合现场情况。要做到这一点模型必须先判断“当前问题属于哪类故障”再决定检索哪些维度的资料。这是普通RAG很难完成的需要设计Agent的决策循环。6.3 多轮对话怎么设计才能不丢上下文RAG多轮对话的设计确实是个老难题。最简单的做法是每轮都重新检索然后只把当前问题和最近几轮对话摘要塞给模型。但如果用户问“那它的防水等级呢”缺少“它”的指代信息检索根本不知道在问什么。我的建议是两步走第一用LLM把历史对话改写成“独立问题”再做检索第二把传统RAG的“单轮检索”升级为“历史及相关实体检索”确保指代消解后的信息能正确命中知识库。举一个例子用户先问“A系列支持哪些通讯协议”系统回答后用户又问“那它的电源电压呢”。如果直接拿第二句去检索大概率搜不到。“电源电压”没问题但“它”没有定位到A系列。如果先做指代消解把问题改写为“A系列的电源电压是多少”再检索结果就准多了。这个改写步骤可以用一段独立的LLM调用实现成本不高但对多轮体验提升明显。6.4 把RAG做成“技能”而不是“整个应用”最后一个进阶思路和“skill怎么和rag结合起来”这个热搜词有关。在比较大的LLM应用里RAG不应该直接暴露给用户而是封装成一个可以被调用的“技能”。比如系统接收到用户问题后先做意图识别如果判断是“查资料”就调用RAG技能如果判断是“执行操作”就调用工作流技能。这样RAG可以和业务系统解耦后续增加新模型、新知识库只需要改技能内部实现不用动整个应用。我自己的下一步计划就是把这个本地私有RAG从“文档问答Demo”升级成可被业务系统调用的服务。具体包括增加用户权限隔离、接入历史会话管理、把检索日志和反馈数据收起来为后续继续优化做准备。这些内容我会在系列后续篇里慢慢展开第一篇先到这里。最后分享一个实际操作中的小技巧无论你用什么框架先准备一个“最小测试集”包含5到10个典型问题每次改动知识库或参数后统一跑一遍。没有测试集你会永远在“感觉效果好了一些”和“怎么又变差了”之间反复横跳而这种玄学式调优在RAG项目里是最消耗耐心的。用数据判断每次调整的效果才是把项目持续做下去的正确方式。 本地私有RAG从零搭建全复盘：架构选型、文档切块与向量化实践
1. 为什么做本地私有RAG以及这篇复盘会讲什么最近我花了两周时间从零搭了一套“本地私有RAG”出来。起因其实特别朴素公司内部有一堆产品手册、FAQ、解决方案文档散落在各个共享盘和协作工具里业务同事每次找资料都要翻半天问AI吧又不敢把内部资料传去云端。我就想能不能用RAG在本地起一个知识库问答把数据完全留在内网模型也用本地开源模型一分钱API费用不花。做完之后效果超出预期也踩了不少坑所以决定开一个“从零搭建本地私有RAG全复盘”系列把完整过程记录下来。这篇是系列的第01篇重点解决“从零起步”的问题本地私有RAG到底由哪些部分组成、怎么选型、文档怎么切块、向量化怎么做、检索和问答链路怎么串起来。我会把整套流程用“最小可用方案”跑通再讨论表格数据怎么入库、切块参数怎么调、检索效果不好怎么排查。适合正在考虑自建RAG的工程师、对本地部署感兴趣的产品经理以及想低成本做企业知识库的个人开发者。先说结论本地私有RAG完全可行而且成本比很多人想象中低。一套可以日常使用的方案只需要一台16GB内存的电脑、几个开源模型、几个免费开源组件就能把“文档问答”这件事做得比较稳。如果你想了解的不是原理而是“怎么跑起来”这一篇可以直接照着操作。2. 整体设计思路先界定问题再谈技术选型2.1 RAG到底解决什么问题不解决什么问题很多人刚开始接触RAG容易把它当成“万能问答系统”。实际上RAG解决的核心问题只有一个让大模型在回答时能引用外部知识而不是只靠参数里记的东西。它把“检索”和“生成”两件事拼在一起先从知识库里找出与问题相关的片段再把片段塞进提示词让模型基于这些片段作答。这样做的直接好处是知识可以随时更新不用重新训练模型回答还可以追溯到来源这在企业场景里非常重要。但RAG不解决所有问题。比如高频的重复性咨询用规则或FAQ系统反而更快需要多表关联的复杂数据统计RAG做起来很吃力往往要结合Text2SQL涉及大量短文本、强逻辑推理的需求纯向量检索会显得机械可能要上升到Agentic RAG。我一开始踩的坑就是把所有问题都往RAG上放结果有些场景效果很勉强。后来我给自己定了一个判断标准如果答案在文档里能直接找到而且问题模式相对固定那就适合用RAG如果答案需要跨多份文档推理、汇总、对比RAG也能做但要把检索和提示词设计得更精细。回到“本地私有”这个关键词。为什么一定要强调本地私有最直接的原因是数据安全。企业内部资料一旦经过外部API哪怕只是传一个片段去检索合规层面都很难交代。本地私有意味着数据从加载、切块、向量化到检索生成全流程都不出内网。这一点在银行、医疗、制造等对数据敏感度极高的行业几乎是硬性要求。即使你只是个人用户有些笔记、合同、个人文档也不适合传到云端那么本地RAG就是一个非常自然的解法。2.2 最小可用架构五件套缺一不可本地私有RAG的完整链路本质上是一条流水线。我最初以为只要装个模型、丢几份文档进去就能问答结果发现远远不够。拆开来看一套能用的方案至少包含五层数据加载层读取PDF、Word、Markdown、Excel、网页等不同格式的文档转成纯文本。这一层容易出问题因为PDF有扫描版、有表格、有双栏排版稍不注意内容就是乱的。切块层把长文档切成适当大小的chunk方便后续向量化和检索。切得太小语义不完整切得太大检索噪音多这一步是效果好坏的分水岭。向量化层用Embedding模型把文本块转成向量。同一个知识库用的Embedding模型直接决定了“语义相似”到底准不准。检索层把用户问题也转成向量在向量库里做相似度搜索召回最相关的chunk。这里还涉及TopK选择、重排rerank等操作。生成层把召回片段和原始问题拼接成提示词交给本地LLM生成最终答案。有了这个五件套的概念你就不会一上来被各种名词搞晕。后续所有调优本质上都在调这五层里的某个环节。举个例子如果你发现回答“牛头不对马嘴”问题可能出在切块层也可能出在向量化层而不是LLM本身差。理解这条流水线后续排查故障会快很多。2.3 技术选型向量库、模型、框架怎么配选型这件事网上资料很多但容易把人绕晕。我实际对比之后给出一个适合本地方案的推荐组合Ollama负责加载和运行本地大模型bge-m3做EmbeddingChroma作为向量数据库Python LangChain做编排。这套组合的好处是全部免费、开源、社区活跃而且对机器性能要求不高。如果你追求极简甚至可以不装LangChain直接用Chroma的API手写完整流程后面我会给出这种写法。向量库的选型是很多人纠结的地方。我对比过Chroma、Qdrant、Milvus三款简单说结论数据量在百万级向量以下Chroma足够它支持持久化、内存模式安装就是一个pip包对新手极其友好Qdrant性能更强但需要单独起服务虽然也有本地模式Milvus适合百万级以上的生产环境功能完整但部署复杂度高。个人项目或中小型企业内部工具别一上来就上Milvus维护成本会让你怀疑人生。大模型的选择也很有讲究。本地方案里7B到14B参数量的模型是性价比最高的一档。7B模型对显存要求低普通消费级显卡就能跑日常问答够用14B模型理解力更强但显存占用和推理速度要权衡。我自己常用的是Qwen系列中文能力扎实对RAG场景的指令理解也很稳。Embedding模型方面bge-m3是目前中文综合能力很能打的选择支持8192长度输入对长文档切块非常友好如果机器资源紧张可以用更轻的模型比如text2vec-base但检索精度会下降一些。下面这张表是我当时做选型时整理的对比基本可以照抄组件推荐方案备选方案说明本地LLMQwen2.5-7B-InstructLlama3.1-8B、Phi-3中文效果好显存需求低Embeddingbge-m3text2vec-large-chinese中文语义理解强支持长文本向量库ChromaQdrant、Milvus轻量、免部署、够用编排框架LangChainLlamaIndex、手写生态好组件齐全模型运行Ollamallama.cpp、vLLM安装简单自带管理命令你可能会问为什么不直接推荐LlamaIndex不是它不好而是LangChain在RAG周边的工具链更丰富比如文档加载器、文本分割器、检索后处理模块遇到问题搜资料也方便。LlamaIndex在“索引”这件事上做得更专精如果你要处理的是超大批量文档可以再研究一下。但第一篇复盘我不想让你陷入框架之争先把一套跑通后面再演进不迟。3. 核心细节解析文档清洗、切块、向量化一个都不能省3.1 文档加载不是“读文件”那么简单文档加载阶段很多人以为调用一个loader就结束了。实际执行中PDF的噩梦你会很快体会到。我第一天测试时丢进去一份扫描版PDF加载出来的全是乱码检索答案自然是乱七八糟。后来才搞清楚扫描版PDF本质是图片必须先做OCR否则任何解析工具都拿不到文字。本地OCR我推荐PaddleOCR或TesseractPaddleOCR中文识别效果明显更好缺点是首次下载模型比较慢但一劳永逸。另一个高频问题是双栏排版和页眉页脚干扰。论文、手册、行业报告经常用双栏排版如果按普通单栏文本解析两栏文字会混在一起切出来的chunk语义完全错乱。解决办法是解析时开启layout分析或者干脆用Markdown格式的源文档。我现在的习惯是能用Markdown或Word源文件就优先用源文件只有格式实在无法获取时才依赖PDF而且PDF一定要先检查解析结果别拿乱码文档往下游传。表格文件的处理更特殊。Excel或Word里的表格直接转成纯文本会丢掉行列关系导致语义信息缺失。比如一份产品参数表型号、尺寸、功率放在不同列转成纯文本后所有值连成一串检索时完全没法对齐。这个我在第3.4节会专门给出一种可行的入库方案直接把表格转成结构化描述或问答对效果比硬塞纯文本好得多。3.2 切块策略固定长度、递归切分与语义切分的选择切块chunking是RAG项目里最容易被低估的一步。我最初图省事直接用固定长度切比如每100个字符切一块。结果问题来了一句话被从中间截断语义碎得没法看检索出来的片段经常是半句话。后来换成递归字符切分器通过分隔符优先级来减少切断语义的概率效果立刻改善不少。具体参数上我推荐chunk_size设置在300到600个字符之间overlap设置在50到100之间。过大的chunk虽然语义完整但检索时会把太多无关信息带进提示词稀释答案精度过小的chunk则语义不完整检索容易漏。这里有一个很直观的类比切块就像切西瓜切太小一嘴吃不到多少果肉切太大一口又啃不完。overlap是让相邻块之间有重叠区域保证跨块的信息不丢失。更进阶的做法是基于语义切分比如用嵌入向量检测主题突变点来分块或者用LLM判断段落边界。这类方法效果好但计算成本高不适合文档量很大的场景。我的实践心得是先跑通固定策略再针对效果不好的文档单独调参。RAG项目百分之八十的检索问题靠仔细调整切块参数就能解决一大半不用急着上复杂方案。3.3 Embedding模型选型和向量化细节Embedding模型是RAG的“翻译官”它把人类语言翻译成向量空间里的坐标。bge-m3是目前中文场景很值得推荐的选择它对中文长文本的支持和小文件检索的稳定度都相当不错。使用Ollama可以直接拉取bge-m3模型一条命令就能启动Embedding服务方便得很。向量化时有个细节容易忽略文本长度。Embedding模型一般有最大输入长度限制bge-m3支持8192但大部分Embedding模型在512到1024之间。如果你的chunk超过模型上限会被截断语义就残缺了。所以在切块时就要考虑Embedding模型的长度约束。另一个细节是向量归一化。有些检索实现里归一化能提升余弦相似度的区分度Chroma会自动处理大部分情况但你做手写检索时要注意。我实测bge-m3在中文产品文档上的检索准确率明显好过之前用的text2vec。如果你用英文文档多也可以考虑开源的英文Embedding模型但中文场景优先bge-m3这个结论目前还是比较稳的。向量维度方面bge-m3默认输出1024维相比传统模型会占更多内存但换来的是更细粒度的语义区分个人项目完全值得。3.4 系列产品表格怎么存入RAG知识库热搜词里有人问“系列产品表格怎么存入rag知识库”这个问题特别典型。我实际处理过一份多系列产品参数表横竖都有关联直接切块后检索效果惨不忍睹。经过几次调整我总结出一套可行做法先把表格转成“描述性文本”再按产品维度拆分成多个文本块入库。举个例子原表格是这样的系列型号功率(W)电压(V)特点A系列A1100220静音A系列A2150220高压B系列B1200380防爆不要试图把整张表塞进一个chunk而是按型号逐条转成自然语言描述“型号A1属于A系列功率100W额定电压220V特点是静音运行。”这样每个型号都是一个独立的语义单元检索“哪款静音”时能精确命中A1。如果知识库的查询模式经常是“对比两个型号”可以额外生成一些对比摘要块。对于数据量很大、查询很复杂的表格建议直接走Text2SQL路径让模型生成SQL去查数据库而不是靠RAG硬扛。这个思路在很多场景都通用遇到结构化数据先考虑“如何转成适合检索的文本形态”而不是“直接往里塞”。RAG本质上是文本检索结构化数据需要做一层“语义化”转换才能发挥向量检索优势。3.5 本地ERP与LLM结合的产品检索场景热搜里有“本地erp rag llm 产品检索 semantic kerner 实例”虽然这个表述有些乱但背后的需求很实际把ERP系统里的产品数据、物料描述、历史报价、客户反馈等放到RAG知识库让内部人员用自然语言检索。我做过一个类似的验证场景把某个产品线的规格、安装说明、常见故障、售后记录都导入本地RAG然后问“这个型号的安装要注意什么”“客户反馈最多的问题是哪些”系统能基于内部文档给出答案同时附上来源文件。这个场景和纯文档问答的区别在于数据源更杂有结构化数据、半结构化日志、非结构化文档需要先做数据整合和清洗再入库。如果你用的是类似Semantic Kernel的编排框架也可以把RAG封装成一个“产品检索技能”外部聊天机器人或内部系统通过统一接口调用。也就是说RAG不是一个孤立产品它是LLM应用里的一个“记忆增强组件”。这个思路对后续扩展特别重要后面第5.4节我还会细讲。4. 实操过程从安装环境到跑通第一个问答4.1 环境准备安装Ollama、Python依赖和向量库实操部分我按自己验证过的顺序来写。假设你用的是Windows或macOS/Linux思路都一样。第一步是安装Ollama它负责管理本地模型安装完成之后命令行执行ollama pull qwen2.5:7b ollama pull bge-m3第一条命令下载并运行大模型第二条是Embedding模型。Ollama会把模型管理得很好不需要手动配置CUDA之类的环境前提是你的机器上装了显卡驱动。如果你只有CPU也能跑就是慢一些。7B模型量化后差不多4到5GB空间16GB内存的机器跑起来比较稳。第二步是创建Python虚拟环境安装依赖。我推荐用conda或venv避免把系统Python环境搞乱。核心依赖就几个pip install chromadb langchain langchain-community sentence-transformers pypdf这里Chroma是向量库LangChain负责文档加载和切分sentence-transformers用来做Embedding如果你的流程不通过Ollama调Embedding。pypdf用于解析PDF。实际安装时要注意版本兼容我建议不要一次装太多最新版本锁定主版本号避免API变动导致代码报错。4.2 文档导入加载、切块、向量化、入库文档导入是整个RAG流程里最“重”的一步。我写了一个脚本把目标目录下的所有文档逐个加载、切块、向量化然后写入Chroma持久化目录。下面是一个精简版本你可以直接参考import os from langchain_community.document_loaders import DirectoryLoader, TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma # 1. 加载文档 loader DirectoryLoader(./docs, glob**/*.txt, loader_clsTextLoader) docs loader.load() print(f加载文档数: {len(docs)}) # 2. 切块 splitter RecursiveCharacterTextSplitter( chunk_size400, chunk_overlap80, separators[\n\n, \n, 。, , , , , ] ) chunks splitter.split_documents(docs) print(f切块数量: {len(chunks)}) # 3. 向量化使用Ollama里的bge-m3 embeddings OllamaEmbeddings(modelbge-m3) # 4. 写入Chroma vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db ) print(入库完成)切块参数中我加了一组中文分隔符这是非常关键的经验。默认的splitter对中文支持一般分隔符里有“。”和“”之后切块才更符合中文语义边界。另外chunk_size我设的是400按中文字符数计算实际体验下来这个长度在“语义完整”和“检索精准”之间取得了不错平衡。如果你的文档比较短可以调小文档很长且主题单一可以调大一点。4.3 检索问答先召回再生成附上来源文档入库之后问答环节就简单了。核心是两步先做相似度检索再拼接提示词交给LLM。我写的问答函数如下from langchain_community.llms import Ollama from langchain.chains import RetrievalQA # 加载已有向量库 vectorstore Chroma( persist_directory./chroma_db, embedding_functionOllamaEmbeddings(modelbge-m3) ) # 创建检索器 retriever vectorstore.as_retriever(search_kwargs{k: 5}) # 创建LLM llm Ollama(modelqwen2.5:7b, temperature0.2) # 组装问答链 qa RetrievalQA.from_chain_type( llmllm, chain_typestuff, retrieverretriever, return_source_documentsTrue ) # 提问 result qa.invoke({query: 这个型号的安装需要注意什么}) print(result[result]) print(来源文档) for doc in result[source_documents]: print(-, doc.metadata.get(source), doc.page_content[:50])有个关键点把temperature设低一点比如0.1到0.3之间。RAG场景里你希望模型尽量遵循检索到的内容而不是自由发挥temperature太高容易“编造”。另外TopK我设的是5因为7B模型上下文有限塞太多chunk反而干扰判断。如果你的文档比较细碎可以适当提高到8或10但要留意生成长度和模型上下文窗口。来源文档的展示也很重要。RAG在企业里能不能被信任很大程度上取决于“答案能不能溯源”。我在这个脚本里直接打印了来源文件名和片段实际产品里可以做成交互式链接点一下就能跳到原文。这是企业知识库最基本的需求不能省。4.4 首次跑通后的效果复盘我第一次跑通时用了一份约50页的产品手册总共切出180多个chunk。提问“这个产品支持哪些通讯协议”系统准确找出了手册中关于通讯协议的章节回答列出了Modbus、Profinet和EtherNet/IP并且给出来源页码。这个过程带给我很直观的感受RAG不像传统搜索引擎那样只把关键词命中的句子堆给你它能组织成自然语言答案而且限定在给定资料范围内。这种体验对内部知识库来说已经足够日常使用了。不过第一次跑通后的效果也是“初步可用”距离我真正放心把它交给业务同事还差不少打磨。比如有些问题答案被切块拆散检索召回的片段只覆盖了一半回答就漏了关键信息。还有一些专业缩写Embedding模型理解不到位检索时找不到对应内容。这些问题的排查方法我放在第5章详细讲。4.5 进阶调优重排、元数据过滤与提示词约束基础链路跑通后如果想让效果更上一层楼有三个性价比很高的优化点。第一个是重排rerank。向量检索是先粗召回把TopK个候选捞出来然后用一个专门的重排模型对候选重新打分。这一招对提升准确率非常明显尤其当知识库里相似文档很多时。常见的做法是接一个rerank模型例如bge-reranker它会综合语义和相关性给出更精细的排序。第二个是元数据过滤。入库时给每个chunk打上来源、日期、类型、部门等标签检索时先按条件过滤再向量搜索。比如只查“2024年之后的售后记录”就不至于把老文档一起召回。元数据过滤在做企业知识库时几乎必备否则跨年份、跨部门的内容混在一起答案会很含糊。第三个是提示词工程。我最初只是简单地把检索片段拼到问题前面后来发现效果一般。改进后的做法是在提示词里明确告诉模型“只基于提供的资料作答资料中没有提到的内容直接回答‘未找到相关信息’不要编造。”这简单的一句话能把幻觉比例大幅压下来。如果你做的是企业内部知识库这句话基本是标配。5. 常见问题与排查技巧实录5.1 检索不到内容或者答案明显偏题这是最常遇到的问题。排查顺序我建议是先看检索召回片段是否相关再决定要不要动切块或Embedding。怎么判断“片段是否相关”把用户问题单独拿出来直接打印检索出的chunk看前几名是不是和问题有关。如果召回都不相关那就是检索阶段有问题跟生成阶段无关。常见的诱发原因有三个。一是切块太大或太小太大导致chunk里无关信息太多相似度被稀释太小导致语义残缺根本匹配不上。二是Embedding模型与文档语言不匹配比如中文文档却用英文Embedding模型效果一定差。三是文档本身有大量噪音比如页眉页脚、目录页、表格错乱这些内容被切进来后干扰检索。排查时按这个顺序走大部分问题能定位。5.2 模型回答出现“幻觉”资料里没有的内容也敢编大模型天生有“补全”倾向RAG场景下的幻觉大多来自提示词约束不到位。我实测下来最有效的一条是显式加上“未找到相关内容时如实说明”同时降低temperature。另一个原因是TopK取得太大混进了不相关的chunk模型把它们也当成事实依据。还有一个小技巧如果知识库答案以“是/否”或简单枚举为主可以在提示词里要求模型“先引用原文再给结论”这样模型会不自觉地贴近检索内容减少自由发挥。另外尽量别让模型回答超出检索范围的问题。实际产品里可以配置一个“兜底”逻辑当检索相似度低于某个阈值时直接不调用LLM生成而是提示“知识库中未找到相关内容”。这样至少不会一本正经地胡说八道。5.3 本地资源占用高运行卡顿怎么办本地RAG对资源的消耗主要集中在三块Embedding模型、LLM推理、向量库索引。我一开始贪方便把7B模型常驻显存跑一条问答要等十几秒后来发现是检索环节和生成环节串行导致的。优化思路有四个一是把Embedding模型和LLM分别部署或者用CPU跑EmbeddingGPU跑LLM避免抢占显存二是控制同时检索的chunk数量减少给模型的上下文长度缩短生成时间三是用量化版本模型比如Q4_K_M量化显存占用能降低一半左右速度还快四是向量库的数据量如果很大可以给Chroma开启持久化索引避免每次启动都重新加载。5.4 常见问题速查表症状可能原因建议处理方式检索结果不相关切块参数不合理、Embedding模型不匹配调小chunk、增加overlap、换bge-m3答案漏掉关键点TopK太小、切块破坏了语义增大TopK、检查切块边界回答凭空编造事实temperature过高、提示词约束弱降到0.10.3增加“基于资料回答”约束速度慢模型常驻显存、chunk过多用量化模型、减少检索TopK、分开部署表格内容检索混乱表格直接转文本丢失结构转成描述性文本或问答对再入库扫描版PDF乱码缺少OCR处理先跑OCR再解析这张表我只列了最典型的六类实际项目中大概率还会遇到更多奇怪问题但排查思路是相通的从数据入口开始检查确认数据没坏再看切块和向量化最后才是模型和提示词。很多人一出问题就怀疑LLM选型其实大多数RAG故障都出在数据侧这是我复盘下来最大的一个感受。6. 进阶方向RAG与MCP、Agentic RAG和多轮对话设计6.1 RAG和MCP到底有什么区别最近“rag和mcp区别”这个话题被讨论得很多。我自己的理解是RAG是一种记忆增强方案解决的是“模型不知道私有知识”的问题MCP则是工具调用的标准化协议解决的是“模型无法操作外部系统”的问题。一个是管“知识输入”一个是管“动作输出”两者不是二选一而是可以配合使用。在实际系统里你可以先用RAG让模型理解文档内容再通过MCP调用内部系统去执行某些操作。比如用户问“帮我查一下这个客户的订单状态”先通过RAG找到这个客户对应的订单编号规则和业务文档再让模型通过MCP去订单系统查询。这样组合出来的系统才有真正的业务价值而不是一个只能聊天的问答机器人。这个理解对做企业内部AI助手非常重要。6.2 Agentic RAG从“一次检索”到“多步推理”传统RAG是“检索一次生成一次”比较机械。Agentic RAG则是让模型拥有更多决策权它可以判断当前信息是否足够不够就继续检索、改写问题、筛选chunk甚至同时调用多个检索源再综合答案。你可以把它看作把RAG链路交给一个Agent来编排。我在实践中最受益的一点是“历史用例检索与实例化适配”这个思路它其实很适合Agentic架构。比如售后场景里知识库存了大量历史故障处理用例上面提到一部分用户在使用过程中遇到了一种提示系统自动把历史相似案例召回然后结合当前设备的实际参数做适配最终生成的解决步骤比单纯匹配文档更符合现场情况。要做到这一点模型必须先判断“当前问题属于哪类故障”再决定检索哪些维度的资料。这是普通RAG很难完成的需要设计Agent的决策循环。6.3 多轮对话怎么设计才能不丢上下文RAG多轮对话的设计确实是个老难题。最简单的做法是每轮都重新检索然后只把当前问题和最近几轮对话摘要塞给模型。但如果用户问“那它的防水等级呢”缺少“它”的指代信息检索根本不知道在问什么。我的建议是两步走第一用LLM把历史对话改写成“独立问题”再做检索第二把传统RAG的“单轮检索”升级为“历史及相关实体检索”确保指代消解后的信息能正确命中知识库。举一个例子用户先问“A系列支持哪些通讯协议”系统回答后用户又问“那它的电源电压呢”。如果直接拿第二句去检索大概率搜不到。“电源电压”没问题但“它”没有定位到A系列。如果先做指代消解把问题改写为“A系列的电源电压是多少”再检索结果就准多了。这个改写步骤可以用一段独立的LLM调用实现成本不高但对多轮体验提升明显。6.4 把RAG做成“技能”而不是“整个应用”最后一个进阶思路和“skill怎么和rag结合起来”这个热搜词有关。在比较大的LLM应用里RAG不应该直接暴露给用户而是封装成一个可以被调用的“技能”。比如系统接收到用户问题后先做意图识别如果判断是“查资料”就调用RAG技能如果判断是“执行操作”就调用工作流技能。这样RAG可以和业务系统解耦后续增加新模型、新知识库只需要改技能内部实现不用动整个应用。我自己的下一步计划就是把这个本地私有RAG从“文档问答Demo”升级成可被业务系统调用的服务。具体包括增加用户权限隔离、接入历史会话管理、把检索日志和反馈数据收起来为后续继续优化做准备。这些内容我会在系列后续篇里慢慢展开第一篇先到这里。最后分享一个实际操作中的小技巧无论你用什么框架先准备一个“最小测试集”包含5到10个典型问题每次改动知识库或参数后统一跑一遍。没有测试集你会永远在“感觉效果好了一些”和“怎么又变差了”之间反复横跳而这种玄学式调优在RAG项目里是最消耗耐心的。用数据判断每次调整的效果才是把项目持续做下去的正确方式。