关于ToB垂直领域大模型的一点探索和尝试

过去一年多，淘天物流技术团队一直在围绕“物流体验”这个垂直领域，摸索着如何用大模型实战解决问题。团队尝试通过一个名为“物流AI”的垂直领域大模型，去应对消费者物流咨询、物流商业化答疑、内部小二和研发的工单答疑等场景。在这个过程中，倒也逐步打磨出了一个“物流AI平台”，使用者花上1到2分钟，就能自定义场景并快速搭建一个专属的物流小助手。这些经验踩了不少坑，也有些收获，很乐意拿出来和大家聊聊。

背景

垂直领域大模型，简单来说，就是在通用大模型的基础上，喂进特定行业的知识，经过针对性训练和优化后形成的模型。比起通用模型，它更强调对某个领域的专业性，输出质量也更高、更实用。不过，一旦落地到B端场景，事情就没那么丝滑了——准确率要求极高、知识库频繁迭代，这些都构成了截然不同的挑战。

• 领域专业：
  它“懂行”——对特定领域的术语、上下文理解起来更利索。

• 高质量输出：
  在目标领域，它的回答质量普遍比通用模型要高。

• 任务表现更好：
  遇到领域内任务，它的反应比通用模型靠谱得多。

• 准确性：
  C端场景下，消费者对大模型的“发挥失常”多少还能包容——写个小说差点意思没关系。但B端不一样，商家对准确性非常敏感。但凡一次结果不靠谱，商家可能连第二次尝试的机会都不给了。B端试错成本太高。

• 知识库维护：
  B端的商家经常要更新、调整自己的知识库，而库里的素材五花八门，有流程图、PPT、PDF。如何保证大模型能高效、准确地识别不同知识体系里的信息，并且在后面的RAG过程中精准召回答案，这是个绕不开的坎。

• 适用性限制：
  垂直模型在特定领域表现很好，但换个场景就弱了。但实际使用中，又没法阻止用户问一些“非物流”的问题。所以在微调的时候，还得混进一些通用数据集去平衡。

以上是To B垂类大模型的共性特点，下面重点讲讲我们在模型层面遇到的挑战和对应的解决思路。

物流AI大致框架结构图

1、对齐增强

实际答疑时，提问者大多不会把问题描述得多细致。所以我们借用了BPO的思路——通过优化提问和给出清晰思路，让大模型更准确地理解问题，从而提升回答质量和准确率。

BPO的大致过程是这样的：先给一个初始指令，让模型针对标准的问答对（Q1，A1）生成答案（Q1， A1'），这样每个标准问答对就变成了一个三元组（Q1, A1, A1')。其中A1是“好答案”，A1'是“坏答案”。然后，让GPT4对比好答案、坏答案和问题Q，优化初始指令，生成一个调整后的指令。接着，训练一个seq2seq模型——输入是问题Q，输出就是调整后的指令。最后，把这个模型装进大模型体系里，所有用户问题都能通过这个seq2seq模型生成对应的提示信息，最后提示+问题一起喂给大模型。这套流程下来，回答准确率提升了1.8%。

举个例子：原来的问题是“天猫超市供应商如何入驻？”经过对话增强优化后，提问变成了：“你是物流部的机器人，针对天猫超市供应商入驻物流及供应链产品的流程，进行详细有条理的解答，包括入驻申请、签署协议、品牌授权、创建二级供应商、签署商务合同和确定入仓方案等步骤。”效果显著。

值得一提的是，BPO这个方法在今年的WAIC会议GLM专场也被专门提到过，确实是好用的路子。

2、Text2API

大模型作为Agent，能学会调用现有工具去解决复杂逻辑问题，这是它和传统答疑机器人显著的区别。在物流场景里，我们有超过1000个需要高频调用的API，而且其中有些还比较相似（比如查询商品信息、查询组套信息、查询货品信息）。从用户体验出发，查询API的时间需要压缩在2秒以内。如何高效、准确地识别问题中的参数，并找到对应的API，成了我们要解决的两个难题。

最初，我们用Langchain自带的React框架来做Text2API的构造，但很快发现了几个问题：第一，Langchain完全依赖底座模型——在ChatGPT4上表现很好，但在一些中文模型上就拉胯了，没法准确识别输入参数，甚至经常出现幻觉，乱编参数。其次，Langchain调用链路很长，导致处理复杂问题的Text2API时，需要做大量手动改写工作。而且React框架没有惩罚机制，调用出错了，只能人工检查并加强prompt来修正。

后来，我们引入了Reflexion框架。它和传统的Reactor相比，多了一个自我反思机制。在memory模块中，短期记忆和长期记忆都被保存下来，后续决策时，模型会基于储存的记忆诱导自己生成更好的答案。引入Reflexion后，API识别的准确率提升了4%。此外，在实际使用前，我们还利用对齐增强模块对某个API的描述进行了补充增强，这正好解决了部分相似API难以识别的问题。

3、RAG

RAG是垂类大模型经典的落地方式——通过自有领域的数据库检索相关信息，合并成提示模板，交给大模型生成最终答案。但在To B场景里，内容素材的多样性是个大的麻烦。比如下面这个白皮书文档，里面既有PDF合同、表格、系统界面截图，还有操作流程图。如何在这些文档注入时做好解析，并且在RAG召回时精准返回结果，是我们必须解决的核心问题。

拿流程图来说，我们先是让ChatGPT帮我们描述流程图里的步骤，然后人工对近1000个ChatGPT生成的结果做了review，最终放到基座模型中进行SFT + DPO。

关于文本切分，目前主要有基于深度模型的切分和基于规则的切分。我们的第一版用的是基于Transformer的切分，但实际效果不理想，后来还是换回了基于规则的切分。不过这里有一些经验可以分享：

• 如果直接把文本分割的结果当作embedding，要特别注意chunk_size的大小。太长了大模型容易忘掉中间内容，太短了又没法包含有效信息，导致关键信息被忽略。
• 不必拘泥于原文的行文结构来决定内容的前后关联度。我们引入了一个聚类方法，按「语义逻辑」重新组织内容，目前效果还不错。
• 要处理长文本，如果没法无限制地提升context，那就只能先把长文本「压缩」成短文本，尽量少减少信息量。
• 当聚类后的chunk数量超过预定值时，递归总结的过程还会再内部递归一次，一直优化到需要的长度。经过这几步优化，文本信息被重新组织成了一棵树状结构。

4、SFT

在业务团队协助下，我们沉淀了几万条标注过的物流垂类场景测评数据。这些数据是我们选择基座模型、微调方法，以及后续持续迭代模型的重要指引。基于这些数据，我们测评了市面上几乎所有的开源基座模型和能找到的全部微调方法，并利用embedding similarity、人工打分、ChatGPT4打分三个维度，分别测试了「基座模型」和「基座模型+微调」在物流场景里的表现，从而挑选出最适合我们场景的基座模型和微调方法。

实际SFT时，我们还混进了一些公开数据集，用来解决垂类大模型通用能力退化的问题。公开数据集方面，主要参考了COIG-CQIA、alpaca-gpt4-data-cn等。最近，也参考了ORPO的思路，尝试把SFT + DPO的模式变成纯粹在SFT中增加一个惩罚项，来做更好的偏好对齐。通过实验对比，ORPO比之前的链路整体效果提升了约5.2%。

落地项目和目前的结果

下面主要分享物流AI的三个主要应用场景和产品界面，欢迎感兴趣的朋友一起交流合作。

与CCO的技术团队合作，通过对图像和上下文的理解，识别消费者的问题和对应诉求，为整体的解决方案提供帮助。

通过在钉钉群部署专属物流机器人，释放部分物流技术支持者和内部小二日常答疑的工作，提升面向业务的服务能力和水平，提高自动答疑效率，节约人效成本。

与千牛的产技算团队合作，在千牛物流tab页为商家提供物流相关（时效、送货上门等）答疑和商业优化建议（择仓、择配等）。

提供快捷、轻便的一站式物流解决方案助手。只要1到2分钟，就能上传知识库，部署专属的物流助手。

这个项目是与CCO团队合作，把多模态能力嵌入物流小蜜。当消费者上传图片后，物流AI的多模态大模型会结合图像和上下文，识别消费者的问题和诉求，为后续解决方案提供帮助。因为涉及多模态，而且落地在整个小蜜链路中，所以除了前面提到的挑战，还有两个问题需要解决：

1. 在多轮对话夹杂图像的复杂场景下，准确提取相关物流属性信息（如运单号、订单号等），同时识别消费者的问题和核心诉求。
2. 在3秒以内完成图像识别、Text2API、大模型生成结果等全部流程。

目前该项目已经上线，切流50%。平均响应时间1.7秒，失败率不足1%。经过人工抽样检测，物流小蜜图片分类准确率89%，消费者问题&诉求识别准确率77%，物流要素提取准确率90%。下面是一个案例的聊天记录截图和识别结果：

{'问题': '用户遇到的核心问题是手工制作的内裤存在质量问题，如长度不一、穿着后裂开，且用户已经清洗无法退货', 
 '诉求': '用户希望申请仅退款，因为产品有质量问题且清洗后无法退货', 
 '是否协商一致': '否'}

我们正在尝试通过扩大上下文长度来提升线上模型效果。离线测试表明，引入图片中的上文信息后，用户问题和诉求的识别准确率从74.6%提升到了87.2%。项目还在快速迭代中，有最新进展再来交流。

我们把大模型技术引入到商家咨询和工单答疑系统中，为商家和内部小二提供答疑服务：

• 在物流服务实施环节，解答商家关于上门、时效等服务相关问题。目前已经服务20多个钉钉群，涉及商家1万多家。
• 在工单技术支持工作中，基于历史数据和知识库沉淀，在工单场景提供智能答疑服务，节约人效成本。目前物流AI主要应用于天猫国际平台、天猫国际直营、喵速达&考拉、天猫超市、猫淘、物流平台6个行业。AI数据库共沉淀FAQ数量2万+条，文档类3500+。

与淘宝物流部、千牛的产技算团队合作，计划在千牛的物流tab页对物流AI助手能力进行升级，向商家提供物流相关答疑服务。项目已进入研发阶段，上线后再来分享经验。

在与客户的实际接触中，我们发现物流领域涉及的知识面实在太广太杂，光靠一个知识库根本覆盖不了所有场景。所以我们就想，能不能搞一个产品，帮助物流从业人员根据自己的场景，轻便、快捷地部署专属的物流助手？这就是物流AI产品的由来。

使用起来很简单，三步搞定：场景上传（上传知识库，比如语雀文档、PDF、PPT等）、场景绑定（选择物流AI要调用的API，比如异常物流轨迹识别、包裹是否发货、商品时效等）、助手导入（把助手绑定到钉钉群或者通过API直接引入）。

以下是一些使用场景的截图：

1、查看商品物流属性，包括重量、存储条件等。

2、查看订单物流轨迹，包括中转站信息，对可能出现的异常订单做出预警。

自定义完场景后，使用者还可以直接把“自定义的物流AI”拖到自己钉钉群中使用：

总结&致谢

以上是物流AI团队在垂类大模型上的一些思考和落地实践。经过一年多的探索，虽然在不少场景上有所突破，但依然有很多未完善的地方。未来还有不少工作要展开，也欢迎各个团队的同学一起交流大模型技术。

最后，衷心感谢一直默默支持我们的前端和后端技术团队，帮我们做标注、review模型效果的业务团队，感谢UED的小姐姐，感谢合作的上下游CCO团队、千牛产技算团队，感谢老板们的大力支持，也感谢物流AI团队所有成员的辛勤付出。