从零搭建一个LLM智能客服：完整技术链路与关键决策

---

如何阅读本文：

本文按八个技术层级组织，每层包含"是什么→评估维度→场景取舍→PM与算法协作"四个部分，结构一致，可以通读也可以按需跳转。

• 通读：按顺序阅读，建议先读"业务特性分类"和"L4系统请求执行顺序"两节，建立整体框架后再进入各层细节
• 按需查阅：直接跳到目标章节。每层的"协作要点"表格是快速决策参考；"场景取舍"是按自身业务特性打标后的选型建议
• 决策地图：文末"总结：AI PM的决策地图"是全文的一页纸概览，适合在项目推进中快速定位"当前处于哪层、该问什么问题"

本文范围说明：本文覆盖文本模态的完整技术链路。多模态场景（用户上传图片、语音交互）涉及额外的视觉理解和语音识别层，不在本文讨论范围内。

智能客服的复杂度分层

在进入技术细节之前，先建立一个复杂度坐标系。市面上的"智能客服"大致可以分为四个层级：

L1：规则型机器人。基于关键词匹配或决策树，无LLM参与。能处理固定格式的问题，无法理解语义变体。适合问题类型极少、答案完全固定的场景（如"营业时间是几点"）。

L2：单轮RAG客服。引入LLM和知识库，能理解自然语言、检索相关文档并生成回答。但每次对话独立，不记忆上下文。适合问题类型多样、答案来源于文档库的场景。

L3：多轮对话+RAG。在L2基础上加入上下文管理，支持多轮追问和指代消解（如"那这个怎么退款"中的"这个"指代前文提到的商品）。

L4：完整生产级系统。在L3基础上叠加意图识别与路由、人工接管机制、完整的离线+在线评估体系、延迟优化、权限管控、可观测性监控。这是真实企业级部署的形态。

本文覆盖L4的完整链路。

L4系统的请求执行顺序：本文按技术层级组织，但实际运行时各层的执行顺序与章节顺序不完全一致。下图展示了一条请求的完整路径：

几个关键点补充说明：输入侧合规检测（PII脱敏、Prompt注入过滤）在意图路由之前执行；Text-to-SQL的SQL执行结果在生成层与RAG主链路汇合，由LLM统一组织成自然语言；输出侧合规检测（幻觉检测、违禁表述过滤）在生成层之后、返回用户之前执行；查询改写（3.1节）发生在确认走RAG路径之后、向量检索之前，与意图识别是先后关系而非并列；评估层、工程层、迭代闭环层不在请求链路上，而是横切所有层持续运行的基础设施。

---

业务特性分类：场景取舍的共同语言

各技术节点的选型不存在绝对最优解，最终取决于产品所处的业务场景。为了避免在每个节点重复解释背景，这里先统一定义业务特性标签，后文中直接引用。以下分类是本文基于常见业务场景归纳的框架，非行业标准术语，供参考使用。

使用方式：标签按三个维度组织，每个维度下按需打标，可多选也可不选。没有命中任何标签的维度，说明该维度对你的场景没有特殊约束，按各节的通用建议执行即可。一个产品通常会同时命中多个标签，后文各节点的场景取舍遇到此情况，取各自约束的交集。

示例对照：

• 银行智能客服 = 准确率敏感型（维度一）+ 延迟敏感型（维度二）+ 隐私合规型（维度三）
• 新创业公司FAQ机器人 = 冷启动期（维度三），维度一和二无特殊约束
• 大型电商促销期客服 = 延迟敏感型 + 吞吐量敏感型（维度二）+ 知识更新频繁型（维度三）
• 企业内部低频知识库 = 三个维度均无特殊约束，按通用建议执行

---

维度一：对错误的容忍边界

准确率敏感型：约束来源是"答错了有直接的法律、财务或医疗代价"，对幻觉容忍度接近于零，宁可拒答也不能答错。典型行业：金融（投资建议、合规判断）、医疗（诊断辅助、用药指导）、法律（条款解释、合同审查）。

如果你的场景在维度一没有命中任何标签，说明错误代价在可接受范围内，系统可以容忍一定的幻觉率，优先关注用户体验和覆盖率。

---

维度二：对系统性能的约束

延迟敏感型：用户在实时交互中等待，超过阈值就会流失或体验崩坏。典型场景：ToC实时文字客服（容忍首token延迟通常＜2秒）、语音交互（更严格，通常＜500ms）、直播答疑。

吞吐量敏感型：并发量大，成本压力高，系统需要在有限预算内服务大量请求。典型场景：大型平台的自助客服、批量文档处理、高频低复杂度的问答。

延迟敏感型和吞吐量敏感型可以同时命中（如大型ToC实时客服），也可以都不命中（如低频企业内部工具）。两者同时命中时，延迟约束优先于成本优化。

---

维度三：运营与合规约束

隐私合规型：约束来源是"数据不能流出特定边界"，受监管要求或企业安全策略约束，对第三方API有合规限制。典型行业：政务系统、医院核心系统、银行核心业务系统、金融机构内部知识库、涉密企业内部系统。

知识更新频繁型：知识库内容变更频率高，系统需要快速同步，否则容易产生"过时回答"类幻觉。典型场景：电商（SKU、促销规则频繁变动）、政策类客服（法规更新）、SaaS产品文档（版本迭代快）。

冷启动期：产品早期，标注数据极少，业务规则尚不稳定。典型场景：新产品上线初期、小团队快速验证MVP。这类阶段工程简单性和可迭代性优先于极致性能。注意这是产品生命周期阶段标签，会随时间变化——系统稳定、数据积累足够后，这个标签自然退出。

---

冷启动期的最小可行系统

如果你当前处于冷启动期，不需要从L4开始搭建。以下是一个能快速上线、后续可逐步升级的最小可行配置，覆盖L2-L3之间的能力：

• 数据层：固定分块，商业Embedding API（无需自托管），pgvector或Chroma（无需独立向量数据库）
• 检索层：纯向量检索起步（暂不引入BM25混合，暂不加Reranker）
• 生成层：闭源商业API，Prompt中加强制引用约束，暂不做成本路由
• 对话管理层：滑动窗口上下文管理，规则触发人工接管（暂不做情绪识别）
• 评估层：从第一天起收集用户反馈信号（Thumbs down），人工抽检，暂不搭建自动化RAGAS评估
• 工程层：默认启用Streaming输出，暂不做语义缓存

当月API费用超过预算阈值、或评估数据积累到100条以上时，再逐层引入更复杂的组件。后文各节的"冷启动期"场景取舍是对这个基础配置的细化补充。

---

一、数据层：知识从哪里来

1.1 知识库来源与文档解析

智能客服的知识来源通常是异构的。一个典型的企业客服知识库可能包含：产品说明书（PDF）、常见问题文档（Word/HTML）、政策文件（PDF/内部Wiki）、工单历史记录（结构化数据库）、实时更新的价格和库存信息（数据库/API接口）。

不同来源对应不同的技术路径：非结构化文档（PDF、Word、HTML）走向量检索路径（见3.2节）；结构化数据（订单数据库、库存表）走Text-to-SQL路径（见3.4节）。两条路径在完整系统中并存，由意图路由层决定走哪条。

主流解析工具：Unstructured.io专为非结构化文档设计，对PDF表格和复杂排版处理能力强，目前是生产级RAG系统的主流选择；LlamaParse针对RAG场景优化，对含图表的PDF支持较好；Apache Tika格式支持最广，适合多格式混合场景。扫描件PDF需额外引入OCR（开源选项：Tesseract；商业选项：AWS Textract、Azure Document Intelligence）。

评估维度：

• 解析完整性：关键内容（表格数据、页眉页脚、多栏文字）是否被正确提取，而不是乱码或丢失
• 格式保留度：表格结构、列表层级是否在解析后仍可被识别，影响后续Chunking的语义完整性
• 处理速度：大批量入库时的吞吐能力，影响知识库更新的及时性
• 错误率：解析失败或解析结果严重错误的文档比例，需要人工兜底的成本

场景取舍：

---

1.2 Chunking策略

文档解析完成后，需要将长文本切割成更小的片段（chunk）用于检索。Chunking是RAG链路中最容易被忽视、但对最终质量影响最大的环节之一。

切得太大：每个chunk包含太多无关内容，检索噪音高，LLM需要从大量冗余信息中提取答案，容易跑偏。切得太小：语义完整性被破坏，一段完整的政策说明被切成碎片，检索时只能召回片段而非完整逻辑。

三种主要策略：

固定分块：按token数量切割，相邻块保留一定比例的重叠（overlap），避免语义在边界被截断。实现最简单，适合文本结构规律、语义单元边界不明显的场景（如工单历史）。overlap是固定分块的必要参数，完全不重叠会导致边界处的信息丢失。

案例：某电商平台将产品说明书按固定大小切割，退换货政策横跨两个chunk边界——第一个chunk以"支持7天无理由退换"结尾，第二个从"但以下情形不适用"开始。用户问"能退货吗"，系统只召回了第一个chunk，遗漏了关键排除条款，导致客诉。引入chunk重叠后问题消失。

语义分块：计算相邻句子之间的语义相似度，在相似度骤降的位置切割，确保每个chunk内部语义连贯。适合叙述性文本和FAQ文档，实现成本高于固定分块。语义分块的切割点选在语义边界，天然减少了边界截断问题，但部分实现中仍会在切割点附近保留轻量级的上下文窗口（即轻量overlap），以应对语义相似度判断不准确的情况。

层级分块：同时维护父chunk（完整段落/章节）和子chunk（具体句子），检索时用子chunk定位，生成时补充父chunk的完整上下文。适合结构化文档（有章节层级的政策手册、产品文档）。层级分块本质上是一种结构化的overlap机制——父chunk始终作为子chunk的上下文补充存在，解决了固定分块中overlap范围固定、无法感知语义结构的问题。

评估维度：

• 召回率（Recall）：正确答案所在的chunk能否被检索到。切片边界不合理是召回失败的高频原因
• 上下文完整性：被召回的chunk是否包含回答问题所需的完整信息，还是只有半截
• 噪音比：召回结果中与问题无关的内容占比，影响LLM生成质量
• 入库效率：分块策略的计算成本，影响知识库大规模更新时的处理时间

场景取舍：

AI PM与算法协作：PM的职责是提供代表性的badcase样本（哪类问题的回答明显残缺或跑偏），算法据此判断是切片问题还是检索问题。切片策略的调整需要重新入库，成本较高，PM需要在"投入优化"和"先上线再迭代"之间做优先级判断。验收标准建议定义为：在代表性评估集上，召回率不低于目标阈值（参考值：冷启动期可先设70%，稳定期提升至85%以上；具体阈值需根据业务场景和知识库特性调整，无通用标准）。

---

1.3 Embedding模型选型

Embedding模型将文本转换为向量，是语义检索的基础。模型的选择直接决定检索能力的天花板——再好的检索策略，也无法弥补embedding本身的语义理解缺陷。

评估维度：

• 检索质量：在业务相关的问答对上，模型能否将语义相近的query和document映射到相近的向量空间。MTEB榜单是通用参考，但MTEB是通用测试集，专业领域（法律、金融、医疗）的真实表现可能与榜单排名有较大偏差，自有数据集上的测试比榜单更重要
• 多语言支持：中英文混合、多语言场景下的跨语言语义对齐能力
• 上下文窗口：支持的最大输入长度，影响长chunk的处理能力，窗口短则长chunk需截断
• 推理延迟：每次embedding的耗时，影响实时检索的响应速度
• 成本：API调用费用（商业模型）或GPU推理成本（开源自托管），规模化后差异显著
• 数据安全：文本是否需要发往第三方服务器，隐私合规型场景的硬性约束

场景取舍：

AI PM与算法协作：PM主导"数据安全要求"和"多语言需求"这两个维度的决策，因为这是业务和合规侧的约束；算法主导具体模型的技术评估（在业务数据集上跑benchmark）。PM需要帮助构建评估用的问答对数据集，这是算法无法独立完成的——算法不了解哪些问题是业务上的高频重要问题。

补充：自托管Embedding模型中，bge-m3原生支持稀疏+稠密双模式输出，可以直接用于2.1节的混合检索，无需额外引入独立的BM25索引，是自托管混合检索场景的高性价比选择。

---

1.4 向量数据库选型

向量数据库负责存储embedding向量并支持高效相似度检索。

评估维度：

• 检索延迟：p50/p99延迟，影响用户感知的响应速度
• 并发能力：同时处理多少查询请求而不显著降级，影响高峰期的系统稳定性
• 混合检索支持：是否原生支持向量+关键词（BM25）混合检索，影响检索质量（详见第二章）
• 数据规模上限：能支持多少向量条目而不显著影响性能
• 运维复杂度：自托管的运维成本，有无托管SaaS选项
• 多租户隔离：同一实例下不同业务线或客户的数据隔离能力，企业级部署的重要需求

场景取舍：

主流选项定位：Pinecone全托管SaaS，运维成本最低；Qdrant自托管/云，延迟低、原生支持混合检索；Weaviate生态丰富、模块化；pgvector复用现有PostgreSQL，向量规模较小时的最简方案；Chroma本地开发首选，不适合生产。

---

结构化数据（订单数据库、库存表）通过Text-to-SQL路径访问，详见3.4节。

数据层协作要点

---

二、意图路由层：请求走哪条路径

2.1 意图识别与路由

并非所有用户问题都适合同一条处理路径。生产级系统在最前端设置意图识别层，先于任何检索或生成执行，将请求分发到对应路径：

• 知识检索路径：可以在知识库中找到答案的问题 → RAG流程
• 数据查询路径：需要查询订单、账户等结构化数据 → Text-to-SQL流程
• 业务操作路径：需要调用后端系统执行操作（发起退款、修改订单）→ API调用/Agent流程
• 情感响应路径：用户表达情绪、进行闲聊 → 情感回应逻辑，不触发检索
• 人工转接路径：超出系统能力或高风险场景 → 触发人工接管
• 拒绝路径：恶意输入、无关问题 → 礼貌拒绝

上述六条路径是完整的意图分类体系；流程图中为简洁起见仅展示了三条主要分支（RAG主链路、Text-to-SQL、人工接管），业务操作、情感响应、拒绝路径的处理逻辑与此一致。

评估维度：

• 意图分类准确率：路由判断的正确率，错误路由会导致用户在错误的路径里循环
• 边界问题处理：意图模糊时（问题可能属于多个类别）的处理逻辑是否合理
• 分类延迟：意图识别必须足够快，不能成为整体响应的瓶颈

AI PM与算法协作：意图的类别定义和边界划分是PM主导的业务决策——"什么算超出系统能力"、"什么算高风险场景"，不是技术判断。PM需要提供覆盖各类意图的测试用例，算法负责分类器的实现和优化。

场景取舍：

---

三、检索层：怎么找到对的内容

检索层包含四个子节，执行顺序为：3.1查询改写（优化query表达）→ 3.2向量/关键词混合检索（从非结构化文档库找内容）→ 3.3 Reranker（精排候选结果，可选）。3.4 Text-to-SQL是并行的另一条路径，面向结构化数据库查询，由意图路由层决定与3.2走哪条——两条路径共同构成检索层的完整全集，分别覆盖非结构化文档和结构化数据两类数据形态。

3.1 查询改写（Query Rewriting）

查询改写发生在意图识别确认走RAG路径之后、向量检索之前——它解决的不是"走哪条路"，而是"怎么把query表达得更利于检索"。与意图识别是先后关系，不是并列关系。查询改写是可选组件：如果用户表达规范、以单轮问答为主，直接用原始query检索也能达到较好效果；多轮对话场景中，指代消解部分是必须的。

用户输入的query往往不是检索友好的形式，有两类主要问题：

指代不明：多轮对话中，用户常用"这个"、"那个"指代前文提到的对象，含指代词的query无法直接检索。解决方式是在检索前用LLM将query改写为独立完整的检索语句。

例：用户在第3轮问"那退款需要多久？"→改写为"申请退换货之后，退款到账需要多少个工作日？"

表达不精确：用户描述问题的方式与知识库表达不匹配（"快递丢了" vs 知识库中的"物流异常"）。解决方式包括同义词扩展、或让LLM生成假设性回答再用回答去检索（HyDE技术）。

评估维度：

• 改写准确率：改写后的query是否准确保留了用户的原始意图，没有偏移或遗漏关键信息
• 召回率提升：改写后相比直接用原始query，检索召回率的提升幅度
• 改写延迟：额外引入的LLM调用耗时，对整体响应时间的影响

场景取舍：

AI PM与算法协作：PM的核心贡献是提供"哪些问题因为表达问题没有找到答案"的badcase样本，这是算法判断是否需要引入改写、以及改写哪种类型的依据。PM同时负责定义指代消解的业务优先级（多轮场景是否是核心场景），算法负责改写方案的实现和延迟优化。

---

3.2 稠密检索、稀疏检索与混合检索

稠密检索（Dense Retrieval）：将用户query转换成向量，在数据库中找语义最相近的chunk，能理解语义变体但有一个固有盲区——精确关键词匹配。订单号、产品SKU、法律条款编号这类精确字符串，语义相似度无法保证准确命中。

稀疏检索（Sparse Retrieval，以BM25算法为代表）：本质是升级版关键词匹配，对精确词汇的召回率高，但无法理解语义变体（"退货"和"退换货"在BM25看来是不同词）。

混合检索将两路并行，通过加权融合合并结果，兼顾语义理解和精确匹配，是生产场景的标准配置。

以保险合同类客服场景为例：用户问"第7条责任免除条款的赔付上限"时，含有条款编号的精确字符串正是纯向量检索的盲区——系统容易召回与"赔付"语义相关但不含"第7条"编号的文档。引入混合检索后，BM25路径能准确命中含该编号的文档。据生产RAG系统对比研究，混合检索相比纯向量检索，召回率从约78%提升至91%，精确字符串查询场景的提升幅度尤为显著。

评估维度：

• 召回率@K：前K个结果中包含正确答案的比例，衡量"找没找到"
• MRR（平均倒数排名）：正确答案排在第几位的平均倒数，衡量"找到了排多靠前"
• 精确匹配率：对含有精确字符串（编号、代码）的问题，准确命中的比例
• 融合权重敏感性：稠密/稀疏两路权重调整对结果的影响幅度，权重太敏感说明系统不稳定

场景取舍：

生产数据参考：据对比研究，稠密检索召回率@10约78%，BM25约65%，混合检索约91%，绝对数值因数据集不同差异较大。

AI PM与算法协作：混合检索几乎在所有生产场景下都值得启用，PM不需要纠结"要不要用"，而是关注验收标准——在评估集上，召回率和MRR相比baseline有没有显著提升。融合权重的调整由算法主导，PM提供业务判断（"这个产品里精确查询和语义查询哪类更多"）。

---

3.3 重排序（Reranker）

混合检索通常召回top-20到top-50个候选chunk，最终送入LLM的往往只有top-3到top-5。Reranker负责在这两步之间精排，判断每个候选chunk对当前query的真实相关度。

Reranker与检索阶段的向量相似度的核心区别：向量检索是独立编码query和document再比较（快但精度有限）；Reranker是将query和document拼接后一起编码（精度高但计算成本大，所以只用于候选集精排）。

主流Reranker选项：Cohere Rerank（商业API，接入方便）；BGE-Reranker-v2-m3（BAAI开源，支持中文，自托管首选）；Jina Reranker（支持长文档输入）。

评估维度：

• NDCG@K（归一化折损累积增益）：综合衡量精排后结果的相关性排序质量
• 精排后Top-K准确率：精排后最终送入LLM的K个chunk，包含正确答案的比例
• 延迟增量：Reranker带来的额外延迟，是否在可接受范围内
• 边际收益：相比不加Reranker，质量提升幅度与延迟增加是否值得

Reranker是可选组件，不是标配。引入前需先通过A/B对比量化收益：对比有/无Reranker时Top-K准确率和最终回答质量的差异。如果差异不显著，引入Reranker只会增加延迟和维护成本。

值得引入Reranker的情况：

• 知识库体量大（万级以上chunk），候选集噪音高，召回的top-20里有大量不相关结果
• 问题语义复杂，同一query对应多种可能意图，向量相似度无法区分
• 评估集上Context Precision（上下文精确性）指标持续偏低

可以先不加Reranker的情况：

• 知识库体量小（千级以下chunk），候选集噪音天然低
• 延迟敏感型场景，Reranker的50-200ms增量超出预算
• 冷启动期，评估数据不足以支撑有效的A/B对比

场景取舍：

AI PM与算法协作：引入Reranker是需要数据说话的决策——PM提出"当前检索结果有多少比例召回了正确答案但排名靠后"的业务问题，算法给出有/无Reranker的量化对比。PM根据质量收益和延迟/成本代价共同决定是否引入，不应基于"这个技术更先进"来决定。

---

3.4 Text-to-SQL：结构化数据的检索路径

3.2节介绍的稠密/稀疏/混合检索，解决的是非结构化文档（PDF、Word、FAQ等）的语义检索问题，找到的是文本片段。但智能客服中有一类高频需求，答案不在文档里，而在结构化数据库的表里：查订单状态、查账户余额、查物流信息、查库存数量。

两条路径构成检索层的完整全集：

Text-to-SQL的工作原理：LLM理解用户的自然语言问题，自动生成SQL查询语句，执行后将结果返回给LLM，再组织成自然语言回答。

用户问题："我的订单2024-88888现在在哪里？"
       ↓
LLM生成SQL：SELECT status, location FROM orders WHERE order_id = '2024-88888'
       ↓
数据库返回：{status: "运输中", location: "上海转运中心"}
       ↓
LLM生成回答："您的订单目前正在上海转运中心，处于运输中状态。"

评估维度：

• SQL准确率：生成的SQL是否能正确返回用户想要的数据
• 执行安全性：是否有可能生成破坏性SQL（DELETE、UPDATE），必须有硬性拦截机制，这是SQL路径的一票否决项
• Schema理解能力：数据库表结构复杂时（多表关联、字段命名不规范），LLM能否生成正确的JOIN逻辑
• 延迟：SQL生成+执行的总耗时，数据库查询本身可能成为瓶颈
• 权限控制：用户只能查自己的数据，不能通过自然语言绕过权限查到他人数据

场景取舍：

AI PM与算法协作：PM需要提供数据库的业务语义描述（哪张表存什么、字段的业务含义是什么），这些描述会注入到LLM的context中帮助SQL生成，算法无法独立完成这部分工作。SQL准确率的验收需要PM参与定义测试用例（"用户会问哪些典型的数据查询问题"）。

---

检索层协作要点

检索层的优化是一个迭代过程：PM提供"哪些问题没找到正确答案"的样本，算法判断是混合检索权重、查询改写还是Reranker的问题，两者共同决定验收阈值和是否引入新组件。

---

四、生成层：怎么生成好答案

4.1 主模型选型与评估框架

召回的相关chunk和用户的问题共同构成送给LLM的输入，LLM负责生成最终回答。主模型的选择是整个系统最核心的决策之一，但它不应该是一个纯技术决策。

四个评估维度（本文归纳）：

质量维度——模型能力本身：

• 指令遵循能力：模型是否能严格按照系统Prompt中规定的格式、语气、禁区生成回答，不越界、不跑偏。客服场景中这点尤为关键（"不能承诺退款金额"这类约束，模型必须严格遵守）
• 幻觉率：在没有检索依据的情况下，模型主动捏造信息的概率
• 推理能力：对于需要多步推理的问题（如计费规则计算、多条款组合判断），模型能否给出正确结论
• 领域适配性：在特定专业领域（金融、医疗、法律）的表现，通用榜单排名高不代表垂直领域表现好

成本维度——规模化后的经济账：

• 推理延迟：首token时延（TTFT）和完整响应时间
• Token单价：输入/输出token的费用，规模化后差距悬殊
• 自托管门槛：如果考虑开源自托管，所需GPU资源和MLOps人力的固定成本
• 成本路由可行性：是否支持用轻量版本处理简单问题、大模型处理复杂问题的分层策略

合规维度——数据和法规约束：

• 数据驻留：用户数据是否会发往境外服务器，涉及跨境数据合规
• 服务协议：服务商是否会用用户数据训练模型（部分商业API有此条款）

工程维度——系统集成层面：

• API稳定性：服务可用性SLA，历史故障频率
• 上下文窗口大小：影响多轮对话历史和长文档的处理能力
• 并发限制：API的并发请求上限，高峰期是否会触发限流
• 静默更新风险（闭源API特有）：服务商在不通知的情况下更新模型，导致系统行为变化

场景取舍：

成本路由策略：不是所有问题都需要最强的模型。实践中常见的做法是将问题按复杂度分层，简单问题（单跳事实查询、格式化信息提取）交给轻量模型，复杂问题（多步推理、政策组合判断）交给大模型。这种分层策略可以显著降低整体成本，但引入了路由判断的额外复杂度，需要在系统稳定后再考虑引入。

AI PM与算法协作：合规维度由PM/法务主导，是硬性过滤条件，在此之前算法评估没有意义；质量维度的评估需要PM参与提供业务场景测试用例，不能只用通用benchmark；成本维度是PM和算法共同核算的，PM提供预算约束，算法核算技术方案的成本；工程维度由算法主导评估。

关于Fine-tuning（模型微调）：算法团队有时会提议对基础模型做Fine-tuning来提升领域表现。在智能客服场景中，随着基础大模型能力的持续增强，目前业界的普遍实践倾向是纯RAG方案在大多数场景下已经足够，Fine-tuning的必要性显著降低（作者判断，供参考）。Fine-tuning更适合以下特定情况：需要固化特定输出格式或语气风格（Prompt难以稳定控制）、特定领域术语的理解一致性要求极高、以及对推理延迟有极致要求需要用小模型替代大模型的场景。Fine-tuning不能替代RAG——微调改善的是模型的行为模式，而不是知识更新问题，知识仍然需要RAG来动态注入。Fine-tuning的完整流程（数据准备、训练、评估、部署）不在本文范围内。

---

4.2 Prompt工程

系统Prompt（System Prompt）是控制模型行为的主要手段，也是PM可以直接参与设计的核心环节之一。本节专指主模型的System Prompt设计——意图识别、查询改写、摘要压缩等其他节点同样需要Prompt，但那些Prompt的设计主要是算法实现细节，不需要PM深度介入。一个完整的客服系统Prompt通常包含：角色定义（"你是XX公司的客服助手，只回答与XX产品相关的问题"）、行为约束（不得承诺退款、不得回答竞品相关问题、知识库中没有的信息必须告知用户而不是猜测）、检索结果注入格式（规定文档如何呈现给模型）、输出格式控制（回答长度、是否引用来源）。

评估维度：

• 约束遵守率：模型在多大比例的情况下严格遵守了系统Prompt中的行为约束，尤其是禁止性约束
• 格式一致性：输出格式是否稳定，不会在某些输入下突然改变结构
• Few-shot效果：加入示范问答对后，模型输出风格与示范的对齐程度

AI PM与算法协作：Prompt的设计是PM可以深度参与的环节——业务约束的定义（"什么不能说"）、品牌语气的把握、输出格式的需求，都是产品侧的判断，不是技术判断。Prompt版本需要和代码一样做版本管理，任何改动都需要在评估集上验证，不能直接上线。

---

4.3 幻觉控制

幻觉是LLM在没有依据的情况下生成听起来合理但实际错误的信息，在客服场景中代价直接。幻觉控制是一个跨层机制：检索层的召回质量直接影响幻觉概率（召回了错误文档，生成层再好也无力回天），生成层的Prompt约束和输出验证是主要的控制手段。本节从生成层视角讲控制手段，检索质量对幻觉的影响见第三章。

真实案例：2024年2月，加拿大卑诗省民事解决裁判所裁定，加拿大航空因其客服机器人错误告知乘客可在购票后90天内追溯申请丧亲优惠票价（实际政策要求购票前申请），被判赔偿812.02加元。裁判所驳回了Air Canada"机器人是独立法律实体"的辩护，裁定（译自英文裁决原文）"公司对其网站上所有信息负责，无论信息来自静态页面还是聊天机器人"。这一判决确立了企业对AI客服输出承担法律责任的先例，也说明幻觉不只是技术问题，而是业务风险。

幻觉控制需要在输入侧（预防）和输出侧（检测）双管齐下：

输入侧（在生成层触发之前执行）：强制引用约束（Prompt中明确"只能基于知识库内容回答，没有依据则告知用户无法回答"）；检索质量保障（幻觉的根源之一是检索失败，模型只好猜测）；置信度阈值（检索相关性低于阈值时直接返回"未找到相关信息"，不进入生成环节）。

输出侧：引用一致性验证（检查回答中的关键表述是否能在召回文档中找到对应依据）；关键词黑名单（绝对不能出现的表述用规则过滤，比LLM判断更可靠）。

评估维度：

• Faithfulness（忠实度）：回答中每个陈述有多少比例能在检索文档中找到依据，核心的幻觉检测指标（对应RAGAS框架的Faithfulness指标，见6.1节）
• 拒答率：当问题超出知识库范围时，系统选择"告知无法回答"而非猜测的比例
• 约束违反率：系统Prompt中的禁止性约束被违反的频率

场景取舍：

AI PM与算法协作：幻觉的业务影响由PM评估（什么类型的错误会带来法律风险或直接客诉），幻觉的技术检测和缓解由算法主导。PM需要定义哪些类别的幻觉是"高危"（如金额承诺、政策误读），哪些是"可接受"（如语气措辞的细微差异），对应不同的处理优先级。

---

生成层协作要点

生成层是PM参与度最高的一层。Prompt设计、约束定义、幻觉风险的业务影响评估，都需要PM主导。算法负责技术实现和量化评估，但"什么样的回答是好的回答"这个判断标准，只有PM能定义清楚。

---

---

五、对话管理层：怎么管理一次完整对话

5.1 上下文窗口管理

多轮对话中，每次调用LLM都需要携带历史对话记录。对话轮数增加会带来两个问题：超出上下文窗口上限，以及成本随token数线性增长。

主要策略及评估维度：

滑动窗口：只保留最近N轮。简单，但会丢失早期重要信息（如用户在第1轮提供的订单号到第10轮可能已被截断）。评估维度：关键信息保留率（早期提供的关键实体在多轮后是否还在上下文中）。

摘要压缩：定期用LLM将历史对话压缩成摘要。保留信息，但引入额外调用延迟，且摘要本身有信息损失风险。评估维度：摘要后的信息完整度（关键实体、问题背景是否被保留）。

关键信息提取（Entity Memory）：从对话中提取关键实体（订单号、用户姓名、问题类型）存为结构化记忆，始终携带，解决滑动窗口丢失早期关键信息的问题，通常与滑动窗口配合使用。评估维度：实体提取准确率和覆盖率。

场景取舍：

---

5.2 多轮对话状态管理

多轮对话的挑战不只是上下文窗口，还涉及：

Session管理：每次完整对话有唯一session ID，所有轮次记录与此绑定，支持会话历史回溯和问题复现。

指代消解：用户说"它的保修期是多少"中的"它"指代什么，需要在检索前解析（通常由查询改写环节处理）。

话题切换检测：用户在同一对话中从询问A产品切换到B产品时，需要适当降权旧话题的上下文，避免混淆。

评估维度：关键实体跨轮保留率、话题切换检测准确率、指代消解准确率。

---

5.3 人工接管触发机制

人工接管是客服系统的安全阀。触发条件建议同时实现：置信度不足（系统判断无法给出可靠回答）、情绪识别（用户表达强烈负面情绪）、问题循环检测（同一问题被追问超过N次）、高风险场景（大额退款、账户安全、法律纠纷）、用户主动请求（无条件响应）。

评估维度：

• 该转未转率：应该触发人工但没有触发的比例，这是最严重的失误，直接影响用户体验
• 误转率：系统能处理但错误地转人工的比例，影响人工客服成本
• 转接后解决率：转人工后问题是否被解决，如果转完还没解决，说明问题可能不在系统而在流程

场景取舍：

AI PM与算法协作：触发阈值是业务决策，PM主导。算法提供各触发条件的置信度分数，PM决定阈值设在哪里——这个设定直接影响人工成本和用户满意度之间的平衡，是典型的需要PM持续监控和调整的指标。

---

对话管理层协作要点

---

六、评估层：怎么知道系统够不够好

6.1 离线评估指标体系（RAGAS框架）

前五层描述的是系统的构建方式，但系统搭好不等于系统好用——评估层解决的是"怎么知道够不够好"的问题。评估是构建可靠LLM系统最容易被低估也最容易被跳过的环节。没有评估体系就没有迭代方向，只能靠直觉猜系统好不好。

RAGAS（RAG Assessment）框架是目前最常用的RAG离线评估框架，四个核心指标分别对应不同的失效模式：

这四个指标指向不同的优化方向，也直接对应前面各层的技术决策：

这个映射关系是RAGAS指标从"数字"变成"行动"的关键桥梁——单看指标分数没有意义，必须对应到具体的技术层才能驱动改进。

评估集的构建：RAGAS需要"Golden Dataset"——人工标注的"问题-正确答案-相关文档"三元组。构建成本高，但没有它就无法做有意义的量化评估。实践建议：从生产日志中抽样100-300条，人工标注，形成初始评估集，后续随业务迭代持续扩充（每次发现重要badcase都加入评估集）。

AI PM与算法协作：评估集的构建是PM不可缺席的工作——哪些问题有代表性、正确答案应该是什么，算法无法独立判断。PM参与标注的比例越高，评估集的业务相关性越强。

---

6.2 在线评估与A/B测试

离线评估是静态快照，无法替代真实用户的反馈。

用户反馈信号（应从第一天起收集）：显式反馈（"有帮助/没有帮助"按钮，收集率有限但信号质量高）；隐式反馈（用户是否追问同一问题、是否触发人工转接、会话完成率）。隐式信号量大但有歧义，需要结合多个信号综合判断。

A/B测试：修改系统某个环节后（更换Reranker、调整Prompt），通过流量分割量化变更效果，而不是依赖直觉。北极星指标建议是"用户在不转人工的情况下问题得到解决的比率"，而不是单纯的点赞率（用户可能对流利的错误回答点赞）。

AI PM与算法协作：A/B测试的指标定义和显著性判断标准由PM主导（需要多少样本、提升多少才算显著），流量分割和统计分析由算法执行。PM需要明确"什么改变值得做A/B测试"——不是每次调整都需要，小改动可以直接上线观察，大改动和关键路径的修改必须走A/B。

---

6.3 持续监控与漂移检测

系统上线后，质量不是静态的。三类主要漂移来源：

知识库漂移：业务规则更新但知识库未同步，系统基于旧知识给出过时回答（Air Canada案例的本质原因）。应对：建立知识库更新触发机制，任何业务变更文档入库后，自动触发相关评估集重新跑分。

模型漂移：使用闭源API时，服务商静默更新模型，导致系统行为变化。应对：在固定评估集上定期（每周）跑基准测试，捕捉异常分数变化。

分布漂移：用户提问模式随时间变化（新功能上线带来新类型问题）。监控：追踪拒答率和意图分类置信度分布，出现明显变化时人工审查。

---

评估层协作要点

评估层与迭代闭环层的关系：评估层提供的RAGAS指标和在线信号，是第七章迭代闭环层badcase归因的量化输入——Context Recall持续偏低触发检索层归因，Faithfulness异常触发生成层归因，拒答率上升触发知识库覆盖度审查。评估层是"发现问题的仪表盘"，迭代闭环层是"修复问题的操作流程"，两者共同构成系统持续改进的完整闭环。

---

七、工程层：怎么让系统跑得起来

7.1 延迟优化

生产标准通常要求首token时延（TTFT）的p90低于2秒。一次完整RAG+生成请求的延迟来源分布在各环节（query embedding约20-50ms、向量检索约5-20ms、Reranker约50-200ms、LLM首token约200-800ms），优化需要针对瓶颈环节。

核心优化手段及评估维度：

Streaming输出：LLM生成时逐token流式输出，用户感知的等待时间从"完整回答生成完毕"变为"第一个字出现"，体感大幅改善。评估维度：TTFT（首token时延），而不是完整响应时间。几乎所有生产系统都应默认启用Streaming输出。

语义缓存：对语义相近的问题复用已有回答，而不是每次重走完整检索+生成流程。评估维度：缓存命中率、命中情况下的响应延迟、误命中率（语义相近但正确答案不同的问题被错误复用）。据生产数据，语义缓存可将LLM API成本降低约68.8%。需要注意知识库更新时相关缓存要主动清除。

并行执行：向量检索和BM25检索并行执行，而不是串行；意图识别和query embedding并行执行。评估维度：并行化后的总耗时相比串行的压缩比。

场景取舍：

---

7.2 数据安全与权限管控

检索时权限过滤：在向量数据库查询时，加入基于用户角色的过滤条件，确保只召回该用户有权限访问的文档。这是成本最低也最可靠的权限控制方式，权限逻辑在数据层实现，不依赖LLM判断。

Prompt注入防护：恶意用户可能构造特殊输入诱导LLM泄露系统Prompt或绕过约束（Prompt Injection攻击）。防护：系统Prompt中明确指令拒绝此类请求、对用户输入做内容过滤、不在系统Prompt中存放敏感信息。

PII脱敏：用户输入中的个人身份信息（手机号、身份证号）在送入LLM前应识别并替换为占位符，避免第三方API接触用户隐私。

评估维度：权限绕过测试通过率（模拟恶意输入后，系统是否正确拦截）、PII脱敏覆盖率、Prompt注入成功率（攻击测试中的防护成功比例）。

---

7.3 可观测性与成本监控

链路追踪：每次请求的完整调用链（query→检索→改写→生成→输出）应被记录，包含每个环节的输入输出、耗时、token用量。这是排查问题（"为什么这个问题的回答不对"）的必要基础。主流工具：LangSmith（LangChain生态）、LangFuse（开源，更灵活）。

核心监控指标：

• 延迟：TTFT p50/p90/p99，完整响应时间
• 成功率：请求失败率（API超时、context exceeded等）
• 成本：每请求token用量，日/月总费用，成本异常告警
• 质量代理指标：Thumbs down率、转人工率、会话完成率、拒答率
• 安全指标：Prompt注入尝试次数、权限绕过尝试次数

AI PM与算法协作：监控指标的定义和告警阈值由PM和算法共同决定。PM关注质量代理指标和成本，算法关注技术性指标（延迟、失败率）。关键是建立"指标异常→问题归因→修复"的响应机制，而不是只有监控没有行动。

---

工程层协作要点

---

八、迭代闭环层：系统怎么持续变好

这是整个链路中最容易被忽视、但对系统长期质量影响最大的一层。一个没有迭代闭环的LLM系统，质量会随时间衰减而不是提升。这也是AI PM在整个技术栈中参与度最高、最难被替代的环节。

8.1 Badcase发现与归因

Badcase是指系统给出了不符合预期的回答。发现渠道包括：用户的显式负反馈（Thumbs down）、触发人工接管后客服人员标记的问题、定期的人工抽检、自动化的Faithfulness评分异常告警。

归因决策树：发现badcase后，需要沿链路逐层定位根因，不同的根因对应不同的修复动作。

Badcase现象
  │
  ├─ 回答内容有误/有幻觉
  │    ├─ 检索到的文档是正确的 → 根因在生成层（Prompt约束不足/模型能力问题）
  │    └─ 检索到的文档是错误/过时的
  │         ├─ 知识库中有正确答案 → 根因在检索层（召回失败/排序错误）
  │         └─ 知识库中没有正确答案 → 根因在数据层（知识库缺失/未更新）
  │
  ├─ 回答答非所问
  │    ├─ query含指代词/表达不清 → 根因在查询改写层
  │    └─ 意图判断错误，走了错误路径 → 根因在意图路由层
  │
  ├─ 回答正确但格式/语气不符合要求 → 根因在Prompt工程
  │
  └─ 系统拒答（但应该能回答）
       ├─ 知识库中有答案但未被召回 → 根因在检索层
       └─ 置信度阈值设置过严 → 根因在阈值配置

AI PM与算法协作：PM负责badcase的业务影响评级（这个错误是高危还是低危），决定修复优先级；算法负责技术归因（具体在哪一层出了问题）。这个分工很重要——算法判断不了"哪个错误更严重"，PM判断不了"哪一层出了问题"，需要真正协作。

---

8.2 评估数据集的构建与维护

评估数据集（Golden Dataset）是系统迭代的基础设施，没有它就无法量化任何改进。它的质量决定了整个评估体系的可信度。

构建原则：

• 代表性：覆盖真实用户问题的分布，不能只收集容易回答的问题。从生产日志中随机抽样比人工设计的题目更有代表性
• 覆盖性：包含各类意图（知识查询、数据查询、边界场景、刁难型问题）和各类难度
• 持续扩充：每次出现重要badcase，应将其加入评估集。评估集应该随系统上线时间增长而增长
• 版本管理：评估集本身需要版本管理，确保不同时间点的评估结果可对比

评估维度：

• 评估集覆盖率：评估集中的问题类型分布是否与生产流量分布一致
• 标注一致性：多人标注同一问题的答案，一致率是否足够高（低一致率说明标注标准不清晰）
• 评估集新鲜度：评估集中的问题和答案是否还反映当前业务状态（知识库更新后，旧的Golden Answer可能已经过时）

AI PM与算法协作：评估集的构建是PM必须深度参与的工作，无法完全委托给算法。PM负责：确认哪些问题有代表性、提供或审核正确答案（业务知识）、定义评估标准（什么样的回答算"正确"）。算法负责：评估集的自动化运行、指标计算、结果分析。

---

8.3 数据飞轮：从用户反馈到系统迭代

数据飞轮是指用户使用系统产生的数据，经过处理后反过来改善系统质量的正向循环。这是LLM系统区别于传统软件系统最重要的特性之一——系统应该越用越好，而不是上线后就静止。

用户使用系统
     │
     ▼
收集反馈信号（显式/隐式）
     │
     ▼
Badcase筛选与归因
     │
     ├──→ 知识库缺失 ──→ 补充文档入库 ──→ 重新embedding入向量库
     │
     ├──→ 检索问题 ──→ 调整Chunking/检索策略 ──→ 重新评估
     │
     ├──→ 生成问题 ──→ 优化Prompt/更换模型 ──→ 重新评估
     │
     └──→ 加入评估数据集 ──→ 评估集扩充 ──→ 下次迭代基准更准确
     │
     ▼
系统质量提升 → 更少Badcase → 飞轮加速

让飞轮转起来的关键条件：

• 反馈信号的可操作性：收集到的反馈要能被归因到具体的技术层，否则反馈是死数据
• 归因到修复的响应速度：从发现问题到修复上线的周期越短，飞轮转得越快
• 修复的系统化而非个案化：不是每个badcase都单独修复，而是找到共性根因，做系统性改进
• 评估集同步更新：每次修复后，评估集要同步加入该类badcase，确保不退化

从Badcase到安全上线的完整流程：

发现和归因只是第一步，修复能否安全上线需要经过完整的验证链路：

① Badcase确认与优先级评级（PM）
         ↓
② 技术归因，制定修复方案（算法）
         ↓
③ 隔离环境验证
   - 目标badcase是否已解决？
   - 是否引入新的badcase？
         ↓
④ 回归测试（防退化）
   - 在完整评估集上跑分
   - 确认修复前正确的case，修复后仍然正确
   - 关键指标（Faithfulness、召回率等）不低于修复前基线
         ↓
⑤ 灰度上线（小流量，如5%-10%）
   - 观察线上质量代理指标：Thumbs down率、转人工率、拒答率
   - 观察工程指标：延迟、成功率
   - 时间窗口：通常观察24-72小时，覆盖工作日+非工作日的流量模式
         ↓
⑥ 全量上线
   - 灰度期间无异常，指标稳定后扩量
   - 若灰度期间触发以下任一条件，立即回滚并排查：
     · Thumbs down率相比对照组上升超过20%
     · 转人工率相比对照组上升超过15%
     · 拒答率相比对照组上升超过10%
     · 请求失败率（API错误）超过1%
   - 具体阈值需根据业务基线设定，以上为参考量级，不是通用标准
         ↓
⑦ 上线后观察期
   - 全量后继续监控3-7天
   - 将本次修复覆盖的badcase类型加入评估集，作为后续的防退化基准

回归测试的核心原则：每次修复一个问题，都可能在其他场景引入新问题，这在LLM系统中尤为常见——调整Prompt修复了A类问题，可能导致B类问题的指令遵循变差。评估集的价值之一正是作为"防退化基准线"：只要修复后的评估集分数不低于修复前，就可以认为没有引入系统性退化。这也是评估集持续扩充的重要原因——覆盖越全面，防退化的保护就越完整。

场景取舍：

AI PM在飞轮中的核心角色：PM是飞轮的"编辑"——决定哪些反馈值得投入修复资源、哪些badcase代表的问题需要优先处理、飞轮的每一圈应该重点改善哪个环节。算法是飞轮的"执行"——完成技术归因和修复实施。没有PM的优先级判断，飞轮会退化成"什么都改一点，什么都没有显著改善"；没有算法的技术执行，PM的判断只是纸上谈兵。

---

总结：AI PM的决策地图

理解这张地图的核心价值在于：每一层都有PM无法缺席的判断，也有PM不需要深入的技术细节。"共同决策"这一列尤其值得关注——这些决策既需要业务判断也需要技术可行性评估，是PM和算法最容易产生分歧、也最需要真正坐在一起讨论的地方。PM的工作不是替代算法做技术决策，而是确保技术决策服务于正确的业务目标。

---

参考资料

一手文件 / 官方发布

• RAGAS官方文档 — RAG评估框架
• MTEB排行榜 — Embedding模型通用评估榜单
• pgvector GitHub — PostgreSQL向量扩展
• BGE-Reranker-v2-m3 HuggingFace — BAAI开源重排序模型

法律案例

• Moffatt v. Air Canada, 2024 BCCRT 149（AI Business报道） — AI客服幻觉的法律责任先例；原始裁定文件见卑诗省民事解决裁判所（2024 BCCRT 149）
• McCarthy Tétrault法律分析 — 加拿大律所对该裁决法律意义的专业解读

学术研究（同行评审或接近同行评审）

• Chunking Strategies and Embeddings for RAG — NAACL 2025会议论文的Substack综述（注：本文引用的为该Substack转述，非原始论文；原始论文为NAACL 2025会议收录，已经同行评审）

工具厂商数据（官方声称，未经独立验证）

• RAG at Scale: How to Build Production AI Systems in 2026 — Redis官方博客；语义缓存降本68.8%、TTFT p90标准等数据为Redis官方声称，未经独立第三方验证

行业博客 / 分析文章（非同行评审，供参考）

• RAG Pipelines in Production: Vector Database Benchmarks — dev.to社区文章，混合检索召回率对比数据；来源为社区博客，非独立研究
• Open Source vs Closed LLMs: The 2026 Decision Framework — 开源vs闭源LLM选型框架；行业博客，框架性参考价值高于具体数据

工具文档

• Unstructured.io、LlamaParse、Apache Tika — 文档解析
• LangSmith、LangFuse — LLM链路追踪
• Cohere Rerank API、Jina Reranker — 商业重排序API

---

本文以智能客服为载体，梳理LLM应用的完整技术链路。文中涉及的具体数字来自引用研究，实际效果因业务场景和数据特性不同会有差异。评估维度和框架具有较高的跨场景复用性，具体指标阈值建议在自有数据集上验证后再应用。