如何處理資料
當您連接至資料來源時,Discovery 會處理 資料來源中的資訊,以建立 集合。
處理資料來源的目標是識別有意義的資訊,並在將它新增至集合時標記它,以便稍後更容易尋找及擷取資訊。
套用至所有資料來源的處理包括下列步驟:
- 識別資料來源中的個別文件
- 在文件中尋找欄位
- 為欄位編製索引
您可以從 管理欄位 頁面查看已編製索引的欄位清單。
-
移至 管理集合 頁面,然後選擇集合。
請確定先完成集合的處理。 「活動」頁面會顯示處理狀態。
-
按一下 Manage fields(管理欄位 )標籤。
顯示的欄位可能根據您的資料而有所不同。 不過,一律會列出一個欄位子集。 這些欄位 (名稱如 footer 及 header) 衍生自「智慧型文件理解 (SDU)」工具,即使您未明確將 SDU 模型套用至集合,也會列出這些欄位。 (如需 SDU 產生的欄位完整清單,請參閱 可用欄位。)
只有指定資料類型的欄位才會儲存在集合的索引中。
儲存在索引中的其中一個 SDU 產生的欄位是 text 欄位。 text 欄位通常包含原始文件的文字主體。 您從 改善及自訂 頁面提交的搜尋結果中傳回的大部分內容都源自此欄位。 如何僅剖析及傳回此欄位中的相關資訊片段,取決於專案所使用的查詢結果配置。 如需相關資訊,請參閱 預覽預設查詢結果。
更多處理程序會新增更多欄位。 而且會根據專案類型自動套用更多處理程序。 當處理程序在集合中的文件上執行時,會新增額外欄位以儲存與處理程序相關聯的資訊。 例如,當內建 Entities 強化套用至集合時,它會啟動一個處理程序,將名稱以 enriched_{field_name}.entities 開頭的欄位新增至集合中的文件。
- 如需依預設套用之強化的相關資訊,請參閱 預設專案設定。
如何處理欄位
對於大部分非結構化檔案類型,檔案中的大量內容會新增至名為 text 的欄位。 對於具有固有資料結構的檔案類型 (例如 JSON 檔案),會使用來源檔案中的名稱來命名儲存內容的欄位。 當您上傳此類型的檔案時,請注意欄位存在一些命名限制。
下列欄位名稱具有特殊意義。 可能的話,請不要在結構化原始檔中使用這些名稱。
document_idhighlighthtmlmetadataparent_document_idresult_metadatascorespans
避免符合下列條件的欄位名稱。 不會查詢具有這些限制字元的欄位名稱。
- 以字元
_、+和-開頭。 例如,+extracted-content。 - 包含字元
.、,、#、?、(、)或:或空格。 例如,extracted content或new:extracted-content。 - 以數字結尾,例如
extracted-content2。
若要處理 Discovery中的文件,集合中的所有文件都必須具有特定欄位的相同資料類型。 當文件中特定欄位的資料類型不同時,欄位檢索程序會失敗,且集合的「活動」頁面的 警告及錯誤摘要 區段中會顯示「無法編製索引」錯誤訊息。
HTML 欄位
文件索引中的 html 欄位會儲存文件的相關結構資訊。
- 如果您使用「智慧型文件理解」工具來註釋集合,則會在
html欄位中檢索文件表示法。 - 如果您使用「智慧型文件理解」工具將預先訓練模型套用至集合,則會在
html欄位及text欄位中為文件表示法編製索引。 html欄位具有大小限制。 如需相關資訊,請參閱 欄位限制。
關於加強資料的附註:
- 如果您想要套用可瞭解文件中表格的強化,文件必須包含
html欄位。
如何處理日期
不同檔案類型以不同方式擷取日期。
- 非結構化檔案
-
從含有非結構化資料的文件主體中擷取日期資訊的最佳方式是使用自然語言處理程序模型強化。 例如,預先建置的「實體」強化會辨識日期,並在
text欄位 (或具有String資料類型的其他內文欄位) 中註釋它們。 在套用強化的文件中,您可以尋找標示為enriched_{fieldname}.entities.type=Date的欄位來尋找日期。Dates from metadata date fields, such as
extracted_metadata.publicationdate, are stored in the index as dates as long as the date format matches one of the supported date data type formats. You can't see nested fields from the Manage fields page. And when you view a search result as JSON, date field values are displayed as string values because the JSON editor shows the date as a string. However, values from date fields behave like dates. You can use greater than (>) or less than (<) operators with such fields in Discovery Query Language queries, for example. - 結構化檔案
-
您匯入的結構檔案 (例如 CSV 或 JSON 檔案) 可能包含您要儲存為日期資料類型的日期欄位。Discovery 可以辨識許多日期格式。 不過,您可能需要將格式新增至清單。 如需相關資訊,請參閱 日期格式設定。
日期格式設定
如果您的文件具有根層次欄位,其中包含日期資訊,則您可以將欄位設為索引中的 Date 資料類型欄位。
Discovery 會自動辨識下列日期格式:
yyyy-MM-dd'T'HH:mm:ssZ
yyyy-MM-dd'T'HH:mm:ssXXX
yyyy-MM-dd'T'HH:mm:ss.SSSZ
yyyy-MM-dd'T'HH:mm:ss.SSSX
yyyy-MM-dd
M/d/yy
yyyyMMdd
yyyy/MM/dd
如果您以其他格式儲存日期,則可以將格式新增至支援的格式清單。
若要新增更多日期格式,請完成下列步驟:
-
從集合的「管理欄位」頁面中,將格式新增為 日期格式 欄位中的新行。
指定 Java SimpleDateFormat 類支援的日期格式。
例如,如果您的記錄只儲存日期的年份值,請將
yyyy新增至支援的日期格式清單。 然後,您可以將包含年份值的欄位的資料類型設為 日期,並重新處理收集。 因此,日期欄位中出現的2019會在索引中儲存為2019-01-01T05:00:00Z。當您新增日期格式時,必須指定日期的相關聯時區。
-
指定時區。
-
選擇性地選取日期語言環境。
您選擇的語言環境用來剖析代表日期類型資料集欄位之日期的字串值。 例如,使用
EEE, MM dd, yyyy格式,English (United States) locale 可以解析"Wednesday, 07 01, 2020"的字串值,而 Japanese (Japan) locale 可以解析"水曜日, 07 01, 2020"的相同字串值。 -
如果您已匯入日期格式為無法辨識的文件,請重新處理文件。
Discovery 無法將文字欄位中提及的日期儲存為索引中的 日期 欄位。 不過,您可以使用強化 (例如 實體 強化) 來識別文字中提及的日期。
如何處理檔案類型
當您上傳文件時,會檢索檔案中的資料。 Discovery會以不同方式處理不同的檔案類型。
CSV 檔案
關於新增資料的注意事項:
-
CSV 檔中定義的每一行都會作為個別文件新增至索引,每一行都具有相同的
parent_document_id。子項文件通常具有語法為
{parent-ID}_n的文件 ID,其中 {parent-ID} 是所新增原始檔案的文件 ID,而 n 是序號。 例如,如果您上傳含有 5 列的 CSV 檔案,則會將五個文件新增至具有文件 ID (例如f5214225c1e03e25190ffcdfad8e84ff_0到f5214225c1e03e25190ffcdfad8e84ff_4) 的集合。 -
您無法對 CSV 檔啟用「光學字元辨識 (OCR)」功能。
-
如果 CSV 檔案具有標頭,則會使用標頭名稱來命名儲存對應直欄中內容的欄位。 請勿使用在 Discovery中具有特殊意義的名稱。 請確定欄位名稱符合命名規則,例如沒有空格和附加數字。 例如,在新增檔案之前,您可以將
start date標頭重新命名為start_date,並將label1重新命名為label-one。 如需相關資訊,請參閱 如何處理欄位。 -
當 CSV 檔案標頭名稱包含受限字元時,當文件轉換器將產生的欄位新增至索引時,會自動從欄位名稱中移除受限字元。
關於加強資料的附註:
- 您無法將預先建置或使用者訓練的「智慧型文件理解」模型套用至 CSV 檔案。
HTML 檔案
如果您上傳 HTML 檔案或搜索具有 HTML 檔案 (例如網站) 的資料來源,則會產生 html 欄位以及 text 欄位。 如需相關資訊,請參閱 HTML 欄位。
JSON 檔案
關於新增資料的注意事項:
-
來源 JSON 檔案中的物件名稱用來命名儲存內容的欄位。 請勿使用在 Discovery中具有特殊意義的名稱。 請確定名稱符合命名規則,例如沒有空格及附加的數字。 例如,在新增檔案之前,您可以將
updated on物件重新命名為updated_on,並將answer2重新命名為answer-two。 如需相關資訊,請參閱 如何處理欄位。 -
如果根層次欄位是陣列,但不包含任何項目,則會從索引中省略該欄位。
-
如果根層次欄位是陣列,且只包含一個項目,則會將陣列編製索引作為一個項目的資料類型。 例如,具有一個字串的字串陣列會檢索為字串。
-
如果巢狀欄位包含陣列,即使陣列只有一個值,也會將它編製成陣列索引。
-
如果根層次欄位是陣列且包含多個項目,則會將資料編製索引為陣列。
-
如果您複製 Discovery 所產生的 JSON,然後將它上傳為 JSON 檔案,請先從檔案中移除這些系統產生的欄位:
document_id、parent_document_id、filename及title。 -
您無法針對 JSON 檔案啟用「光學字元辨識 (OCR)」特性。
-
如果來源文件具有名稱為
document_id的欄位,則會跳過該欄位,且不會新增至集合中的索引。如何使用 API 的
2023-03-31版本更新來處理 JSON 檔案中的document_id欄位。 在更新之前,當您從產品使用者介面上傳 JSON 檔案,或使用 API 以 新增文件 方法來新增它時,檔案的document_id欄位中的值在查詢結果中顯示為document_id值。 不過,已指派不同的文件 ID 給它,並儲存在parent_document_id欄位中。 指定的文件 ID 是您呼叫 List documents 方法時傳回的 ID,也是 Delete document 方法請求的端點 URL 中必須使用的document_id。 當您使用 更新文件 方法來指派新的document_id時,原始 ID 會繼續在查詢結果中傳回。 不過,必須使用指派的 ID 來刪除文件。 如果您的應用程式依賴先前的行為,您可以在 API 呼叫中指定早於 2023-03-31 的版本號碼,例如2020-08-30。
關於加強資料的注意事項:
-
您無法將預先建置或使用者訓練的「智慧型文件理解」模型套用至 JSON 檔案。
-
當您將強化套用至 JSON 檔案中的欄位時,欄位資料類型會轉換為陣列。 即使欄位包含單一值,也會轉換成陣列。 例如,"field1": "Discovery" 會變成 "field1": ["Discovery"]。
-
只會強化 JSON 檔案中自訂欄位的前 50,000 個字元。
-
在自動套用 詞性 (POS) 強化的專案類型中,強化會套用至新增至集合的第一個 JSON 檔案中包含大量檔案內容的欄位。 此欄位由下列規則決定:
- 如果欄位命名為
text,則會套用 POS 強化。 - 系統會選擇具有最長字串值及最高相異值數目的欄位。
- 如果多個欄位符合前一個條件,則會隨機選擇其中一個欄位。
- 如果欄位命名為
-
如果您要將強化套用至巢狀欄位,則必須建立「內容採礦」專案,然後將強化套用至欄位。 如果您想要使用「內容採礦」以外的專案類型,則可以在其他位置重複使用您使用「內容採礦」專案類型所建立的集合。 如需相關資訊,請參閱 套用強化。
您可以在 API 的 更新集合 方法中指定 normalizations 和 conversions 物件,以移動或合併 JSON 欄位。
如何衍生段落
Discovery 使用更準確的演算法來判斷查詢所傳回所有文件的最佳文字段落。 依預設,每個文件都會傳回段落。 它們會顯示為每一個文件查詢結果內的區段,並依段落相關性來排序。
Discovery 使用句子界限偵測來挑選包含完整句子的段落。 它會搜尋大約長度為 200 個字元的段落,然後查看長度兩倍的內容片段,以尋找包含完整句子的段落。 句子界限偵測適用於所有支援的語言,並使用語言特定邏輯。
對於 交談式搜尋以外的所有專案類型,您可以從 自訂顯示畫面> 搜尋結果 頁面變更段落在搜尋結果中的顯示方式。 例如,您可以配置每個文件顯示的段落數,以及每個段落的字元大小上限。