Agents Bedrock : résumé de la mémoire, règles versionnées et base de connaissances.

Faillites silencieuses

De nombreux problèmes peuvent survenir dans un système d’agents IA, et les pires défaillances ne génèrent aucun erreur ni alerte. La qualité se détériore simplement progressivement. La mémoire de session accumule du bruit au lieu de signaux utiles, les règles de sécurité se trouvent en dehors du système de contrôle de version, et l’agent fait appel à des outils pour obtenir du contenu que une base de connaissances pourrait fournir directement.

Amazon Bedrock propose trois solutions pour résoudre ces problèmes : une surcharge de MEMORY_SUMMARIZATION qui conserve les signaux utiles des utilisateurs au fil des sessions, une fonction Bedrock Guardrail versionnée via Terraform, ainsi qu’une base de connaissances optionnelle hébergée sur S3.

L’ingénierie des prompts ne peut pas assumer toute la charge. Les systèmes réels nécessitent des mécanismes de contrôle en trois endroits :

1. Qualité de la mémoire de session. Les résumés doivent conserver les signaux pertinents des utilisateurs.
2. Gouvernance de la sécurité. Les règles de protection doivent être explicites et versionnées.

Limite de récupération. L’agent a besoin d’une règle claire indiquant quand utiliser les outils, la base de connaissances ou les deux.

Sans elles, un système semble stable lors des démonstrations mais se dégrade dès qu’un trafic réel et varié arrive.

Fonctionnement de la mémoire de session

La synthèse de la mémoire permet de conserver l’historique d’un utilisateur d’une session à l’autre, ce qui évite de devoir extraire et retraiter manuellement les anciennes messages en temps réel. Dans les agents Classic, Bedrock offre une forme de base via enabled_memory_types = ["SESSION_SUMMARY"] sur aws_bedrockagent_agent, et GetAgentMemory dans l’Agent Runtime lit ce qui a été stocké.

Lorsque la mémoire est activée, le traitement s’effectue de manière asynchrone après la fermeture d’une session. Bedrock résume la conversation terminée, en stocke le résumé et l’injecte dans les sessions ultérieures qui partagent le même memoryId, tout cela sans retarder la réponse de l’utilisateur.

Bedrock fournit un prompt par défaut qui définit le comportement du résumé :

{
  "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>"
        }
    ]
}

Ses instructions se trouvent principalement dans la section <guidelines/>, qui indique à l’agent de retourner son résultat à l’intérieur d’une balise <summary/>. Le résumé est divisé par thème. Tout ce qui concerne les objectifs de l’utilisateur se trouve sous le thème intitulé user goals, les actions de l’agent lui-même sous assistant actions, et chaque thème utilise un enveloppement <topic name='$TOPIC_NAME'></topic>. La sortie attendue ressemble à ceci :

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

Bedrock remplit <previous_summaries/> avec les résumés antérieurs via la variable $past_conversation_summary$, et la conversation en temps réel apparaît à l’intérieur de <conversation>$conversationlt;/conversation>. Deux autres sections, <additional_guidelines/> et <special_guidelines/>, vous permettent d’ajouter des détails à la stratégie de résumé.

Le cycle de vie se déroule comme suit :

1. La mémoire est activée dans la configuration de l’agent avec memory_configuration et enabled_memory_types = ["SESSION_SUMMARY"].
2. L’utilisateur invoque l’agent en fournissant un memoryId unique pour chaque utilisateur.
3. La session se termine soit par l’instruction endSession = true, soit en raison d’une expiration.
4. Bedrock génère le résumé en arrière-plan.

Lors des sessions ultérieures avec le même memoryId, Bedrock place le contexte de la mémoire dans des placeholders d’orchestration tels que $memory_content$.

Deux conséquences en découlent. Les résumés ne sont pas instantanés et peuvent apparaître quelque temps après la fermeture d’une session. De plus, si le memoryId change d’une requête à l’autre, la continuité disparaît.

Avertissement : Des valeurs instables de memoryId, comme les identifiants de connexion auxquels appartiennent les identifiants d’utilisateur, perturbent la continuité de la mémoire. Utilisez un identifiant qui reste fixe pour chaque utilisateur ou entité de conversation.

Rendre les résumés utiles

Le résumé par défaut est un aperçu générique. Cela convient bien à un assistant généraliste, mais est souvent trop bruyant pour un assistant spécialisé. Pour un petit assistant de nouvelles, un bon résumé doit retenir :

• des sujets récurrents tels que les nouvelles sur l’IA, le climat ou la géopolitique ;

régions et entités préférées ;

articles que l’utilisateur suit entre les sessions ;

rejets explicites, tels que « ne pas inclure les cryptomonnaies ».

Sans cette structure, la mémoire s’accroît tandis que la pertinence diminue.

Activer cette fonctionnalité commence par la ressource agent dans 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 ...
}

Les agents Bedrock n’acceptent ici que le type SESSION_SUMMARY. AgentCore va plus loin, en prenant en compte des résumés, les préférences de l’utilisateur, des faits sémantiques ainsi que des stratégies de mémoire personnalisées. storage_days définit la durée pendant laquelle les résumés sont conservés, tandis que max_recent_sessions contrôle le nombre de sessions récentes qui seront résumées.

Chaque appel doit inclure un memoryId, ici le user_id, afin que les conversations soient liées à la même entité :

# 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
)

La récupération utilise le même 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"
)

Défaut du prompt de synthèse

Avec la mémoire activée, Bedrock permet à un prompt de remplacement de remplacer l’étape MEMORY_SUMMARIZATION : on passe de prompt_type = "MEMORY_SUMMARIZATION" à prompt_creation_mode = "OVERRIDDEN". Les agents classiques utilisent deux placeholders dédiés : $past_conversation_summary$ pour les résumés stockés liés à la même identité mémoire, et $conversation$ pour le texte de la session en cours. Dans les modèles d’orchestration, le contexte mémoire est transmis via $memory_guideline$ pour la stratégie, $memory_content$ pour la persistance et $memory_action_guideline$ pour les prompts système.

Une version personnalisée du prompt par défaut précise ce que l’agent doit capturer et ce qu’il doit ignorer, de sorte que seuls les détails utiles restent :

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 ...
}
]
}

Surmonter cette étape lorsque un résumé générique ne permet pas d’améliorer les réponses ultérieures, lorsque des synthèses nécessitent un rapport signal/bruit élevé, ou lorsque le budget de tokens mémoire doit rester limité et prévisible. Si l’assistant est générique et ne repose pas sur la personnalisation, la valeur par défaut convient.

Les erreurs typiques incluent :

• des valeurs instables de memoryId, comme l’utilisation d’identifiants de connexion à la place des identifiants d’utilisateur ;
• des sessions qui ne se terminent jamais, ce qui empêche toute génération de synthèse ;
• des demandes de synthèse trop détaillées qui reconstituent pratiquement l’intégralité du texte ;
• le mélange d’objectifs de synthèse avec des objectifs de mise en forme destinés au traitement ultérieur.

Règles de sécurité : politiques que les prompts ne peuvent pas imposer

Les utilisateurs sont parfois impolis, utilisent mal l’agent ou demandent des détails internes, des secrets ainsi que des données personnelles d’autres personnes. Les mécanismes de contrôle s’occupent de cela. Le principe est simple : les prompts guident le comportement, tandis que les mécanismes de contrôle appliquent les politiques. Utilisez les prompts pour prendre des décisions et gérer le formatage, et les mécanismes de contrôle pour respecter les limites de sécurité du contenu, tant pour les entrées des utilisateurs que pour les sorties de l’assistant.

Conseil : Essayez d’abord les mécanismes de contrôle en mode DETECT avant de passer en mode BLOCK. Vérifier ce qui aurait été bloqué ne affecte pas les testeurs.

Bedrock intègre plusieurs fonctionnalités de contrôle qui ne nécessitent aucune configuration supplémentaire, il suffit de les ajouter à la liste :

• Filtres de contenu : ils permettent de gérer la haine, les insultes, la violence, le contenu sexuel, les comportements inappropriés ainsi que les attaques via des prompts, avec des paramètres et des actions adaptés aux entrées et aux sorties. Ils assurent une sécurité de base permanente pour le trafic normal des utilisateurs.

Sujets interdits : bloquent les domaines non autorisés, utiles pour définir des limites liées aux produits ou à la réglementation, comme par exemple « ne jamais aborder ce domaine ».

Filtres de mots : prennent en compte des termes bloqués gérés ou personnalisés, pratiques pour les termes spécifiques à l’entreprise, les jurons ou les mots strictement interdits.

Filtres d’informations sensibles : identifient les entités de données personnelles et des expressions régulières personnalisées, assurant ainsi un contrôle de la confidentialité pour les identifiants de compte, les adresses e-mail et les numéros de téléphone.

Vérifications basées sur le contexte : appliquent des politiques de réponses fondées sur le contexte dans les flux de récupération d’informations, ce qui est essentiel dans les configurations RAG et de bases de connaissances où le contrôle des hallucinations est crucial.

Attaques par prompts : font partie des filtres de contenu en tant que catégorie (bypass, injections, fuites de prompts) au niveau Standard.

Vérifications par raisonnement automatisé qui valident la cohérence avec les règles de politique, afin d’assurer une logique stricte dans les réponses réglementées.

La plupart des équipes obtiennent de meilleurs résultats en mettant en œuvre ces fonctionnalités par étapes : d’abord les filtres de contenu et d’informations sensibles, puis ceux liés aux sujets et aux mots, enfin le raisonnement une fois que les politiques de récupération sont matures.

Ordre d’évaluation

Les mécanismes de contrôle examinent les deux directions :

1. Entrée. La demande de l’utilisateur est évaluée en premier, avec toutes les politiques configurées fonctionnant en parallèle. Un bloc pousse Bedrock à retourner votre blocked_input_messaging et à ignorer l’inférence.
2. Sortie. Lorsque l’entrée est validée, le modèle répond et sa sortie est vérifiée. Un bloc remplace la réponse par blocked_outputs_messaging, ou masque celle-ci lorsque des filtres sensibles sont activés.

Si les deux tests réussissent, la sortie est renvoyée telle quelle.

L’ordre a de l’importance en termes de coût. Une entrée bloquée ne coûte que l’évaluation des mécanismes de protection et non l’inférence du modèle.

Chaque filtre de contenu dispose de deux paramètres indépendants. Intensité (inputStrength et outputStrength) peut prendre les valeurs NONE, LOW, MEDIUM ou HIGH et détermine la rigueur avec laquelle les violations sont détectées. Action (inputAction et outputAction) peut être BLOCK, ce qui bloque le contenu et remplace celui-ci par un message indiquant le blocage, ou NONE, ce qui ne fait rien d’autre que d’enregistrer les détections dans les réponses de suivi, ce qui correspond en fait à un mode de simple détection.

Une stratégie par défaut judicieuse :

• Commencez par MEDIUM pour les catégories à haut risque telles que la haine, la violence et les comportements inappropriés, tant pour l’entrée que pour la sortie ;
• Lors des tests ou en phase de préparation, commencez avec outputAction = "NONE" afin de pouvoir compter les faux positifs ;
• Passez à BLOCK uniquement après que les résultats des traces et du jeu de test semblent acceptables ;
• Laissez les catégories à faible risque à LOW ou MEDIUM, et ne mettez pas tout en HIGH dès le premier jour.

Les filtres de contenu existent également en deux niveaux de protection. Le CLASSIC représente le filtrage de base, tandis que le STANDARD offre une protection plus forte grâce à l’analyse du domaine de code et au soutien pour les catégories d’attaques par prompt. Un assistant qui gère des prompts, des extraits ou du texte et du code mélangés dans le style d’un développeur est généralement plus sûr en mode Standard.

Gestion des versions

Les mises à jour des règles de protection doivent être explicites et immuables, et chaque modification de politique doit donner naissance à une nouvelle version. aws_bedrock_guardrail_version permet cela : il suffit de créer une version et de la lier à aws_bedrock_guardrail via 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 ...
}

Cette séparation permet un retrait propre. Les messages d’invite restent tels quels, et seule la version de protection se met à jour lorsque des ajustements de politique sont nécessaires.

Base de connaissances pour le contenu interne

Supposons que l’agent doive répondre en s’appuyant sur les politiques de l’entreprise ou les connaissances accumulées au fil du temps, tout en évitant des appels inutiles à des outils. Bedrock utilise une base de connaissances associée pour générer des réponses à partir de documents récupérés, et elle est activée par défaut dès qu’une telle base a été configurée. Elle permet aux agents de se connecter en toute sécurité aux données privées de l’entreprise, afin que les modèles de base fournissent des réponses plus pertinentes, précises et personnalisées grâce à la génération augmentée par récupération d’informations (RAG).

Cette solution convient lorsque la source de vérité est constituée de documents internes ou curatés, lorsqu’une fraîcheur au niveau minute n’est pas requise, ou lorsque des réponses fondées sur des références vérifiables sont nécessaires.

Remarque : Les outils API sont plus adaptés pour gérer les informations indexées en temps réel à l’extérieur.

Bedrock Knowledge Base fonctionne comme un pipeline RAG géré pour vos propres contenus. Au lieu de construire vous-même l’infrastructure de récupération, vous laissez Bedrock recevoir les données depuis un connecteur, parser et diviser les documents en blocs, créer des embeddings, stocker les vecteurs dans un entrepôt pris en charge et récupérer les blocs pertinents lorsqu’une demande arrive. Pendant KNOWLEDGE_BASE_RESPONSE_GENERATION, ces blocs alimentent les réponses basées sur des données concrètes.

Deux flux sont impliqués. L’ingestion s’exécute hors ligne ou en mode synchronisation : les documents sont analysés, divisés en blocs selon la stratégie de segmentation, convertis en vecteurs par un modèle d’incorporation et enregistrés dans un index vectoriel accompagné de mappages de métadonnées. La récupération en temps réel a lieu pour chaque requête : la requête est incorporée, le stockage vectoriel renvoie des blocs sémantiquement pertinents, Bedrock les ajoute au contexte du modèle, et l’étape de génération produit un résultat fondé sur ces données, ou simplement des résultats de récupération dans les modes exclusivement de recherche.

Cette segmentation a une signification opérationnelle, car une mauvaise qualité de récupération est souvent due à un problème d’ingestion ou de segmentation, et non à un problème lié à la requête.

Rien n’est « inséré en tant que ligne » comme dans un cache SQL. Vous ajoutez ou mettez à jour des fichiers, ou des sources gérées par des connecteurs, puis vous exécutez le mode synchronisation.

Avertissement : La synchronisation n’est pas automatique. Après avoir ajouté des documents à S3, il faut la déclencher explicitement avant que l’agent ne puisse les récupérer.

Contrôles en temps de exécution

• numberOfResults définit le nombre de fragments sources qui seront retournés (par défaut jusqu’à 5, plage de 1 à 100).
• overrideSearchType permet de choisir SEMANTIC pour une recherche uniquement vectorielle ou HYBRID pour une recherche vectorielle combinée à une recherche sur du texte brut, ce qui n’est supporté que sur des stores et indices compatibles. Si cette valeur n’est pas définie, Bedrock fait le choix.
• Le filter des métadonnées ainsi que les groupes logiques (andAll, orAll) permettent une récupération précise.
• Un réclassement optionnel améliore l’ordre final des fragments.

Avec le fractionnement hiérarchique, le nombre de résultats peut être inférieur à celui demandé, car les fragments enfants peuvent être remplacés par leurs parents au moment de la réponse.

Chunking

Le chunking a un impact significatif sur la qualité de la récupération. Bedrock propose un chunking par défaut d’environ 300 tokens le long des limites des phrases, un chunking de taille fixe avec une taille et un chevauchement de tokens définis explicitement, des chunks hiérarchiques parents et enfants pour plus de précision ainsi que pour un contexte plus large, un chunking sémantique avec des limites déterminées par le modèle, et pas de chunking du tout, qui traite chaque document comme un seul chunk et convient principalement aux contenus déjà segmentés.

Une approche raisonnable : commencer par le chunking par défaut ou de taille fixe, car il est simple. Passer au chunking hiérarchique lorsque des réponses nécessitent un contexte plus étendu, et au chunking sémantique si la précision reste faible après l’ajustement du prompt. Comparer les résultats avec un ensemble d’évaluation de récupération avant et après chaque modification.

Stockages vectoriels

Les bases de connaissances fonctionnent avec plusieurs backends vectoriels, tels que OpenSearch Serverless ou un cluster géré, Aurora compatible avec PostgreSQL, Pinecone, Redis Enterprise Cloud, MongoDB Atlas et Neptune Analytics, en fonction du support offert par le fournisseur au moment du déploiement. Le choix influencie la présence d’une recherche HYBRIDE, les filtres de métadonnées possibles, ainsi que la complexité opérationnelle et les coûts. OpenSearch Serverless est généralement le moyen le plus rapide pour commencer. Voici un exemple d’configuration avec Terraform :

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 ...
}

Acheminement entre la base de connaissances et les outils

L’association d’une base de connaissances offre à l’agent une deuxième voie de récupération. Afin d’éviter toute ambiguïté, indiquez les règles d’acheminement pour la base de connaissances par rapport à l’outil API dans la commande d’orchestration, conservez le contrat POST_PROCESSING identique quel que soit l’origine de la réponse, et précisez quand l’agent doit poser des questions pour obtenir plus de détails en cas de faible niveau de confiance dans la récupération.

Une politique pratique pour cette configuration : utilisez la base de connaissances pour des contextes internes et statiques tels que les documents de politique, les normes éditoriales et les notes historiques ; utilisez le groupe d’actions pour des données externes en temps réel ; et n’appeliez pas les deux en même temps sauf si la demande nécessite réellement une vérification croisée.

Les mécanismes de contrôle s’appliquent également aux opérations de récupération et de génération, ce qui est important car la récupération fondée sur des données concrètes ne supprime pas à elle seule les risques de sécurité. Une recommandation courante consiste d’abord à évaluer le parcours de la base de connaissances avec ces mécanismes de contrôle en mode détection, à ajuster les faux positifs et négatifs à partir des traces générées, puis à passer à la blocage ou au masquage en environnement de production.

Récupération du contenu

• Corpus initial : pour un chargement unique des politiques, FAQ et guides de style, téléchargez les fichiers dans le bucket S3 connecté à la source de données et lancez une synchronisation.
• Mises à jour continues : lorsque le texte produit ou juridique change selon un calendrier prédéfini, une tâche nocturne peut télécharger de nouveaux fichiers dans S3 et déclencher StartIngestionJob pour la source de données, ou bien compter sur une synchronisation automatique si elle est activée.

De nombreux petits documents : stockez un sujet par fichier, comme kb/topics/eu-ai-act-overview.md, afin que les limites des blocs correspondent aux sujets et que les citations soient plus claires qu’avec un seul PDF géant.

Connexions : SharePoint, Confluence, les robots de recherche et autres outils s’intègrent aux contenus déjà présents. Bedrock effectue des récupérations et des synchronisations selon un calendrier prédéfini, et les options exactes varient en fonction du type de connexion et de la région.

Pipelines programmatisés : lorsque un CMS ou un système de tickets exporte du HTML ou du JSON, une fonction Lambda peut le convertir en texte brut ou en markdown, l’enregistrer dans S3 et appeler StartIngestionJob pour que la base de connaissances prenne en charge les nouveaux objets.

Péripéties

• Considérer la base de connaissances comme une source en temps réel. Elle n’est aussi à jour que selon le calendrier de synchronisation des données.
• Blocquer trop ou trop peu de contenu, ce qui nuit à la précision.
• Métadonnées négligées, ce qui rend les filtres inutiles.
• Fusion des tâches de récupération et de formatage au même stade de la requête.
• Croyance que la reformulation des requêtes peut sauver un index de récupération faible.

Conséquences globales

Les résumés fonctionnent le mieux lorsqu’ils sont adaptés au domaine concerné et non laissés en tant que textes de synthèse génériques. Les requêtes et les contraintes opèrent à des niveaux différents, il convient donc de les gérer séparément. Une base de connaissances représente un seul mode de récupération et ne remplace pas les API en temps réel ; par conséquent, les requêtes doivent indiquer clairement quand un outil fournit des informations à jour et quand la base de connaissances propose du contexte soigneusement sélectionné.

Ces éléments ensemble complètent le pipeline interne de l’agent : une instruction MEMORY_SUMMARIZATION qui condense les longues conversations en résumés réutilisables, une fonction Bedrock Guardrail qui bloque les catégories de contenu nocifs, ainsi qu’une base de connaissances basée sur une source de données S3 pour une génération améliorée par la récupération d’informations.