作者：京東物流 朱飛

一、背景·問題

1、職能人員（運營管理人員）日常工作所涉及的知識信息包括業(yè)務最新SOP、發(fā)文、操作手冊等，獲取渠道較分散，很多都依靠線下傳遞（發(fā)郵件、咚咚分享等），目前運力業(yè)務各種Sop、操作手冊等文檔上千個，累計文字過百萬，缺乏統(tǒng)一查詢入口，需要花費較高的時間成本去獲取，耗時且體驗較差

2、一線作業(yè)人員遇到常見系統(tǒng)問題時主要咨詢值班小秘和對接的系統(tǒng)人員，很多共性問題需要重復多次解答，面對一線不同用戶的高頻問題需要重復溝通，咨詢量較大的時候無法及時響應并且溝通成本高

3、各級管理者核心關注的報表數(shù)據(jù)缺少統(tǒng)一的查詢工具入口，目前有通過工作臺查看的，有通過EasyBi報表查看的，有通過Udata報表查詢的等，數(shù)據(jù)查看存在難度，并且指標體系數(shù)量比較大，部分指標是通用型的指標數(shù)據(jù)，查詢鏈路長，不能快速的、直接的定位到所關心的結果，并且指標體系需要用戶主動查看才能看到相關問題，缺少核心數(shù)據(jù)指標惡化的主動推送

4、從協(xié)作層面來說，針對一些臨時性的信息，缺少統(tǒng)一的對外通知渠道，不能及時通知相關人員，造成問題的持續(xù)發(fā)酵和影響（例如當我們發(fā)現(xiàn)一個異常正在進行處理的時候，區(qū)域反復找過來咨詢），比如上線公告、調研問卷等主動和一線交互的內容沒有統(tǒng)一的出口

5、從體驗層面來說，現(xiàn)在運力相關資料獲取、數(shù)據(jù)查詢等操作大部分是PC端執(zhí)行，缺少便攜的移動端功能，一線人員不在電腦前時信息查詢不方便

二、措施·目標

基于大模型搭建運力智能機器人“運力小智”，定位是一個集知識問答、數(shù)據(jù)分析功能于一體的便攜式知識百科信息問答平臺。它以運力平臺日常工作所涉及的內容為核心，涵蓋了業(yè)務SOP、常見系統(tǒng)問題、操作手冊、實時類信息查詢（天氣、安全）、報表查詢、數(shù)據(jù)分析等多項內容，致力于幫助運力用戶（內部運營崗位、承運商、司機）更便捷、高效的獲取有效信息，并通過大模型能力持續(xù)賦能，為用戶提供個性化的推薦和良好的用戶體驗，減少用戶獲取知識的成本以及減少異常等問題的管理難度。

從使用頻次、大模型賦能的技術特點，針對一線人員和管理人員的痛點，并調研其他事業(yè)部等情況，結合運力自身業(yè)務特點綜合考慮，運力機器人功能建設應用在以下兩個方向推進：

?智能問答：通過用戶和機器人的對話（包括單輪對話和上下文多輪對話），為用戶解答運力日常工作中常見問題以及快速便捷進行數(shù)據(jù)信息查詢，減少用戶獲取知識路徑困難和響應不及時，釋放用戶問題依賴技術人工支持等問題。

? 智能主動預警：除了支持個人用戶以及群聊用戶主動搜索進行對話以外，還支持面向m端/pc端指定用戶、特定群組，主動發(fā)送單聊消息、語音信息（例如定時或固定周期發(fā)送報告、識別到的異常信息等）進行提示預警，讓問題主動、及時的觸達主責用戶。

與其他事業(yè)部智能機器人相比，一方面，通過內、外部的途徑建立運力垂直領域豐富的知識、數(shù)據(jù)信息庫，另外一方面，集成智能問答和數(shù)據(jù)分析為一體，統(tǒng)一入口，豐富機器人能力，減少用戶查詢成本

?

運力小智一共進行兩個大版本的上線，升級內容如下

能力	V1.0	V2.0
特點	用戶：部分管理者和有數(shù)據(jù)訴求的人 功能：僅適用于簡單搜索工作臺鏈接，不能主動觸達用戶	用戶：目標人群為運力平臺全體 功能：已具備功能包括指標即時分析查詢、系統(tǒng)指南、知識庫、軌跡即時查詢等，并具備一定主動觸達能力，功能擴展到實際運營和調度崗位。
語義理解方面	對用戶得提問有比較高得要求，需要使用非常標準的話術，機器人才能理解	在大模型能力賦能下，可以更好得理解用戶得提問，對于相似語義得理解更準確和全面
數(shù)據(jù)查詢	支持部分指標查詢	支持進行體驗、效率指標的多維度查詢
知識查詢	常用日報、看板查詢	常用日報、看板查詢 TMS系統(tǒng)指南 操作手冊 業(yè)務sop 軌跡查詢 行駛證查詢 小秘常見問題
報表推送	不支持	通過和udata工具結合，支持進行報表的定時推送、預警推送
上線報告/調查問卷推送	不支持	支持上線報告/調查問卷推送

三、實現(xiàn)細節(jié)

1、知識問答

知識問答部分借助開源框架langchain和集團提供的大模型功能接口，實現(xiàn)了RAG問答機器人。這部分主要包括知識庫的建立和知識問答兩個部分。

下面是技術細節(jié)，并對其中的重要技術給出示例說明。

1、知識庫的構建

知識庫的構建實際上包括兩個主要部分：知識的生成和知識庫的存儲。知識庫的質量是問答系統(tǒng)效果的基礎因素。在本項目中，根據(jù)具體需求分別建立了問答（QA）知識庫和文檔知識庫。

傳統(tǒng)的運力機器人已經積累了大量的QA對，基于這些現(xiàn)有數(shù)據(jù)構建QA知識庫，依然采用QA對的形式。此外，QA知識庫的數(shù)據(jù)來源還包括兩個方面：一是利用大模型從文檔中抽取相關信息，二是通過分析機器人的問答日志并結合人工標注進行收集。QA類的知識在問答環(huán)節(jié)具有更高的準確性。與QA對相比，文檔知識庫主要包含各種類型的文檔，格式包括PDF、DOCX和PPTX等。從問答質量的角度來看，文檔知識庫的質量可能不如QA知識庫，但其數(shù)量龐大，且人工運營成本更低。文檔知識庫不需要將內容整理成QA對，只需將文檔轉換為文本格式并進行存儲。通過這兩種知識庫的建立，可以在保證問答系統(tǒng)質量的同時，大幅降低人工運營成本，提高系統(tǒng)的整體效率和實用性。

兩種知識庫建立之后，為了下游的（相似度）算法使用，均需要將待檢索/待召回文本轉為向量，存儲在向量數(shù)據(jù)庫中，此項目中選擇的是京東的Vearch庫。

在文檔轉純文本這個步驟中，對文檔中內容的解析質量是至關重要的，包括對文檔中表格內容的解析。此項目基于開源PDF解析框架進行了二次開發(fā)，解析了PDF中的章節(jié)信息，并將PDF中的表格內容進行了結構化抽取和處理，最終提升了下游生產出的知識質量。PDF的解析結果和PDF中的表格解析示例如下。

如下：PDF的解析后的結構化結果，保留了頁眉、頁腳、章節(jié)信息等。正文內容被保存到了多個文本塊中，每個文本塊中記錄了當前文本塊的內容、類型(text/table)、段落id、句子id、章節(jié)id等

{    
    "metadata": {                  # 文檔級元信息
        "footers": [],             # 頁腳
        "headers": [],             # 頁眉
        "catalogs": []             # 目錄
    },
    "chapters": {                  # 章節(jié)信息
        "1": "[CHAPTER_ROOT]",
        "1.1": "第一條 xxx",
        "1.2": "第二條 xxxx",
        "1.3": "第三條 xxxx"
    },
    "context": [                   # 內容信息
        {                          # 文本塊
            "text": "JDLxxxx規(guī)定",
            "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的知識問答流程是比較固定的：根據(jù)問題召回知識，將問題、知識、問答歷史等內容拼接為大模型prompt，使用大模型進行回答。此項目中，我們額外添加了問題重新生成環(huán)節(jié)：根據(jù)問答歷史對本輪問題進行重新生成，使重新生成的問題在知識相似度召回時具有更好的效果。這部分使用langchain的精簡問題鏈實現(xiàn)，一段示例代碼如下。

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(
        """給定歷史對話和一個后續(xù)問題，將后續(xù)問題改寫為一個標準問題，用其原始語言，確保避免使用任何不清晰的代詞。
歷史對話:
{chat_history}
后續(xù)輸入: {question}
標準問題:"""
    )
    condense_question_chain = LLMChain(
        llm=ChatOpenAI(
            model="",
            temperature="",
            openai_api_key="",
            openai_api_base="",
        ),
        prompt=CONDENSE_QUESTION_PROMPT,
    )
    return condense_question_chain

2、數(shù)據(jù)分析

1、NoETL 衍生邏輯模型資產

在數(shù)據(jù)集市生產過程中，由于生產邏輯的多變和不確定性，導致指標在不同時間粒度和下鉆維度組合的情況下，統(tǒng)計邏輯有一定共性但難以完全復用。為了平衡邏輯模型的標準化與字段治理效率，定義了一套基于指標技術元數(shù)據(jù)衍生模型資產的編織規(guī)范。在無需額外的人力干預和物理資源投入的前提下，實現(xiàn)自動化生成覆蓋任意時間粒度和業(yè)務維度的邏輯模型。

模型元數(shù)據(jù)：

{
    "uid": "742250d1dd9f457aa",
    "name": "離線_低裝載線路占比_日_3",
    "nodes": [
        {
            "id": "98579cdb14b44423ace0",
            "data": {
                "viewUid": "e246257e141e4fe78",
                "viewSql": "SELECT dt, trans_type_new_name AS trans_type_name , -- 線路類型 transport_org_name, -- 區(qū)域 business_type_name, -- 業(yè)務類型 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": [
                "區(qū)域"
            ],
            "field": "transport_org_name",
            "type": "str",
            "format": "text",
            "description": "區(qū)域"
        },
        {
            "id": 5,
            "names": [
                "線路類型"
            ],
            "field": "trans_type_name",
            "type": "str",
            "format": "text",
            "description": "線路類型"
        },
        {
            "id": 12,
            "names": [
                "業(yè)務類型"
            ],
            "field": "business_type_name",
            "type": "str",
            "format": "text",
            "description": "業(yè)務類型"
        }
    ],
    "timeSeries": [
        {
            "id": 1,
            "names": [
                "日",
                "日期",
                "天"
            ],
            "field": "dt",
            "type": "yyyy-mm-dd",
            "format": "date"

        }
    ]
    "operator": "liuyanchen9",
    "updatedAt": 1714112126
}

?

2、基于模型元數(shù)據(jù)萃取統(tǒng)一語義知識圖譜

基于邏輯模型元數(shù)據(jù)，創(chuàng)建語義詞典構建的調度任務，并允許業(yè)務方添加業(yè)務方言和語義同義詞，與血緣沿襲關系共同組成運力業(yè)務域的語義知識圖譜，目前已積累70余萬實體。語義詞典用于對用戶的自然語言問題進行切詞分析，將業(yè)務語言轉化為技術語言。后通過語義血緣關系，結合RAG能力，利用時間、維度、指標、分析方法等元數(shù)據(jù)的組合，推理每個語素在知識庫中的坐標，并精確匹配到相應的邏輯模型，從而實現(xiàn)自然語言驅動的數(shù)據(jù)查詢和分析的可行性。

血緣推理Agent原子能力：

?指標

?維度&標簽

?維度值

?邏輯模型

?視圖

?物理表

3、AI增強生成SQL與分析思路

大模型在技術生產中可以顯著提高效率，盡管幻覺問題理論上無法完全消除，但前述嚴密優(yōu)質的語義知識體系已能有效控制推理風險。在此基礎上，基于準確的元素結合Prompt生成SQL，不僅邏輯精確，而且計算效率的優(yōu)化表現(xiàn)超越絕大多數(shù)數(shù)據(jù)分析師。同時，基于準確的SQL結果，大模型有助于提供有見地的分析和解讀。

數(shù)據(jù)分析Agent原子能力

?自然語言問詢轉OLAP

?指標波動歸因

?大模型增強分析與解讀

3、功能融合

為提升業(yè)務的使用體驗，確保統(tǒng)一平臺統(tǒng)一問答入口出口，后臺將知識問答與數(shù)據(jù)分析能力進行了有機融合。

用戶query提出后，首先調用數(shù)據(jù)分析問答接口，若意圖命中輸出數(shù)據(jù)類結果，若未命中數(shù)據(jù)意圖，則再次請求知識問答接口，返回知識卡片結果。

四、能力展示

功能一：指標查詢

問答式交互數(shù)據(jù)分析：大模型數(shù)據(jù)分析與udata數(shù)據(jù)能力結合，讓用戶可以在京ME通過便捷靈活的問答機器人方式，統(tǒng)一入口，快速獲取數(shù)據(jù)，縮短數(shù)據(jù)分析鏈路，提高分析效率和及時性。

產品覆蓋的指標范圍簡單介紹：

體驗類指標：公路到達準點率、航空到達準點率、鐵路到達準點率以及他們對應的解耦指標等

效率類指標：車次管控、到車車次貨量、大車型占比、裝載率、車均單量、自營車效率等

分析維度：時間、區(qū)域、長途組、車隊、線路類型、線路名稱等

以上做為大家簡單的了解，詳細指標產品使用方法詳解如下：

運力小智正確打開方式：

（1）京ME中直接搜索”運力小智“或在群聊中直接艾特”運力小智“

（2）提問格式：時間維度?分析匯總維度?指標名稱?想要的圖表形式

【例如】：

?1月西南干線裝載率

?12月西南每個車隊的裝載率，折線圖

?準點率最高的2個區(qū)域

?從蘇州昆山退貨組到南京退貨組公路到達準點率

?北京長途組的公路到達準點率

?

功能二：知識問答

為運營人員提供日常的關于操作規(guī)范、規(guī)章制度、常見系統(tǒng)問題、常用看板、系統(tǒng)連接查詢等內容；大大縮短人工檢索信息的時間

產品覆蓋內容簡單介紹：

常用日報鏈接：運營日報，損益日報、時效日報、年貨節(jié)日報

系統(tǒng)網址：TMS常用網頁查詢

TMS系統(tǒng)指南：日常咨詢的運輸小秘的頻率較高的問題

操作手冊/sop內容查詢：支持直接搜索知識庫文檔鏈接，以及文檔內的關鍵問（知識庫文檔鏈接大全）

以上做為大家簡單的了解，詳細使用方法詳解如下：

運力小智正確打開方式：

（1）京ME中直接搜索”運力小智“或在群聊中直接艾特”運力小智“

（2）提問格式：直接用業(yè)務語言向小智提問即可

常用日報鏈接：

?運營日報

?損益日報

?時效日報

?年貨節(jié)日報

系統(tǒng)網址：

?委托書簽收網址

?行云

?easyBI網址鏈接

TMS系統(tǒng)指南：

?京管家APP在哪下載？

?如何清除瀏覽器緩存？

?創(chuàng)建司機失敗

?TMS系統(tǒng)員工管理新增或修改員工信息時，提示該京東賬號已存在

?艙位發(fā)布后，為啥訂艙看不到？

操作手冊/sop內容查詢：

?油耗影響因素有哪些

?合同倒簽怎么管理

?運力全景圖

?非標準附加費系統(tǒng)操作手冊

針對一線人員反饋的通用性的問題給予快速解答

一線咨詢問題快速轉化工單，大大提高每日值班人員手動錄入工單的效率

功能三：特定場景-軌跡查詢

方便運營人員根據(jù)派車單號（TW）進行車輛軌跡查詢，減少繁瑣的系統(tǒng)操作步驟

以上做為大家簡單的了解，詳細使用方法詳解如下：

運力小智正確打開方式：

（1）京ME中直接搜索”運力小智“或在群聊中直接艾特”運力小智“

（2）提問格式：按照TW號+軌跡 的格式向小智提問

例如：TW24042503278457的軌跡

功能四：特定場景-行駛證圖片查詢

支持根據(jù)車牌號，查詢對應的行駛證圖片

場景描述：

當發(fā)生車輛故障、經濟糾紛、交通事故等人為在途異常等情況下，運營需要通過車牌號查車輛注冊時間等信息來核查異常，運營同事反饋在一些場景下不在電腦旁邊時，查詢很不方便，需要發(fā)給在公司的同事幫忙查詢，工作效率低。

以上做為大家簡單的了解，詳細使用方法詳解如下：

運力小智正確打開方式：

（1）京ME中直接搜索”運力小智“或在群聊中直接艾特”運力小智“

（2）提問格式：按照 車牌號+行駛證照片 的格式向小智提問

例如：京A12345的行駛證照片

權限控制：該功能有權限控制哦

?

功能五：報表推送

udata報表支持定時推送、預警推送2大功能

產品覆蓋內容簡單介紹：

1.定時推送：業(yè)務關注的數(shù)據(jù)結果現(xiàn)可以通過京ME推送定時觸達到群，收到的推送內容為全量信息；

2.預警推送：基于業(yè)務自身數(shù)據(jù)看板，根據(jù)所關注的達成率/指標值等進行規(guī)則的靈活設置，可以自動觸達到對應責任人，提升數(shù)據(jù)分析和決策效率；

以上做為大家簡單的了解，詳細使用方法詳解如下：

?如何進行相關配置：

1、Udata報表中心，先選擇要推送的報表，選擇右邊的推送設置選擇【京ME】-選擇想要的推送方式

2、選擇推送方式：定時推送or預警推送

3、設置推送內容：

定時推送：

預警推送：

4、設置推送規(guī)則

5、保存并發(fā)送


審核編輯 黃宇

?