使用情境依據檢查來篩選回應中的幻覺 - Amazon Bedrock

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

使用情境依據檢查來篩選回應中的幻覺

Amazon Bedrock 防護機制支援情境依據檢查,可在提供參考來源和使用者查詢時,偵測和篩選模型回應中的幻覺。支援的使用案例包括摘要、複寫和問題回答,如電腦科學學科所定義。(不支援轉換 QA/Chatbot 使用案例。)

情境依據檢查會檢查每個已處理區塊的相關性。如果任何一個區塊被視為相關,整個回應就會被視為相關,因為它對使用者的查詢有答案。對於串流 API,這可能會導致不相關的回應傳回給使用者的情況,並且僅在整個回應串流之後才會標記為不相關。

內容接地會檢查下列範例:

  • 依據 – 這會檢查模型回應是否根據來源而符合事實,並且以來源為依據。回應中引入的任何新資訊都會被視為未依據。

  • 關聯性 – 這會檢查模型回應是否與使用者查詢相關。

請考慮參考來源的範例,當中包含「倫敦是英國的首都。東京是日本的首都」,而使用者查詢是「日本的首都是什麼?」。「日本的首都為倫敦」等回應將被視為不合理且不符事實,其中「英國的首都為倫敦」等回應將被視為不相關,即使其正確且以來源為依據也一樣。

注意

當請求包含多個 grounding_source 標籤時,防護機制會合併並評估所有提供的 grounding_source 值,而不是分別考慮每個 grounding_source。此行為對於 query 標籤是相同的。

注意

情境依據政策目前支援最多 100,000 個字元的依據來源、1,000 個字元的查詢,以及 5,000 個字元的回應。

可信度分數和閾值

情境依據檢查會產生可信度分數,對應到根據提供的來源和使用者查詢處理的每個模型回應的依據和相關性。您可以設定閾值,根據產生的分數篩選模型回應。篩選閾值會決定模型回應的最低允許可信度分數,以便在生成式 AI 應用程式中將其視為依據且相關。例如,如果您的依據閾值和相關性閾值都設定為 0.7,則依據或相關性分數小於 0.7 的所有模型回應都會偵測為幻覺,並在您的應用程式中予以封鎖。隨著篩選閾值的增加,封鎖未依據和不相關情境的可能性會增加,且在應用程式中看到幻覺情境的可能性也會降低。您可以設定 0 到 0.99 之間的依據和相關性閾值。閾值 1 無效,因為這會封鎖所有情境。

情境依據檢查需要 3 個元件才能執行檢查:依據來源、查詢和要防護的情境 (或模型回應)。根據您是使用調用 API、Converse API 或直接使用 ApplyGuardrail,這些設定會有所不同。

  • 依據來源 – 回答任何使用者查詢所需的情境資訊。例如,「倫敦是英國的首都。東京是日本的首都。」

  • 查詢 – 使用者可能提出的問題。例如,「日本的首都是什麼?」。

  • 要防護的情境 – 應該相對於依據來源和查詢進行防護的文字。對於調用和 Converse API,這是模型回應。例如,這可以是「日本的首都是東京」。

未依據範例

  • 依據來源 -「倫敦是英國的首都。東京是日本的首都。」

  • 查詢 -「日本的首都是什麼?」

  • 要防護的情境 -「日本的首都是倫敦。」

在此範例中,要防護的情境與查詢相關,但由於未正確使用依據來源,因此未依據。這將具有較低的依據分數。

不相關範例

  • 依據來源 -「倫敦是英國的首都。東京是日本的首都。」

  • 查詢 -「日本的首都是什麼?」

  • 要防護的情境 -「英國的首都是倫敦。」

在此範例中,依據要防護的情境,但不相關。它使用來自依據來源的資訊,但不回答查詢。這個為低相關性分數。

未依據和不相關範例

  • 依據來源 -「倫敦是英國的首都。東京是日本的首都。」

  • 查詢 -「日本的首都是什麼?」

  • 要防護的情境 -「外面在下雨。」

在這個範例中,未依據要防護的情境,也不相關。它既未使用來自依據來源的資訊,也未回答查詢。這個為低依據和相關性分數。

更多範例

考慮一個旨在回答與費用相關問題的銀行應用程式。

來源:

  • 開立支票帳戶不會產生相關費用。

  • 維護支票帳戶的每月費用為 10 美元。

  • 國外轉帳需支付 1% 的交易費用。

  • 國內轉帳不會產生相關費用。

  • 與信用卡帳單延遲繳費相關的費用為 23.99%。

根據上述來源,根據使用者的查詢,可能會有四種情況。

已依據且相關

  • 問:與支票帳戶相關的費用是多少?

  • 答:維護支票帳戶的每月費用為 10 美元。國內轉帳不會產生相關費用。不過,國外轉帳需支付 1% 的交易費用。開立支票帳戶不會產生相關費用。

未依據但相關

  • 問:與信用卡相關聯的交易費用是多少。

  • 答:與信用卡相關聯的交易費用為 23.99%。

已依據但不相關

  • 問:使用支票銀行帳戶的費用是多少?

  • 答:根據提供的資訊,信用卡的遲繳費用為 23.99%。

未依據且不相關

  • 問:使用支票銀行帳戶的費用是多少?

  • 答:每次交易證券帳戶的費用為 0.5 美元。

使用主控台新增情境依據檢查

  1. AWS 管理主控台 使用具有使用 Amazon Bedrock 主控台之許可的 IAM 身分登入 。接著,開啟位於 https://console.aws.amazon.com/bedrock 的 Amazon Bedrock 主控台。

  2. 從左側導覽窗格中,選擇防護機制,然後選擇建立防護機制

  3. 提供防護機制詳細資訊頁面中,執行下列動作:

    1. 防護機制詳細資訊區段中,提供防護機制的名稱和選用的描述

    2. 封鎖提示的訊息中,輸入套用防護機制時顯示的訊息。選取為回應套用相同的封鎖訊息核取方塊,以在將防護機制套用至回應時,使用相同的訊息。

    3. (選用) 若要為您的防護機制啟用跨區域推論,請展開跨區域推論,然後選取為您的防護機制啟用跨區域推論。選擇護欄設定檔,定義可路由護欄推論請求 AWS 區域 的目的地。

    4. (選用) 根據預設,您的防護機制會使用 AWS 受管金鑰進行加密。若要使用您自己的客戶受管 KMS 金鑰,請展開 KMS 金鑰選取範圍,然後選取自訂加密設定 (進階) 核取方塊。

      您可以選取現有的 AWS KMS 金鑰,或選取建立金鑰以建立新的 AWS KMS 金鑰

    5. (選用) 若要將標籤新增至防護機制,請展開標籤,然後為您定義的每個標籤選取新增標籤

      如需詳細資訊,請參閱標記 Amazon Bedrock 資源

    6. 選擇下一步

  4. 新增情境依據檢查頁面上,設定閾值以封鎖未依據或不相關的資訊。

    注意

    對於每種類型的檢查,您可以移動滑桿或輸入閾值,從 0 到 0.99。為您的使用選取適當的閾值。較高的閾值需要以高度信賴為依據或相關的回應才能允許。低於閾值的回應將遭篩選掉。

    1. 依據欄位中,選取啟用依據檢查,以是否已依據檢查模型回應。

    2. 關聯性欄位中,選取啟用關聯性檢查,以檢查模型回應是否相關。

    3. 當您完成設定敏感資訊篩選條件時,請選取下一步跳至檢閱和建立

使用調用 API 呼叫情境依據檢查

為了在輸入中標記依據來源和查詢,我們提供 2 個標籤,其運作方式與輸入標籤相同。這些標籤是 amazon-bedrock-guardrails-groundingSource_xyzamazon-bedrock-guardrails-query_xyz,並假設標籤尾碼是 xyz。例如:

{ "text": """ <amazon-bedrock-guardrails-groundingSource_xyz>London is the capital of UK. Tokyo is the capital of Japan. </amazon-bedrock-guardrails-groundingSource_xyz> <amazon-bedrock-guardrails-query_xyz>What is the capital of Japan?</amazon-bedrock-guardrails-query_xyz> """, "amazon-bedrock-guardrailConfig": { "tagSuffix": "xyz", }, }

請注意,需要模型回應才能執行情境式依據檢查,因此檢查只會在輸出上執行,而不會在提示上執行。

這些標籤可與 guardContent 標籤搭配使用。如果未使用任何 guardContent 標籤,則防護機制預設會將所有設定的政策套用至整個輸入,包括依據來源和查詢。如果使用 guardContent 標籤,則情境依據檢查政策將僅調查依據來源、查詢和回應,而其餘政策將調查 guardContent 標籤中的情境。

使用 Converse 調用 API 呼叫情境依據檢查

若要標記 Converse API 的依據來源和查詢,請使用每個防護情境區塊中的限定詞欄位。例如:

[ { "role": "user", "content": [ { "guardContent": { "text": { "text": "London is the capital of UK. Tokyo is the capital of Japan", "qualifiers": ["grounding_source"], } } }, { "guardContent": { "text": { "text": "What is the capital of Japan?", "qualifiers": ["query"], } } }, ], } ]

請注意,需要模型回應才能執行情境式依據檢查,因此檢查只會在輸出上執行,而不會在提示上執行。

如果沒有以 guard_content 限定詞標記任何情境區塊,則情境依據檢查政策只會調查依據來源、查詢和回應。其餘政策將遵循預設調查行為:系統提示預設為不進行調查,而訊息預設為進行調查。不過,如果以 guard_content 限定詞標記情境區塊,則情境依據檢查政策只會調查依據來源、查詢和回應,而其餘政策則會調查以 guardContent 標籤標記的情境。

使用 ApplyGuardrail API 呼叫情境依據檢查

搭配 ApplyGuardrail 使用情境依據檢查類似於搭配 Converse API 使用。若要標記 ApplyGuardrail 的依據來源和查詢,請使用每個情境區塊中的限定詞欄位。不過,由於並未使用 ApplyGuardrail 調用模型,因此您還必須提供額外的情境區塊,其中包含要防護的情境。此情境區塊可以選擇性地符合 guard_content 的資格,相當於 Invoke* 或 Converse* API 中的模型回應。例如:

[ { "text": { "text": "London is the capital of UK. Tokyo is the capital of Japan", "qualifiers": [ "grounding_source" ] } }, { "text": { "text": "What is the capital of Japan?", "qualifiers": [ "query" ] } }, { "text": { "text": "The capital of Japan is Tokyo." } } ]

請注意,需要模型回應才能執行情境式依據檢查,因此檢查只會在輸出上執行,而不會在提示上執行。

如果沒有以 guard_content 限定詞標記任何情境區塊,則情境依據檢查政策只會調查依據來源、查詢和回應。其餘政策將遵循預設調查行為:系統提示預設為不進行調查,而訊息預設為進行調查。不過,如果以 guard_content 限定詞標記情境區塊,則情境依據檢查政策只會調查依據來源、查詢和回應,而其餘政策則會調查以 guardContent 標籤標記的情境。