提及項目

提及項目是您在領域資料中視為相關的任何文字段。 例如，在關於汽車的類型系統中，出現的詞彙諸如airbag、Ford Explorer 及child restraint system 可能都是相關的提及項目。

實體類型

實體類型是您對實際事物進行分類的方式。 實體提及項目是該類型的事物範例。 例如，President Obama 提及項目可以註釋為 PERSON 實體類型。 提及項目 IBM 可以註釋為 ORGANIZATION 實體類型。 實體通常是名詞，但也可以是動詞，只要動詞對於基於將使用類型系統的應用程式目的而進行的擷取很重要。 例如，對於關於汽車的類型系統，EVENT_CRASH 可能是有效的實體類型，因此，可以註釋句子 hit 中的 The car hit the barrier. 這個字。

註釋工作區的目標是要在文件中使用每一個提及項目所屬的事物類型來註釋每一個提及項目。 在依實體類型將提及項目分類之後，標示的文字段即稱為實體。

您使用 Knowledge Studio 建置的類型系統可包括下列實體類型屬性。 這些屬性可協助限定文字中的提及項目，但機器學習模型不會將其標示為實體類型。 例如，如果實體類型 ORGANIZATION 具有稱為 COMMERCIAL 的實體子類型，則 COMMERCIAL 不會自行標示為實體類型。

• 角色

  依出現提及項目的上下文限定提及項目。 例如，在聲明 France 中的提及項目 the students went to France 是以實體類型 GPE 加以標示，因為 France 是地理政治實體。 但是，因為此上下文中的 France 也是旅行學生的目的地，所以會藉由新增屬性來限定實體類型，在此情況下，指的是角色 LOCATION。 對於另一個範例，提及項目 Lawyers 可能是以實體類型 PEOPLE 進行標示，也可能藉由角色 OCCUPATION 進行標示。

• 實體子類型

  將實體類型進一步分類。 例如，實體類型 ORGANIZATION 可能包括子類型 COMMERCIAL、GOVERNMENT、MILITARY 及 EDUCATION。

• 提及項目類型

  依特定詞性限定提及項目：

  • NAM：此提及項目是專有名稱，例如人員名稱或組織名稱。
  • NOM：此提及項目是名詞（一般名詞），例如公司 或總裁。
  • PRO：此提及項目是代名詞，例如他、我們 或它。
  • NONE：其他三種提及項目類型，沒有一個適用。

• 提及項目類別

  藉由指出提及項目是特定、一般，還是否定來限定提及項目：

  • SPC：此提及項目是特定的，通常包括英文單字 the，例如 the book 或 the hurricane occurred in September。 在這些範例中，提及項目 book 及 hurricane 將以屬性 SPC 進行註釋。
  • GEN：此提及項目是一般的，例如 a book 或 hurricanes usually occur in the fall。 在這些範例中，提及項目 book 及 hurricanes 將以屬性 GEN 進行註釋。
  • NEG：此提及項目是否定的，例如 no book 的參照。 當您訓練模型時，演算法可以同時從負面及正面範例中學習，因此務必標示這兩種類型的提及項目。

關係類型

關係類型定義兩個實體之間的二進位排序關係。 如需關係提及項目存在，文字必須明確定義關係，並將兩個實體的提及項目連結在一起，而且必須在單一句子內進行。 例如，句子 Mary works for IBM 是 employedBy 關係類型的文字證明。

對於部分關係類型，實體提及項目的順序至關重要。 例如， employedBy 關係類型容許實體類型 PERSON 或 PEOPLE 作為關係中的第一個提及項目，並容許 ORGANIZATION 或 GPE 作為第二個提及項目，而不是相反。 Mary employedBy IBM 是有效的關係。 IBM employedBy Mary 不是。 對於某些關係類型，例如 spouseOf、colleague 或 sibling，順序並不重要。 當您定義順序並不重要的關係類型時，最佳作法是將資訊新增至註釋準則，以規則化表示式類型的使用方式。 注意這類對稱關係的慣例是，指出在文字中第一個出現的實體提及項目應該是關係中的第一個提及項目。

相關概念：

從另一個工作區上傳資源

關於此作業

下列命名規則適用於類型系統項目：

• 名稱不得包含空格。
• 在新增至類型系統的值中，只使用下列英數 ASCII 字元及底線字元：A 到 Z、a 到 z、0 到 9。
• 實體或關係類型名稱中的第一個字元必須是字母。
• 實體類型名稱長度不得超過 64 個字元。
• 關係類型名稱長度不得超過 128 個字元。

依慣例，實體類型名稱以大寫字元 (ORGANIZATION) 指定，關係類型名稱以駝峰式大小寫 (employedBy) 指定。 但是，此慣例是選用的。

程序

1. 以 Knowledge Studio 管理者或專案經理身分登入，開啟資產 > 實體類型頁面。

2. 選擇下列其中一種方法來建立類型系統：

   • 上傳現有類型系統：

     1. 在實體類型標籤上，按一下上傳。

        如果您先前從 Knowledge Studio 工作區下載類型系統，則會以 JSON 格式下載類型系統。 您可以上傳此類型系統，以快速開始建立工作區。 如需相關資訊，請參閱從其他工作區上傳資源。

        不論類型系統的原點為何，其中的項目都必須符合先前列出的命名規則。

     2. 新增、編輯及刪除實體類型和關係類型，其方式與您從頭開始建立類型系統時所做的方式相同。

   • 從頭開始建立類型系統：

     1. 在實體類型標籤上，按一下新增實體類型。

     2. 指定敘述性實體類型名稱，請記住實體類型是一種標籤，用於註釋領域內容中的重要文字段圍（提及項目）。 保持簡短的名稱與代表性，讓註釋人員可以輕鬆地記住它。

        您也可以選擇性地定義實體類型的角色及子類型：

        • 角色可協助在出現提及項目的上下文中限定實體類型。 例如，提及項目 Software Engineer 可能是以實體類型 PEOPLE 進行標示，而且在此上下文中，藉由角色 OCCUPATION 進行標示。 如需相關資訊，請參閱何時定義角色。
        • 子類型可協助將實體類型進一步分類。 例如，實體類型 GOVERNMENT 可能具有 MILITARY 及 CIVILIAN 子類型。

        藉由定義實體的角色或子類型，您可以向將在註釋時建立類型資訊與提及項目之關聯的人員提供其他選項。 註釋人員可以套用一個註釋，只指定實體類型，或指定實體類型加上您現在所定義的角色或子類型。

        嘗試定義足夠的實體類型，以擷取您要註釋的主要概念，但不要擷取太多實體類型，讓註釋人員難以正確地套用標籤。

     3. 按一下提及項目類別及提及項目類型，以檢視預設提及項目類別和提及項目類型。 您無法編輯這些值。

        屬性的目的在於協助依每一個提及項目所屬的事物類型來標示每一個提及項目。 提及項目類型指出提及項目是名稱、名詞，還是代名詞，而提及項目類別則指出提及項目是特定、一般，還是否定。

     4. 開啟資產 > 關係類型頁面，指定兩個提及項目彼此之間的關係。

        關係類型中第一個與第二個實體之間的順序通常是相關的。 例如，PERSON 實體可以是 ORGANIZATION 實體或地理政治實體 (GPE) 的員工，例如 Mary employedBy IBM，但人員無法雇用組織及地理政治實體。 當註釋人員按一下基準編輯器中的實體時，可用關係類型的清單是由類型系統中定義的項目控制。

        請不要定義關係屬性。 機器學習模型不會使用它們。 此模型僅使用關係類型及順序，會忽略關係屬性。

     5. 請使用編輯及刪除圖示來修改實體類型及其關聯的關係類型，或從類型系統刪除實體類型或關係類型。

        如果您刪除關係類型定義中使用的實體，則也會刪除關係類型定義。

相關作業：

在不失去人工註釋的情況下修改類型系統

角色與子類型有何不同？

實體子類型用於將實體類型的庫存分層為階層。 例如，如果您在乎區分 40 個事物，但在邏輯上它們是 10 組 4（VITALSIGN_BLOODPRESSURE、VITALSIGN_HEARTRATE、MEDICATION_DOSAGE、MEDICATION_FREQUENCY），則您可以將它們建構為類型及子類型，這會產生更精簡的功能表，但卻會對標示程序帶來深度層次及麻煩事件。 基於資訊擷取的目的，類型及子類型的組合可以與批次類型和不含子類型的批次類型交換。 對照下，套用角色的單字或詞組是某個實體類型的範例，但它扮演另一種實體類型的角色，以及不是其他類型之子類型的角色。

如何處理角色？

Knowledge Studio 機器學習模型會為其在來源文件中找到之實體的每一個提及項目定義分類器標籤，方法為連結實體類型與角色值。 提供角色值時，您可以建立更精確的標籤。 訓練資料中找到的某個標籤類型的每一個實例群組，會形成一組更一致的提及項目。 挑戰在於，藉由選擇更精確，您還必須同意提供更多的訓練資料，以確保模型妥善執行。 但是，您提供的訓練資料越多，模型就會越好。 因此，如果您不在意執行其他註釋，則使用角色可讓您獲得更好的結果。

舉例來說，假設在來源文件中出現下列句子，而且我們想要擷取 Acme（其中 Acme 是著名的卡車製造商）、sedan 及 truck 作為類似實體，因為它們全都參照實體車輛：

• a) The Acme crashed into the concrete barrier.
• b) The sedan crashed into the concrete barrier.
• c) The Acme A-160 truck crashed into the concrete barrier.

您可以使用兩種方式來處理類型系統設計：

1. 定義兩個實體類型：MANUFACTURER 及 VEHICLE。 對於 MANUFACTURER 實體，除了預設 VEHICLE 角色外，定義可以使用的 MANUFACTURER 角色。

   使用此類型系統時，這些句子會註釋如下：

   • a) Acme 會註釋為 MANUFACTURER 實體，但具有角色 VEHICLE，因為它它參照實際的車輛。 因此，其內部標籤是 MANUFACTURER-VEHICLE。
   • b) sedan 會註釋為實體類型 VEHICLE。 已自動指派 VEHICLE 角色，因為未定義其他角色。
   • c) Acme 會註釋為實體類型 MANUFACTURER，而 truck 會註釋為實體類型 VEHICLE。 未指派任何角色，因此會使用預設角色。

2. 定義兩個沒有角色的實體類型：MANUFACTURER 及 VEHICLE。

   使用此類型系統時，這些句子會註釋如下：

   • a) Acme 會註釋為實體類型 VEHICLE。
   • b) sedan 會註釋為實體類型 VEHICLE。
   • c) Acme 會註釋為實體類型 MANUFACTURER，而 truck 會註釋為實體類型 VEHICLE。

兩個不同的類型系統的執行方式？ 假設註釋人員已註釋一組文件。 在註釋作業回合之後，會在訓練語料庫中識別下列手動標示為實體的訓練事件：

• 類型系統 1

  MANUFACTURER-MANUFACTURER 800 events
  MANUFACTURER-VEHICLE 200 events
  VEHICLE-VEHICLE 400 events
  

• 類型系統 2

  MANUFACTURER 800 events
  VEHICLE 200 + 400 = 600 events
  

模型處理新文件時，很可能 Acme 大部分時間都標示為 MANUFACTURER，因為單字的拼寫是強大的特性，而且單字 Acme 可能定義在 MANUFACTURER 字典中。 它會取得許多上下文，以不同方式標示它。 如果使用類型系統 1 ，則只有 200 個 MANUFACTURER-VEHICLE 訓練事件，相較於類型系統 2 中 VEHICLE 的 600 個事件，這是缺點。 不過，類型系統 1 中的訓練事件叢集都非常一致，這會導致更好的效能。 對於類型系統 2，VEHICLE 的一組 600 個訓練事件實際上是由兩個不交集的叢集所組成：一個包含參照實際車輛的製造商名稱，例如 Acme 及 Ford，另一個包含車輛類型，例如 sedan、SUV 及 truck。 直覺上，這兩個叢集各自都是一致的，但藉由將它們混合在一起，這會降低訓練叢集，並呈現一個更難解決的問題。 如果您繼續執行註釋，並新增更多訓練事件，則類型系統 1 中的效能會越來越好，然而，解決您使用類型系統 2 所得到的兩個不交集叢集的問題，並不會由於更多的訓練而改善。