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

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ć. Więc tutaj mamy pierwszy zestaw modeli, które będą na to czankować. Chodźcie o rozbicie dużej jakiejś tam treści. Na mniejszy kawałeczki z tego względu. I właściwie po co to się robi? Czemu nie można pracować od razu na tej dużej treści? No dlatego, że to ostatecznie, co my chcemy zrobić, to chcielibyśmy właśnie wziąć ich z tych małych kawałeczków i z tych małych kawałeczków wyciągnąć te małe kawałeczki z tego dokumentu, które są istotne dla naszego pytania. Wyobraź sobie, że masz jakąś pracę naukową, która, albo nawet książkę, o, wyobraź sobie, że masz książkę, lalkę powiedzmy, tak, Bolesława Prusa, ale ciebie interesuje tylko... Nie, to dopóźnij Blue Book, Ewansa.

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ć.

a one mogą znaczyć coś innego. Mamy w tekście pomidor, ktoś pyta o warzywa, ktoś pyta o owoce i pomidor pasuje pod obie rzeczy. Więc czasami mogą być pewnego rodzaju dwuznaczności. Więc ten re-ranker, on jeszcze analizuje ten tekst, który wyszedł i sprawdza, czy on rzeczywiście jest powiązany z tym zapytaniem, które zostało wysłane. 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.

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.