1. 从离线知识库到实时在线企业AI助手的能力断层在哪里做过企业级AI助手落地的人大概都有过这种体验Demo演示的时候用户问什么都能答上来因为演示问题都是提前设计好的。一旦上线给真实业务人员用问题就来了——今天有什么行业新闻值得关注最近这个政策有什么变化竞品上周发布的新品参数是多少AI助手要么答我的知识截止到某年某月要么直接开始编。这不是模型能力不行而是架构上缺了一环联网检索能力。传统企业AI助手的典型架构是大模型本地知识库RAG。本地知识库解决的是企业内部文档、产品手册、历史工单这类相对静态的知识。它的假设是知识是有限的、可枚举的、变化缓慢的。但企业真实业务场景里大量高价值信息是动态的、外部的、时效性极强的。市场人员需要知道今天的舆情风向销售需要知道客户公司的最新动态产品经理需要知道竞品的版本更新客服需要知道最新的活动规则。这些信息不在企业内网里而在公开的互联网上且每分钟都在变。联网问答Agent要解决的核心矛盾就是让AI助手具备实时获取外部信息并整合进回答的能力。听起来简单——不就是让模型调用搜索接口吗但真正落地过的人知道这里面的坑远比想象中多搜索结果怎么筛选、多源信息怎么去重、时效性怎么判断、引用怎么标注、幻觉怎么抑制、成本怎么控制。每一个问题处理不好都会让联网变成添乱。这篇文章面向的是正在做或准备做企业AI助手联网能力的技术负责人、产品经理和一线开发者。我会从架构设计、检索策略、信息融合、工程实现、成本控制几个维度把联网问答Agent的完整落地路径拆开讲清楚。不堆概念只讲能直接抄作业的方案和我自己踩过的坑。2. 联网问答Agent的架构选型三种主流路线怎么选2.1 路线一模型原生联网Function Calling 搜索工具这是目前最主流的做法。大模型通过Function Calling机制在判断需要外部信息时主动调用一个搜索工具函数拿到结果后再生成回答。整个流程是用户提问 → 模型判断是否需要联网 → 调用搜索API → 返回搜索结果 → 模型整合生成回答。这条路线最大的优势是灵活。模型自己决定什么时候搜、搜什么、搜几次。比如用户问对比一下A产品和B产品的最新版本模型可能会先搜A产品再搜B产品然后整合对比。这种多轮检索的能力是硬编码流程做不到的。但它的坑也很明显。第一模型判断是否联网的准确率不稳定。有些问题明明需要实时信息模型觉得自己知道就不搜了有些问题不需要联网模型又非要搜一下。第二搜索query的质量完全依赖模型。模型生成的搜索词可能过于宽泛或过于具体导致搜索结果质量差。第三延迟不可控。一次Function Calling可能触发多次搜索每次搜索都有网络延迟用户等待时间可能从2秒变成10秒。我实测下来的经验是对于问题类型相对固定的企业场景比如客服问答、产品咨询纯Function Calling路线的稳定性不够需要配合意图识别做前置判断。具体做法是先用一个轻量分类模型判断问题是否需要联网需要联网的直接走检索流程不需要的走本地知识库这样既保证了准确率又控制了延迟。2.2 路线二固定检索增强流程Query改写 搜索 重排 生成这条路线不依赖模型的自主判断而是用工程化的方式把检索流程固定下来。典型流程是用户提问 → Query改写把口语化问题转成搜索友好的关键词→ 调用搜索API → 结果重排按相关性、时效性、权威性排序→ 选取Top-K片段 → 和问题一起喂给模型生成回答。这条路线的好处是可控性强。每一步都是确定的延迟可预测结果质量可以通过调整重排策略来优化。对于企业场景来说可控性往往比灵活性更重要——你不可能让一个客服AI助手在用户等待时自己决定要不要搜。但它的代价是灵活性差。如果用户的问题需要多步检索先搜A再根据A的结果搜B固定流程就很难处理。而且Query改写的质量直接决定了检索效果改写不好后面全白搭。我的建议是企业场景优先选这条路线把灵活性让渡给可控性。具体实现上Query改写可以用一个小模型来做也可以用规则模板的方式。比如用户问你们家产品最近有什么更新改写成XX产品 更新日志 2024这样的搜索query。规则模板覆盖80%的常见问题类型剩下的用模型兜底。2.3 路线三混合架构意图路由 多路召回 Agent编排这是前两条路线的结合体也是我认为中长期最值得投入的架构。核心思路是先用意图识别做路由简单问题走固定流程复杂问题走Agent编排。同时检索侧做多路召回——搜索引擎一路、垂直站点一路、内部知识库一路最后统一重排融合。这种架构的复杂度最高但扩展性最好。比如用户问最近行业内有什么值得关注的政策变化意图识别判断这是行业动态类问题路由到新闻检索政策站点检索两路召回重排后生成回答。如果用户追问那对我们公司有什么影响Agent可以基于上一轮的检索结果做二次推理而不需要重新搜索。选型建议我整理成了一张表方便对照自己团队的情况做决策维度模型原生联网固定检索流程混合架构实现复杂度低中高可控性低高中高灵活性高低高延迟稳定性差好中适合场景探索型问答客服/咨询综合型助手团队要求1-2人2-3人3-5人提示不要一上来就做混合架构。先用固定检索流程把核心场景跑通验证了用户价值之后再逐步引入Agent编排。我见过太多团队在架构上过度设计结果核心场景的检索质量都没调好。3. 检索质量决定生死Query改写与结果重排的实操细节3.1 Query改写把人话翻译成搜索语言用户不会用搜索引擎的方式提问。用户会说你们那个新功能怎么用不了了而搜索引擎需要的是XX产品 XX功能 故障 解决方法。Query改写的质量直接决定了后面所有环节的效果上限。我试过三种改写方案各有适用场景方案一规则模板匹配。针对高频问题类型预设模板。比如怎么/如何开头的问题改写成XX 教程 步骤为什么开头的问题改写成XX 原因 分析。这种方案覆盖率高、延迟低几乎为零但泛化能力差遇到模板没覆盖的问题就失效。方案二小模型改写。用一个7B级别的模型做Query改写输入原始问题和上下文输出搜索query。实测下来改写质量比规则好很多延迟在200-500ms之间可以接受。关键是要给模型足够的few-shot示例让它学会保留核心实体补充搜索意图词的改写模式。方案三大模型改写规则兜底。用大模型做改写同时用规则做后处理。比如大模型改写出XX产品 新功能 无法使用 解决方法规则再补充时间限定词2024。这种方案质量最高但成本和延迟也最高。我的实操建议是方案二为主方案一兜底。具体做法是维护一个高频问题模板库命中模板的直接用规则改写没命中的走小模型改写。这样80%的请求走规则零延迟20%走模型可控延迟整体体验和成本都能接受。还有一个细节容易被忽略改写后的query要做长度控制。搜索引擎对query长度是敏感的太短召回不足太长会引入噪声。我的经验是控制在15-30个字符之间核心实体必须保留修饰词能删就删。3.2 结果重排从搜到到搜对的关键一步搜索引擎返回的结果是按自己的排序逻辑来的这个逻辑和你的业务需求往往不一致。比如搜索XX产品 价格搜索引擎可能返回一堆电商页面但你希望优先展示官方定价页。这就需要重排。重排的核心是设计一个多因子打分函数。我常用的因子包括相关性得分query和文档的语义相似度可以用向量模型算也可以用BM25这类传统方法。时效性得分文档发布时间越新得分越高。但要注意不是所有问题都追求最新——查产品参数时官方文档比最新新闻更权威。权威性得分来源站点的可信度。官方站点行业媒体个人博客论坛帖子。这个需要维护一个站点白名单/黑名单。内容丰富度文档长度、是否有结构化数据、是否包含表格/列表。内容越丰富越可能包含用户需要的信息。去重因子多个结果来自同一站点或内容高度相似时做降权处理。这些因子的权重需要根据业务场景调。我的做法是先用一个默认权重跑起来然后收集bad case做针对性调整。比如发现用户经常抱怨答案太旧就提高时效性权重发现答案来源不可靠就提高权威性权重。重排之后还要做片段抽取。不要把整个网页塞给模型那样token消耗大且噪声多。正确的做法是从重排后的Top-K文档中抽取和query最相关的段落通常2-5段每段控制在200-500字再喂给模型生成回答。3.3 多源信息融合当搜索结果打架时怎么办联网问答最棘手的情况是不同来源的信息互相矛盾。比如搜XX产品支持的最大并发数A来源说1000B来源说5000。这时候模型如果直接选一个说就是在制造幻觉。我的处理策略是分层呈现置信度标注。具体做法是来源分级官方文档技术白皮书行业报告媒体报道用户讨论。高等级来源的信息优先采信。时间加权如果两个来源矛盾且权威性相近取更新的那个。显式标注如果矛盾无法消解在回答中明确说明关于这个问题存在不同说法官方文档显示X部分用户反馈为Y建议以官方信息为准。置信度提示对于信息不完整或来源单一的回答加一句以上信息来自公开渠道仅供参考。这套策略的核心思想是宁可让用户知道信息有不确定性也不要给一个看似确定但可能是错的答案。在企业场景里错误信息的代价远高于不确定的提示。4. 工程落地中的硬骨头延迟、成本与幻觉的三重博弈4.1 延迟优化把首字响应压到2秒以内联网问答的延迟链路比纯本地RAG长得多Query改写200-500ms→ 搜索API调用500-2000ms→ 结果重排100-300ms→ 片段抽取50-100ms→ 模型生成首token 500-1500ms。加起来轻松超过3秒用户体感就是卡。我试过几个有效的优化手段并行化Query改写和搜索API调用可以并行。具体做法是先用原始query发起一次搜索同时做Query改写改写完成后再发起第二次搜索取两次结果的并集做重排。这样虽然多了一次搜索调用但整体延迟反而更低因为第一次搜索的结果可能已经够用了。缓存高频问题的搜索结果做缓存TTL设置在5-30分钟。企业场景里很多问题是重复的比如最新活动规则是什么缓存命中率能到30%以上。缓存key用改写后的query做归一化处理避免XX产品价格和XX产品 价格被当成两个不同请求。流式输出模型生成阶段用流式输出让用户先看到部分答案。即使整体延迟3秒首字响应控制在1.5秒以内用户感知就会好很多。配合正在检索...的加载提示体验更自然。搜索API选型不同搜索API的延迟差异很大。我的经验是通用搜索引擎API延迟在500-1500ms垂直站点API延迟在200-800ms。如果业务场景对特定站点有强需求直接对接该站点的API比走通用搜索更快。4.2 成本控制联网问答的token消耗是纯本地的3-5倍联网问答的成本主要来自三块搜索API调用费、模型token消耗、重排模型的推理成本。其中模型token消耗是大头因为搜索结果作为上下文会显著增加输入token。我实测过一组数据纯本地RAG的单次问答平均消耗1500 input tokens 300 output tokens联网问答平均消耗5000 input tokens 400 output tokens。按主流模型定价算单次成本从约0.02元涨到约0.08元翻了4倍。如果日活1000次问答月成本从600元涨到2400元。控制成本的手段有几个搜索结果截断只取Top-3文档每篇只取最相关的2段每段不超过300字。这样输入token能控制在3000以内。重排模型轻量化重排用小型交叉编码器cross-encoder而不是大模型推理成本可以忽略不计。分级服务简单问题走轻量模型少量检索结果复杂问题走大模型完整检索结果。用意图识别做路由。缓存复用前面提到的搜索结果缓存不仅降延迟也直接省token——缓存命中的请求不需要重新检索和重排。注意不要为了省成本而牺牲检索质量。我见过团队把Top-K从5降到2结果回答质量明显下降用户投诉反而增加了。成本优化的前提是质量达标顺序不能反。4.3 幻觉抑制联网之后模型反而更容易编这是一个反直觉的现象联网之后模型有了外部信息按理说应该更准确但实际中幻觉率反而可能上升。原因是模型面对多个来源的信息时会脑补一些来源中没有的内容或者把不同来源的信息错误地拼接在一起。我总结了几条有效的抑制策略强制引用要求模型在回答中标注每条信息的来源编号比如根据[1]和[3]的信息...。这样一方面让用户可验证另一方面也约束模型不要编造——编造的内容没有来源可标。片段级输入不要把整个网页给模型而是给抽取后的片段每个片段标注来源。这样模型能清楚地知道这段话来自哪里减少混淆。拒答机制当检索结果的相关性得分低于阈值时让模型直接回答抱歉我没有找到足够相关的信息来回答这个问题而不是硬编一个答案。这个阈值需要根据业务容忍度来调。后验校验生成回答后用一个轻量模型做事实一致性检查——回答中的每个事实性陈述是否能在检索结果中找到支撑。找不到支撑的句子做标记或删除。这一步会增加延迟但对质量要求高的场景值得做。5. 从能用到好用企业级联网问答的评估与迭代5.1 怎么评估一个联网问答Agent好不好纯本地RAG的评估相对简单检索准确率、回答忠实度、答案相关性。联网问答的评估要复杂得多因为多了检索这个变量。我常用的评估维度包括评估维度具体指标测量方式检索相关性Top-K命中率人工标注自动评估时效性信息新鲜度检查引用来源的发布时间引用准确性引用与内容一致率抽样人工校验回答忠实度无支撑陈述占比自动校验人工抽检拒答合理性该拒答时拒答率构造边界测试集端到端延迟P50/P95延迟线上监控其中我特别想强调的是拒答合理性。很多团队只关注答对率忽略了该拒答时能不能拒答。一个联网问答Agent如果对所有问题都硬答即使用户当时没发现错误长期也会失去信任。构造一个包含无法回答的问题的测试集定期跑一遍是保证质量底线的必要手段。5.2 迭代节奏先跑通核心场景再扩展边界我见过不少团队一上来就想做一个什么都能问的通用联网助手结果每个场景都做得半吊子。更务实的做法是先锁定1-2个高频核心场景把检索质量和回答质量做到80分以上再逐步扩展。比如先做产品咨询场景——用户问产品功能、价格、版本差异Agent联网检索官方文档和最新公告来回答。这个场景的问题类型相对固定检索源明确官方站点评估标准清晰。跑通之后再扩展到行业动态竞品分析等更开放的场景。每个场景的迭代循环是收集bad case → 分析失败原因是检索没搜到还是重排排错了还是生成编造了→ 针对性优化 → 回归测试。这个循环跑3-5轮核心场景的质量就能稳定下来。5.3 一个容易被忽略的细节引用展示的产品设计技术做完了最后一步是产品呈现。联网问答的回答里引用来源怎么展示直接影响用户信任度。我的经验是行内引用在回答的句子后面用上标数字标注来源用户点击可以跳转原文。这种方式最直观但要求模型生成时准确标注。底部来源列表回答下方列出所有引用的来源包含标题、站点、时间。这种方式实现简单但用户需要自己对应。混合方式行内标注底部列表兼顾可验证性和可读性。还有一个细节来源的时间要显示。用户看到来源XX官网2024-01-15和看到来源XX官网的信任感是完全不同的。时间信息让用户能判断信息的时效性这对联网问答尤其重要。6. 我踩过的几个坑和对应的解法第一个坑是搜索结果被广告污染。早期我们直接对接通用搜索API结果返回的结果里混了不少推广内容模型把这些当事实引用闹了笑话。解法是维护一个站点黑名单同时在重排阶段对已知的推广类站点做降权。更彻底的做法是对接垂直站点的官方API从源头保证质量。第二个坑是Query改写过度。小模型有时候会把用户的query改得面目全非比如用户问XX功能怎么开通改写成XX功能 开通 教程 步骤 2024 最新结果搜出来一堆不相关的教程。解法是给改写加约束——核心实体必须原样保留只允许添加意图词和时间词不允许替换或删除实体。第三个坑是多轮对话中的检索上下文丢失。用户先问XX产品有什么新功能Agent搜了一轮回答了。用户接着问那价格呢这时候如果只拿那价格呢去搜索肯定搜不到东西。解法是在Query改写时把对话历史带上让模型理解那价格呢指的是XX产品的价格。这个细节不做多轮体验会非常割裂。第四个坑是缓存导致的时效性问题。我们给搜索结果设了30分钟缓存结果有一次官方刚发布了紧急公告用户问相关问题时Agent还在用缓存里的旧信息回答。解法是给缓存加分级——普通信息缓存30分钟但涉及最新紧急公告等关键词的查询不走缓存或者缓存TTL降到1分钟。这四个坑的共同点是都不是模型能力问题而是工程细节问题。联网问答Agent的落地技术选型只占30%剩下70%都是这些琐碎但致命的工程细节。把细节磨好了Agent才能从能用变成好用。最后分享一个我个人的判断标准一个联网问答Agent是否合格就看用户愿不愿意把它的回答直接转发给同事。如果用户每次都要自己核实一遍再转发说明信任度不够还有优化空间。这个标准比任何自动评估指标都直观。