LLM-y mogą „widzieć” naraz tylko ograniczoną ilość tekstu, czyli okno kontekstu. Sprawdza się to przy małych zadaniach, ale zawodzi, gdy baza wiedzy obejmuje tysiące stron. Nawet gdy okno kontekstu jest wystarczające, wydajność może spaść z powodu problemu „igły w stogu siana”.
RAG („generowanie wspomagane wyszukiwaniem”) stało się bardzo popularnym wzorcem: utrzymujesz bazę wiedzy (dokumenty, wiki, zasady, transkrypcje itp.), przeprowadzasz wyszukiwanie semantyczne dla zapytania użytkownika, aby za pomocą osadzeń znaleźć najtrafniejsze fragmenty, a następnie przekazujesz je do LLM-u wraz z pytaniem. Ogranicza to kontekst modelu, a przy prawidłowym wdrożeniu może poprawić jakość odpowiedzi i zmniejszyć liczbę halucynacji.
pgai to otwartoźródłowe rozszerzenie Postgresa (wraz z narzędziami), które pomaga tworzyć procesy „wyszukiwania AI” na bazie zaufanej, otwartoźródłowej bazy danych PostgreSQL.
Głównym założeniem jest przeniesienie większej części standardowego procesu RAG do warstwy bazy danych (pozyskiwanie → dzielenie → osadzanie → synchronizacja osadzeń), zamiast traktowania bazy jako „zwykłego magazynu” osadzeń.
Pierwsze wrażenia są obiecujące, ale gdy proces RAG staje się choćby umiarkowanie złożony — zwłaszcza pod względem metod dzielenia treści — rozwiązanie przestaje się sprawdzać. Mimo to będziemy uważnie obserwować ten projekt.
RAG można zbudować na wiele sposobów. Szczegółowe omówienie różnych podejść znajdziesz w artykule Praktyczne przykłady niestandardowych rozwiązań RAG. Gdy liczy się jakość, liczba możliwości okazuje się zaskakująco duża, a typowe „domyślne” podejście wygląda mniej więcej tak:
Zbierz zestaw dokumentów.
Podziel je na fragmenty. Można to zrobić na wiele sposobów, np. według akapitów lub grup semantycznych.
Przekształć każdy fragment w osadzenie.
Zapisz osadzenia w wektorowej bazie danych (Pinecone, Milvus itp.) albo w Postgresie za pomocą pgvector.
Po otrzymaniu zapytania wyszukaj najbliższe fragmenty `i przekaż je do LLM-u (tu również istnieje wiele sposobów).
W wielu stosach kroki (1)–(3) odbywają się poza bazą danych — w kodzie aplikacji lub potoku danych — a baza służy głównie do:
przechowywania osadzeń
wyszukiwania osadzeń
pgai to otwartoźródłowe rozszerzenie Postgresa rozwijane przez Timescale, które próbuje zatrzeć tę granicę.
Zamiast pozostawiać aplikacji ręczne zarządzanie osadzeniami, pgai przekształca je w funkcję bazy danych:
Określasz tabelę lub dokumenty, dla których mają powstać osadzenia.
Wskazujesz model osadzania i strategię dzielenia treści.
pgai zajmuje się resztą, w tym aktualizowaniem osadzeń po zmianie danych źródłowych.
Korzyści brzmią zachęcająco:
Mniej niestandardowego kodu integracyjnego wymagającego utrzymania.
Łatwiejsze utrzymywanie „świeżych” osadzeń w miarę zmian dokumentów źródłowych.
Postgres/pgai obsługuje ponowne próby, limity częstotliwości, nieudane zadania itp.
Uwaga dla czytelnika: pgai zawiera pgvector — inne bardzo popularne rozszerzenie Postgresa do RAG. pgvector dodaje do Postgresa przechowywanie wektorów i wyszukiwanie podobieństw, a pgai wykorzystuje te funkcje do automatyzacji etapów procesu RAG, takich jak dzielenie treści, tworzenie osadzeń i ich aktualizowanie.
1) Łatwo je uruchomić.
Podstawowy scenariusz jest dość prosty:
Pobierz obrazy Dockera od Timescale (baza danych i proces roboczy).
Podaj klucz API dostawcy modelu osadzania.
Uruchom kilka poleceń SQL definiujących wektoryzator, czyli określających, co osadzać, jak dzielić treść i którego modelu używać.
Następnie pgai uruchamia proces roboczy wektoryzatora jako osobny proces, który asynchronicznie generuje osadzenia, np. co 5 minut lub z dowolną inną częstotliwością.
2) Wygodnie jest realizować cały proces „blisko” bazy danych.
pgai może pobierać treść z tabel, a także wczytywać dokumenty z takich miejsc jak S3, po czym je analizować, dzielić i osadzać. Obsługuje również różne formaty dokumentów tekstowych, takie jak PDF czy Markdown.
1) Tracisz dużą część kontroli, a RAG czasem jej wymaga.
Systemy RAG zapewniające wysoką jakość odpowiedzi często wymagają niestandardowych procesów, takich jak:
niestandardowe reguły dzielenia treści (według nagłówków, stron, wypowiedzi rozmówców itp.)
dzielenie treści uwzględniające metadane (z zachowaniem tytułów sekcji, znaczników czasu, autorów i typu dokumentu)
różne strategie osadzania dla poszczególnych typów dokumentów
W powyższych obszarach pgai oferuje mniejszą elastyczność.
Obecnie dostępne są dwie główne strategie: dzielenie tekstu według liczby znaków oraz rekurencyjne dzielenie według liczby znaków. Można też zrezygnować z dzielenia. W niektórych zastosowaniach może to wystarczyć, ale wiele produkcyjnych systemów RAG wymaga większych możliwości dostosowania.
Świetnie byłoby zobaczyć, jak Timescale wdraża bardziej zaawansowane strategie dzielenia treści znane z bibliotek takich jak Chonkie oraz obsługuje zaawansowane rozwiązania, takie jak wyszukiwanie kontekstowe Anthropic.
2) Najpierw tekst, bez multimodalności.
Wiele interesujących problemów RAG nie dotyczy już wyłącznie tekstu:
pliki PDF z diagramami
zrzuty ekranu i obrazy
nagrania dźwiękowe
klipy wideo
Nawet jeśli z tych źródeł da się „wyodrębnić tekst”, nie jest to równoznaczne z prawdziwie multimodalnym procesem osadzania.
Gdyby pgai zapewniło kompleksową obsługę modeli multimodalnych — wczytywanie, dzielenie i osadzanie dużych obrazów oraz plików audio i wideo zapisanych w S3 wraz z niezawodną synchronizacją — byłoby to bardzo atrakcyjne. Dziś jednak obsługuje proces osadzania tekstu.
3) Jeśli potrzebujesz tylko osadzeń, pgai może być zbędne.
Jeśli Twój proces pozyskiwania danych jest już niestandardowy lub musi taki być, „osadzanie fragmentów tekstu” nie stanowi najtrudniejszej części RAG. W takim przypadku pgai rozwiązuje najłatwiejszą część problemu.
Ponadto, jeśli baza wiedzy jest aktualizowana rzadko, automatyczna synchronizacja osadzeń ma mniejszą wartość.
Szczególnie dobrym zastosowaniem pgai byłoby wdrożenie w bazach danych interfejsu konwertującego tekst na SQL. Można to dość łatwo osiągnąć za pomocą modułu semantic_catalog oferowanego przez pgai. Wystarczy skonfigurować go tak:
Bash
a następnie poleceniem pgai semantic-catalog create zlecić katalogowi semantycznemu odczytanie słowników danych. W ten sposób z magazynu danych generowany jest kontekst wyglądający mniej więcej tak:
Plain Text
Ten kontekst jest teraz dostępny dla pgai na kilka sposobów:
Poprzez wyszukiwanie semantyczne:
To zapytanie zwróci tabele, funkcje i inne obiekty, które mogą mieć znaczenie dla zapytania sformułowanego w języku naturalnym:
Bash
Pobieranie surowego kontekstu:
Spowoduje to wyświetlenie surowego kontekstu YAML powiązanego z zapytaniem sformułowanym w języku naturalnym:
Bash
Generowanie SQL:
Możesz też bezpośrednio wygenerować surowy kod SQL potrzebny do udzielenia odpowiedzi na zapytanie. Kontekst z poprzedniego kroku jest wysyłany do LLM-u, który generuje odpowiedź:
Bash
Jeśli tworzysz stosunkowo prosty system RAG, warto wypróbować pgai, gdy zależy Ci na:
Postgresie jako głównym źródle danych,
minimalnej ilości kodu integracyjnego,
automatycznie synchronizowanych osadzeniach,
szybkim sposobie wdrożenia konwersji tekstu na SQL w bazach danych,
eksperymentowaniu z nowymi narzędziami RAG i rozszerzeniami Postgresa.
Prawdopodobnie warto poczekać z pgai, jeśli Twój proces RAG wymaga któregokolwiek z poniższych elementów:
rozbudowanej, niestandardowej logiki pozyskiwania lub dzielenia treści
wielu typów dokumentów o różnych wymaganiach dotyczących analizy
osadzeń multimodalnych
Choć pgvector wyraźnie zyskało dużą popularność, nie wiadomo, czy pgai spotka się z podobnym zainteresowaniem, a tym samym wsparciem — zwłaszcza że istnieje dopiero od około 18 miesięcy.
pgai to ciekawe podejście do RAG, w którym baza danych przejmuje więcej rutynowych zadań operacyjnych, dzięki czemu kod aplikacji może być prostszy.
Obecnie pgai jest:
użyteczne i naprawdę wygodne w prostych konfiguracjach RAG
zbyt mało elastyczne dla bardziej niestandardowych procesów, zwłaszcza multimodalnych
Rozwiązanie jest obiecujące i zdecydowanie warto obserwować jego dalszy rozwój.