1. 项目缘起当“降本增效”遇上“AI焦虑”最近公司业务量上来了客服团队的压力肉眼可见地增大。每天几百个咨询涌进来重复性问题占了六七成像“怎么下单”、“运费多少”、“订单怎么查”这类问题客服同学敲键盘敲到手软用户还得排队等。老板天天念叨“降本增效”技术团队自然就成了被寄予厚望的“救火队”。一开始我们考虑过采购成熟的SaaS客服系统但一看报价单和那堆复杂的定制化流程再想想我们业务里那些奇奇怪怪的定制逻辑感觉就像穿别人的鞋走自己的路怎么走怎么别扭。于是一个大胆或者说被逼无奈的想法冒了出来既然现在大语言模型LLM这么火各种开源框架和工具也层出不穷我们能不能自己动手用AI“肝”一个智能客服助手出来目标很明确不是要做一个能聊哲学、写诗歌的“贾维斯”而是要一个能精准理解用户意图、快速回答高频问题、并且能无缝接入我们现有业务系统的“实干派”。这个想法得到了团队的支持也成了接下来一周“爆肝”之旅的起点。这不仅仅是一个技术项目更像是一次在AI应用浪潮下的务实探索如何用有限的资源把前沿的LLM技术真正落地到一个具体的、能产生价值的业务场景里。2. 核心架构选型在“轮子”与“造轮子”之间做选择决定自研后第一个灵魂拷问就是从零开始还是站在巨人的肩膀上现在LLM应用开发的生态已经非常丰富各种框架和平台让人眼花缭乱。我们需要一个既能快速搭建原型又具备足够灵活性应对复杂业务逻辑的方案。2.1 模型层闭源巨兽 vs. 开源轻骑模型是智能客服的“大脑”选型直接决定了能力上限、成本和可控性。闭源模型如GPT-4、Claude-3能力强大开箱即用在复杂逻辑、多轮对话和意图理解上表现优异。但缺点也很明显API调用有成本且存在速率限制比如热词里提到的error code: 429就是触发了速率限制。更关键的是数据需要出境在涉及用户隐私和订单等敏感信息时存在合规风险。对于企业内部或对数据安全要求高的场景这几乎是“一票否决项”。开源模型如 Llama 3、Qwen、ChatGLM可以本地或私有化部署数据完全自主可控这是最大的优势。经过微调Fine-tuning后在特定领域比如我们的电商客服话术上表现可以非常精准。但挑战在于需要一定的机器资源GPU并且对提示词工程Prompt Engineering和微调技巧要求更高。对于“智能客服”这个相对垂直的领域我们判断一个7B或13B参数量的开源模型经过适当调教完全能满足需求。我们的选择经过评估我们决定采用开源模型路线。核心原因是数据安全与长期成本。我们选择了一款在中文理解和指令跟随上表现较好的7B模型作为基座计划后续用我们的客服日志进行微调。初期为了快速验证我们使用了托管的开源模型API服务避免了自建GPU环境的复杂同时保留了未来完全私有化部署的弹性。2.2 应用框架层LangChain vs. “轻量级组合拳”框架能极大提升开发效率。LangChain 及其生态如 LangGraph无疑是当前最流行的LLM应用框架它提供了链Chain、代理Agent、工具调用等高级抽象。热词里也提到了LangChain 工具调用 和 LLM function call 有什么区别这确实是个关键点。LangChain的工具调用它是一个更上层的封装将Function Calling的能力标准化并集成了大量的外部工具如搜索引擎、数据库。它的优势在于生态丰富能快速构建复杂的多步推理流程Agent。但它的抽象有时会带来额外的复杂性和性能开销热词中也提到了“速度受什么影响”的疑问对于追求极致性能和简洁架构的项目可能显得有些“重”。原生Function Calling许多LLM包括OpenAI和部分开源模型现在都原生支持了函数调用功能。这更接近底层延迟更低控制更精细。但你需要自己管理工具的定义、调用和结果处理逻辑。我们的选择考虑到智能客服的核心流程相对固定意图识别→知识检索→回复生成并不需要非常复杂的、动态规划路径的Agent我们放弃了使用全功能的LangChain。而是采用了一种“轻量级组合拳”模式使用FastAPI构建核心后端服务直接利用LLM的原生Function Calling或结构化输出能力来处理意图识别用精心设计的Prompt模板来驱动对话用独立的模块处理知识库查询和业务系统调用。这样做的结果是架构更清晰性能更可控调试也更直接。Dify这类低代码平台我们也评估过它非常适合快速搭建原型和可视化编排工作流如热词提到的将输出保存到Word但面对我们高度定制化的业务逻辑集成需求时灵活性略显不足因此作为备选而非核心。2.3 核心模块设计一个务实的三段式管道我们的智能客服助手最终被设计成一个清晰的管道Pipeline流程包含三个核心模块意图识别与槽位填充模块这是第一道关卡。用户输入“帮我查一下订单123456的物流状态”这个模块需要识别出意图是“查询物流”并提取出关键参数槽位“订单号: 123456”。我们利用LLM的零样本或少样本提示能力将其定义为一个文本分类和实体抽取任务要求模型返回结构化的JSON数据。这比传统的基于规则或机器学习的方法开发效率高得多且泛化能力更好。决策与执行模块根据识别出的意图决定下一步做什么。如果是“查询物流”就调用内部的订单系统API如果是“退货政策”就转向知识库检索如果是复杂业务如“我要退货因为商品破损”则可能进入一个预设的多轮对话流程。这里我们为每个意图预定义了对应的“工具函数”或“处理流程”。知识库与回复生成模块对于需要从知识库回答的问题我们采用了经典的RAG检索增强生成架构。将公司的产品文档、客服手册等非结构化文本进行切分、向量化存入向量数据库如Chroma、Milvus。当用户提问时先根据问题检索出最相关的几个知识片段然后将“问题知识片段”一起组合成Prompt交给LLM生成最终回复。这确保了回复的准确性和信息实时性避免了LLM“胡言乱语”。这个“意图识别→决策执行→检索生成”的三段式管道逻辑简单直接每个模块都可以独立优化和迭代构成了我们智能客服的骨干。3. 实战开发从Prompt工程到系统集成的“踩坑”实录架构画起来很美但真正开发起来全是细节。这一周大部分时间其实都是在解决一个个具体的问题。3.1 驯服LLM意图识别的稳定性之战让LLM稳定地输出结构化的意图识别结果是第一个挑战。最初我们只是简单地在Prompt里写“请判断用户意图”结果模型一会儿返回中文一会儿返回英文格式五花八门根本无法被程序解析。解决方案与心得严格的输出格式指令在Prompt中必须使用非常明确的指令例如“请严格按以下JSON格式输出不要有任何额外解释{“intent”: “意图类别”, “slots”: {“参数1”: “值1”}}”。甚至可以提供几个清晰的示例少样本学习。使用支持结构化输出的模型或库有些开源模型社区提供了强制结构化输出的微调版本或配套库如instructor、outlines。我们最终选择了一个在提示词中声明格式后服从性特别好的模型这步选择节省了大量后期调试时间。后处理与降级策略代码中必须包含对模型输出结果的健壮性解析。如果JSON解析失败不能直接崩溃而是应该有一个降级策略比如将整个用户输入传递给一个更通用的“问答”意图处理流程或者返回一个让用户澄清的提示。注意意图的分类体系设计至关重要。不要一开始就追求大而全应该从最高频的10-20个意图开始如“查询订单”、“咨询运费”、“退货申请”等。过于精细的意图分类会增加模型识别难度和后续流程的复杂度。3.2 知识库的“质”与“量”RAG效果提升关键RAG听起来高大上但效果极度依赖知识库的构建质量。我们一开始把整本PDF手册直接切分成固定大小的文本块扔进向量数据库结果检索出来的片段经常文不对题或者缺少关键信息。核心优化点智能文本分割放弃简单的按字符数切割采用基于语义的分割方法比如优先在段落、标题处进行切割确保每个文本块都是一个相对完整的语义单元。也可以使用递归分割确保块大小适中且语义连贯。优化检索策略不仅仅是简单的向量相似度检索。我们结合了关键词检索BM25和向量检索的混合搜索。例如先通过关键词快速筛选出相关文档再用向量排序进行精排这样既能保证召回相关文档又能根据语义相似度进行高质量排序。元数据过滤为每个文本块添加丰富的元数据如“所属产品线”、“文档类型用户协议/操作指南”、“更新日期”等。在检索时可以根据用户问题中隐含的信息通过LLM提取对元数据进行过滤大幅提升检索精度。比如用户问“旗舰版会员有什么权益”我们可以过滤出“产品线: 会员服务”且“文档类型: 权益说明”的文本块。Prompt工程优化给LLM的Prompt里需要明确指令“请严格基于以下提供的参考信息来回答问题。如果信息中没有明确答案请直接回答‘根据现有资料我暂时无法回答这个问题您可以联系人工客服进一步咨询。’” 这能有效防止模型幻觉胡编乱造。3.3 与业务系统的“握手”工具调用的可靠性当意图识别出需要查询订单状态时就需要调用内部的订单系统API。这涉及到几个问题认证与授权智能客服后端服务如何安全地获取调用业务系统API的令牌Token我们采用了独立的服务账号和固定的API密钥并严格限制了该账号的权限范围只允许查询禁止任何写操作。错误处理业务API可能超时、返回错误或数据为空。我们的执行模块必须有完备的重试机制、超时设置和友好的降级回复。例如“系统正在查询请稍后重试”或“暂时未能查到您的订单信息请确认订单号是否正确”。数据格式化从业务API获取的原始数据可能是复杂的JSON需要被转换成用户能看懂的自然语言。我们让LLM承担了这个“格式化”工作将API返回的数据和一段指令“请将以下订单信息用友好、清晰的方式告知用户”一起交给模型生成最终回复。这样比手动编写模板灵活得多。3.4 会话管理的挑战记住“上一句说了什么”真正的对话不是一问一答而是有上下文关联的。用户可能会说“上一个订单”或者回答系统提出的问题“您指的是哪个商品”。这就需要会话管理Session Management。我们的实现方案会话标识为每个独立的对话窗口可以是网页、App会话创建一个唯一的Session ID。上下文缓存在内存或Redis中为每个Session ID维护一个对话历史列表。这个列表不仅存储用户和AI的对话内容最好也存储每一轮对话中识别出的意图和槽位信息。上下文窗口与摘要LLM的上下文长度有限比如4K或8K Token。当对话轮次增多历史记录会超出限制。我们采用了一种简单的策略只保留最近N轮如5轮的原始对话对于更早的历史则使用另一个LLM调用将其摘要Summarize成一段简短的背景说明放在Prompt的开头。例如“之前用户咨询了退货流程并提供了订单号123456。”这样既能保持上下文连贯又不会过度消耗Token。4. 效果评估与迭代不仅仅是“准确率”开发完成后我们并没有直接上线而是进行了严格的内部测试和评估。评估一个智能客服不能只看技术指标。4.1 多维度的评估体系我们建立了一个简单的评估矩阵意图识别准确率用一批标注好的测试用例看模型是否能正确分类和抽取参数。这是基础。任务完成率对于可执行的任务如查订单最终是否能成功调用API并返回有效结果这衡量了系统集成的可靠性。回答满意度人工评估我们让多名同事模拟真实用户进行对话从“回答准确性”、“语言流畅度”、“有用性”三个维度进行打分。这是最主观但也最重要的指标。人工接管率在测试对话中有多少比例的问题需要触发“转人工”响应延迟从用户发送消息到收到回复的平均时间。这直接影响用户体验我们的目标是压到1.5秒以内。4.2 构建反馈闭环让系统自我进化上线不是终点。我们设计了两个关键的反馈循环主动学习Active Learning系统会记录下所有“低置信度”的意图识别结果比如模型对自己判断的把握度低于某个阈值以及所有用户最终选择“转人工”的对话。这些数据被定期收集、清洗和标注形成新的训练数据用于后续的模型微调。这是提升模型在业务领域表现的最有效途径。日志分析与Bad Case复盘每天查看对话日志寻找典型的失败案例。例如用户说“它不亮了”模型可能无法关联到“产品故障咨询”意图。这类案例需要被抽象成新的意图或补充到现有意图的训练数据中。5. 一周“爆肝”后的反思与避坑指南回顾这一周的高强度开发虽然成果可喜但踩的坑也不少。以下是几条血泪教训供后来者参考不要过早追求完美的Agent架构除非你的业务逻辑极其复杂且非确定性高否则在初期一个设计良好的管道Pipeline模式比一个全能的Agent更简单、更稳定、更易调试。热词中提到的LLM、Agent、RAG、Harness的层级架构对于智能客服来说RAG和精准的意图识别是地基Agent更像是锦上添花的“大脑皮层”初期可以简化。数据准备比模型选型更重要无论是用于意图识别的示例数据还是用于RAG的知识库文档其质量直接决定了系统效果的上限。花在数据清洗、整理和标注上的时间回报率远高于反复切换不同的LLM模型。在知识库构建上多花一天时间优化文本分割和添加元数据可能让检索准确率提升30%。必须为“未知”和“失败”设计路径LLM再强也有不懂的时候外部API再稳定也可能挂掉。你的系统必须能优雅地处理这些情况识别为“未知意图”时如何引导用户调用失败时如何给出不令用户沮丧的反馈一个设计好的“转人工”入口和友好的降级话术比一个报错的空白页面重要一万倍。性能监控与成本意识要从第一天开始记录每一次LLM调用的Token消耗、响应时间、费用如果用商用API。设置告警当平均响应时间或错误率超过阈值时及时通知。对于开源模型要监控GPU显存使用和推理速度。这些数据是未来优化和扩容决策的基础。安全与合规是底线我们的数据没有出境这是基本原则。此外在Prompt中要加入明确的指令禁止模型生成任何有害、歧视性或涉及公司机密的信息。对于用户输入也要有基本的敏感词过滤和内容审核机制即使是内部测试版。这一周我们从一个模糊的需求出发到最终跑通一个能处理十几种核心意图、能查订单、能问知识库的智能客服原型过程充满了挑战但收获巨大。它不是一个完美的产品但是一个极佳的起点。AI技术的应用尤其是LLM正在从“炫技”走向“务实”。对于我们开发者而言最重要的能力或许不再是追逐最前沿的模型而是如何将这些强大的能力用稳定、可靠、低成本的方式缝合到复杂的真实业务场景中去解决那些实实在在的痛点。这条路我们才刚刚开始。