Redakcja
Kontekst
Rozwój modeli językowych sprawił, że AI coraz częściej wspomaga tworzenie kodu, testowanie, refaktoryzację czy debugowanie. W odpowiedzi na ich możliwości powstały systemy oparte na agentach, czyli złożonych środowiskach, w których model (np. GPT-4) wykonuje polecenia, analizuje wyniki, używa narzędzi (edytorów, terminali, frameworków testowych), a nawet planuje kolejne kroki. Przykłady? Devin, SWE-agent, AutoCodeRover.
Te podejścia próbują odwzorować sposób pracy ludzkiego programisty, ale same w sobie wprowadzają nowe problemy. Posiadają one kosztowne i trudne w utrzymaniu interfejsy z repozytorium, rozmytą logikę decyzji modelu i wykazują się trudnością w identyfikacji momentu, w którym „coś poszło nie tak”. Złożoność architektury działa tu na niekorzyść, bo każda interakcja z narzędziem to potencjalne źródło błędu, kosztów i nieprawidłowości.
Podejście alternatywne - AGENTLESS
Badacze z Illinois zaproponowani AGENTLESS, system, który rezygnuje z agenta jako autonomicznej jednostki podejmującej decyzje, a zamiast tego operuje deterministycznie, etapami, na podstawie trzech kroków:
- Lokalizacja błędu. Model identyfikuje podejrzane pliki i konkretne fragmenty kod na podstawie opisu problemu i struktury repozytorium (analiza nagłówków, embeddingi, selekcja klas/funkcji).
- Naprawa (repair). Na wybranych fragmentach generowane są różne propozycje poprawek w prostym formacie diff (search/replace).
- Walidacja poprawki. Model generuje testy reprodukujące błąd, a następnie porównuje skuteczność poprawek na ich podstawie i na podstawie istniejących testów regresyjnych.
Całość odbywa się bez zapętlonych planów działania, iteracyjnego feedbacku ani dynamicznego podejmowania decyzji przez model. Każdy krok jest jawny, powtarzalny i łatwy do zrozumienia.
Wyniki
AGENTLESS został przetestowany na benchmarku SWE-bench Lite, zbiorze 300 realistycznych zadań naprawy błędów na prawdziwych repozytoriach Pythona. Zidentyfikowano następujące efekty:
- 96 poprawnych rozwiązań (32%), co plasuje go na pierwszym miejscu wśród wszystkich otwartych narzędzi (i tuż za zamkniętymi, komercyjnymi),
- średni koszt na problem to 0,70 USD, czyli wielokrotnie mniej niż systemy agentowe (które potrafią przekraczać 2-3 USD na jedno zadanie),
- złożoność działania ograniczona została do zrozumiałych, audytowalnych etapów, bez nieprzewidywalnych interakcji.
Dla porównania, systemy agentowe często wymagają 30-40 „ruchów” (turns) LLM-a, z każdą decyzją zależną od poprzedniej, co dramatycznie zwiększa zarówno koszty, jak i podatność na błędy logiczne.
Problem benchmarków
Ważnym aspektem pracy było również spojrzenie krytyczne na sam benchmark. Autorzy zidentyfikowali:
- 4,3% zadań z dosłownie podanym rozwiązaniem w opisie,
- 10% z niedostateczną ilością informacji,
- 5% z opisami wprowadzającymi w błąd.
W odpowiedzi stworzyli SWE-bench Lite-S, czyli oczyszczoną wersję benchmarku, pozbawioną takich przypadków. AGENTLESS również na niej utrzymał wysoką skuteczność, co wzmacnia argument o jego realnej użyteczności.
Wnioski
Z perspektywy zespołów testerskich i inżynieryjnych warto wyciągnąć kilka lekcji z tej pracy:
- Nie każda automatyzacja wymaga „agenta”. Przed budową pełnej orkiestracji LLM-a i narzędzi, warto rozważyć prostsze podejścia oparte na zadaniowych promptach i punktowych interakcjach.
- Testy reprodukcyjne nie są doceniane. Generowanie prostych testów na podstawie opisu błędu może być tanim i skutecznym sposobem na weryfikację poprawek, także w klasycznych procesach QA.
- Zrozumiałość i audytowalność > złożoność. AGENTLESS pokazuje, że da się zautomatyzować naprawę kodu bez tworzenia systemów, które trudno zdebugować i utrzymać.
- LLM nie musi planować, wystarczy że wykona konkretny krok dobrze. W testowaniu można z powodzeniem stosować model do konkretnych zadań (lokalizacja, generacja patcha, test) zamiast powierzać mu pełną odpowiedzialność za proces.
Perspektywa rozwoju
AGENTLESS nie rozwiązuje każdego problemu, ale redefiniuje punkt odniesienia dla podejść LLM do programowania. Zamiast gonić za coraz bardziej „ludzkimi” agentami, może warto wrócić do narzędzi, które po prostu dobrze wykonują swoje zadania. To kierunek nie tylko bardziej praktyczny, ale też – jak pokazują wyniki badań – skuteczniejszy.
Z całością badania zapoznacie się tutaj: https://arxiv.org/abs/2407.01489
