1、背景

隨著公司業務的發展，客服的業務量不斷增加，為了解放人力，提升質檢業務的覆蓋率，及時有效的發現客服日常工作中的問題，需要建設智能質檢系統，滿足日益增長的話務質檢系統需求。

2、業務特征

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

質檢的各項指標，按照數據的來源劃分大致可以分為以下幾種：

• IM系統

IM文本會話的內容，會話的時間等

• 電話系統

二線外呼，400內呼電話通話內容，通話信息等

• 工單系統

工單操作，比如創建工單，重啟工單，催單等

• 訂單商品

商品類型，訂單價格等

• 賠付系統

賠付記錄，用戶標簽等

按照數據類型可以分為以下幾種：

• 話術類

會話內容的語義，意圖等

• 交互類

通話語速，情緒等

• 屬性類

訂單金額，商品標簽，工單類型等

• 操作類

客服各類操作，創建工單，創建賠付單等

同時，在不同的場景下，“標準”的判定會有一定的差別，這就要求系統的質檢，具有可以靈活調整的能力，規則的制定需要隨著業務發展進行調整。

3、技術挑戰

3.1 挑戰

基于質檢系統的業務特征，為了保證系統上線功能的正常使用，同時保證系統的穩定運行，在系統的設計時需要面臨一些挑戰：

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

以上這4點就是整個質檢系統在設計過程中著重需要注意的點，為系統設計指明了方向。

3.2 解決思路

基于前面提到的這些挑戰，整體的質檢系統圍繞如何采配置質檢項，如何采集數據并完成質檢開展。

質檢系統整體數據采集的流程如下：

4、技術選型

4.1 數據大寬表

為了減少對下游系統服務的壓力，解決大量質檢單所需質檢數據的采集問題，基于現有質檢系統T+1生成質檢單的模式，數據大寬表采用離線采集是比較優選的方案。

4.2 質檢規則

質檢系統執行“質檢”行為，主要基于在質檢項上配置的質檢規則進行，而質檢規則的執行就依賴于規則引擎。

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

5、技術實現

5.1 離線數據采集

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

• 以IM會話id為主鍵，采集，組裝IM相關數據
• 以工單號為主鍵，采集組裝工單，以及關聯的訂單，賠付單等數據
• 以訂單號為主鍵，采集組裝訂單相關數據

基礎數據采集生成離線表后，質檢系統根據質檢單中對應的會話id查詢信息，并通過關聯工單號，解析會話內容中的訂單號，查詢對應關聯的離線數據表，最終組裝成上下文信息并提交給規則引擎計算最終結果。

5.2 規則執行

規則執行主要依賴于規則腳本的配置和規則引擎執行腳本，系統選用了QLExpress作為腳本引擎，QLExpress是一門動態腳本引擎解析工具，具有以下的一些優點:

• 支持大部分java語法

支持 +,-,*,/,<,>,<=,>=,==,!=,<>【等同于!=】,%,mod【取模等同于%】,++,--,
/in【類似sql】,like【sql語法】,&&,||,!,等操作符
支持for，break、continue、if then else 等標準的程序控制邏輯
邏輯三元操作 a > b ? a : b;
不支持try{}catch{}
不支持java8的lambda表達式
不支持for循環集合操作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 系統實現

• 總體架構

• 主流程?

質檢系統的主要用戶為

• 運營人員：負責基礎配置，包括抽檢規則，質檢項以及自動質檢的規則腳本。
• QC ：負責對系統質檢完的質檢單進行復核，找出系統差錯并反饋給運營人員，修改對應的規則腳本。
  ?

• 離線數據

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

• 自動質檢

?

• 質檢腳本
• 算子
• 質檢項的最小單元為算子，每個算子至少對應一個基礎指標，配置自動質檢時，需要先配置算子，并將算子作為基礎單元組合質檢規則。

配置頁面如下：

• 質檢規則

上次催單=距離最近時間(@I,@A,false);
承諾催單=A && !E;
催單時間=距離最近時間(@B,@C,true);
創單時間=距離最近時間(@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;

• 腳本執行

腳本執行依賴于規則引擎中預先定義好的自定義函數和包含各種所需參數的上下文context執行。

• 自定義函數

自定義函數通過QLExpress的綁定java對象的method特性實現。以規則中“分鐘差”為例：

首先通過java代碼實現所需的自定義函數

public int timeDiff_Minute(Long t1,Long t2){
    if(Objects.isNull(t1) || Objects.isNull(t2)){
        throw new QlExpressException(4000,"計算分鐘差失敗，時間參數為空");
    }
    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本質為Map對象,用于傳遞腳本執行時所需的參數。一般使用DefaultContext，也可通過實現IExpressContext接口自定義context。

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

6、未來規劃

6.1 實時質檢

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

6.2提升語義解析準確率

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

6.3反哺SOP

質檢結果的第二個影響因素“行為”，在客服域內，客服可以應答用戶訴求的操作應該遵循SOP。同樣，質檢系統在進行質檢時，也應該根據SOP來制定質檢規則。質檢系統和SOP系統應該是相輔相成，質檢系統發現問題并不是目標，而通過發現問題反饋建立SOP，杜絕相似問題的發生才是目的。