2026/8/31 11:22:55
FEATURED · 精选文章 
一条技术消息最近值得关注Decagon 接入 Perplexity 的实时搜索服务方向明确对准大客户。初看只是一条合作新闻但放在 AI 客服落地的背景里它指向一个长期被绕开的问题AI 客服最尴尬的时刻往往就是它需要最新信息的时刻。Decagon 做的是面向企业的 AI 客户支持平台把工单、会话、知识库整合进同一个 AI 工作流。Perplexity 主打 AI 搜索特点是能实时检索互联网公开信息并把答案和来源一起返回。两者结合表面上是“客服机器人终于可以联网找答案了”。但真正做过知识问答产品的人会知道从“能搜”到“敢用”中间隔着权限、时效、引用、延迟、成本、责任六道坎。这篇不打算复述新闻而是想把这类合作背后的工程逻辑拆开看。先解释这次接入解决的核心问题再讲落地中普遍会遇到的四类工程问题然后给出一条自建接入的参考路径最后把适用边界说清楚。1. 先理解 Decagon 这次接入到底接入的是什么1.1 三个关键词分开看才能看清合作的性质Decagon 不是一家普通的聊天机器人公司。从产品定位看它面向的是企业客户支持场景做的是一整套客服自动化平台用户进来之后AI 要能判断意图、读取工单、调用知识库、给出解决方案甚至在必要时创建售后单或升级到人工。这意味着它的技术栈不只是“大模型生成回复”还包含工单路由、客户数据读取、解决率统计这些东西。Perplexity 则更特殊。它做的不是传统搜索引擎的“给链接”而是“给答案”用户输入问题它实时检索互联网把最有可能是答案的内容组织成一段话并附上来源链接。这个模式从消费端产品逐渐延伸出面向开发者的 API 服务正好可以被企业应用调用。所谓“实时搜索服务”在这里更准确的叫法是“可编程的实时搜索能力”。它不是一个搜索框而是一段可以被嵌入工作流的服务请求进来、返回结构化结果、并且每个结果都能追溯到来源。把这三个词拼在一起这次合作的性质就不是“客服机器人加一个搜索按钮”而是“把实时查询外部信息的能力装进客户支持的自动决策链路里”。这对后端架构、权限体系、审计要求的影响会远大于一个按钮。1.2 为什么“大客户”这个定语才是关键如果只是个人产品或小工具接一个搜索 API技术难度没那么高。真正拉开差距的是“大客户”这三个字。大客户的客服系统通常有几个特点。第一生产环境有明确的 SLA搜索服务超时 3 秒就要触发降级不能影响在线会话。第二权限体系复杂不同坐席、不同部门、不同地域能看到的信息范围不一样搜索进来的外部信息不能绕过这些权限。第三审计要求严格AI 每说一句话系统最好能回答出“这句话的依据是什么、来自哪个来源、什么时候检索的”。第四集成不是新起炉灶而是要嵌入已经存在的 CRM、工单和知识库系统。这些要求意味着Decagon 接 Perplexity 不是技术演示而是要在一个已经有大量企业客户的生产系统里把外部实时信息变成可审计、可降级、可解释的客服能力。这才是“大客户”这个定语的分量它决定了一次搜索回答背后必须有一整套工程保障而不是一个把 PDF 喂给模型就完事的小工具。2. 实时搜索进入客户支持最难的其实是“敢用”2.1 静态知识库的三种失效方式先说一个大家都见过的问题如果你的 AI 客服完全依赖一个静态知识库它什么时候会答错第一种是时间失效。政策在变、价格在变、航班在变、产品在变。知识库的寿命取决于更新频率而现实里很多企业知识库是按季度更新的。用户问“现在还能不能退这个月的会员费”知识库里写的是三个月前的规则AI 答得越流畅伤害越大。第二种是范围失效。用户问的问题根本不在知识库里。比如一个突然爆发的行业事件、一款竞品刚发布的新功能、一条刚刚公布的新规。这些内容不会出现在企业内部整理好的文档里模型再怎么检索自己的知识库也翻不出来。第三种是表达失效。知识库里的条目是固定的用户问法却是千变万化的。RAG 可以把“怎么退货”和“我想把这东西寄回去”匹配上但遇到“你们和 XX 家比到底好在哪”这种开放问题知识库往往没有对应记录。实时搜索解决的核心正是前两种失效。它的价值不是让 AI 更聪明而是让 AI 在一个信息高速变化的世界里不至于永远活在知识库快照里。2.2 从 RAG 到实时增强链路发生了什么变化普通 RAG 的链路是用户问题 - 向量检索知识库 - 拼接上下文 - 大模型生成回答。它的先决条件是“知识库里有答案”。加上实时搜索之后链路会变成用户问题 - 判断是否需要外部信息 - 改写搜索词 - 调用搜索服务 - 过滤和排序结果 - 拼接带来源的上下文 - 大模型生成带引用的回答。多出来的那几步才是真正的难点。搜索服务返回的不是金科玉律可能是低质页面、营销文案、过时内容甚至是被人工干预过的错误信息。相比企业内部知识库外部网页的信噪比要低得多。如果系统只是把搜索结果原样喂给大模型等于把判断责任完全交给了模型这在客户支持场景里是危险的。“敢用”的关键是给搜索结果加一层校验来源是否可信任、时间是否在允许范围内、和用户问题的相关性是否够高、答案生成后能不能挂回来源。这层校验没有做好接入实时搜索就像让客服拿着一本没有编辑审过的百科全书上岗。2.3 引用与审计企业级信任的门槛个人场景里AI 答错了重问一次就好。客服场景里AI 答错了影响是可以量化的差评、投诉、退货、流失严重的还有合规问题。所以企业级接入必须做一件事让每个回答都携带依据。这个依据不能只是模型自己生成的“根据公开信息显示”而必须是可点击、可查看、可追溯的来源链接最好还能记录检索时间和当时的命中位置。这也是我认为这类合作真正有参考价值的地方它把搜索从“模型能力”变成了“系统的可审计外设”。模型负责理解和表达搜索负责从外部找依据来源负责背书。一旦出错团队可以顺着检索日志、来源链接和上下文记录定位到是哪一步出问题而不是只能对着模型摇头。注意如果接入实时搜索时没有保留检索日志等于把答案正确性的最后一道保险也丢掉了。日志不是可选项是审计和复盘的前提。3. 工程落地要过的四道关3.1 延迟预算客服会话等不起十秒在线客服对响应速度的容忍度很低。一个用户正在对订单问题着急AI 如果思考 10 秒才回复体验已经接近失败。业内常用的体感阈值大致是2 秒内流畅5 秒可接受超过 10 秒用户大概率想转人工。实时搜索的接入会带来明显的延迟压力。一次回答的链路可能是大模型判断要不要搜 - 改写搜索词 - 调用搜索 API - 等结果返回 - 再交给大模型生成回答。每一步都是模型调用或者网络请求叠起来很容易突破 5 秒。从工程经验看处理这个问题有几个常用手段。第一做一个“是否要搜”的门控模型或规则只有确定外部信息必要时才触发搜索避免每个问题都白白等一轮搜索。第二对高频问题做结果缓存同一个问题在短时间内不需要重复检索。第三把搜索请求和某些判断请求并行化别写成严格的串行。第四给搜索调用设置明确超时比如 2 到 3 秒没返回就直接走降级路径不能让用户陪着一个慢搜索等到底。延迟设计的目标不是让每次回答都快而是让“慢的情况”可控、有明确上限。3.2 检索失败与降级策略任何一个外部服务都可能失败。网络抖动、搜索服务暂时不可用、返回结果为空、结果质量过低这些都会在真实生产中出现。比失败更糟糕的是系统失败了却不自知给用户回了一个看起来正常但来源缺失的答案。我建议的降级顺序是先回退到内部知识库确保企业自己的权威信息仍然是第一优先级如果知识库也没有内容再回退到通用话术比如“这个问题我需要进一步核实”最后把会话升级到人工处理。每一步降级都应该在系统里留下标记方便事后复盘为什么触发了降级。还有个细节不要让用户在降级时感受到“AI 变笨了”。回退到知识库时可以不做任何提示因为本身这就是正常路径。但如果是直接转人工要明确告诉用户“我马上帮您转接人工”避免用户不知道发生了什么。3.3 知识库与实时结果冲突时听谁的这个问题几乎一定会遇到。知识库写的是 2023 年的售后政策搜索结果却显示 2025 年已经更新了或者企业内部规定和某个行业媒体的报道不一致。这时候模型该听谁的一个相对稳妥的原则是企业内部权威信息优先但必须让“信息级别”显式可见。也就是说系统要明确知道某个回答依据的是知识库、实时搜索还是用户提供的上下文而不是让模型凭感觉选。如果搜索到的更新信息明显更准确可以在回答里标注“根据最新公开信息”并附上来源同时保留知识库内容作为对照。如果只是外部传言企业也没有确认过宁可模糊回答也不要让 AI 去扮演官方发言人。这个问题的本质是实时搜索扩大的是 AI 的信息获取范围但没有改变企业的信息责任边界。搜索进来的外部内容只能作为参考不能自动变成企业官方的承诺。3.4 成本和安全边界大客户的流量量级不是个人调用能比的。搜索 API 按次数计费如果每个会话里的每个问题都触发搜索账单会涨得很快。所以闸门必须前置只有满足条件的问题才配调用搜索否则走知识库或通用回答。成本控制不是财务问题是架构问题。安全方面要更谨慎。搜索返回的是外部不可信内容理论上可能包含诱导指令、挂马链接甚至是专门构造出来攻击 AI 系统的文本。这类输入不能直接拼进 Prompt更不能让它接触到用户的隐私字段。比较通用的做法包括限定来源域名白名单、对搜索结果做清洗和截断、在输出端检查是否有敏感信息泄露以及不让外部内容触发高权限工具。安全提醒只把允许访问的搜索结果放进上下文不要无条件信任外部页面。搜索服务的价值在于“找”风险控制还得靠后置过滤来完成。4. 如果自己想接入实时搜索可以按这个路径走4.1 最小可用流程五步跑通如果你不是 Decagon也没有大客户的资源只是想在自己的知识问答或客服产品里接入实时搜索可以先按这五步跑通一个最小版本。第一步明确边界。不是所有问题都值得搜索。你可以先列一个名单哪几类问题允许触发实时搜索哪几类永远只走知识库。比如“公司政策、产品规格”走知识库“最新动态、行业新闻、突发事件”才搜索。第二步限定来源。给搜索服务一个域名白名单只允许检索你信任的站点。这一步能从源头上过滤掉大量低质内容。不要一开始就追求搜全全网企业场景里“搜得准”比“搜得全”重要。第三步规定引用格式。让模型每给一个结论就必须附上一个来源序号。这一步看起来简单实际上决定了后面所有答案能不能被审计。可以在 Prompt 里写死格式并在后处理时做校验没有来源的回答不允许展示。第四步准备小样本验证集。挑 50 到 100 条真实历史问题人工标注“正确答案 来源类型 可接受延迟”先跑一遍记录命中率、失败率和超时率。第五步灰度上线。先在公司内部用让同事当第一批用户收集日志和反馈。没问题了再开放到真实客户而且先从小流量开始不要一天全量放开。这个流程的价值在于它不追求一步到位而是先保证每一层都是可观测、可回退的。4.2 关键参数别急着拉满接入实时搜索时有几个参数直接决定结果质量。这里给一组我常用的初始建议具体值要根据你的业务调整参数建议初始值为什么这么设搜索触发阈值知识库置信度低于 0.6 才触发避免每个问题都走搜索控制延迟和成本时间范围最近 7 到 30 天客户支持场景只需要近期信息太早结果参考价值低返回结果条数3 到 5 条太多会稀释注意力太少可能漏掉正确答案关联性过滤阈值相关性得分低于 0.5 的结果丢弃低相关结果进上下文只会增加噪声生成温度0.2 或更低客服场景需要确定性不需要创意发挥搜索超时3 秒内超过就降级不能拖住整个会话缓存时间高频问题缓存 30 到 60 分钟平衡新鲜度和成本这些参数不要一次性全部调优。先按初始值跑一周看日志后再调整。你会发现真正需要调的往往不是某一个参数而是“触发条件”和“来源范围”。4.3 一个排查链路答案不对先查哪几层接入之后一定会遇到各种问题。答案过时、答案没有来源、来源打不开、系统超时、偶尔生成的内容和搜索内容对不上……我的建议是不要东一榔头西一棒子按这个链路一层层查。第一层看现象。先确认问题是什么是答案错了、来源错了、还是速度慢了。不同现象对应不同的排查方向。第二层看输入。把用户原始问题和系统改写后的搜索词都打出来。很多时候问题出在改写这一步用户问“你们家那个新品怎么样”系统搜索词可能变成“新品怎么样”根本搜不到具体品牌。第三层看环境。确认搜索服务的 Key 是否有权限、网络是否通畅、服务本身有没有降级或故障。这类问题通常有监控可以看别一上来就怀疑模型。第四层看参数。时间范围是不是太短、结果条数是不是太少、过滤阈值是不是把正确答案拦掉了。把参数放宽一点看看问题是否消失。第五层看边界。如果所有参数都正常搜索也正常返回但答案还是不对那很可能这个信息根本不在你要搜的范围里或者搜索服务本身还没建立索引。真实事件发生后的头几个小时搜不到是正常的。这个排查顺序的核心是先把问题隔离到具体环节再动手修。不要一听到答案不对就去改模型 Prompt那通常是最后一步才做的事。5. 适用边界这类方案适合谁不适合谁5.1 四类适合场景与三类不适合场景实时搜索接入 AI 客服并不是适合所有场景。我把它大概分成两类更适合接入不太适合接入物流、航空、电商这类政策变化快的行业医疗诊断、法律意见等强约束专业回答产品百科型客服经常要查新功能、新参数的场景高度依赖企业内部机密数据的场景需要查询行业公告、监管新规、竞品动态的场景对回答格式、语气、品牌口径要求极其严格的场景内部知识助手员工需要了解外部动态的场景不允许任何外部信息进入决策链的场景适合的场景有一个共同点错误容忍度相对高或者信息更新带来的价值明显高于出错成本。不适合的场景则相反出错成本太高或者企业内部信息才是唯一权威来源外部内容只会添乱。你应该先判断业务属于哪一侧再决定要不要引入实时搜索。而不是因为“这是热点”“别人都在做”就接进去。5.2 最容易翻车的三个细节第一引用来源与回答不对应。模型可能在搜索结果的参考下回答但生成时把来源序号写错甚至凭空编一个来源。这需要用后处理逻辑强校验每一条引用都必须能对应到真实送入上下文的搜索结果无法对应的引用直接去掉。第二搜索索引滞后。很多实时搜索服务并不是真的“毫秒级爬取全网”它也有索引延迟。一个刚发生 20 分钟的事情搜不到很正常。如果你要求的是极强时效性需要额外评估所选服务的索引刷新速度而不是假设搜得到。第三多轮对话中的上下文污染。用户前面说“我买了 XX 牌手机”后面问“它的售后怎么样”系统如果把它改写成一个泛化问题去搜可能搜回一堆别人的意外。要格外注意把搜索词限定在当前意图里别让历史上下文放飞搜索条件。这三个细节都不是大模型能力问题而是系统设计问题但每一个都能让接入从“能用”变成“总出错”。5.3 长期维护才是真正的分水岭实时搜索接入不是部署完就结束的项目。长期来看有几件维护工作是持续性的。第一定期回流日志。每周看一次那些“触发了搜索但用户还是不满意”的会话你会发现很多问题不在模型而在入口该搜的没触发不该搜的反而搜了。第二维护来源质量评级。互联网来源质量是浮动的今天可信的站点明天可能开始发低质内容。需要定期审查白名单并且给不同来源打质量分搜索结果里优先展示高质量来源。第三监控成本与超时。设置每日调用预算超过阈值就告警。搜索服务的价格和性能也会变最好每年评估一次替代方案和额度。如果没有这一类长期机制接实时搜索就是一个“开始很兴奋、三个月后越来越糟”的功能。这也是企业级接入和个人演示最大的区别不是谁接得快而是谁能维护得久。6. 回到本质实时搜索改变的是信息责任模型6.1 从“塞知识”到“查知识”系统形态变了走到这里可以回到最初的问题了。Decagon 接入 Perplexity真正值得关注的地方不是“AI 客服能上网了”而是它把客户支持系统的信息责任模型往前推了一步。过去AI 客服的做法是“把所有知识提前塞进模型”企业希望模型在训练和微调阶段就把事情都学会。这条路的问题在于知识会过期世界会变化模型永远无法通过一次训练来跟上现实。实时搜索的引入把机制改成了另一种形态模型负责理解和组织表达搜索负责从外部获取最新信息来源负责背书。AI 不再被要求“什么都知道”而是被要求“知道自己不知道并且知道去哪里查”。这个变化对客户支持、企业知识问答乃至更广义的 AI 内容生产都有方法论上的意义。它意味着我们可以不再追求一个无所不知的黑箱而是搭建一个“理解 检索 校验
AI客服接入实时搜索：从RAG到可审计的工程落地指南
一条技术消息最近值得关注Decagon 接入 Perplexity 的实时搜索服务方向明确对准大客户。初看只是一条合作新闻但放在 AI 客服落地的背景里它指向一个长期被绕开的问题AI 客服最尴尬的时刻往往就是它需要最新信息的时刻。Decagon 做的是面向企业的 AI 客户支持平台把工单、会话、知识库整合进同一个 AI 工作流。Perplexity 主打 AI 搜索特点是能实时检索互联网公开信息并把答案和来源一起返回。两者结合表面上是“客服机器人终于可以联网找答案了”。但真正做过知识问答产品的人会知道从“能搜”到“敢用”中间隔着权限、时效、引用、延迟、成本、责任六道坎。这篇不打算复述新闻而是想把这类合作背后的工程逻辑拆开看。先解释这次接入解决的核心问题再讲落地中普遍会遇到的四类工程问题然后给出一条自建接入的参考路径最后把适用边界说清楚。1. 先理解 Decagon 这次接入到底接入的是什么1.1 三个关键词分开看才能看清合作的性质Decagon 不是一家普通的聊天机器人公司。从产品定位看它面向的是企业客户支持场景做的是一整套客服自动化平台用户进来之后AI 要能判断意图、读取工单、调用知识库、给出解决方案甚至在必要时创建售后单或升级到人工。这意味着它的技术栈不只是“大模型生成回复”还包含工单路由、客户数据读取、解决率统计这些东西。Perplexity 则更特殊。它做的不是传统搜索引擎的“给链接”而是“给答案”用户输入问题它实时检索互联网把最有可能是答案的内容组织成一段话并附上来源链接。这个模式从消费端产品逐渐延伸出面向开发者的 API 服务正好可以被企业应用调用。所谓“实时搜索服务”在这里更准确的叫法是“可编程的实时搜索能力”。它不是一个搜索框而是一段可以被嵌入工作流的服务请求进来、返回结构化结果、并且每个结果都能追溯到来源。把这三个词拼在一起这次合作的性质就不是“客服机器人加一个搜索按钮”而是“把实时查询外部信息的能力装进客户支持的自动决策链路里”。这对后端架构、权限体系、审计要求的影响会远大于一个按钮。1.2 为什么“大客户”这个定语才是关键如果只是个人产品或小工具接一个搜索 API技术难度没那么高。真正拉开差距的是“大客户”这三个字。大客户的客服系统通常有几个特点。第一生产环境有明确的 SLA搜索服务超时 3 秒就要触发降级不能影响在线会话。第二权限体系复杂不同坐席、不同部门、不同地域能看到的信息范围不一样搜索进来的外部信息不能绕过这些权限。第三审计要求严格AI 每说一句话系统最好能回答出“这句话的依据是什么、来自哪个来源、什么时候检索的”。第四集成不是新起炉灶而是要嵌入已经存在的 CRM、工单和知识库系统。这些要求意味着Decagon 接 Perplexity 不是技术演示而是要在一个已经有大量企业客户的生产系统里把外部实时信息变成可审计、可降级、可解释的客服能力。这才是“大客户”这个定语的分量它决定了一次搜索回答背后必须有一整套工程保障而不是一个把 PDF 喂给模型就完事的小工具。2. 实时搜索进入客户支持最难的其实是“敢用”2.1 静态知识库的三种失效方式先说一个大家都见过的问题如果你的 AI 客服完全依赖一个静态知识库它什么时候会答错第一种是时间失效。政策在变、价格在变、航班在变、产品在变。知识库的寿命取决于更新频率而现实里很多企业知识库是按季度更新的。用户问“现在还能不能退这个月的会员费”知识库里写的是三个月前的规则AI 答得越流畅伤害越大。第二种是范围失效。用户问的问题根本不在知识库里。比如一个突然爆发的行业事件、一款竞品刚发布的新功能、一条刚刚公布的新规。这些内容不会出现在企业内部整理好的文档里模型再怎么检索自己的知识库也翻不出来。第三种是表达失效。知识库里的条目是固定的用户问法却是千变万化的。RAG 可以把“怎么退货”和“我想把这东西寄回去”匹配上但遇到“你们和 XX 家比到底好在哪”这种开放问题知识库往往没有对应记录。实时搜索解决的核心正是前两种失效。它的价值不是让 AI 更聪明而是让 AI 在一个信息高速变化的世界里不至于永远活在知识库快照里。2.2 从 RAG 到实时增强链路发生了什么变化普通 RAG 的链路是用户问题 - 向量检索知识库 - 拼接上下文 - 大模型生成回答。它的先决条件是“知识库里有答案”。加上实时搜索之后链路会变成用户问题 - 判断是否需要外部信息 - 改写搜索词 - 调用搜索服务 - 过滤和排序结果 - 拼接带来源的上下文 - 大模型生成带引用的回答。多出来的那几步才是真正的难点。搜索服务返回的不是金科玉律可能是低质页面、营销文案、过时内容甚至是被人工干预过的错误信息。相比企业内部知识库外部网页的信噪比要低得多。如果系统只是把搜索结果原样喂给大模型等于把判断责任完全交给了模型这在客户支持场景里是危险的。“敢用”的关键是给搜索结果加一层校验来源是否可信任、时间是否在允许范围内、和用户问题的相关性是否够高、答案生成后能不能挂回来源。这层校验没有做好接入实时搜索就像让客服拿着一本没有编辑审过的百科全书上岗。2.3 引用与审计企业级信任的门槛个人场景里AI 答错了重问一次就好。客服场景里AI 答错了影响是可以量化的差评、投诉、退货、流失严重的还有合规问题。所以企业级接入必须做一件事让每个回答都携带依据。这个依据不能只是模型自己生成的“根据公开信息显示”而必须是可点击、可查看、可追溯的来源链接最好还能记录检索时间和当时的命中位置。这也是我认为这类合作真正有参考价值的地方它把搜索从“模型能力”变成了“系统的可审计外设”。模型负责理解和表达搜索负责从外部找依据来源负责背书。一旦出错团队可以顺着检索日志、来源链接和上下文记录定位到是哪一步出问题而不是只能对着模型摇头。注意如果接入实时搜索时没有保留检索日志等于把答案正确性的最后一道保险也丢掉了。日志不是可选项是审计和复盘的前提。3. 工程落地要过的四道关3.1 延迟预算客服会话等不起十秒在线客服对响应速度的容忍度很低。一个用户正在对订单问题着急AI 如果思考 10 秒才回复体验已经接近失败。业内常用的体感阈值大致是2 秒内流畅5 秒可接受超过 10 秒用户大概率想转人工。实时搜索的接入会带来明显的延迟压力。一次回答的链路可能是大模型判断要不要搜 - 改写搜索词 - 调用搜索 API - 等结果返回 - 再交给大模型生成回答。每一步都是模型调用或者网络请求叠起来很容易突破 5 秒。从工程经验看处理这个问题有几个常用手段。第一做一个“是否要搜”的门控模型或规则只有确定外部信息必要时才触发搜索避免每个问题都白白等一轮搜索。第二对高频问题做结果缓存同一个问题在短时间内不需要重复检索。第三把搜索请求和某些判断请求并行化别写成严格的串行。第四给搜索调用设置明确超时比如 2 到 3 秒没返回就直接走降级路径不能让用户陪着一个慢搜索等到底。延迟设计的目标不是让每次回答都快而是让“慢的情况”可控、有明确上限。3.2 检索失败与降级策略任何一个外部服务都可能失败。网络抖动、搜索服务暂时不可用、返回结果为空、结果质量过低这些都会在真实生产中出现。比失败更糟糕的是系统失败了却不自知给用户回了一个看起来正常但来源缺失的答案。我建议的降级顺序是先回退到内部知识库确保企业自己的权威信息仍然是第一优先级如果知识库也没有内容再回退到通用话术比如“这个问题我需要进一步核实”最后把会话升级到人工处理。每一步降级都应该在系统里留下标记方便事后复盘为什么触发了降级。还有个细节不要让用户在降级时感受到“AI 变笨了”。回退到知识库时可以不做任何提示因为本身这就是正常路径。但如果是直接转人工要明确告诉用户“我马上帮您转接人工”避免用户不知道发生了什么。3.3 知识库与实时结果冲突时听谁的这个问题几乎一定会遇到。知识库写的是 2023 年的售后政策搜索结果却显示 2025 年已经更新了或者企业内部规定和某个行业媒体的报道不一致。这时候模型该听谁的一个相对稳妥的原则是企业内部权威信息优先但必须让“信息级别”显式可见。也就是说系统要明确知道某个回答依据的是知识库、实时搜索还是用户提供的上下文而不是让模型凭感觉选。如果搜索到的更新信息明显更准确可以在回答里标注“根据最新公开信息”并附上来源同时保留知识库内容作为对照。如果只是外部传言企业也没有确认过宁可模糊回答也不要让 AI 去扮演官方发言人。这个问题的本质是实时搜索扩大的是 AI 的信息获取范围但没有改变企业的信息责任边界。搜索进来的外部内容只能作为参考不能自动变成企业官方的承诺。3.4 成本和安全边界大客户的流量量级不是个人调用能比的。搜索 API 按次数计费如果每个会话里的每个问题都触发搜索账单会涨得很快。所以闸门必须前置只有满足条件的问题才配调用搜索否则走知识库或通用回答。成本控制不是财务问题是架构问题。安全方面要更谨慎。搜索返回的是外部不可信内容理论上可能包含诱导指令、挂马链接甚至是专门构造出来攻击 AI 系统的文本。这类输入不能直接拼进 Prompt更不能让它接触到用户的隐私字段。比较通用的做法包括限定来源域名白名单、对搜索结果做清洗和截断、在输出端检查是否有敏感信息泄露以及不让外部内容触发高权限工具。安全提醒只把允许访问的搜索结果放进上下文不要无条件信任外部页面。搜索服务的价值在于“找”风险控制还得靠后置过滤来完成。4. 如果自己想接入实时搜索可以按这个路径走4.1 最小可用流程五步跑通如果你不是 Decagon也没有大客户的资源只是想在自己的知识问答或客服产品里接入实时搜索可以先按这五步跑通一个最小版本。第一步明确边界。不是所有问题都值得搜索。你可以先列一个名单哪几类问题允许触发实时搜索哪几类永远只走知识库。比如“公司政策、产品规格”走知识库“最新动态、行业新闻、突发事件”才搜索。第二步限定来源。给搜索服务一个域名白名单只允许检索你信任的站点。这一步能从源头上过滤掉大量低质内容。不要一开始就追求搜全全网企业场景里“搜得准”比“搜得全”重要。第三步规定引用格式。让模型每给一个结论就必须附上一个来源序号。这一步看起来简单实际上决定了后面所有答案能不能被审计。可以在 Prompt 里写死格式并在后处理时做校验没有来源的回答不允许展示。第四步准备小样本验证集。挑 50 到 100 条真实历史问题人工标注“正确答案 来源类型 可接受延迟”先跑一遍记录命中率、失败率和超时率。第五步灰度上线。先在公司内部用让同事当第一批用户收集日志和反馈。没问题了再开放到真实客户而且先从小流量开始不要一天全量放开。这个流程的价值在于它不追求一步到位而是先保证每一层都是可观测、可回退的。4.2 关键参数别急着拉满接入实时搜索时有几个参数直接决定结果质量。这里给一组我常用的初始建议具体值要根据你的业务调整参数建议初始值为什么这么设搜索触发阈值知识库置信度低于 0.6 才触发避免每个问题都走搜索控制延迟和成本时间范围最近 7 到 30 天客户支持场景只需要近期信息太早结果参考价值低返回结果条数3 到 5 条太多会稀释注意力太少可能漏掉正确答案关联性过滤阈值相关性得分低于 0.5 的结果丢弃低相关结果进上下文只会增加噪声生成温度0.2 或更低客服场景需要确定性不需要创意发挥搜索超时3 秒内超过就降级不能拖住整个会话缓存时间高频问题缓存 30 到 60 分钟平衡新鲜度和成本这些参数不要一次性全部调优。先按初始值跑一周看日志后再调整。你会发现真正需要调的往往不是某一个参数而是“触发条件”和“来源范围”。4.3 一个排查链路答案不对先查哪几层接入之后一定会遇到各种问题。答案过时、答案没有来源、来源打不开、系统超时、偶尔生成的内容和搜索内容对不上……我的建议是不要东一榔头西一棒子按这个链路一层层查。第一层看现象。先确认问题是什么是答案错了、来源错了、还是速度慢了。不同现象对应不同的排查方向。第二层看输入。把用户原始问题和系统改写后的搜索词都打出来。很多时候问题出在改写这一步用户问“你们家那个新品怎么样”系统搜索词可能变成“新品怎么样”根本搜不到具体品牌。第三层看环境。确认搜索服务的 Key 是否有权限、网络是否通畅、服务本身有没有降级或故障。这类问题通常有监控可以看别一上来就怀疑模型。第四层看参数。时间范围是不是太短、结果条数是不是太少、过滤阈值是不是把正确答案拦掉了。把参数放宽一点看看问题是否消失。第五层看边界。如果所有参数都正常搜索也正常返回但答案还是不对那很可能这个信息根本不在你要搜的范围里或者搜索服务本身还没建立索引。真实事件发生后的头几个小时搜不到是正常的。这个排查顺序的核心是先把问题隔离到具体环节再动手修。不要一听到答案不对就去改模型 Prompt那通常是最后一步才做的事。5. 适用边界这类方案适合谁不适合谁5.1 四类适合场景与三类不适合场景实时搜索接入 AI 客服并不是适合所有场景。我把它大概分成两类更适合接入不太适合接入物流、航空、电商这类政策变化快的行业医疗诊断、法律意见等强约束专业回答产品百科型客服经常要查新功能、新参数的场景高度依赖企业内部机密数据的场景需要查询行业公告、监管新规、竞品动态的场景对回答格式、语气、品牌口径要求极其严格的场景内部知识助手员工需要了解外部动态的场景不允许任何外部信息进入决策链的场景适合的场景有一个共同点错误容忍度相对高或者信息更新带来的价值明显高于出错成本。不适合的场景则相反出错成本太高或者企业内部信息才是唯一权威来源外部内容只会添乱。你应该先判断业务属于哪一侧再决定要不要引入实时搜索。而不是因为“这是热点”“别人都在做”就接进去。5.2 最容易翻车的三个细节第一引用来源与回答不对应。模型可能在搜索结果的参考下回答但生成时把来源序号写错甚至凭空编一个来源。这需要用后处理逻辑强校验每一条引用都必须能对应到真实送入上下文的搜索结果无法对应的引用直接去掉。第二搜索索引滞后。很多实时搜索服务并不是真的“毫秒级爬取全网”它也有索引延迟。一个刚发生 20 分钟的事情搜不到很正常。如果你要求的是极强时效性需要额外评估所选服务的索引刷新速度而不是假设搜得到。第三多轮对话中的上下文污染。用户前面说“我买了 XX 牌手机”后面问“它的售后怎么样”系统如果把它改写成一个泛化问题去搜可能搜回一堆别人的意外。要格外注意把搜索词限定在当前意图里别让历史上下文放飞搜索条件。这三个细节都不是大模型能力问题而是系统设计问题但每一个都能让接入从“能用”变成“总出错”。5.3 长期维护才是真正的分水岭实时搜索接入不是部署完就结束的项目。长期来看有几件维护工作是持续性的。第一定期回流日志。每周看一次那些“触发了搜索但用户还是不满意”的会话你会发现很多问题不在模型而在入口该搜的没触发不该搜的反而搜了。第二维护来源质量评级。互联网来源质量是浮动的今天可信的站点明天可能开始发低质内容。需要定期审查白名单并且给不同来源打质量分搜索结果里优先展示高质量来源。第三监控成本与超时。设置每日调用预算超过阈值就告警。搜索服务的价格和性能也会变最好每年评估一次替代方案和额度。如果没有这一类长期机制接实时搜索就是一个“开始很兴奋、三个月后越来越糟”的功能。这也是企业级接入和个人演示最大的区别不是谁接得快而是谁能维护得久。6. 回到本质实时搜索改变的是信息责任模型6.1 从“塞知识”到“查知识”系统形态变了走到这里可以回到最初的问题了。Decagon 接入 Perplexity真正值得关注的地方不是“AI 客服能上网了”而是它把客户支持系统的信息责任模型往前推了一步。过去AI 客服的做法是“把所有知识提前塞进模型”企业希望模型在训练和微调阶段就把事情都学会。这条路的问题在于知识会过期世界会变化模型永远无法通过一次训练来跟上现实。实时搜索的引入把机制改成了另一种形态模型负责理解和组织表达搜索负责从外部获取最新信息来源负责背书。AI 不再被要求“什么都知道”而是被要求“知道自己不知道并且知道去哪里查”。这个变化对客户支持、企业知识问答乃至更广义的 AI 内容生产都有方法论上的意义。它意味着我们可以不再追求一个无所不知的黑箱而是搭建一个“理解 检索 校验 但比较O(n²)，不是O(n log n))
