原文标题：关于ToB垂直领域大模型的一点探索和尝试
原文作者：阿里云开发者
冷月清谈：
- 专业性和实用性更强
- 可针对特定领域进行优化，输出质量更高
ToB场景的挑战：
- 对准确性的要求更高
- 知识库维护和更新更频繁
- 适用性受限，对非目标领域表现不佳
物流AI搭建过程中的技术要点：
- **对齐增强：**采用BPO方法，优化用户提问的准确性，提高模型回答质量
- **Text2API：**将复杂问题转换为API调用，提高问题理解和API识别精度
- **RAG：**通过自有数据库和提示模板，检索相关信息并输出答案
- **SFT：**利用标注数据和公开数据集，挑选和微调适合物流场景的基座模型和微调方法
物流AI的应用场景：
- 物流小蜜：图片识别+多模态理解，帮助消费者解决物流问题
- 钉钉机器人：提供物流相关答疑和商家咨询服务
- 千牛物流商家后台：为商家提供物流相关咨询和优化建议
- 物流AI产品：一站式物流解决方案助手，可根据场景定制专有物流小助手
怜星夜思：
2、eCommerce场景下，如何利用垂类大模型为客户提供个性化的购物体验？
3、如何评估垂直领域大模型的效果，有哪些定量和定性指标？
原文内容
阿里妹导读
背景
大家好，我们是淘天物流技术团队，在过去一年多的实践工作中，我们团队围绕“物流体验”这一垂直领域，尝试通过垂直领域大模型“物流AI”为消费者物流相关咨询、物流商业化答疑、内部小二/研发的工单答疑等场景提供快捷、轻便的大模型能力。同时，我们又在实践探索中，慢慢打磨了“物流AI平台”，支持使用者可以在1-2分钟内就可以自定义场景并创建专属于自己的物流小助手。在此也把这两年的一些经验分享出来，希望跟大家一起交流和探讨。
垂直领域大模型的一些特点
垂直领域大模型是指以通用大模型作为base model，再喂以特定领域或行业的领域知识，经过训练和优化的大语言模型。与通用语言模型相比，垂直领域大模型更专注于某个特定领域的知识和技能，具备更高的领域专业性和实用性。但因为B端场景的一些特殊性（比如对于准确性的要求、知识库的频繁迭代等），To B大模型也面临着不一样的挑战。
垂直领域大模型的优势
-
领域专业性：垂直领域大模型经过专门的训练，能够更好地理解和处理特定领域的知识、术语和上下文。
-
高质量输出：由于在特定领域中进行了优化，垂直领域大模型在该领域的输出质量通常比通用大模型更高。
-
特定任务效果更好：对于特定领域的任务，垂直领域大模型通常比通用大模型表现更好。
To B场景的挑战
-
准确性：C端场景下，消费者对于大模型的产出都有一定的容忍度，比如写个小说、画个图。大模型只要回答的不是太差，消费者对于结果都会一定程度的接受。但B端场景，商家对于大模型产出的结果的准确性更加敏感。同时大模型在B端的试错成本很高，如果一次结果不满意，商家可能就不愿意用第二次。
-
知识库维护：B端场景下，商家经常频繁的更替、维护自己的知识库，并且知识库里面的素材多种多样，有流程图、ppt、pdf等。如何保证大模型高效、准确的识别不同知识库体系里面的相关知识，并为后续的RAG召回高质量的答案是需要面临和解决的挑战。
-
适用性限制：B端场景的垂类大模型在特定领域中的适应性较强，但在其他领域的表现可能相对较弱。但我们在实际使用中，又不能完全杜绝使用者会问一些“非物流”相关的问题，所以在实际的微调过程中，需要与一些通用数据集合并在一起进行微调。
以上是To B垂类大模型的一些特点，下面主要分享下这段时间遇到的模型层面的一些挑战和对应的解决方案。
物流AI大致框架结构图
1、对齐增强
2、Text2API
-
langchain完全依赖底座模型，在chatgpt4上表现很好。但在一些中文模型上无法很好识别api的输入参数，经常出现幻觉导致乱编参数的现象。
-
langchain调用链路很长，导致我们在改写较复杂问题text2api的时候会有大量的工作。并且react框架因为没有penalty机制，如果出现调用错误的情况，只能人工检查然后通过增强prompt的方式进行修正。
3、RAG
如何解决复杂的素材：以流程图为例，我们首先让chatgpt帮我们描述流程图里面对应的步骤，然后我们人工对近1000个chatgpt4生成的结果进行review，并最终放到我们的基座模型中进行sft + dpo。
-
如果将文本分割的结果直接作为embedding，需要特别注意chunk_size大小，太长了大模型容易忘掉中间的内容，太短了又不能包含有效的信息，从而导致关键信息而被忽略；
-
不需要拘泥于原来的文章的行文结构来决定内容的前后关联度，我们引入了一个聚类的方法重新把内容通过「语义逻辑」重新组合，目前来看效果还不错；
-
为了使LLM处理长文本，如果不能无限制的提升context的话，就只能掉过头来先把长文本「压缩」成短文本而尽量不要减少信息量；
-
当聚类之后的 chunk 数量超过了预定的值之后，递归总结的过程还会在内部再次进行递归总结，一直优化到需要的长度。基于上面几步优化，文本信息被重新组织、优化成一棵树。
4、SFT
落地项目和目前的结果
物流小蜜
这个项目是与cco团队合作，将多模态能力嵌入到物流小蜜当中，当消费者上传图片后，会调用物流AI多模态大模型，通过对图像以及上下文的理解，识别消费者的问题和对应诉求，为后续整体的解决方案提供帮助。因为这个模块涉及到多模态，并且落地在整个小蜜的链路中，所以除了前面提到的一些挑战，还有以下2个问题需要克服：
物流AI最终识别结果：
{
'问题': '用户遇到的核心问题是手工制作的内裤存在质量问题，如长度不一、穿着后裂开，且用户已经清洗无法退货',
'诉求': '用户希望申请仅退款，因为产品有质量问题且清洗后无法退货',
'是否协商一致': '否'
}
钉钉群物流服务商家咨询答疑机器人
我们尝试将大模型技术引入到商家咨询和工单答疑系统中，为商家和内部小二提供相关答疑服务：
-
在物流服务的实施环节，我们为商家解答上门、时效等服务相关的问题。目前已经服务20+钉钉群，涉及商家1w多。
-
在工单技术支持工作中，基于工单历史数据、知识库沉淀，在工单场景提供智能答疑服务，节约人效成本。目前物流AI主要应用于天猫国际平台、天猫国际直营、喵速达&考拉、天猫超市、猫淘、物流平台6个行业。AI数据库共沉淀FAQ数量2W+,文档类3500+。
工单答疑场景
千牛物流商家后台
跟淘宝物流部、千牛的产技算团队进行合作。计划在千牛的物流tab页，对物流AI助手能力进行升级，从而给商家提供物流相关答疑服务。目前这个项目已经进入研发阶段，待项目上线后再跟大家分享经验。
自定义完场景后，使用者也可以将“自定义的物流AI”直接拖到自己的钉钉群中进行使用：
总结&致谢
自建数据库迁移到云数据库
本方案介绍如何将网站的自建数据库迁移至云数据库 RDS，解决您随着业务增长可能会面临的数据库运维难题。数据库采用高可用架构，支持跨可用区容灾，给业务带来数据安全、可用性、性能和成本方面收益。方案提供了快速体验教程，模拟了数据库迁移所需的工作，帮助您快速上手。
点击阅读原文查看详情。