Bedrock Agents: Streszczanie pamięci, wersjonowane zasady bezpieczeństwa oraz baza wiedzy.

Błędy, które nie wydają żadnego dźwięku

W systemie agentów AI może zdarzyć się wiele błędów, a najgorsze z nich nie powodują żadnych błędów ani nie uruchamiają alertów. Jakość systemu po prostu się pogarsza. Pamięć sesji gromadzi szum zamiast sygnałów, zasady bezpieczeństwa znajdują się gdzieś poza systemem kontroli wersji, a agent korzysta z narzędzi do przetwarzania treści, które mogłaby bezpośrednio dostarczyć baza wiedzy.

W Amazon Bedrock istnieją trzy rozwiązania na te problemy: modyfikacja MEMORY_SUMMARIZATION, która przechowuje istotne sygnały użytkownika pomiędzy sesjami, Bedrock Guardrail wersjonowany za pomocą Terraform oraz opcjonalna baza wiedzy oparta na S3.

Inżynieria promptów nie może sama udźwignąć całego ciężaru. Prawdziwe systemy wymagają kontroli w trzech obszarach:

1. Jakość pamięci sesji. Streszczenia muszą zachowywać właściwe sygnały użytkownika.
2. Kierownictwo bezpieczeństwa. Zasady bezpieczeństwa powinny być jasne i mieć wersje.

Granica pobierania danych. Agent potrzebuje jasnej zasady określającej, kiedy używa narzędzi, bazy wiedzy lub obu.

Bez nich system wydaje się stabilny w demonstracjach, ale jego funkcjonowanie pogarsza się po pojawieniu się rzeczywistego, zróżnicowanego ruchu.

Jak działa pamięć sesji

Podsumowanie pamięci umożliwia dostęp do historii użytkownika z jednej sesji do drugiej, dzięki czemu stare wiadomości nie muszą być ponownie wydobywane i przetwarzane w czasie rzeczywistym. W Classic Agents Bedrock oferuje podstawową formę poprzez enabled_memory_types = ["SESSION_SUMMARY"] w obiekcie aws_bedrockagent_agent, a funkcja GetAgentMemory w Agent Runtime odczytuje przechowywane dane.

Gdy pamięć jest włączona, praca odbywa się asynchronicznie po zamknięciu sesji. Bedrock podsumowuje zakończoną rozmowę, przechowuje to podsumowanie i włącza je do późniejszych sesji, które dzielą ten sam memoryId, przy czym to nie opóźnia odpowiedzi użytkownika.

Bedrock dostarcza domyślną instrukcję, która określa zachowanie funkcji podsumowywania:

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

Jego instrukcje znajdują się głównie w sekcji <guidelines/>, która nakazuje agencie zwrócić swój wynik wewnątrz tagu <summary/>. Streszczenie jest podzielone według tematów. Wszystko, co dotyczy celów użytkownika, znajduje się pod tematem o nazwie user goals, natomiast działania samego agenta – pod assistant actions; każdy temat jest otoczony tagiem <topic name='$TOPIC_NAME'></topic>. Oczekiwany wynik wygląda następująco:

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

Bedrock wypełnia <previous_summaries/> wcześniejszymi podsumowaniami za pomocą zmiennej $past_conversation_summary$, a żywa rozmowa pojawia się wewnątrz <conversation>$conversationlt;/conversation>. Dwie dodatkowe sekcje, <additional_guidelines/> i <special_guidelines/>, umożliwiają dodanie szczegółów do strategii tworzenia podsumowań.

Życiowy cykl przebiega w następujący sposób:

1. Pamięć jest włączana w konfiguracji agenta za pomocą memory_configuration oraz enabled_memory_types = ["SESSION_SUMMARY"].
2. Wzywający uruchamia agenta, podając dla każdego użytkownika stały memoryId.
3. Sesja kończy się albo dzięki ustawieniu endSession = true, albo z powodu wygaśnięcia czasu.
4. Bedrock generuje podsumowanie w tle.

W późniejszych sesjach z tym samym memoryId Bedrock umieszcza kontekst pamięci w miejscach zastępczych do orkiestracji, takich jak $memory_content$

ulubione regiony i podmioty;

historia treści, których użytkownik śledzi pomiędzy sesjami;

wyraźne niepragnienia, np. „nie uwzględniaj kryptowalut.”

Bez takiej struktury pamięć rośnie, podczas gdy istotność spada.

Aby ją włączyć, należy zacząć od zasobu agenta w Terraformie:

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

Agenci Bedrock przyjmują tutaj wyłącznie typ SESSION_SUMMARY. AgentCore idzie o krok dalej, oferując podsumowania, preferencje użytkownika, fakty semantyczne oraz dostosowane strategie pamięciowe. storage_days określa, jak długo przechowywane są podsumowania, a max_recent_sessions kontroluje, ile najnowszych sesji zostanie podsumowanych.

Każde wezwanie musi zawierać memoryId, w tym przypadku user_id, aby rozmowy odnosiły się do tej samej jednostki:

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

Wymiana danych wykorzystuje ten sam 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"
)

Przejęcie sterowania promptem do streszczania

Gdy pamięć jest włączona, Bedrock umożliwia przejęcie sterowania poprzez zastąpienie etapu MEMORY_SUMMARIZATION: prompt_type = „MEMORY_SUMMARIZATION” na prompt_creation_mode = „OVERRIDDEN”. Klasyczne agenty używają do tego dwóch dedykowanych zmiennych: $past_conversation_summary$ dla przechowywanych streszczeń związanych z tą samą tożsamością pamięci oraz $conversation$ dla tekstu bieżącej sesji. W szablonach orkiestracji kontekst pamięci jest dostępny poprzez $memory_guideline$ dla strategii, $memory_content$ dla zachowania danych oraz $memory_action_guideline$ dla promptów systemowych.

Sprawdzona wersja domyślnego promptu określa dokładnie, co agent powinien uwzględnić, a co zignorować, dzięki czemu przetrwają tylko przydatne informacje:

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

Przełącz się na inny etap, gdy ogólne podsumowanie nie poprawia późniejszych odpowiedzi, gdy streszczenia wymagają wysokiego stosunku sygnału do szumu, lub gdy budżet tokenów pamięci musi pozostać ograniczony i przewidywalny. Jeśli asystent jest ogólny i nie opiera się na personalizacji, domyślna ustawienie jest w porządku.

Typowe błędy to:

• niestabilne wartości memoryId, ponownie, np. identyfikatory połączeń zamiast identyfikatorów użytkowników;
• sesje, które nigdy się nie kończą, w wyniku czego streszczenie nigdy nie jest tworzone;
• rozbudowane polecenia dotyczące streszczeń, które odtwarzają praktycznie całą transkrypcję;
• mieszanie celów streszczenia z celami formatowania przeznaczonymi do późniejszej obróbki.

Zasady bezpieczeństwa: polityka, której polecenia nie mogą narzucać

Użytkownicy czasami są nieuprzejmi, nadużywają agenta lub proszą o informacje wewnętrzne, tajemnice oraz dane osobowe innych osób. Mechanizmy ochronne zajmują się tym problemem. Zasada jest prosta: instrukcje kierują zachowaniem, a mechanizmy ochronne egzekwują zasady. Używaj instrukcji do podejmowania decyzji i formatowania, a mechanizmów ochronnych do ograniczeń bezpieczeństwa treści zarówno w przypadku wprowadzanych przez użytkowników danych, jak i wyników działania asystenta.

Wskazówka: Spróbuj najpierw użyć mechanizmów ochronnych w trybie DETECT, zanim przejdziesz do blokowania. Audyt tego, co zostałoby zablokowane, nie wpływa na osoby przeprowadzające testy.

Bedrock zawiera kilka funkcji ochronnych, które nie wymagają dodatkowej konfiguracji poza ich dodaniem do listy:

• Filtrzy treści chronią przed nienawiścią, obelgami, przemocą, treściami seksualnymi, nieprawidłowym zachowaniem oraz atakami na instrukcje, oferując zarówno mechanizmy obronne na poziomie wejścia i wyjścia, jak i konkretne działania. Są one odpowiednie do ciągłej ochrony podstawowej dla zwykłego ruchu użytkowników.

Zabronione tematy blokują zakazane obszary tematyczne, co jest przydatne do określenia granic produktowych lub regulacyjnych, na przykład „nigdy nie omawiać tego tematu”.

Filtrzy słów obejmują zarządzane oraz dostosowane terminy do blokowania, przydatne w przypadku konkretnych terminów biznesowych, wulgaryzmów lub słów wymagających ścisłego zakazu.

Filtrzy wrażliwych informacji dopasowują się do zmiennych PII oraz dostosowanych wzorów regularnych, obejmując kontrole prywatności dotyczące identyfikatorów kont, adresów e-mail i numerów telefonów.

Kontrole oparte na kontekście egzekwują zasady odpowiedzi uzasadnionych w procesach wyszukiwania, co jest istotne w konfiguracjach RAG i baz wiedzy, gdzie ważna jest kontrola halucynacji.

Ataki typu prompt należą do kategorii filtrów treści (ujemki, iniekcje, wyciek promptów) na poziomie Standard.

Zautomatyzowane sprawdzenia rozumowania weryfikują zgodność z regułami polityki, zapewniając ścisłą logikę w odpowiedziach regulowanych.

Większość zespołów najlepiej wprowadza te rozwiązania etapami: najpierw filtry treści i informacji wrażliwych, następnie filtry tematów i słów, a dopiero potem mechanizmy uzasadniania i rozumowania, gdy polityki wyszukiwania będą już rozwinięte.

Kolejność oceny

Zasady bezpieczeństwa sprawdzają obie strony:

1. Wejście. Najpierw oceniany jest prompt od użytkownika, przy czym wszystkie skonfigurowane polityki działają równolegle. Blok sprawia, że Bedrock zwraca wartość blocked_input_messaging i pomija proces inferencji.
2. Wyjście. Gdy wejście zostanie zaakceptowane, model udziela odpowiedzi, a jej wyjście jest sprawdzane. Blok zastępuje odpowiedź wartością blocked_outputs_messaging lub maskuje ją, jeśli skonfigurowane są filtry informacji wrażliwych.

Jeśli oba testy przойdą pomyślnie, wynik jest zwracany bez zmian.

Kolejność ma znaczenie dla kosztów. Zablokowany wprowadzony tekst kosztuje jedynie ocenę zabezpieczeń, a nie inferyencję modelu.

Każdy filtr treści ma dwa niezależne ustawienia. Siła (inputStrength i outputStrength) może przyjmować wartości NONE, LOW, MEDIUM lub HIGH i określa, jak skutecznie wykrywane są naruszenia. Działanie (inputAction i outputAction) może być BLOCK, co oznacza zablokowanie treści i zastąpienie jej komunikatem o blokadzie, lub NONE, co oznacza brak żadnych działań, z wyjątkiem rejestrowania wykryć w odpowiedziach typu trace – jest to w praktyce tryb wyłącznie wykrywania.

Rozsądna domyślna strategia:

• W kategoriach o wysokim ryzyku, takich jak nienawiść, przemoc i nieprawidłowe zachowanie, zacznij od ustawienia MEDIUM zarówno dla danych wejściowych, jak i wyjściowych;
• Podczas testowania lub w środowisku stagingowym użyj outputAction = „NONE”, aby móc liczyć fałszywie pozytywne wyniki;
• Przejdź na ustawienie BLOCK dopiero wtedy, gdy wyniki analizy śladów i zestawu testowego będą akceptowalne;
• Kategorie o niskim ryzyku należy pozostawić na poziomie LOW lub MEDIUM; nie ustawiaj wszystkiego na poziomie HIGH od samego początku.

Filtrzy treści dostępne są również w dwóch poziomach ochrony. CLASSIC to podstawowy filtr, natomiast STANDARD oferuje silniejszą ochronę dzięki analizie kodu oraz obsłudze kategorii ataków opartych na zapytaniach. Asystent obsługujący zapytania w stylu programistycznym, fragmenty kodu lub mieszankę tekstu i kodu jest zazwyczaj bezpieczniejszy w trybie Standard.

Wersjonowanie

Uwolnienia zabezpieczeń typu Guardrail powinny być jednoznaczne i niezmienne, a każda zmiana polityki powinna stanowić nową wersję. aws_bedrock_guardrail_version umożliwia to: tworzy się wersję i przypina ją do aws_bedrock_guardrail za pośrednictwem 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 ...
}

Taka struktura umożliwia czyste cofnięcie zmian. Powiadomienia pozostają bez zmian, a zmienia się jedynie wersja z zabezpieczeniami, gdy konieczna jest dostosowanie polityki.

Baza wiedzy dla treści wewnętrznych

Załóżmy, że agent powinien odpowiadać na podstawie polityk firmy lub wiedzy zgromadzonej z biegiem czasu, unikając niepotrzebnych wywołań narzędzi. Bedrock wykorzystuje dołączoną bazę wiedzy do generowania odpowiedzi na podstawie pobranych dokumentów; jest ona włączona domyślnie po jej konfiguracji. Umożliwia ona agentom bezpieczne połączenie z prywatnymi danymi firmy, dzięki czemu modele podstawowe mogą dostarczać bardziej trafne, dokładne i dostosowane odpowiedzi za pomocą techniki Retrieval Augmented Generation (RAG).

Metoda ta jest odpowiednia, gdy źródłem prawdy są wewnętrzne lub starannie przygotowane dokumentacje, gdy nie jest wymagana aktualność na poziomie minut, lub gdy potrzebne są odpowiedzi uzasadnione z możliwością śledzenia źródeł w sposób przypominający cytaty.

Uwaga: Informacje indeksowane zewnętrznie w czasie rzeczywistym lepiej przetwarzać za pomocą narzędzi API.

Bedrock Knowledge Base funkcjonuje jako zarządzany pipeline RAG dla Twoich własnych treści. Zamiast samodzielnie budować infrastrukturę do wyszukiwania, pozwalamy Bedrockowi pobierać dane z konektora, analizować i dzielić dokumenty na fragmenty, tworzyć embeddingi, przechowywać wektory w obsługiwanym magazynie oraz pobierać odpowiednie fragmenty po otrzymaniu żądania. Podczas KNOWLEDGE_BASE_RESPONSE_GENERATION te fragmenty służą do tworzenia spójnych odpowiedzi.

Zaangażowane są dwa procesy. Przyjmowanie danych odbywa się offline lub w trybie synchronizacji: dokumenty są analizowane, dzielone na fragmenty zgodnie ze strategią dzielenia, przekształcane w wektory za pomocą modelu embedding i zapisywane do indeksu wektorowego wraz z mapami metadanych. Wyszukiwanie w czasie rzeczywistym odbywa się przy każdej prośbie: zapytanie jest przekształcane w wektor, magazyn wektorów zwraca semantycznie istotne fragmenty, Bedrock dodaje je do kontekstu modelu, a etap generowania tworzy spójny wynik, natomiast w trybach wyłącznie wyszukiwawczych otrzymuje się same wyniki.

Dzielenie na fragmenty ma znaczenie operacyjne, ponieważ słaba jakość wyszukiwania często wynika z problemów z przyjmowaniem danych lub dzieleniem na fragmenty, a nie z błędów w zapytaniu.

Nic nie jest „wstawiane jako wiersz” jak w cache SQL. Dodaje się lub aktualizuje pliki lub źródła obsługiwane przez konektory, a następnie uruchamia się synchronizację.

Ostrzeżenie: synchronizacja nie jest automatyczna. Po dodaniu dokumentów do S3 należy ją wywołać wyraźnie, zanim agent będzie mógł je pobrać.

Kontrola w trakcie działania

• numberOfResults określa, ile fragmentów źródłowych zostanie zwróconych (domyślnie do 5, zakres od 1 do 100).
• overrideSearchType umożliwia wybór SEMANTIC dla wyszukiwania tylko wektorowego lub HYBRID dla wyszukiwania wektorowego w połączeniu z tekstem surowym; jest obsługiwany tylko w kompatybilnych magazynach i indeksach. Jeśli nie zostanie ustawiony, Bedrock dokona wyboru sam.
• Filtr metadanych filter oraz grupy logiczne (andAll, orAll) umożliwiają precyzyjne wyszukiwanie.
• Opcjonalna ponowna sortowanie poprawia końcowe uporządkowanie fragmentów.

Dzięki hierarchicznemu dzieleniu na fragmenty liczba wyników może być mniejsza niż zapytana, ponieważ fragmenty potomne mogą zostać zastąpione przez swoje elementy nadrzędne w momencie generowania odpowiedzi.

Dzielenie na fragmenty

Dzielenie tekstu na fragmenty ma duży wpływ na jakość wyszukiwania. Bedrock oferuje domyślne dzielenie na fragmenty o długości około 300 tokenów wzdłuż granic zdań, dzielenie o stałej długości z określoną wielkością tokena i stopniem nakładania się, hierarchiczne fragmenty rodzicielskie i potomne dla większej precyzji oraz szerszego kontekstu, dzielenie semantyczne z wykorzystaniem granic określonych przez model, a także brak dzielenia na fragmenty, w którym każdy dokument jest traktowany jako jeden fragment i który nadaje się głównie do treści już podzielonych na części.

Rozsądny sposób postępowania to rozpoczęcie od domyślnego lub stałego dzielenia na fragmenty, ponieważ jest to proste. Przejdź na rozwiązanie hierarchiczne, gdy odpowiedzi wymagają większego otoczenia kontekstowego, a na rozwiązanie semantyczne, jeśli precyzja pozostaje niska po dostosowaniu promptu. Porównuj efekty z zestawem do oceny wyszukiwania przed i po każdej zmianie.

Magazyny wektorowe

Bazy wiedzy mogą korzystać z różnych backendów wektorowych, takich jak OpenSearch Serverless lub zarządzany klastrum kompatybilny z Aurora PostgreSQL, Pinecone, Redis Enterprise Cloud, MongoDB Atlas oraz Neptune Analytics, w zależności od dostępnej obsługi ze strony dostawcy w momencie implementacji. Wybór tych rozwiązań wpływa na to, czy dostępna jest funkcja wyszukiwania HYBRID, jakie filtry metadanych są możliwe, a także na złożoność operacyjną i koszty. OpenSearch Serverless jest zazwyczaj naj szybszym rozwiązaniem do rozpoczęcia pracy. Poniżej znajduje się przykład konfiguracji za pomocą 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 ...
}

Łączenie wiedzy z narzędziami

Dodanie bazy wiedzy daje agentowi drugą drogę do wyszukiwania informacji. Aby uniknąć niejednoznaczności, należy umieścić zasady routingu dla bazy wiedzy kontra narzędzia API w instrukcjach orkiestracji, zachować identyczny kontrakt POST_PROCESSING niezależnie od tego, które źródło udzieliło odpowiedzi, oraz wskazać, kiedy agent powinien zadawać pytania uzupełniające ze względu na niski poziom pewności wyników wyszukiwania.

Pракtyczna zasada w tym ustawieniu: używaj bazy wiedzy do informacji wewnętrznych i statycznych, takich jak dokumenty polityczne, standardy redakcyjne i notatki historyczne; używaj grupy działań do aktualnych danych zewnętrznych; oraz nie wykorzystujaj obu naraz w jednej turze, chyba że żądanie naprawdę wymaga weryfikacji między źródłami.

Zasady bezpieczeństwa mają zastosowanie również w operacjach pobierania i generowania danych, co jest istotne, ponieważ samo pobieranie oparte na konkretnych danych nie eliminuje ryzyka bezpieczeństwa. Powszechną zaleceniem jest najpierw ocena ścieżki bazy wiedzy przy użyciu zasad bezpieczeństwa w trybie wykrywania, dostosowanie liczby fałszywie pozytywnych i negatywnych wyników na podstawie uzyskanych danych, a następnie przejście do blokowania lub maskowania w środowisku produkcyjnym.

Dostarczanie treści

• Początkowy korpus: aby raz na zawsze załadować polityki, FAQ oraz przewodniki stylowe, należy przesłać pliki do bufora S3 połączonego z źródłem danych i rozpocząć synchronizację.
• Ciągłe aktualizacje: gdy tekst produktu lub prawniczy zmienia się według ustalonego harmonogramu, nocna usługa może przesłać nowe pliki do S3 i uruchomić StartIngestionJob dla danego źródła danych, albo skorzystać z automatycznej synchronizacji, jeśli jest włączona.

Liczne małe dokumenty: przechowuj jeden temat w każdym pliku, na przykład kb/topics/eu-ai-act-overview.md, dzięki czemu granice fragmentów odpowiadają tematom, a cytaty są bardziej czytelne niż w przypadku jednego ogromnego pliku PDF.

Łączniki: SharePoint, Confluence, boty przeglądające stronę internetową i podobne narzędzia pasują do treści już tam istniejących. Bedrock pobiera i synchronizuje dane według ustalonego harmonogramu, a dostępne opcje zależą od typu łącznika i regionu.

Pipeline programistyczne: gdy system CMS lub system zgłoszeń eksportuje pliki HTML lub JSON, Lambda może przekształcić je w zwykły tekst lub markdown, zapisać w S3 i wywołać StartIngestionJob, aby baza wiedzy mogła przyjąć nowe obiekty.

Potencjalne problemy

• Traktowanie bazy wiedzy jako źródła danych w czasie rzeczywistym. Jest ona aktualna tylko zgodnie z ustalonym harmonogramem synchronizacji.
• Zbyt duża lub zbyt mała podziałka na fragmenty, co wpływa negatywnie na dokładność.
• Niedbale przygotowane metadane, które sprawiają, że filtry stają się bezużyteczne.
• Łączenie zadań pobierania i formatowania danych w jednej fazie instrukcji.
• Przekonanie, że zmiana sformułowania instrukcji może uratować słaby indeks wyszukiwania.

Jakie to ma konsekwencje

Streszczenia działają najlepiej, gdy są dostosowane do konkretnego obszaru tematycznego, a nie pozostawione jako ogólne podsumowania. Instrukcje i zasady bezpieczeństwa funkcjonują na różnych poziomach, dlatego należy je wersjonować oddzielnie. Baza wiedzy to tylko jedna z opcji wyszukiwania i nie zastępuje API w czasie rzeczywistym, co oznacza, że instrukcje powinny jasno wskazywać, kiedy narzędzie dostarcza aktualne dane, a kiedy baza wiedzy – starannie przygotowany kontekst.

Wspólnie te elementy tworzą wewnętrzną architekturę agenta: prompt MEMORY_SUMMARIZATION, który skraca długie rozmowy do możliwych do ponownego użycia streszczeń, Bedrock Guardrail blokujący kategorie treści szkodliwych oraz baza wiedzy oparta na źródle danych S3 służąca do generowania treści wzbogaconych o informacje z bazy wiedzy.