Strona główna / Artykuły / Dlaczego wywołanie LLM nie jest aplikacją: jakie miejsce zajmuje LangChain w pipeline’u RAG

Dlaczego wywołanie LLM nie jest aplikacją: jakie miejsce zajmuje LangChain w pipeline’u RAG

Dowiedz się, co tak naprawdę robi LangChain, śledząc aplikację do odpowiadania na pytania w dokumencie od przesłania pliku PDF do uzyskania konkretnej odpowiedzi, i zobacz, kiedy inna platforma sprawdzi się lepiej.

2551 słów

Zawołanie dużego modelu językowego jest proste: wysyła się prompt, a w odpowiedzi otrzymuje się tekst. Stworzenie czegoś przydatnego na podstawie tego wywołania nie jest takie łatwe. Prawdziwa aplikacja musi przetwarzać dokumenty, znajdować istotne fragmenty, śledzić przebieg rozmowy, komponować prompty oraz prezentować to wszystko za pośrednictwem interfejsu, a model jest zaledwie jedną z tych elementów. Ten artykuł wyjaśnia, czym jest LangChain, omawiając dokładnie tę całą infrastrukturę, używając jako przykładu asystenta do czytania dokumentów. Po jego przeczytaniu powinieneś być w stanie opisać każdy etap procesu pozyskiwania informacji, wskazać, które zadania framework taki jak LangChain przejmuje za Ciebie, oraz ocenić, czy on, czy jedna z jego alternatyw pasuje do Twojego projektu.

Czym jest LangChain, w jednym akapicie

LangChain to framework o otwartym kodzie służący do tworzenia aplikacji w oparciu o modele językowe. Zamiast dostarczyć gotowy model, oferuje modułowe elementy budulcowe oraz kompletny zestaw narzędzi do obsługi wszystkich komponentów związanych z modelem: szablony promptów, parserzy wyników, narzędzia do ładowania dokumentów, mechanizmy wyszukiwania informacji, pamięć, różne narzędzia oraz elementy łączące je ze sobą. Działa z najważniejszymi dostawcami modeli, integruje się z szerokim wyborem narzędzi od firm trzecich, jest dostępny bezpłatnie i znajduje się w fazie aktywnego rozwoju. Do typowych aplikacji tworzonych przy użyciu tego narzędzia należą chatboty, systemy odpowiadające na pytania, generatory wzbogacone o dane z zewnętrznych źródeł (RAG) oraz autonomiczne agenty.

Kluczową zmianą w sposobie myślenia jest to, że LangChain nie jest samym modelem językowym. Jest to warstwa, która umożliwia modelowi językowemu współpracę z twoimi danymi, promptami oraz użytkownikami. Jeśli wysyłasz tylko jeden prompt i wyświetlasz odpowiedź, nie potrzebujesz go. W momencie, gdy twoja aplikacja ma kilka kroków, zaczynasz korzystać z mechanizmów już dostarczanych przez LangChain.

Mapa obszaru

Pomaga spojrzeć na cały obraz przed przybliżeniem. Nauka LangChain zazwyczaj dzieli się na trzy obszary, z których każdy opiera się na poprzednim.

Zasady podstawowe

To elementy, z którymi ma do czynienia każda aplikacja oparta na LangChain:

  • ogólny model komponentów
  • modele, czyli otoczenia dla API do rozmów i uzupełniania tekstu
  • prompty oraz szablony promptów
  • parsowanie wyników, dzięki czemu tekst w formie wolnej staje się danymi strukturyzowanymi
  • Runnables oraz język wyrażeń LangChain (LCEL), warstwa kompozycji
  • łańcuchy, które łączą poszczególne kroki w proces pracy
  • pamięć, służąca do przechowywania kontekstu pomiędzy kolejnymi krokami
  • Generowanie wzbogacone o wyszukiwanie informacji

    RAG to sposób na umożliwienie modelowi odpowiadania na pytania na podstawie własnych dokumentów. Istotne komponenty to:

    • ładowniki dokumentów
    • dzielacze tekstu
    • embeddingi
    • magazyny wektorów
    • narzędzia do wyszukiwania informacji
    • łączenie wszystkich powyższych elementów w działającą aplikację RAG

    Agenci

    Agenci pozwalają modelowi decydować, jakie działania należy podjąć. Tematy poruszane w tym kontekście to:

    • narzędzia i zestawy narzędzi
    • wywoływanie narzędzi
    • tworzenie agenta, który je wykorzystuje

    Pozostała część tego artykułu koncentruje się na pierwszych dwóch obszarach, ponieważ one wyjaśniają, dlaczego w ogóle istnieje ten framework.

    Problem, który rozwiązuje LangChain

    System LLM produkcyjny rzadko składa się z jednego żądania. Spójrz, co musi obsłużyć nawet skromny asystent:

    • przyjmowanie dokumentów
    • wykonywanie wyszukiwania semantycznego
    • generowanie i przechowywanie embeddingów
    • wykonywanie generacji wzbogaconej o wyniki wyszukiwania
    • zarządzanie kontekstem i stanem rozmowy
    • koordynowanie jednego lub więcej wywołań LLM
    • dostarczanie interfejsu do czatowania

    Każda z tych funkcji może być obsługiwana osobno. Gdy są łączone ręcznie, tworzą plątaninę dostosowanego kodu, w której zmiana modelu, magazynu wektorów lub formatu promptu oznacza konieczność edycji kilku plików. Zaletą LangChain jest to, że zapewnia standardowy interfejs oraz zestaw ponownie używalnych abstrakcji dla każdej z tych funkcji, dzięki czemu elementy łączą się w spójny proces i można je niezależnie wymieniać.

    Przykład zastosowania: czytnik książek oparty na AI

    Rozważmy aplikację, w której użytkownicy przesyłają książki lub pliki PDF, czytają je w wbudowanym czytniku i zadają asystentowi pytania na temat tego, co czytają. Wyobraźmy sobie podręcznik z zakresu uczenia maszynowego: student może pytać o kompromis między błędem a wariancją, jak jest zbudowana określona architektura sieci CNN, co robi backpropagacja, jak działają mechanizmy uwagi lub który algorytm optymalizacji nadaje się do rozwiązania danego problemu.

    Asystent może dobrze odpowiedzieć tylko wtedy, gdy zobaczy właściwe strony. Ten jeden wymóg pociąga za sobą cały łańcuch działań: załaduj plik przesłany przez użytkownika, znajdź fragmenty istotne dla pytania, utrzymaj spójność historii rozmowy, stwórz prompt łączący pytanie z tymi fragmentami i prześlij go do modelu.

    W tej aplikacji LangChain zajmowałby się:

    • załadunkiem i analizą przesłanych dokumentów
    • połączeniem interfejsu rozmowy z modelem LLM
  • zarządzanie szablonami promptów
  • przechowywanie kontekstu rozmowy pomiędzy pytaniami
  • budowa pipeline'u do wyszukiwania, który wybiera odpowiedni tekst
  • To najjaśniejszy przykład tego, dlaczego sam model LLM nie stanowi aplikacji. Model zapewnia umiejętności językowe; wszystko, co sprawia, że odpowiedź dotyczy konkretnej książki, pochodzi z komponentów wokół niej.

    Szukanie semantyczne: znajdowanie tekstu według znaczenia

    Podstawą czytnika książek jest umiejętność wybierania odpowiednich fragmentów z dużej kolekcji. Szukanie według słów kluczowych ma tu trudności, ponieważ pytania ucznia rzadko używają tych samych słów co podręcznik. Szukanie semantyczne rozwiązuje ten problem za pomocą embeddingów: wektorów liczbowych, które umieszczają fragmenty tekstu o podobnym znaczeniu blisko siebie w wysoko wymiarowym przestrzeni. Wyszukiwanie polega więc na znalezieniu przechowywanych wektorów najbliższych wektorowi pytania.

    Prosty przykład

    Załóżmy, że zapytanie brzmi „Jaka jest stolica Francji?”. System wyszukiwania semantycznego nie szuka dokumentów, które jedynie dzielą się słowami z pytaniem. Szuka fragmentu o znaczeniu najbliższym temu zapytaniu, czyli akapitu o Paryżu, a nie fragmentów o Berlinie lub Madrycie, mimo że te również omawiają stolice europejskie i mogłyby uzyskać wysokie wyniki dzięki wspólnym słowom.

    To jest praktyczna różnica. Silnik oparty na słowach kluczowych sortuje według pokrywających się terminów; silnik semantyczny natomiast według bliskości znaczeń. W praktyce wiele systemów produkcyjnych łączy oba podejścia, ponieważ dokładne terminy, takie jak kody produktów czy komunikaty błędów, nadal korzystają z dopasowywania słów kluczowych.

    Dlaczego to ma znaczenie dla aplikacji opartych na LLM

    Modele odpowiadają znacznie lepiej, gdy otrzymują odpowiedni kontekst. Dlatego dobra funkcja wyszukiwania prowadzi bezpośrednio do:

    • lepszego wyszukiwania dokumentów
  • dokładniejsze odpowiedzi
  • mądrzejsze rekomendacje
  • asystenci, które odpowiadają z uwzględnieniem treści użytkownika
  • LangChain sam nie wdraża wyszukiwania wektorowego. Integruje się z elementami niezbędnymi do jego realizacji: modelami embeddingów, bazami danych wektorowych, narzędziami do wyszukiwania oraz funkcjami porównywania podobieństwa, wszystkie dostępne poprzez spójne interfejsy.

    Gdy dokumenty stają się dostępne do wyszukiwania, odpowiadanie na pytanie odbywa się zgodnie z przewidywalną sekwencją:

    • Użytkownik zadaje pytanie. Pytanie przychodzi w języku naturalnym.
    • Pytanie jest przekształcane na wektor. Jest ono zamieniane na wektor, aby można je było porównywać pod względem znaczenia, a nie dokładnych słów.
    • Pobierany jest istotny tekst. System ściąga fragmenty lub strony, których wektory są najbliższe.
    • Dane wejściowe są zestawione. Pobrane fragmenty tekstu oraz oryginalne pytanie łączą się w prompt przeznaczony dla modelu.
    • Model je przetwarza. Kompletny prompt, wraz z kontekstem i pytaniem, trafia do LLM.
    • Otrzymujemy uzasadnioną odpowiedź. Ponieważ model wyciąga wnioski na podstawie dostarczonego tekstu, a nie tylko pamięci, odpowiedź jest dokładniejsza i łatwiejsza do odniesienia do źródła.

    Każda strzałka na tej liście reprezentuje przekazanie danych pomiędzy komponentami, a właśnie to ma za zadanie zarządzać LangChain. Uproszcza proces pozyskiwania informacji, łączy ze sobą poszczególne kroki generowania promptów, obsługuje pamięć, wprowadza kontekst do promptów oraz koordynuje wywołania modelu. Ten sześcioskładnikowy proces stanowi istotę każdego systemu RAG. Jeśli chcesz lepiej zrozumieć sam proces pozyskiwania informacji, nasz artykuł wyjaśniający, w jaki sposób RAG pozyskuje aktualną wiedzę omawia to bardziej szczegółowo.

    Pełna architektura RAG

    Sześć wymienionych powyżej kroków zakłada, że dokumenty są już zindeksowane. Kompletny system składa się z dwóch pipeline’ów: jednego, który przygotowuje dokumenty z wyprzedzeniem, oraz drugiego, który odpowiada na zapytania w momencie ich wysłania.

    Przygotowanie dokumentów do wyszukiwania

    Zanim ktoś będzie mógł zadać pytanie, każdy dokument musi zostać przekształcony w coś, co można wyszukiwać:

    • Zapisz plik. PDF trafia do systemu przechowywania, na przykład do pojemnika AWS S3.
    • Załaduj plik. Narzędzie do ładowania dokumentów odczytuje plik i wydobywa z niego tekst do dalszej obróbki.
    • Rozdziel tekst. Narzędzie do dzielenia tekstu podziela go na mniejsze fragmenty lub strony. Jest to istotne, ponieważ umieszczenie całej książki jako jednego wektora spowodowałoby zatarcie wszystkich jej tematów, a modele mają ograniczone okna kontekstowe.
    • Wbuduj wektory. Każdy fragment przechodzi przez model do tworzenia wektorów i staje się wektorem.
    • Zapisz wektory. Wektory wraz z tekstem, który reprezentują, są zapisywane w bazie danych wektorowej.

    Na końcu tego etapu dokument jest gotowy do wyszukiwania. Zazwyczaj proces ten odbywa się raz na każdy zapis pliku, a nie przy każdym pytaniu.

    Odpowiadanie na zapytanie

    Gdy przychodzi pytanie, uruchamia się drugi proces:

    • Zawieranie zapytania. Pytanie jest przekształcane w wektor za pomocą tego samego modelu embeddingowego, dzięki czemu znajduje się w tym samym przestrzeni co przechowywane fragmenty.
    • Szukanie. Szukanie podobieństw znajduje fragmenty najbliższe pytaniu.
    • Pobieranie kontekstu. Te fragmenty są pobierane z bazy danych wektorowej.
    • Budowanie promptu. Pobrany tekst oraz pytanie użytkownika są łączone w prompt systemowy.
    • Wezwanie modelu. Gotowy prompt jest wysyłany do API LLM.
    • Odpowiedź. Model zwraca odpowiedź opartą na pobranych materiałach.

    Jeden szczegół, który sprawia trudności początkującym: zapytanie i dokumenty muszą być embedowane za pomocą tego samego modelu. Wektory z dwóch różnych modeli embeddingowych nie są porównywalne, a ich bezpośrednie łączenie pogarsza jakość wyszukiwania.

    To, co sami byś napisali

    Bez frameworka zespół tworzący takie rozwiązanie musiałby samodzielnie zajmować się zarządzaniem zapytaniami, logiką wyszukiwania, wstrzykiwaniem kontekstu, łańcuchami wieloetapowymi, pamięcią, integracją narzędzi oraz koordynacją wszystkich tych elementów. Żadna z tych czynności nie jest konceptualnie trudna, ale łącznie sprawiają one dużą pracę i zwykle powodują silne powiązanie kodu z konkretnym modelem i bazą danych. Reutilizowalne abstrakcje LangChain umożliwiają szybsze budowanie rozwiązań oraz łatwiejszą późniejszą modyfikację komponentów z mniejszą ilością przerabianego kodu.

    To, co oferuje framework

    Cztery korzyści pojawiają się wielokrotnie.

    Łańcuchy jako model kompozycji

    Łańcuch połączeń łączy takie elementy jak szablon zapytania, wywołanie modelu oraz parser wyników w jeden spójny proces pracy, który można uruchomić, przetestować i ponownie wykorzystać. W obecnych wersjach jest to realizowane za pomocą Runnables i LCEL, które umożliwiają łączenie poszczególnych komponentów.

    Kod niezależny od modelu

    Ponieważ LangChain obsługuje głównych dostawców LLM poprzez wspólną interfejs, twoja aplikacja nie jest przywiązana do jednego dostawcy. Zmiana modelu polega wtedy na modyfikacji konfiguracji, a nie na przepisywaniu kodu, co jest przydatne zarówno pod względem kontroli kosztów, jak i testowania nowszych modeli.

    Szeroki ekosystem

    Framework dostarcza lub łączy się z dużym zestawem komponentów i integracji: narzędzi do ładowania różnych typów plików, wielu magazynów wektorowych, dostawców embeddingów oraz odpowiednich narzędzi. Większość potrzebnych elementów prawdopodobnie już istnieje w postaci gotowych integracji.

    Pamięć i stan

    Aplikacje konwersacyjne muszą pamiętać to, co zostało powiedziane wcześniej. LangChain oferuje sposoby zarządzania kontekstem konwersacji, pamięcią oraz stanem w trakcie różnych interakcji. Zalecane podejście zmieniało się w kolejnych wersjach – nowsze wytyczne skupiają się na użyciu LangGraph do zautomatyzowanych procesów wymagających przechowywania stanu, dlatego sprawdź aktualną dokumentację dostosowaną do swojej wersji.

    Czego możesz stworzyć za pomocą tego narzędzia

    Powszechne typy aplikacji to:

    • Chatboty konwersacyjne, w których użytkownicy rozmawiają z AI w języku naturalnym.
    • Asystenci wiedzy, którzy pomagają ludziom znajdować i rozumieć informacje w ich własnych dokumentach lub bazach wiedzy.
    • Agenci AI, które realizują zadania wieloetapowe i decydują, jakie narzędzia wykorzystać w danym momencie.
    • Autoryzacja procesów, w której LLM stanowi jeden z etapów większego, zautomatyzowanego procesu.
  • Narzędzia do streszczania i przeprowadzania badań, które skracają materiał i wspomagają badania.
  • Kiedy rozważyć alternatywę

    LangChain to jedna z kilku opcji, a każda alternatywa ma swój własny nacisk:

    • LlamaIndex skupia się głównie na łączeniu modeli LLM z danymi zewnętrznymi oraz tworzeniu aplikacji opartych na danych i RAG.
    • Haystack jest przeznaczony do wyszukiwania, odpowiadania na pytania, aplikacji RAG oraz agentowych.
    • Semantic Kernel to SDK o otwartym kodzie od Microsoftu, które włącza modele AI do istniejącego oprogramowania i koordynuje wieloetapowe procesy AI.
    • DSPy traktuje systemy LLM jako programy do optymalizacji, zamiast wymagać ręcznego tworzenia każdego promptu.
    • AutoGen jest opracowany dla aplikacji, w których kilka agentów współpracuje i komunikuje się ze sobą.
    • CrewAI służy do koordynacji zespołów agentów pracujących razem nad zadaniami.
    • PydanticAI to framework w Pythonie przeznaczony do aplikacji produkcyjnych oraz agentów generujących ustrukturyzowane, bezpieczne pod względem typów wyniki.

    Ogólne prawidło: jeśli twoja aplikacja polega głównie na wyszukiwaniu danych we własnych zasobach, warto porównać LlamaIndex i Haystack. Jeśli najważniejsze są dla ciebie typowane wyniki, rozważ PydanticAI. Jeśli chcesz, aby centralną koncepcją była współpraca wielu agentów, odpowiednie będą AutoGen lub CrewAI. Zaletą LangChain jest szeroki zakres możliwości, co czyni go rozsądnym wyborem domyślnym, gdy jeszcze nie jesteś pewien, jak będzie wyglądać twoja aplikacja. Aby porównać dwa najpopularniejsze rozwiązania, zapoznaj się z naszym porównaniem LangChain i LlamaIndex.

    Warto również wiedzieć, kiedy nie należy korzystać z żadnego frameworka. Funkcja oparta na jednym promptzie lub mały skrypt z jedną wywołaniem modelu i ręcznie napisanym promptem często są jaśniejsze bez warstwy abstrakcji. Frameworki okazują się przydatne, gdy liczba kroków i wymiennych komponentów rośnie.

    Bazy wiedzy do nauki dalej

    Gdy już mamy ogólny obraz sytuacji, naturalnym następnym krokiem są poszczególne komponenty, z których składa się każde aplikacje LangChain:

    • Modele – interfejsy służące do komunikacji z różnymi modelami AI.
    • Prompty – elementy, które wpływają na to, w jaki sposób model reaguje na dane wejściowe.
    • Łańcuchy – elementy łączące komponenty w procesy pracy.
    • Indeksy – elementy łączące aplikacje z zewnętrzną wiedzą. Nowsza dokumentacja często opisuje tę dziedzinę w kategoriach ładowarek, magazynów wektorowych i narzędzi do ich wyszukiwania.
  • Pamięć, która przechowuje kontekst między interakcjami.
  • Agenci, które łączą rozumowanie z narzędziami w celu wykonywania zadań.
  • Zrozumienie tego, za co jest odpowiedzialny każdy z tych elementów, znacznie ułatwia czytanie kodu LangChain oraz decydowanie o tym, które komponenty są rzeczywiście potrzebne w Twojej aplikacji.

    Główne wnioski

    • LLM to tylko jeden z komponentów aplikacji; ładowanie danych, wyszukiwanie, tworzenie promptów, pamięć oraz interfejs to wszystko inne, a właśnie przy budowie tego „wszystkiego innego” pomaga LangChain.
    • Szukanie semantyczne sortuje teksty według znaczenia przy użyciu embeddingów, dlatego znajduje akapit o Paryżu na pytanie dotyczące stolicy Francji.
    • System RAG składa się z dwóch pipeline’ów: jednego offline, który ładuje, dzieli, wstawia i przechowuje dokumenty, oraz drugiego online, który wstawia zapytanie, pobiera kontekst, buduje prompt i wywołuje model.
    • Zawsze należy wstawiać zapytania i dokumenty za pomocą tego samego modelu, w przeciwnym razie jakość wyszukiwania spada.
    • Główne zalety LangChain to kompozycja oparta na łańcuchach, niezależność od dostawców, szeroki ekosystem integracji oraz narzędzia do zarządzania stanem i pamięcią.
    • Aльтernatywy takie jak LlamaIndex, Haystack, Semantic Kernel, DSPy, AutoGen, CrewAI i PydanticAI kładą nacisk na różne aspekty, a bardzo prosta funkcjonalność może w ogóle nie wymagać żadnego frameworka.

    Literatura pokrewna

  • Piętnaście koncepcji LLM prześledzonych przez jedną prośbę botu podpierającego — Prześledź jedno pytanie klienta za pośrednictwem asystenta AI, aby dowiedzieć się, co tak naprawdę robią modele, tokeny, embeddingi, kontekst, RAG, agenci oraz metody oceny, i gdzie kończy się działanie każdego z nich.