AI答疑实践:有赞门店智能助手效率提升之道
春节前后,DeepSeek突然出圈,把AI的热度推到了一个新高度。各大厂都在加码AI工具,有赞门店技术团队自然也没闲着。我们一直在探索各种能借助AI提效的手段,今天这篇文章,就打算从「技术答疑」这个小切口入手,聊聊我们基于飞书Aily平台搭建智能助手的真实经历和思考。
在这篇文章里,你会看到:
- 为什么最终选择了Aily来搭这个门店智能助手;
- 实际用下来,它到底帮我们省了多少事、提了多少效;
- 以及在整个搭建和调试过程中,那些踩过的坑、沉淀下来的心得。
1. 为什么是Aily?
SaaS系统的业务复杂度是出了名的——标品功能、定制功能、白名单功能混杂在一起,服务商家越多,每天收到的咨询和问题反馈就越多。这背后有几个根深蒂固的痛:
- 大量问题其实只是基础流程配置或简单咨询,却占用了大量人力和时间。
- 问题量太大,研发和客服根本处理不过来,紧急问题容易在洪流中被淹没,客户体验自然好不了。
- 商家的问题重复性极高,但每次都需要人工去查、去判,效率低下。
- 文档分散在各处,维护困难,答疑极度依赖个人经验,没有形成组织级的沉淀。
为了破解这个局面,我们引入了Aily智能助手。看中的是它几个核心能力:
- :基于已有的知识库和大模型能力,快速回应用户咨询,基础问题秒级响应,大幅减少人工时间。
AI智能回答,提速降本
- :能不断学习新内容,随着业务变化动态调整知识库,始终保持信息准确。
持续学习,知识库自动更新
- :能和企业自有系统无缝对接,数据流转不再有孤岛,处理结果也能回流到内部系统做闭环管理。
深度集成,打通内部系统
基于这些能力,我们搭建了
有赞门店业务智能助手
2. 门店智能助手:业务流程与真实效果
2.1 业务流程:本质上是“监听到应答”的闭环
整体逻辑不复杂:系统实时监听飞书群里的消息,智能助手通过Aily的RAG+LLM能力做智能应答。如果用户对答案不满意,还可以通过助手提供的按钮,进一步提交问题或需求。
(流程图)
2.2 深度集成:让闭环真正跑起来
整个流程和我们内部系统做了深度绑定。基于内部已有的能力底座,再加上AI的加持,把答疑、问题创建、需求跟进串成了一个完整的闭环。
(集成示意图)
2.3 实际效果:数据说话
上线不到两个月,效果可以说相当有说服力:
- 近一个月对话数超过1000+,相当于回答了1000多个问题。答疑回复和提交问题的比例大约2:1——约2/3的咨询被智能助手直接处理掉,无需人工介入。
- 基于智能助手自动总结的知识内容40+条,知识库在不断被充实,准确度也在持续上升。
- 通过助手创建的咨询或问题超过300个,紧急问题拉群处理10+,响应和处理效率明显提升。
- 而且这套方案的可复制性很高——复制给其他业务使用,搭建耗时仅1人日左右。
3. 搭建过程与实用技巧
3.1 三个阶段,逐步打磨
阶段一:先跑起来,再发现问题
第一阶段目标很简单——尽快上线。我们直接用Aily的知识问答流程,答不上来的问题调用后备技能,靠大模型判断是线上问题还是新需求,自动创建Jira。但上线后问题暴露了:很多不是问题的问题被错误创建;问题还是需求AI也傻傻分不清。结果不但没提效,反而增添了工作量。
阶段二:重构流程,人机协同
意识到AI还没法完全替代人工,我们的思路转为“人机协同”。核心做了三件事:
- 改用工作流模式,把知识问答嵌入到完整的答疑流程中。
- 给提问者更多自主权——答案不满意可以直接按按钮提交问题,避免AI误判带来的额外工作。
- 完善知识库:和公司内部AI团队合作,把对外发布的帮助中心内容向量化后纳入知识库,让数据来源更权威。
至此,工作流已经完全替代了最初的知识问答模式。
阶段三:效果调优,持续学习
第二阶段跑下来,仍然有知识库过期、隐性知识缺失、紧急问题响应慢等痛点。所以我们做了进一步优化:
- 支持话题内容自动总结,总结后同步到多维表格,再同步至Aily知识库,实现近实时更新(3小时间隔),显著提升了隐性知识的沉淀效率。
- 新增紧急问题一键拉群功能,严格权限控制,只有技术支持负责人能用,拉群后自动邀请值班人员进群,确保命中了就快速响应。
- 成本控制方面,把大模型全面切换为公司自研接口,既适配业务又降低成本。
(图片)
3.2 一些可以复用的技巧
技巧一:用总结技能实现知识库的自学习
知识库更新不及时、隐性经验没落到文档里,导致助手答不上来——这是很常见的事。但如果有其他同事在话题下给出了有效回答,就可以用总结技能把这些内容“吃”进去。
核心逻辑
(相关示意图)
技巧二:技能编排要讲“模块化”
技能编排本质上是低代码流程编排,但完全可以借鉴编程思维——把通用的逻辑抽象成独立技能,提高复用性和可维护性。
举个例子:获取飞书文档需要token,那就可以写一个“根据URL生成token”的通用技能,其他地方直接调用就行。我们把整个答疑流程抽象出了多个可复用技能,主流程反而变得非常简单。
- 封装了token获取方法
- 封装了各种消息卡片技能
- 封装了消息总结技能
- ……
(组件示意图)
技巧三:如何降低AI幻觉,提高准确性
AI给出看似正确实则错误的内容并不少见,大多是因为知识内容模糊导致的。可以从几个维度优化:
- :加入明确约束,比如“输出时不能做任何衍生、扩展或缩减”,限制AI的自由发挥。
优化prompt
- :建议设置在0.3~0.5之间,降低生成结果的随机性。
调低温度参数
- :设置标准问答对;添加术语库(尤其是有赞内部的专业术语);引入满意度反馈机制,持续修正。
完善知识库
- :在回答底部标注参考来源,并加一句「本答案由AI智能生成,仅供参考」,让用户有判断依据。
增加引用和声明
(优化前后对比图)
技巧四:大模型调用超时怎么办
一开始所有大模型节点都用GPT-4o,活跃度上来后,每天频繁出现超时或限流。和飞书技术支持沟通后得知,国外模型存在服务器不在国内的客观问题,建议改用豆包或DeepSeek。实际切换后超时情况大幅减少。目前我们的经验(不完全普适)是:
- 图片解析 → GPT-4o
- 总结、意图识别、推理 → DeepSeek-v3
- 字段提取 → 豆包
另外也可以反查流程编排里是否有多余的大模型调用节点,减少节点数同样能提高稳定性。
技巧五:上下文长度管理
当prompt中注入的参数过长(比如知识库和帮助中心查到的内容),超出大模型上下文限制后,可能会出现答非所问的情况。优化prompt、减少不必要的参数注入,就能有效缩短上下文长度。比如优化前prompt超1万字,助手给出了错误答案;优化后压到3k+,答案就对了。
此外也可以通过调整模型的max token参数来扩大上下文窗口。
技巧六:技能编排没有回滚,记得备份
技能编排修改后不支持历史版本回滚,也没法查看改动内容。建议每次修改前先复制当前技能,在新的副本上改。调试通过后再切到新版本上线,这样线上不会受影响,出问题也能快速切回。
技巧七:善用评测功能,发布前先验证
大模型回答本质上是概率性的,同样的提示词换一个模型可能就变样了。Aily的「评测」功能可以导入常用测试集做批量验证,执行后输出评测报告,通过后再上线。这就像写代码前先跑一遍单元测试——保证每次发布的功能是可靠的。
4. 总结与展望
搭建这个智能答疑助手的过程中,一个很深的体会是:真正的智能化转型,不是简单地用工具替代人,而是实现人机协同的能力跃迁。通过Aily的深度应用,我们从单一答疑场景,延伸到了多个维度的智能化升级。
除了本文重点讲的答疑,我们还尝试了其他方向的实践,效果也不错:
- AI代码审查:从构想到快速落地
- 基于Aily的线上日志告警自动分析
AI+低代码的组合,让我们能快速搭建各种应用场景,把想法快速落地并跑起来,这本身就是对创新和迭代能力的一种加速。AI的价值从来不是替代工程师,而是解放创造力。当Aily处理了80%的常规问题,我们就能腾出精力去解决那些真正重要、更有创造性的事。这或许就是技术进化的终极意义——让我们回归思考的本质。