Bedrock-Agenten: Zusammenfassung von Merkmalen, versionierte Schutzregeln und Wissensdatenbank.

Fehler, die keinen Lärm machen

In einem KI-Agentensystem kann viel schiefgehen, und die schlimmsten Fehler erzeugen weder Fehlermeldungen noch Alarme. Die Qualität verschlechtert sich einfach weiter. Die Sitzungsmemory sammelt Rauschen anstelle von Signalen, Sicherheitsregeln befinden sich außerhalb der Versionskontrolle, und der Agent ruft Tools auf, die eine Wissensdatenbank direkt liefern könnte.

Drei Lösungen beheben diese Probleme bei Amazon Bedrock: eine MEMORY_SUMMARIZATION-Überlagerung, die bedeutungsvolle Benutzersignale über Sitzungen hinweg bewahrt, ein in Terraform versioniertes Bedrock Guardrail sowie eine optional verfügbare Wissensdatenbank, die von S3 unterstützt wird.

Prompt-Engineering kann die gesamte Last nicht tragen. Reale Systeme benötigen Kontrollmechanismen an drei Stellen:

1. Qualität der Sitzungsmemory. Zusammenfassungen müssen die richtigen Benutzersignale beibehalten.
2. Sicherheitssteuerung. Sicherheitsregeln sollten klar definiert und versioniert sein.

Abgrenzung zur Informationsabfrage. Der Agent benötigt eine klare Regel dafür, wann Tools, die Wissensdatenbank oder beides verwendet werden sollen.

Ohne diese Regeln wirkt ein System in Demos in der Regel stabil, verschlechtert sich jedoch, sobald echter, vielfältiger Traffic eintrifft.

Wie die Sitzungsspeicherung funktioniert

Durch die Zusammenfassung des Speichers bleibt die Historie eines Benutzers von einer Sitzung zur nächsten verfügbar, sodass alte Nachrichten nicht erneut extrahiert und in Echtzeit verarbeitet werden müssen. Bei Classic Agents bietet Bedrock eine grundlegende Möglichkeit über enabled_memory_types = ["SESSION_SUMMARY"] in aws_bedrockagent_agent, und GetAgentMemory im Agent Runtime liest den gespeicherten Inhalt aus.

Wenn die Speicherfunktion aktiviert ist, findet die Verarbeitung asynchron nach Schließen der Sitzung statt. Bedrock fasst das abgeschlossene Gespräch zusammen, speichert diese Zusammenfassung und fügt sie in spätere Sitzungen ein, die denselben memoryId teilen – ohne dass dies die Antwort des Benutzers verzögert.

Bedrock liefert einen Standardprompt, der definiert, wie die Zusammenfassung funktioniert:

{
  "messages": [
    {
      "role" : "user",
      "content" : "We will be given a conversation between a user and an AI
        assistant.
        When available, in order to have more context, we will also be given
        summaries we previously generated.
        Our goal is to summarize the input conversation.
        When we generate summaries we ALWAYS follow the below guidelines:
        <guidelines>
          - Each summary MUST be formatted in XML format.
          - Each summary must contain at least the following topics: 'user
            goals', 'assistant actions'.
          - Each summary, whenever applicable, MUST cover every topic and be
            placed between <topic name='$TOPIC_NAME'></topic>.
          - We ALWAYS output all applicable topics within <summary></summary>
          - If nothing about a topic is mentioned, DO NOT produce a summary
            for that topic.
          - We summarize in <topic name='user goals'></topic> ONLY what is
            related to the user, e.g., user goals.
          - We summarize in <topic name='assistant actions'></topic> ONLY what
            is related to the assistant, e.g., assistant actions.
          - NEVER start with phrases like 'Here's the summary...', provide
            directly the summary in the format described below.
        </guidelines>The XML format of each summary is as follows:
        <summary>
          <topic name='$TOPIC_NAME'>
            ...
          </topic>
          ...
        </summary>
        Here is the list of summaries we previously generated.
        <previous_summaries>
          $past_conversation_summary$
        </previous_summaries>
        And here is the current conversation session between a user and an AI
        assistant:
        <conversation>
          $conversation$
        </conversation>
        Please summarize the input conversation following the above guidelines
        plus the below additional guidelines:
        <additional_guidelines>
          - ALWAYS strictly follow the above XML schema and ALWAYS generate
          well-formatted XML.
          - NEVER forget any detail from the input conversation.
          - We also ALWAYS follow the below special guidelines for some of the topics.
          <special_guidelines>
            <user_goals>
              - We ALWAYS report in <topic name='user goals'></topic> all details the user
              provided in formulating their request.
            </user_goals>
            <assistant_actions>
              - We ALWAYS report in <topic name='assistant actions'></topic> all details
              about actions taken by the assistant, e.g., parameters used to invoke actions.
            </assistant_actions>
          </special_guidelines>
        </additional_guidelines>"
        }
    ]
}

Die Anweisungen befinden sich hauptsächlich im Abschnitt <guidelines/>, der dem Agenten mitteilt, sein Ergebnis innerhalb eines <summary/>-Tags zurückzugeben. Die Zusammenfassung ist nach Themen unterteilt. Alles, was sich auf die Ziele des Benutzers bezieht, wird unter dem Thema user goals aufgeführt, die eigenen Aktionen des Agents unter assistant actions. Jedes Thema verwendet außerdem eine Umhüllung in Form von <topic name='$TOPIC_NAME'></topic>. Die erwartete Ausgabe sieht wie folgt aus:

<summary>
  <topic name='$TOPIC_NAME'>
    ...
  </topic>
  ...
</summary>

Bedrock füllt <previous_summaries/> mit früheren Zusammenfassungen über die Variable $past_conversation_summary$, und das aktuelle Gespräch wird innerhalb von <conversation>$conversationlt;/conversation> dargestellt. Zwei weitere Abschnitte, <additional_guidelines/> und <special_guidelines/>, ermöglichen es, der Zusammenfassungsstrategie weitere Details hinzuzufügen.

Der Lebenszyklus verläuft wie folgt:

1. Die Speicherfunktion wird in der Agentenkonfiguration mit memory_configuration sowie enabled_memory_types = ["SESSION_SUMMARY"] aktiviert.
2. Der Aufrufer ruft den Agenten mit einer eindeutigen memoryId für jeden Benutzer auf.
3. Die Sitzung endet entweder durch endSession = true oder aufgrund einer Zeitüberschreitung.
4. Bedrock erzeugt die Zusammenfassung im Hintergrund.

In späteren Sitzungen mit derselben memoryId platziert Bedrock den Speicherkontext in Orchestrierungsplatzhalter wie $memory_content$.

Daraus ergeben sich zwei Folgen. Zusammenfassungen sind nicht sofort verfügbar und können einige Zeit nach Beendigung einer Sitzung erscheinen. Wenn sich die memoryId von Anfrage zu Anfrage ändert, geht die Kontinuität verloren.

Achtung: Instabile memoryId-Werte, wie beispielsweise Verbindungs IDs, in denen Benutzer IDs enthalten sind, stören die Speicherkontinuität. Verwenden Sie einen Identifikator, der für jeden Benutzer oder jede Konversationsinstanz konstant bleibt.

Zusammenfassungen nützlich machen

Die Standardzusammenfassung ist eine allgemeine Übersicht. Das eignet sich für einen breit gefächerten Assistenten, ist aber oft zu umfangreich für einen spezialisierten. Für einen kleinen Nachrichtenassistenten sollte eine prägnante Zusammenfassung Folgendes beinhalten:

• wiederkehrende Themen wie KI-Nachrichten, Klima oder Geopolitik;

geförderte Regionen und Einheiten;

Geschichten, denen ein Benutzer über verschiedene Sitzungen hinweg folgt;

ausdrückliche Abneigungen, wie zum Beispiel „Kryptowährungen nicht einbeziehen.“

Ohne diese Struktur nimmt die Menge der Daten zu, während die Relevanz abnimmt.

Die Aktivierung beginnt mit der Agent-Ressource in Terraform:

resource "aws_bedrockagent_agent" "agent" {
  # ... existing code above ...
  memory_configuration {
    enabled_memory_types = ["SESSION_SUMMARY"]
    storage_days = 30
    session_summary_configuration {
      max_recent_sessions = 5
    }
  }
  # ... existing code below ...
}

Bedrock-Agenten akzeptieren hier nur den SESSION_SUMMARY-Typ. AgentCore geht weiter und bietet Zusammenfassungen, Benutzerpräferenzen, semantische Fakten sowie benutzerdefinierte Speichermethoden. storage_days legt fest, wie lange die Zusammenfassungen aufbewahrt werden, und max_recent_sessions bestimmt, wie viele aktuelle Sitzungen zusammengefasst werden.

Jede Aufrufung muss einen memoryId enthalten, hier den user_id, damit die Gespräche mit derselben Entität verknüpft werden können:

# Invoke with stable memoryId and explicit session end
resp = bedrock_agent_runtime.invoke_agent(
  agentId=agent_id,
  agentAliasId=alias_id,
  sessionId=conversation_id,
  memoryId=user_id,     # stable per user
  inputText=message_text,
  endSession=is_last_turn
)

Die Abrufung verwendet denselben memoryId:

# Retrieve summaries later (classic Agents API)
memory = bedrock_agent_runtime.get_agent_memory(
  agentId=agent_id,
  agentAliasId=alias_id,
  memoryId=user_id,
  memoryType="SESSION_SUMMARY"
)

Überlagern des Zusammenfassungsauftrags

Wenn die Speicherfunktion aktiviert ist, ermöglicht Bedrock es, einen Überlagerauftrag einzusetzen, um die MEMORY_SUMMARIZATION-Phase zu ersetzen: prompt_type = „MEMORY_SUMMARIZATION“ durch prompt_creation_mode = „OVERRIDDEN“. Klassische Agenten verwenden dazu zwei spezielle Platzhalter: $past_conversation_summary$ für gespeicherte Zusammenfassungen, die zur gleichen Speicheridentität gehören, sowie $conversation$ für den Text der aktuellen Sitzung. In Orchestrierungsvorlagen wird der Speicherkontext über $memory_guideline$ für Strategien, $memory_content$ für die Persistenz und $memory_action_guideline$ für Systemaufträge bereitgestellt.

Eine an die Bedürfnisse angepasste Version des Standardauftrags legt genau fest, was der Agent erfassen und was er ignorieren soll, sodass nur nützliche Details übrig bleiben:

prompt_override_configuration {
  prompt_configurations = [{
    prompt_type = "MEMORY_SUMMARIZATION"
    prompt_state = "ENABLED"
    prompt_creation_mode = "OVERRIDDEN"
    parser_mode = "DEFAULT"
    base_prompt_template = <<-JSON
{
  "system": "
  We are summarizing a news research conversation for future sessions.
  Capture:
    - recurring topics,
    - region focus,
    - entities and stories the user tracks,
    - explicit dislikes.
  Ignore:
    - greetings and small talk,
    - implementation questions about the assistant itself.
  Past summaries:
  <previous_summaries>
    $past_conversation_summary$
  </previous_summaries>
  Current session:
  <conversation>
    $conversation$
  </conversation>
  Return concise bullet points focused on user signal.",
  "messages": [
    {
      "role": "user",
      "content": [{ "text": "Generate a focused memory summary for personalization." }]
    }
  ]
}
JSON
  inference_configuration = [{
    temperature = 0.2
    top_k = 64
    top_p = 0.9
    max_length = 512
    stop_sequences = []
  }]
  # ... existing code below ...
}
]
}

Überschreiben Sie den Stadium-Modus, wenn eine allgemeine Zusammenfassung keine besseren späteren Antworten liefert, wenn Zusammenfassungen ein hohes Signal-Rausch-Verhältnis benötigen oder wenn der Speichertoken-Budget eng und vorhersehbar gehalten werden muss. Wenn der Assistent allgemein ist und nicht auf Personalisierung setzt, reicht die Standardeinstellung aus.

Typische Fehler sind:

• instabile memoryId-Werte, beispielsweise Verbindungs IDs anstelle von Benutzer IDs;
• Sitzungen, die niemals enden und daher keine Zusammenfassung erzeugt wird;
• ausführliche Zusammenfassungsanfragen, die im Grunde ein vollständiges Transkript neu erstellen;
• Mischung von Zusammenfassungszielen mit Formatierungszielen, die für die Nachverarbeitung bestimmt sind.

Richtlinien: Vorgaben, die Anfragen nicht durchsetzen können

Manchmal sind Nutzer unhöflich, missbrauchen den Assistenten oder fragen nach internen Details, Geheimnissen sowie persönlichen Daten anderer Personen. Schutzmechanismen kümmern sich darum. Das Prinzip ist einfach: Anweisungen leiten das Verhalten, Schutzmechanismen sorgen für die Einhaltung der Richtlinien. Verwenden Sie Anweisungen für Entscheidungen und Formatierung sowie Schutzmechanismen für Sicherheitsgrenzen bezüglich der Eingaben der Nutzer und der Ausgaben des Assistenten.

Tipp: Probieren Sie Schutzmechanismen zunächst im DETECT-Modus aus, bevor Sie sie blockieren. Die Überprüfung dessen, was gestoppt worden wäre, beeinträchtigt die Tester nicht.

Bedrock bietet mehrere Schutzmechanismen, für die keine zusätzliche Einrichtung erforderlich ist – man fügt sie einfach der Liste hinzu:

• Inhaltsfilter erkennen Hass, Beleidigungen, Gewalt, sexuellen Inhalt, Fehlverhalten sowie Angriffe mittels Anweisungen und bieten Einstellungen für die Stärke der Überwachung sowie entsprechende Aktionen. Sie eignen sich für eine ständige Grundsicherheit im normalen Nutzerverkehr.

Ablehnung von Themen sperren verbotene Themabereiche ab, was nützlich ist für Produkt- oder regulatorische Grenzen wie „Diskutieren Sie diesen Bereich niemals.“

Wortfilter verwenden verwaltete sowie benutzerdefinierte gesperrte Begriffe, die sich gut für präzise Geschäftsbegriffe, Schimpfwörter oder streng zu blockierende Wörter eignen.

Filter für sensible Informationen erkennen PII-Einheiten sowie benutzerdefinierte Regex-Regeln und sichern so die Privatsphäre von Kontoinhalten, E-Mails und Telefonnummern.

Kontextbezogene Überprüfungen sorgen in den Abrufprozessen für die Einhaltung von Richtlinien bezüglich fundierter Antworten, was bei RAG- und Wissensdatenbank-Lösungen von Bedeutung ist, wo die Kontrolle von Fehlinformationen entscheidend ist.

Prompt-Angriffe gehören auf der Standard-Ebene als Kategorie zu den Inhaltssiegeln (Jailbreaks, Einblendungen, Prompt-Leckagen).

Automatisierte Schlussfolgerungsprüfungen überprüfen die Konformität mit den Richtlinienregeln, um in regulierten Antworten eine strenge Logik zu gewährleisten.

Die meisten Teams arbeiten am besten, wenn sie diese Schritte schrittweise einführen: Zuerst Filter für Inhalte und sensible Informationen, anschließend Filter nach Thema und Worten, und schließlich Grundlegende Überprüfungen sowie Schlussfolgerungen, sobald die Abrufrichtlinien ausgereift sind.

Ablauf der Bewertung

Die Sicherheitsmechanismen prüfen in beide Richtungen:

1. Eingabe. Zunächst wird die Anfrage des Benutzers bewertet, wobei alle konfigurierten Richtlinien parallel ausgeführt werden. Ein Block lässt Bedrock Ihren blocked_input_messaging zurückgeben und die weitere Verarbeitung überspringen.
2. Ausgabe. Wenn die Eingabe überprüft wurde, gibt das Modell eine Antwort ab, deren Ausgabe anschließend geprüft wird. Ein Block ersetzt die Antwort durch blocked_outputs_messaging oder maskiert sie, falls sensible Filter konfiguriert sind.

Falls beides bestanden wird, wird die Ausgabe unverändert zurückgesendet.

Die Reihenfolge ist für die Kosten wichtig. Eine blockierte Eingabe kostet nur die Bewertung durch den Schutzmechanismus und nicht die Modellinferenz.

Jeder Inhaltssensor verfügt über zwei unabhängige Einstellungen. Stärke (inputStrength und outputStrength) kann den Wert NONE, LOW, MEDIUM oder HIGH annehmen und bestimmt, wie aggressiv Verstöße erkannt werden. Aktion (inputAction und outputAction) kann entweder BLOCK sein, wodurch der Inhalt blockiert und durch eine alternative Nachricht ersetzt wird, oder NONE, wodurch nichts unternommen wird, außer dass die Erkennungen in den Trace-Antworten protokolliert werden – im Grunde ein reiner Erkennungsmodus.

Eine sinnvolle Standardstrategie:

• Verwenden Sie für Hochrisikokategorien wie Hass, Gewalt und Fehlverhalten sowohl bei der Eingabe als auch bei der Ausgabe zunächst MEDIUM;
• Im Test- oder Staging-Betrieb sollten Sie mit outputAction = „NONE“ beginnen, damit falsch-positive Ergebnisse erfasst werden können;
• Wechseln Sie erst auf BLOCK, wenn die Ergebnisse der Tests und Spuren als akzeptabel erscheinen;
• Lassen Sie Niedrigrisikokategorien bei LOW oder MEDIUM, und setzen Sie nicht alles bereits am ersten Tag auf HIGH.

Inhaltsfilter sind außerdem in zwei Schutzniveaus unterteilt. CLASSIC stellt das Basistierungsfiltern dar, während STANDARD durch Analyse des Code-Bereichs sowie Unterstützung für Prompt-Angriffe einen stärkeren Schutz bietet. Ein Assistent, der Anfragen im Entwicklerstil, Codeausschnitte oder gemischten Text und Code verarbeitet, ist in der Regel bei Standard sicherer.

Versionierung

Die Veröffentlichungen von Guardrail-Regeln sollten eindeutig und unveränderlich sein, und jede Richtlinienänderung sollte zu einer neuen Version führen. aws_bedrock_guardrail_version unterstützt dies: Erstellen Sie eine Version und verknüpfen Sie sie mit aws_bedrock_guardrail über guardrail_configuration.

resource "aws_bedrock_guardrail" "guardrail" {
  name = "${var.environment}-news-guardrail"
  description = "Safety policies for news assistant"
  blocked_input_messaging = "Your request violates our usage policy."
  blocked_outputs_messaging = "This response was blocked by our safety policy."
  content_policy_config {
    filters_config {
      type = "HATE"
      input_strength = "MEDIUM"
      output_strength = "MEDIUM"
    }
    filters_config {
      type = "VIOLENCE"
      input_strength = "MEDIUM"
      output_strength = "MEDIUM"
    }
    filters_config {
      type = "MISCONDUCT"
      input_strength = "MEDIUM"
      output_strength = "MEDIUM"
    }
  }
}

resource "aws_bedrock_guardrail_version" "guardrail_version" {
  guardrail_arn = aws_bedrock_guardrail.guardrail.guardrail_arn
  description = "release-${substr(sha256(var.guardrail_policy_fingerprint), 0, 12)}"
  skip_destroy = true
}

resource "aws_bedrockagent_agent" "news_agent" {
  # ... instruction, model, prompt overrides ...
  guardrail_configuration {
    guardrail_identifier = aws_bedrock_guardrail.guardrail.guardrail_id
    guardrail_version = aws_bedrock_guardrail_version.guardrail_version.version
  }
  # ... existing code below ...
}

Die Trennung ermöglicht einen sauberen Rollback. Die Anfragen bleiben unverändert, und nur die Version mit Schutzmaßnahmen ändert sich, wenn eine Anpassung der Richtlinien erforderlich ist.

Wissensdatenbank für interne Inhalte

Nehmen wir an, der Agent soll aus Unternehmensrichtlinien oder im Laufe der Zeit gesammeltem Wissen antworten und unnötige Toolaufrufe vermeiden. Bedrock verwendet eine angehängte Wissensdatenbank, um Antworten aus abgerufenen Dokumenten zu generieren, und diese ist standardmäßig aktiv, sobald eine konfiguriert wurde. Sie ermöglicht es den Agenten, sich sicher auf private Unternehmensdaten zuzugreifen, sodass die Grundmodellien durch Retrieval Augmented Generation (RAG) relevantere, genaue und individuell angepasste Antworten liefern können.

Sie eignet sich, wenn die Quelle der Wahrheit interne oder sorgfältig kuratierte Dokumentation ist, wenn keine Echtzeitaktualität auf Minutebene erforderlich ist oder wenn fundierte Antworten mit zitierähnlicher Nachvollziehbarkeit benötigt werden.

Hinweis: Für Echtzeit-Informationen, die extern indiziert sind, eignen sich API-Tools besser.

Die Bedrock Knowledge Base fungiert als verwalteter RAG-Pipeline für Ihr eigenes Content. Anstatt selbst eine Suchinfrastruktur aufzubauen, überlassen Sie Bedrock die Aufnahme von Daten über einen Connector, die Analyse und Aufteilung der Dokumente in Blöcke, die Erstellung von Embeddings, die Speicherung der Vektoren in einem unterstützten Speicher sowie das Abrufen der relevanten Blöcke bei einem Anfrageneingang. Während des KNOWLEDGE_BASE_RESPONSE_GENERATION-Prozesses liefern diese Blöcke die Grundlage für fundierte Antworten.

Zwei Abläufe sind beteiligt. Die Einpflege findet offline oder im Synchronisierungsmodus statt: Die Dokumente werden analysiert, gemäß der Chunking-Strategie in Blöcke aufgeteilt, mithilfe eines Embedding-Modells in Vektoren umgewandelt und zusammen mit Metadaten-Mapping-Informationen in einen Vektorindex geschrieben. Die Abfrage während der Ausführung erfolgt pro Anfrage: Die Anfrage wird in Vektoren umgewandelt, der Vektor-Speicher liefert semantisch relevante Blöcke, Bedrock fügt diese dem Kontext des Modells hinzu, und in der Generierungsphase wird ein fundiertes Ergebnis erzeugt – bei reinen Abfragemustern werden lediglich die Ergebnisse zurückgegeben.

Die Aufteilung in Blöcke hat praktische Bedeutung, denn eine schlechte Abfragequalität liegt oft an Problemen bei der Einpflege oder beim Chunking und nicht am Prompt selbst.

Nichts wird „als Zeile eingefügt“, wie es in einem SQL-Cache der Fall ist. Man fügt Dateien oder Quellen, die über Connector unterstützt werden, hinzu oder aktualisiert diese und führt anschließend Synchronisierung durch.

Achtung: Die Synchronisierung erfolgt nicht automatisch. Nach dem Hinzufügen von Dokumenten zu S3 muss sie explizit ausgelöst werden, bevor der Agent sie abrufen kann.

Laufzeitsteuerung

• numberOfResults legt fest, wie viele Quellblöcke zurückgegeben werden (Standard bis zu 5, Bereich von 1 bis 100).
• overrideSearchType wählt SEMANTIC für eine Suche ausschließlich mit Vektoren oder HYBRID für eine Suche mit Vektoren sowie Rohtexten; dies ist nur auf kompatiblen Speichern und Indizes möglich. Wenn dieser Wert nicht gesetzt wird, entscheidet Bedrock selbst.
• Metadaten-Filter sowie logische Gruppen (andAll, orAll) ermöglichen eine präzise Abfrage.
• Eine optionale Neubewertung verbessert die endgültige Reihenfolge der Blöcke.

Durch hierarchisches Aufteilen in Blöcke kann die Anzahl der Ergebnisse geringer sein als gewünscht, da Untergebene Blöcke zum Zeitpunkt der Antwort durch ihre übergeordneten Blöcke ersetzt werden können.

Chunking

Das Chunking hat einen starken Einfluss auf die Qualität der Abrufung. Bedrock bietet ein standardmäßiges Chunking von etwa 300 Tokens entlang der Satzgrenzen, ein festgrößiges Chunking mit expliziter Tokengröße und Überlappung, hierarchische Eltern- und Kind-Chunks für höhere Präzision sowie einen breiteren Kontext, semantisches Chunking mit modellgesteuerten Grenzen sowie das Ausbleiben jeglichen Chunkings, wodurch jedes Dokument als ein einziger Chunk behandelt wird und dies hauptsächlich für vorsegmentiertes Inhalte geeignet ist.

Ein sinnvoller Ansatz: Beginnen Sie mit dem standardmäßigen oder festen Chunking, da es einfach ist. Wechseln Sie auf das hierarchische Chunking, sobald mehr umliegender Kontext benötigt wird, und auf das semantische Chunking, falls die Präzision nach Anpassungen des Prompts weiterhin schlecht bleibt. Vergleichen Sie vor und nach jeder Änderung mit einem Evaluationsset für die Abruffunktion.

Vektordatenspeicher

Wissensbasen arbeiten mit verschiedenen Vektor-Backend-Lösungen, wie OpenSearch Serverless oder einem verwalteten Cluster, Aurora PostgreSQL-kompatibel, Pinecone, Redis Enterprise Cloud, MongoDB Atlas und Neptune Analytics – je nachdem, welche Unterstützung der Anbieter zum Zeitpunkt der Bereitstellung bietet. Die Wahl beeinflusst, ob eine HYBRID-Suche möglich ist, welche Metadatenfilter verfügbar sind sowie die Betriebskomplexität und Kosten. OpenSearch Serverless ist in der Regel der schnellste Weg zum Start. Ein Beispiel für die Konfiguration mit Terraform folgt:

resource "aws_bedrockagent_knowledge_base" "news_kb" {
  name = "${var.environment}-news-kb"
  role_arn = aws_iam_role.bedrock_execution_role.arn
  knowledge_base_configuration {
    type = "VECTOR"
    vector_knowledge_base_configuration {
      embedding_model_arn = "arn:aws:bedrock:${data.aws_region.current.name}::foundation-model/amazon.titan-embed-text-v2:0"
    }
  }
  storage_configuration {
    type = "OPENSEARCH_SERVERLESS"
    opensearch_serverless_configuration {
      collection_arn = aws_opensearchserverless_collection.kb.arn
      vector_index_name = "news-kb-index"
      field_mapping {
        vector_field = "vector"
        text_field = "text"
        metadata_field = "metadata"
      }
    }
  }
  # ... existing code below ...
}

resource "aws_bedrockagent_data_source" "news_docs" {
  knowledge_base_id = aws_bedrockagent_knowledge_base.news_kb.id
  name = "${var.environment}-news-docs"
  data_source_configuration {
    type = "S3"
    s3_configuration {
     bucket_arn = aws_s3_bucket.news_docs.arn
    }
  }
  # ... existing code below ...
}

resource "aws_bedrockagent_agent_knowledge_base_association" "news_agent_kb" {
  agent_id = aws_bedrockagent_agent.agent[0].agent_id
  agent_version = "DRAFT"
  knowledge_base_id = aws_bedrockagent_knowledge_base.news_kb.id
  description = "Internal news assistant knowledge base for curated context and editorial guidelines"
  knowledge_base_state = "ENABLED"
  # ... existing code below ...
}

Routing zwischen der Wissensdatenbank und den Tools

Durch die Verwendung einer Wissensdatenbank erhält der Agent einen zweiten Abrufweg. Um Unklarheiten zu vermeiden, sollten die Routing-Regeln für Wissensdatenbank versus API-Tool in der Orchestrierungsanweisung festgelegt werden, das POST_PROCESSING-Konzept unabhängig davon identisch bleiben, welche Quelle geantwortet hat, und angegeben werden, wann der Agent klärende Fragen stellen soll, da das Vertrauen in die Abrufergebnisse gering ist.

Eine praktische Vorgehensweise für diese Konfiguration: Nutzen Sie die Wissensdatenbank für interne, statische Kontexte wie Richtliniedokumente, redaktionelle Standards und historische Notizen; verwenden Sie die Aktionengruppe für aktuelle externe Daten; und rufen Sie nicht beide in derselben Aktion auf, es sei denn, die Anfrage erfordert tatsächlich eine Überprüfung.

Sicherheitsmaßnahmen gelten auch bei Lese- und Erstellungsoperationen, was wichtig ist, denn eine auf Fakten basierende Suche beseitigt nicht automatisch die Sicherheitsrisiken. Eine gängige Empfehlung ist es, zunächst den Wissensspeicherpfad im Erkennungsmodus mit Sicherheitsmaßnahmen zu prüfen, die Fehlalarme und -fehler anhand der Protokolle anzupassen und anschließend im Produktivbetrieb auf Blockieren oder Maskieren umzustellen.

Inhalt einholen

• Ursprüngliches Korpus: Für einen einmaligen Ladevorgang von Richtlinien, FAQs und Stilrichtlinien sollten die Dateien in den mit der Datenquelle verbundenen S3-Container hochgeladen und eine Synchronisierung gestartet werden.
• Fortlaufende Aktualisierungen: Wenn Produkt- oder Rechtstexte zu festgelegten Zeiten geändert werden, kann eine nächtliche Aufgabe neue Dateien in S3 hochladen und StartIngestionJob für die Datenquelle auslösen, oder man kann sich auf eine automatische Synchronisierung verlassen, sofern diese aktiviert ist.

Viele kleine Dokumente: Speichern Sie ein Thema pro Datei, wie zum Beispiel kb/topics/eu-ai-act-overview.md, sodass die Grenzen der Blöcke den Themen entsprechen und die Zitate klarer sind als bei einem einzigen großen PDF.

Verbindungen: SharePoint, Confluence, Web-Crawlers und ähnliche Tools eignen sich für bereits dort vorhandenen Inhalt. Bedrock zieht und synchronisiert den Inhalt nach einem festgelegten Zeitplan, wobei die genauen Optionen je nach Verbindertyp und Region variieren.

Programmgesteuerte Pipelines: Wenn ein CMS oder Ticketsystem HTML oder JSON exportiert, kann eine Lambda-Funktion diesen Inhalt in reinen Text oder Markdown umwandeln, ihn in S3 schreiben und StartIngestionJob aufrufen, damit die Wissensdatenbank die neuen Objekte aufnimmt.

Herausforderungen

• Die Wissensdatenbank als Echtzeit-Quelle zu betrachten. Sie ist nur so aktuell wie der Synchronisierungszeitplan.
• Zu viele oder zu wenige Blöcke zu erstellen, was die Genauigkeit beeinträchtigt.
• Mangelhafte Metadaten, die die Filter nutzlos machen.
• Die Zusammenfassung der Abruf- und Formatierungsaufgaben in derselben Prompt-Ebene.
• Die Annahme, dass das Umformulieren von Prompts einen schwachen Abrufindex retten kann.

Was daraus resultiert

Zusammenfassungen funktionieren am besten, wenn sie auf den jeweiligen Bereich abgestimmt sind und nicht als allgemeiner Überblickstext verwendet werden. Prompts und Sicherheitsregeln arbeiten auf unterschiedlichen Ebenen, daher sollten sie getrennt versioniert werden. Eine Wissensdatenbank ist nur eine der Möglichkeiten zum Abrufen von Informationen und ersetzt keine Echtzeit-APIs – daher sollten Prompts klar angeben, wann ein Tool aktuelle Informationen liefert und wann die Wissensdatenbank kuratierten Kontext bereitstellt.

Zusammen bilden diese Komponenten den internen Ablauf des Agenten: ein MEMORY_SUMMARIZATION-Prompt, der lange Gespräche in wiederverwendbare Zusammenfassungen kürzt, ein Bedrock Guardrail, der schädliche Inhaltskategorien blockiert, sowie eine Wissensdatenbank auf einer S3-Datengrundlage für retrieval-augmented Generation.