規劃如何調整您的應用程式

版本之間的主要變更之一是 Discovery v2 引進專案。 專案由一個或多個集合組成。 使用專案的優點是一個查詢可以同時針對多個集合執行。 每個集合可以包含您上傳或從單一資料來源抓取的文件，例如網站、Microsoft SharePoint, 等。

當您調整應用程式以使用專案時要考量的事項:

• 雖然環境概念不存在於 v2中，但資料仍會組織成集合。 在 v2中，集合會分組成專案。 在大部分情況下，您想要將單一 v1 集合移轉至單一 v2 集合。

  如果您想要保留套用至 v1 集合的相關性訓練資訊，請將集合文件新增至 v2 專案中的單一集合。

• 決定您要新增至每一個 v2 專案的集合數目。 除了「內容採礦」專案之外，所有專案類型最多可以包含 5 個集合。 為您的資料選擇正確的專案類型。

  為了最佳化搜尋結果，不同的強化和配置選項會自動套用至新增至不同專案類型的集合。 如需相關資訊，請參閱下列主題：

  • 專案說明
  • 預設專案設定
  • 預設查詢設定

• Discovery v2 API 已變更為專案和集合的帳戶，以及其他加強功能。 部分 API 呼叫已變更為支援專案層次而非集合層次的動作，例如提交查詢及執行相關性訓練。 許多其他 API 方法已變更，部分在 v2中無法使用。 如需 v1 和 v2 API 方法的詳細比較，請參閱 API 版本比較。

挑選服務方案

透過購買 Discovery Cartridge for IBM Cloud Pak for Data，從 Plus、Enterprise及 Premium 受管理方案中選擇或選擇內部部署安裝。 在選擇方案類型之前，請先檢閱每一種方案類型的權益及限制。

• 如需方案的相關資訊，請參閱 Discovery 定價方案。
• 如需構件限制的相關資訊，請參閱 限制詳細資料。

下表顯示通常在 v1 與 v2之間類似之受管理部署的方案類型。

若要取得所使用現行儲存體、文件及集合的相關資訊，請從產品使用者介面標頭中按一下 環境詳細資料 圖示。

您無法從 v1 方案 (例如「精簡」或「進階」) 直接升級至 v2 方案。 您必須建立新的 v2 方案，然後將資料移至新的服務實例。 當您將資料從 v1 移轉至 v2時，可能會同時部署 v1 和 v2 實例。 考量在此期間使用第一個 Plus 方案實例提供的 30 天免費試用。

上傳資料

如果您使用 API 將文件上傳至 Discovery v1，則在 v2 中提供類似的 API，可將文件上傳至集合。 您必須更新您用來自動化處理程序的任何工作流程，以說明專案和集合的新安排。

如果您吸收至 Discovery v1 的原始文件不再可用，您可以使用查詢 API 從 Discovery v1擷取文件文字。 然後，您可以將文字新增至 Discovery v2中的集合。 如需相關資訊，請參閱 回復文件。

已搜索資料

如果您在 v1中從外部資料來源搜索資料，則可以在 v2中繼續從相同的外部資料來源搜索資料。 支援所有相同的資料來源。

若要使用來自外部資料來源的資料，您必須在 v2 專案內重建集合，並配置如何搜索資料來源。 如需相關資訊，請參閱 資料來源概觀。

服務需要時間和資源，才能從外部資料來源搜索及汲取文件。 一次重建一個連接器。 將重新搜索資料的時間計入移轉計劃排程。

預先建置的資料集合

下列內建資料來源集合在 v2:

Watson Discovery 新聞

此預先強化的資料來源未在 v2中提供。 如需取得新聞資料之替代方式的相關資訊，請參閱 搭配使用新聞服務與 v2。

COVID-19 套件

此預先建置的集合旨在協助您推動動態聊天機器人，此動態聊天機器人是使用 IBM® watsonx™ Assistant 及 Discovery 來建置，以回答客戶關於 COVID-19的問題。 在 v2中，您可以建置類似的解決方案。 建立具有集合的 交談式搜尋 專案類型，可搜索信任網站以取得 COVID-19 問題的答案。

保留文件 ID

當您從產品使用者介面上傳文件或使用 新增文件 API 方法新增文件時，會將文件 ID 指派給您新增至 v2 集合的文件。

如果您使用相依於這些唯一 ID 的處理程序，則可能想要在 v2 中保留 v1 文件的 ID。 例如，應用程式的回歸測試可能會透過檢查文件 ID 來驗證是否傳回特定文件。 相關性訓練使用文件 ID 在訓練執行之間追蹤文件。 如果 v1 和 v2 實例之間的文件 ID 相同，這些程序更容易調整。 否則，與 Discovery v1 實例搭配使用的程序必須重新對映至將它們新增至 Discovery v2 實例之後指派給文件的 ID。

如果您在將文件新增至 v1 服務實例時指定自己的文件 ID，則可以使用 更新文件 方法而非 新增文件 方法來保留 ID。 使用 update 方法，您可以在將文件新增至 v2 集合時，將文件 ID 指派給該文件。 如需相關資訊，請參閱 更新文件。

如果資料儲存在 JSON 檔案中，則原始文件中的陣列會產生附加有數字的文件 ID。 例如，original_id_n。 若要保留不含數字字尾的原始文件 ID，請移除 JSON 檔案中的陣列。 例如，將 [ {"name": "value"} ] 變更為 {"name": "value"}。

如果 v1 文件具有系統產生的 ID，您可以提交空的 搜尋查詢，以擷取文件及其 ID 的清單。 然後，當您在 v2中將每一個文件新增至新集合時，可以將相同的 ID 指派給該文件。

回復文件

在某些情況下，已吸收至 Discovery V1 的原始文件不再可用。 您可以使用 Discovery v1 實例來擷取文件中的資訊。Discovery 會建立它所汲取之每一個文件的文字副本。 副本僅為文字，因此任何 HTML、PDF 或其他非文字格式的文件都會轉換為純文字版本。

您只能使用此方法回復集合中的前 10,000 個文件。 如需回復超過 10,000 個文件之方法的相關資訊，請參閱 從集合回復超過 10,000 個文件。

如果要將文件資訊從 v1 傳送至 v2，請完成下列步驟:

1. 使用 API 提交空查詢，從 v1 擷取文件。

   例如，GET {url}/v1/environments/{environment_id}/collections/{collection_id}/query?q=。

   API 會傳回結果。 matching_results 欄位指定結果總數。 results 物件會傳回相符文件。 每一份文件會以個別的 JSON 物件傳回。 依預設，它最多會傳回 10 個文件。

   {
     "matching_results": 34,
     "session_token": "nnn",
     "results": [
       {"{result objects}":"{maximum of 10 by default}"}
     ]
   }
   

2. 您可以使用 count 和 offset 參數來翻看查詢結果，並儲存所有文件。

   例如，若要一次取得 100 個文件，您可以將 count 設為 100，並將 offset 設為 0，然後提交查詢。

   GET {url}/v1/environments/{environment_id}/collections/{collection_id}/query?q=&count=100&offset=0
   

   接下來，您可以再次將計數設為 100，但這次將偏移設為 100，以取得下 100 個文件。

   GET {url}/v1/environments/{environment_id}/collections/{collection_id}/query?q=&count=100&offset=100`
   

   重複此程序，將偏移增加 100，直到您擷取所有文件為止。

3. 準備匯出的文件以吸收至 v2。

   您從 Discovery v1 取得的每一個產生的 JSON 檔案都包含從原始文件擷取的資料，例如文字、html 及其他欄位。 如果自訂 meta 資料在上傳至 v1時與文件相關聯，則它也會呈現在 JSON 檔案中。 此外，該檔案包含 v1 分析所產生的數個欄位。 僅保留此資料的子集作為您新增至 Discovery v2之文件的一部分。

   下列提示可協助您決定要保留哪些欄位:

   • 在 Discovery v2中包含 text 欄位或任何其他欄位，以及您想要能夠強化或搜尋的文字內容。
   • 包含儲存在文件中的任何自訂 meta 資料。 此 meta 資料通常專用於使用 Discovery 並在搜尋中用來過濾文件的應用程式。 例如，metadata.customer_id。
   • 請勿包含來自 Discovery v1的強化。 例如，enriched_text.entities. Discovery v2 會產生自己的強化。
   • 排除 Discovery 所產生的欄位，除非您的應用程式使用它們，且它們包含文件 v1 版本特有的資訊。 在該情況下，請重新命名欄位，以便在將文件汲取至 Discovery v2時不會取代該欄位。 例如，extracted_metadata.publicationdate 是吸收文件時由 Discovery 產生的欄位。 您可能想要保留 v1 中的 metadata.parent_document_id 資訊，以瞭解最初如何從單一來源文件產生子文件。
   • 避免具有保留欄位名稱的欄位。 如需相關資訊，請參閱 如何處理欄位。

4. 將每一個已編輯的 v1 JSON 文件汲取至 Discovery v2 實例。 Discovery v1 文件 ID 可以在 Discovery v2中維護。 如需如何保留文件 ID 的相關資訊，請參閱 保留文件 ID。

從集合中回復超過 10,000 個文件

查詢最多只能傳回 10,000 個文件。 不過，如果您想要從集合中回復超過 10,000 個文件，則需要將文件分隔成非重疊子群組的方法。 每個子群組應該包含少於 10,000 個可由查詢傳回的文件。 然後，您可以透過結果來標頁數，以擷取文件。

結果的分頁限制為查詢所傳回的文件數上限為 10,000。 具體而言，count 和 offset 分頁參數的結合使用不能超過 10,000 個文件。

將文件分隔成非重疊子群組的一種方法是利用存在於每個文件中且包含唯一值的欄位。 例如，SHA-1 欄位包含原始原始檔的雜湊，並格式化為十六進位字串值。 您可以使用欄位的第一個字元作為將集合劃分為子群組的方法。 因為 SHA-1 包含十六進位值，所以第一個字元最多可以有 16 個可能的值 (0-9 或 a-f)。 如果您依 first_char_of (SHA-1) == 0 來過濾，它可能會傳回大約整個集合的 1/16。 然後，您可以循環執行每一個可能的 16 值，以取得其餘文件。 如果未在其中一個子群組中傳回最佳文件數，則您可以改用 SHA-1 欄位的前 2 個字元，將集合分成 256 個子群組。

更新應用程式處理查詢結果的方式

應用程式顯示查詢結果的方式可能需要更新，因為 v1 和 v2 查詢之間的查詢結果文件語法有下列差異:

• 在實體強化層次，v2:

  • 澄清
  • 情緒
  • Sentiment

  在 v2中，Part of Speech 強化會自動套用至大部分專案類型中的文件，但該強化所產生的索引欄位不會顯示在文件的 JSON 表示法中。

  

• v2 包含提及項目，而不是 v1中的 count 和 relevance。

  提及項目中的每一個項目都對應於文件文字中出現的實體。 在下列範例中，找到七個出現項目。 對於每一個出現項目，會顯示信任評分及提及文字的偏移。 當使用者介面中顯示結果時，您可以使用偏移來強調顯示文件文字中的提及項目。

  

• 查詢回應的 JSON 結構在 v2中稍微重新排列。

• 刪除重複資料資訊不包含在 v2 查詢回應中。

• 在 v2中，enriched_text 是陣列而不是物件。

• 在 Discovery v2中，使用實體 v2 強化。 v2 中的實體類型名稱是以標題大小寫來指定，而不是全部都是大寫字母。 如果您使用指定實體名稱的查詢或聚集，則必須變更大小寫。 例如，將 PERSON 變更為 Person。

• 在 v1 與 v2之間汲取期間，新增至集合的 JSON 檔案中的欄位會以不同方式進行轉換。 如果您的應用程式操作這些結果，您可能需要進行調整。

  您可以在 API 的 更新集合 方法中指定 normalizations 和 conversions 物件，以移動或合併 JSON 欄位。

  如何處理 JSON 來源欄位

  原始 JSON 欄位內容	v1 表示法	v2 表示法	附註
  "field": null	"field": null	N/A	v1 會保留空值。v2 會完全跳過空值欄位。
  "field": ""	"field": ""	N/A	v1 會保留空白文字值。v2 會完全跳過空白文字欄位。
  "field": "value2"	"field": "value2"	"field": "value2"	沒什麼區別
  "field": []	"field": []	N/A	v1 會保留空陣列。v2 會跳過含有空白陣列的欄位。
  "field": [ "value4" ]	"field": [ "value4" ]	"field": "value4"	v1 會保留單態陣列。v2 只會將單態陣列轉換成值; 它不會儲存成陣列的一部分。
  "field": [ 1, 2, 3 ]	"field": [ 1, 2, 3 ]	"field": [ 1, 2, 3 ]	沒什麼區別
  "field": [ "v6", "v7", "v8" ]	"field": [ "v6", "v7", "v8"]	"field": [ "v6", "v7", "v8"]	沒什麼區別