DevTalk #130 – O RAG do Eksploracji Kodu z Łukaszem Szydło

Dzień dobry, nazywam się Maciej Aniserowicz i zapraszam was serdecznie na kolejny odcinek podcastu DevTalk. Dziś z nami wyjątkowy gość i bardzo ciekawy temat. Łukasz Szydło o RAG. Przed tobą DevTalk. Programistyczny głos w twoim domu. Cześć Łukasz. Cześć Maciej. Powiedz, please, na samym początku, proszę tak każdego od jakiegoś czasu, powiedz, proszę, kilka słów o sobie, żebyś to ty się przedstawił, a nie ja ciebie, to może będzie bardziej szczerze. Oj, no, na początku ostro. No, jestem w sumie architektem, konsultantem, trenerem.

Dziś będziemy mówili o RAGU. Zgadza się. Rozwiń proszę ten skrót na początku. Zacznijmy może z takiego popłapu, zakładając, że niektórym osobom to się obiło o uszy, ale w sumie nie bardzo wiedzą, co to jest. A później przejdziemy do rzeczy, które także starzy wyjadacze powinni znaleźć jako interesujące. Zanglicyzuję. Zanglicyzujesz? Spoko. RAC, czyli Retrieval Augmented Generation, to jest technika, która pozwala na dostosowywanie tego, co w danym momencie powinniśmy wrzucić do kontekstu naszego LLM-a. To na początku może tak trochę ogólnie, abstrakcyjnie, ale o co chodzi, jaki problem próbujemy przez takiego raga rozwiązać?

Mrząbuk Ewansa, kurczę, że w okulskim dzień zacząć mówić o tym do Blue Booka Ewansa, ale dobrze, niech będzie. Załóżmy, że masz Blue Booka Ewansa, no i ty byś chciał tylko i wyłącznie dowiedzieć się czegoś na temat value objectów. I na końcu masz indeks, prawda? Zawsze na końcu książki masz indeks, który mówi, o, value object, taki klucz, na których stronach to on jest. I będziesz widział, że value object jest tam na 17 stronach włączonych. 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. I dzięki temu zetwórzesz dwie rzeczy. Pierwsza, twój kontekst staje się krótszy, więc mniej płacisz. za LLM-a, bo zużywasz mniej tokenów, a druga, jest też mniejsza szansa na halucynacje, dlatego, że on ma w sobie tylko te dane, które rzeczywiście dotyczą się tematu, który ciebie interesuje, czyli tylko tych value objectów. Można by zrobić wtedy tak, że drogi LLM-ie, zapomnij wszystko, co wiesz na temat value objectów, co sobie wyczytałeś z internetu, Tutaj masz wszystko, co powinieneś wiedzieć, bo interesują nas wyłącznie informacje z tej książki.

raczej, może być tak, rach powinniśmy traktować jako pewien wzorzec, który może mieć wiele różnych implementacji. 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. Jakby jego cel jest zawsze taki sam, najmniej te dane, które są związane z moim kontekstem, z jakiegoś dużego zbioru danych, ale możemy to robić na różny sposób, dlatego że tutaj te bazy danych wektorowe, one mają pewną wadę, a mianowicie właśnie taką, że one nie są za bardzo taki kontekst, wrażliwe na kontekst.

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. A tokeny lecą. A tokeny lecą, nie? Ż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... bazy wiedzy, na takim lepszym modelu, bo żeby mieć w miarę dobre wyniki, no to możemy użyć małych, tanich modeli, ale na nich te wyniki są średnie, no to to jest na tym takim dobrym, lepszym modelu to jest około 3,5 dolara.

Albo mamy bardzo dobre rezultaty, ale nas to bardzo dużo kosztuje, przez to, że musimy używać tych najlepszych modeli, które zżerają nam dużo tokenów i rezultaty wychodzą dobre, albo chcemy mieć rozwiązanie, które jest trochę bardziej oszczędne, ale wtedy musimy się pogodzić z tym, że jakość może być o drobne niż. Okej, to mówiliśmy na razie o takich zastosowaniach, można powiedzieć, że ogólnych. 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. Tak, to jest element, czy rozwiązanie, które jest używane bardzo często, dlatego że tutaj właśnie mamy ten problem. W jaki sposób zbudować, jeżeli mamy jakiegoś LLM-a, który generuje nam kod, czy który opisuje nam kod, czy w jakikolwiek sposób wchodzi w interakcję z naszym kodem, no to często nasze bazy kodu są większe niż okno kontekstowe.

Tak, to są wszystko takie dane, tylko musimy się mocno zastanowić, które dane są dla nas najistotniejsze. Na przykład, jakiej jakości jest nasza dokumentacja, którą aktualnie mamy. Czy to jest dokumentacja, która rzeczywiście jest aktualna i my chcemy, żeby ona była źródłem wiedzy dla naszego LLM-a? Czy to jest dokumentacja, która opisuje stan rzeczy sprzed dwóch miesięcy, czterech miesięcy, pół roku, bo nikt tego na bieżąco nie aktualizuje. 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. Może być, może być i generalnie do tego dążymy, nawet nie tylko dokumentacją, ale też generalnie źródłem wiedzy na temat naszego CodeBase'u, na temat naszej bazy kodu, która może być wykorzystywana zarówno do tego, żeby zadawać pytania i mieć informacje na temat tego, jak ten system aktualnie działa, ale też, żeby budować kontekst dla agentów.

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ć. I w niektórych narzędziach, w niektórych pluginach ręcznie jest to robione, że mówimy mu, dobra, weź, zwróć uwagę na ten plik, na ten plik, na ten plik, na ten plik, weź uwagę na tą metodę, na tą metodę. W części jest to robione w sposób automatyczny, że my tego nie widzimy. Mówimy mu tylko, weź tam, napisz mi specke dla takiego i takiego feature'a z takimi i takimi rzeczami i on to robi pod spodem i widzimy, co on robi. Nie widzimy, co on tam sobie zapytuje. Ale to, kogo on może właśnie sobie zapytywać, to może sobie zapytywać takiego raga,

Ja od jakiegoś czasu, nie wiem czy się bawiłeś, ale od jakiegoś czasu bawię się Cloud Codem od jakichś trzech tygodni i wrzucam to w różne codebazy i zadaję mu pytania, na przykład kto pracuje w projekcie i jest najlepszym tutaj programistą i tak dalej, albo to jest największym wyzwaniem i on... Bardzo fajnie to robi, bo on pokazuje, jakich komend używa. Na przykład bierze sobie ostatnie 100 komitów z Gita, analizuje komit messages, analizuje, co tam się zmieniało i faktycznie jego odpowiedzi są bardzo fajne. Więc to jest taki, jak to nazwać, rak dla ubogich? Też nie ubogich, bo tam też to konie lecą. Myślę, że tam pod spodem też może siedzieć jakiś mini-rag, który to analizuje. Wątpię, żeby on za każdym razem do kontekstu wkładał absolutnie wszystko, raczej ten agent. Wszystko nie, on sobie wybiera pliczki, które są lokalnie, on to jakoś selektywnie robi, nie wrzuca całego codebase'u.

Właśnie, więc też jakiegoś raga musi mieć. W każdym razie polecam do pobawienia się, jeśli ktoś jest zainteresowany, jak to w ogóle może wyglądać. No i właśnie... Ale to propos Cloda. Wiesz, czym eksperymentujemy? Eksperymentujemy z tym, żeby na podstawie tego grafu wiedzy, który mamy, generować ClodMD pliki dla poszczególnych modułów, żeby właśnie miał jeszcze więcej informacji na temat tego, co się w danym module dzieje. Okej, żeby za każdym razem nie musiał tego od nowa analizować. Dokładnie, żeby dodać mu dodatkową informację na temat, co tutaj jest i takie automatyczne generowanie tych plików MD to też jest coś, co mamy na swojej roadmapie. Takiemu zwykłemu programiście czy programistce do czego to może być potrzebne?

Gdybyśmy mogli tę wiedzę wyciągnąć i dać im na zewnątrz, to mamy pierwszą linię supportu. 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ć. Dlatego jest kwestia jakości. Więc w sumie teraz pewną specjalizacją jest przebijanie się przez tą pierwszą linię supportu właśnie. Dlatego jest kwestia jakości. Ja mam doświadczenie różne. Mam takie doświadczenie właśnie, kiedy w końcu wyjdę z tego flowu AI-owego i się do jakiegoś konsultanta dobiorę. Ja ciągle wciskam to zero w telefonie, jeszcze nie słucham, nie czekam, aż skończę gadać. Właśnie, tak.

Ale czasami rzeczywiście zdarzają się takie, które na jakieś tam proste pytanie potrafią odpowiedzieć. I teraz chodzi o to, żeby taki rak nie odpowiedział na wszystkie pytania. On nie ma być pierwszą, drugą i trzecią linią supportu. On ma być tą pierwszą. 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... jak coś działa, żebyśmy w ogóle mogli przejść do takiego drugiego elementu wymyślania czegoś. Niekoniecznie osoba z innego działu, to może być też nowa osoba w zespole, czyli onboarding może być o wiele łatwiejszy, ponieważ zamiast poświęcać dwa tygodnie na przechodzenie wspólnie po kodzie i siedzenie w tym ID,

O, dobra. W takim razie, gdyby rag był jakimś utensylium kuchennym, naczyniem, narzędziem, to czym by był? Kurde. Kukidu z Thermomixa. Ale cię zagiął. Wy tego nie widzicie, ale widzę minę Maćka teraz. A powtórz to. Jest takie narzędzie do gotowania, które się nazywa Thermomix. To jest taka... To wiesz, co to jest. Miska z mieszadłem. I ta miska z mieszadłem ma taki ekran, który pozwala ci wyszukiwać przepisy. I potem prowadzi cię krok po kroku, jak te przepisy wykonywać. I to się nazywa... Ta przystawka, która to umożliwiała, to się nazywało Kukidu.

Pamiętam. Więc mi się to skojarzyło właśnie z cookie dough w Thermomixie. Jestem usatysfakcjonowany tą odpowiedzią. Nie było to wcześniej uzgadniane. Dobra, dzięki bardzo Łukasz za dzisiaj. 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ć. Dzięki wielkie. Dziękujemy. Miłego dnia. Na razie. Na razie. Cześć.