客服机器人最让人头疼的地方，不是它答不上来，而是它一本正经地胡说八道。用户问退货政策，它给你编一个"30天无理由退货"；用户问产品参数，它把两个型号的数据混在一起。这种"幻觉"问题在通用大模型上几乎无解，因为模型本质上是在做概率续写，它没有"不知道"这个概念。RAG（检索增强生成）就是冲着这个痛点来的——让模型在回答之前先去查资料，查到什么说什么，查不到就老实说不知道。这篇内容我会从RAG的核心原理讲起，一直落到用LangGraph、Milvus、Embedding模型搭建一套可运行的客服机器人系统，包括我在实际部署中踩过的坑和调优经验。不管你是刚接触RAG的新手，还是已经跑过Demo但效果不理想的开发者，都能从中找到可以直接复用的方案。
1. 为什么客服场景非RAG不可
1.1 纯大模型做客服的三个致命伤
先说清楚为什么不能直接拿大模型来当客服。我见过不少团队一开始的想法很简单：把GPT或者本地部署的模型接上API，写个System Prompt说"你是一个客服助手"，然后就上线了。结果不出三天，客诉量翻倍。
第一个问题是知识截止。大模型的训练数据有明确的时间边界，你公司上个月刚调整的退换货政策、新发布的SKU、刚变更的物流合作方，模型一概不知。你可能会想，那我把这些信息写进System Prompt不就行了？可以，但System Prompt有长度限制，而且每次请求都携带大量静态文本，Token成本会飙升。更关键的是，当知识库有几千条FAQ时，你根本塞不进去。
第二个问题是幻觉不可控。大模型在遇到不确定的问题时，不会说"我不知道"，而是会根据语言模式的惯性编一个看起来合理的答案。客服场景对准确性的要求极高，一个错误的退货地址可能导致用户寄错包裹，一个错误的保修期限可能引发法律纠纷。这种错误不是"体验不好"的问题，是"业务事故"的问题。
第三个问题是不可追溯。当用户质疑"你上次说的不是这样"时，纯大模型的回答没有任何依据可以查证。你无法知道模型是基于哪条知识做出的判断，也就无法修正和优化。这在客服场景里是致命的——你连问题出在哪都不知道，怎么改？
1.2 RAG到底解决了什么
RAG的思路其实很朴素：不让模型凭记忆回答，而是让它开卷考试。具体来说，当用户提出一个问题时，系统先去知识库里检索相关内容，把检索到的原文片段和用户问题一起交给模型，让模型基于这些材料来组织回答。
这个思路带来的改变是根本性的。模型不再需要"记住"你公司的业务知识，它只需要具备两个能力：一是理解用户问题在问什么，二是把检索到的材料用通顺的语言组织成回答。知识的事情交给知识库，语言的事情交给模型，各司其职。
从工程角度看，RAG还带来了几个额外的好处。知识更新变得极其简单——你只需要更新知识库里的文档，不需要重新训练或微调模型。回答可追溯——每一条回答都能对应到具体的知识片段，方便审核和纠错。成本可控——检索用的是向量相似度计算，比让模型处理超长上下文便宜得多。
但RAG不是银弹。它的效果高度依赖于检索质量，如果检索出来的内容不相关，模型照样会基于错误材料编出错误答案。所以RAG的核心工程挑战不在生成端，而在检索端。这也是为什么后面我会花大量篇幅讲Embedding模型选型、分块策略和Milvus索引调优。
1.3 客服机器人对RAG的特殊要求
通用RAG和客服RAG之间有明显的差异，不能直接套用同一套方案。
客服场景的第一个特殊要求是低延迟。用户在对话框里等3秒和等10秒的体验完全不同。这意味着检索环节不能太慢，Embedding模型不能太大，Milvus的索引类型要选对。我见过有人用7B参数的Embedding模型做检索，单次查询要2秒以上，加上生成时间，用户等得想砸键盘。
第二个要求是高准确率。客服回答不允许"差不多对"，必须是精确的。这就要求在检索阶段引入重排序（Rerank）机制，先用向量检索召回一批候选，再用更精细的模型对候选进行排序，把最相关的放在最前面。
第三个要求是多轮对话能力。用户不会每次都把问题说完整，可能第一句问"退货怎么操作"，第二句只问"那运费呢"。系统需要理解"那运费呢"指的是退货的运费，而不是别的什么运费。这就需要LangGraph这样的对话编排框架来管理对话状态和上下文。
第四个要求是兜底策略。当检索不到相关内容时，系统要能识别出来并给出合理的回复，而不是硬编一个答案。这个"不知道"的判断逻辑，比很多人想象的要复杂。
2. RAG检索质量的决定性因素
2.1 Embedding模型选型：不是越大越好
Embedding模型的作用是把文本转换成向量，让语义相近的文本在向量空间里距离更近。这是整个RAG系统的地基，选错了后面怎么调都白搭。
目前主流的选择分几个梯队。第一梯队是OpenAI的text-embedding-3-large和Cohere的embed-v3，效果好但需要调用外部API，有网络延迟和数据隐私的顾虑。第二梯队是开源的BGE系列（BAAI/bge-large-zh-v1.5、bge-m3）和M3E系列，可以本地部署，中文效果不错。第三梯队是轻量级的all-MiniLM-L6-v2和paraphrase-multilingual-MiniLM-L12-v2，速度快但精度一般。
我的建议是：中文客服场景优先选BGE-large-zh-v1.5或bge-m3。bge-m3的优势是支持多语言和长文本（8192 tokens），如果你的知识库里有中英文混合的内容，选它更省心。bge-large-zh-v1.5在纯中文场景下效果略好，模型体积也更小（约1.3GB）。
这里有个很多人忽略的点：Embedding模型的维度选择。bge-m3支持1024维，bge-large-zh-v1.5也是1024维。维度越高，表达能力和存储成本都越高。如果你的知识库规模在10万条以内，1024维完全够用。如果超过百万级，可以考虑用Matryoshka Embedding技术把维度降到512甚至256，精度损失很小但存储和检索速度提升明显。
还有一个实操细节：查询和文档要用同一个模型编码。我见过有人用模型A编码文档，用模型B编码查询，然后困惑为什么检索效果这么差。不同模型的向量空间是不对齐的，混用等于随机检索。
2.2 文本分块：切得好比选得好更重要
分块（Chunking）是RAG里最容易被低估的环节。很多人随便按500字一切就完事了，结果检索出来的片段要么缺头少尾，要么包含大量无关信息。
分块的核心矛盾是：块太小，语义不完整；块太大，噪声太多。一个500字的块可能包含三个不同的知识点，检索时匹配到了其中一个，但另外两个无关内容也会被送给模型，干扰生成。
我的经验是，客服知识库的分块要按语义边界切，而不是按字数切。具体做法是：先用规则把文档按标题、段落、列表项拆开，然后用一个滑动窗口做重叠切分。块大小控制在300-500字，重叠部分50-100字。重叠的作用是防止关键信息刚好被切在边界上。
对于FAQ类型的知识，最好的分块策略是一问一答一块。每个QA对作为一个独立的块，这样检索时匹配到的就是完整的问答，不会出现"问到了问题但答案被切掉了"的情况。
对于产品手册、政策文档这类长文本，我推荐用父子块（Parent-Child Chunking）策略。具体来说，把文档切成较大的父块（1000-1500字）和较小的子块（200-300字），检索时用子块匹配，但返回给模型的是父块。这样既保证了检索精度，又保证了上下文的完整性。LangChain的ParentDocumentRetriever就是干这个的。
还有一个坑：表格和图片的处理。客服知识库里经常有价格表、参数对比表。如果直接按文本切，表格的结构会丢失，变成一堆没有意义的数字。我的做法是把表格转成Markdown格式保留结构，或者用多模态Embedding模型（如CLIP）单独处理图片。Milvus支持多向量字段，可以把文本向量和图片向量存在同一个Collection里。
2.3 Milvus索引类型与参数调优
Milvus是当前最主流的开源向量数据库之一，但它的索引类型和参数配置对检索性能影响极大。选错了索引，要么检索慢，要么召回率低。
Milvus支持的主要索引类型有FLAT、IVF_FLAT、IVF_SQ8、HNSW、DISKANN等。对于客服场景，我的推荐是：
| 索引类型 | 适用场景 | 召回率 | 查询速度 | 内存占用 |
|---|---|---|---|---|
| FLAT | 小规模（<1万条） | 100% | 慢 | 高 |
| IVF_FLAT | 中等规模（1万-100万） | 高 | 中等 | 中等 |
| HNSW | 大规模（>100万） | 高 | 快 | 高 |
| IVF_SQ8 | 内存受限场景 | 中等 | 快 | 低 |
| DISKANN | 超大规模（>1000万） | 高 | 中等 | 低 |
客服知识库通常在几千到几万条之间，IVF_FLAT或HNSW是最实用的选择。如果追求极致召回率且数据量不大，直接上FLAT也行。
HNSW的关键参数是M和efConstruction。M控制每个节点的邻居数量，越大召回率越高但内存占用越大，一般设16-32。efConstruction控制建索引时的搜索范围，越大索引质量越好但建索引越慢，一般设200-500。查询时的ef参数控制搜索范围，越大召回率越高但越慢，一般设64-128。
IVF_FLAT的关键参数是nlist，即聚类中心的数量。经验公式是nlist = 4 * sqrt(N)，N是向量总数。比如你有1万条数据，nlist设400左右。查询时的nprobe参数控制搜索的聚类数量，一般设nlist的10%-20%。
还有一个容易被忽略的参数：距离度量方式。Milvus支持L2（欧氏距离）、IP（内积）和COSINE（余弦相似度）。对于文本Embedding，COSINE是最常用的，因为文本向量的模长没有实际意义，我们只关心方向。但要注意，如果你的Embedding模型已经做了归一化（大多数开源模型都会做），那么IP和COSINE是等价的，用IP计算更快。
3. 用LangGraph编排客服对话流程
3.1 为什么不用简单的Chain
很多人做RAG的第一反应是用LangChain的RetrievalQA Chain，几行代码就能跑通。但客服场景很快就暴露出问题：用户问了一个模糊的问题，Chain检索不到相关内容，直接返回"根据已知信息无法回答"，体验很差。或者用户连续问了三个问题，Chain每次都独立检索，完全丢失了上下文。
LangGraph的核心价值在于把RAG流程从线性Chain升级为状态图。你可以定义多个节点（检索、判断、生成、追问），用条件边控制流程走向。比如：检索到相关内容就走生成节点，检索不到就走追问节点让用户补充信息，用户补充后再重新检索。
这种灵活性在客服场景里至关重要。真实的客服对话不是一问一答的直线，而是有分支、有循环、有状态的。
3.2 状态设计：对话机器人的记忆管理
LangGraph的核心概念是State（状态），它贯穿整个对话流程。对于客服机器人，State里至少要包含这几样东西：
from typing import TypedDict, List, Annotated from langgraph.graph import StateGraph, END from langgraph.checkpoint.memory import MemorySaver class CustomerServiceState(TypedDict): messages: Annotated[List[dict], "对话历史"] query: str # 当前用户问题 retrieved_docs: List[dict] # 检索到的文档 relevance_score: float # 检索相关性评分 need_clarification: bool # 是否需要追问 final_answer: str # 最终回答messages字段用Annotated标记，配合LangGraph的add_messagesreducer，可以自动累积对话历史。这样在多轮对话中，模型能看到完整的上下文。
这里有个关键设计决策：对话历史要不要全部传给模型。我的做法是只保留最近5轮对话，更早的对话做摘要压缩。原因是Token成本和噪声控制——太长的历史会让模型分心，而且大部分客服对话在前几轮就已经解决了问题。
3.3 条件路由：什么时候该追问，什么时候该回答
LangGraph最强大的地方是条件边（Conditional Edge）。在客服场景里，我设计了三个路由分支：
第一个分支是相关性足够高（relevance_score > 0.75），直接走生成节点，基于检索到的文档组织回答。
第二个分支是相关性中等（0.5 < relevance_score <= 0.75），走一个"确认节点"，让模型先复述用户的问题并确认理解是否正确，同时给出一个初步回答。这样即使用户问题模糊，也能通过确认环节澄清。
第三个分支是相关性低（relevance_score <= 0.5），走追问节点，让用户补充更多信息。追问的话术要设计好，不能简单说"我不理解"，而是要说"您是想了解退货流程还是换货流程？"这样引导性的追问。
def route_by_relevance(state: CustomerServiceState): score = state["relevance_score"] if score > 0.75: return "generate" elif score > 0.5: return "confirm" else: return "clarify" workflow = StateGraph(CustomerServiceState) workflow.add_node("retrieve", retrieve_node) workflow.add_node("generate", generate_node) workflow.add_node("confirm", confirm_node) workflow.add_node("clarify", clarify_node) workflow.set_entry_point("retrieve") workflow.add_conditional_edges("retrieve", route_by_relevance) workflow.add_edge("generate", END) workflow.add_edge("confirm", END) workflow.add_edge("clarify", END)这个路由逻辑看起来简单，但实际效果比线性Chain好很多。用户不会收到"无法回答"这种冷冰冰的回复，而是被引导着把问题说清楚。
3.4 工具调用：让客服机器人能查订单、算运费
LangGraph的另一个杀手级功能是工具调用（Tool Calling）。客服机器人不只是回答FAQ，还需要查订单状态、计算运费、发起退换货申请。这些操作需要调用外部API，LangGraph的ToolNode可以无缝集成。
from langchain_core.tools import tool @tool def query_order_status(order_id: str) -> str: """根据订单号查询订单状态""" # 调用内部订单系统API return f"订单{order_id}当前状态：已发货，预计明天送达" @tool def calculate_shipping(from_city: str, to_city: str, weight: float) -> str: """计算运费""" # 调用运费计算服务 return f"从{from_city}到{to_city}，{weight}kg的运费为15元" tools = [query_order_status, calculate_shipping]在LangGraph里，你可以加一个tool_node节点，让模型自己决定什么时候调用工具。比如用户问"我的订单12345到哪了"，模型会识别出需要调用query_order_status，自动提取订单号并执行。
这里有个实操经验：工具的描述（docstring）要写得非常清楚。模型是根据工具描述来决定调不调用的。如果描述模糊，模型可能该调的时候不调，不该调的时候乱调。我一般会在描述里写清楚：这个工具是干什么的、什么情况下用、参数格式是什么。
4. 从零搭建一套可运行的客服RAG系统
4.1 环境准备与Milvus部署
先说环境。我的开发环境是Mac + Docker，生产环境是Linux服务器。Milvus在两种环境下的部署方式略有不同。
在Mac上，用Docker Compose部署Milvus Standalone是最省事的：
wget https://github.com/milvus-io/milvus/releases/download/v2.4.0/milvus-standalone-docker-compose.yml -O docker-compose.yml docker-compose up -d启动后，Milvus默认监听19530端口（gRPC）和9091端口（HTTP）。你可以用docker ps确认三个容器（etcd、minio、milvus）都正常运行。
在Linux服务器上，如果只是做轻量级测试，可以用Milvus Lite模式，直接指定本地文件路径：
from pymilvus import MilvusClient client = MilvusClient("./data/milvus.db")Milvus Lite适合数据量小、单机运行的场景，不需要额外部署etcd和minio。但它的性能有限，生产环境还是建议用Standalone或Cluster模式。
注意：Milvus Lite和Standalone的数据格式不兼容，不能直接迁移。如果从Lite切换到Standalone，需要重新导入数据。
4.2 知识库构建：从原始文档到向量
知识库构建的完整流程是：文档加载 → 文本清洗 → 分块 → 向量化 → 存入Milvus。
文档加载用LangChain的DocumentLoader，支持PDF、Word、Markdown、HTML等格式。文本清洗主要是去掉页眉页脚、多余空行、特殊字符。分块用RecursiveCharacterTextSplitter，设置chunk_size=400，chunk_overlap=80。
向量化用BGE模型：
from sentence_transformers import SentenceTransformer model = SentenceTransformer('BAAI/bge-large-zh-v1.5') def embed_texts(texts): # BGE模型建议在查询前加instruction前缀 embeddings = model.encode(texts, normalize_embeddings=True) return embeddings.tolist()注意normalize_embeddings=True，这样向量就是单位向量，后续用IP距离度量等价于余弦相似度，计算更快。
存入Milvus的代码：
from pymilvus import MilvusClient, DataType client = MilvusClient(uri="http://localhost:19530") # 创建Collection schema = client.create_schema(auto_id=True, enable_dynamic_field=True) schema.add_field("id", DataType.INT64, is_primary=True) schema.add_field("vector", DataType.FLOAT_VECTOR, dim=1024) schema.add_field("text", DataType.VARCHAR, max_length=2000) schema.add_field("source", DataType.VARCHAR, max_length=500) index_params = client.prepare_index_params() index_params.add_index( field_name="vector", index_type="HNSW", metric_type="IP", params={"M": 16, "efConstruction": 200} ) client.create_collection("customer_service", schema=schema, index_params=index_params)4.3 检索链路：向量召回 + 重排序
基础检索就是拿用户问题的向量去Milvus里搜Top-K相似的文档。但Top-K的K值怎么定？太小可能漏掉相关内容，太大则引入噪声。
我的做法是两阶段检索：第一阶段用向量检索召回Top-20，第二阶段用重排序模型（Rerank）对20条结果精排，取Top-3送给模型。
重排序模型推荐BAAI/bge-reranker-v2-m3，它比向量检索更精细，能捕捉到query和document之间的细粒度语义关系。代价是速度慢一些，但只对20条候选做重排，延迟可以接受。
from FlagEmbedding import FlagReranker reranker = FlagReranker('BAAI/bge-reranker-v2-m3', use_fp16=True) def rerank(query, candidates, top_k=3): pairs = [[query, doc["text"]] for doc in candidates] scores = reranker.compute_score(pairs) ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True) return [doc for doc, score in ranked[:top_k]]实测下来，加了Rerank之后，检索准确率能提升15%-25%，尤其是对于语义相近但细节不同的文档（比如"退货政策"和"换货政策"），区分效果明显。
4.4 生成环节：Prompt设计与幻觉抑制
检索到文档后，最后一步是让模型基于文档生成回答。Prompt的设计直接决定了回答质量。
我的System Prompt模板是这样的：
你是一个专业的客服助手。请严格根据以下参考资料回答用户问题。 规则： 1. 只使用参考资料中的信息，不要添加任何参考资料之外的内容。 2. 如果参考资料中没有相关信息，直接回答"抱歉，我暂时没有找到相关信息，建议您联系人工客服"。 3. 回答要简洁明了，直接给出用户需要的答案，不要重复问题。 4. 如果参考资料中有多个相关条目，综合它们的信息给出完整回答。 参考资料： {context} 用户问题：{question}这个Prompt的关键在于明确禁止模型使用参考资料之外的知识。实测下来，这条规则能显著降低幻觉率。但要注意，模型有时会"偷偷"使用自己的知识，尤其是在参考资料不完整的时候。所以检索质量仍然是第一位的。
还有一个技巧：在参考资料中标注来源。比如每条文档前面加上[来源：退货政策文档]，这样模型在回答时可能会引用来源，增加可信度。
5. 实际部署中踩过的坑
5.1 检索到了但答不对：分块边界问题
这是我在实际项目里遇到的第一个大坑。用户问"退货需要几天到账"，系统检索到了退货政策文档，但检索到的片段刚好把"到账时间"那部分切掉了，只返回了退货条件。模型基于不完整的片段，编了一个"3-5个工作日"的答案，而实际政策是"7-15个工作日"。
排查这个问题的过程很痛苦，因为从日志上看，检索确实命中了正确的文档，只是命中的片段不完整。后来我调整了分块策略，把chunk_overlap从50提高到100，并且在分块时优先按段落边界切，而不是按固定字数切。这个问题就基本解决了。
5.2 多轮对话中的指代消解
用户第一轮问"退货怎么操作"，第二轮问"那运费谁出"。如果系统独立处理第二轮，检索"运费谁出"可能匹配到物流费用相关的文档，而不是退货运费。这就是指代消解问题。
我的解决方案是在LangGraph的State里维护一个last_topic字段，记录上一轮对话的主题。当检测到当前问题包含指代词（"那""这个""它"）时，把last_topic拼接到查询里再检索。比如把"那运费谁出"改写成"退货的运费谁出"，检索准确率大幅提升。
这个改写可以用一个小模型来做，也可以用规则匹配。规则匹配的准确率已经够用了，而且没有额外延迟。
5.3 Milvus连接超时与重试
在生产环境上，Milvus偶尔会出现连接超时。尤其是在数据导入阶段，大量并发写入可能导致连接池耗尽。我的做法是加一个重试装饰器：
from tenacity import retry, stop_after_attempt, wait_exponential @retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=1, max=10)) def search_with_retry(client, collection, query_vector, top_k): return client.search(collection, [query_vector], limit=top_k)同时把Milvus的timeout参数从默认值调大到10秒，避免大批量操作时超时。
5.4 Embedding模型的冷启动延迟
BGE-large模型第一次加载需要几秒钟，如果每次请求都重新加载，延迟无法接受。解决方案是在服务启动时预加载模型，并保持常驻内存。如果用FastAPI部署，可以在startup事件里加载模型：
from fastapi import FastAPI app = FastAPI() model = None @app.on_event("startup") async def load_model(): global model model = SentenceTransformer('BAAI/bge-large-zh-v1.5')这样模型只在服务启动时加载一次，后续请求直接复用。
6. 效果评估与持续优化
6.1 怎么判断RAG系统好不好
RAG系统的评估不能只看"回答对不对"，要拆成检索质量和生成质量两个维度。
检索质量的指标是召回率（Recall）和精确率（Precision）。召回率衡量的是"该检索到的文档有没有被检索到"，精确率衡量的是"检索到的文档有多少是相关的"。客服场景对召回率要求更高，因为漏掉关键信息的代价比引入噪声更大。
生成质量的指标是忠实度（Faithfulness）和答案相关性（Answer Relevancy）。忠实度衡量的是"回答是否完全基于检索到的文档"，答案相关性衡量的是"回答是否切题"。这两个指标可以用RAGAS框架自动评估。
我的做法是建一个包含100-200个问答对的测试集，覆盖常见问题和边界情况。每次调整检索策略或Prompt后，跑一遍测试集，看指标变化。没有测试集的RAG优化就是盲人摸象。
6.2 持续优化的三个方向
第一个方向是扩充知识库。很多检索失败的根本原因是知识库里根本没有相关内容。定期分析用户问但系统答不上的问题，补充到知识库里。
第二个方向是优化分块策略。随着知识库内容的变化，最优的分块大小和重叠长度也会变化。建议每季度重新评估一次分块效果。
第三个方向是微调Embedding模型。如果你的客服领域有大量专业术语（比如医疗、法律、金融），通用Embedding模型可能表现不佳。可以用领域数据微调BGE模型，效果提升明显。但微调需要标注数据，成本较高，建议先用Rerank和Prompt优化，实在不够再考虑微调。
6.3 一个容易被忽略的指标：拒答率
拒答率是指系统回答"我不知道"的比例。这个指标太高说明检索或知识库有问题，太低则可能意味着模型在硬编答案。健康的客服RAG系统，拒答率应该控制在5%-15%之间。低于5%要警惕幻觉，高于15%要检查知识库覆盖度。
我在实际运营中发现，拒答率突然升高通常是知识库更新导致的——新文档的分块格式和旧文档不一致，导致检索匹配不到。所以每次知识库更新后，都要监控拒答率的变化。
7. 一些实操心得
关于Embedding模型，我的建议是先用bge-m3跑通全流程，再根据效果决定要不要换。bge-m3的多语言和长文本支持让它成为最省心的起点，等系统跑起来、有了测试集之后，再对比bge-large-zh-v1.5或其他模型的效果。
关于Milvus，不要一上来就追求Cluster模式。Standalone模式在数据量百万级以下完全够用，运维复杂度低得多。等真的遇到性能瓶颈再升级也不迟。
关于LangGraph，状态设计要克制。不要把所有东西都塞进State里，只放真正需要跨节点传递的数据。State太臃肿会导致调试困难，而且每次节点切换都要序列化和反序列化State，影响性能。
关于Prompt，少即是多。我试过写很长的System Prompt，列了十几条规则，结果模型反而无所适从。后来精简到4-5条核心规则，效果更好。规则太多会让模型在规则之间"打架"。
最后分享一个调试技巧：把检索到的文档和最终回答一起打日志。这样当用户反馈回答错误时，你能快速定位是检索错了还是生成错了。我见过很多团队只打最终回答的日志，出了问题完全不知道从哪查起。
