AWS přidává do Bedrocku jednorázové RAG a režim pouze pro vyhledávání

Amazon Web Services oznámila 9. listopadu 2026, že Amazon Bedrock Managed Knowledge Base nyní podporuje jednorázové generování rozšířené vyhledáváním (RAG) a požadavky vracející pouze pasáže prostřednictvím AgenticRetrieveStream. Rozšířený rozsah 0–5 pro maxAgentIteration umožňuje aplikacím zvolit načtení zdrojových pasáží, odpověď po jediném vyhledání nebo stávající vícekrokové agentní vyhledávání této služby.

Aktualizace přináší základní vzorec RAG, tedy jedno vyhledání následované vygenerovanou odpovědí, do stejného streamovacího rozhraní API, které se používá pro složité vyhledávání. Jednorázové RAG využívá ke generování jedno volání základního modelu, zatímco požadavky pouze na vyhledávání žádné volání nevyužívají. AWS uvádí, že jednorázový režim může ve srovnání s agentním vyhledáváním snížit latenci a využití modelu, oznámení však neuvádí žádné naměřené srovnání latence ani nákladů.

Režim vyhledávání určuje jediný parametr

Hodnota 0 vrací odpovídající pasáže, aniž by generovala odpověď; hodnota 1 provede jedno vyhledání a vygeneruje odpověď s generateResponse=true; a hodnoty 2 až 5 zachovávají stávající agentní chování. Každý režim podporuje více znalostních bází. Jednorázové tedy označuje jedno vyhledání, nikoli omezení na jednu znalostní bázi.

Jedna iterace představuje jedno volání základního modelu. Pokud je generování povoleno, limit n vyhrazuje poslední volání pro generování odpovědi a umožňuje až n minus 1 plánovacích kol. Každé plánovací kolo spojuje přeformulování dotazu s vyhledáním. Počáteční spekulativní vyhledání proběhne před plánováním a nikdy se do limitu nezapočítává.

Při hodnotě 0 musí být generování odpovědi vypnuté. Jeho zapnutí vyvolá chybu 4xx, protože odpověď vyžaduje volání modelu. Při hodnotě 1 stream obsahuje jedno vyhledání a jednu odpověď podloženou zdroji, bez událostí s informacemi o průběhu plánování. Stávající požadavky využívající hodnoty 2 až 5 se nemění.

Chování streamu a provozní limity

Referenční příručka k rozhraní API AgenticRetrieveStream uvádí messages, retrievers, a agenticRetrieveConfiguration jako povinné vstupy požadavku, zatímco generateResponse je nepovinné. Části generované odpovědi se odesílají pouze tehdy, je-li generování povoleno. Konečný výsledek může obsahovat vyhledané položky, syntetizovanou odpověď a citace propojující úseky odpovědi s výsledky, které je podporují.

Provoz pouze s vyhledáváním odpovídá přímému volání Retrieve přímo, jeho formát odpovědi se však liší: pasáže se zobrazují v události streamu result bez score ani location polí. Aplikace, které již používají AgenticRetrieveStream tak mohou získat Retrieve-stylové chování změnou parametru namísto integrace samostatného rozhraní API.

Pro složité otázky popisuje uživatelská příručka Amazon Bedrock pracovní postup, který rozděluje dotazy na dílčí dotazy, ověřuje, zda jsou získané důkazy dostačující, provádí další vyhledávání a může se rozšířit na celý dokument. Agentní vyhledávání podporuje pouze plně spravované znalostní báze Bedrock a pro každý požadavek umožňuje až pět retrieverů. Snížení horního limitu počtu iterací může agenta zastavit dříve a potenciálně snížit přesnost u složitých dotazů.

Týmy vyvíjející aplikace volí režim a testují jej

AWS nastavení ilustruje na fiktivním interním asistentovi banky pro vyhledávání směrnic, nikoli na řešení nasazeném u zákazníka. Dotaz na dokumentaci pro živnostníky využívá maxAgentIteration=1, zatímco srovnání požadavků pro živnostníky a společnosti s ručením omezeným (LLC), které zároveň ověřuje pravidla pro vlastníky-nerezidenty, využívá hodnotu 4 a umožňuje až tři plánovací kola. Požadavek na kontrolu znění směrnice využívá hodnotu 0 a vrací zdrojové pasáže bez shrnutí.

Režim musí zvolit aplikace; maxAgentIteration požadavky automaticky nerozřazuje. Ukázkový asistent zpracovává vyhledávání a porovnávání směrnic, neschvaluje však účty ani nenahrazuje kontrolu a schvalování ze strany banky.

Při zavádění AWS doporučuje porovnat jednorázové RAG se stávající agentní konfigurací nad stejnou znalostní bází a použít reprezentativní otázky i očekávané odpovědi. Vyhodnocení by mělo měřit latenci a náklady na požadavek, ověřovat správnost i oporu v získaných pasážích a zahrnovat otázky týkající se více dokumentů i otázky, na něž nelze odpovědět. Výsledky mohou pomoci vybrat nejnižší limit počtu iterací, který splňuje požadavky na kvalitu pro daný pracovní postup.

Tato změna činí z hloubky vyhledávání výslovné infrastrukturní rozhodnutí pro každý požadavek. Přímé dotazy mohou obejít volání potřebná k plánování, zatímco složité dotazy si zachovávají iterativní shromažďování důkazů. Pro podniky je zásadní otázkou, zda nižší využití modelu zachová úplné odpovědi podložené vlastními dokumenty, místo aby se předpokládalo, že vyšší limit počtu iterací je vždy lepší.