Hledání, které nevidí vlastní data

Změřeno 3. 8. 2026. Nález, který vysvětluje dvě různá selhání téhož dne jednou příčinou.

Teze: Nástroj, který na dotaz beze změny nastavení vrátí prázdno místo chyby, je horší než nástroj, který nefunguje vůbec. Ten se pozná hned.

Co se stalo

Ráno jsem asistentovi vytkl slovo, které používá a v češtině neexistuje. Souhlasil, zapsal si to a pak napsal:

„Ještě zkontroluju, jestli se to slovo neobjevuje v cronjobu nebo skriptech — abych ho vyřadil i tam."

Za pár sekund odpověděl:

„Žádný výskyt nenalezen — buď už to někdo opravil, nebo je to jen v historii konverzací. Hotovo."

To slovo bylo v té chvíli na deseti místech — čtyřikrát v zadání noční úlohy, šestkrát ve skriptu, který ta úloha spouští. Přesně tam, kam se šel podívat.

Co se ve skutečnosti provedlo

Ze záznamu je vidět celé volání:

VOLÁ   search_files  {"pattern": "…", "target": "content"}
VRACÍ  search_files  {"total_count": 0}
ŘÍKÁ   „Žádný výskyt nenalezen"

Ten nástroj má nepovinný parametr path. Když se nevyplní, hledá se v pracovním adresáři. Ten je /home/hermes — a veškerá data agenta leží v .hermes/, tedy ve skryté složce. Vyhledávač skryté složky ve výchozím nastavení přeskakuje.

Měřeno přímo:

Není to zaokrouhlené. Jeden soubor.

Proč to nikdo nezachytil dřív

Protože nástroj funguje, když se mu cesta předá. Ze tří volání téhož dne:

Nikdy to nespadne, nikdy nevypíše varování. Vrátí total_count: 0, což je platná odpověď na otázku „kolik jsi toho našel" — jen se neptá nikdo na to, kolik toho vůbec prohledal.

Táž příčina, druhé selhání

To třetí volání ze seznamu bylo o deset hodin později a v úplně jiné situaci: agent zápasil s příliš velkou odpovědí externího nástroje a hledal, kam se odložila na disk. Dostal nulu, takže si musel napsat vlastní skript.

Jedna slepá skvrna, dva incidenty, jeden den. A protože se v obou případech projevila jako „nic tu není" a ne jako chyba, vypadala pokaždé jako jiný problém.

Oprava (doplněno 4. 8.)

Ke dvěma incidentům z 3. 8. přibyl třetí — noční úloha 4. 8. si chtěla ověřit nález, dostala nulu a ohlásila ho bez ověření. To rozhodlo.

Oba vyhledávače teď hlásí jmenovatel. Totéž volání, které celý nález spustilo, vrací místo holé nuly:

Searched 1 file(s) under . (of 100000+ present); none matched.
Most files here are inside hidden directories, which are skipped
by default — pass the hidden directory as `path` explicitly.

A vlastní fulltext nese rozsah v každém výstupu, i úspěšném:

[prohledáno 699 sekcí v 52 souborech · zásahů 11 · zobrazeno 7]

Jmenovatel se počítá jen při nule nálezů (u vestavěného nástroje) — na plném stromě to je jeden find navíc, řádově sekundy, a platí se jen v případě, kdy nula bez kontextu umí napáchat největší škodu.

Mimochodem: k témuž pravidlu došel nezávisle framework AXI — říká mu „definitivní prázdný stav" a měří jeho přínos benchmarkem s cloudovými modely. Že se na něm potkalo jejich měření s naším provozním selháním, je slušný signál, že to není kosmetika.

Dodatek (7. 8.): a potřetí totéž, tentokrát od autorů Hermese. Verze 0.20 přišla s vlastní sondou na nulové nálezy — podle jejich čísel vrací nulu 13,9 % produkčních hledání — a hlásí přesně to, co tu chybělo: „0 shod ve viditelných souborech, ale 57 shod v 11 skrytých; prohledej skrytou cestu explicitně." Náš patch zůstává vedle ní kvůli jmenovateli (kolik souborů se vůbec prošlo) a obě hlášky se skládají do jedné. Tři nezávislé cesty ke stejnému pravidlu za čtyři dny.

Poznámka k publikaci

Hledané slovo je nahrazené, protože o něm je jiný nález a tady by odvádělo pozornost. Počty souborů, argumenty volání i výsledky jsou původní. Ukázky výstupu po opravě jsou doslovné z ověření 4. 8.