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

tylko staramy się zbudować ten graf, z którego jak już znajdziemy jakiś jeden węzeł w tym grafie, to jesteśmy w stanie znaleźć elementy, które są z nim powiązane i są do niego podobne. To są tak zwane grafragi. I powiedzmy działa to trochę podobnie, ten pipeline przygotowywania takiego grafraga działa dosyć podobnie. 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... encjami, które znajdzie w tym tekście, a następnie podpina te konkretne embeddingi już pod konkretne encje i relacje i buduje z tego taki dwu lub trzypoziomowy graf, po którym my jesteśmy w stanie przechodzić i szukać.

Z tego co wiem, to właśnie większość startupów skupia się na tym, żeby wszystko robić przy pomocy AI, a my właśnie poszliśmy w tym kierunku, ok, co właśnie się stanie, jeśli za chwilę ten AI będzie na tyle drogi. że, no, że trzeba będzie jakieś optymalizacje wprowadzić, nie? To w tym wypadku jakby my jesteśmy odpowiedzią też na to pytanie, nie? Jak to robić rzeczywiście w miarę tanio i deterministycznie i używać tylko w tych rzeczach, w których on jest bardzo dobry, a w tych, w których są deterministyczne rozwiązania, to użyjmy, nie? Jeszcze jeden przykład ci podam ciekawy. Na przykład dużo tutoriali, które czasami oglądam, polega na tym, że wygeneruj mi projekt na przykład, nie? I ktoś mówi elemowi, weź mi wygeneruj projekt w Springboocie z czymś tam, nie? No kurczę, przecież mam Spring initializera, wystarczy sobie, że sobie w jednym formularzu wypełnię trzy pola, buch i mam to.