LLM-y nie rozumieją, jak kod działa w czasie wykonania - benchmark SWE-Flux

👁 118 przeczytań

Modele językowe piszą kod, wyjaśniają go i szukają błędów. Ale czy naprawdę rozumieją, co się dzieje, gdy ten kod faktycznie działa? To pytanie zadali sobie Hamed Taherkhani, Mohammad Abdollahi, Melika Sepidband, Hridya Dhulipala, Tien N. Nguyen i Hadi Hemmati w pracy opublikowanej we wrześniu 2026 roku na arXiv.

Problem z dotychczasowymi testami

Autorzy wskazują na dwie luki w istniejących podejściach do oceny modeli. Po pierwsze, benchmarki działające na poziomie całych repozytoriów kodu skupiają się głównie na statycznym rozumieniu kodu - czyli na tym, jak kod wygląda, a nie jak się zachowuje. Po drugie, benchmarki sprawdzające rozumowanie o wykonaniu kodu ograniczają się zazwyczaj do krótkich fragmentów lub pojedynczych funkcji, nie do całych projektów. Dodatkowo wiele istniejących testów używa innych modeli językowych jako sędziów oceniających odpowiedzi - co samo w sobie jest źródłem błędów.

Czym jest SWE-Flux

Odpowiedzią na te braki jest SWE-Flux - benchmark zawierający 480 instancji opartych na wykonaniu kodu, zebranych z 12 prawdziwych repozytoriów napisanych w Pythonie. Kluczowa różnica w stosunku do poprzedników: poprawne odpowiedzi nie były pisane ręcznie przez ludzi ani oceniane przez inne modele AI. Zamiast tego zostały automatycznie zebrane z rzeczywistych uruchomień kodu z dodanym instrumentowaniem - czyli z kodu, do którego dołączono sondy rejestrujące jego zachowanie podczas działania.

Benchmark obejmuje dwa typy pytań: dotyczące pojedynczego testu oraz dotyczące wielu testów jednocześnie. Sprawdzane są następujące aspekty działania kodu: przepływ sterowania, pętle, stan programu, przepływ danych, wyjątki oraz niezmienniki programu.

Wyniki testowanych modeli

Autorzy przetestowali pięć modeli językowych. Dokument nie wymienia ich nazw w abstrakcie, który był dostępny - podaje jedynie zbiorczy wynik: najlepszy model osiągnął dokładność wynoszącą tylko 37%. To wynik wyraźnie pokazujący, że zadanie pozostaje trudne.

Z analizy wynika, że modele radzą sobie lepiej z pytaniami o zachowanie lokalne - czyli o niezmienniki, przepływ sterowania wewnątrz jednej procedury, wyjątki oraz proste pętle. Natomiast mają wyraźne problemy z przepływem danych, wykonaniem obejmującym wiele procedur jednocześnie, precyzyjnym rozumowaniem o stanie programu oraz z agregowaniem wyników na poziomie całego zestawu testów.

Automatyczne generowanie trudniejszych wariantów

Dodatkowym elementem pracy jest mechanizm tworzenia nowych wersji benchmarku. Potok zbierania odpowiedzi-wzorców można uruchomić ponownie po wprowadzeniu perturbacji wejściowych - czyli drobnych zmian w danych wejściowych do kodu. Autorzy piszą, że w ten sposób udało się zebrać poprawne warianty dla prawie 90% wybranych instancji. Co ważne, te nowe warianty okazały się wyraźnie trudniejsze dla testowanych modeli niż oryginalne pytania.

Mechanizm ten rozwiązuje praktyczny problem benchmarków: z czasem modele mogą być trenowane na danych zawierających odpowiedzi z testów, co zawyża ich wyniki. Możliwość generowania świeżych wariantów pozwala utrzymać benchmark jako wiarygodne narzędzie oceny.

Co z tego wynika

Moim zdaniem ta praca ujawnia konkretną, mierzalną słabość obecnych modeli - nie w pisaniu kodu, lecz w rozumieniu tego, co kod robi po uruchomieniu. 37% skuteczności najlepszego modelu przy pytaniach o zachowanie prawdziwych repozytoriów to wynik, który powinien schłodzić entuzjazm wobec używania LLM-ów do debugowania czy analizy zachowania systemu w produkcji. Benchmark jest o tyle wiarygodny, że unika pułapki oceniania modeli przez inne modele - odpowiedzi wzorcowe pochodzą z faktycznego wykonania kodu. Szkoda, że w dostępnym abstrakcie nie ma nazw testowanych modeli ani ich indywidualnych wyników - to informacja, którą chciałbym móc podać.

Źródło: arXiv cs.AI: Can LLMs Reason About Runtime Behavior? A Repository-Level Dynamic Benchmark (dokument z 2026-09-24). To omówienie powstało na podstawie pełnego tekstu dokumentu, nie relacji innych mediów.