Mentionsy

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.

Wszyscy wiemy, że nasze LLM-y mają jakiś ograniczony kontekst, ograniczoną liczbę tokenów, ograniczoną liczbę słów, którą jesteśmy w stanie wrzucić w prompta.

I kiedy pytamy tego LLM-a o takie proste rzeczy, weź mi wygeneruj obrazek, albo podsumuj mi jakiś film z YouTube'a, tudzież podcast, to wtedy wszystko, co potrzebujemy, wrzucimy się w ten kontekst mieści.

ale w momencie, kiedy zaczynamy, czy chcemy zacząć wykorzystywać naszego LLM-a do tego, żeby on nam zaczął odpowiadać na pytania związane z jakimiś specyficznymi rzeczami z naszej domeny.

że co chwilę jak nam się pojawiają jakieś nowe, super aktualne dane, które też chcielibyśmy, żeby nasz LLM wiedział i znał, a najczęściej jak zadajemy jakieś pytania, to raczej nie zadajemy pytania o tym, co się stało w zeszłym miesiącu, albo jak coś zrobiliśmy dwa lata temu, tylko chcemy mieć jak najbardziej aktualny stan wiedzy tego naszego LLM.

Więc ostatnim możliwością wprowadzenia danych do takiego LLM-a, to jest właśnie wrzucenie tych danych po prostu w prompta.

Zrobienie tak dużego prompta, żeby te wszystkie dane, których potrzebujemy, do tego prompta wrzucić, a następnie dać LLM-owi zadanie, weź odpowiedź mi na pytanie na podstawie tych informacji, które wrzuciłem Ci w prompt.

odpyta jakąś bazę danych, w której będziemy trzymać te wszystkie informacje w odpowiedni sposób, odpyta i wrzuci do tego kontekstu naszego LLM-a tylko tę część wiedzy, tylko tę część informacji, tylko tę część opisów, która jest istotna w kontekście tego pytania.

Bierzemy te dokumenty, kroimy je na mniejsze kawałeczki i tutaj do tego krojenia też używamy często LLM-a.

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

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.

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,

Jeśli założylibyśmy, że nasz LLM nic nie wie o value objectach, albo prawie nic, a my chcemy mu te informacje dołożyć, żeby on był w stanie o value objectach nam coś opowiedzieć, to właśnie wtedy coś takiego byśmy zrobili.

Wydaje mi się, że to jest kwestia LLM-a, który jest odpowiedzialny za generowanie tego embeddingu.

Jeśli ten LLM będzie potrafił obsługiwać wielojęzykowe treści, nie będzie na przykład wyspecjalizowany tylko i wyłącznie w języku angielskim, bo powiedzmy, tak, możemy tak zrobić, im ten LLM ma węższy zakres,

Jeśli mamy takiego LLM-a, który potrafi obsługiwać wiele różnych języków, to wtedy tak, to wtedy one będą bardzo blisko siebie.

Z tych czanków robimy za pomocą specjalnego LLM-a robimy embeddingi.

Dzięki temu, jeżeli ja wtedy zapytam o value object, na czym polega modelowanie value objectów, to zostanie zamienione na, przez LLM zostanie zamienione na wektor.

Następnie można jakby w prostej wersji od razu moglibyśmy wrzucić do kontekstu LLM-a.

czyli jest jeszcze jeden taki LLM-ik, agent, który odpowiada za to, żeby te dane posegregować pod kątem istotności, które są rzeczywiście mocno związane z tym naszym zapytaniem, a które są mniej z tym zapytaniem związane, no bo być może ktoś używa, że tak powiem, tych samych słów do opisu.

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.

No i to nam na początku obiecywały właśnie te wektorewe bazy danych i LLM-y, które produkowały embeddingi, że to rzeczywiście będzie działać bardzo dobrze.

Tylko, że zamiast na początku chunkować to tak, jak LLMowi się wydaje, to LLM stara właśnie się na początku znajdować encję i budować relacje, czyli stara się zbudować taki ogólny model encji i relacji pomiędzy właśnie tymi...

jako bazy grafowej i stworzyć właśnie taki graf wiedzy i zamiast pytać i generować, w sensie i zamiast, jak mamy zapytanie z naszego LLM-a, to wcześniej co robiliśmy?

Dlatego, że znowu wadą powiedzmy tych rozwiązań regowych jest to, że przez to, że cały ten pipeline wrzucania tych danych do tej bazy, to jest pipeline oparty o LLM-y,

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.

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.

Pomimo tego, że już słyszy się tak o tym, że już są LLM-y, które mają milion na przykład tokenów w kontekście i już mamy w głowie, że za chwilę ranki nie będą potrzebne, bo te okna kontekstowe już będą tak duże, że jakby całe repozytoria będą nam się mieściły w tym...

Na razie badania, z którymi się ostatnio zapoznawałem, pokazują, że niestety, ale pomimo tego, że LLM wspiera to okno kontekstowe, to im więcej elementów do niego wrzucimy, tym mniejsza jest dokładność odpowiedzi.

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?

Robimy te embeddingi LLM-em, wrzucamy do naszej bazy danych, czasami określone jakimiś jeszcze dodatkowymi metadanymi i jesteśmy w stanie sobie po tym kodzie, my jesteśmy w stanie sobie wyszukiwać.

Jesteśmy przyzwyczajeni do tego, że no daj spokój, tam ile kosztuje LLM, przecież płacę za niego 20-40 dolarów na miesiąc, czasami może 200, no ale jak już zaczynamy pracować na takim produkcyjnym kodzie, którego jest sporo, to te rachuneczki bardzo szybko potrafią wbijać, szczególnie, że tych

zapytań do takiego LLM-a, to potrafi się robić dziesiątki tysięcy, a czasami nawet setki tysięcy, żeby każdego takiego czanka sobie przekonwertować, a później sobie jeszcze nad tym pracować.

Czyli my analizujemy całą bazę kodu właśnie w tym procesie kompilacji, wyciągamy wszystkie informacje na temat metod, obiektów, które w tym kodzie są i robimy z tego taki właśnie wielki graf wiedzy na temat całego tego kodu, zero LLMA w tym momencie.

LLM jest używane później, ale w tym momencie mamy używanie 0 LLM, a więc mamy tak.

Znowu, nie używamy LLM, a tylko robimy to w sposób deterministyczny, więc jest to super tanie.

Jeśli mielibyśmy taką ontologię, to ten LLM szukałby tych elementów.

Dla takiego LLM-a nie zawsze jest się w stanie domyślić, analizując ten kod na różne sposoby, ale to jest znowu to droższe rozwiązanie, które nie daje nam gwarancji, bo tutaj mogą być jakieś halucynacje, ale to, co moglibyśmy temu LLM-owi powiedzieć, to nałożyć pewną ontologię na ten nasz kodzik i powiedzieć te namespacy to są moduły,

taką ontologię, czyli gdybyśmy mogli powiedzieć temu LLM-owi, co jest czym w tym grafie, że które z tych jego węzłów to są takie ważne węzły, które nas interesują, a które to można by było totalnie olać i nic z tym nie robić, no to by było super.

I my łącząc te dwie rzeczy ze sobą, czyli łącząc ten nasz graf, który wypluwamy z tymi konwencjami, które są, tworzymy analogiczny graf wiedzy, jak robią to LLM-y, tylko że w sposób w pełni deterministyczny.

i te wrzucić tylko do kontekstu mojego LLM-a, żeby on mi je być może opisał i wygenerował dokumentację, być może zrefaktoryzował ten feature w jakiś tam inny sposób.

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.

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.

Być może przy użyciu Unesys, może przy użyciu jakiegoś innego narzędzia, takiego czysto LLM-owego,

Taki trzecim punktem to jest właśnie to wspieranie LLM-ów do tego, żeby właśnie ten kontekst engineering był jeszcze bardziej precyzyjny, jeszcze lepszy.

Po co mam używać LLM-a do scaffoldowania projektu?

których nie, które możemy robić ciągle w taki sposób deterministyczny, żeby też nie popaść w to, że teraz wszystko będziemy robić przy pomocy LLM-a.

A potem AI jest używany, LLM jest używany tylko do stworzenia embeddingu właśnie z pytania i tyle.

Kiedy robi to LLM, nie mamy tutaj takiej gwarancji, że on to rzeczywiście pochunkuje w taki sposób.