开发者社区 > 博文 > 基于大模型搭建运力业务的“小红书”
分享
  • 打开微信扫码分享

  • 点击前往QQ分享

  • 点击前往微博分享

  • 点击复制链接

基于大模型搭建运力业务的“小红书”

  • zh****
  • 2024-09-29
  • IP归属:北京
  • 1浏览

    共同作者:运力平台技术部 王兰平 史季强

    运力平台部 张丽微 李苗苗

    数据平台部 刘彦辰 杨文君

    运营AI算法部 于鑫

    一、背景·问题

    1、职能人员(运营管理人员)日常工作所涉及的知识信息包括业务最新SOP、发文、操作手册等,获取渠道较分散,很多都依靠线下传递(发邮件、咚咚分享等),目前运力业务各种Sop、操作手册等文档上千个,累计文字过百万,缺乏统一查询入口,需要花费较高的时间成本去获取,耗时且体验较差

    2、一线作业人员遇到常见系统问题时主要咨询值班小秘和对接的系统人员,很多共性问题需要重复多次解答,面对一线不同用户的高频问题需要重复沟通,咨询量较大的时候无法及时响应并且沟通成本高

    3、各级管理者核心关注的报表数据缺少统一的查询工具入口,目前有通过工作台查看的,有通过EasyBi报表查看的,有通过Udata报表查询的等,数据查看存在难度,并且指标体系数量比较大,部分指标是通用型的指标数据,查询链路长,不能快速的、直接的定位到所关心的结果,并且指标体系需要用户主动查看才能看到相关问题,缺少核心数据指标恶化的主动推送

    4、从协作层面来说,针对一些临时性的信息,缺少统一的对外通知渠道,不能及时通知相关人员,造成问题的持续发酵和影响(例如当我们发现一个异常正在进行处理的时候,区域反复找过来咨询),比如上线公告、调研问卷等主动和一线交互的内容没有统一的出口

    5、从体验层面来说,现在运力相关资料获取、数据查询等操作大部分是PC端执行,缺少便携的移动端功能,一线人员不在电脑前时信息查询不方便

    二、措施·目标

    基于大模型搭建运力智能机器人“运力小智”,定位是一个集知识问答、数据分析功能于一体的便携式知识百科信息问答平台。它以运力平台日常工作所涉及的内容为核心,涵盖了业务SOP、常见系统问题、操作手册、实时类信息查询(天气、安全)、报表查询、数据分析等多项内容,致力于帮助运力用户(内部运营岗位、承运商、司机)更便捷、高效的获取有效信息,并通过大模型能力持续赋能,为用户提供个性化的推荐和良好的用户体验,减少用户获取知识的成本以及减少异常等问题的管理难度。

    从使用频次、大模型赋能的技术特点,针对一线人员和管理人员的痛点,并调研其他事业部等情况,结合运力自身业务特点综合考虑,运力机器人功能建设应用在以下两个方向推进:

    • 智能问答:通过用户和机器人的对话(包括单轮对话和上下文多轮对话),为用户解答运力日常工作中常见问题以及快速便捷进行数据信息查询,减少用户获取知识路径困难和响应不及时,释放用户问题依赖技术人工支持等问题。
    • 智能主动预警:除了支持个人用户以及群聊用户主动搜索进行对话以外,还支持面向m端/pc端指定用户、特定群组,主动发送单聊消息、语音信息(例如定时或固定周期发送报告、识别到的异常信息等)进行提示预警,让问题主动、及时的触达主责用户。

    与其他事业部智能机器人相比,一方面,通过内、外部的途径建立运力垂直领域丰富的知识、数据信息库,另外一方面,集成智能问答和数据分析为一体,统一入口,丰富机器人能力,减少用户查询成本


    运力小智一共进行两个大版本的上线,升级内容如下

    能力
    V1.0
    V2.0
    特点
    用户:部分管理者和有数据诉求的人
    功能:仅适用于简单搜索工作台链接,不能主动触达用户
    用户:目标人群为运力平台全体
    功能:已具备功能包括指标即时分析查询、系统指南、知识库、轨迹即时查询等,并具备一定主动触达能力,功能扩展到实际运营和调度岗位。
    语义理解方面
    对用户得提问有比较高得要求,需要使用非常标准的话术,机器人才能理解 在大模型能力赋能下,可以更好得理解用户得提问,对于相似语义得理解更准确和全面
    数据查询
    支持部分指标查询支持进行体验、效率指标的多维度查询
    知识查询


    常用日报、看板查询


    常用日报、看板查询
    TMS系统指南
    操作手册
    业务sop
    轨迹查询
    行驶证查询
    小秘常见问题
    报表推送
    不支持通过和udata工具结合,支持进行报表的定时推送、预警推送
    上线报告/调查问卷推送
    不支持支持上线报告/调查问卷推送

    三、实现细节

    1、知识问答

    知识问答部分借助开源框架langchain和集团提供的大模型功能接口,实现了RAG问答机器人。这部分主要包括知识库的建立和知识问答两个部分。

    下面是技术细节,并对其中的重要技术给出示例说明。

    1、知识库的构建

    知识库的构建实际上包括两个主要部分:知识的生成和知识库的存储。知识库的质量是问答系统效果的基础因素。在本项目中,根据具体需求分别建立了问答(QA)知识库和文档知识库。

    传统的运力机器人已经积累了大量的QA对,基于这些现有数据构建QA知识库,依然采用QA对的形式。此外,QA知识库的数据来源还包括两个方面:一是利用大模型从文档中抽取相关信息,二是通过分析机器人的问答日志并结合人工标注进行收集。QA类的知识在问答环节具有更高的准确性。与QA对相比,文档知识库主要包含各种类型的文档,格式包括PDF、DOCX和PPTX等。从问答质量的角度来看,文档知识库的质量可能不如QA知识库,但其数量庞大,且人工运营成本更低。文档知识库不需要将内容整理成QA对,只需将文档转换为文本格式并进行存储。通过这两种知识库的建立,可以在保证问答系统质量的同时,大幅降低人工运营成本,提高系统的整体效率和实用性。

    两种知识库建立之后,为了下游的(相似度)算法使用,均需要将待检索/待召回文本转为向量,存储在向量数据库中,此项目中选择的是京东的Vearch库。

    在文档转纯文本这个步骤中,对文档中内容的解析质量是至关重要的,包括对文档中表格内容的解析。此项目基于开源PDF解析框架进行了二次开发,解析了PDF中的章节信息,并将PDF中的表格内容进行了结构化抽取和处理,最终提升了下游生产出的知识质量。PDF的解析结果和PDF中的表格解析示例如下。

    如下:PDF的解析后的结构化结果,保留了页眉、页脚、章节信息等。正文内容被保存到了多个文本块中,每个文本块中记录了当前文本块的内容、类型(text/table)、段落id、句子id、章节id等

    {    
        "metadata": {                  # 文档级元信息
            "footers": [],             # 页脚
            "headers": [],             # 页眉
            "catalogs": []             # 目录
        },
        "chapters": {                  # 章节信息
            "1": "[CHAPTER_ROOT]",
            "1.1": "第一条 xxx",
            "1.2": "第二条 xxxx",
            "1.3": "第三条 xxxx"
        },
        "context": [                   # 内容信息
            {                          # 文本块
                "text": "JDLxxxx规定",
                "type": "text",
                "pid": 1,
                "sid": 1,
                "metadata": {
                    "section_range": []
                },
                "cid": "1"
            },
            ......
        ]
    }

    如下记录了PDF解析结果中的一个表格类文本块的示例。其中包含了每个cell的位置和内容,位置信息通过cell的四个坐标来定位。这样的结构可以在下游处理成想要的格式,如markdown、json等。并且可以标识其中单元格的合并情况。

    {
        "text": [
            [[0, 0, 1, 1], "名称"],
            [[0, 1, 1, 2], "尺寸"],
            [[0, 2, 1, 3], "三层加强材质"],
            [[0, 3, 1, 4], "售价"],
            [[0, 4, 1, 5], "三层特硬材质"],
            [[0, 5, 1, 6], "售价"],
            [[0, 6, 1, 7], "五层材质"],
            [[0, 7, 1, 8], "售价"],
            [[0, 8, 2, 9], "单卷纸生产量"],
            [[1, 0, 2, 1], "1号纸箱"],
            [[1, 1, 2, 2], "530*290*370"],
            [[1, 2, 2, 3], "130/140C/130"],
            [[1, 3, 2, 4], ""],
            [[1, 4, 2, 5], "160/160C/160"],
            [[1, 5, 2, 6], "3.50"],
            [[1, 6, 2, 7], "140/110B/90/110C/140"],
            [[1, 7, 2, 8], "3.89"],
            ......
        ],
        "type": "table",
        "pid": 89,
        "sid": 111,
        "metadata": {"section_range": []},
        "cid": "1.8",
    }
    

    2、问答结果召回

    基于RAG的知识问答流程是比较固定的:根据问题召回知识,将问题、知识、问答历史等内容拼接为大模型prompt,使用大模型进行回答。此项目中,我们额外添加了问题重新生成环节:根据问答历史对本轮问题进行重新生成,使重新生成的问题在知识相似度召回时具有更好的效果。这部分使用langchain的精简问题链实现,一段示例代码如下。

    from langchain import PromptTemplate
    from langchain.chains import LLMChain
    from langchain.chat_models import ChatOpenAI
    
    
    def get_condense_question_chain(self):
        """精简问题链"""
        CONDENSE_QUESTION_PROMPT = PromptTemplate.from_template(
            """给定历史对话和一个后续问题,将后续问题改写为一个标准问题,用其原始语言,确保避免使用任何不清晰的代词。
    历史对话:
    {chat_history}
    后续输入: {question}
    标准问题:"""
        )
        condense_question_chain = LLMChain(
            llm=ChatOpenAI(
                model="",
                temperature="",
                openai_api_key="",
                openai_api_base="",
            ),
            prompt=CONDENSE_QUESTION_PROMPT,
        )
        return condense_question_chain
    

    2、数据分析

    1、NoETL 衍生逻辑模型资产

    在数据集市生产过程中,由于生产逻辑的多变和不确定性,导致指标在不同时间粒度和下钻维度组合的情况下,统计逻辑有一定共性但难以完全复用。为了平衡逻辑模型的标准化与字段治理效率,定义了一套基于指标技术元数据衍生模型资产的编织规范。在无需额外的人力干预和物理资源投入的前提下,实现自动化生成覆盖任意时间粒度和业务维度的逻辑模型。

    模型元数据:

    {
        "uid": "742250d1dd9f457aa",
        "name": "离线_低装载线路占比_日_3",
        "nodes": [
            {
                "id": "98579cdb14b44423ace0",
                "data": {
                    "viewUid": "e246257e141e4fe78",
                    "viewSql": "SELECT dt, trans_type_new_name AS trans_type_name , -- 线路类型 transport_org_name, -- 区域 business_type_name, -- 业务类型 team_name, -- 车队 changtu_group, --长途组 low_loading_plink_cnt, plink_cnt FROM bdp_app.app_dis_tsc_product_low_loading_new_sum_d WHERE date_type = 1 AND begin_node_name = '全部' AND add1 = '全部' AND add2 = '全部' AND tail_type = '全部' AND plink = '全部' AND trans_type_old_name = '全部' UNION ALL SELECT dt, trans_type_name, transport_org_name, business_type_name, team_name, changtu_group, low_loading_plink_cnt, plink_cnt FROM bdp_app.app_dis_tsc_product_chuanbai_low_loading_rate_sum_d WHERE date_type = 1"
                },
                "type": "fact"
            }
        ],
        "where": "trans_type_name <> '全部' AND transport_org_name <> '全部' AND business_type_name <> '全部' AND team_name = '全部' AND changtu_group = '全部'",
        "measures": [
            {
                "id": 99,
                "names": [
                    "低装载线路占比"
                ],
                "sql": "SUM(low_loading_plink_cnt)/SUM(plink_cnt)",
                "type": "float",
                "format": "percentage",
                "sort": 1
            }
        ],
        "dimensions": [
            {
                "id": 1,
                "names": [
                    "区域"
                ],
                "field": "transport_org_name",
                "type": "str",
                "format": "text",
                "description": "区域"
            },
            {
                "id": 5,
                "names": [
                    "线路类型"
                ],
                "field": "trans_type_name",
                "type": "str",
                "format": "text",
                "description": "线路类型"
            },
            {
                "id": 12,
                "names": [
                    "业务类型"
                ],
                "field": "business_type_name",
                "type": "str",
                "format": "text",
                "description": "业务类型"
            }
        ],
        "timeSeries": [
            {
                "id": 1,
                "names": [
                    "日",
                    "日期",
                    "天"
                ],
                "field": "dt",
                "type": "yyyy-mm-dd",
                "format": "date"
    
            }
        ]
        "operator": "liuyanchen9",
        "updatedAt": 1714112126
    }


    2、基于模型元数据萃取统一语义知识图谱

    基于逻辑模型元数据,创建语义词典构建的调度任务,并允许业务方添加业务方言和语义同义词,与血缘沿袭关系共同组成运力业务域的语义知识图谱,目前已积累70余万实体。语义词典用于对用户的自然语言问题进行切词分析,将业务语言转化为技术语言。后通过语义血缘关系,结合RAG能力,利用时间、维度、指标、分析方法等元数据的组合,推理每个语素在知识库中的坐标,并精确匹配到相应的逻辑模型,从而实现自然语言驱动的数据查询和分析的可行性。

    血缘推理Agent原子能力:

    • 指标

    • 维度&标签

    • 维度值

    • 逻辑模型

    • 视图

    • 物理表

    3、AI增强生成SQL与分析思路

    大模型在技术生产中可以显著提高效率,尽管幻觉问题理论上无法完全消除,但前述严密优质的语义知识体系已能有效控制推理风险。在此基础上,基于准确的元素结合Prompt生成SQL,不仅逻辑精确,而且计算效率的优化表现超越绝大多数数据分析师。同时,基于准确的SQL结果,大模型有助于提供有见地的分析和解读。

    数据分析Agent原子能力

    • 自然语言问询转OLAP

    • 指标波动归因

    • 大模型增强分析与解读

    3、功能融合

    为提升业务的使用体验,确保统一平台统一问答入口出口,后台将知识问答与数据分析能力进行了有机融合。

    用户query提出后,首先调用数据分析问答接口,若意图命中输出数据类结果,若未命中数据意图,则再次请求知识问答接口,返回知识卡片结果。

    四、能力展示

    功能一:指标查询

    问答式交互数据分析:大模型数据分析与udata数据能力结合,让用户可以在京ME通过便捷灵活的问答机器人方式,统一入口快速获取数据缩短数据分析链路,提高分析效率和及时性。

    产品覆盖的指标范围简单介绍:

    体验类指标:公路到达准点率、航空到达准点率、铁路到达准点率以及他们对应的解耦指标等

    效率类指标:车次管控、到车车次货量、大车型占比、装载率、车均单量、自营车效率等

    分析维度:时间、区域、长途组、车队、线路类型、线路名称等

    以上做为大家简单的了解,详细指标产品使用方法详解如下:

    运力小智正确打开方式:

    (1)京ME中直接搜索”运力小智“或在群聊中直接艾特”运力小智“

    (2)提问格式:时间维度分析汇总维度指标名称➕想要的图表形式

    【例如】:

    • 1月西南干线装载率
    • 12月西南每个车队装载率,折线图
    • 准点率最高的2个区域
    • 苏州昆山退货组南京退货组公路到达准点率
    • 北京长途组公路到达准点率


    功能二:知识问答

    为运营人员提供日常的关于操作规范、规章制度、常见系统问题、常用看板、系统连接查询等内容;大大缩短人工检索信息的时间

    产品覆盖内容简单介绍:

    常用日报链接:运营日报,损益日报、时效日报、年货节日报

    系统网址:TMS常用网页查询

    TMS系统指南:日常咨询的运输小秘的频率较高的问题

    操作手册/sop内容查询:支持直接搜索知识库文档链接,以及文档内的关键问(知识库文档链接大全

    以上做为大家简单的了解,详细使用方法详解如下:

    运力小智正确打开方式:

    (1)京ME中直接搜索”运力小智“或在群聊中直接艾特”运力小智“

    (2)提问格式:直接用业务语言向小智提问即可

    常用日报链接:

    • 运营日报
    • 损益日报
    • 时效日报
    • 年货节日报

    系统网址

    • 委托书签收网址
    • 行云
    • easyBI网址链接

    TMS系统指南:

    • 京管家APP在哪下载?
    • 如何清除浏览器缓存?
    • 创建司机失败
    • TMS系统员工管理新增或修改员工信息时,提示该京东账号已存在
    • 舱位发布后,为啥订舱看不到?

    操作手册/sop内容查询:

    • 油耗影响因素有哪些
    • 合同倒签怎么管理
    • 运力全景图
    • 非标准附加费系统操作手册

    针对一线人员反馈的通用性的问题给予快速解答

    一线咨询问题快速转化工单,大大提高每日值班人员手动录入工单的效率

    功能三:特定场景-轨迹查询

    方便运营人员根据派车单号(TW)进行车辆轨迹查询,减少繁琐的系统操作步骤

    以上做为大家简单的了解,详细使用方法详解如下:

    运力小智正确打开方式:

    (1)京ME中直接搜索”运力小智“或在群聊中直接艾特”运力小智“

    (2)提问格式:按照TW号+轨迹 的格式向小智提问

    例如:TW24042503278457的轨迹

    功能四:特定场景-行驶证图片查询

    支持根据车牌号,查询对应的行驶证图片

    场景描述:

    当发生车辆故障、经济纠纷、交通事故等人为在途异常等情况下,运营需要通过车牌号查车辆注册时间等信息来核查异常,运营同事反馈在一些场景下不在电脑旁边时,查询很不方便,需要发给在公司的同事帮忙查询,工作效率低。

    以上做为大家简单的了解,详细使用方法详解如下:

    运力小智正确打开方式:

    (1)京ME中直接搜索”运力小智“或在群聊中直接艾特”运力小智“

    (2)提问格式:按照 车牌号+行驶证照片 的格式向小智提问

    例如:京A12345的行驶证照片

    权限控制:该功能有权限控制哦


    功能五:报表推送

    udata报表支持定时推送、预警推送2大功能

    产品覆盖内容简单介绍:

    1. 定时推送:业务关注的数据结果现可以通过京ME推送定时触达到群,收到的推送内容为全量信息;
    2. 预警推送:基于业务自身数据看板,根据所关注的达成率/指标值等进行规则的灵活设置,可以自动触达到对应责任人,提升数据分析和决策效率;

    以上做为大家简单的了解,详细使用方法详解如下:

    • 如何进行相关配置:

    1、Udata报表中心,先选择要推送的报表,选择右边的推送设置选择【京ME】-选择想要的推送方式

    2、选择推送方式:定时推送or预警推送

    3、设置推送内容:

    定时推送:

    预警推送:

    4、设置推送规则

    5、保存并发送


    🔔特别说明:如果还是不会配置可参考配置页面最上方的教学视频哦

    功能六:信息主动推送

    支持每周上线公告、调研问卷等信息主动推送


    五、效果展示

    • 从使用情况来看:

    使用人数和咨询次数逐步提升,当前每周活跃用户保持在50~100左右,咨询次数大于500+,覆盖总部九大区共154个组织,咨询人数347人,共68个岗位。;


    • 从用户体验来看:

    调度、精益改善相关岗位的智能人员,每天需要高频的查看派车单轨迹,现在工作台查询轨迹需要4步操作,查询起来需要2~3分钟,现在通过运力小智快速查询简化成一步,查询时间减少为1分钟内,大大提高了轨迹查询的效率,截止当前,轨迹相关咨询次数共1230次,一线人员反馈使用效果比较好

    针对一线调度人员,当发生车辆故障、经济纠纷、交通事故等人为在途异常等情况下,需要通过车牌号查车辆注册时间等信息来核查异常,需要对比行驶证信息,另外有些司机上传的图片是PS的,需要通过看照片抓这种PS行驶证的情况。以上两种情况下需要通过车牌号查询对应的行驶证正反面的图片信息,但是运营同事反馈在一些场景下不在电脑旁边时,查询很不方便,需要发给在公司的同事帮忙查询,工作效率低,针对这种情况,现在通过运力小智问答的方式直接返回行驶证信息,查询时间由10分钟减少为1分钟内返回结果

    • 从成功率来看

    数据分析类,运力效率、体验类指标一线人员咨询结果成功率70%左右

    知识问答类,一开始用户知识类的发散提问成功率20%~30%,引导用户熟悉使用后,现在用户特定场景的使用率提升,知识问答类成功率达到50%左右


    六、总结与规划

    运力小智是一个为了提升职能人员、管理人员工作效率的集知识类、数据类问题于一体、通过大模型的能力赋能便携性的智能机器人,致力于给运力相关用户提供高效、便捷的信息反馈,我们Q2重点实现运力小智机器人交互数据分析、知识查询、报表推送的的功能交付,在后续需要持续打磨交付效果,在保证价值功能的前提下提升查询效率和查询结果召回稳定性,提升用户体验,并进行规模化推广,后续的功能规划如下:

    序号
    分类
    内容
    内容详情
    1
    功能扩展
    上线公告推送功能
    系统上线公告机器人主动触达推送
    2
    高频场景查询功能
    包括但不限于下列场景
    1、航班起降时间查询
    2、其他高频场景
    3
    指标颗粒度
    下探车队、线路维度数据治理
    4
    性能优化
    语义理解准确性提示
    1、短期内通过引导用户尽量按照规范的格式提问
    2、长期通过对机器人大量的训练以及GPT算法能力的提升来解决
    5
    查询定位准确性提升
    增加后台日志记录,根据上游信息做判断原因后给出业务对应提示,增加问题定位和优化解决速度
    6
    数据查询服务稳定性提升
    推进集团数据公共服务层面解决


    文章数
    3
    阅读量
    263