1、背景

隨著公司業(yè)務(wù)的發(fā)展，客服的業(yè)務(wù)量不斷增加，為了解放人力，提升質(zhì)檢業(yè)務(wù)的覆蓋率，及時有效的發(fā)現(xiàn)客服日常工作中的問題，需要建設(shè)智能質(zhì)檢系統(tǒng)，滿足日益增長的話務(wù)質(zhì)檢系統(tǒng)需求。

2、業(yè)務(wù)特征

質(zhì)檢系統(tǒng)主要針對的是電話（二線外呼，400內(nèi)呼）和文本會話（IM會話）內(nèi)容，以及客服的后續(xù)操作進行質(zhì)檢，以解決用戶需求為核心，檢驗客服的服務(wù)。由于客服日常對接的用戶訴求“千奇百怪”，質(zhì)檢系統(tǒng)需要對接的數(shù)據(jù)來源也是多方面的，這就要求質(zhì)檢系統(tǒng)需要對接各個系統(tǒng)，將多方數(shù)據(jù)進行串聯(lián)，以算子為基礎(chǔ)，使用配置化的規(guī)則計算腳本進行最終結(jié)果的計算。

質(zhì)檢的各項指標(biāo)，按照數(shù)據(jù)的來源劃分大致可以分為以下幾種：

• IM系統(tǒng)

IM文本會話的內(nèi)容，會話的時間等

• 電話系統(tǒng)

二線外呼，400內(nèi)呼電話通話內(nèi)容，通話信息等

• 工單系統(tǒng)

工單操作，比如創(chuàng)建工單，重啟工單，催單等

• 訂單商品

商品類型，訂單價格等

• 賠付系統(tǒng)

賠付記錄，用戶標(biāo)簽等

按照數(shù)據(jù)類型可以分為以下幾種：

• 話術(shù)類

會話內(nèi)容的語義，意圖等

• 交互類

通話語速，情緒等

• 屬性類

訂單金額，商品標(biāo)簽，工單類型等

• 操作類

客服各類操作，創(chuàng)建工單，創(chuàng)建賠付單等

同時，在不同的場景下，“標(biāo)準(zhǔn)”的判定會有一定的差別，這就要求系統(tǒng)的質(zhì)檢，具有可以靈活調(diào)整的能力，規(guī)則的制定需要隨著業(yè)務(wù)發(fā)展進行調(diào)整。

3、技術(shù)挑戰(zhàn)

3.1 挑戰(zhàn)

基于質(zhì)檢系統(tǒng)的業(yè)務(wù)特征，為了保證系統(tǒng)上線功能的正常使用，同時保證系統(tǒng)的穩(wěn)定運行，在系統(tǒng)的設(shè)計時需要面臨一些挑戰(zhàn)：

• 數(shù)據(jù)量較大
  
  按照一通會話對應(yīng)一次質(zhì)檢，每天需要生成對應(yīng)數(shù)量的質(zhì)檢單。針對每條質(zhì)檢單還需要有對應(yīng)的質(zhì)檢項，最終質(zhì)檢系統(tǒng)需要對這些質(zhì)檢項，按照配置好的質(zhì)檢規(guī)則進行質(zhì)檢。
• 數(shù)據(jù)源多樣
  質(zhì)檢系統(tǒng)不光數(shù)據(jù)量較大，質(zhì)檢的范圍也多種多樣，有的質(zhì)檢項需要獲取依賴的工單系統(tǒng)，訂單系統(tǒng)的數(shù)據(jù)，需要保證能夠準(zhǔn)確的獲取這些數(shù)據(jù)并且不對下游依賴的系統(tǒng)造成影響。
• 質(zhì)檢項多且雜
  系統(tǒng)需要支持多種質(zhì)檢項的配置，同時每個質(zhì)檢項又存在多條質(zhì)檢規(guī)則，且根據(jù)業(yè)務(wù)場景需要經(jīng)常性的調(diào)整規(guī)則，這就要求系統(tǒng)可以支持靈活的配置，挑戰(zhàn)質(zhì)檢項和質(zhì)檢規(guī)則。
• 準(zhǔn)確性
  質(zhì)檢系統(tǒng)最終的結(jié)果會影響到用戶的體驗以及客服的工作，需要保證質(zhì)檢結(jié)果的準(zhǔn)確性。

以上這4點就是整個質(zhì)檢系統(tǒng)在設(shè)計過程中著重需要注意的點，為系統(tǒng)設(shè)計指明了方向。

3.2 解決思路

基于前面提到的這些挑戰(zhàn)，整體的質(zhì)檢系統(tǒng)圍繞如何采配置質(zhì)檢項，如何采集數(shù)據(jù)并完成質(zhì)檢開展。

質(zhì)檢系統(tǒng)整體數(shù)據(jù)采集的流程如下：

4、技術(shù)選型

4.1 數(shù)據(jù)大寬表

為了減少對下游系統(tǒng)服務(wù)的壓力，解決大量質(zhì)檢單所需質(zhì)檢數(shù)據(jù)的采集問題，基于現(xiàn)有質(zhì)檢系統(tǒng)T+1生成質(zhì)檢單的模式，數(shù)據(jù)大寬表采用離線采集是比較優(yōu)選的方案。

4.2 質(zhì)檢規(guī)則

質(zhì)檢系統(tǒng)執(zhí)行“質(zhì)檢”行為，主要基于在質(zhì)檢項上配置的質(zhì)檢規(guī)則進行，而質(zhì)檢規(guī)則的執(zhí)行就依賴于規(guī)則引擎。

規(guī)則引擎的選擇，最初考慮JDK自帶的Java Script Engine，但該引擎只支持JavaScript，后期選擇了擴展性更加強大的QLExpress。

5、技術(shù)實現(xiàn)

5.1 離線數(shù)據(jù)采集

質(zhì)檢系統(tǒng)根據(jù)話務(wù)類型將質(zhì)檢分為3大類，分別是一線，二線和400。不同類型的質(zhì)檢單通過離線采集數(shù)據(jù)生成對應(yīng)的大寬表用于查詢計算。以一線在線為例，數(shù)據(jù)的采集，清洗主要分為以下幾個步驟：

• 以IM會話id為主鍵，采集，組裝IM相關(guān)數(shù)據(jù)
• 以工單號為主鍵，采集組裝工單，以及關(guān)聯(lián)的訂單，賠付單等數(shù)據(jù)
• 以訂單號為主鍵，采集組裝訂單相關(guān)數(shù)據(jù)

基礎(chǔ)數(shù)據(jù)采集生成離線表后，質(zhì)檢系統(tǒng)根據(jù)質(zhì)檢單中對應(yīng)的會話id查詢信息，并通過關(guān)聯(lián)工單號，解析會話內(nèi)容中的訂單號，查詢對應(yīng)關(guān)聯(lián)的離線數(shù)據(jù)表，最終組裝成上下文信息并提交給規(guī)則引擎計算最終結(jié)果。

5.2 規(guī)則執(zhí)行

規(guī)則執(zhí)行主要依賴于規(guī)則腳本的配置和規(guī)則引擎執(zhí)行腳本，系統(tǒng)選用了QLExpress作為腳本引擎，QLExpress是一門動態(tài)腳本引擎解析工具，具有以下的一些優(yōu)點:

• 支持大部分java語法

支持 +,-,*,/,<,>,<=,>=,==,!=,<>【等同于!=】,%,mod【取模等同于%】,++,--,
/in【類似sql】,like【sql語法】,&&,||,!,等操作符
支持for，break、continue、if then else 等標(biāo)準(zhǔn)的程序控制邏輯
邏輯三元操作 a > b ? a : b;
不支持try{}catch{}
不支持java8的lambda表達式
不支持for循環(huán)集合操作for (Item item : list)

• java對象操作

date = new Date();
System.out.println(date.getTime());

• 擴展操作符

• 重命名

runner.addOperatorWithAlias("如果", "if", null);
runner.addOperatorWithAlias("則", "then", null);
runner.addOperatorWithAlias("否則", "else", null);
express = "如果 (A > B) 則 {return a;} 否則 {return b;}";
DefaultContext<String, Object> context = new DefaultContext<String, Object>();
runner.execute(express, context, null, false, false, null);

• 自定義操作符

//定義一個join方法
public class JoinOperator extends Operator {
    @Override
    public Object executeInner(Object[] list) throws Exception {
        Object opdata1 = list[0];
        Object opdata2 = list[1];
        if (opdata1 instanceof List) {
            ((List)opdata1).add(opdata2);
            return opdata1;
        } else {
            List result = new ArrayList();
            for (Object opdata : list) {
                result.add(opdata);
            }
            return result;
        }
    }
}

5.3 系統(tǒng)實現(xiàn)

• 總體架構(gòu)

• 主流程?

質(zhì)檢系統(tǒng)的主要用戶為

• 運營人員：負(fù)責(zé)基礎(chǔ)配置，包括抽檢規(guī)則，質(zhì)檢項以及自動質(zhì)檢的規(guī)則腳本。
• QC ：負(fù)責(zé)對系統(tǒng)質(zhì)檢完的質(zhì)檢單進行復(fù)核，找出系統(tǒng)差錯并反饋給運營人員，修改對應(yīng)的規(guī)則腳本。
  ?

• 離線數(shù)據(jù)

用于自動質(zhì)檢的大寬表是在dataworks中，通過各數(shù)據(jù)源的基礎(chǔ)表組裝而成，最終將大寬表寫入es以供自動質(zhì)檢時使用。查詢時，大寬表數(shù)據(jù)還會經(jīng)過二次組裝，最終組裝成規(guī)則引擎可用的上下文信息。

• 自動質(zhì)檢

?

• 質(zhì)檢腳本
• 算子
• 質(zhì)檢項的最小單元為算子，每個算子至少對應(yīng)一個基礎(chǔ)指標(biāo)，配置自動質(zhì)檢時，需要先配置算子，并將算子作為基礎(chǔ)單元組合質(zhì)檢規(guī)則。

配置頁面如下：

• 質(zhì)檢規(guī)則

上次催單=距離最近時間(@I,@A,false);
承諾催單=A && !E;
催單時間=距離最近時間(@B,@C,true);
創(chuàng)單時間=距離最近時間(@D,@C,true);
重啟時間=距離最近時間(@F,@C,true);
備注時間=距離最近時間(@G,@C,true); 
if(承諾催單){         
    if(分鐘差(上次催單,@A)>10){
        return  (!B || (@J < 催單時間 && 分鐘差(@J,催單時間)>10)) && !D && !F;         
    }else{                 
        return (!G || (@J < 備注時間 && 分鐘差(@J,備注時間)>10));        
    }          
} 
return false;

• 腳本執(zhí)行

腳本執(zhí)行依賴于規(guī)則引擎中預(yù)先定義好的自定義函數(shù)和包含各種所需參數(shù)的上下文context執(zhí)行。

• 自定義函數(shù)

自定義函數(shù)通過QLExpress的綁定java對象的method特性實現(xiàn)。以規(guī)則中“分鐘差”為例：

首先通過java代碼實現(xiàn)所需的自定義函數(shù)

public int timeDiff_Minute(Long t1,Long t2){
    if(Objects.isNull(t1) || Objects.isNull(t2)){
        throw new QlExpressException(4000,"計算分鐘差失敗，時間參數(shù)為空");
    }
    return (int)TimeUnit.MILLISECONDS.toMinutes(timeDiff(t1,t2));
}

將定義的method綁定至腳本引擎

QlExpressFunc qlExpressFunc = new QlExpressFunc();
runner.addFunctionOfServiceMethod("分鐘差", qlExpressFunc, "timeDiff_Minute",
        new Class[]{Long.class, Long.class}, null);

• 上下文CONTEXT

上下文context本質(zhì)為Map對象,用于傳遞腳本執(zhí)行時所需的參數(shù)。一般使用DefaultContext，也可通過實現(xiàn)IExpressContext接口自定義context。

public class DefaultContext<K,V> extends HashMap<K,V> implements IExpressContext<K,V>
{ }

6、未來規(guī)劃

6.1 實時質(zhì)檢

質(zhì)檢系統(tǒng)的目的是發(fā)現(xiàn)客服工作中的問題，為了提升發(fā)現(xiàn)問題的時效，并有效攔截外訴風(fēng)險，未來質(zhì)檢的模式將從現(xiàn)有的基于T+1的離線數(shù)據(jù)模式改為實時質(zhì)檢模式。修改后的質(zhì)檢服務(wù)將在分鐘級的尺度上對客服操作進行質(zhì)檢并及時發(fā)出預(yù)警。同時，修改實時質(zhì)檢模式后，可以有效的提升現(xiàn)有服務(wù)器資源的利用率，對整體服務(wù)的穩(wěn)定性有很大的提升。

6.2提升語義解析準(zhǔn)確率

客戶服務(wù)行為的本質(zhì)可以簡單的歸納為客服通過會話與用戶交流并滿足用戶訴求，而質(zhì)檢則是對客服這一服務(wù)行為的檢查。那么質(zhì)檢的結(jié)果就是由“語義”——客服與用戶交流的內(nèi)容和“行為”——客服滿足用戶訴求的操作來決定。其中語義的解析是現(xiàn)在影響質(zhì)檢結(jié)果的最大的瓶頸。對于質(zhì)檢系統(tǒng)來說，提高質(zhì)檢的準(zhǔn)確率，當(dāng)務(wù)之急就是提升語義解析的準(zhǔn)確率。現(xiàn)在的系統(tǒng)通過文本，正則匹配和算法意圖解析來進行語義的解析，這其中大部分語義解析都是基于單句話來執(zhí)行，未來的目標(biāo)是通過整通會話的上下文，進行更加精細的語義解析，以此來提升質(zhì)檢的準(zhǔn)確率。

6.3反哺SOP

質(zhì)檢結(jié)果的第二個影響因素“行為”，在客服域內(nèi)，客服可以應(yīng)答用戶訴求的操作應(yīng)該遵循SOP。同樣，質(zhì)檢系統(tǒng)在進行質(zhì)檢時，也應(yīng)該根據(jù)SOP來制定質(zhì)檢規(guī)則。質(zhì)檢系統(tǒng)和SOP系統(tǒng)應(yīng)該是相輔相成，質(zhì)檢系統(tǒng)發(fā)現(xiàn)問題并不是目標(biāo)，而通過發(fā)現(xiàn)問題反饋建立SOP，杜絕相似問題的發(fā)生才是目的。