Mentionsy

Łukasz Szydło o RAG.

Dziś będziemy mówili o RAGU.

To na początku może tak trochę ogólnie, abstrakcyjnie, ale o co chodzi, jaki problem próbujemy przez takiego raga rozwiązać?

Co chwilę dochodzi nowa, co chwilę pojawiają się nowe zadania, co chwilę pojawiają się nowe wymagania, co chwilę pojawiają się nowe fragmenty kodu i tak dalej.

żeby ten LLM przeanalizował trochę wstępnie te teksty, te dokumenty i pokroił je na takie fragmenty, które mają generalnie sens.

Czyli jeżeli mamy jakieś prace naukowe, no to żeby być może na jakieś paragrafy je pokroił, być może wyciągnął już jakieś tam informacje o tym, gdzie najlepiej jest to robić.

Ale to nie cała strona jest o value objectie, tylko o value objectie jest pewien paragraf.

Więc to, co ty byś chciał zrobić, żeby twój LLM mógł ci opowiedzieć na temat value objectów, to ty byś chciał z tego Bluebooka wyciągnąć tylko te fragmenty stron, te paragrafy, które się rzeczywiście tyczą tylko tych value objectów.

i ewentualnie jakieś elementy z nimi powiązane, ale to niekoniecznie muszą być paragrafy, które są blisko siebie.

Więc jeśli ty podzielisz sobie Bluebooka właśnie takimi mniejszymi, na mniejsze czanki niż strony, czy niż w ogóle rozdziały, czy cała książka, to właśnie dzięki temu potem jesteś w stanie tak mocno jak podzielisz, tak drobno jak podzielisz, tak drobne kawałki jesteś w stanie z tego raga wyciągać.

I dzięki temu, właśnie jak podzielisz sobie na takie małe, to wtedy z tych małych fragmentów wrzucisz do tego kontekstu tylko te rzeczy, ostatecznie, czyli wyciągniesz z tego raga tylko te fragmenty, które się tyczą wali obiektów.

Czyli chcielibyśmy Bluebooka podzielić na fragmenty.

Z każdego takiego fragmentu zrobilibyśmy tak zwany embedding.

No właśnie, embednik to jest po prostu wektor, czyli ciąg, wektor w wielowymiarowej przestrzeni, czyli de facto haszujemy nasz fragment tekstu do jakiegoś wektora w przestrzeni po to, żeby później, kiedy mamy z każdego takiego fragmentu zrobiony taki wektor, te bazy danych, do których to wrzucamy, to są tak zwane wektorowe bazy danych i one się specjalizują w tym,

Czyli jeżeli mam fragment o agregacie, to ten fragment będzie wektorem, który będzie bardziej odległy niż fragment, który jest o value objectie.

Ale fragment na przykład o subdomenach będzie jeszcze bardziej odległy od nich obu.

A fragment lalki będzie w ogóle gdzieś indziej.

Możemy mieć bluebook po angielsku, możemy mieć w tłumaczeniu po polsku i jak weźmiemy ten sam paragraf przetłumaczony z angielskiego na polski i zrobimy z tego ten wektor, ten embedding, to one będą w miarę blisko siebie, tak?

Czyli ten fragment tekstu plus wektor.

I tak już przygotowany fragment tych danych zostaje wrzucony do kontekstu LLM-a, żeby ten mógł odpowiedzieć na źródłowe pytanie, które zostało zadane.

Dzięki temu zamiast wrzucać do LLM-a całą wielką książkę Erika Evansa, wrzucamy mu parę tylko paragrafów, które tyczą się dokładnie value objectów i niczego więcej.

plus też rzeczy związane z podsumowaniami, które kierują nas do, ale tutaj już zaczynamy przechodzić na powiedzmy taki drugi sposób realizacji tych realizacji ragów, bo to co sobie powiedzieliśmy tutaj to jest

Pewien, pewien pattern, tak jak mamy, nie wiem, CQRS-a, możemy go zarówno zaimplementować w .necie, jak i możemy go zaimplementować w Javie, możemy go zaimplementować na osobnych bazach danych, możemy zaimplementować go na jednej bazie danych, pewien ogólny wzorzec, który na różne sposoby można zaimplementować i podobnie jest w przypadku raga.

No to mam nadzieję, że zaraz o tym też porozmawiamy, ale właśnie, bo jeszcze przyszło mi do głowy, powiedziałeś o semantycznym dopasowaniu, czyli znaczeniowym, bo to generalnie o to chodzi, żeby to tym się różni od normalnego pokrojenia stron na paragrafy i wrzucenia do zwykłego SQL Servera czy innej baski i odpalenia na tym indeksowania do wyszukiwania full text searchem powiedzmy, że właśnie tu nie musimy użyć dokładnie tych słów, które zostały użyte w danym paragrafie, tylko chodzi konkretnie o to znaczenie, tak, że możemy zadać pytanie potem po swojemu

I drugim sposobem, taką alternatywą do tego, żeby właśnie robić embeddinki są tak zwane grafragi.

Czyli to, co robi grafrag, to ten grafrag, on właśnie próbuje zamienić ten tekst, który mamy, na graf wiedzy.

To są tak zwane grafragi.

I powiedzmy działa to trochę podobnie, ten pipeline przygotowywania takiego grafraga działa dosyć podobnie.

No ciekawe, tylko to tak jak mówisz, to już wymaga większej ilości wiedzy na temat samych tych informacji, które posiadamy na samym początku, no plus więcej pewnie pracy, żeby faktycznie te dane odpowiednio oporządzić przed wrzuceniem ich do bazy, bo to zrobienie wektorów z paragrafów po kolei, czy nawet bardziej logicznego podziału niż same paragrafy, to brzmi jednak prościej niż wyłuskanie o czym to jest i jak te CUS-ie między sobą i jakie mają relacje zanim nie wrzucimy ich dalej.

no to im będziemy mieli tych danych więcej, tym więcej będzie nas kosztowało zrobienie takiego raga.

A jeżeli chcielibyśmy sobie zrobić właśnie takiego graf raga, no to tej mocy obliczeniowej od LLM-a potrzeba jeszcze więcej.

Żeby Ci podać przykład, 10 tysięcy tokenów, czyli to jest około dziesięciostronicowy dokument, który jest przez ten pipeline grafragowy transformowany do tej właśnie...

Mówiłeś trochę o medycznych, tu mówiliśmy o książce Evansa, wspomniałeś w ogóle o tym, żeby sobie gadać z treścią lalki Prusa, a jakbyśmy to zawęzili do świadka programistycznego, czyli do raga na naszym codebase'ie.

A czekaj, wtedy właśnie taki rag, jeśli pominiemy tą naszą nieaktualną dokumentację, to on może być aktualną dokumentacją, która tworzy się na bieżąco na podstawie stanu faktycznego.

AI-owych, które, żeby wygenerować dla nas, nie wiem, jakąś speckę, jakieś wymagania, czy nawet fragmenty kodu, które mają być, to one też potrzebują wiedzieć, ok, to który z tych fragmentów kodu jest dla mnie istotny, żebym ja sobie go wrzucił do kontekstu, żebym na podstawie jego mógł sobie to zrobić.

Ale to, kogo on może właśnie sobie zapytywać, to może sobie zapytywać takiego raga,

który zwróci mu te fragmenty kodu, które są dla niego istotne.

Więc reklama reklamą, ale też jakby tym samym mówimy, że wiesz o czym mówisz i o czym będziesz mówił dalej, bo w sumie teoria ragów była najpierw teraz wchodzimy bardziej w zakres specjalizacji i ekspertyzy Twojej aktualnej.

do standardowej formy go rozpisać, tak żebyśmy mieli drzewko, które nam pokazuje, jakie są relacje między poszczególnymi fragmentami.

W zależności od tego, jak dużo tych metadanych dokładamy do tego naszego fragmentu kodu.

on jest w stanie znaleźć te fragmenty kodu, które odpowiadają za rabatowanie, wrzucić je sobie do kontekstu, a następnie przeanalizować je i wypluć bardzo ładny opis, który mówi, twoje rabatowanie działa w taki sposób, być może nawet jest w stanie wygenerować jakiś diagram sekwencji, który to opisuje.

Czyli żeby wziąć jakiś większy fragment kodu, odpowiedniego poszatkować i zrobić z niego te embeddingi naszymi elemami.

Więc jestem w stanie wyciągnąć dokładnie te fragmenty kodu, które są realizowane w tym jednym konkretnym use case'ie.

Czyli kiedy my już wiemy, które elementy są istotne, które warto jest opisywać, bo po co mi jest na przykład opis, po co mi wysłać do LLM-a kod mapera, który mapuje mi, prawda, jeden fragment kodu na drugi kod.

Albo jakiegoś takiego nieistotnego fragmentu związanego z nie wiem, z jakąś tam serializacją, albo podobnymi rzeczami.

Więc to, co my zrobiliśmy, to my właśnie przeanalizowaliśmy ten fragment tworzenia tych ragów w taki czysto AI-owy, LLM-owy i myśleliśmy, kurczę, w przypadku kodu my moglibyśmy to zrobić lepiej.

Myślę, że tam pod spodem też może siedzieć jakiś mini-rag, który to analizuje.

Właśnie, więc też jakiegoś raga musi mieć.

Znaczy wiesz, podejrzewam, że ty też, tak samo jak i ja i pewnie większość naszych słuchaczek i słuchaczy mają doświadczenie z tą pierwszą linią supportu na różnego rodzaju infoliniach, gdzie też są pewnie wpięte różne systemy typu RAG i przez te pieprzone boty nie da się przebić do tego człowieka wyoutsourcowanego, który też nic nie wie i dopiero on musi do tej trzeciej linii supportu nas przełączać.

Ona ma być taką ogólnie informacyjną, taką, że jak ktoś się przygotowuje na spotkanie ze mną, to nie przychodzi na nie zielony, tylko jest się w stanie trochę odpytać tego raga, albo tego czata, albo nawet przeczytać na wiki te dokumentacje, które ja wygenerowałem, żeby on chociaż przyszedł już z jakąś wiedzą, a nie, że mamy godzinne spotkanie i ja przez pół godziny...

Albo nawet zawołać kogoś i wytłumacz mi, jak ten twój fragment, twój mikroserwis działa, żebym mógł się z nim zintegrować.

My jako DevStyle mieliśmy jedną taką publiczną przygodę właśnie z Ragiem i to robił nasz wspólny znajomy Tomek Stolarczyk nam.

W takim razie, gdyby rag był jakimś utensylium kuchennym, naczyniem, narzędziem, to czym by był?

Mamy nadzieję, że z tej rozmowy dowiedzieliście się, co to jest RAG, gdzie warto go stosować, jak do tego mniej więcej podejść oraz w kontekście programistycznym, do czego może być przydatne i na co uważać.