0.作業聲明
| 這個作業屬於哪個課程 | 信安1912-軟件工程 (廣東工業大學 - 計算機學院) |
|---|---|
| 這個作業要求在哪里 | 團隊作業5——測試與發布（Alpha版本） |
| 這個作業的目標 | Alpha版本測試報告、Alpha版本發布說明 |
1.作業gitee鏈接
2.團隊展示
1、隊名：is-good-bro
2、隊員學號
| 隊員 | 學號 |
|---|---|
| 陳梓浩（組長） | 3119005455 |
| 羅行健 | 3119005470 |
| 黃浩 | 3119005414 |
| 何子陽 | 3119005413 |
| 蘇澤 | 3119005473 |
3、擬作的團隊項目描述：基於知識圖譜的醫療問答機器人
3.Alpha版本測試報告
1、測試過程
①產品背景與定義
針對學齡兒童需要一個准確的醫療診斷機器人，青年群體需要一個即時的醫療咨詢機器人，中老年群體需要一個便捷的醫療問答機器人的時代發展背景，我們開發一個基於知識圖譜的醫療問答機器人，要求醫療數據包含疾病的定義、症狀、治療方法，拓展疾病的忌吃食物、宜吃食物、通用葯品、推薦葯品、並發症、治療科室；要求辨識用戶，識別用戶輸入內容中的意圖、實體，緩存用戶對話信息，並支持槽位繼承和意圖繼承實現多輪對話
②測試定義與目的
此次測試為模塊測試，目的在於已開發好的進行測試，如測試實體識別模塊是否能對輸入內容進行實體識別，分割出文字中的實體，測試關系抽取模塊是否能抽取出文字中的實體關系，測試要求廣泛收集測試數據，確保測試的客觀准確性，提高測試可信度，並據測試結果向開發人員反饋意見
③測試工具與環境
測試工具：Pycharm
測試環境：
python==3.7
tensorflow==1.14.0
keras==2.3.1
bert4keras==0.10.6
h5py==2.8.0
④測試時間與人員
| 測試內容 | 測試時間 | 測試人員 |
|---|---|---|
| 實體識別模塊 | 2天 | 羅行健、蘇澤、陳梓浩 |
| 意圖識別模塊 | 2天 | 黃浩、何子陽、陳梓浩 |
| 模塊銜接測試（多輪對話模塊） | 3天 | 陳梓浩、羅行健、黃浩 |
⑤測試資源
每項測試，測試數據均為100條，30%為測試人員結合自身生活生成，40%為網絡收集，30%為交叉測試人員生成，例如實體識別模塊，測試數據為“我昨天晚上腸胃炎犯了，而且頭痛”，實體識別模塊識別出“腸胃炎”疾病實體和“頭痛”症狀實體，意圖識別模塊測試數據“你是機器人嗎”，模塊識別出這句話的意圖是閑聊意圖范圍中的isrobot，多輪對話模塊測試數據“心臟病是什么”->“那怎么治療呢”，模塊識別出“那怎么治療呢”的意圖是醫療咨詢范圍中的詢問治療方法，但對應槽位並沒有填充信息，於是繼承上一句對話的槽位信息，即做到了多輪對話
⑥測試過程中發現的各類型bug
| 類型（數量） | 簡述 | 描述 |
|---|---|---|
| 修復的bug（3） | 無用戶標識信息（本地端） | 原因：本程序因為含有多輪對話功能，所以需要程序具有記錄用戶對話緩存的功能，因此需要獲取用戶的標識信息，但在本地端中因為只有對話過程，而沒有登錄過程，所以無用戶標識信息。 修復：在對話過程的開始前詢問用戶的名稱，當作用戶的標識信息 |
| 無用戶標識信息（微信端） | 原因：本程序因為含有多輪對話功能，所以需要程序具有記錄用戶對話緩存的功能，因此需要獲取用戶的標識信息，但在微信端不同於本地端，無法識別用戶輸入的是不是名稱，無法通過與本地端相同的辦法獲取用戶標識信息。 修復：將從微信端接收到的消息直接輸出，找到微信自帶的用戶標識信息FromUserName，當作本程序的用戶標識信息 |
|
| 查詢數據庫返回異常 | 原因：后台查詢數據庫數據，語句是沒有錯誤，在數據庫中查詢能查詢出數據，但是通過項目查詢時，返回的數據沒辦法接收到，由於返回的數據與接收的實體類型不能一一對應，不能直接寫入，需要在 cypher 中進行屬性的標注，進行寫入；還可能發生這樣的原因就是在未加@Autowired的注解，導致java.lang.NullPointerException: null異常。 修復： @Query("MATCH (a:疾病)-[r]->(b) WHERE a.name={diseaseName} RETURN type(r) as type,b.name AS name") List @Query("MATCH (a:疾病)-[r]->(b) WHERE b.name={name} RETURN type(r) as type,a as disease") List |
|
| 不能重現的bug（2） | 程序運行卡死 | 原因：本程序的資源較多和所需運行內存較大，需要調用多個模型以實現項目功能，所以需要一定程度的硬件配置，當運行機器的配置在瞬時達不到要求時，程序運行將會卡死，但該bug出現的幾率較低，所以不能重現 修復：提高硬件配置，或刷新機器內存 |
| 緩存增刪查改異常 | 原因：在管理員對緩存進行增刪查改的期間，由程序原本邏輯產生的緩存寫入會被覆蓋或無法寫入，修改緩存的過程需要先將緩存讀入內存后再對緩存項進行操作，在管理員讀取緩存進入內存之后程序原本邏輯對緩存文件的寫入將無法被讀取到，由於管理員實際操作緩存的時間非常短，碰撞出現機率低； 修復：即使碰撞出現，造成的后果是程序緩存寫入失敗，此后果影響很小，下次再次寫入即可 |
|
| 這個產品就是這樣設計的，不是bug（1） | 無法回復用戶的其他意圖信息 | 原因：本程序僅設計了閑聊和醫療咨詢功能，不具備文學、工學、網絡詞互動等其他功能，面對此類信息，程序將會識別為其他意圖，並回復機器人暫不能理解 |
| 沒有能力修復，將來也不打算修復（1） | 無法回復用戶發送的動畫表情和emoji信息 | 原因：想要做到識別動畫表情和emoji信息，需要具有多模態交互，聯邦學習的知識，才可以做到讓程序理解表情中的信息，並轉化為文字信息，目前團隊成員不具備這個知識，且該知識點所需的學習時間較長，所以此bug不作修復打算 |
| 這個bug的確應該修復，但是沒有時間在這個版本修復，延遲到下一個版本修復（1） | 無法回復用戶發送的部分閑聊和醫療咨詢信息 | 原因：本程序由於所需知識點較多和所需搭建時間較長，所以目前僅設計了部分閑聊意圖和咨詢意圖的數據集供程序模型學習，並不能實現識別大部分閑聊和咨詢信息 修復：擴增數據集和重新訓練模型，理論和知識儲備上都可以實現，因為目前階段沒有時間修復，所以延遲到下一個版本修復 |
2、測試結果
①預期不同的用戶的使用、需求和目標
| 用戶群體 | 需求 | 目標和使用 |
|---|---|---|
| 學齡兒童 | 一個准確的醫療診斷機器人 | 詢問身體上的異常，由於人口老齡化趨勢導致年輕人的壓力增大，越來越多的年輕人選擇外出打拼，將孩子交給祖輩看護，但是祖輩的科學知識並不充裕，存在很多封建土方，比如孩子發燒通過厚被悶汗出熱治病，但是這其實沒有任何正效應，甚至可能導致加重發燒，避免因誤判或過晚發現身體上的異常，容易造成不可估量的無法挽回后果，保證准確性 |
| 青年群體 | 一個即時的醫療咨詢機器人 | 詢問一些日常生活中的不適情況，青年身體有異常習慣通過挺兩天嘗試自愈，但是並非每種情況都可以靠身體自愈，而且為了方便，通常選擇網絡查病，但例如百度，經常隨便一問都是癌症征兆或者晚期，不僅沒實際效果，而且會導致心理焦慮，保證即時性，及時保障自身健康 |
| 中老年人 | 一個便捷的醫療問答機器人 | 詢問服用葯品的劑量和時間，防止影響治療效果，且保證便捷性 |
②如何滿足用戶的需求
| 需求 | 實現 |
|---|---|
| 用戶輸入信息 | 本地端、微信端、網頁端界面 |
| 識別輸入中的實體 | 實體識別模塊，實體規范化模塊 |
| 識別輸入中的意圖 | 意圖識別模塊 |
| 多輪對話 | 用戶標識，對話緩存 |
| 准確性 | 搜索引擎、醫院等數據集 |
| 即時性 | neo4j圖數據庫，比mysql數據庫更快的響應速度 |
| 便捷性 | 本地端、微信端、網頁端 |
③測試矩陣
| 配置配置 | 服務端/客戶端 | 本地端 | 微信端 |
|---|---|---|---|
| 聯想拯救者 Y7000P GTX 1660Ti i5-9300H DDR4 16GB python 3.7 PyCharm 2020.3 wechat 3.4.5.22 |
服務端 客戶端 |
√ | √ |
| 聯想拯救者 Y7000 GTX 1650 i5-9300H DDR4 8GB python 3.7 PyCharm 2020.3 wechat 3.4.0.38 |
服務端 客戶端 |
√ | √ |
| 聯想 82DM AMD Radeon Graphics AMD Ryzen 5 4600U RAM 16384MB wechat 3.4.5.22 |
客戶端 | / | √ |
| 聯想拯救者 Y7000 GTX 1650 i5-9300H DDR4 8GB wechat 3.4.0.38 |
客戶端 | / | √ |
| 戴爾 G3 GTX 1650 i7-9750H DDR4 16GB wechat 3.4.0.38 |
客戶端 | / | √ |
| 戴爾 Inspiron i5-9300H GTX 1050 DDR4 8GB wechat 3.4.0.38 |
客戶端 | / | √ |
| 黑鯊游戲手機 2 Pro JOYUI 12.5 21.10.20 wechat 8.0.16 |
客戶端 | / | √ |
| iPhone XR ios 14.4.1 wechat 8.0.16 |
客戶端 | / | √ |
| iPhone 13 ios 15.1.1 wechat 8.0.16 |
客戶端 | / | √ |
| 紅米 K20 Pro MIUI 12.5.6 wechat 8.0.16 |
客戶端 | / | √ |
| 華為 NOVA7 HarmonyOS 2.0.0 wechat 8.0.16 |
客戶端 | / | √ |
| 紅米 Note10 Pro MIUI 12.5.8 wechat 8.0.15 |
客戶端 | / | √ |
| 真我 GT realmeUI 2.0 wechat 8.0.16 |
客戶端 | / | √ |
| 小米 10 MIUI 12.5.10 wechat 8.0.15 |
客戶端 | / | √ |
| 紅米 K20 Pro MIUI 12.0.2 wechat 8.0.15 |
客戶端 | / | √ |
| 華為 P30 Pro HarmonyOS 2.0.0 wechat 8.0.16 |
客戶端 | / | √ |
④出口條件
通過以上16個不同配置的設備的測試，實現在0.5s內回復本地端咨詢，在1s內回復微信端咨詢，本團隊認為該項目已經足夠好，可以發布Alpha版本
⑤部分測試截圖
4.Alpha版本發布說明
1、功能
| 功能模塊 | 實現需求解決說明 |
|---|---|
| 前端 | 提供輸入界面和輸入方法，獲取用戶輸入 |
| 后端 | 使用Java語言進行設計開發，使用版本為Java11。在設計過程中采用了SpringBoot框架進行開發，期間調用了Neo4j圖形數據庫進行數據存儲，后續通過Java語言設計接口，實現了對數據庫中節點數據的模糊搜索 |
| 實體識別 | 使用BILSTM-CRF模型對用戶輸入進行命名實體識別預測，識別出用戶輸入中疾病、器官、症狀、人群、治療、時間等實體，提供給后期對話機器人使用 |
| 關系抽取 | 使用CasRel模型對病症數據進行實體關系抽取預測，抽取出病症數據中疾病、器官、症狀、人群、治療、時間等實體的關聯關系，生成三元組，保存為關系文本文件，提供給后期數據導入作為預處理后的數據使用 |
| 數據導入 | 將實體識別生成的詞庫文本文件和關系抽取獲得的關系三元組文本文件，使用python編寫批處理程序，先使用詞庫在neo4j圖數據庫建立對應的節點，並將關系三元組中的內容以此使用CQL語句向neo4j數據庫輸入，建立節點之間的關系，提供給后期對話機器人使用 |
| 實體規范化 | 當涉及到使用本項目進行查詢相關信息時，為減少誤輸和錯輸對用戶產生的體驗影響，使用bm25算法+esim模型進行實體規范化訓練，收集常錯輸入與規范詞的數據，如將“你好”誤輸為“nihao”，將輸入與規范詞進行實體連接，使得即使錯輸部分詞語也能正確反饋，提供給后期對話機器人使用 |
| 意圖識別 | 使用bert+textCNN模型進行意圖識別訓練，可以用來辨別用戶的輸入意圖是什么，如用戶輸入“你好”，對話機器人可以識別出這是問好意圖，回復“你好，我是信息查詢機器人”；用戶輸入“查詢XXX信息”，機器人可以識別出這是查詢意圖，提供給后期對話機器人使用 |
| 對話機器人 | 調用前面的實體識別等多個部分，對用戶的輸入進行自然語言理解，得出用戶的對話意圖和關鍵詞，如用戶輸入“心臟病是什么”，機器人就可以識別出這是查詢意圖，並且是查詢關鍵詞是心臟病，從neo4j數據庫查詢相關信息並返回給用戶 |
| 對話緩存 | 將用戶上一句查詢意圖輸入經實體識別后得到的槽位信息保存，當下一句輸入缺乏槽位信息時進行槽位繼承，使得實現多輪對話 |
2、修復的缺陷
| 缺陷 | 描述 |
|---|---|
| 無用戶標識信息（本地端） | 原因：本程序因為含有多輪對話功能，所以需要程序具有記錄用戶對話緩存的功能，因此需要獲取用戶的標識信息，但在本地端中因為只有對話過程，而沒有登錄過程，所以無用戶標識信息。 修復：在對話過程的開始前詢問用戶的名稱，當作用戶的標識信息 |
| 無用戶標識信息（微信端） | 原因：本程序因為含有多輪對話功能，所以需要程序具有記錄用戶對話緩存的功能，因此需要獲取用戶的標識信息，但在微信端不同於本地端，無法識別用戶輸入的是不是名稱，無法通過與本地端相同的辦法獲取用戶標識信息。 修復：將從微信端接收到的消息直接輸出，找到微信自帶的用戶標識信息FromUserName，當作本程序的用戶標識信息 |
| 查詢數據庫返回異常 | 原因：后台查詢數據庫數據，語句是沒有錯誤，在數據庫中查詢能查詢出數據，但是通過項目查詢時，返回的數據沒辦法接收到，由於返回的數據與接收的實體類型不能一一對應，不能直接寫入，需要在 cypher 中進行屬性的標注，進行寫入；還可能發生這樣的原因就是在未加@Autowired的注解，導致java.lang.NullPointerException: null異常。 修復： @Query("MATCH (a:疾病)-[r]->(b) WHERE a.name={diseaseName} RETURN type(r) as type,b.name AS name") List @Query("MATCH (a:疾病)-[r]->(b) WHERE b.name={name} RETURN type(r) as type,a as disease") List |
3、運行環境要求
| 模式 | 環境要求 |
|---|---|
| 本地端（既為服務端又為客戶端） | python 3.7 tensorflow 1.14.0 keras 2.3.1 bert4keras 0.10.6 h5py 2.8.0 運行內存 4GB |
| 微信端（服務端） | python 3.7 tensorflow 1.14.0 keras 2.3.1 bert4keras 0.10.6 h5py 2.8.0 itchat-uos 1.4.1 運行內存 4GB |
| 微信端（客戶端） | wechat>=8.0.0 |
4、安裝方法
| 模式 | 安裝 |
|---|---|
| 本地端（既為服務端又為客戶端） | 使用語句“pip install ...”按上表依次安裝庫，注意不要顛倒順序，否則會因為各庫的包版本不一致導致程序運行出錯，運行“build_kg_utils.py”將數據寫入本地的neo4j數據庫，運行“terminal.py”開啟本項目的本地端版本 |
| 微信端（服務端） | 使用語句“pip install ...”按上表依次安裝庫，注意不要顛倒順序，否則會因為各庫的包版本不一致導致程序運行出錯，運行“build_kg_utils.py”將數據寫入本地的neo4j數據庫，運行“wechat_api.py”開啟本項目的微信端版本，使用手機微信掃描二維碼登錄，即讓本項目的問答機器人架設到登錄的微信賬號上 |
| 微信端（客戶端） | 添加架設了本項目問答機器人的微信賬號，在聊天框中直接輸入內容進行咨詢 |
5、系統已知的問題和限制
| 問題和限制 | 描述 |
|---|---|
| 無法回復用戶的其他意圖信息 | 原因：本程序僅設計了閑聊和醫療咨詢功能，不具備文學、工學、網絡詞互動等其他功能，面對此類信息，程序將會識別為其他意圖，並回復機器人暫不能理解 |
| 無法回復用戶發送的動畫表情和emoji信息 | 原因：想要做到識別動畫表情和emoji信息，需要具有多模態交互，聯邦學習的知識，才可以做到讓程序理解表情中的信息，並轉化為文字信息，目前團隊成員不具備這個知識，且該知識點所需的學習時間較長，所以此bug不作修復打算 |
| 無法回復用戶發送的部分閑聊和醫療咨詢信息 | 原因：本程序由於所需知識點較多和所需搭建時間較長，所以目前僅設計了部分閑聊意圖和咨詢意圖的數據集供程序模型學習，並不能實現識別大部分閑聊和咨詢信息 修復：擴增數據集和重新訓練模型，理論和知識儲備上都可以實現，因為目前階段沒有時間修復，所以延遲到下一個版本修復 |
6、軟件的發布方式以及發布地址
①本地端，在gitee上開源，作業gitee鏈接，直接下載
②微信端，在本團隊開啟微信測試號的時間，掃描下方二維碼添加
③網頁端，點擊以下鏈接訪問