本頁面說明如何設定結構定義欄位,以便為結構化資料、含中繼資料的非結構化資料,或含自訂結構化屬性的網站資料設定應用程式。
欄位設定可協助判斷 Agent Search 如何在結果中使用欄位。您可以在控制台的「結構定義」分頁中設定欄位。Google Cloud
只有包含結構化資料或內含中繼資料的非結構化資料的資料儲存庫,才能設定欄位。
欄位設定
下列欄位設定適用於搜尋或建議資料中的許多欄位類型,但並非所有資料類型都適用。結構定義包含個別欄位的多項欄位設定,下表則列出可套用至結構定義中欄位的設定。強烈建議使用結構化資料,設定下列欄位:
| 設定 | 定義 | 目的 | 用途範例 |
|---|---|---|---|
| 可建立索引 | 將欄位設為可建立索引,即可在文件中的結構化欄位上執行篩選、提升和分面等作業。 類型為 |
將欄位標示為 請注意,將欄位標示為 |
在飯店資料儲存庫中,您可以將 hotel_chain 等欄位設為可建立索引。這樣一來,您就能對 hotel_chain 執行排序、篩選和提升作業。舉例來說,您可以套用篩選器,讓搜尋結果只顯示包含篩選飯店連鎖店的結果。 |
| 可供搜尋 |
最有可能與搜尋相關的欄位會標示為 只有內含文字值的欄位可以標示為可供搜尋。因此,數值價格欄位可編入索引 (用於篩選或分面),但無法做為全文搜尋。 |
將欄位設為「可供搜尋」可提高搜尋查詢中該欄位的召回率,讓使用者透過查詢這些欄位中的文字,找到網頁等內容。將欄位標示為可供搜尋,即可套用排名。因此,如果將過多欄位標示為可搜尋,可能會導致排名演算法過度飽和,傳回過多結果,進而對搜尋精確度造成負面影響。這可能會導致搜尋結果不相關。 |
網際網路服務供應商的支援單處理系統會將每張支援單儲存為結構化文件。如果這些文件包含可搜尋的文字欄位 (例如 |
| 可比對前置字串 (預覽) |
允許使用篩選器運算式中的 詳情請參閱下方的「提供欄位以供前置字元和部分比對」。 |
將欄位設為可比對前置字串,搜尋引擎就能比對欄位值前置字串的查詢字串。如果字串開頭已知,這項功能特別適合用來比對階層式 ID、路徑或程式碼。前置字元比對僅限於正規化欄位值的前 12 個字元,且會增加搜尋索引的大小。您最多只能將 10 個欄位設為可前置字元比對。 |
您有一個欄位 ( |
| 部分可比對 (預覽版) |
允許在篩選器運算式中使用 詳情請參閱下方的「提供欄位以供前置字元和部分比對」。 |
將欄位設為可部分比對,即可在欄位內啟用以符記為準的比對功能,讓使用者在只知道部分欄位值時,也能找到內容。搜尋引擎會比對查詢權杖與欄位值中的權杖,不考慮順序。請注意,將欄位標示為部分可比對會增加搜尋索引的大小。您最多只能將 10 個欄位設為可部分比對。 |
您想篩選歐洲地區。 |
| 可做為動態 facet | 提供情境感知篩選器,協助使用者更精準地搜尋。將欄位設為 Dynamic Facetable,系統就能根據欄位中的不重複值,自動產生互動式篩選器 (構面)。 |
將欄位設為 Dynamic
facetable,使用者就能直接從已擷取的資料選取類別或屬性,動態調整搜尋結果,不必手動預先定義所有可能的篩選選項。使用者可以藉此將搜尋範圍縮小至非常具體的網頁內容。搭配使用 Searchable 和 Dynamic Facetable,可獲得更出色的結果,進而提升搜尋的召回率,以及提供給使用者的側欄品質。 |
系統會擷取公司內部知識庫中的網頁 (例如人資政策),並加入 department、document_type 或 last_modified_date 等資料。如果這些欄位標記為 dynamic facetable,員工搜尋「費用報銷」等字詞時,系統會根據找到的相關結果動態產生互動式篩選器。在這種情況下,網頁介面可能會顯示「部門:財務、旅遊」、「文件類型:政策、常見問題」或「上次修改日期:本季、去年」等切面。 |
| 可擷取 | 當搜尋查詢命中相符內容時,搜尋引擎可以提取可擷取欄位的值,以顯示或用於應用程式,也就是說,原始文件中的資訊會顯示為搜尋結果的一部分。將鍵值欄位 (文件的專屬 ID) 設為可擷取。 | 可擷取的欄位會區分可顯示值的欄位,以及僅用於搜尋邏輯但原始值不應向使用者顯示的欄位,藉此提供搜尋情境。 | 在商家網站上搜尋產品時,product_id、name、price 和 image_url 通常是您要設為可擷取的欄位。另一方面,internal_tracking_code只能編入索引並用於管理用途,不會顯示在公開搜尋結果中。 |
| 可完成 | 允許將欄位內容做為搜尋查詢建議。詳情請參閱「設定自動完成功能」。 | 啟用這項設定後,系統就能根據使用者輸入的內容,即時提供查詢建議。這項功能可引導使用者前往相關內容,並加快搜尋程序。使用自然語言篩選等因素可能會影響這項效能。 | 如果為 completable、product_name、brand 和 category 欄位設定 Tech,當使用者輸入「Tech」時,自動完成建議會顯示:
|
| 可篩選 | 允許建議功能使用欄位篩選建議結果,決定使用者看到的搜尋結果。如要瞭解如何篩選最佳化建議,請參閱「篩選最佳化建議」。 | 將欄位設為 Filterable 有助於為使用者提供個人化建議。請注意,這會受到篩選限制。 |
依語言和戲劇篩選的篩選器設定可能如下所示:language_code: ANY("en", "fr") OR categories: ANY("drama")。 |
常用設定的差異
可建立索引、可供搜尋和可擷取的欄位設定之間有重要差異。下表摘要列出這些差異。
| 功能 | 可建立索引 | 可供搜尋 | 可擷取 |
|---|---|---|---|
| 主要角色 | 讓搜尋引擎可存取欄位內容 | 允許對欄位內容進行全文查詢 | 允許在搜尋結果中傳回欄位值 |
| 分析 | 系統會處理內容並建立索引。 | 通常會經過廣泛的詞彙分析。 | 系統會直接儲存值以供顯示。 |
| Can it be... | |||
| ...可供搜尋? | 是 (通常是先決條件) | 不適用 | 不一定 (可擷取,但無法搜尋) |
| ...可擷取? | 不一定 | 不一定 | 不適用 |
| ...Filterable/Sortable/Facetable? | 是 (通常也是這些項目的先決條件) | 無法直接建立,這些是獨立屬性,通常以可建立索引的欄位為基礎。 | 不會直接影響,這些屬性與欄位的索引和查詢方式有關,而不只是顯示方式。 |
在實務上,許多對使用者體驗至關重要的欄位 (例如名稱、說明和識別資訊) 通常會設為 indexable、searchable 和 retrievable。
限制
欄位設定有下列限制:
- 您最多可將 50 個欄位設為可建立索引、可供搜尋、可擷取或動態商情項目。
- 如要將欄位設為動態商情項目,必須先將其設為可建立索引。
- 如要變更可建立索引的設定,您必須重新建立資料索引。這項作業可能需要數小時,尤其是大型資料儲存庫。
如果您要為媒體搜尋應用程式設定欄位,並想瞭解結構定義中的欄位詳細資訊,請參閱「關於媒體文件和資料存放區」。
更新欄位設定
如要更新欄位設定,請按照下列步驟操作:
前往 Google Cloud 控制台的「AI Applications」頁面。
按一下要編輯的應用程式名稱。
按一下 [Data] (資料)。
按一下 [Schema] (結構定義) 分頁標籤。這個分頁會顯示目前的欄位設定。
如果資料儲存庫包含基本網站資料或沒有中繼資料的非結構化資料,就不會看到「結構化資料」分頁。
按一下 [編輯]。
選取或清除需要更新的欄位設定。系統不支援部分欄位設定。舉例來說,數值欄位無法設為「可搜尋」。
按一下 [Save] (儲存) 套用您的變更。
加權可搜尋欄位 (預先發布版)
如果將欄位標示為可搜尋,您可以指定權重,指出該欄位在搜尋結果中的相對重要性。在大多數情況下,您不需要為個別欄位指定權重,因為預設權重效果良好。
不過,在某些情況下,您可能需要調整權重,例如:
您要從現有的搜尋平台遷移資料,該平台已使用加權欄位。
預設權重無法提供令人滿意的搜尋結果時。具體來說,如果可搜尋的欄位很多,且某些欄位明顯比其他欄位重要,就可能發生這種情況。
或許摘要是搜尋時最重要的欄位,因此您想優先處理該文字。
或者,結構化資料含有高度相關的關鍵字,可準確預測搜尋結果,但由於這個欄位比其他欄位短得多,因此影響力往往會被較長的欄位掩蓋。提高權重可確保該目標發揮預期影響。
重量等級
權重會分級如下:
| 欄位重要性 | 說明 |
|---|---|
| 非常低 | 系統在合併所有欄位的評分時,仍會考量的低值。如要進一步降低權重,讓效果可忽略不計,請不要將該欄位標示為可搜尋。 |
| 低 | 低於預設值的權重。 |
| 預設 | 可搜尋欄位的標準權重。在大多數情況下,這個權重都能提供相當不錯的成效。 |
| 高 | 權重明顯高於預設值。 |
| 非常高 | 權重占多數。通常最多只能為一個欄位保留這項功能。 |
更新結構定義並重新建立索引
如要為可搜尋的欄位新增權重,必須更新結構定義,然後重新為資料儲存庫中的資料建立索引。更新結構定義需要數小時,而且沒有可靠的指標可判斷索引作業何時完成,因此您需要高估索引時間。
設定欄位的權重等級
設定欄位權重等級的作業可能很繁瑣,因為您只能進行小幅變更,然後仔細檢查搜尋結果,確認是否出現非預期的後果。每次變更後,您必須等待重新建立索引完成,才能評估變更的影響。
搜尋欄位權重只能透過 API 設定。這項功能不適用於 Google Cloud 控制台。
如要設定權重,請透過 API projects.locations.dataStores.schemas.patch 方法更新資料儲存庫的架構。
如果還沒有結構定義,請按照「查看結構定義」一文中的操作說明取得結構定義。
按照指示以程式輔助方式更新結構化資料。為一或多個可搜尋的欄位新增權重,如以下範例所示:
"summary": { "type": "string", "searchable": true, "weight": "high" }, "uri": { "type": "string", "searchable": true, "weight": "low" },在本例中,
summary欄位設為高於正常值的權重,uri欄位則設為較低的權重。如要將權重設回預設值,請設為default。weight 參數的有效值如下:
very_lowlowdefaulthighvery_high
等待重新建立索引完成,然後測試搜尋行為。
提供可供前置字元和部分比對的欄位 (搶先體驗)
如果是 string 類型的欄位,您可以編輯結構定義,讓欄位可供前置字元比對或部分比對。這樣您就能在篩選運算式中使用 STARTS_WITH 或 CONTAINS。
更新結構定義並重新建立索引
如要讓欄位支援前置字元或部分比對,必須更新結構定義,然後重新為資料儲存庫中的資料建立索引。更新結構定義需要數小時,而且沒有可靠的指標可判斷索引作業何時完成,因此您需要高估索引時間。
更新前置字元和部分相符的結構定義
如要指定可進行前置字元比對或部分比對的欄位,請透過 API projects.locations.dataStores.schemas.patch 方法更新資料儲存庫的結構定義。
如果還沒有結構定義,請按照「查看結構定義」一文中的操作說明取得結構定義。
按照指示以程式輔助方式更新結構化資料。在結構定義中,將可比對的參數設為
true,如以下範例所示:"zone": { "type": "string", "searchable": true, "prefixMatchable": true }, "region": { "type": "string", "searchable": true, "partialMatchable": true }, "model": { "type": "string", "searchable": true, "prefixMatchable": true, "partialMatchable": true },在本範例中,
zone欄位設為可進行前置字元比對。篩選運算式最多可使用 12 個字元 (不區分大小寫),用來比對欄位值。region欄位設為可部分比對。等待重新建立索引完成。
前置字串比對詳細資料
在 Agent Search 中,前置字元比對功能可根據欄位值是否以特定字串開頭,篩選搜尋結果。這項功能由 STARTS_WITH 運算子提供支援,且目標文字欄位必須在結構定義中設定為 prefixMatchable。
標準化和比對邏輯
為提升效能並確保一致性,系統會對欄位值 (建立索引期間) 和查詢字串 (搜尋期間) 進行特定正規化程序。
轉換成小寫:所有字元都會轉換成小寫。這會讓比對不區分大小寫。
12 個字元的截斷:系統只會考慮字串的前 12 個字元。超過這個限制的字元會遭到忽略,不會用於前置字元比對。
運作方式
在建立索引時,如果欄位標示為 prefixMatchable,系統會為前 12 個字元產生前置字元權杖。以 asia-south1-c 這類值為例,索引會儲存 a、as、asi、asia、asia- 等符記,最多可儲存第 12 個字元 (asia-south1-)。
在查詢時,提供給 STARTS_WITH 運算子的字串也會轉換為小寫,並截斷為 12 個字元。然後系統會比對查詢與儲存的前置字元權杖。
範例
以下範例說明 12 個字元的正規化如何影響搜尋結果:
廣泛比對:
STARTS_WITH("A")比對開頭為「a」的任何值 (不區分大小寫),例如asia、australia或africa。部分前置字元:
STARTS_WITH("asia-south")會同時比對asia-south1-a和asia-southeast1-b,因為兩者都以指定的 10 個字元開頭。截斷行為:由於系統只會比對前 12 個字元,因此
STARTS_WITH("asia-south1-a")會比對asia-south1-c的欄位值。這是因為兩個字串都正規化為相同的前置字元 (12 個字元):asia-south1-。
部分比對的詳細資料
在 Agent Search 中,部分相符功能可根據欄位值是否包含特定字詞或權杖來篩選結果。這項功能由 CONTAINS 運算子提供支援,且目標文字欄位必須在結構定義中設定為 partialMatchable。
正規化和符記化邏輯
Agent Search 會將欄位值 (在建立索引期間) 和查詢字串 (在搜尋期間) 正規化並標記化:
轉換為小寫:Agent Search 會將字元轉換為小寫。這樣比對時就不會區分大小寫。
斷詞:Agent Search 會使用空格和其他字元做為分隔符號,將字串拆分成個別詞元 (字詞)。
標準分隔符:空格和常見標點符號會做為分隔符,包括連字號 (
-)、斜線 (/)、逗號 (,)、句號 (.)、星號 (*)、大括號 ({ })、方括號 ([ ])、圓括號 (( )) 和單引號 (')。非分隔符:連接符號 (
&) 和底線 (_) 不會做為分隔符。系統會將以這些符號連結的字元視為單一代碼。電子郵件分隔符號 (
@):@符號是特殊分隔符號,可協助系統辨識電子郵件地址。系統會為個別元件和合併表單產生權杖。舉例來說,它會將support+tier1@example.com權杖化為support、tier1、example、com、support+tier1@example.com和support@example.com。
運作方式
在建立索引時,系統會針對標示為 partialMatchable 的欄位,將欄位值正規化並權杖化,然後將產生的權杖儲存在索引中。舉例來說,如果欄位值為「25-meter, outdoor, swimming
pool」,系統會將其權杖化為「[25, meter, outdoor, swimming, pool]」。
在查詢時,提供給 CONTAINS 運算子的字串會經過相同的正規化和權杖化程序。搜尋引擎接著會驗證所有查詢權杖是否與該欄位的儲存權杖相符。權杖順序不會影響結果。
範例
以下範例說明權杖化如何影響部分相符結果:
基本符記比對:如果欄位值為
25-meter, outdoor, swimming pool,則CONTAINS("Outdoor pool")的篩選條件會相符。系統會將查詢權杖化為[outdoor, pool],兩者都會出現在欄位的權杖中。順序獨立性:篩選條件
CONTAINS("pool outdoor")也會比對欄位值25-meter, outdoor, swimming pool,因為系統會檢查每個權杖是否存在,而不會考量權杖順序。電子郵件地址比對:如果欄位儲存電子郵件地址
support+tier1@example.com,由於@符號的特殊權杖化方式,CONTAINS("support")、CONTAINS("example.com")或CONTAINS("support@example.com")等篩選器都會成功比對。