尧图网页设计 
聊RAG在企业落地这件事我这两年接触过不少团队从几十人的创业公司到几千人的集团都有。大家一开始的思路出奇一致买个大模型API把内部文档丢进去一个企业知识库马上搞定。结果呢要么回答得天花乱坠却全是编的要么稍微冷门一点的问题直接答不上来要么文档更新之后模型还在用旧知识。RAG检索增强生成就是在这一步被真正重视起来的。它不是某种新模型而是一套“先检索、再生成”的架构——让模型在回答之前先去你的知识库里找证据再基于这些证据组织语言。这和你平时工作先查资料再写邮件是同一个逻辑。这篇文章我从原理讲到企业落地再讲Mac上怎么搭一套能跑的原型最后把高频踩坑点整理成速查表适合正在评估技术方案的技术负责人也适合准备动手做知识库的开发者。1. 先搞懂RAG的原理它到底是怎么工作的1.1 RAG解决的核心问题幻觉和知识过期先说说为什么需要RAG。大语言模型本身是一个“纯参数化记忆系统”它的所有知识都固化在训练时的权重里。模型训练完就固定了之后发生的事它不知道训练数据里没有的领域细节它也只能靠概率“编”。这就是所谓的幻觉——不是模型故意骗你是它没有可靠信息来源时被迫自圆其说。RAG的思路是把知识从模型参数里“抽出来”放到外部可检索的存储里。模型生成时不再只凭自身记忆而是先从外部检索模块拿到相关的文本碎片再在提示词里把这些碎片作为参考材料提供。这一下子解决了两个最要命的问题知识可以随时更新。文档更新了重建索引就行不需要重新训练模型。答案可以被追溯。模型说“根据制度第X条”你可以直接定位到原文让幻觉在工程上变得可验证。这也是为什么RAG在企业场景里比微调更受欢迎——微调解决不了知识过期问题每次业务变化都要重新训练成本极高而RAG的代价只是维护一个可控的知识库。1.2 三阶段拆解索引、检索、生成一套标准RAG流程可以拆成三个明确阶段Indexing索引阶段文档进来后先做解析。PDF要转文本表格要识别结构扫描件还得过OCR。解析完成后按一定策略切分chunking因为直接整篇塞给模型一是超出上下文窗口二是检索粒度太粗找不到局部答案。切好的文本块经嵌入模型embedding model转成向量和原文一起存入向量数据库。这一步是“离线准备”。Retrieval检索阶段用户提问后把问题做同样的向量化然后在向量库里做相似度搜索一般是余弦相似度。拿到top-k个最相似的文本块后不少生产级方案还会加一步重排序rerank——用一个交叉编码器对候选结果细粒度打分把真正相关的排前面。这一步是“在线召回”。Generation生成阶段把检索到的文本块按格式拼进提示词模板附上原始问题一并交给大模型生成回答。提示词里通常会强制要求“仅基于以下参考资料回答不要使用先验知识”并标注引用编号。这一步是“组合输出”。三个阶段里最关键的认知是RAG的性能上限不取决于模型有多强而取决于检索能捞回多少有效信息。检索捞不回正确答案后面的模型再聪明也只能胡说。所以在方案上你要优先把检索精度做扎实再去考虑生成优化。2. 企业级RAG架构从demo到能扛住生产流量2.1 企业场景里RAG到底落在哪里企业级应用和个人的“问我的PDF”完全是两个量级的事。我对接过的真实场景大致分四类一是内部知识库问答。制度文档、技术规范、SOP或历史项目档案员工用自然语言查询。这类场景数据基本是有权限边界的答案要准确引用要可信。二是售前售后客服。产品资料、FAQ、维修手册作为知识源线上机器人做首轮问答。这类场景对响应延迟敏感还要考虑被问倒了之后如何无缝转人工。三是合规与审计辅助。合同条款、监管要求、历年报告合规人员用问答来快速定位风险点。数据高度敏感甚至要私有化部署。四是研发辅助。研发团队把内部组件文档、接口规范、历史故障记录做成知识库辅助编码和排障。这些场景共性很强多源异构数据、需要权限控制、需要和现有系统打通。这也是企业级和demo最大的区别——demo只需要一个启动脚本企业级需要一整套数据流水线和治理机制。2.2 架构分层一条完整的数据到答案流水线我习惯把企业级RAG架构分为五层数据接入层负责连接各类数据源内网盘、数据库、Wiki、SharePoint做增量同步和格式转换。这里看似不起眼实际最耗时——企业数据源永远比你想象中杂。索引处理层解析、清洗、切块、向量化。这块要重点关注切分策略和解析失败率。扫描版PDF、复杂表格、图片型文件都会在这一层暴露问题。存储层通常需要同时部署向量数据库和关系型/文档数据库。向量库存embedding和索引关系库存原文、元数据、版本信息和权限标签。检索与编排层混合检索关键词向量、rerank、多路召回融合、对话状态管理。这一层是企业自研的核心竞争力所在。应用集成层对外暴露API接SSO单点登录结果做权限过滤操作有审计日志再对接业务系统OA、客服工单、IM机器人。分层设计最大的好处是每一层可以独立替换。今天用的向量库不行换掉存储层就行嵌入模型升级了只需要重建索引。不需要动整个系统。2.3 和存量系统的集成别忽略身份权限这一关企业级RAG十有八九要接入已有的业务系统。很多团队用Java包括Java EE那套做后端RAG服务通常是Python生态的实践中最常见的做法是把RAG封装成一个独立的检索服务对外提供REST APIJava服务端用HTTP调用不追求语言层面的直接嵌入。封装成API时有一个原则检索服务不直接面对终端用户它只接收带有用户身份标识的请求权限校验必须回溯到统一身份体系。知识文档往往有密级和部门隔离不问出处地全量检索是最大的合规隐患。推荐的做法是在索引阶段就给每个文本块打上权限标签部门、密级、可见范围。检索阶段先按权限过滤候选集再执行相似度搜索。这样即使某个词命中了一条权限之外的文档它也不会进入候选集更不会进入大模型的参考上下文。日志方面至少记录谁在什么时间问了什么问题、系统用了哪些文档生成回答以及用户对回答质量的反馒反馈。3. RAG知识库和知识图谱到底选哪个3.1 两种知识组织方式的本质差异很多团队聊着聊着就发现RAG知识库和知识图谱KG好像干的是一件事——把企业知识和模型能力结合起来。但它俩不是替代关系甚至不是同一层的东西。RAG知识库特指基于向量检索的那套本质上是“无结构的相关文本召回”。它学的是语义相似度说“打卡规则”和“考勤制度”相近但不知道这两个概念之间的具体关联。它最适合的场景是答案藏在某段非结构化文本里你需要找到它。知识图谱属于“结构化表示”。它用实体和关系构建网络——公司是实体“成立于”是关系一个人是“公司员工”这个关系的一端。查询走的是图遍历或者SPARQL这类结构化查询语言回答的是“谁的上级是谁的上级”这种精确问题。现在更多的做法是RAGKG融合叫作GraphRAG或Ontology增强RAG。用知识图谱保存实体关系和结构稳定的事实类知识用向量检索覆盖非结构化文本。回答问题先查图谱拿精确事实再靠向量检索找延伸解释。二者互补各管一段。3.2 应用场景选型对照我整理了一个对照表可以按这个思路去判断自己的场景维度向量RAG知识库知识图谱方案融合方案数据类型非结构化文本为主结构化关系数据、元数据两者都要典型问题“报销流程里有哪些注意事项”“A部门和B部门之间的汇报关系”既问事实又问背景准确率瓶颈语义相似度不够精准建图质量严重依赖人工建模维护复杂度高建设成本相对低自动流程多高需要本体建模和专家参与最高可解释性中等靠引用原文强答案能演示实体链路强对大多数企业来说第一套方案一定是从向量RAG开始的因为它见效最快、门槛最低。只有当出现大量“多跳推理”类问题需要沿着关系链推导答案时再去考虑引入图谱层。不要一开始就想做一个完美的本体Ontology那是一个无底洞。3.3 一个避不开的问题知识库里能存图片吗这个问题被问得非常多。答案是能但要做好预期管理——不是“图片本身放进知识库就能被问答”而是要看图片里的信息以什么方式参与检索。有两条成熟路线 一条是图文混合检索用带视觉能力的模型比如CLIP类模型把图片编码成向量搜索时文本问题和图片向量做匹配。这种方式找的是“图里有什么”对场景类图片有效但对一张扫描的合同拍照页效果很差。 另一条是“先转文本再入库”用OCR把图片里的文字提取出来连同文件路径一起作为知识块存储。搜索命中这个知识块后答案是文字用户再从系统里打开原始图片确认。这条路线在工程上最稳定也是我目前更推荐的做法。如果图片里有非文字信息比如流程图的结构、产品外观差异那就需要接入多模态大模型把图片直接作为输入配合文本块获得更完整的答案。这里成本会上升要按需求来控制范围。4. 在Mac上搭建一套RAG知识库端到端操作实录4.1 工具链选型为什么我选了Ollama LangChain ChromaMac是很多开发者搭原型的第一环境。我这套方案刻意压低了配置门槛目的不是追求最强效果而是让你在30分钟内跑通全链路先看到流程长什么样。运行环境Ollama本地跑大模型不用注册API key不用联网等待对个人知识库完全够用。嵌入模型用Nomic Embed Text或BGE-M3都对中文支持友好体积适中Mac上甚至CPU推理也能接受。大模型Qwen2.5 7B或Llama 3.1 8B。个人场景7B级别的模型足够了内存16GB的机器能跑得动。编排框架LangChain生态最全教程和社区资源最多Debug时容易找到相似案例。向量库Chroma轻量开源支持持久化pip装完就能用适合原型验证。4.2 从零搭建步骤先确认电脑上有Homebrew和Python 3.10以上版本然后装Ollama并拉取模型brew install ollama ollama pull qwen2.5:7b ollama pull nomic-embed-text然后新建一个项目目录安装Python依赖mkdir rag-demo cd rag-demo python3 -m venv .venv source .venv/bin/activate pip install langchain langchain-community chromadb ollama建立一个ingest.py做文档入库存索引。这里以Markdown文档为例解析后按块切分向量化后写入Chromafrom 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 loader DirectoryLoader(./docs, glob**/*.md, loader_clsTextLoader) docs loader.load() splitter RecursiveCharacterTextSplitter(chunk_size512, chunk_overlap64) chunks splitter.split_documents(docs) embeddings OllamaEmbeddings(modelnomic-embed-text) db Chroma.from_documents(chunks, embeddings, persist_directory./chroma_db) print(findexed {len(chunks)} chunks)然后写query.py做问答检索from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma from langchain_community.chat_models import ChatOllama from langchain.chains import RetrievalQA embeddings OllamaEmbeddings(modelnomic-embed-text) db Chroma(persist_directory./chroma_db, embedding_functionembeddings) retriever db.as_retriever(search_typesimilarity, search_kwargs{k: 4}) llm ChatOllama(modelqwen2.5:7b) qa RetrievalQA.from_chain_type( llmllm, retrieverretriever, chain_typestuff, return_source_documentsTrue, ) answer qa.invoke(报销流程中需要填哪些关键信息) print(answer[result]) print(--- sources ---) for doc in answer[source_documents]: print(doc.metadata.get(source))检索参数里k值建议先从4起步明确了答案覆盖范围之后再调。chunk_size先用512看效果再改。这个流程跑通之后你再替换成企业数据源和更强的模型逻辑都不变。4.3 搭建过程中的两个关键细节第一个是切分参数别迷信默认值。Chroma和LangChain的默认配置更适合英文文档中文标点和句子长度特征不同建议把切分器改为按句号、问号、感叹号优先切分。我习惯自定义separators[\n\n, 。, , , \n, , ]让中文语义边界更完整。第二个是注意Ollama嵌入模型的维度一致性。向量化模型换掉之后旧库里的向量维度对不上检索就会直接报错。换模型必须重建索引没有第二条路。所以上线之前先确定主用的嵌入模型不要频繁切换。5. 常见问题与瓶颈排查实录5.1 高频问题速查表问题现象根因方向处理办法答案明显不对跟资料无关检索没召回相关块调大k值换混合检索加query改写回答引用了错误上下文切块边界把相关句子拆散调整切分策略增加重叠长度问得只要换个说法就答不上来嵌入模型对中文语料不敏感换用中文专项微调过的嵌入模型模型总爱自由发挥幻觉提示词约束不够或参考块太杂强制要求仅用参考文本无关块不上送文档更新了答案还是旧的索引未做增量更新建增量任务按文件修改时间重索引并发一高就卡顿向量检索或推理线程阻塞加缓存层检索和生成异步拆分扫描版PDF根本搜不到任何内容缺少OCR步骤先转文本再走流程保留原文供核对5.2 最典型的三个“坑”第一个坑是以为“检索不能空所以塞越多的文本块越好”。实验下来会发现上下文里塞了5个相关块答案质量是好的塞了8个前几个相关块被后几个弱相关块干扰生成质量反而下滑。因为大模型对长上下文的注意力会被无关信息稀释。不要贪多用rerank保证放进上下文的每个块都是高质量的。第二个坑是忘记评估指标。很多团队上线RAG之后只有感性判断——“答得还行”“有时候不太行”。没有量化指标优化方向全靠猜测。建议从这三个指标起步忠实度faithfulness——答案是否严格来自参考文档答案相关性answer relevancy——是否正面回答了问题召回准确率——标准答案是否在检索结果的前N条里。可以用RAGAS这类评估框架也可以人工抽样做小规模标注关键是要有持续评估的口径。第三个坑是权限过滤和检索顺序搞反了。如果先向量搜索再过滤权限已经在结果里“见过”了不该看的文档这在合规审计里是隐患。必须先把权限标签作为硬条件过滤再做相似度排序确保越权文档根本不会出现在候选集里。这不仅是实现细节实际上是合规底线。5.3 性能瓶颈与成本控制企业级系统一跑起来性能问题会立刻浮现。检索慢通常不是向量库的锅而是数据没做分区、没开索引或者并发查询绕过了批量接口。生成慢基本就是大模型或者GPU资源不够了解决思路是给高频问题做缓存完全相同的问法直接命中缓存不再走模型推理。更精细一点可以做语义缓存——相似度高于0.95的问题直接复用上次答案企业客服场景实测命中率能到三成以上。成本方面最容易失控的是嵌入模型频繁重算。文档库几万个文本块每换一次模型就是全量重跑一遍。建议把嵌入结果作为静态资源管理好每次重算之前问一句“真的需要吗”。另外召回候选集低于阈值的问题不要让大模型强行回答设计好“拒答”话术既保用户体验也省token。我个人在实际项目里最深的一个体会是RAG落地成败的七成不在生成阶段而在检索质量。你和模型反复斗嘴的那么多奇怪回答追到底都是上游没把材料找齐。先把索引、切分、权限、更新链路做扎实把评估口径定下来再谈怎么调提示词和选模型。这个顺序走过几轮之后你会比我更早摸到自己的那套方法论。 RAG企业落地全指南：原理、架构、Mac搭建与避坑实操
聊RAG在企业落地这件事我这两年接触过不少团队从几十人的创业公司到几千人的集团都有。大家一开始的思路出奇一致买个大模型API把内部文档丢进去一个企业知识库马上搞定。结果呢要么回答得天花乱坠却全是编的要么稍微冷门一点的问题直接答不上来要么文档更新之后模型还在用旧知识。RAG检索增强生成就是在这一步被真正重视起来的。它不是某种新模型而是一套“先检索、再生成”的架构——让模型在回答之前先去你的知识库里找证据再基于这些证据组织语言。这和你平时工作先查资料再写邮件是同一个逻辑。这篇文章我从原理讲到企业落地再讲Mac上怎么搭一套能跑的原型最后把高频踩坑点整理成速查表适合正在评估技术方案的技术负责人也适合准备动手做知识库的开发者。1. 先搞懂RAG的原理它到底是怎么工作的1.1 RAG解决的核心问题幻觉和知识过期先说说为什么需要RAG。大语言模型本身是一个“纯参数化记忆系统”它的所有知识都固化在训练时的权重里。模型训练完就固定了之后发生的事它不知道训练数据里没有的领域细节它也只能靠概率“编”。这就是所谓的幻觉——不是模型故意骗你是它没有可靠信息来源时被迫自圆其说。RAG的思路是把知识从模型参数里“抽出来”放到外部可检索的存储里。模型生成时不再只凭自身记忆而是先从外部检索模块拿到相关的文本碎片再在提示词里把这些碎片作为参考材料提供。这一下子解决了两个最要命的问题知识可以随时更新。文档更新了重建索引就行不需要重新训练模型。答案可以被追溯。模型说“根据制度第X条”你可以直接定位到原文让幻觉在工程上变得可验证。这也是为什么RAG在企业场景里比微调更受欢迎——微调解决不了知识过期问题每次业务变化都要重新训练成本极高而RAG的代价只是维护一个可控的知识库。1.2 三阶段拆解索引、检索、生成一套标准RAG流程可以拆成三个明确阶段Indexing索引阶段文档进来后先做解析。PDF要转文本表格要识别结构扫描件还得过OCR。解析完成后按一定策略切分chunking因为直接整篇塞给模型一是超出上下文窗口二是检索粒度太粗找不到局部答案。切好的文本块经嵌入模型embedding model转成向量和原文一起存入向量数据库。这一步是“离线准备”。Retrieval检索阶段用户提问后把问题做同样的向量化然后在向量库里做相似度搜索一般是余弦相似度。拿到top-k个最相似的文本块后不少生产级方案还会加一步重排序rerank——用一个交叉编码器对候选结果细粒度打分把真正相关的排前面。这一步是“在线召回”。Generation生成阶段把检索到的文本块按格式拼进提示词模板附上原始问题一并交给大模型生成回答。提示词里通常会强制要求“仅基于以下参考资料回答不要使用先验知识”并标注引用编号。这一步是“组合输出”。三个阶段里最关键的认知是RAG的性能上限不取决于模型有多强而取决于检索能捞回多少有效信息。检索捞不回正确答案后面的模型再聪明也只能胡说。所以在方案上你要优先把检索精度做扎实再去考虑生成优化。2. 企业级RAG架构从demo到能扛住生产流量2.1 企业场景里RAG到底落在哪里企业级应用和个人的“问我的PDF”完全是两个量级的事。我对接过的真实场景大致分四类一是内部知识库问答。制度文档、技术规范、SOP或历史项目档案员工用自然语言查询。这类场景数据基本是有权限边界的答案要准确引用要可信。二是售前售后客服。产品资料、FAQ、维修手册作为知识源线上机器人做首轮问答。这类场景对响应延迟敏感还要考虑被问倒了之后如何无缝转人工。三是合规与审计辅助。合同条款、监管要求、历年报告合规人员用问答来快速定位风险点。数据高度敏感甚至要私有化部署。四是研发辅助。研发团队把内部组件文档、接口规范、历史故障记录做成知识库辅助编码和排障。这些场景共性很强多源异构数据、需要权限控制、需要和现有系统打通。这也是企业级和demo最大的区别——demo只需要一个启动脚本企业级需要一整套数据流水线和治理机制。2.2 架构分层一条完整的数据到答案流水线我习惯把企业级RAG架构分为五层数据接入层负责连接各类数据源内网盘、数据库、Wiki、SharePoint做增量同步和格式转换。这里看似不起眼实际最耗时——企业数据源永远比你想象中杂。索引处理层解析、清洗、切块、向量化。这块要重点关注切分策略和解析失败率。扫描版PDF、复杂表格、图片型文件都会在这一层暴露问题。存储层通常需要同时部署向量数据库和关系型/文档数据库。向量库存embedding和索引关系库存原文、元数据、版本信息和权限标签。检索与编排层混合检索关键词向量、rerank、多路召回融合、对话状态管理。这一层是企业自研的核心竞争力所在。应用集成层对外暴露API接SSO单点登录结果做权限过滤操作有审计日志再对接业务系统OA、客服工单、IM机器人。分层设计最大的好处是每一层可以独立替换。今天用的向量库不行换掉存储层就行嵌入模型升级了只需要重建索引。不需要动整个系统。2.3 和存量系统的集成别忽略身份权限这一关企业级RAG十有八九要接入已有的业务系统。很多团队用Java包括Java EE那套做后端RAG服务通常是Python生态的实践中最常见的做法是把RAG封装成一个独立的检索服务对外提供REST APIJava服务端用HTTP调用不追求语言层面的直接嵌入。封装成API时有一个原则检索服务不直接面对终端用户它只接收带有用户身份标识的请求权限校验必须回溯到统一身份体系。知识文档往往有密级和部门隔离不问出处地全量检索是最大的合规隐患。推荐的做法是在索引阶段就给每个文本块打上权限标签部门、密级、可见范围。检索阶段先按权限过滤候选集再执行相似度搜索。这样即使某个词命中了一条权限之外的文档它也不会进入候选集更不会进入大模型的参考上下文。日志方面至少记录谁在什么时间问了什么问题、系统用了哪些文档生成回答以及用户对回答质量的反馒反馈。3. RAG知识库和知识图谱到底选哪个3.1 两种知识组织方式的本质差异很多团队聊着聊着就发现RAG知识库和知识图谱KG好像干的是一件事——把企业知识和模型能力结合起来。但它俩不是替代关系甚至不是同一层的东西。RAG知识库特指基于向量检索的那套本质上是“无结构的相关文本召回”。它学的是语义相似度说“打卡规则”和“考勤制度”相近但不知道这两个概念之间的具体关联。它最适合的场景是答案藏在某段非结构化文本里你需要找到它。知识图谱属于“结构化表示”。它用实体和关系构建网络——公司是实体“成立于”是关系一个人是“公司员工”这个关系的一端。查询走的是图遍历或者SPARQL这类结构化查询语言回答的是“谁的上级是谁的上级”这种精确问题。现在更多的做法是RAGKG融合叫作GraphRAG或Ontology增强RAG。用知识图谱保存实体关系和结构稳定的事实类知识用向量检索覆盖非结构化文本。回答问题先查图谱拿精确事实再靠向量检索找延伸解释。二者互补各管一段。3.2 应用场景选型对照我整理了一个对照表可以按这个思路去判断自己的场景维度向量RAG知识库知识图谱方案融合方案数据类型非结构化文本为主结构化关系数据、元数据两者都要典型问题“报销流程里有哪些注意事项”“A部门和B部门之间的汇报关系”既问事实又问背景准确率瓶颈语义相似度不够精准建图质量严重依赖人工建模维护复杂度高建设成本相对低自动流程多高需要本体建模和专家参与最高可解释性中等靠引用原文强答案能演示实体链路强对大多数企业来说第一套方案一定是从向量RAG开始的因为它见效最快、门槛最低。只有当出现大量“多跳推理”类问题需要沿着关系链推导答案时再去考虑引入图谱层。不要一开始就想做一个完美的本体Ontology那是一个无底洞。3.3 一个避不开的问题知识库里能存图片吗这个问题被问得非常多。答案是能但要做好预期管理——不是“图片本身放进知识库就能被问答”而是要看图片里的信息以什么方式参与检索。有两条成熟路线 一条是图文混合检索用带视觉能力的模型比如CLIP类模型把图片编码成向量搜索时文本问题和图片向量做匹配。这种方式找的是“图里有什么”对场景类图片有效但对一张扫描的合同拍照页效果很差。 另一条是“先转文本再入库”用OCR把图片里的文字提取出来连同文件路径一起作为知识块存储。搜索命中这个知识块后答案是文字用户再从系统里打开原始图片确认。这条路线在工程上最稳定也是我目前更推荐的做法。如果图片里有非文字信息比如流程图的结构、产品外观差异那就需要接入多模态大模型把图片直接作为输入配合文本块获得更完整的答案。这里成本会上升要按需求来控制范围。4. 在Mac上搭建一套RAG知识库端到端操作实录4.1 工具链选型为什么我选了Ollama LangChain ChromaMac是很多开发者搭原型的第一环境。我这套方案刻意压低了配置门槛目的不是追求最强效果而是让你在30分钟内跑通全链路先看到流程长什么样。运行环境Ollama本地跑大模型不用注册API key不用联网等待对个人知识库完全够用。嵌入模型用Nomic Embed Text或BGE-M3都对中文支持友好体积适中Mac上甚至CPU推理也能接受。大模型Qwen2.5 7B或Llama 3.1 8B。个人场景7B级别的模型足够了内存16GB的机器能跑得动。编排框架LangChain生态最全教程和社区资源最多Debug时容易找到相似案例。向量库Chroma轻量开源支持持久化pip装完就能用适合原型验证。4.2 从零搭建步骤先确认电脑上有Homebrew和Python 3.10以上版本然后装Ollama并拉取模型brew install ollama ollama pull qwen2.5:7b ollama pull nomic-embed-text然后新建一个项目目录安装Python依赖mkdir rag-demo cd rag-demo python3 -m venv .venv source .venv/bin/activate pip install langchain langchain-community chromadb ollama建立一个ingest.py做文档入库存索引。这里以Markdown文档为例解析后按块切分向量化后写入Chromafrom 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 loader DirectoryLoader(./docs, glob**/*.md, loader_clsTextLoader) docs loader.load() splitter RecursiveCharacterTextSplitter(chunk_size512, chunk_overlap64) chunks splitter.split_documents(docs) embeddings OllamaEmbeddings(modelnomic-embed-text) db Chroma.from_documents(chunks, embeddings, persist_directory./chroma_db) print(findexed {len(chunks)} chunks)然后写query.py做问答检索from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma from langchain_community.chat_models import ChatOllama from langchain.chains import RetrievalQA embeddings OllamaEmbeddings(modelnomic-embed-text) db Chroma(persist_directory./chroma_db, embedding_functionembeddings) retriever db.as_retriever(search_typesimilarity, search_kwargs{k: 4}) llm ChatOllama(modelqwen2.5:7b) qa RetrievalQA.from_chain_type( llmllm, retrieverretriever, chain_typestuff, return_source_documentsTrue, ) answer qa.invoke(报销流程中需要填哪些关键信息) print(answer[result]) print(--- sources ---) for doc in answer[source_documents]: print(doc.metadata.get(source))检索参数里k值建议先从4起步明确了答案覆盖范围之后再调。chunk_size先用512看效果再改。这个流程跑通之后你再替换成企业数据源和更强的模型逻辑都不变。4.3 搭建过程中的两个关键细节第一个是切分参数别迷信默认值。Chroma和LangChain的默认配置更适合英文文档中文标点和句子长度特征不同建议把切分器改为按句号、问号、感叹号优先切分。我习惯自定义separators[\n\n, 。, , , \n, , ]让中文语义边界更完整。第二个是注意Ollama嵌入模型的维度一致性。向量化模型换掉之后旧库里的向量维度对不上检索就会直接报错。换模型必须重建索引没有第二条路。所以上线之前先确定主用的嵌入模型不要频繁切换。5. 常见问题与瓶颈排查实录5.1 高频问题速查表问题现象根因方向处理办法答案明显不对跟资料无关检索没召回相关块调大k值换混合检索加query改写回答引用了错误上下文切块边界把相关句子拆散调整切分策略增加重叠长度问得只要换个说法就答不上来嵌入模型对中文语料不敏感换用中文专项微调过的嵌入模型模型总爱自由发挥幻觉提示词约束不够或参考块太杂强制要求仅用参考文本无关块不上送文档更新了答案还是旧的索引未做增量更新建增量任务按文件修改时间重索引并发一高就卡顿向量检索或推理线程阻塞加缓存层检索和生成异步拆分扫描版PDF根本搜不到任何内容缺少OCR步骤先转文本再走流程保留原文供核对5.2 最典型的三个“坑”第一个坑是以为“检索不能空所以塞越多的文本块越好”。实验下来会发现上下文里塞了5个相关块答案质量是好的塞了8个前几个相关块被后几个弱相关块干扰生成质量反而下滑。因为大模型对长上下文的注意力会被无关信息稀释。不要贪多用rerank保证放进上下文的每个块都是高质量的。第二个坑是忘记评估指标。很多团队上线RAG之后只有感性判断——“答得还行”“有时候不太行”。没有量化指标优化方向全靠猜测。建议从这三个指标起步忠实度faithfulness——答案是否严格来自参考文档答案相关性answer relevancy——是否正面回答了问题召回准确率——标准答案是否在检索结果的前N条里。可以用RAGAS这类评估框架也可以人工抽样做小规模标注关键是要有持续评估的口径。第三个坑是权限过滤和检索顺序搞反了。如果先向量搜索再过滤权限已经在结果里“见过”了不该看的文档这在合规审计里是隐患。必须先把权限标签作为硬条件过滤再做相似度排序确保越权文档根本不会出现在候选集里。这不仅是实现细节实际上是合规底线。5.3 性能瓶颈与成本控制企业级系统一跑起来性能问题会立刻浮现。检索慢通常不是向量库的锅而是数据没做分区、没开索引或者并发查询绕过了批量接口。生成慢基本就是大模型或者GPU资源不够了解决思路是给高频问题做缓存完全相同的问法直接命中缓存不再走模型推理。更精细一点可以做语义缓存——相似度高于0.95的问题直接复用上次答案企业客服场景实测命中率能到三成以上。成本方面最容易失控的是嵌入模型频繁重算。文档库几万个文本块每换一次模型就是全量重跑一遍。建议把嵌入结果作为静态资源管理好每次重算之前问一句“真的需要吗”。另外召回候选集低于阈值的问题不要让大模型强行回答设计好“拒答”话术既保用户体验也省token。我个人在实际项目里最深的一个体会是RAG落地成败的七成不在生成阶段而在检索质量。你和模型反复斗嘴的那么多奇怪回答追到底都是上游没把材料找齐。先把索引、切分、权限、更新链路做扎实把评估口径定下来再谈怎么调提示词和选模型。这个顺序走过几轮之后你会比我更早摸到自己的那套方法论。