做客服机器人最怕什么？不是用户问不到点上，是机器人一本正经地胡说八道。用户问“退货退款几天到账”，它敢答“1-3个自然日”；用户追问“为什么我的订单状态不更新”，它开始编“系统正在升级维护”。这种幻觉问题在大模型时代被无限放大了——模型确实能说会道，但它没有“记忆”，没有“查证”能力，所有回答都是概率生成的结果，而不是事实检索的结果。
RAG（Retrieval-Augmented Generation，检索增强生成）就是冲着这个问题来的。它的思路特别朴素：模型不知道答案没关系，先从一个知识库里把相关资料检索出来，把资料塞进上下文，再让模型基于资料作答。这样回答就有了出处，有了引用，胡说八道的空间被死死按住。这篇文章我会把RAG的原理拆开讲清楚，再给出一套能落地的工程实现方案，包括技术选型、文档拆解、检索链路、Mac本地部署等完整实操内容。适合正在做大模型应用、客服系统、知识库问答的工程师，也适合想搞懂RAG到底是怎么回事的产品和技术负责人。
1. 客服机器人为什么总会“一本正经地胡说八道”
1.1 幻觉问题的根源：大模型在“复述”而不是“查证”
大模型的本质是一个词元预测器。给定前文，它根据海量语料中学到的概率分布，预测下一个最可能出现的词。这意味着它生成的内容是“统计最合理”的，而不是“事实正确”的。客服场景中这个缺陷暴露得特别明显：用户会问非常具体的业务问题，比如“保价服务覆盖预售商品吗”“赠品漏发可以单独补寄吗”，这些问题在训练语料里大概率没有标准答案，模型只能靠相关性联想硬凑。
我举个实际例子。某个电商客服机器人在没有接入知识库之前，用户问“会员日当天退货，运费险还生效吗”，模型给出的回答是“会员日退货同样享受运费险保障，具体以页面显示为准”。这句话听起来很稳妥，但实际上是错的——这个平台的运费险规则里明确写着“会员日订单取消或退货，系统自动赠送的运费险不生效”。模型不知道这个规则，但它知道“会员日”“运费险”这两个词经常一起出现，于是把它们缝合成了一句看似合理的话。
这就是幻觉的本质：模型不是查到了答案再回答你，而是觉得“应该这么答”所以这么答。人在面对不确定的问题时，会说“我不确定，我去查一下”；大模型不会，它会直接编一个听起来很自信的答案。这个特性在闲聊场景是优点，在客服场景是灾难。
1.2 为什么不靠微调和提示词硬压幻觉
有人会说，那我把业务规则整理出来，微调一个模型不就行了？或者我在提示词里写“只能根据已知信息回答，不知道就说不确定”不就行了？
这两个方案我都试过，效果都不理想。
微调的成本和收益完全不成正比。业务规则是动态变化的，促销活动每个月都在变，运费政策跟着平台规则走，你不可能每改一条规则就重新训练一次模型。微调解决的是模型的“行为能力”问题，比如让模型学会某种语气、某种输出格式，而不是解决“事实知识”问题。想让微调记住大量具体业务条款，你需要准备几千上万条高质量问答对，训练完还要重新评测、重新上线，这个周期在业务方看来是不可接受的。
提示词约束更是靠不住。你写“不知道就回答不知道”，模型确实会在一些简单问题上说不知道，但遇到它“觉得”自己知道的问题，它依然会自信地给出错误答案。因为模型没有真正的“自我认知”，它不知道“我知道什么”，它只知道“我能生成什么”。提示词只能压低幻觉概率，不能消除幻觉，尤其当业务规则的表述在公开语料中有相似但不完全相同的文本时，模型几乎必然会被带偏。
1.3 为什么是 RAG：检索增强的本质是把“记忆”换成“查资料”
RAG的核心理念可以用一句话概括：不要逼模型背答案，让它学会查资料。
类比一下人类的工作方式。一个优秀的客服并不是把几千页规则手册全背下来，而是遇到问题能快速定位到手册里对应章节，找到原文再答复。RAG就是把这件事工程化了：先有一个知识库，用户提问后系统先去知识库检索相关片段，把检索到的片段和问题一起交给大模型，模型的任务从“回忆答案”变成了“阅读理解并转述”。
这个转换带来的变化是本质性的。第一，回答有了来源，每句话都能对应到知识库中的某个段落，出了错可以追责、可以修正；第二，知识可以实时更新，运营改一条规则，只需要更新知识库，不需要重新训练模型；第三，模型被限制在给定上下文中作答，它“自由发挥”的空间被极大压缩。所以RAG不是大模型的竞品，而是大模型走向严肃应用的关键配套设施。这也是为什么这一年多来，所有做知识库问答、企业搜索、智能客服的团队，最后都收敛到RAG这条技术路线上来。
2. RAG 的核心原理：一次检索、一次生成、一个闭环
2.1 RAG 的三段式架构
RAG标准流程分成三个阶段：检索（Retrieval）、增强（Augmented）、生成（Generation）。听起来高级，拆开看每一段都很好理解。
检索阶段的任务是：给定用户问题，从知识库中找出最相关的若干条文本片段。这个阶段最核心的指标是召回率——真正包含答案的片段有没有被捞出来。如果检索阶段就把答案片段漏掉了，后面模型再怎么聪明也白搭。
增强阶段的任务是：把检索到的片段做重排、去重、裁剪、拼接，组装成一份适合大模型阅读的上下文。这个过程决定了喂给模型的“资料”质量。原始检索结果往往是按相关度分数排列的，但分数最高不一定最有用，片段之间可能信息冗余，也可能断在句子中间，这些问题都要在这一阶段处理。
生成阶段的任务是：把“用户问题+增强后的上下文”打包进提示词，让大模型基于上下文生成最终回复。这个阶段的关键是提示词约束和输出解析。你要告诉模型“只能使用上下文中提供的信息”“如果上下文中没有答案，直接回答不知道”“引用答案时标注来源ID”，这些约束能把幻觉率进一步压低。
三个阶段的工程优先级非常明确：检索决定上限，增强决定质量，生成决定体验。我见过很多团队把精力全花在调提示词上，结果检索召回一塌糊涂，提示词再花哨也没用。做RAG的第一步永远是先把检索做好。
2.2 检索引擎的选型逻辑：稀疏检索与向量检索的互补
检索是整个RAG系统的命门。当前主流方案是混合检索，也就是把两类检索方式叠加使用。
第一类叫稀疏检索，典型代表是BM25。它的原理建立在词频和逆文档频率之上：一个词在当前文档中出现得越多，同时在所有文档中出现得越少，这个文档就越相关。BM25的优点是精确、可解释、不需要任何模型，速度快到可以忽略不计，特别适合匹配专有名词、型号、政策编号这类关键词。缺点也很明显：它只能做字面匹配，用户问“商品坏了怎么办”，知识库里写的是“质量问题售后流程”，两个句子一个共同词都没有，BM25就抓瞎了。
第二类叫密集检索，也就是向量检索。先把文本用嵌入模型转成向量，再用向量相似度找最近的片段。它的核心优势是语义匹配：即使字面完全不同，只要语义相近，向量距离就近。用户问“东西坏了”，嵌入模型能把这句话和“质量问题售后处理”映射到相近的向量空间。
但向量检索不是银弹。它依赖嵌入模型的质量，对领域专有名词不敏感，而且返回结果的“可解释性”弱——你很难解释为什么这两个文本向量距离近。所以工程上最稳的做法是BM25和向量检索并行跑，取两者的结果做融合排序。一个管精确匹配，一个管语义召回，互补性很强。我在实际项目中观察下来，混合检索相比单用向量检索，召回准确率通常能提升10到15个百分点，而且对长尾问题的稳定性好很多。
2.3 增强阶段的重排序与上下文拼装
检索返回的候选片段通常有几十条，但大模型上下文窗口再大，塞进去的信息也不是越多越好。信息过多会稀释注意力，降低回答质量，还会拖慢推理速度、推高成本。所以增强阶段要做两件事：压缩和排序。
压缩是把候选片段裁剪到合理长度，去掉重复内容和无关干扰。排序则是通过重排序模型（Reranker）把最相关的片段顶到前面。重排序模型和嵌入模型的区别在于：嵌入模型是“双塔”结构，问题和文档分别编码再算相似度，速度快但精度粗；重排序模型是“交叉编码”结构，问题和文档拼在一起过一遍完整模型，精度高但速度慢。所以工程上通常先用嵌入模型做粗召回（从全库召回Top 50），再用重排序模型做精排（从50条里选Top 5）。
上下文拼装也很有讲究。我的经验是把相关度最高的片段放在上下文开头和结尾，这两个位置是模型注意力最强的区域。同时要给每个片段打上编号，在提示词里明确要求“引用内容时必须标注来源编号”，这样回答就能追溯，出了问题能快速定位是哪条知识不正确。
2.4 生成阶段的约束策略与可解释性设计
生成阶段的核心是提示词模板。同一个RAG系统，提示词写得好不好，幻觉率能差一倍以上。我总结了一份比较实用的客服场景提示词结构，包含四个部分：角色设定、任务说明、硬性约束、上下文资料。
角色设定要简短，比如“你是一名电商平台在线客服”；任务说明要明确输出格式，比如“先给出结论，再提供依据”；硬性约束是最关键的部分，必须写清楚“只能使用提供的资料回答问题”“资料中没有答案时，必须回答‘这个情况需要转人工核实’”“不得编造任何规则和数字”；上下文资料区用清晰的标记包裹，避免模型把资料内容和对话历史混淆。
可解释性设计被很多人忽略。实际客服场景里，业务运营人员需要知道“机器人为什么这么回答”，没有来源标注的回答对他们来说等于不可信。所以系统里至少要返回三个信息：最终答案、引用的知识片段、相关度分数。前端展示时可以把引用折叠到详情里，不影响用户阅读体验，但后台一定要能看到完整链路。
3. 工程实现：从零搭一个能落地的 RAG 客服机器人
3.1 技术选型与框架对比：别盲目上框架
现在做RAG的技术选型，绕不开LangChain和LlamaIndex这类框架。我的建议是：中小型项目可以直接用框架快速搭建，但生产级客服系统不要过度依赖框架，核心检索链路自己写更可控。
框架的优势是封装完整，Loader、Splitter、VectorStore、QA链都现成的，跑个Demo半小时就能起来。但框架的问题也出在封装上：出了问题你很难定位是哪个环节出的错，而且框架版本迭代频繁，接口变动大，升级一次要跟着改一遍代码。我实际做的项目里，向量检索、重排序、上下文拼装、提示词管理都是自己实现的，只用了框架的文档解析和向量库客户端。这样每一环都清楚，排查问题时心里有底。
具体选型上，嵌入模型我推荐bge系列，中文效果好而且开源可控，不像闭源嵌入API那样存在数据合规风险；向量数据库小规模用Chroma或者FAISS，数据量上百万以后再上Milvus或Qdrant；大模型接开源可以用Qwen、DeepSeek，接闭源可以用几家主流商用API，按成本和效果权衡。还有个容易被忽略的点：客服系统通常有敏感数据合规要求，如果数据不能出内网，大模型和嵌入模型都得部署私有化版本，选型时一定要提前确认这一点。
3.2 文档拆解：比算法更影响效果的一步
说句得罪人的话：大部分RAG项目效果差，不是算法不行，是文档处理没做好。知识库里放着一堆PDF、Word、Excel表格，你直接暴力切块往向量库里塞，检索出来的全是支离破碎的文本，效果能好才怪。
文档拆解要做好三件事。
第一是格式解析。PDF要区分扫描版和文字版，扫描版要做OCR；表格要单独抽取，转成有结构的Markdown表格；页眉页脚、页码、水印这些噪声要清洗掉。我见过一个项目把每页的“第X页共Y页”都切成了知识片段，检索结果里全是页码，气得业务方直拍桌子。
第二是分块策略。分块大小直接影响检索效果。块太大，一个块里包含多个主题，检索时返回了太多无关信息；块太小，一句话被切成两半，语义完整性被破坏。我的经验值是：普通客服文档按300到500字分块，设置50到100字的交叠，保证语义连贯性。分块时尽量按章节、标题、段落边界切，不要按固定字符数硬切。
第三是清洗与标注。每个知识片段要保留来源文档名、章节路径、更新时间、所属业务线，这些元数据在后续做权限过滤、时效性排序、错误追溯时都至关重要。写代码时可以把这些字段存在向量库的metadata里，检索时带条件过滤。
3.3 索引构建与向量化：离线还是在线
索引构建是RAG系统的数据管道。推荐做法是离线构建、增量更新。客服知识库的特点是单条知识不长但总量大，每天有少量更新。构建流程包括：定时扫描知识库文件变更、新文件解析、分块、向量化、写入向量库。这个过程用消息队列串起来跑离线任务，不要塞进在线接口里。
向量化环节有两个参数要调：嵌入模型和向量维度。不同嵌入模型的维度差异很大，比如bge-small是512维，bge-large是1024维，维度越高理论上表达力越强但存储和计算成本也越高。我的建议是从小模型开始，效果不够再换大模型。很多团队一上来就换1024维的大模型，结果检索效果没提升多少，向量库查询延迟增加了两倍，得不偿失。
增量更新要处理一个问题：知识文档改了，旧向量怎么办。我的做法是给每个知识文档分配唯一ID，更新时先删除旧ID对应的全部向量，再写入新向量。注意向量库的删除操作和写入操作要在一个事务里，否则会出现新旧数据同时存在的窗口期，导致用户检索到过期内容。
3.4 检索链路与问答接口：一次完整请求的旅程
把整条链路串起来，一次客服问答请求的处理流程是这样的：
用户提问进来，先做问题预处理——去除语气词、识别意图、提取关键实体；然后并行发起BM25检索和向量检索，分别取Top 50候选；融合排序后取Top 10，送入重排序模型精排，选出Top 5；从向量库metadata里拉出这5条片段的原文和元信息，拼接成上下文；把“用户问题+上下文+系统提示词”发给大模型生成回答；最后做输出校验——检查回答中是否有引用标注、是否包含“我不知道”这类拒绝词、是否超出上下文范围，全部通过才返回给用户。
这里有个细节值得强调：问题预处理往往决定了检索质量。用户提问口语化严重，比如“我昨天买的鞋今天降价了能退差价吗”，直接拿这句话去检索，效果一般。我是先让一个大模型做问题改写，把口语转成标准查询语句，比如改成“保价政策 降价 退差价 规则”，再去做检索。实测下来，这个问题改写环节能提升5到8个百分点的召回准确率，性价比极高。
此外，客服场景还有一个特殊设计——多轮对话。用户问“那退货运费谁出”，如果不结合上文“我昨天买的鞋”，这句根本无法检索。所以RAG客服系统必须维护一个会话上下文窗口，在检索前先做指代消解，把“那”“这”“它”替换成具体的实体，再构造检索请求。这部分逻辑我在常见问题排查里还会细说。
4. 知识库的形态与边界：别让 RAG 干它干不了的事
4.1 RAG 知识库能存图片吗
对这个高频问题，先给结论：RAG知识库可以关联图片，但直接把图片作为主检索对象是不推荐的。RAG的检索链路本质是文本语义匹配，图片无法直接参与BM25或文本向量相似度计算。你往向量库塞一张纯图片，它只能通过图片的附属信息——文件名、OCR文字、ALT描述——被检索到，没有这些文本信息，它就是一个“看得见但搜不到”的孤儿数据。
图片在RAG里正确用法是作为“答案的补充材料”。比如用户问“怎么申请运费险理赔”，知识库里对应文本片段写明了步骤，同时附带一张理赔入口截图。实现时把截图上传到对象存储，在知识片段的metadata里加一个image_url字段，生成回答时让模型在合适位置插入图片引用。这样用户既拿到了文字步骤，又看到了操作界面，体验提升一个档次。
真正需要“以图搜图”的场景，比如用户拍一张商品损坏照片让客服判断是否符合退换货标准，那属于多模态检索的范畴。实现方案是给图片抽特征向量建独立的多模态向量库，走CLIP这类图文对齐模型，这是另一套工程体系，不要混进RAG链路里做。
4.2 RAG、知识图谱和结构化知识库到底怎么分工
热词里经常看到“KG知识库”“RAG知识库”“结构化知识库”，很多人容易混为一谈，实际上它们解决的完全不同。
RAG知识库本质是“非结构化文档集合”，知识以自然语言文本形式存在，适合处理FAQ、操作手册、政策条款这类内容。优势是构建成本低，直接扔文档就行；劣势是理解不了复杂关系和规则逻辑。
知识图谱知识库把知识表示成“实体—关系—实体”的三元组网络，比如“运费险——覆盖范围——预售商品”“预售商品——排除项——虚拟商品”。它的优势是能回答多跳推理问题，比如“买了预售商品又用了优惠券，退款时优惠券退不退”，这种问题需要在图谱里做多步关系回溯；劣势是构建成本极高，需要人工定义本体和关系，维护起来很重。
结构化知识库则是传统的表格和数据库，存的是字段和记录，比如商品表、订单表、物流表。这类知识适合做精确查询，用户问“订单DS20240301001现在什么状态”，直接查数据库返回即可，不需要RAG，也不需要图谱。
客服系统的正确做法是对三者做组合：政策条款类走RAG，实体关系类走知识图谱，订单状态类走结构化接口。我给一个粗略的分流规则：问题中如果包含订单号、手机号这类精确标识，优先走结构化查询；问题涉及多实体关系推理，走图谱；剩下的开放文本类问题，走RAG。三者之上再挂一层路由模型做意图识别，把请求分发给正确的引擎。
4.3 ontology 在客服场景里的落地价值
知识图谱靠人工定义概念体系非常累，ontology（本体）就是来解决这个问题的。ontology定义了一个领域内的核心概念、概念的属性、以及概念之间的关系，相当于给图谱画了一张“设计蓝图”。比如客服领域里，“售后期”和“订单状态”是两个概念，它们之间存在“约束”关系——某个售后期内订单才能申请售后。把这个关系在ontology里定义清楚，图谱才有办法做推理，而不是光存一堆脱节的节点。
对一个成熟客服系统来说，Ontology的作用不只是服务图谱，它也能反哺RAG。举个例子：用户问“耳机坏了能换吗”，如果你有一个简单的商品类目本体，知道“耳机属于电子消费品”“电子消费品适用七天无理由退换规则”，就能在检索前做一个概念泛化——把“耳机”泛化成“电子消费品”，再去知识库里检索“电子消费品退换规则”，召回率会明显提升。这就是所谓Ontology RAG的思路：用本体知识增强检索召回。
5. Mac 上搭建本地 RAG 知识库的完整流程
5.1 环境准备与模型选择
很多人在Mac上搭RAG是因为手里有本地文档，不想传到云端处理。这个诉求很现实，尤其涉及企业内部资料的时候。Mac本地搭RAG的硬件条件是：M系列芯片至少16G内存，Intel芯片建议32G以上，毕竟要同时跑嵌入模型和大模型。
模型选择上，Mac的Metal Performance Shaders可以给部分模型做GPU加速。我的推荐组合是：嵌入模型用bge-m3量化版，跑在CPU上速度也够用，因为嵌入是短文本编码，计算量不大；本地大模型用Ollama跑Qwen系列，几行命令就能下载启动，模型量化版本内存占用控制在8G以内。如果只想体验完整链路不想装太多东西，也可以直接用OpenAI的API做生成端，本地只跑检索。
5.2 本地文本拆解工具选型
热词里“本地RAG文本拆解工具”，我实测过几款，最省心的是这几类组合。
PDF解析优先用PyMuPDF，纯Python库，文字版PDF解析精度高，支持按坐标抽取文本块，配合正则清洗很容易拿到干净的章节结构。扫描版PDF要接OCR，Mac上最快的是macOS自带的Vision框架，通过PyObjC调用，识别中文准确率不错，完全离线。
Word和Markdown文档直接走python-docx和markdown库，解析成本最低。Excel表格建议转成Markdown表格后再进知识库，因为大模型读Markdown表格的能力远强于读原始Excel格式。网页类型的内容可以用Readability算法提取正文，Lib2Reader这个库就干这个事的，能过滤掉导航栏、广告等噪声。
还有一类被忽视的文本——“短文案”，比如公告、群聊记录、工单描述，这类文本没有标题结构，直接按窗口滑切就行，但要注意清洗掉@符号、链接、重复的祝福语，否则碎片进库后全是垃圾。
5.3 启动一条本地 RAG 服务的实操步骤
我用最精简的方式在Mac上搭过一套本地RAG，完整步骤如下。
第一步，安装依赖。用conda建一个干净环境，Python 3.10以上，装四个核心库：langchain的文档处理部分、chromadb、sentence-transformers、ollama的Python客户端。不需要装全套LangChain，用哪个装哪个。
第二步，启动Ollama并拉模型。命令行里执行：
ollama pull qwen2.5:7b ollama serve这一步会下载大模型并启动本地推理服务，默认端口11434。
第三步，写嵌入和入库脚本。用sentence-transformers加载bge-m3模型，把分块后的文本转成向量，写入Chroma集合。Chroma有一个很贴心的能力——metadata过滤，我把每条知识的来源文件名、章节、更新时间都放进去，后面检索时可以做条件筛选。
第四步，实现检索接口。查询时同时跑两个检索器：一个用Chroma自带的向量检索，一个用rank_bm25库做关键词检索，两者结果做简单加权融合。我实测下来权重设为向量0.7、关键词0.3比较稳定，但这个值要看你的文档类型调整，如果文档里规范术语多，关键词权重可以提到0.4。
第五步，对接生成端。把检索结果拼进提示词，调用Ollama的chat接口，设置较低的温度参数，比如temperature=0.1，让输出更稳定。前后端串起来之后，整个链路在M1 Mac上跑一次完整问答大约耗时7到9秒，检索占1秒以内，生成占大部分时间。如果嫌慢可以在Ollama里换更小的量化模型，或者用7b模型的更小量化版本。
这套方案的工程化程度足够用来做内部知识库和产品Demo，但要说承受生产级并发，那还得上服务器集群，Mac本机更适合做原型验证和离线处理。
6. 常见问题与排查实录：那些让我熬夜的坑
6.1 检索效果差的经典原因
“检索结果不相关”是所有RAG项目的第一大坑，我排查过太多次了。总结下来最典型的几个原因。
文档解析不清楚导致分块内容残缺。PDF解析出来一段文字混着表格碎片，又带着页眉页码，检索时命中的全是这些脏内容。这种情况优先处理解析层，不要急着调检索参数。
分块策略不合理。有些文档是条款型，每条独立成意；有些是叙述型，上下文强依赖。同一套分块参数不能套所有文档，需要按文档类型分开配置。我在系统里给“条款类”设300字块、给“说明类”设500字块，各有交叠。
检索的候选集太小。默认取Top K可能漏掉正确答案，尤其当答案分布比较分散时。我把粗召回Top K从20提到50以后，重排后的命中率明显好转。这个方法简单有效，代价只是重排序模型多算了30条样本，对延迟影响很小。
6.2 回答幻觉依旧存在的隐蔽原因
有些项目检索没问题，但生成结果仍然胡说八道。这种情况CMC概率出在提示词约束不到位。我见过最典型的错误是：把用户历史对话和检索到的知识片段一锅炖塞进上下文，模型分不清哪部分是资料、哪部分是历史消息，就会“借用”历史消息里的错误信息生成答案。解决方法是把上下文分区明确标注，用XML标签包裹，并在提示词里强调“只使用RETRIEVED_CONTENT标签内的内容作为事实依据”。
另一个隐蔽原因是知识库本身有矛盾。两篇文档写两条冲突规则，模型都检索到了，选了一条过时的生成回答。这个问题靠提示词解决不了，要在数据治理层面解决：在metadata里存每条知识的生效时间，检索时过滤掉过期版本，并按版本时间排序。
还有一个容易被忽略的点：嵌入模型更新后，向量库还是旧模型生成的向量。新旧向量空间不一致，检索质量会莫名其妙下降。嵌入模型升级后必须重建全部索引，这点务必记住。
6.3 工程性能与成本控制
RAG系统跑起来以后，性能瓶颈通常出现在三个地方：重排序模型、大模型生成、向量库查询。
重排序模型延迟一般在几十到几百毫秒，在完整链路里占比不大，但并发量上来以后容易把服务拖垮。我的优化手段是加一层缓存：同一问题改写后的标准查询结果缓存10分钟，覆盖短时间内的重复咨询，命中率大概有15%到20%，能实打实减掉一部分重排序压力。
大模型生成的成本是大头。客服场景里很多回答其实很短，“是的，支持七天无理由退换货”这种答案成本很低，但有些开放问题需要长回答。我按业务场景分段计费：规则问答走小模型，复杂推理走大模型。实测下来整体成本能降30%到40%，效果没有明显退化。
向量库查询的问题在数据量上涨后才会显现。上百万向量以后，暴力检索不可行，必须建HNSW索引。这个参数有个三角权衡：内存占用、召回精度、查询延迟。我把M值设为64、efConstruction设为200、查询时efSearch设为128，在10万到100万级别的向量规模下，延迟能控制在50毫秒以内。再往上量级，就该考虑分布式方案了。
最后再说一个运维层面的坑：知识库必须做权限管控。客服系统经常对接内部文档，直接全量入库有合规风险。我的方案是在检索阶段加metadata过滤，按用户角色限制可见知识范围。这套逻辑必须提前设计好，等数据铺开了再切权限模型，改造成本翻倍。
踩过这么多坑之后，我的体感是RAG不是一个“调完参数就完事”的算法问题，而是一个“从数据生产到检索到生成再到治理”的系统工程。每一层都有坑，每一层都有优化空间。如果你正在做或者准备做客服机器人，我建议第一步不是跑Demo，而是先把知识库的数据治理做扎实——文档整理干净、分块合理、元数据齐全，这三件事做好，RAG的效果就已经及格了。后面再慢慢优化重排、提示词和路由逻辑。说到底，一个不会胡说八道的客服机器人，地基不是在模型，是在你那堆看起来不起眼的知识文档里。