在电商SaaS服务这片竞争激烈的红海中，商家对于客服系统的依赖程度早Yi不言而喻。当大模型的浪潮刚刚开始拍打岸边时我们就敏锐地嗅到了变革的气息。特别是从2025年年初开始，有赞决定在这个领域投入重兵，试图探索出一条属于我们的AI客服之路。今天我想抛开那些官方的套话，纯粹从研发的视角，和大家聊聊这段从0到1的实战经历。这不仅仅是代码的堆砌，geng是一场关于思维模式的重塑。

回溯整个项目的起点，其实并非源于一份详尽无比的PPT，而是诞生于有赞内部一场充满激情的“黑客马拉松”。当时的时间非常紧迫，为了赶工期，团队面临着一个极其现实的选择：是使用智Neng体化的开发平台，还是老老实实地写工程化代码？

坦白讲，那时候我们gengkan重速度。为了迅速验证产品市场契合度，我们果断选择了前者。有赞内部独立部署了一套Dify环境，这在当时是个非常明智的决定。Dify在迭代效率以及工具集成方面的表现，确实让我们尝到了甜头，帮助我们在极短的时间内就跑通了第一个版本。这就像是在迷雾中找到了一盏灯，虽然光线微弱，但至少证明了方向是对的。

项目初期，除了工具链的选择，开发模式的确定也让我们纠结了hen久。是在Workflow和Agent之间如何取舍？这不仅是技术选型，geng是对产品可控性的一种考量。

我们深知，Agent虽然听起来hen酷，具备高度的自主性，但在实际落地中，其结果的确定性、性Neng表现往往不尽如人意。对于商家而言，客服系统的稳定性远比“智Neng”geng重要。因此，我们Zui终选择了比较保守的Workflow模式。先搭建起一个稳定的流程骨架，去追求那些确定的、我们Ke以完全掌控的结果。

现在回过头来kan，当初坚持走工作流这条路绝对是正确的。我们从工作流入手，像剥洋葱一样，逐步引入并解决每一个遇到的问题，在效果、成本和可控制程度之间找到了一个相对完美的平衡点。

AI客服的大脑固然重要，但Ru果没有高质量的知识输入，它也只是一个只会说漂亮话的“花瓶”。在知识工程方面我们主要面临两大挑战：文档知识的处理和商品信息的获取。

商家的文档知识主要是在后台上传的。技术上，这其实是一个在“上下文完整性”与“信息密度”之间走钢丝的过程。我们通过反复调整文本切片的字符数和重叠字符数，试图寻找那个动态的平衡点。

这里面的门道hen多，chunk_size直接决定了模型单次Neng承载多少信息，而chunk_overlap则是为了缓解边界断裂的问题，保持语义的连贯性。经过无数次的测试与调整，我们才摸索出了一套Zui适合当前业务的参数配置。这不仅仅是数字的游戏，geng是对模型理解Neng力的深度试探。

商品知识是客服咨询的重头戏，主要分为“预学商品信息”和“实时商品信息查询”两部分。我们的目标hen明确：当用户询问商品相关问题时模型Neng依据这些知识给出精准的回答。

对于商品详情、主图、规格等静态信息，我们会预先写入向量数据库。这里有个有趣的技术细节，在图片信息提取上，我们没有采用传统的OCR方案，而是直接利用模型的多模态Neng力。这种方式就像是一个具备常识的“图片解读者”，它不仅Neng处理结构化信息，还Neng聪明地过滤掉图片中的冗余内容和无效信息。

但是光有静态信息是不够的。商品状态、库存、预售商品的物流等动态信息，时刻dou在变化。对于这些数据，我们采用实时查询的方式获取，并在特定的流程节点将这些信息拼接到上下文中。这种动静结合的策略，极大地提升了回答的准确性。

当然模型提取知识并非完美无缺。我们也遇到过尴尬的情况，比如商品规格里明明没有紫色的车，但商品详情的图片里却误展示了结果导致模型一本正经地胡说八道。这提醒我们，数据源的质量才是根本。

随着业务量的增长，我们发现全量加载信息会导致模型因为信息干扰而产生严重的“幻觉”。为了解决这个问题，我们构建了一套路由和过滤机制，确保上下文的“信噪比”。

早期，我们只是简单地把知识片段拼接成文本字符串。但后来发现，即便Zuo了筛选，依然无法完全规避知识重叠、冲突以及信息过载。于是我们开始尝试结构化的方式组装信息，甚至采用了类似XML的标签结构来定义知识优先级。

例如我们会将上下文结构化为：

<知识库> 
  <商品信息> 
    <商品名称>知识片段x 
    <商品详情>知识片段x 
   
  <物流政策信息> 
    知识片段x 
   
  知识片段x

通过这种方式，再配合提示词的引导，我们显著减少了模型产生幻觉的概率。

模型是AI客服的心脏，选对模型至关重要。在早期版本中，为了追求效果，我们使用了当时表现Zui好且Zui熟悉的模型，几乎把所有事情dou交给它去处理。那时候的意图识别节点，身兼数职，既要负责问题 ，又要识别重复问题和负面情绪。虽然快速完成了1.0版本上线，但成本压力也随之而来。

1.0版本上线后降低成本成了当务之急。除了常规的压缩提示词、优化知识分块和召回策略外我们Zuo了一个大胆的决定：将意图识别所用的GPT-4.1切换为Qwen模型，并对意图识别节点进行了拆分。

不过切换模型并非一帆风顺。使用Qwen模型后我们发现Dify原本的记忆机制对其非常敏感，反而加剧了幻觉现象。没办法，我们只Neng自己动手，维护一个全局变量来存储历史对话信息，并将这些信息手动拼接到重复问题、负面情绪、问题 与意图识别节点的System提示词中。虽然麻烦了点，但效果确实立竿见影。

AI项目的开发测试，与传统软件有着根本性的差异。传统软件测试通常针对固定目标，流程标准化，结果可复现。但Agent的评测，却要面对其自身的不确定性、开放性与场景多样性。模型一换、提示词一调，整个系统的表现可Neng就大相径庭。

因此，建立一套有效的评测体系显得尤为关键。我们认为，一个完整的评测体系必须包含评测对象、评测数据集、评估指标以及反馈优化机制。

在项目上线前，我们从历史对话中提取内容，并人工构造了一部分测试集。上线后我们则依据线上实际流量，筛选出Goodcase和Badcase，不断充实数据集。确立评估指标是其中Zui具挑战的一环，单纯依赖人工判断难以全面覆盖，所以我们还会依据历史对话数据，运用评估器来判断内容的相似度，进行综合评估。

在这个过程中，产品和研发必须把控好整个流程，重点关注指标和效果反馈。测试人员则应将精力投入到评测的基础建设以及用例集方面尽可Neng提升“评测 -> 优化 -> 再评测”这一循环的效率。同时我们还会对线上流量进行实时监控巡检，构建“问题识别 -> 根因分析 -> 优化迭代”的数据闭环，达成从Badcase到模型迭代的良性循环。

在系统运行一段时间后我们遇到了瓶颈。由于我们采用的是意图识别和分发策略，这是一种较为保守的Zuo法——宁可让AI不回答问题，也不Neng让它答错。这导致AI承接率到了一定阶段就hen难再往上走了。

要想有所提升，就得拓展场景。我们开始尝试从历史对话中学习，筛选高频的问答来补充知识。虽然这个过程推进了hen久，直到后期才kan到明显进展，但积累的经验是宝贵的。

为了进一步提高承接率，我们决定开始承接售后问题咨询。这时候，一个新的决策摆在了面前：售前和售后是共用一套流程，还是分开处理？经过对业务特性的深入分析，我们发现售前与售后问题的回复风格存在显著差异——售前需要主动热情，售后则需要严谨专业。加上所需知识库的不同，以及单节点复杂度的考量，我们Zui终选择了分开处理。

当然我们当前的流程并非完美无缺。比如意图识别节点的职责依然不够单一，问题 与意图识别还在共用一个节点。售后问题分类节点的功Neng也与意图识别存在部分重叠。但工作流的设计本就是一个渐进式的演进过程，随着业务复杂度的提升，流程必将逐步优化。

从Zui初“黑客马拉松”式的灵感碰撞，到如今步入稳定运行、持续进化的新阶段，有赞AI客服的从0到1，不仅是一次技术栈的升级，geng是一场研发模式与思维方式的深度变革。

这段经历让我们深切感受到，AI项目和传统软件研发有着巨大的不同。它充满了不确定性，需要我们具备geng强的耐心和geng灵活的应对策略。未来我们将继续秉持“宁可不答，不Neng答错”的严谨态度，不断拓宽AI的应用边界，为商家提供geng高效、geng具温度的智Neng服务体验。

AI浪潮下智Neng客服的演进没有终点。我们依然在路上，摸着石头过河，但这一次我们kan得geng清，走得geng稳。