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

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

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

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

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

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

可信度分數和閾值

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

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

未依據範例

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

不相關範例

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

未依據和不相關範例

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

更多範例

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

來源：

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

已依據且相關

未依據但相關

已依據但不相關

未依據且不相關

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

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

為了在輸入中標記依據來源和查詢，我們提供 2 個標籤，其運作方式與輸入標籤相同。這些標籤是 amazon-bedrock-guardrails-groundingSource_xyz 和 amazon-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 標籤標記的情境。