AWS dodało funkcję kompresji uwzględniającej zapytania (query-aware compression) do swojej usługi Bedrock, co pozwala programistom usuwać nieistotne fragmenty dokumentów, zanim trafią one do modelu językowego. Dzięki ograniczeniu liczby tokenów przesyłanych do modelu, funkcja ta może obniżyć koszty obliczeniowe potoków (pipelines) Retrieval-Augmented Generation (RAG).

Dlaczego potoki RAG generują wysokie koszty

Systemy RAG najpierw pobierają fragmenty tekstu z bazy wiedzy, a następnie przekazują je do modelu generatywnego, aby odpowiedzieć na pytanie użytkownika. Większość implementacji przesyła każdy pobrany fragment bezpośrednio do modelu, nawet jeśli duże części tekstu nie mają nic wspólnego z zapytaniem. Każde dodatkowe słowo staje się tokenem, a każdy token przetwarzany przez model zwiększa opłatę za korzystanie z podstawowego API. W przypadku małych i średnich firm obsługujących boty wsparcia lub wewnętrzne narzędzia wyszukiwania, wydatki na tokeny mogą szybko przewyższyć koszty samych wywołań modelu.

Jak działa kompresja uwzględniająca zapytania

Nowa funkcja Bedrock wprowadza krok filtrowania pomiędzy etapem pobierania (retrieval) a generowaniem:

  • System nadal pobiera ten sam zestaw dokumentów dla danego zapytania.
  • Zanim model zobaczy jakikolwiek tekst, lekki procesor ocenia każdy fragment pod kątem konkretnego pytania.
  • Zachowywane są tylko te części, które uznano za istotne; reszta jest odrzucana jako szum.

Nie potrzebujesz nowego indeksu, modelu embeddingowego ani dotrenowanego (fine-tuned) modelu językowego. Zmiana polega po prostu na przebudowaniu potoku tak, aby wywoływał warstwę kompresji.

Wpływ na biznes

Ponieważ opłaty za tokeny rosną wraz z ilością tekstu przesyłanego do modelu, usuwanie nieistotnych fragmentów może liniowo zmniejszać rachunek. Największe korzyści odniosą firmy, których koszty RAG gwałtownie rosły wraz ze skalowaniem wykorzystania.

Na co zwrócić uwagę w następnej kolejności

  • Przetestuj funkcję na własnych danych: Przeprowadź test porównawczy standardowego przepływu RAG z przepływem uwzględniającym kompresję typu query-aware. Zmierz liczbę tokenów, opóźnienie (latency) oraz trafność odpowiedzi.
  • Transparentność dostawcy: Oceniając zewnętrzne platformy RAG, zapytaj, czy stosują kompresję lub filtrowanie w swoich potokach pobierania danych. Dostawca przesyłający surowe fragmenty prawdopodobnie będzie generował wyższe miesięczne faktury.

Podsumowanie

Skromna modyfikacja potoku — filtrowanie nieistotnego tekstu przed przesłaniem go do modelu — może zmienić ukryty koszt w kontrolowaną pozycję w budżecie. Dla organizacji korzystających już z RAG opartego na Bedrock, włączenie kompresji uwzględniającej zapytania jest eksperymentem wymagającym niewielkiego wysiłku, jednak wszelkie oszczędności będą zależeć od specyfiki Twoich danych.