Wyjaśnienie podstawowego procesu RAG: od surowych dokumentów do precyzyjnych odpowiedzi.
Jak działa podstawowy proces generacji wzbogaconej o wyszukiwanie informacji: czyszczenie danych, dzielenie na fragmenty, tworzenie wektorów reprezentacji, wyszukiwanie wektorowe, formułowanie zapytań, ocena oraz typowe problemy.
Źródła: Building a Basic RAG Pipeline: A Practical Guide to Retrieval-Augmented Generation
Modele językowe mają dziwny nawyk: brzmią, jakby były pewne siebie, mimo że nie posiadają odpowiednich informacji. Zadaj pytanie dotyczące wewnętrznej polityki firmy, instrukcji do produktu wydanego w zeszłym miesiącu, mało znanej dokumentacji prawnej lub wczorajszego zgłoszenia obsługi klienta – model po prostu może tego nie wiedzieć. Co gorsza, może wygenerować coś brzmiącego wiarygodnie, aby zatuszować tę lukę.
Generowanie wzbogacone pobieraniem danych, zwykle skracane jako RAG, jest standardowym rozwiązaniem. Taka metoda umożliwia modelowi korzystanie z zewnętrznej wiedzy w momencie, gdy jest to konieczne. Nie wszystko musi znajdować się w pamięci modelu, ponieważ system wyszukuje zaufaną bazę wiedzy, wybiera najbardziej istotne fragmenty i tworzy odpowiedź opartą na nich. Mówiąc prościej, asystent „z zamkniętą książką” staje się takim z otwartą książką.
To podejście przyciągnęło uwagę dzięki artykułowi badawczemu z 2020 roku na temat generacji wzbogaconej o wyszukiwanie danych w zadań NLP wymagających dużych ilości wiedzy, który łączył model generatywny z narzędziem do wyszukiwania przeszukującym zewnętrzną kolekcję dokumentów. Kluczowym spostrzeżeniem było to, że wbudowana w model wiedza oraz informacje zewnętrzne mogą się wzajemnie uzupełniać. Model zapewnia umiejętności językowe, natomiast narzędzie do wyszukiwania dostarcza aktualnych, konkretnych szczegółów.
Bazowy proces przebiega w dwóch fazach. Indeksowanie przygotowuje dokumenty do wyszukiwania. Odpowiadanie obejmuje przyjęcie pytania użytkownika, pobranie odpowiednich materiałów i przekazanie ich modelowi jako kontekstu. Brzmi to prosto, ale każdy etap kryje za sobą decyzje, które wpływają na wynik. Słaby system rzadko zawodzi z powodu słabego samego modelu – znacznie częściej pobiera niewłaściwe dokumenty, fragmenty są nieuporządkowane, prompt jest niejasny lub system nie potrafi przyznać, że nie ma odpowiedzi.
Poniższe sekcje wyjaśniają tę koncepcję od podstaw.
Czym w praktyce jest RAG
Bazowy cykl składa się z czterech kroków: użytkownik zadaje pytanie, system przeszukuje bazę wiedzy, najbardziej odpowiednie fragmenty trafiają do promptu modelu, a model odpowiada, korzystając z tego uzyskanego kontekstu.
Załóżmy klienta, który chce wiedzieć, czy laptop po renowacji nadal może zostać zwrócony po upływie 20 dni. Zwykły chatbot może zgadywać na podstawie ogólnych zwyczajów handlowych. Chatbot RAG może sprawdzić rzeczywistą politykę zwrotów, znaleźć sekcję dotyczącą produktów po renowacji i odpowiedzieć na podstawie niej. Jeśli polityka określa 14-dniowy termin na zwrot laptopów po renowacji, bot może to potwierdzić. Jeśli polityka milczy na temat laptopów po renowacji, bot nie powinien wymyślać żadnych zasad.
To jest sedno sprawy: najpierw pozyskiwanie informacji, potem ich generowanie. Pozyskiwanie informacji ogranicza zakres do kilku przydatnych dowodów, a generowanie przekształca je w pomocną odpowiedź. Przy prawidłowym zastosowaniu RAG poprawia dokładność faktów, ułatwia weryfikację odpowiedzi i umożliwia aktualizację wiedzy systemu bez konieczności ponownego szkolenia modelu.
Wybór źródła wiedzy
Każda ścieżka przetwarzania zaczyna się od materiału, który należy pobrać. Typowymi przykładami są dokumentacja firmy, instrukcje produktów, artykuły z centrum pomocy, pliki PDF, umowy, prace badawcze, notatki z spotkań, rekordy bazy danych, dokumentacja kodu oraz zgłoszenia obsługi klienta.
Największe źródło nie zawsze jest najlepszym. Skupiona, uporządkowana i aktualna kolekcja dokumentów zwykle przewyższa dużą ilość przestarzałych plików. RAG nie może naprawić złego materiału źródłowego, więc przestarzałe, niejasne lub sprzeczne dokumenty dają przestarzałe, niejasne lub sprzeczne odpowiedzi.
Zanim cokolwiek zindeksujesz, przydatne jest postawienie kilku praktycznych pytań:
- Czy informacje są dokładne i aktualne?
- Kto jest ich właścicielem?
- Czy każdy użytkownik ma prawo je oglądać?
- Czy istnieją duplikaty lub sprzeczne wersje?
- Czy tabele, obrazy, przypisy lub klauzule prawne wymagają specjalnego traktowania?
Niewielka, dobrze utrzymana baza wiedzy to dobry początek. Do pierwszego projektu wybierz jeden jasny przypadek użycia, na przykład pytania dotyczące podręcznika pracownika lub FAQ produktu, i rozwijaj go, gdy to zadziała.
Czyszczenie i przygotowywanie dokumentów
Pliki surowe rzadko są gotowe do wyszukiwania. Pliki PDF mogą mieć uszkodzone przerwy między wierszami. Strony internetowe zawierają menu, banery z informacjami o plikach cookie, reklamy oraz stopki, które powtarzają się na każdej stronie. Dokumenty wewnętrzne mogą mieć nagłówki bez wystarczającego kontekstu, a arkusze kalkulacyjne mogą ukrywać kluczowe informacje w kolumnach, które trudno odczytać jako zwykły tekst.
Czyszczenie przekształca ten bałagan w tekst nadający się do wyszukiwania. Może polegać na usunięciu tekstów szablonowych, zachowaniu nagłówków, wydobyciu tabel, konwersji wszystkiego do spójnego formatu oraz dodaniu metadanych. Metadane są szczególnie przydatne, ponieważ fragment tekstu z takimi informacjami jak tytuł dokumentu, autor, data, dział odpowiedzialny, wersja produktu, link, poziom dostępu lub nagłówek sekcji zyskuje na wartości.
Porównajmy prosty fragment tekstu typu „Zwroty należy zgłaszać w ciągu 14 dni” z tym, który ma etykietę: tytułem jest zasada zwrotu laptopa z renowacji, sekcją jest okno czasowe na zwrot, ostatnia aktualizacja miała miejsce w marcu 2026 roku, a w treści podano, że zwrot laptopa z renowacji musi zostać zgłoszony w ciągu 14 dni od jego otrzymania. Ta druga forma daje zarówno narzędziu do wyszukiwania, jak i modelowi więcej materiału do przetworzenia, a także ułatwia późniejsze cytowanie i filtrowanie.
Dzielenie dokumentów na fragmenty
Modele językowe i systemy wyszukiwania zazwyczaj nie radzą sobie z całymi książkami, podręcznikami czy bibliotekami polityk jako całością. Lepiej radzą sobie z mniejszymi fragmentami zwanymi kawałkami.
Krojenie tekstu na kawałki jest jedną z najważniejszych części całego procesu, ponieważ wyszukiwanie odbywa się na poziomie tych kawałków. Jeśli kawałki są zbyt duże, odpowiedź może zostać pogrzebana wśród nieistotnego tekstu. Jeśli są zbyt małe, system może znaleźć jedynie fragmenty bez wystarczającego kontekstu, by właściwie odpowiedzieć. Dobry kawałek jest na tyle duży, by zawierać kompletną ideę, a na tyle mały, by zachować koncentrację.
W przypadku systemów o dużej ilości tekstu programiści często zaczynają od kawałków składających się z kilkuset słów i dostosowują je w zależności od wyników. Niektórzy używają nakładających się kawałków, aby kontekst nie został utracony przy granicach, na przykład tam, gdzie nagłówek zamyka jeden kawałek, a tekst polityki, który wprowadza, otwiera następny.
Podział na fragmenty powinien, o ile to możliwe, odpowiadać strukturze dokumentu. Dzielenie na sekcje, nagłówki, akapity lub pary pytanie-odpowiedź zazwyczaj jest skuteczniejsze niż dzielenie według ustalonej liczby znaków, a różne typy dokumentów, takie jak zasady zwrotu pieniędzy, przewodniki naprawcze i artykuły naukowe, mogą wymagać własnego podejścia.
Tutaj wiele prostych systemów albo skutecznie funkcjonuje, albo zawodzi. Model może odpowiadać tylko na podstawie tego, co otrzymuje, więc fragment bez kontekstu może sprawić trudności nawet silnemu modelowi.
Tworzenie embeddingów
Po oczyszczeniu i podziale na fragmenty każdy z nich jest przekształcany w embedding – numeryczną reprezentację znaczenia. Technicznie jest to wektor, lista liczb odzwierciedlająca informacje semantyczne dotyczące tekstu. Teksty o podobnym znaczeniu zazwyczaj znajdują się blisko siebie w przestrzeni wektorowej, co umożliwia systemowi wyszukiwanie według znaczenia, a nie tylko dokładnych słów kluczowych.
Załóżmy teraz, że pytanie brzmi, jak długo ktoś ma czas na zwrócenie komputera po renowacji, podczas gdy dokument stanowi, że laptopy po renowacji można zwrócić na żądanie w ciągu 14 dni od dostawy. Tradycyjne wyszukiwanie według słów kluczowych może przeoczyć związek pomiędzy „zwróceniem” a „zwrotami” lub pomiędzy „komputerem” a „laptopem”. Wyszukiwanie oparte na embeddingach ma większe szanse na dostrzeżenie tej relacji.
Taki rodzaj dopasowywania semantycznego wyjaśnia, dlaczego metoda Dense Retrieval stała się ważna w odpowiadaniu na pytania z otwartego domeny. Badania z 2020 roku pokazały, że nauczone reprezentacje gęste mogą przewyższyć silną bazę BM25 w kilku testach wydajnościowych związanych z odpowiadaniem na pytania w otwartym domenie.
W prostym pipeline każdy fragment jest umieszczany w bazie wiedzy. Gdy użytkownik zadaje pytanie, ono również jest tam umieszczane, porównywane z zapisanymi reprezentacjami fragmentów i wybierane są najbliższe dopasowania.
Zapisywanie reprezentacji we wektorowej bazie danych
Reprezentacje te potrzebują miejsca umożliwiającego wyszukiwanie, a tę rolę pełni wektorowa baza danych lub magazyn wektorów. Przechowuje ona reprezentację każdego fragmentu, jego oryginalny tekst oraz wszelkie przydatne metadane. Podczas zadawania pytania znajduje fragmenty, których reprezentacje są najbliższe reprezentacjom pytania.
Dla prototypu wystarczy lokalny lub pamięciowy magazyn. W warunkach produkcyjnych może być konieczna zarządzana wektorowa baza danych, silnik wyszukiwania obsługujący wektory lub rozszerzenie bazy danych dodające funkcję wyszukiwania wektorowego. Decyzję powinny kierować wymagania dotyczące skalowalności, szybkości, kosztów, potrzeb filtrowania, bezpieczeństwa oraz częstotliwości zmian dokumentów.
Należy traktować to jako część silnika wyszukiwania, a nie tylko pudełko do przechowywania. Dobry filtr metadanych może znacząco wpłynąć na efektywność. Pytanie dotyczące europejskiej polityki zwrotów nie powinno przywoływać zasad z innej regionu. Jeśli użytkownik może przeglądać tylko dokumenty HR swojego działu, mechanizm wyszukiwania musi to zagwarantować, zanim cokolwiek dotrze do modelu.
To jest ważne, ponieważ RAG może ujawniać informacje, gdy kontrola dostępu jest słaba. Nie można polegać na modelu, by ukrywał treści dostępne tylko dla uprawnionych użytkowników po ich wyświetleniu, a bezpieczniej jest w ogóle zapobiegać wyświetlaniu takich materiałów.
Wyszukiwanie odpowiednich fragmentów
Odpowiadanie rozpoczyna się, gdy użytkownik zadaje pytanie. System wstawia to pytanie do bazy wektorowej, przeszukuje ją i zwraca najbardziej odpowiednie fragmenty. Praktycy nazywają to metodą wyszukiwania typu top-k, gdzie k oznacza liczbę powracających fragmentów; top-5 oznacza pięć najbliższych wyników.
Wybór wartości k to kwestia równowagi. Jeśli pobra się zbyt mało informacji, odpowiedź może pomijać kluczowe szczegóły. Jeśli zaś pobra się zbyt wiele, zapytanie staje się chaotyczne, kosztowne lub mylące. Więcej kontekstu nie zawsze jest lepsze, ale lepszy kontekst na pewno tak.
Wiele podstawowych systemów zaczyna od wyszukiwania podobieństwa wektorowego, które dobrze radzi sobie z pytaniami dotyczącymi znaczenia, ale nie jest doskonałe. Niektóre zapytania wymagają dokładnych słów, identyfikatorów, nazw, dat, kodów błędów lub sformułowań prawniczych, a w takich przypadkach wyszukiwanie według słów kluczowych może być skuteczniejsze niż samo wyszukiwanie wektorowe.
Z tego powodu popularne jest wyszukiwanie hybrydowe. łączy ono wyszukiwanie wektorowe z wyszukiwaniem według słów kluczowych w tekście pełnym i łączy uzyskane wyniki. Na przykład Azure AI Search opisuje wyszukiwanie hybrydowe jako pojedyncze zapytanie, które uruchamia oba rodzaje wyszukiwania jednocześnie i łączy uporządkowane wyniki za pomocą metody Reciprocal Rank Fusion. Mówiąc prościej, system ma dwa sposoby dotarcia do odpowiedzi: poprzez znaczenie i poprzez dokładne sformułowanie.
Poszukiwanie wektorowe to rozsądny pierwszy krok. Jeśli odbiorcy często wpisują kody produktów, tytuły polis, sformułowania prawne lub komunikaty o błędach, warto rozważyć zastosowanie podejścia hybrydowego.
Tworzenie promptu
Gdy dane zostaną pobraane, trafiają do promptu modelu, który powinien jasno określić kontekst, pytanie użytkownika oraz to, co ma zrobić model. Prosty prompt typu RAG może polecić modelowi udzielenie odpowiedzi na podstawie dostarczonego kontekstu, poleganie wyłącznie na informacjach tam zawartych, stwierdzenie braku wiedzy w przypadku, gdy kontekst nie zawiera odpowiedzi, oraz wskazanie tytułu lub sekcji źródła, jeśli to możliwe. Następnie podawane są pobraane dane oraz pytanie.
Te instrukcje są ważne, ponieważ model posiada ogólne wiedze we własnym zakresie. Bez jasnych wytycznych może łączyć uzyskane fakty ze swoimi własnymi założeniami. Czasami jest to do przyjęcia, ale w przypadku bota pomocniczego, asystenta prawniczego, narzędzia medycznego lub pomocnika w tworzeniu polityk model powinien trzymać się blisko dostarczonych mu dowodów.
Dokumentacja OpenAI dotycząca projektowania zapytań przedstawia RAG jako dodawanie istotnego kontekstu, pochodzącego z bazy danych wektorowej lub wyszukiwania plików, do żądania generowania treści. Sposób sformułowania ma znaczenie – określa on, że uzyskany tekst jest tym, na czym model powinien się opierać.
Dobrze napisane zapytanie radzi sobie również z niepewnością, pozwalając modelowi stwierdzić, że dostarczone dokumenty nie odpowiadają na pytanie. Taka odpowiedź jest mniej efektowna niż pewna domysł, ale znacznie bardziej przydatna.
Generowanie odpowiedzi
Teraz model językowy pisze ostateczną odpowiedź, tę część, którą faktycznie widzą użytkownicy. Powinna być jasna, uzasadniona i odpowiednio konkretna. Nie powinien przedstawiać surowego, pobranego tekstu bez prośby. Powinien wyjaśniać rzeczy w naturalnym języku, wspominać o ważnych ograniczeniach i cytować źródła, gdy to możliwe.
Dobry przykład: „Laptopy z renowacji muszą zostać zwrócone w ciągu 14 dni od dostawy. Zasady nie przewidują wyjątków dla zwrotów po 20 dniach, więc zgodnie z podanymi regulacjami zwrot złożony po 20 dniach nie będzie akceptowany.” To działa, ponieważ podaje zasadę, stosuje ją do sytuacji użytkownika i nie udaje, że istnieje wyjątek, gdy źródło go nie wskazuje.
Cytaty również dodają wartości, ponieważ umożliwiają użytkownikom weryfikację odpowiedzi, a nie tylko poleganie na modelu. Umożliwienie śledzenia odpowiedzi AI to jeden z największych praktycznych zalet RAG.
Ocena procesu
System typu RAG powinien zostać przetestowany, zanim ktokolwiek będzie na niego polegał. Powszechnym błędem jest sprawdzanie tylko ostatecznej odpowiedzi. Lepiej oceniać proces wyszukiwania i generowania oddzielnie: najpierw sprawdzić, czy mechanizm wyszukiwania znalazł odpowiednie fragmenty, a następnie, czy model je prawidłowo wykorzystał.
Prosty zestaw do oceny łączy rzeczywiste pytania użytkowników z poprawnymi fragmentami źródłowymi oraz oczekiwanymi odpowiedziami. Dla każdego pytania sprawdzić, czy wśród wyników wyszukiwania znajduje się odpowiedni dokument. Gdy właściwy fragment nigdy nie trafia do modelu, mało prawdopodobne jest uzyskanie wiarygodnych odpowiedzi.
Następnie przejrzeć wygenerowaną odpowiedź. Czy jest zgodna z kontekstem? Czy zawiera twierdzenia, których nikt nie popiera? Czy odpowiada na rzeczywiste pytanie i odwołuje się do właściwego źródła? Gdy dokumenty okazały się niewystarczające, czy system to przyznał?
Książka kucharska Claude RAG zaleca ocenę procesu pozyskiwania danych oraz całego systemu oddzielnie, unikając polegania na niejasnych wrażeniach dotyczących jakości odpowiedzi – to rada, której warto przestrzegać nawet przy małym projekcie.
Bazowy cykl oceny może obejmować:
- Dokładność pozyskiwania danych, czyli sprawdzenie, czy znaleziono właściwy fragment tekstu.
- Wierność, czyli określenie, czy odpowiedź jest poparta znalezionym kontekstem.
- Pełność, czyli sprawdzenie, czy obecne są ważne szczegóły.
- Jakość cytowania, czyli ocena, czy cytowane źródła są rzeczywiście istotne.
- Latencja, czas potrzebny na uzyskanie odpowiedzi.
- Koszt, liczba tokenów oraz wykonywanych zapytań o dane.
- Zadowolenie użytkownika, czyli sprawdzenie, czy problem został rozwiązany.
RAG rzadko jest doskonały od razu po pierwszej próbie. Ocena pokazuje, gdzie należy poprawić jakość – czy to w podziale na fragmenty, metadanych, procesie wyszukiwania, promptach, ponownym sortowaniu, czy w samych dokumentach źródłowych.
Gdzie popełniają błędy podstawowe procesy przetwarzania
Pierwsza wersja takiego procesu zazwyczaj działa na tyle dobrze, by być inspirująca, ale na tyle źle, by przyprawić o zakłopotanie. Typowe problemy to:
- Słaby podział na fragmenty. Wraca odpowiedni fragment, ale cała odpowiedź w nim nie znajduje się.
- Zakłócenia w procesie wyszukiwania. Zwracane są fragmenty, które wydają się powiązane, ale nie odpowiadają na pytanie, szczególnie gdy zapytanie jest szerokie, niejednoznaczne lub zawiera terminy występujące w wielu dokumentach.
- Przestarzałe informacje. Aktualizacje są łatwiejsze niż ponowne szkolenie modeli, ale tylko wtedy, gdy baza wiedzy jest aktualna. Stare dokumenty pozostawione w indeksie nadal mogą być odzyskiwane.
Prosta architektura
Projekt przyjazny początkującym działa w dwóch etapach. Na etapie indeksowania dokumenty są zbierane, oczyszczane, dzielone na fragmenty, wzbogacane embeddami i przechowywane w bazie wektorowej razem z oryginalnym tekstem oraz metadanymi. Na etapie odpowiadania pytanie użytkownika jest wzbogacane embeddami, wybierane są najbardziej istotne fragmenty, które opcjonalnie mogą być filtrowane lub ponownie sortowane, a następnie umieszczane w promptzie, dzięki któremu model językowy może udzielić odpowiedzi w oparciu o ten kontekst.
Mówiąc krótko: dokumenty stają się fragmentami, potem embeddami, a następnie są przechowywane w bazie wektorowej; pytanie zamienia się w embedd query, przechodzi przez mechanizm wyszukiwania w celu uzyskania kontekstu, a model językowy przekształca go w odpowiedź.
Frameworki takie jak LangChain i LlamaIndex dostarczają narzędzia do ładowania dokumentów, tworzenia indeksów i mechanizmów wyszukiwania oraz łączenia tych mechanizmów z modelami językowymi. Dokumentacja LangChain przedstawia proces wyszukiwania jako wykorzystywanie własnych baz wiedzy za pośrednictwem narzędzi do ładowania i magazynów wektorowych. LlamaIndex traktuje technologię RAG jako proces indeksowania danych z góry, dzięki czemu każde zapytanie może uzyskać istotny kontekst przed wywołaniem modelu językowego.
Aby to opanować, nie potrzeba skomplikowanego systemu. Mały prototyp wymaga zaledwie pięciu elementów: kilku dokumentów w folderze, modelu do generowania wektorów, miejsca na przechowywanie wektorów, mechanizmu wyszukiwania oraz modelu do rozmowy. Ważne jest zrozumienie każdego kroku i nie traktowanie całego procesu jako czarnej skrzynki.
Czym wyróżnia się dobry proces
Dobry pipeline robi więcej niż tylko pobiera tekst. Znajduje właściwy tekst, prezentuje go modelowi w użytecznej formie i dostarcza odpowiedź wierną dostępnym dowodom. Najlepsze systemy mają kilka wspólnych cech: czyste, aktualne źródła, staranne dzielenie tekstu na fragmenty, zachowywanie metadanych, wyszukiwanie zarówno według znaczenia, jak i dokładności w razie potrzeby, jasne instrukcje, cytaty, oddzielna ocena procesu wyszukiwania i generowania treści, ochrona danych wrażliwych przed dotarciem do modelu oraz umiejętność przyznania się do niewiedzy.
Dobry RAG to zatem coś więcej niż tylko funkcja sztucznej inteligencji. Łączy w sobie zarządzanie wiedzą, wyszukiwanie, projektowanie produktów oraz aspekty bezpieczeństwa.
Dalej co robić
Gdy prosty pipeline zacznie działać, dostępne są kilka ulepszeń:
- Dodanie hybrydowego wyszukiwania umożliwiającego znajdowanie informacji zarówno według znaczenia, jak i dokładnych terminów.
- Dodanie kroku ponownego sortowania, w którym drugi model sprawdza i uporządkowuje znalezione fragmenty tekstu.
Zaawansowane ustawienia umożliwiają wykorzystanie agentów, wyszukiwanie w kilku krokach lub za pomocą grafów, zapytania do strukturalnych baz danych, wyszukiwanie w obrazach i tekście lub narzędzia do ponownego rankowania dostosowane do konkretnego dziedziny. Ostatnie badania wskazują, że ten obszar przechodzi od prostych systemów RAG ku modułowym, w których wyszukiwanie, generowanie i ulepszanie są oddzielnymi, elastycznymi komponentami, a nie jednym stałym procesem. Mimo to podstawowy proces pozostaje fundamentem: znajdować istotne dowody, przekazywać je modelowi i sprawdzać poprawność odpowiedzi w oparciu o te dowody.
Dlaczego warto się tego nauczyć
RAG zyskało popularność, ponieważ odpowiada na praktyczną potrzebę. Przedsiębiorstwa, badacze, programiści oraz zespoły przechowują już cenne informacje w dokumentach, bazach danych, instrukcjach, zgłoszeniach i notatkach, a sam model językowy nie jest w stanie ich skutecznie poznać. RAG daje modelowi możliwość wyszukiwania tych informacji.
Sama metoda jest prosta: przygotowuje się dokumenty, dzieli je na części, wstawia i przechowuje te fragmenty, wybiera odpowiednie, a następnie model odpowiada na podstawie nich. Kluczowe są szczegóły – jakość źródeł, dzielenie na fragmenty, wyszukiwanie, projektowanie zapytań, ocena oraz bezpieczeństwo. Podstawowy proces nie stanowi ostatecznej formy inteligentnego asystenta, ale pozostaje jedną z najprostszych dróg do stworzenia AI, które jest bardziej przydatne, aktualne i lepiej uzasadnione. Zamiast wymagać od modelu bycia wszechwiedzącym orakulem, RAG daje mu „kartę biblioteczną” i uczy go efektywnego korzystania z biblioteki.
Literatura pokrewna
- Budowanie pipeline ETL do użycia w produkcji dla RAG przy użyciu LangChain i FAISS — Projektowanie procesów dzielenia na fragmenty, tworzenia embeddingów oraz indeksowania wektorowego dla 40 000 plików PDF z wymogami regulacyjnymi, wraz z mechanizmami ponawiania prób, kolejkami wiadomości nieudanych transakcji, metrykami Prometheus oraz mierzalnymi wskaźnikami wydajności.
- Praktyczne wskazówki: Budowanie nowoczesnego pipeline ISR dla modality kodowej w dużych systemach — Szczegółowy przewodnik po praktycznych wskazówkach dotyczących budowy nowoczesnego pipeline ISR dla modality kodowej w dużych systemach: umowy, sprawdzania oraz gotowe elementy kodu dostępne dla zespołów wdrażających ten model.