官网的转化漏斗上有两个位置常年漏水一个是用户看完价格页之后的那三分钟另一个是他在产品列表里来回横跳的那五分钟。前一个位置缺的是有人接话后一个位置缺的是有人指路。过去这两件事得靠两拨人干——客服团队排班运营团队手工配推荐位成本高、响应慢而且周末和深夜基本处于放弃状态。这次我拿一个云产品官网下称飞鸟云官网做实验用快马平台这套 AI 生成链路把智能客服和推荐系统一次性搭起来跑了两周把踩过的坑和能直接抄的配置都记下来。先说清楚这篇东西适合谁看手里有官网、有产品文档、有历史工单但前端人力紧张、后端资源排队、又想在转化率上做点实事的团队。不需要你会训模型也不需要你会写向量检索的底层代码但需要你愿意花两天时间把官网内容捋顺——这件事机器替不了你。整套方案的核心不是接个大模型上去而是把散落在官网各处的产品信息整理成机器能检索、能比较、能打分的数据底座再让 AI 在这个底座上做问答和推荐。底座不对接什么模型都是白搭。1. 客服和推荐看似两件事其实是同一个意图层1.1 官网咨询链路上的三个断点我把过去三个月官网的咨询记录翻了一遍按用户行为路径做了归类发现断点集中在三处。第一处是找不到入口很多用户是在产品详情页做决策而悬浮客服默认收在右下角一个小气泡里视觉权重极低尤其在移动端会被底部导航栏挤压。第二处是问不到点子上用户打字问你们这个存储怎么收费人工客服要先反问业务场景、数据量级、访问频次来回三四轮才进入正题用户耐心在这个阶段消耗掉大半。第三处是答完没人接客服给了一段解释用户回好的会话就死了没有任何把解释转成行动试用、留资、看文档的钩子。这三个断点里只有第一个是 UI 问题后两个本质是信息组织问题。用户问得模糊是因为官网把关键信息藏在了三层导航之下答完没转化是因为回答本身是终点而不是岔路口。这直接决定了后面的技术选型与其做一个能聊天的机器人不如做一个能把模糊问题映射到具体产品页/文档页/试用入口的路由器。1.2 云产品官网的选型困惑为什么比电商更重电商推荐系统成熟是因为商品有明确的结构化属性品类、价格、规格、评价数。云产品的麻烦在于决策维度是组合式的——同一款对象存储计费方式分按量与包年包月存储类型分标准与低频访问路径分内网与外网再叠加地域和冗余策略一个用户面对的可能是几十种组合。更麻烦的是术语门槛新用户根本不知道自己该问IOPS还是并发连接数。这就意味着推荐系统不能照搬看过 A 的人还看了 B的协同过滤逻辑——官网流量根本撑不起这种密度。我实测下来日均 UV 四位数出头的官网协同过滤的覆盖率不到两成剩下八成全是冷启动。所以推荐这一侧必须走规则 标签匹配的路线先保证可解释、不出错、覆盖全模型排序等数据攒够半年再谈。1.3 把两条链路并到一个意图识别层上我最终的结构是这样用户在任何页面触发对话先过一层意图分类分成价格与计费功能与能力接入与技术故障与工单其他五类。前四类走知识检索问答检索结果里如果命中产品实体就在回答下方挂一到两张产品卡片——这就是推荐位的注入点。第五类直接转人工不做无谓的兜底尝试。这么设计的好处是客服和推荐共用同一份产品结构化数据不用维护两套内容。坏处是耦合度高产品信息一改两边同时受影响所以后面我强制加了内容版本号和生效时间字段这点在第 5 章会展开讲。整体思路是先用一个轻量分类把流量分桶再在桶内做重活避免让大模型在这句到底该问啥上浪费 token。2. 喂料阶段把官网内容整理成能检索的底座2.1 语料来源清单与取舍标准动手之前我列了一张表把官网上所有可能成为答案来源的内容全列出来然后逐项判断要不要进知识库。判断标准只有一条这段话能不能直接回答一个具体问题。能进不能不进或者改造后再进。来源是否入库处理方式产品文档功能说明、参数表是按小节切片保留标题层级计费说明页是单独建价格标签强制校验常见问题页是一问一答作为完整切片不拆历史工单脱敏后部分只取已闭环且有明确结论的营销落地页文案否形容词太多检索命中后答非所问博客/技术文章部分只取含配置示例的实操类营销文案被排除这件事我吃过亏。最早图省事把产品落地页的介绍段落直接灌进去结果用户问这个能不能对接对象存储机器人答我们提供极致弹性的云原生体验——用户当场骂了一句就关了。原因很简单营销文案是写给搜索引擎和决策者看的通篇是形容词和愿景没有一个可验证的事实。这类内容进知识库只会稀释检索质量。2.2 切片粒度与元数据设计切片这件事粒度比算法重要。我试过按固定字数硬切效果很差——一段计费说明被从中间切开前半段讲按量计费单价后半段讲阶梯折扣检索命中前半段时回答里就少了最关键的价格条件。后来改成按语义结构切优先按 H2/H3 标题切其次按段落切单个切片控制在 300 到 500 字超长的段落按句子边界拆相邻切片保留约 15% 的重叠内容。元数据比切片更关键。我给每个切片挂了六个字段这些字段后来成了推荐系统和客服兜底逻辑的主要依据{ chunk_id: doc-storage-0031, product_line: 对象存储, doc_type: billing, version: 2024Q3, billing_model: [按量, 包年包月], updated_at: 2024-09-12, source_url: /docs/storage/pricing }product_line是做推荐关联的主键doc_type决定这条切片能不能用来回答价格问题只有billing类型的切片才允许输出具体金额version和updated_at是后面做失效校验的依据。这套元数据是我在整个项目里投入产出比最高的一块工作多花半天打标签后面省掉无数次的答非所问。2.3 推荐系统需要的结构化产品表客服靠文本切片推荐靠结构化表两者必须同源。我维护了一张产品能力表字段包括产品线、适用场景标签、起步规格、计费方式、是否支持试用、关联产品。这张表不需要多精细十几行就能覆盖官网在售的主力产品但场景标签必须用人话写比如图片与视频存储日志归档静态网站托管而不是高可用对象存储服务。原因在于推荐触发的入口是用户的自然语言。用户说我要存一批监控截图大概几百 G系统提取到的关键词是存截图几百 G只有场景标签写成图片与视频存储才能匹配上。标签写得太专业匹配率会掉一大截。我在这一块反复改了三次标签体系最后定下的原则是标签按用户会怎么说来写不按产品经理会怎么写来写。2.4 一个容易被忽略的动作清理历史工单历史工单是好东西但不能直接用。我抽了两百条看大概有三类问题一是回答里带具体客户名和资源 ID必须脱敏二是很多工单是已电话沟通解决正文没有结论这类要整条剔除三是有时效性的回答比如某个功能下季度上线现在早就上线了这类必须核对后重写或删除。我最后只保留了两成工单进库但这批数据的价值极高——它们记录的正是真实用户的原话表述方式。用它来扩充同义表达比如用户会说欠费停机而不是资源冻结比任何同义词词典都好使。3. 智能客服的搭建提示词分层与检索调优3.1 挂件形态与触发时机挂件这块我改了三版。第一版是常规的右下角气泡点击展开数据很难看——曝光高、点击低移动端尤其差。第二版加了停留超过 20 秒自动弹出一句引导语点击率上去了但跳出率也上去了因为打断感太强。第三版改成场景化触发只在三个位置主动出现——价格页停留超过 15 秒、产品对比页滚动到底、文档页搜索无结果。这三个位置都是用户明显卡住的地方这时候给一句需要帮你算一下这个配置的费用吗接受度完全不同。技术上挂件脚本做了延迟加载挂在requestIdleCallback里初始化避免和首屏抢资源。这一点在后面的性能章节会细说因为第一版差点把 LCP 拖垮。3.2 提示词的六层结构提示词我拆成六层写比塞一大段自然语言稳定得多。核心是让模型明确什么情况下必须闭嘴【角色】你是飞鸟云官网的技术顾问回答围绕官网在售的云产品。 【知识来源】只能依据检索到的文档片段作答不得引入片段之外的产品能力。 【价格规则】涉及金额时必须同时给出计费方式、地域、以及最终以官网价格页为准的提示。 【不确定处理】检索片段不足以支撑结论时明确说这部分我需要帮你转给人工确认不得猜测。 【输出格式】结论先行三句以内需要步骤时用编号涉及产品时用产品全称。 【转人工条件】用户明确要求人工、涉及账号与账单争议、连续两轮未命中知识库。这六层里最关键的是【价格规则】和【不确定处理】。大模型在价格问题上有强烈的补全冲动你给一个模糊的单价它能自己推算出一个月度总价而且算得理直气壮。我加了一条硬约束凡是输出中含金额必须携带billing标签的切片作为依据否则走兜底话术。这条加上之后价格类错误基本清零。3.3 检索参数的实测取值参数这块没有普适最优值只能实测。我用了两百条真实问题做测试集记录了不同配置下的命中情况参数初版调整后说明召回条数 top_k105召回太多会引入干扰片段反而拉低准确率相似度阈值0.60.72低于 0.72 的基本是弱相关宁可走兜底重排后取用条数32两条足够支撑一个结论多了模型容易拼接出新事实切片最小字数100200太短的切片缺少上下文答出来是半句话同义扩展关闭开启开启后欠费停机冻结能互相命中阈值调到 0.72 是个权衡。调高到 0.78准确率确实上去了但兜底率涨到四成用户体验变差0.72 是我这边兜底率 18%、准确率 86% 的平衡点。这个值跟你的文档质量强相关文档写得越规范阈值可以放得越低。3.4 兜底不是认输是转化入口早期我把兜底设计成抱歉我没听懂效果极差。后来改成兜底三段式承认 给替代路径 留钩子。承认部分直接说这个问题我这边没有找到准确答案替代路径给两个具体链接一个是最相关的文档页一个是提交工单钩子是可选的留资表单只在用户愿意留联系方式时才展示不强制。这里有个细节值得说留资表单的字段我砍到只剩两个——联系方式和一句话描述问题。字段一多填写率断崖下跌。填完之后系统会自动把前面的对话摘要带进工单用户不用重复描述这个体验提升带来的好评比客服本身还多。3.5 埋点没有数据就无法迭代我在挂件上埋了六个事件两周就攒够了调优依据chat_open会话打开带来源页面和触发方式chat_msg用户发消息带轮次序号chat_hit检索命中带命中切片 ID 和相似度chat_miss未命中带用户原话lead_submit留资提交chat_handoff转人工带触发原因chat_miss这个事件最有价值。我每周把未命中的问题聚一次类基本上前十条就覆盖了八成缺口补完这批语料兜底率能再降五到八个点。这是一个持续滚动的过程别指望一次到位。4. 推荐系统规则先行把可解释性放在第一位4.1 冷启动阶段为什么必须放弃协同过滤前面提过流量密度不够。我做过一个简单测算官网日均有效曝光约三千次分散到十几个产品上单个产品的日曝光中位数不到两百两周才能攒出一点像样的共现数据。这个量级下协同过滤算出来的相似产品基本是噪声。所以我一开始就走规则打分路线靠三类信号用户当前浏览的产品、对话中提取的场景关键词、历史访问过的产品线。三类信号加权求和取分数最高的两个作为推荐结果。这套东西土但可解释、可调试、不出洋相。等数据攒到能算的时候再换不着急。4.2 三条打分策略的具体配置我把策略拆成三条独立规则各自打分再合并。这样出问题时能快速定位是哪条规则在捣乱{ rule_same_line_upgrade: { desc: 同类产品升级推荐, weight: 0.45, condition: 当前页面产品线已知, candidate: 同 product_line 下规格更高的产品 }, rule_scene_match: { desc: 场景关键词匹配, weight: 0.35, condition: 对话或搜索中出现场景标签, candidate: scene_tags 有交集的全部产品 }, rule_popular_fallback: { desc: 热门兜底, weight: 0.20, condition: 前两条均无有效候选, candidate: 近 7 天试用转化率 Top3 产品 } }权重是拍脑袋定的初值然后靠埋点数据调。调的时候有个原则单条规则的权重不要超过 0.5否则等于退化成单策略出问题没有交叉验证。另外我给推荐结果加了强约束——同一产品 24 小时内不重复推荐跨会话也生效用本地存储记一个已推荐列表用户不觉得烦点击率反而更高。4.3 推荐位的三个落点与埋点回收推荐卡片我放在三个位置客服回答下方、产品对比页侧栏、文档页文末。三个位置的点击率差异很大客服回答下方最高因为上下文最强文档页文末最低但转化质量最好点进去的人基本是在做技术选型。埋点跟着卡片走记录曝光、点击、后续是否进入试用页。这里有个坑曝光埋点一定要做可见性判断元素进入视口超过 50% 且停留超过 1 秒才计一次否则页面上滑过去的卡片全算曝光CTR 会被稀释得没法看。我第一版没做这个数据出来后 CTR 只有 0.8%做完可见性过滤重算真实 CTR 是 3.4%差了四倍。4.4 负反馈用户关掉推荐卡片这件事要当真我加了一个很小的功能推荐卡片右上角有个不感兴趣。点击后该产品线在本次会话中不再出现。这个功能上线的第一周我拿到的数据很有意思——被标记最多的不是冷门产品而是某个被系统反复推荐的主力产品。原因很直接用户在价格页看了三次同一个推荐会觉得这个网站只会推这一个。这件事让我意识到推荐的敌人不是推错而是推重复。后来我把去重逻辑从同产品扩展到同产品线重复感明显下降卡片点击率回升了两个点。5. 上线两周踩到的四个坑5.1 检索命中了但答的不是那个意思最典型的例子用户问你们支持 IPv6 吗检索命中了一段讲网络类型支持的文档里面确实提到了 IPv6但那段话的上下文是在讲某个特定产品的内网配置。模型照本宣科答了出来用户以为全站都支持。根因是切片时把上下文切没了。修复方式是给每个切片补一段所属章节标题路径检索时把路径一起喂给模型并在提示词里要求如果问题涉及适用范围必须核对章节标题中的产品名。改完之后这类适用范围错位的错误降了七成。这类错误的隐蔽性很强用户不会当场反驳但会默默失去信任所以必须靠抽查发现——我每周固定抽三十条会话逐条看这个动作不能省。5.2 价格说错是唯一不能容忍的错误我把所有错误类型排了个序价格错误排第一因为它会直接引发投诉。防线做了三层第一层是检索侧价格类问题强制要求命中billing标签的切片否则不走生成第二层是生成侧提示词硬约束必须带计费方式和地域第三层是输出侧用一个正则做后置校验检测到金额但回答里没有以官网价格页为准这句话时直接替换成兜底话术。第三层看着笨但它救过场。有一次上游更新了折扣政策知识库没同步正则拦截了六次错误输出。这件事之后我加了一条铁律价格页任何改动必须同步触发知识库更新并在更新记录里留痕。这条规则后来被我写进了内容维护的流程里。5.3 推荐把用户带偏跳失率反而上升上线第三天我发现一个反常现象推荐卡片的点击率不错但被点击的产品页跳出率比自然流量高了将近二十个点。翻了几十条会话记录才明白问题出在同类升级推荐这条规则上——用户在文档页看的是入门款配置说明系统给他推了高一档的产品价格差了好几倍点进去直接被吓退。修复思路是加价格带约束推荐的候选产品其起步价不得高于用户当前浏览产品的两倍。这个阈值是试出来的一倍太紧几乎没有候选三倍太松还是会被吓到两倍是个相对舒服的区间。加完约束后推荐带来的跳出率回落到只比自然流量高三个点属于可接受范围。5.4 挂件拖慢了首屏这个必须盯第一版挂件是同步加载的一个三百多 KB 的脚本堵在首屏关键路径上移动端 LCP 直接劣化了将近一秒。改法有三步脚本改成defer加载初始化逻辑放进requestIdleCallback空闲时才跑把知识库检索改成按需请求用户第一次发消息时才拉取上下文配置。改完之后的实测数据LCP 恢复到改动前水平脚本对首屏的影响基本归零。这里提醒一句挂件类的第三方脚本最容易在性能上翻车上线前一定要在移动端弱网下跑一遍别只看桌面端。6. 迭代节奏每周半小时的固定动作跑了两周之后我把维护动作固化成三件事每周花不到半小时。第一件是导出chat_miss事件看未命中的问题分布挑前五条补语料或者补切片。第二件是抽查二十条完整会话重点看有没有答得流畅但内容错的情况这类问题埋点抓不到。第三件是看推荐卡片的曝光点击和后续转化把连续两周零点击的卡片位置下线。这套动作的价值在于它把 AI 系统从上线即完成变成了持续喂养。我见过太多团队把机器人接上去就不管了三个月后兜底率飙到四成用户全跑光。这类系统的真实成本不在搭建而在维护——搭建可能两天,维护是长期的。一个可以马上用的小技巧给知识库加一个最近更新的字段在客服回答的末尾当命中的切片是三十天内更新的内容时附一句这条信息更新于 X 月 X 日。这个细节能明显提升用户对回答的信任度尤其在价格和功能变更频繁的场景下用户看到时间戳会安心很多。我个人在实际操作中的体会是这套东西的技术门槛远比想象中低真正决定成败的是两件很朴素的事内容整理得够不够干净以及你愿不愿意每周花半小时去看真实会话。模型会换、平台会升级这两件事不会变。
