AWS łączy semantic i keyword search w jednym agencie RAG

Amazon Web Services opublikował na swoim blogu technicznym instrukcję budowania agentycznego asystenta AI, który łączy wyszukiwanie semantyczne i tekstowe w ramach jednej architektury RAG opartej na Amazon Bedrock i Amazon OpenSearch.

Hybrid RAG, czyli dlaczego samo wektorowe wyszukiwanie nie wystarcza

Pure semantic search ma swoje ślepe plamki — kiedy użytkownik wpisuje dokładną frazę, nazwę produktu albo numer katalogowy, modele embeddingowe potrafią zwrócić tematycznie zbliżone wyniki, ale nie ten jeden konkretny dokument. Z kolei klasyczny BM25 (keyword search) gubi kontekst i synonimię. Hybryda łączy oba podejścia i AWS właśnie pokazał, jak ją poprawnie odpalić na swoim stacku.

W opisanej architekturze OpenSearch działa równolegle jako silnik wektorowy i pełnotekstowy. System wykonuje oba zapytania niezależnie, a następnie scala rankingi przy użyciu Reciprocal Rank Fusion — algorytmu, który nie faworyzuje żadnego z sygnałów bez powodu.

Co robi Strands Agents i dlaczego AWS wrzucił to do stosu

Strands Agents to stosunkowo świeży framework od AWS do budowania agentów AI, który AWS odpalił publicznie wcześniej w tym roku. W omawianej architekturze agent decyduje, kiedy wywołać narzędzie do wyszukiwania, jak sformułować zapytanie i jak połączyć wyniki z kilku źródeł przed wygenerowaniem odpowiedzi przez model językowy.

Do tego dochodzi Amazon Bedrock AgentCore — usługa zarządzająca cyklem życia agenta: pamięcią, sesjami i wywołaniami narzędzi. To nowa warstwa infrastruktury, którą AWS dorzucił do Bedrock, żeby nie trzeba było samodzielnie kleić tych elementów lambdami i DynamoDB.

Czy to działa lepiej niż samodzielny LangChain?

Porównanie z LangChain czy LlamaIndex jest nieuniknione. AWS nie podaje w artykule benchmarków porównawczych z innymi frameworkami, więc trudno oceniać twarde liczby. Strands Agents jest wyraźnie zaprojektowany pod ekosystem AWS — głęboka integracja z Bedrock, IAM, CloudWatch i OpenSearch sprawia, że setup jest szybszy, ale jednocześnie mocniej uzależnia od jednego dostawcy.

Dla firm, które już siedzą w chmurze AWS i używają Bedrock do modeli (Anthropic Claude, Meta Llama, Mistral), to podejście redukuje ilość kodu orkiestracyjnego, który trzeba utrzymywać. Dla tych na multi-cloud lub z własnymi modelami — niekoniecznie.

Architektura w skrócie

Cały pipeline wygląda następująco:

• Dokumenty trafiają do OpenSearch z podwójną indeksacją: wektorową (przez model embeddingowy z Bedrock) i klasyczną (BM25)
• Użytkownik zadaje pytanie agentowi
• Strands Agent wywołuje narzędzie wyszukiwania z odpowiednio sformułowanym zapytaniem
• OpenSearch wykonuje parallel query — semantyczne i tekstowe jednocześnie
• Reciprocal Rank Fusion scala listę wyników
• Top-N fragmentów trafia do kontekstu modelu językowego na Bedrock
• Agent generuje odpowiedź i może wykonać kolejne rundy wyszukiwania, jeśli odpowiedź jest niewystarczająca

Cały cykl jest iteracyjny — agent nie musi zadowolić się pierwszym zapytaniem.

Kiedy warto to wdrożyć?

Hybrydowy RAG ma sens wszędzie tam, gdzie baza wiedzy jest duża i zróżnicowana — dokumentacja techniczna z konkretnymi komendami miesza się z artykułami opisowymi, albo katalogi produktów łączą kody SKU z opisami marketingowymi. Czysto wektorowe podejście w takich przypadkach regularnie gubi precyzyjne zapytania.

AWS podaje jako przykład asystenta obsługi klienta, który musi jednocześnie rozumieć intencję użytkownika i odnajdować konkretne numery polis czy nazwy produktów — klasyczny przypadek, gdzie sama semantyka nie wykręci wystarczającej precyzji.

Amazon Bedrock AgentCore jest dostępny w wybranych regionach AWS, a pełny kod przykładowej implementacji trafił na GitHub razem z artykułem blogowym.