Dlaczego oszczędne pod względem tokenów wyszukiwanie w kodzie ma znaczenie dla agentów AI

Farah Rahman miała znany problem w Doha: zgłoszenie błędu od klienta, nocny wątek na Slacku i bazę kodu liczącą 1,8 miliona linii rozproszonych po 43 repozytoriach. Poprosiła agenta o prześledzenie awarii płatności. Pierwsze podejście pochłonęło tyle tokenów, że model zgubił wątek. Potem zwrócił odpowiedź częściowo trafną, podaną z ogromną pewnością siebie.

Właśnie taki bałagan Semble stara się naprawić. Ich obietnica — wyszukiwanie kodu dla agentów, które używa o 98% mniej tokenów niż grep — brzmi prawie zadziornie. Ale pod tym nagłówkiem kryje się poważna zmiana: wyszukiwanie kodu nie polega już tylko na szybkim znajdowaniu tekstu. Chodzi o podawanie maszynom wyłącznie tego skrawka źródła, którego potrzebują. W formie, nad którą mogą rozumować, nie spalając budżetu ani kontekstu.

Szczerze mówiąc, to ma znaczenie, bo stary workflow był budowany dla ludzi przeglądających terminale. Agenci nie skanują pobieżnie. Oni przyswajają. A gdy przyswajają źle, każda kolejna akcja staje się bardziej chwiejna: generowanie poprawek, analiza przyczyny źródłowej, wybór testów, poprawki dokumentacji, a nawet przegląd bezpieczeństwa.

Dlaczego to ma znaczenie teraz

Prawie jednocześnie zmieniły się dwie rzeczy. Po pierwsze, zespoły zaczęły wprowadzać LLM-y bezpośrednio do procesów inżynierskich, od asystentów w IDE po autonomiczne boty triage. Po drugie, koszt kontekstu stał się boleśnie widoczny. Ma sens? Duże prompty są nie tylko drogie; są też kruche. Jeśli agent musi przejrzeć monorepo, kilka złych kroków wyszukiwania może zmarnować całe uruchomienie.

Tymczasem oczekiwania wobec wyszukiwania się zmieniły. Programiści nadal chcą precyzji podobnej do grep, ale agentom potrzeba czegoś więcej niż dokładnego dopasowania ciągów. Potrzebują semantycznego zawężania, grupowania z uwzględnieniem symboli i wystarczającej struktury, by nie halucynować na podstawie nieistotnych fragmentów. Semble znajduje się dokładnie w tej luce.

Główna idea: wyszukiwanie dla modelu, nie tylko dla inżyniera

Tradycyjny grep jest genialny w jednej rzeczy: dopasowywaniu tekstu. Jest też bezlitośnie dosłowny. Jeśli Twój błąd jest wyrażony przez przemianowaną funkcję, plik generowany automatycznie albo symbol żyjący w pięciu wrapperach, grep może być ślepy — chyba że człowiek zna właściwą igłę, którą trzeba wbić.

Wyszukiwanie kodu dla agentów powinno działać inaczej. Powinno redukować ogromne repozytorium do zwartego, niosącego wysoki sygnał materiału dowodowego. To oznacza ranking według prawdopodobnej trafności, zwracanie otaczającej struktury i usuwanie powtarzalnego boilerplate’u, który ludzkiemu oku może umknąć, ale model chętnie zmarnuje na niego tokeny.

Głębsza kwestia jest taka, że tokeny stały się dziś rzadkim zasobem inżynierskim. Nie abstrakcyjnie. Dosłownie. Każdy dodatkowy fragment pliku, który podajesz agentowi, może zmienić opóźnienie, koszt i jakość odpowiedzi. Dlatego narzędzie, które twierdzi, że używa o 98% mniej tokenów niż grep, jest interesujące: nie dlatego, że grep jest zły, ale dlatego, że grep nigdy nie był projektowany jako dieta dla LLM.

W praktyce lepszy system do agentowego wyszukiwania kodu zwykle dobrze robi kilka rzeczy:

• Indeksuje symbole, a nie tylko linie. Funkcje, klasy, importy i odwołania są dla agentów łatwiejsze do podsumowania niż surowe bloki tekstu.
• Szereguje według kontekstu, nie tylko liczby trafień. Pojedyncze, bardzo wartościowe dopasowanie obok nieudanego testu może znaczyć więcej niż 27 wystąpień w wygenerowanej dokumentacji.
• Agresywnie kompresuje. Powtarzające się nagłówki licencji, kod vendored i zduplikowane stałe nie powinny dominować w prompcie.
• Zwraca ustrukturyzowane fragmenty. Ścieżka pliku, nazwa symbolu, zakres i wskazówki zależności pomagają modelowi rozumować bez ponownego czytania całego drzewa.
• Zachowuje możliwość śledzenia. Dobre wyszukiwanie dla agentów jest audytowalne. Powinno być widać, dlaczego dany fragment został wybrany.
• Dobrze współpracuje z narzędziami. Najlepsza warstwa wyszukiwania wpasowuje się w CI, IDE i terminal, zamiast wymagać osobnego rytuału.

Jeśli model nie potrafi wyjaśnić, dlaczego wybrał dany plik, prawdopodobnie nie ufasz mu na tyle, by ten plik edytował.

Jest też subtelna korzyść ergonomiczna. Ludzie używają wyszukiwania, by się zorientować. Agenci używają wyszukiwania, by wygenerować działanie. To nie to samo zadanie. Programista może rzucić okiem na 12 chaotycznych trafień i nadal wiedzieć, dokąd iść. Agent natomiast może z pełnym przekonaniem roznieść błędne założenie przez całą poprawkę, jeśli warstwa wyszukiwania jest niedbała.

Twierdzenie Semble o redukcji tokenów należy więc czytać jako wskaźnik czegoś większego: lepszej higieny pobierania kontekstu. Mniej szumu oznacza mniej miejsca na halucynacje. Mniej szumu oznacza też więcej przestrzeni dla modelu, by dostrzegł rzeczywiste inwarianty w kodzie. A właśnie stąd biorą się wartościowe zmiany.

Jak to wygląda w praktyce

Kenji Silva, analityk danych w Krakowie, pomagał swojemu zespołowi debugować pipeline cenowy obejmujący 14 usług i 9 modeli SQL. Tradycyjne wyszukiwanie zwróciło 311 trafień dla jednego ciągu błędu. Workflow wyszukiwania uwzględniający tokeny zawęził zestaw roboczy do 18 fragmentów i zmniejszył rozmiar promptu agenta o 91%. Powiedział, że pierwsza użyteczna diagnoza pojawiła się po 4 minutach zamiast po 29.

Rina Popescu, kierowniczka operacyjna w Tallinnie, użyła agenta do przeglądu instrukcji postępowania przy incydentach w 6 wewnętrznych repozytoriach. Agent był wielokrotnie zdezorientowany przez szablonowy markdown i zduplikowane runbooki. Gdy jej zespół przeszedł na warstwę wyszukiwania kodu, która deduplikowała boilerplate, liczba fałszywych eskalacji bota spadła z 17 w tygodniu do 3, a zespół on-call przestał ignorować połowę alertów.

Farah Rahman, z powrotem w Doha, przeprowadziła pilotaż na usłudze płatniczej z 248 testowymi niepowodzeniami w ciągu miesiąca. Jej zespół poprosił agenta o pogrupowanie awarii według przyczyny źródłowej. Dzięki lepszej warstwie wyszukiwania agent pogrupował 193 z nich w 5 wzorców i wskazał dokładne ścieżki plików, które się zmieniły. To nie zastąpiło ludzkiego osądu. Ale usunęło dużo ślepego grzebania.

Najczęstsze błędy, których warto unikać

• Traktowanie oszczędności tokenów jako celu samego w sobie. Mniejsze zużycie tokenów jest świetne, ale nie jest produktem. Jeśli wyszukiwanie zwraca mniej kontekstu i gorsze dowody, po prostu skompresowałeś błąd. Celem nie są mniejsze prompty; celem są bardziej niezawodne decyzje.

• Używanie myślenia opartego na dokładnym dopasowaniu do zadań semantycznych. grep jest znakomity, gdy znasz ciąg, symbol lub ścieżkę importu. Agenci często nie znają. Jeśli Twoja strategia wyszukiwania tylko kopiuje grep w chudszej oprawie, przeoczysz przemianowany kod, ukryte zależności i artefakty generowane automatycznie.

• Ignorowanie struktury repozytorium. Definicja funkcji w helperze testowym i ta sama nazwa w kodzie produkcyjnym nie są równoważne. Agenci potrzebują wskazówek dotyczących własności, granic modułów i kierunku wywołań. Bez tego mogą poprawić złą warstwę z absolutnie poważną miną.

• Podawanie zbyt dużej ilości boilerplate’u. Bloki licencji, paczki vendor, zminifikowany JS i powtarzające się fragmenty konfiguracji mogą bardzo szybko pożreć kontekst. Zespoły często to pomijają, bo ludzie mentalnie przeskakują przez szum. Modele nie przeskakują; one to przyswajają.

• Pomijanie ewaluacji. Warstwa wyszukiwania, która wygląda sprytnie w demo, może zawieść przy prawdziwych obciążeniach z długim ogonem nazw, repozytoriach wielojęzycznych lub chaotycznych testach. Mierz jakość pobierania na konkretnych zadaniach: lokalizacji błędów, rankingu plików i poprawności odpowiedzi, a nie tylko opóźnieniu zapytania.

• Zakładanie, że agent sam się skoryguje. Często się nie skoryguje. Jeśli krok pobierania kontekstu wskazuje złą grupę plików, model może zbudować na tym elegancką, ale fałszywą historię. Dobre wyszukiwanie to pierwsza bariera ochronna, nie opcjonalne ulepszenie.

Praktyczna checklista

1. Zacznij od jednego bolesnego workflow. Wybierz zadanie, takie jak triage błędów, analiza nieudanych testów lub śledzenie zależności. Nie próbuj ogarnąć wszystkiego, zanim nie będziesz wiedzieć, który problem wyszukiwania boli najbardziej.

2. Zmierz rozmiar promptu przed i po. Śledź liczbę tokenów wejściowych, jakość wyniku i czas do pierwszej użytecznej odpowiedzi. Jeśli nie potrafisz nazwać punktu odniesienia, nie udowodnisz poprawy.

3. Loguj, dlaczego każdy fragment został zwrócony. Zachowuj ścieżkę pliku, symbol i sygnał trafności. Możliwość debugowania ma znaczenie, gdy model wykonuje dziwny skok.

4. Usuń martwy ciężar wcześnie. Wyklucz katalogi vendored, artefakty budowania i zduplikowane pliki generowane automatycznie. To tanie i często od razu daje efekt.

5. Preferuj wyszukiwanie strukturalne zamiast surowych zrzutów tekstu. Daj agentowi zwarty pakiet: nazwę symbolu, otaczające linie i wskazówki zależności. Zwykle to lepsze niż wklejanie całych plików.

6. Testuj na brzydkich zapytaniach. Wypróbuj przemianowane funkcje, częściowe komunikaty o błędach i nieprecyzyjne opisy typu „to od zamówienia psuje się po ponowieniu”. Prawdziwi agenci widzą bałagan, nie idealne słowa kluczowe.

7. Porównuj uczciwie z grep. grep nadal wygrywa w wielu zadaniach wykonywanych przez ludzi. Sprawdź, gdzie nowe wyszukiwanie pomaga agentowi, a gdzie stare narzędzie pozostaje szybsze i prostsze.

8. Uważaj na fałszywą pewność siebie. Jeśli agent staje się bardziej elokwentny, ale mniej trafny, zaostrz pobieranie kontekstu i wymagaj cytatów prowadzących do odpowiednich zakresów źródłowych.

Kiedy NIE warto tego robić

Nie każdy zespół potrzebuje warstwy wyszukiwania zorientowanej na agentów. Jeśli Twoje repozytorium jest małe, stos technologiczny uporządkowany, a zadania głównie wykonywane przez ludzi, grep plus przyzwoite wyszukiwanie w IDE może wystarczyć. Zaawansowane pobieranie kontekstu może stać się teatrem, gdy prawdziwym wąskim gardłem jest zrozumienie produktu, a nie lokalizacja pliku.

To także zły kierunek, jeśli nie masz dość dyscypliny operacyjnej, by oceniać wyniki. Tokenowo wydajna wyszukiwarka może obniżyć koszt eksperymentów, co jest miłe, ale może też obniżyć koszt złego zachowania agenta. Jeśli nikt nie ocenia jakości pobierania, możesz po prostu zautomatyzować chaos taniej.

Gdzie dowiedzieć się więcej

• https://owasp.org/www-project-top-ten/ - podstawy bezpieczeństwa, które nadal mają znaczenie, gdy agenci dotykają kodu
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions - dobre przypomnienie, co tak naprawdę robi pod spodem wyszukiwanie w stylu grep
• https://en.wikipedia.org/wiki/Information_retrieval - szersza dziedzina stojąca za rankingiem, trafnością i oceną wyszukiwania

Fwiw, interesująca część Semble nie tkwi w liczbie marketingowej, nawet jeśli 98% mniej tokenów to niezły nagłówek. Chodzi o sygnał, że wyszukiwanie kodu jest przebudowywane najpierw dla maszyn czytających, a dopiero potem dla ludzi, i że ta zmiana przekształci sposób, w jaki zespoły debugują, poprawiają i automatyzują swoje oprogramowanie. Pytanie nie brzmi już, czy agenci potrafią przeszukiwać kod — brzmi raczej, czy Twoja warstwa wyszukiwania pomaga im myśleć jasno, czy tylko dostarcza im więcej szumu.