1. 从概念到落地：为什么Claude能处理95%的查询？

最近和几个做AI产品落地的朋友聊天，大家普遍有个共识：把一个大模型Demo跑起来，和把它真正塞进一个每天处理百万级请求的生产系统，完全是两码事。前者像是搭了个乐高模型，后者则像是在运营一座需要24小时供电、供水、排污，还得应对早晚高峰的现代化城市。所以，当我看到Anthropic宣称他们用Claude处理了95%的客服查询时，我的第一反应不是“哇，好厉害”，而是“他们到底是怎么做到的？”。这背后绝不仅仅是模型能力的问题，更是一整套工程化、产品化和运营策略的胜利。

这个“95%”的数字，听起来很美好，但它背后隐藏着几个关键问题：第一，这95%的查询具体是什么？是简单的FAQ，还是包含了复杂意图识别的多轮对话？第二，剩下的5%去了哪里？是直接转人工了，还是进入了某种“待处理”队列？第三，也是最重要的，为了达到这个比例，他们在产品设计、流程编排和模型调优上做了哪些取舍和努力？这绝不是把Claude的API接上就能自动实现的结果。今天，我就结合自己在大模型落地项目中的一些踩坑经验，来拆解一下这个“95%”背后可能的技术与产品逻辑。你会发现，真正的挑战往往不在模型本身，而在那些模型之外、却又决定成败的细节里。

2. 拆解“查询”：定义Claude的能力边界与处理范围

要理解95%这个数字，首先得定义清楚“查询”是什么。在客服场景下，用户的输入千差万别，从“我的订单号123456发货了吗？”到“你们这个产品的设计理念是不是抄袭了某某品牌？”，复杂度天差地别。Anthropic的Claude不可能，也不需要处理所有类型的问题。因此，第一步必然是进行精准的“问题分类”和“意图识别”，这是整个流程的闸门。

2.1 意图识别：第一道也是最重要的过滤网

在实际系统中，用户的问题进来后，首先会经过一个轻量级的、专门训练的分类模型（可能是小模型或规则引擎）。这个模型的任务不是回答问题，而是快速判断：“这个问题Claude能处理吗？” 这里就涉及到一个核心的产品决策：哪些问题划归Claude，哪些问题需要路由到其他渠道。

根据常见的客服场景，Claude likely擅长处理以下几类：

• 信息查询类：订单状态、物流跟踪、产品规格、价格咨询、营业时间等。这类问题有明确答案，且数据通常结构化或半结构化，易于从知识库中检索。
• 简单事务处理类：重置密码、修改个人信息、申请退换货（标准流程内）、订阅/取消订阅等。这类操作有固定流程，Claude可以通过调用内部API或提供明确的指引链接来完成。
• 常见问题解答（FAQ）：关于政策、流程、功能的解释性内容。这里的关键是知识库的构建和维护，确保Claude检索到的信息是最新且准确的。
• 轻度多轮对话：例如，用户先问“推荐一款笔记本电脑”，Claude给出几个选项后，用户再追问“第一款和第三款的显卡区别是什么？”。这要求模型具备一定的上下文理解和连贯对话能力。

那么，哪些问题会被排除在这95%之外，归入那关键的5%呢？

• 高度敏感或涉及重大利益：如投诉、索赔、法律纠纷、涉及大额资金的操作。这类问题容错率极低，且需要人类的情感判断和法律知识，必须转人工。
• 极度模糊或信息不全：用户只说“我有个问题”或发一张模糊的图片。Claude可能需要引导用户澄清，但如果多次引导失败，也应转人工。
• 需要深度创意或主观判断：比如“为我的新产品写一首上市宣传诗”（虽然Claude能写，但质量是否符合品牌调性需人审）、“评价一下我们竞争对手的最新战略”。这类输出需要人类把关。
• 系统已知的Claude弱项或盲区：通过持续的bad case分析，会发现模型在某些特定领域（如极其冷门的产品代码、未被录入知识库的内部流程）表现不稳定。这些领域会被加入“屏蔽列表”，直接路由。

所以，这个95%首先是一个产品定义的结果。通过精心设计的意图识别和路由规则，确保流入Claude的问题池，是其最擅长、风险也相对可控的。这就像给Claude划定了一个“安全作战区”。

2.2 知识库与实时数据：让Claude“有据可依”

光有意图识别还不够。Claude再聪明，它也无法知道“订单A123456的快递员小王今天下午3点是否派件失败”。它的知识有截止日期，且不包含企业的私有动态数据。因此，一个强大的检索增强生成（RAG）系统是必不可少的后台支撑。

当Claude判定一个问题属于“信息查询类”时，它不会仅凭自己的内部知识来回答。系统会首先将该问题转化为一个或多个搜索查询（Query），去实时检索企业的内部知识库、帮助文档、产品数据库，甚至是调用订单查询API获取实时状态。然后，Claude的职责是理解这些检索到的碎片化信息，并组织成一段连贯、准确、友好的回复。

注意：这里有一个巨大的坑。很多团队以为接上向量数据库就完成了RAG。实际上，检索的准确性直接决定了最终回答的质量。如果知识库文档本身过时、矛盾或格式混乱，或者检索策略不好（比如返回了10篇相关文档但没找到最关键的那一句），Claude再强也会“巧妇难为无米之炊”，甚至可能基于错误信息进行“幻觉”编造。因此，知识库的治理（定期更新、去重、标注关键信息）和检索策略的调优（结合关键词、向量、元数据过滤），其重要性不亚于模型本身。

3. 工程架构：支撑高并发与稳定性的“隐形引擎”

处理95%的查询，意味着Claude需要融入一个高可用、低延迟、可扩展的在线服务架构。这绝对不是直接调用OpenAI或Anthropic的API端点那么简单。让我们看看一个生产级系统可能包含的组件。

3.1 请求处理流水线：从用户输入到AI回复

一个典型的请求会经历如下管道：

1. 接入与预处理：用户请求通过API网关进入。首先进行基础的安全校验（防刷、鉴权）、输入清洗（去除乱码、处理超长文本）和标准化。
2. 意图识别与路由：如上节所述，通过分类模型进行快速判断。这里可能采用规则（关键词匹配）+ 轻量级模型（如Fine-tune过的BERT）结合的方式，在精度和速度间取得平衡。
3. 上下文管理与会话：如果是多轮对话，系统需要维护会话状态。这包括记住之前的对话历史、用户身份信息、以及在本会话中已执行过的操作（如已查询过的订单号）。这些信息会作为“上下文”注入给Claude，使其能进行连贯对话。这里的关键是上下文窗口的优化，不能无脑地把所有历史记录都塞进去，需要做摘要或选择性保留，以节省token并聚焦重点。
4. 工具调用与知识检索：对于需要查数据或执行操作的问题，Claude需要具备“使用工具”的能力。这通常通过“Function Calling”或“Tool Use”来实现。系统会定义好一套工具（如get_order_status(order_id),search_knowledge_base(query)），并在提示词中告诉Claude这些工具的用途和调用格式。当Claude认为需要时，它会输出一个结构化的调用请求，由后端系统执行该工具，并将结果返回给Claude，Claude再据此生成最终回复。
5. 生成与后处理：Claude生成原始回复。后端可能需要对回复进行后处理，例如：过滤掉模型可能不小心泄露的内部系统提示词、对特定格式（如订单号、日期）进行标准化渲染、添加免责声明或转人工的入口。
6. 输出与日志：将最终回复返回给用户。同时，完整记录本次交互的输入、输出、中间步骤（意图分类结果、调用的工具、检索到的文档）、耗时、token使用量以及用户满意度信号（如有）。这些日志是后续优化最重要的燃料。

3.2 性能、成本与稳定性的三角平衡

处理海量查询，必须直面三个现实问题：

• 延迟：用户能忍受多长的等待时间？通常，客服场景下，3-5秒内的回复是可接受的。这意味着从请求进来到回复出去，整个管道（包括网络传输、模型推理、检索、工具调用）必须在这个时间窗内完成。对于复杂问题，可能需要采用“流式输出”先返回部分内容，或者设置超时机制，超时后降级为返回一个“正在查询，请稍候”的提示。
• 成本：Claude API是按token收费的。95%的查询都使用它，成本会非常可观。优化策略包括：
  • 缓存：对高频、答案固定的FAQ类问题，将Claude生成的优质回答缓存起来，下次同样问题直接返回缓存，绕过模型调用。
  • 上下文压缩：精心设计提示词，减少不必要的上下文token。对历史对话进行智能摘要，而非全文传递。
  • 模型阶梯：并非所有问题都需要动用最强的Claude Opus。可以设计一个“模型路由”层，简单问题用更便宜、更快的Claude Haiku或Sonnet，复杂问题再用Opus。这需要对问题复杂度有准确的预判。
• 稳定性：API服务可能有波动，模型输出也可能偶尔出现极端情况。工程上需要有降级、熔断和重试机制。例如，当Claude API连续失败数次，系统应能自动切换到备用的规则引擎或简单模型，至少保证用户能收到一个“服务暂时繁忙”的友好提示，而不是一个HTTP 500错误。

4. 持续迭代：从“能用”到“好用”的飞轮

达到95%的覆盖率只是一个起点，更重要的是保持这95%的解决率和用户满意度。这依赖于一个强大的持续迭代闭环。

4.1 数据飞轮：Bad Case是宝藏

所有未能被Claude妥善处理（无论是错误回答、未解决用户问题，还是用户主动不满意）的对话，都会流入一个“bad case池”。运营和AI训练团队需要定期（例如每天）审查这些案例。这个过程不是简单的删除，而是深度分析：

• 根因分类：是意图识别错了？（该转人工的给了Claude）。是知识库没数据？（该查到的没查到）。是检索策略不好？（查到了但不是最相关的）。是模型理解有偏差？还是工具调用失败了？
• 针对性修复：
  • 如果是意图识别问题，就收集更多此类case，去优化分类模型的训练数据。
  • 如果是知识缺失，就补充或更新知识库文档。
  • 如果是检索问题，就调整检索算法的参数或引入新的元数据过滤条件。
  • 如果是模型对某类问题总是“幻觉”，可以考虑针对这类问题收集高质量问答对，对模型进行特定领域的微调（Fine-tuning），或者设计更精准的提示词模板。
• 回归测试：修复后，需要将之前出错的case以及类似的新case组成测试集，验证修复是否有效，确保不会引入新的问题。

4.2 提示词工程与评估：模型的“隐形指挥棒”

提示词（Prompt）是引导Claude行为的关键。一个生产系统不会只有一段固定的提示词，而是会有一个“提示词库”，针对不同的意图和场景，使用不同的提示词模板。例如，“处理投诉”的提示词和“查询订单”的提示词，在语气、谨慎程度和可执行操作上会有巨大差异。

如何评估提示词的好坏？不能靠人工一个个看。需要建立自动化的评估体系：

• 基于规则的评估：检查回复中是否包含了必备元素（如订单号、链接）、是否避免了禁用词。
• 基于模型的评估：用另一个轻量级模型（如裁判员模型）来评估回复的相关性、有用性、安全性。
• 人工抽样评估：定期由标注人员对抽样对话进行打分（1-5分），这是黄金标准。 通过A/B测试，对比不同提示词模板在相同流量下的核心指标（解决率、满意度、平均对话轮次）的变化，从而科学地迭代提示词。

4.3 人的价值：那5%与监督者的角色

最后，我们必须正视那5%。这5%不是失败，而是系统设计上的明智留白。它们是最复杂、最敏感、最需要人类智慧、共情和判断力的问题。高效的人工坐席后台应该能清晰地看到这些被路由过来的问题，以及Claude在处理过程中产生的所有中间信息（用户历史、检索到的文档、模型犹豫的原因等），从而快速接手，提供高质量的服务。

同时，人类还扮演着“AI监督员”和“训练师”的角色。通过处理bad case、标注优质数据、调整知识库，人类在持续地教导和优化Claude系统。这是一个“AI处理常规，人类处理异常并优化AI”的共生循环。

5. 实战中的坑与经验：那些文档里不会写的事

说了这么多理论，结合我自己和同行们趟过的坑，分享几点最实在的经验：

5.1 不要追求100%的自动化

这是心态上首先要调整的。目标是提升效率、覆盖大部分场景，而不是完全取代人。强求100%只会导致两个结果：要么系统过于保守（大量简单问题也转人工），要么风险失控（把不该处理的问题处理错了，造成损失）。坦然接受那5%，并把它设计成流畅的人工交接流程，整个系统反而更健壮。

5.2 监控指标比模型指标更重要

在研发阶段，我们关注模型的BLEU、ROUGE分数。但在生产阶段，这些几乎没用。你需要关注的是业务指标：

• 首轮解决率：用户第一个问题就被完美解决的比例。
• 对话轮次：平均需要多少轮对话才能解决一个问题？轮次越少，效率越高。
• 转人工率：多少比例的问题最终需要人工介入？这直接关联成本和用户体验。
• 用户满意度（CSAT）：通过对话结束后的评分或表情反馈收集。
• 成本与延迟：每日token消耗、API调用费用、P95/P99延迟。 建立这些指标的实时仪表盘，设置告警（如转人工率突然飙升），你才能知道系统真实运行的好坏。

5.3 安全与合规是高压线

大模型会“胡说八道”（幻觉），也可能被恶意引导（Prompt注入）说出不该说的话。在客服场景，这可能导致泄露用户隐私、承诺无法兑现的服务、甚至发表不当言论。必须建立多层防线：

• 输入过滤：在请求到达模型前，过滤明显的恶意、攻击性或包含个人敏感信息（如完整信用卡号）的输入。
• 系统提示词约束：在给模型的系统指令中，必须明确、强硬地规定其角色、边界和禁止事项。
• 输出审查：对模型的回复进行二次扫描，检查是否有泄露内部信息、生成有害内容或做出越权承诺。
• 审计日志：所有交互必须全程留痕，可追溯，以满足合规要求。

5.4 从“单点模型”到“系统工程”的思维转变

最大的挑战往往不是技术，而是思维。很多团队一开始把所有精力都放在调优模型本身上，忽略了意图识别、知识库、工具调用、评估体系这些“配套设施”。结果就是模型本身可能拿了很高的测试分数，但一上线就发现用户体验很差，因为问题分类错了，或者查不到数据。必须从一开始就以“系统工程”的视角来设计，把Claude看作这个智能管道中的一个核心但非唯一的组件。

回到最初的问题，Anthropic的“95%”更像是一个结果，而这个结果是精准的场景定义、健壮的工程架构、持续的数据迭代和务实的产品策略共同作用的产物。它告诉我们，大模型落地的成功，功夫在诗外。对于想要复现类似效果的技术团队和产品经理来说，与其纠结于哪个模型参数多、分数高，不如沉下心来，先把你的“查询”定义清楚，把知识库整理好，把意图识别的管道搭稳固，并设计好一个包含人类在内的、完整的服务闭环。这条路没有捷径，但每一步都算数。