Wyszukiwanie agentowe to problem środowiska wykonawczego

Artykuł opublikowany 14 maja w arXiv sprawdzał grep i wyszukiwanie wektorowe w Chronos, Claude Code, Codex oraz Gemini CLI na 116 pytaniach z LongMemEval. W pierwszym eksperymencie grep z wynikami podawanymi bezpośrednio w rozmowie pokonał wyszukiwanie wektorowe podawane w ten sam sposób w każdej parze mechanizm-model, ale ważniejszy wniosek był mniej oczywisty: środowisko wykonawcze zmieniało wynik niemal tak mocno jak sam mechanizm wyszukiwania.¹

Jakość wyszukiwania agentowego nie sprowadza się wyłącznie do wyboru „grep czy wyszukiwanie wektorowe”. Powstaje w całym środowisku wykonawczym: instrukcji zadaniowej, powierzchni narzędzi, ergonomii powłoki, formatowaniu wyników, presji kontekstu, ścieżce dostarczania, zachowaniu przy ponowieniach i zdolności modelu do domknięcia pętli narzędziowej.

TL;DR

Sen, Kasturi, Lumer, Gulati i Subbiah porównali wyszukiwanie leksykalne oraz wektorowe w niestandardowym mechanizmie o nazwie Chronos oraz w 3 natywnych dla dostawców mechanizmach CLI: Claude Code, Codex i Gemini CLI.¹ Badanie wykorzystało podzbiór LongMemEval-S obejmujący 116 pytań i sprawdzało zarówno wyniki narzędzi podawane bezpośrednio w rozmowie, jak i wyniki przekazywane przez pliki.¹ Grep z wynikami w rozmowie osiągnął lepsze wyniki niż wyszukiwanie wektorowe w rozmowie w każdej parze mechanizm-model w eksperymencie 1, w tym dla Codex CLI z GPT-5.4: 93,1% dla grep wobec 75,9% dla wyszukiwania wektorowego.¹ Artykuł nie dowodzi, że grep ogólnie pokonuje wyszukiwanie wektorowe; autorzy wyraźnie ograniczają wniosek do badanego scenariusza konwersacyjnego QA z długą pamięcią, gdzie odpowiedzi często zależą od dosłownych fragmentów tekstu.¹ Najbardziej użyteczny wniosek dla osób budujących agentów jest ostrzejszy: metoda wyszukiwania, środowisko wykonawcze agenta i sposób dostarczenia wyników tworzą jeden system. Należy testować je razem.

Najważniejsze wnioski

• Dla osób budujących agentów: grep powinien pozostać poważnym punktem odniesienia. Wyniki artykułu pokazują, że „wyszukiwanie wektorowe domyślnie” wygląda leniwie w QA z długą pamięcią na historii czatów, zwłaszcza gdy znaczenie mają dosłowne nazwiska, daty i fakty o użytkowniku.¹
• Dla użytkowników Codex i Claude Code: nie należy traktować CLI dostawcy jako neutralnej obudowy wokół prymitywu wyszukiwania. Artykuł raportuje duże przesunięcia na poziomie mechanizmu przy tych samych danych konwersacyjnych.¹
• Dla zespołów RAG: trzeba raportować ścieżkę dostarczenia wyników, a nie tylko mechanizm wyszukiwania. Wyniki podawane w rozmowie i wyniki oparte na plikach powodowały inne zachowanie, ponieważ dostarczenie przez plik dodaje kolejne zadanie użycia narzędzi.¹
• Dla migracji: warto zachować te zachowania środowiska wykonawczego, które czynią wyszukiwanie niezawodnym. Migracja z Claude Code do Codex powinna testować wyszukiwanie, kształt transkryptu i pętle weryfikacji, zanim ogłosi równoważność.
• Dla systemów mocno opartych na cytowaniach: końcowe cytowania nie wyczerpują historii dowodowej. Osobny artykuł o Agentic GraphRAG argumentuje, że proweniencja może zależeć od odwiedzonego, ale niecytowanego kontekstu grafu, a nie tylko od cytowanych węzłów.⁴

Co właściwie sprawdzał artykuł o grep?

Artykuł stawia praktyczne pytanie: gdy agent LLM ma odpowiadać na pytania na podstawie długiej historii rozmów, w jakim stopniu wyszukiwanie zależy od metody, a w jakim od systemu agentowego, który ją otacza?¹

Autorzy porównali 2 rodziny wyszukiwania:

Sprawdzono te mechanizmy wyszukiwania w 2 klasach środowiska wykonawczego:

Zmieniano także sposób, w jaki wyniki trafiały do modelu. Dostarczenie bezpośrednio w rozmowie wstawia trafienia wyszukiwania do transkryptu. Dostarczenie programowe zapisuje wyniki do plików, a potem wymaga od modelu ich zlokalizowania, otwarcia i zintegrowania.¹ Brzmi to jak detal implementacyjny. Dane pokazują, że jest to część zadania.

Dlaczego grep tutaj wygrał?

Mierzone zadanie sprzyja odzyskiwaniu dosłownych informacji. LongMemEval zadaje pytania dotyczące długich, wielosesyjnych rozmów. Wiele odpowiedzi zależy od nazwisk, określeń czasu, faktów osobistych albo dokładnych wcześniejszych wypowiedzi. W takim ustawieniu precyzyjne narzędzie leksykalne może pokonać semantyczny mechanizm wyszukiwania, ponieważ odpowiedź często kryje się za charakterystycznym ciągiem znaków.¹

Tabela 1 w artykule pokazuje ten wzorzec wyraźnie:

Ta tabela nie mówi: „proszę usunąć bazę wektorową”. Sam artykuł ostrzega przed taką interpretacją. Autorzy wskazują, że ich wniosek dotyczy konwersacyjnego QA z długą pamięcią oraz że wyszukiwanie gęste lub hybrydowe może zachowywać się inaczej w syntezie naukowej, dokumentach wizualnych lub semantyce kodu.¹

Lepsza interpretacja jest taka: dokładne wyszukiwanie zasługuje na pełnoprawne miejsce w każdym poważnym środowisku wykonawczym agenta. Jeśli agent może przeszukiwać system plików, czytać logi, analizować wcześniejsze transkrypty albo odzyskać dosłowny fakt o użytkowniku, wyszukiwanie leksykalne może być najtańszym narzędziem o wysokim stosunku sygnału do kosztu.

Środowisko wykonawcze zmieniło wynik

Najbardziej użyteczne zdanie w artykule nie brzmi „grep wygrał”. Brzmi raczej tak: zmiana mechanizmu może przesunąć górny pułap mniej więcej w takiej samej skali jak zmiana mechanizmu wyszukiwania.¹

Przykład: Claude Opus 4.6 z grep podawanym w rozmowie osiągnął 93,1% w Chronos i 76,7% w Claude Code.¹ Ta sama rodzina modeli, ten sam podzbiór testu porównawczego, inne środowisko wykonawcze. Inny przykład: Codex CLI z GPT-5.4 osiągnął 93,1% z grep w rozmowie, ale spadł do 55,2%, gdy wyniki grep przechodziły przez programową ścieżkę dostarczenia przez plik; programowe wyszukiwanie wektorowe osiągnęło 67,2%.¹

To nie jest wyłącznie wynik wyszukiwania. To wynik środowiska wykonawczego.

Model musiał zrobić więcej niż znaleźć dowód. Musiał zrozumieć kontrakt narzędzia, dobrać terminy wyszukiwania, zinterpretować stdout, zdecydować, kiedy ponowić próbę, czytać pliki, gdy wyniki nie były podane w rozmowie, i włączyć dowody do odpowiedzi. Każdy z tych kroków należy do środowiska wykonawczego agenta. Jeśli którykolwiek staje się kruchy, nawet silny mechanizm wyszukiwania może dać słabą odpowiedź.

Dlaczego dostarczenie przez plik testuje użycie narzędzi

Dostarczenie przez plik ma oczywistą zaletę. Może zmniejszyć presję kontekstu, utrzymując duże wyniki wyszukiwania poza bezpośrednim transkryptem, dopóki model nie poprosi o ich odczyt. To powinno pomagać, gdy wyszukiwanie wektorowe podawane w rozmowie zapełnia okno kontekstu.

Artykuł pokazuje kompromis. Programowe wyszukiwanie wektorowe pokonało programowy grep w kilku wierszach, co wspiera argument o presji kontekstu.¹ Wiersz Codex/GPT-5.4 pokazuje jednak drugą stronę: dostarczenie przez plik może zmienić tanie wyszukiwanie w wieloetapowy przepływ pracy. Agent musi znaleźć artefakt, otworzyć go, wyodrębnić przydatne fragmenty i ponowić próbę, gdy pierwszy odczyt nie wystarczył.¹

Oznacza to, że dostarczenie programowe wymienia przepustowość kontekstu na kompetencję w pętli narzędziowej. Ten kompromis opłaca się tylko wtedy, gdy środowisko wykonawcze niezawodnie domyka pętlę.

To ma znaczenie w realnej pracy. Lokalny agent nie ponosi porażki w wyszukiwaniu wyłącznie dlatego, że indeks był zły. Porażka pojawia się także wtedy, gdy stdout został źle podzielony, ścieżkę pliku z wynikami łatwo przeoczyć, polecenie zwróciło zbyt dużo szumu, instrukcja źle ustawiła zadanie albo model zakończył pracę o jeden odczyt za wcześnie.

Co to oznacza dla migracji do Codex

Moja własna migracja z Claude Code do Codex skupiała się na przenoszeniu kontraktów operacyjnych, a nie na kopiowaniu drzewa plików. Ten artykuł wzmacnia tę decyzję.

Jeśli jakość wyszukiwania zależy od środowiska wykonawczego, to jakość migracji zależy od czegoś więcej niż odpowiedzi na pytanie: „czy Codex ma narzędzie wyszukiwania?”. Migracja musi zachować zachowania, które czynią wyszukiwanie użytecznym:

• agent wie, kiedy użyć dokładnego wyszukiwania przed semantycznym;
• output polecenia pozostaje wystarczająco mały, by dało się go przeczytać;
• ścieżki dowodów trafiają do odpowiedzi końcowej;
• artefakty oparte na plikach łatwo znaleźć i sprawdzić;
• nieudane wyszukiwania prowadzą do lepszych zapytań, a nie do przedwczesnych odpowiedzi;
• publiczne pisanie korzysta z weryfikacji źródeł, a nie z prawdopodobnie brzmiącego wyszukiwania.

Ta lista jest celowo publiczna i ogólna. Nie ujawnia prywatnych punktów zaczepienia, prywatnych instrukcji ani lokalnych szczegółów przepływu pracy. Chodzi o kontrakt operacyjny: agent ma udowodnić, co znalazł, a nie tylko brzmieć pewnie w sprawie przeprowadzonego wyszukiwania.

Artykuł wyjaśnia również, dlaczego migracja może sprawiać wrażenie gorszej, nawet gdy istnieje każda oczywista funkcja. Claude Code i Codex mogą udostępniać narzędzia powłoki. Oba mogą czytać pliki. Oba mogą wyszukiwać. Jeśli jednak różnią się formatowaniem transkryptu, obsługą wyników plikowych, zachowaniem zatrzymania lub wzorcami ponowień, ten sam prymityw wyszukiwania może wytworzyć inną pracę.

Pozostałe 3 sygnały prowadzą w tym samym kierunku

Trzy inne artykuły z 14 maja z tego samego przeglądu wskazują na szerszy wzorzec: jakość agentów przesuwa się z izolowanych wywołań modelu do architektury środowiska wykonawczego.

APWA traktuje silnie równoległą pracę agentów jako problem rozproszonego wykonywania. Autorzy rozkładają przepływy pracy na nieingerujące w siebie podproblemy, które niezależne zasoby mogą przetwarzać bez komunikacji między sobą, a następnie oceniają skalowanie na większych zadaniach, przy których wcześniejsze systemy zawodzą.² To twierdzenie o środowisku wykonawczym, nie sztuczka z instrukcją.

MeMo traktuje pamięć jako osobny komponent modelowy. Utrzymuje wykonawczy LLM bez zmian, koduje nową wiedzę w dedykowanym modelu pamięci i raportuje odporność na szum wyszukiwania oraz kompatybilność plug-and-play z otwartymi i zamkniętoźródłowymi LLM.³ To twierdzenie o architekturze pamięci, nie o dłuższym kontekście.

Artykuł o proweniencji Agentic GraphRAG argumentuje, że końcowe cytowania mogą być konieczne, ale niewystarczające. Trafne odpowiedzi mogą zależeć od niecytowanego kontekstu przejścia, struktury grafu i odwiedzonych, lecz niecytowanych encji.⁴ To twierdzenie o proweniencji, nie o formacie cytowań.

Po zestawieniu z artykułem o grep wyłania się taki obraz:

Wspólny motyw: obudowa jest produktem. To środowisko wykonawcze decyduje, czy zdolność modelu stanie się użyteczną pracą.

Co zmieniłbym w stosie agentowym

Należy zacząć od nudnego punktu odniesienia. Dać agentowi dokładne wyszukiwanie po ważnych plikach, logach, transkryptach lub notatkach. Zmierzyć to przed dodaniem wyszukiwania semantycznego.

Potem sprawdzić 4 kombinacje, nie 2:

Dla każdego przebiegu warto zapisać transkrypt narzędzi. Sama odpowiedź końcowa nie wystarcza. Trzeba wiedzieć, czy agent wyszukiwał właściwe terminy, otworzył właściwy plik, zauważył właściwy fragment, ponowił próbę po braku trafienia i przytoczył dowód, który faktycznie wspierał odpowiedź.

Wyszukiwanie wektorowe warto dodać wtedy, gdy domena wymaga odzyskiwania parafraz, syntezy pojęciowej albo dowodów niedosłownych. Dokładne wyszukiwanie należy zachować tam, gdzie domena zawiera nazwiska, ID, nazwy plików, daty, linie logów, output poleceń, preferencje użytkowników lub wcześniejsze instrukcje. Routing hybrydowy sprawdza się, gdy zadanie miesza oba typy.

W publicznym pisaniu ścieżka wyszukiwania powinna być surowsza. Artykuł z cytowaniami powinien nieść adresy URL źródeł, dopasowanie twierdzeń do źródeł i zapis tego, co pozostaje niezweryfikowane. Jeśli system użył grafu, warstwy pamięci lub pośredniej ścieżki wyszukiwania, końcowe cytowania nie powinny być jedynym śladem. Artykuł o proweniencji pokazuje to dla Agentic GraphRAG, ale lekcja produktowa jest szersza: dowody powinny wyjaśniać drogę, nie tylko miejsce docelowe.⁴

Lepsze pytanie testowe

Słabe pytanie testowe brzmi:

Który mechanizm wyszukiwania jest lepszy?

Mocniejsze pytanie brzmi:

W tym środowisku wykonawczym, z tym modelem, tym korpusem, tą ścieżką dostarczenia i tą polityką ponowień, które zachowanie wyszukiwania prowadzi do zweryfikowanych odpowiedzi?

Na to pytanie odpowiada się wolniej. Ale odpowiedź daje coś, czego można użyć.

Praca agentowa wciąż kusi twierdzeniami o komponentach: lepszy model, lepszy mechanizm wyszukiwania, lepsza instrukcja, lepsza pamięć, lepsza równoległość. Rzeczywistość operacyjna stale pcha w przeciwną stronę. Komponent ma znaczenie dopiero wtedy, gdy środowisko wykonawcze zmieni go w niezawodną ścieżkę od zadania przez dowód do działania.

To właśnie tę część warto migrować.

FAQ

Czy ten artykuł dowodzi, że grep pokonuje wyszukiwanie wektorowe?

Nie. Autorzy wyraźnie ograniczają wynik do badanego scenariusza konwersacyjnego QA z długą pamięcią. Stwierdzają, że wyszukiwanie gęste i routing hybrydowy mogą zachowywać się inaczej w domenach, gdzie dowody rzadko są dosłowne, w tym w syntezie naukowej, dokumentach mocno wizualnych i semantyce kodu.¹

Dlaczego grep wypadł tak dobrze w eksperymencie?

Pytania LongMemEval często zależą od dosłownych fragmentów wcześniejszych rozmów: nazwisk, dat, faktów osobistych i dokładnych wypowiedzi. Grep premiuje wysoce precyzyjne wzorce, gdy agent potrafi odgadnąć charakterystyczny termin.¹

Dlaczego mechanizm miał znaczenie?

Środowisko wykonawcze kontroluje kształt instrukcji zadaniowej, opisy narzędzi, formatowanie transkryptu, zachowanie powłoki, budowę kontekstu, dostarczanie wyników i kryteria zatrzymania. Artykuł raportuje duże przesunięcia dokładności między Chronos, Claude Code, Codex CLI i Gemini CLI, nawet gdy bazowe dane konwersacyjne pozostawały takie same.¹

Co powinni z tym zrobić użytkownicy Codex?

Zachować dokładne wyszukiwanie jako punkt odniesienia, sprawdzać transkrypty narzędzi i testować dostarczanie w rozmowie oraz przez pliki, zanim uzna się jedną metodę wyszukiwania za lepszą. Wiersz dotyczący Codex w artykule jest przydatny, ale nadal reprezentuje jedno ustawienie testu porównawczego, jeden typ korpusu i niepełny obraz całego dostawcy dla wierszy skalowania.¹

Jak to się wiąże z cytowaniami RAG?

Artykuł o proweniencji Agentic GraphRAG argumentuje, że końcowe cytowania mogą wspierać odpowiedź, a jednocześnie pomijać kontekst wyszukiwania, który wpłynął na odpowiedź. W systemach agentowych jakość cytowań powinna obejmować proweniencję ścieżki, a nie tylko końcową listę cytowanych źródeł.⁴

Co należy zachować przy migracji z Claude Code do Codex?

Należy zachować zachowanie operacyjne: kiedy agent wyszukuje, jak ogranicza output, jak otwiera dowody, jak ponawia próby, jak zapisuje ścieżki źródeł i jak odmawia twierdzeń bez wsparcia. Nie należy zakładać równoważności tylko dlatego, że oba środowiska udostępniają powłokę i polecenie wyszukiwania.

Źródła