Wyobraź sobie, że jesteś nauczycielem i oceniasz egzamin z matematyki. Uczeń wpisuje wynik końcowy - poprawny lub nie - i na tej podstawie stawiasz ocenę. Nie widzisz brudnopisu. Nie wiesz, czy uczeń rozumiał wzór, ale źle podstawił, czy może strzelał i trafił. Tak właśnie działają obecne benchmarki agentów kodujących: SWE-bench, Aider-bench, LiveCodeBench. Agent dostaje issue, produkuje patch, testy przechodzą albo nie. Punkt albo zero. Ale nikt nie sprawdza, czy agent w ogóle znalazł właściwy fragment kodu.
SWE-Explore (arXiv 2606.07297, czerwiec 2026) zmienia reguły gry: izoluje fazę eksploracji repozytorium od generowania patchy i mierzy ją osobno. Wyniki? Nawet najlepsi agenci, którzy rozwiązują ponad połowę issue’ów, celują na poziomie linii kodu z recall zaledwie 0.15-0.19. Ale jeden system - CoSIL - osiąga recall 0.788 i w downstream resolve rate jest praktycznie nieodróżnialny od Oracle.
Problem: dlaczego “rozwiązał / nie rozwiązał” to za mało
Benchmarki typu SWE-bench zrewolucjonizowały ewaluację agentów kodujących. Dajemy agentowi repozytorium i opis issue’a, agent produkuje patch, sprawdzamy czy testy przechodzą. Proste, mierzalne, porównywalne.
Tu jest haczyk: nie wiemy, dlaczego agent się pomylił.
Rozwiązanie issue’a na poziomie repozytorium to wieloetapowy proces:
- Eksploracja - zrozumienie struktury repo, znalezienie odpowiednich plików
- Lokalizacja - precyzyjne wskazanie linii wymagających zmiany
- Rozumowanie - zbudowanie planu naprawy
- Generowanie - napisanie patcha
Gdy agent nie rozwiąże issue’a, nie wiemy, który etap zawiódł. Czy nie znalazł właściwego pliku? Znalazł plik, ale nie te linie? A może kontekst był poprawny, ale generacja patcha się posypała?
To ma realne konsekwencje. Jeśli wąskim gardłem jest eksploracja, to ulepszanie generatora patchy to strata czasu. Jeśli wąskim gardłem jest generacja - inwestowanie w lepsze wyszukiwanie jest bezcelowe. Bez granularnej ewaluacji poszczególnych faz, optymalizujesz po omacku.
Rozwiązanie: SWE-Explore w pigułce
SWE-Explore to benchmark, który izoluje pierwszą i najkrytyczniejszą fazę pracy agenta kodującego: eksplorację repozytorium. Zamiast pytać “czy rozwiązałeś issue?”, pyta “czy znalazłeś właściwy kontekst?”.
Kilka liczb na start:
- 848 issue’ów z 203 repozytoriów open-source
- 10 języków programowania - nie tylko Python, ale też JavaScript, TypeScript, Java, Go, C++, Ruby, Rust, PHP i C
- Ground truth budowany z konsensusu trajektorii wielu agentów, nie z jednego golden patcha
Wielojęzyczność ma znaczenie. Nawigacja po repozytorium w Javie (z hierarchią pakietów, interfejsami i wzorcami fabrycznymi) wygląda zupełnie inaczej niż w Pythonie (flat namespace, duck typing). System, który doskonale eksploruje repozytoria Pythonowe, może się gubić w TypeScript’owym monorepo z setkami plików .d.ts.
Jak działa zadanie eksploracji
Formalnie: dany jest issue $q$ i repozytorium $R$, eksplorer musi zwrócić uszeregowaną listę regionów kodu:
$$f : (q, R) \rightarrow P = (r_1, r_2, \ldots, r_K) \tag{1}$$gdzie:
- $q$ - opis issue’a w języku naturalnym
- $R$ - pełne repozytorium (wszystkie pliki, cała historia)
- $P$ - uszeregowana lista $K$ regionów kodu (domyślnie $K = 5$)
- $r_i = (p_i, s_i, e_i)$ — trójka: ścieżka do pliku, linia początkowa, linia końcowa
Innymi słowy: eksplorer dostaje pytanie i repozytorium, a zwraca pięć regionów kodu uszeregowanych od najbardziej do najmniej istotnego. Żadnego patcha, żadnego rozumowania o naprawie - wyłącznie zdolność do znalezienia właściwego kontekstu.
Dlaczego akurat pięć? To kompromis. Pięć regionów daje wystarczająco dużo miejsca na wieloplikowe issue’y (a takich jest mnóstwo), ale wymusza priorytetyzację - agent nie może wylistować połowy repozytorium i liczyć na trafienie.
Ground truth: konsensus zamiast golden patcha
Tu dochodzimy do najbardziej eleganckiej części. Warto zrozumieć, dlaczego tradycyjne podejście - “właściwe linie to te z referencyjnego patcha” - jest za ciasne. Agent musi przeczytać znacznie więcej kontekstu niż sam diff: definicje klas, importy, testy, powiązane funkcje. To wszystko jest niezbędne do naprawy, ale nie pojawia się w patchu.
SWE-Explore konstruuje ground truth w trzech krokach:
Krok 1: Zbieranie trajektorii. Pięć niezależnych systemów - GPT-5.4, Gemini-3-Pro, Sonnet-4.6, GLM-5.1, Kimi-K2.6 - rozwiązuje każdy issue niezależnie. Autorzy zbierają pełne trajektorie: każde otwarcie pliku, każdy odczyt regionu kodu, każdą komendę grep.
Krok 2: Ekstrakcja akcji odczytu. Z każdej pomyślnej trajektorii wyodrębniane są akcje odczytu - momenty, w których agent faktycznie przeczytał fragment kodu. Każda taka akcja staje się regionem $(file, start\_line, end\_line)$.
Krok 3: Przecięcie. Regiony odczytane przez wiele niezależnych agentów tworzą core context - rdzeń kontekstu:
$$R_{\text{int}} = \bigcap_{a \in A_{\text{succ}}} \operatorname{ReadRegions}(a) \tag{2}$$gdzie:
- $A_{\text{succ}}$ - zbiór agentów, którzy pomyślnie rozwiązali dany issue
- $\operatorname{ReadRegions}(a)$ - zbiór regionów kodu odczytanych przez agenta $a$
- $R_{\text{int}}$ - przecięcie regionów, te fragmenty, które wszyscy pomyślni agenci uznali za konieczne
Interpretacja: Jeśli GPT-5.4, Gemini-3-Pro i Sonnet-4.6 niezależnie od siebie postanowiły przeczytać tę samą funkcję w utils/parser.py:45-78, to ta funkcja jest prawdopodobnie krytyczna. Konsensus eliminuje idiosynkratyczne wzorce eksploracji i wyodrębnia rdzeń kontekstu, który jest naprawdę niezbędny.
Dodatkowo, LLM-owy refiner promuje pewne regiony odczytane przez mniejszość agentów, jeśli analiza wskazuje, że są “load-bearing”. Ręczny audyt weryfikuje jakość końcowego ground truth.
Podejście z konsensusem rozwiązuje fundamentalny problem: golden patch jest za ciasny (brakuje kontekstu diagnostycznego), pojedyncza trajektoria jest za zaszumiona (przypadkowe eksploracje). Konsensus wielu agentów daje złoty środek.
Jak ocenić eksplorera? Metryki w pigułce
SWE-Explore mierzy trzy wymiary jakości: pokrycie, ranking i efektywność kontekstu.
Pokrycie i dokładność
Podstawowe metryki to Precision i Recall na poziomie linii kodu:
$$\operatorname{Prec}_{\ell} = \frac{|L_P \cap L_G|}{|L_P|}, \quad \operatorname{Rec}_{\ell} = \frac{|L_P \cap L_G|}{|L_G|} \tag{3}$$gdzie:
- $L_P$ - zbiór linii zwróconych przez eksplorera
- $L_G$ - zbiór linii w ground truth
- $\operatorname{Prec}_{\ell}$ - jaka frakcja zwróconych linii jest faktycznie istotna
- $\operatorname{Rec}_{\ell}$ - jaka frakcja istotnych linii została znaleziona
Innymi słowy: Precision mówi “ile z tego, co zwróciłeś, jest przydatne?”. Recall mówi “ile z tego, co powinieneś znaleźć, faktycznie znalazłeś?”. Na poziomie linii te metryki są surowe - jeden region przesunięty o kilka linii dramatycznie obniża wynik.
HitFile i HitRegion to metryki binarne na wyższym poziomie: czy eksplorer wskazał co najmniej jeden plik / region z ground truth? Odpowiadają na pytanie: “czy w ogóle trafiłeś w okolice problemu?”
Ranking: nDCG pod budżetem liniowym
Eksplorer nie tylko musi znaleźć właściwe regiony - musi je uszeregować. Region najbardziej istotny powinien być pierwszy. To krytyczne, bo downstream solver (generator patchy) ma ograniczone context window.
$$\operatorname{DCG}{@}B = \sum_{\substack{i \in P \\ \operatorname{cumlines}(i) \leq B}} \frac{g_i}{\log_2(i + 2)} \tag{4}$$gdzie:
- $B$ - budżet liniowy (domyślnie 500 linii)
- $\operatorname{cumlines}(i)$ — skumulowana liczba linii do pozycji $i$
- $g_i$ - gain regionu $i$: liczba linii z ground truth pokrytych przez ten region
- $\log_2(i + 2)$ - dyskonto pozycyjne
Interpretacja: nDCG@B mierzy jakość rankingu z dwoma ograniczeniami: pozycji (wyżej = ważniej) i budżetu liniowego (po $B$ liniach przestajemy liczyć). Eksplorer z nDCG@500 = 0.95 oznacza ranking niemal idealny w budżecie 500 linii.
Dodatkowa metryka: First Useful Hit (FUH) - frakcja instancji, w których pierwszy zwrócony region jest istotny.
Efektywność kontekstu
Context Efficiency (CtxEff) łączy pokrycie z oszczędnością:
$$\operatorname{CtxEff} = \frac{|L(P) \cap (L(R_{\text{core}}) \cup L(R_{\text{opt}}))|}{|L(P)|} \tag{5}$$gdzie:
- $L(P)$ — wszystkie linie zwrócone przez eksplorera
- $L(R_{\text{core}}) \cup L(R_{\text{opt}})$ — wszystkie linie z ground truth
Innymi słowy: eksplorer zwracający 50 trafnych linii w 100 liniach kontekstu jest lepszy od eksplorera zwracającego te same 50 trafnych linii w 5000 liniach kontekstu. Nadmiar kontekstu to szum, który obciąża context window solvera i może go zmylić.
Warto zapamiętać tę metrykę. To właśnie Context Efficiency okazuje się najsilniejszym predyktorem downstream resolve rate - korelacja Pearsona wynosi r = 0.950. Żadna inna metryka nie zbliża się do tak silnego związku z końcowym sukcesem.
Liczby, które przekonują
Autorzy ewaluują szeroki wachlarz systemów: klasyczne metody wyszukiwania (BM25, TF-IDF), ogólne agenty kodujące (OpenHands, Claude Code, Codex), wyspecjalizowane lokalizatory (AutoCodeRover, LocAgent, CoSIL) i dedykowane mini-agenty (Mini-SWE-Agent, AweAgent). Oracle i Random jako górna i dolna granica.
Pełne wyniki przy $K = 5$:
| Explorer | HitReg | Prec | Rec$_{\ell}$ | F1 | HitFile | nDCG@500 | FUH | CtxEff | NoiseReg$\downarrow$ |
|---|---|---|---|---|---|---|---|---|---|
| Oracle | 0.915 | 1.000 | 0.953 | 0.964 | 0.923 | 0.858 | 1.000 | 1.000 | 0.000 |
| Random | 0.003 | 0.002 | 0.004 | 0.002 | 0.004 | 0.004 | 0.006 | 0.002 | 0.997 |
| BM25 | 0.065 | 0.055 | 0.021 | 0.024 | 0.079 | 0.132 | 0.141 | 0.087 | 0.910 |
| TF-IDF | 0.121 | 0.117 | 0.049 | 0.054 | 0.140 | 0.223 | 0.240 | 0.190 | 0.821 |
| OpenHands | 0.514 | 0.489 | 0.179 | 0.209 | 0.645 | 0.867 | 0.895 | 0.737 | 0.245 |
| Mini-SWE-Agent | 0.505 | 0.530 | 0.151 | 0.190 | 0.640 | 0.885 | 0.907 | 0.754 | 0.253 |
| AweAgent | 0.534 | 0.577 | 0.140 | 0.182 | 0.682 | 0.954 | 0.975 | 0.829 | 0.191 |
| AutoCodeRover | 0.272 | 0.680 | 0.233 | 0.291 | 0.280 | 0.720 | 0.730 | 0.738 | 0.034 |
| LocAgent | 0.472 | 0.642 | 0.191 | 0.241 | 0.540 | 0.950 | 0.977 | 0.799 | 0.195 |
| CoSIL | 0.544 | 0.581 | 0.788 | 0.602 | 0.544 | 0.824 | 0.920 | 0.898 | 0.471 |
| Claude Code | 0.531 | 0.598 | 0.154 | 0.202 | 0.667 | 0.938 | 0.963 | 0.829 | 0.186 |
| Codex | 0.516 | 0.523 | 0.194 | 0.223 | 0.649 | 0.901 | 0.936 | 0.762 | 0.249 |
Tabela jest gęsta, więc rozbijmy ją na kluczowe obserwacje.
Agenci vs. klasyczne wyszukiwanie: przepaść
Różnica między klasycznymi metodami retrieval a agentami jest ogromna. BM25 osiąga HitFile = 0.079, podczas gdy nawet najsłabszy agent (OpenHands) ma HitFile = 0.645. Ośmiokrotna różnica.
Dlaczego? Issue’y w repozytoriach to nie są proste zapytania typu “znajdź funkcję sort”. To opisy błędów, stack trace’y, oczekiwane vs. faktyczne zachowanie. Zrozumienie, który fragment kodu jest odpowiedzialny za opisany bug, wymaga rozumowania, nie dopasowania słów kluczowych. Agenci mogą iteracyjnie nawigować: przeczytać plik importów, pójść do definicji klasy, sprawdzić testy, wrócić do configu. Ta wielokrokowa eksploracja jest kluczowa.
Wąskie gardło: recall na poziomie linii
Teraz najważniejsze odkrycie. Spójrz na kolumnę Rec$_{\ell}$:
- OpenHands: 0.179
- Claude Code: 0.154
- Codex: 0.194
- AweAgent: 0.140
- Mini-SWE-Agent: 0.151
Wszyscy główni agenci osiągają recall w przedziale 0.14-0.19. Mniej niż jedna piąta linii, które powinni znaleźć. Jednocześnie ich HitFile przekracza 0.6 - trafiają we właściwe pliki w ponad 60% przypadków, ale nie celują w odpowiednie linie.
Jak lekarz, który wie, że problem jest w sercu, ale nie potrafi wskazać, która zastawka szwankuje. Ogólna diagnoza poprawna, precyzja - fatalna.
Jedyny wyjątek: CoSIL z recall 0.788 - ponad czterokrotnie wyższy niż reszta. Warto też odnotować AutoCodeRover z najwyższą Precision (0.680) i najniższym NoiseReg (0.034) - zwraca mało, ale to co zwraca jest niezwykle trafne. Problem w tym, że jego recall (0.233) wciąż daleko od ideału.
Dlaczego to się dzieje? Model LLM vs. mechanizm eksploracji
Ciekawe pytanie: co bardziej wpływa na jakość eksploracji - silniejszy model czy lepszy mechanizm?
Dane sugerują jednoznacznie: mechanizm eksploracji dominuje. Claude Code i Codex używają frontier modeli, ale ich recall na poziomie linii (0.154 i 0.194) jest porównywalny z Mini-SWE-Agent i OpenHands. Natomiast CoSIL, z dedykowaną strategią lokalizacji, osiąga recall 0.788 - ponad czterokrotnie więcej.
Warto to zapamiętać. Samo wrzucenie silniejszego modelu do pętli agent nie wystarczy. Trzeba zaprojektować strategię eksploracji - heurystyki przeszukiwania, politykę priorytetyzacji regionów, mechanizmy śledzenia już odwiedzonego kontekstu.
nDCG@500 pokazuje inny wzorzec. AweAgent (0.954) i LocAgent (0.950) dominują w rankingu - potrafią uszeregować to, co znajdą, niemal idealnie. Ale ranking nie pomoże, jeśli brakuje pokrycia. Nie możesz uszeregować czegoś, czego nie znalazłeś.
Brakujący kontekst boli bardziej niż szum
To chyba najbardziej praktyczna konkluzja paperu. Co się dzieje, gdy kontekst z eksplorera przekażemy solverowi do wygenerowania patcha?
| Explorer | Resolve Rate (%) |
|---|---|
| Oracle | 59.7 |
| Random | 4.7 |
| CoSIL | 59.3 |
| Mini-SWE-Agent | 50.0 |
| Codex | 50.3 |
| Claude Code | 48.0 |
| OpenHands | 47.7 |
CoSIL z resolve rate 59.3% jest praktycznie nieodróżnialny od Oracle (59.7%). Zdumiewające - CoSIL nie ma dostępu do idealnego kontekstu, a solver radzi sobie niemal identycznie.
Dlaczego? Bo CoSIL ma najwyższy recall (0.788) i najwyższy CtxEff (0.898). Solver dostaje prawie cały potrzebny kontekst z minimalnym szumem. Brakujący kontekst jest znacznie bardziej szkodliwy niż nadmiarowy kontekst.
Porównaj dwa skrajne przypadki:
- AutoCodeRover: Precision 0.680 (najwyższa!), ale Recall 0.233. Solver często nie dostaje wystarczającego kontekstu.
- CoSIL: Precision 0.581 (niższa), ale Recall 0.788. Trochę więcej szumu, ale znacznie więcej trafnego kontekstu - i to wygrywa.
Innymi słowy: lepiej dać solverowi 100 linii, z których 58 jest trafnych, niż 50 linii, z których 34 jest trafnych. Nadmiar kontekstu LLM potrafi przefiltrować. Brakujący kontekst - nie.
Obecne systemy są zbyt konserwatywne w eksploracji - wracają z wąskim kontekstem o wysokiej precyzji, zamiast z szerokim kontekstem o wysokim recall. Odwrócenie tej tendencji mogłoby dać znaczące zyski.
Jak czytać te metryki razem?
Bogactwo metryk może na pierwszy rzut oka przytłaczać, ale każda opowiada inną część historii. Trzy profile:
AweAgent - mistrz rankingu. nDCG@500 = 0.954, FUH = 0.975. Prawie zawsze stawia coś użytecznego na pierwszym miejscu. Ale recall = 0.140. Profil: “znam drogę, ale nie odwiedzam wystarczająco wielu miejsc.”
CoSIL - mistrz pokrycia. Recall = 0.788, CtxEff = 0.898. Znajduje prawie wszystko. Ale nDCG@500 = 0.824 - ranking gorszy niż u agentów ogólnych. Profil: “odwiedzam wszystkie istotne miejsca, ale nie zawsze w optymalnej kolejności.”
AutoCodeRover - mistrz precyzji. Precision = 0.680, NoiseReg = 0.034. Prawie zerowy szum. Ale HitReg = 0.272, recall = 0.233. Profil: “jestem pewny swoich wyborów, ale często czegoś brakuje.”
Idealny eksplorer łączyłby recall CoSIL, ranking AweAgent i precyzję AutoCodeRover. SWE-Explore daje narzędzia, żeby mierzyć postęp w każdym z tych wymiarów niezależnie.
Dla kogo to jest?
Dla praktyków
Jeśli budujesz agenta kodującego, implikacja jest jasna: zamiast iterować nad generatorem patchy, zainwestuj w lepszą fazę eksploracji. SWE-Explore daje ci metryki do mierzenia postępu w tym wymiarze. Context Efficiency z korelacją r = 0.950 do resolve rate mówi wprost, co optymalizować.
Konkretna rada: obecne systemy są zbyt konserwatywne. Zwracają wąski, precyzyjny kontekst. Dane pokazują, że lepiej zwracać szeroki kontekst o wysokim recall - LLM-owy solver poradzi sobie z filtrowaniem szumu.
Dla badaczy
SWE-Explore otwiera pole badawcze, które dotychczas było niewidoczne. Warto zwrócić uwagę na trzy luki:
- Strategia eksploracji > model bazowy. CoSIL z dedykowanym mechanizmem lokalizacji bije Claude Code i Codex z frontier modelami. To zachęta do projektowania lepszych heurystyk przeszukiwania, nie tylko wrzucania silniejszych LLM-ów.
- Wielojęzyczność. 10 języków programowania ujawnia, że profile kompetencji agentów różnią się między ekosystemami. SWE-bench z samym Pythonem tego nie pokaże.
- Konsensusowe ground truth. Podejście z wieloma trajektoriami agentów rozwiązuje fundamentalny problem zbyt ciasnego golden patcha. Warto zbadać, jak zmienia się ground truth przy innym zestawie agentów bazowych.
Techniczne szczegóły
Dla zaawansowanego czytelnika - kilka aspektów, które warto rozwinąć.
Korelacja Context Efficiency z resolve rate
Korelacja Pearsona r = 0.950 między CtxEff a downstream resolve rate to niemal perfekcyjna liniowa zależność. Żadna inna metryka nie osiąga tak silnego związku. To oznacza, że jeśli chcesz poprawić resolve rate agenta kodującego, optymalizuj efektywność kontekstu - dostarczaj solverowi więcej trafnych linii i mniej szumu.
Skala i wielojęzyczność benchmarku
848 issue’ów z 203 repozytoriów w 10 językach to poważna skala. Dotychczasowe benchmarki były zdominowane przez Pythona - SWE-bench zawiera wyłącznie repozytoria Pythonowe. Nawigacja po repozytorium w Javie wygląda zupełnie inaczej niż w Pythonie, a SWE-Explore pozwala to zmierzyć.
LLM-owy refiner w budowaniu ground truth
Samo przecięcie trajektorii to nie koniec. Refiner promuje pewne regiony odczytane przez mniejszość agentów, jeśli analiza wskazuje na ich krytyczność. To ważne, bo konsensus sam w sobie może być zbyt restrykcyjny - jeśli czterech agentów rozwiązało problem różnymi ścieżkami, ich przecięcie może być puste. Refiner łagodzi ten problem.
Ograniczenia
- Zależność od trajektorii agentów. Ground truth pochodzi od pięciu konkretnych systemów. Jeśli istnieje ścieżka rozwiązania, której żaden z nich nie odkrył, odpowiadające regiony nie trafią do ground truth. Faworyzuje “konwencjonalne” strategie eksploracji.
- Granulacja na poziomie regionów. Metryki operują na ciągłych regionach (file, start_line, end_line). W praktyce agent może potrzebować linii 45 i linii 180 z tego samego pliku - dwie niezwiązane linie. Definicja ciągłego bloku może nie odzwierciedlać rzeczywistych wzorców.
- Brak mierzenia zrozumienia. SWE-Explore mierzy, czy agent znalazł właściwy kontekst, ale nie czy go zrozumiał. Agent może przeczytać właściwy region i wciąż źle zinterpretować kod.
- Statyczny snapshot. Benchmark operuje na zamrożonych snapshotach repozytoriów. W praktyce agenci mogą uruchomić testy, sprawdzić logi CI, postawić debugger. Te interaktywne źródła informacji nie są uwzględnione.
Podsumowanie
1. Eksploracja jako mierzalna faza. SWE-Explore to pierwszy benchmark, który izoluje eksplorację repozytorium od generowania patchy i mierzy ją granularnymi metrykami - pokrycie, ranking, efektywność kontekstu.
2. Agenci » retrieval, ale recall na poziomie linii to katastrofa. Agenty dominują nad BM25 i TF-IDF, ale osiągają recall zaledwie 0.14-0.19. Znajdują właściwe pliki, nie właściwe linie.
3. Recall bije precision w downstream impact. CoSIL z recall 0.788 osiąga resolve rate 59.3% - niemal identycznie jak Oracle (59.7%). Brakujący kontekst boli bardziej niż szum. Context Efficiency koreluje z resolve rate na poziomie r = 0.950.
4. Mechanizm eksploracji > model bazowy. Claude Code i Codex z frontier modelami mają porównywalny recall do prostszych agentów. Kluczem jest jak agent eksploruje, nie czym.
5. Konsensusowe ground truth. Budowanie ground truth z trajektorii wielu agentów daje bogatszą i uczciwszą definicję “właściwego kontekstu” niż sam golden patch.
Benchmarki, które mierzą tylko wynik końcowy, nie powiedzą ci, co poprawić. SWE-Explore mówi.
📎 Linki
- Na podstawie publikacji 📄 arXiv:2606.07297