滴滴客服平臺(tái)建設(shè)解決方案

案言客服是連接用戶與事業(yè)部的橋梁從用角度用戶過(guò)能道C自助或者人工服渠道反饋問(wèn)和表達(dá)訴求道識(shí)別和記錄用戶問(wèn)題后，給出問(wèn)題對(duì)應(yīng)的解決方案。在過(guò)去問(wèn)題對(duì)應(yīng)的解決方案散在渠道及各關(guān)模塊中導(dǎo)很問(wèn)的包括體驗(yàn)和邏輯一致解決方案質(zhì)量難以保證影解決能力和用戶體驗(yàn)，而且難管理運(yùn)維另一方面，這些解決方案很大程度依賴事業(yè)部提供的服務(wù)能力往的編程式接入成高代期且缺乏統(tǒng)一管會(huì)導(dǎo)致相同場(chǎng)景服務(wù)能力使用的一致性難以保證，影響解決方案的質(zhì)量和用戶體驗(yàn)。為了保證解決方案質(zhì)量提升用戶體驗(yàn)和管理效率我們需統(tǒng)一管理這些解決方案建設(shè)解決方案平臺(tái)整各事業(yè)部提供業(yè)信和務(wù)能力，為人工智能渠道統(tǒng)一提供標(biāo)準(zhǔn)化解決方案。決方平臺(tái)分析散落各的解決方案般是基于事業(yè)部輸入的業(yè)務(wù)邏輯和服務(wù)能力處理能力大體以分為使的和解決問(wèn)題的處理程我們前提了識(shí)和標(biāo)準(zhǔn)解決方案，方案，成整解決方案平臺(tái)：：主要指流，簡(jiǎn)稱為，應(yīng)用場(chǎng)景比廣，戶問(wèn)題的場(chǎng)景；主要指知相關(guān)產(chǎn)品在業(yè)內(nèi)通常稱為知識(shí)庫(kù)，的問(wèn)題解釋和指導(dǎo)等場(chǎng)景；：主要負(fù)責(zé)管理問(wèn)題到答案的關(guān)系；案針對(duì)需要通過(guò)標(biāo)準(zhǔn)化流程引導(dǎo)以及解決用戶問(wèn)題的場(chǎng)景們提供流程管理平臺(tái)，負(fù)責(zé)生、執(zhí)行和管理態(tài)程。用戶（C端用戶、客服等）過(guò)單面進(jìn)行息互，背后則是理問(wèn)題的業(yè)務(wù)流程向前驅(qū)動(dòng)和處理，下是對(duì)這個(gè)鏈路的一個(gè)簡(jiǎn)單示在這個(gè)鏈路中需要解決幾個(gè)問(wèn)題：1).如何支持不同渠道的交互方式2).如何支持處理流程標(biāo)準(zhǔn)化；3).業(yè)務(wù)信和服務(wù)能力如何規(guī)范且高效地接入。為此，我在設(shè)計(jì)上從幾方面進(jìn)行了拆

式。交互方式實(shí)現(xiàn)表單的可支不同能力和一致的交互體驗(yàn)。的邏輯執(zhí)行，起的作用的流程執(zhí)能力，支接入到執(zhí)行的線上化和標(biāo)準(zhǔn)化。能力的接入，我們從了及回的字段為了管理資源我們化接入和使的能力，服能力的標(biāo)準(zhǔn)化接入，同時(shí)對(duì)業(yè)營(yíng)服能力更加友好?；诹鞒痰恼着渲霉苣芰σ粋€(gè)流從設(shè)到測(cè)到上線實(shí)現(xiàn)了流程線上化很大程度地縮短了務(wù)迭代周期提升產(chǎn)研效率。同時(shí)基這條鏈路現(xiàn)業(yè)可化管，業(yè)在務(wù)梳理、量把控、風(fēng)險(xiǎn)控制等方面提了有力支持。在今年年中，我們打通了端助鏈路味著一個(gè)用戶問(wèn)題應(yīng)的處理自助流上線以全置上，代率均升。此基礎(chǔ)上也同時(shí)打通-決方案單的數(shù)據(jù)鏈路業(yè)務(wù)精細(xì)化運(yùn)營(yíng)提供數(shù)據(jù)支撐，助力業(yè)務(wù)綜合提升解決能力。靜態(tài)決方針對(duì)大量業(yè)務(wù)信息要透?jìng)鹘o用戶或者輔助客服解決用戶問(wèn)題的些場(chǎng)景我們提供了標(biāo)準(zhǔn)的靜態(tài)知識(shí)解決方案從產(chǎn)品層上提供客服知識(shí)點(diǎn)、用戶對(duì)、相似題列表等。在服務(wù)對(duì)靜態(tài)知識(shí)有兩個(gè)核心訴求1.知識(shí)的結(jié)化/非構(gòu)存；2.用各場(chǎng)景的檢索能力。前產(chǎn)品在這兩方面的能力受限于關(guān)系型數(shù)據(jù)庫(kù)的存儲(chǔ)接下來(lái)將進(jìn)行一系列升級(jí)建設(shè)時(shí)也包括產(chǎn)品層面知識(shí)檢索、運(yùn)營(yíng)和反饋等功能的進(jìn)一步加強(qiáng)。方案匹配方案匹配是指根據(jù)用戶問(wèn)題找到相應(yīng)的解決方案理多道的問(wèn)題與同一方案的匹配關(guān)系。一般說(shuō)來(lái)對(duì)于匹配過(guò)程一個(gè)問(wèn)題能找到唯一的解決方案一個(gè)解決方案可以對(duì)應(yīng)多個(gè)問(wèn)那么理想情況下我們分別為用戶的個(gè)問(wèn)題和每個(gè)解決方案計(jì)唯一的編號(hào)案匹配層只需維護(hù)問(wèn)題到答案的一多的關(guān)系即可。但在落地過(guò)程中我們發(fā)現(xiàn)：

用戶問(wèn)題的描述方式不是唯編號(hào)，而是多維度的排列組解決一方一方案的解決方案；因此方案匹配層設(shè)計(jì)思路是維護(hù)問(wèn)組到答案組的關(guān)前這一層的能力比較單薄未來(lái)計(jì)劃升級(jí)底層能力支持異構(gòu)的問(wèn)題和答案組匹配，提升可擴(kuò)展性以適應(yīng)業(yè)務(wù)及產(chǎn)品層的快速迭代。淀前面我們從業(yè)務(wù)視角介紹了決方案平臺(tái)如何支持客服業(yè)其實(shí)在平臺(tái)建設(shè)過(guò)程也遇了一些技術(shù)的面要合解決方案平臺(tái)建設(shè)過(guò)程遇到的問(wèn)題介紹一技術(shù)沉淀：流程在介紹動(dòng)態(tài)解決方案的時(shí)候們提到它底層依賴的核心基礎(chǔ)能——流程引擎。在方案選型的時(shí)候我們調(diào)研了Activiti等方案，作為比較成熟的工作流引擎activiti功能強(qiáng)大且有比較完整的態(tài)，但在我們的景中優(yōu)勢(shì)并不明顯主要體現(xiàn)在幾方從定位上我們建設(shè)的是流程引擎產(chǎn)品化后的產(chǎn)品對(duì)流引只依賴流程驅(qū)動(dòng)的核心能從功能上在流程定義和行過(guò)程中部署校驗(yàn)、數(shù)據(jù)交互、支選擇等方面有滿足或不易擴(kuò)展的需求；從性能上，Activiti的通用性和靈活性決定實(shí)現(xiàn)的復(fù)雜度如頻繁的存儲(chǔ)層操作等導(dǎo)致其性能表現(xiàn)不佳不能很好地滿足我們的端場(chǎng)景對(duì)能的需求外考慮上手成本維護(hù)成本等綜合因素，最終我們決定針對(duì)我的場(chǎng)景自研。作為輕量級(jí)的程引擎，自研流程引擎主要負(fù)責(zé)提供穩(wěn)定的能力驅(qū)流執(zhí)上層是型上為，介紹我們?nèi)缌鞒?慮到性，我們?cè)谌缌鞒虝r(shí)考了bpmn：

起點(diǎn)行路徑、執(zhí)策略；成流中的種元分為節(jié)點(diǎn)和順序流兩大了事件節(jié)點(diǎn)（點(diǎn)）、任務(wù)點(diǎn)、網(wǎng)關(guān)節(jié)點(diǎn)（如排他網(wǎng)關(guān)節(jié)點(diǎn)）；流程元素列表可以完整描述一個(gè)流程；要使用一個(gè)流程分兩步：1.設(shè)計(jì)一個(gè)流程；2.執(zhí)行這個(gè)流程好比定義一個(gè)類與創(chuàng)建個(gè)對(duì)象的關(guān)系此流程引擎的構(gòu)基本也是按照這樣的思路設(shè)計(jì)，分為兩大部：流程定義和流程執(zhí)：程定義為了保證流程在執(zhí)行過(guò)程不受流程模更新的影響以及慮運(yùn)維場(chǎng)景的需求們?cè)诹鞒潭x時(shí)對(duì)流程模采用了近似快照的處理，在流程執(zhí)行時(shí)直使用快照模型：程執(zhí)行流程執(zhí)行其實(shí)是從開(kāi)始節(jié)點(diǎn)開(kāi)始處理當(dāng)前節(jié)點(diǎn)完成理后根據(jù)當(dāng)前狀態(tài)及配置規(guī)則到下一個(gè)節(jié)點(diǎn)并繼續(xù)處理節(jié)直到結(jié)節(jié)點(diǎn)?

在程行程，游動(dòng)引交互節(jié)點(diǎn)，流程引擎

工落地▍資源背文到種戶問(wèn)題整合輸入還有部是服力主要是各事業(yè)部通整服業(yè)有業(yè)APIAPI入各種API入&資源服入事業(yè)部資源工入在里我們將事業(yè)部提供的服務(wù)能稱為資源，并根據(jù)使用場(chǎng)景將資源分為大類：

API：主指事業(yè)部提供的接能力查詢訂單詳情apiField：通常為一字段，eg.單詳情接口返回的“總額”字段。使用資源分為定義資源和獲取資源兩部份源引擎提的能力也以這兩部份為核心輔以相關(guān)的配套管理能力于是我們?cè)O(shè)計(jì)了關(guān)的模塊：

客服端：SDK，使用方自行集SDK，根據(jù)資源引協(xié)議查詢資源定義，并獲取及解析資源服務(wù)端：服務(wù)端，支持源定義的查詢；管理平臺(tái)：配置化接入資源及資源列表的統(tǒng)一管理*量數(shù)據(jù)產(chǎn)出離線數(shù)據(jù)包括接入資源的用情況錯(cuò)誤率、耗時(shí)等質(zhì)量數(shù)據(jù)，幫助使用方及事業(yè)部發(fā)問(wèn)題，迭代方案；互模：系統(tǒng)：

Manager：資源理后臺(tái)，是資源及相關(guān)配置管理入口；Server服務(wù)端，需要性能穩(wěn)定地支持客戶的查詢，盡量到量因此server只做兩件：訪問(wèn)控制高效查詢；Client客戶端負(fù)責(zé)獲取資源；：事業(yè)提的服能力目前要支持API，根據(jù)需求考擴(kuò)展；可看，中即負(fù)責(zé)核心的獲取資源的邏輯，層次設(shè)計(jì)：

：協(xié)層，描述用方如何使用資源，例如可擴(kuò)展等；：核心邏a.與交互獲取資源相關(guān)定義；根據(jù)定義計(jì)算執(zhí)行計(jì)劃；c.通用調(diào)事業(yè)部；解析和加工返回的數(shù)據(jù)，得到最終結(jié)果；：根據(jù)資源定義，用事業(yè)部能力獲取直結(jié)果；舉個(gè)例子，已知：

f1來(lái)自a1(應(yīng)返回結(jié)果的apiField1段)；api參數(shù)為f4;f4不是數(shù)據(jù)，是對(duì)f3再加工；f3值為；f2述省略...求：f1、f2值；

協(xié)議析析出參數(shù)列表以及需要獲取的資源列表；：這里括要取的源以它們賴的源配置；將得的資源列表分成組，組原則是組內(nèi)每外的資源，抽象來(lái)說(shuō)類似有向聯(lián)通圖的意思；Process每個(gè)組內(nèi)的資源列表交給處理任務(wù)遍歷進(jìn)行原子處理：遞歸獲取該資源依賴的資源列表；執(zhí)行，得到原始結(jié)果；根據(jù)對(duì)原始結(jié)果進(jìn)行工，得到最終結(jié)；