W poprzednim wpisie pisałem, że warto dostarczyć LLM jak najwięcej kontekstu. Tylko czasami problem polega na tym, że sami tego kontekstu jeszcze nie mamy.
Nie wiemy, gdzie dana funkcjonalność jest budowana. Nie wiemy, który command odpowiada za konkretny proces. Nie znamy dobrze struktury indeksu albo — tak jak u mnie — Elasticsearch jest naszą piętą achillesową.
I to jest okej. Nie trzeba udawać przed LLM, że dokładnie wiemy, czego szukamy.
Możemy powiedzieć mu wprost:
Nie wiem, gdzie w projekcie budowany jest ten raport. Przeszukaj wskazany zakres plików i opisz, które commandy, serwisy oraz skrypty mogą być z nim związane. Nie wprowadzaj jeszcze żadnych zmian.
W tym momencie celem AI nie jest rozwiązanie całego zadania. Ma najpierw pomóc nam zbudować kontekst potrzebny do kolejnej iteracji.
Tak samo można podejść do Elasticsearcha.
Nigdy nie chciało mi się go porządnie nauczyć. Zawsze udawało mi się przejść obok, znaleźć kogoś, kto ogarniał go lepiej, albo zrobić coś inaczej. Gdy więc potrzebuję przygotować konkretne query, nie zlecam od razu całego raportu.
Zaczynam od małego kroku.
Dostarczam LLM strukturę indeksu, kilka przykładowych wartości, opisuję cel i wskazuję oczekiwany output:
Tutaj masz strukturę indeksu oraz przykładowe dokumenty. Przygotuj query do Elasticsearcha, które zwróci dane potrzebne do raportu. Wynik powinien zawierać pola X, Y oraz Z.
I tyle.
Nie generujemy jeszcze commanda. Nie zapisujemy pliku JSON. Nie próbujemy od razu wpasować wszystkiego w architekturę aplikacji.
Najpierw chcemy mieć poprawne zapytanie i sprawdzić, czy zwraca odpowiednie dane. O tym, jak takie query uruchamiać i weryfikować z pomocą AI, opowiem przy innej kawce.
Dzięki temu LLM ma jeden mały i konkretny cel, a Ty skupiasz się na jednej iteracji zamiast wrzucać mu zadanie składające się z kilku zależnych od siebie etapów.
Bo gdy od razu poprosisz o znalezienie danych, zbudowanie query, przygotowanie logiki, dodanie commanda i wygenerowanie raportu, model zacznie szukać wszędzie.
Może coś będzie w innym repozytorium. Może jakaś definicja ORM go naprowadzi. Może istnieje podobny command. Może stary skrypt robi połowę potrzebnej roboty.
A tokeny robią brrr. I co jeszcze gorsze brudzisz context.
Wniosek jest prosty: dziel pracę tak samo, jak podczas normalnego developmentu.
Najpierw analiza. Potem mała zmiana. Następnie weryfikacja i kolejna iteracja.
Krok po kroku, zamiast próbować rozwiązać cały świat jednym promptem.