MindMeld 實體解析的最新消息

介紹

實體解析 (ER) 是消除實體歧異的過程。 實現方法為：將文字提及對應至查詢知識庫 (KB) 中，所能找到最合適的現實名稱。 例如，將「madrid fc」解析為「Real Madrid Club de Fútbol」(皇家馬德里足球俱樂部)，前者為後者的另一種寫法。 實體解析常以其他名稱稱呼，例如，實體配對、實體連結、記錄連結，或者記錄重複資料刪除。 實體解析是 MindMeld 自然語言處理管道的一部分，與預先填入的知識庫配對，用來消除任何使用者輸入中所辨識實體的差異。 請查看官方文件瞭解如何為實體解析程式建立知識庫，並在建置 MindMeld 應用程式時使用該知識庫。直到最近，MindMeld 提供兩種實體解析選項：其中一種以 Elasticsearch 的全文檢索搜尋和分析引擎為基礎；另一種則以簡單精確配對演算法為基礎，作為備用選項。 隨著 MindMeld 應用方式越來越多樣，上述兩種選項並非永遠適用。 為了提供延伸支援，MindMeld 現在提供另外兩種實體解析選項：其中一種以 TF-IDF 為基礎，另一種則以預先訓練的神經模型呈現為基礎 (BERT、GloVe、fastText 等等)。 值得注意的是，這兩個新選項完全不需依賴 Elasticsearch 及其服務。 進一步深入瞭解這些新選項前，先快速回顧一下實體知識庫在 MindMeld 中的建構方式。 以下使用點餐藍圖為例，包含為消除食品項目名稱歧異建立的知識庫： 如圖所示，「cname」欄位 (正式名稱) 和「whitelist」欄位，列示每個食物項目的某些常用用法，「id」欄位則指向知識庫中唯一正式認可的記錄。 這三個欄位主要構成了知識庫中的實體物件。 「cname」欄位中的文字通常用於對話應答，「whitelist」欄位以及正式名稱同時在消除歧異時作為別名使用。 通常在「whitelist」欄位完整填入時 (包含替代用法、拼寫錯誤和簡稱等等)，能獲得最佳實體解析程式結果。 某些應用中，這類型的策劃過程可能極其乏味，但在處理高度專業領域的實體時，將無法避免此類策劃。

深入瞭解新增的解析程式

除了精準配對以外的解析程式，步驟一為取得欲消除歧異輸入文字的向量表示，以及知識庫 (cname 加上 whitelist) 中，作為消除歧異別名使用所有項目的向量表示。 接著利用某些類型的向量相似性配對 (例如，餘弦相似性)，為每個別名評分和排名。 在新增的實體解析選項中，以 TF-IDF 為基礎的解析程式在計算稀疏向量的餘弦相似性前，策劃了各種 n 元語法特徵 (亦即表層文字特徵)。 另一方面，預先訓練以嵌入器為基礎的解析程式，使用餘弦相似性對文字的密集向量表示進行配對。 與其他方法相比，利用預先訓練的嵌入器進行實體解析，擁有某些優勢。 例如，該方法不需大量填寫 whitelist 就能提供文字的語意理解 (例如，「表現低於預期」相當於「表現不佳」)，並且能夠輕鬆轉換到多語言項目配對 (例如，推斷西班牙文中的「tercio」和英文中的「third」相同)。 然而，事先訓練和推斷之間的差異，例如輸入文字長度差異，是事先訓練嵌入器的缺點。 此外，由於基礎的密集向量計算，嵌入器模型的推斷時間可能高於其他解析程式選項。 但是經過適當微調後，嵌入器模型的表現將優於其他以表層文字特徵為主要基礎的解析程式選項。 以下分析中，預先訓練的嵌入器模型，將與 Elasticsearch 和 TF-IDF 實體解析程式進行比較。 策劃用於比較的資料集包含表層文字配對和語意配對。

不同解析程式的效能

經過使用各種內部策劃資料集的實驗後，得出了以下不同實體解析程式針對簡短文字實體配對的平均效能。 此處以最佳擷取分數作為測量的正確度： 預先訓練的 BERT 變體可作為 Huggingface 句子轉換器的一部分，圖表只呈現了效能前 5 名的變體。 fastText 這類預先訓練的單字嵌入模型，一般而言表現劣於 BERT 嵌入器模型或以 TF-IDF 為基礎的解析程式。 此類低效能可歸因於網域轉移或缺乏微調。 使用效能最佳的 BERT 變體 (distilbert-base-nli-stsb-mean-tokens)，並使用不同設定進一步分析，得到以下結果：   結果顯示 BERTScore 等其他相似評分，並不具有競爭力。 此外，在串連不同層 BERT 模型時使用餘弦相似性，可讓效能提高到與 Elasticsearch 相當。 此結果十分直覺化，因為不同層的 BERT 可以擷取互補資訊。 即使量化 BERT 變體，在減少磁碟使用量和時間複雜度後，效能也僅降低 2-3%。 此外，評估輸入中含有拼寫錯誤的隨機雜訊資料時，以 TF-IDF 為基礎的解析程式之效能優於其他解析程式。 此結果可能導因於，此解析程式擷取了不同組的 n 元語法。 (此實驗中，whitelist 文字作為測試執行個體重複使用，並且在其中引發拼寫錯誤。 因此，0% 雜訊時，所有測試實體也同時出現在 whitelist 中，因此觀察到 100% 正確度！)   最後，以下圖表說明不同解析程式選項中，推斷時間複雜度的差異：(從左至右：最準確的 BERT、TF-IDF 和 Elasticsearch) 每一個實體在不同大小知識庫下，所測量出的推斷時間。 X 軸顯示知識庫大小，而 Y 軸則顯示各實體時間，單位為毫秒。 黃色的是編碼輸入文字的推斷時間，綠色是相似性計算的推斷時間。 TF-IDF 和 Elasticsearch 的時間複雜度相當，但最佳的 BERT 變體雖然已經量化，依然慢 20 倍。 如果不串連前 4 層，速度會提升到僅慢 10 倍，但會導致正確度下降。

選取和設定實體解析程式

MindMeld 實體解析程式設定，會根據使用的解析程式，提供各種可設定的參數。 在應用程式的「config.py」中提供時，以下程式碼片段利用您在 Huggingface 所選之預先訓練的 BERT 模型： ENTITY_RESOLVER_CONFIG = {     ‘model_type’: ‘resolver’,     ‘model_settings’: {         ‘resolver_type’: ‘sbert_cosine_similarity’,         ‘pretrained_name_or_abspath’: ‘distilbert-base-nli-stsb-mean-tokens’,         …     } } 您可以修改「embedder_type」參數，以使用其他嵌入器模型：ENTITY_RESOLVER_CONFIG = {     ‘model_type’: ‘resolver’,     ‘model_settings’: {         ‘resolver_type’: ’embedder_cosine_similarity’,         ’embedder_type’: ‘glove’,        …     } } 使用嵌入器模型時，您也可以指定「batch_size」等執行時間設定以及嵌入器模型特定設定。 若要載入以 TF-IDF 為基礎的解析程式，您可以執行以下操作：ENTITY_RESOLVER_CONFIG = {     ‘model_type’: ‘resolver’,     ‘model_settings’: {         ‘resolver_type’: ‘tfidf_cosine_similarity’,         …     } } 知識庫中的每個實體，包含所有別名嵌入平均/最大集區的特殊嵌入，設定完成後，也會計算並用於解析。 這類特殊嵌入通常只會稍微增加計算成本，但能改善解析程式正確度。 完整詳細資料和所有可設定選項，請參閱官方文件中的「設定」章節。

總結想法和未來展望

整體而言，除非因為特殊情境無法使用外，十分推薦使用以 Elasticsearch 為基礎的解析程式。 至於備用方案，如果需要更多語意配對，可以使用以嵌入器模型為基礎的解析程式，如果無上述需求，則可以使用以 TF-IDF 為基礎的解析程式。 MindMeld 中的 ER 模組，目前還沒有提供任何 API 來衡量哪一個解析程式最適合您的應用程式。 敬請期待，我們已經計劃新增該項支援，以及微調以嵌入器為基礎解析程式的方法。 註冊 Webex 請前往我們的首頁或直接聯絡我們以尋求協助。 按一下此處，深入瞭解 Webex 提供的產品與服務，並註冊免費帳戶。