Zurück zum Blog

Nullbefund ist kein Befund: wann eine leere Suche etwas beweist

Eine leere Trefferliste sieht aus wie eine Auskunft, ist aber oft nur das Geständnis des Werkzeugs, nicht hingeschaut zu haben. Fünf Wege, auf denen mir das passiert ist, und die Gegenprobe, die 30 Sekunden kostet.

4 Min. Lesezeitvon Daniel AlischEngineering, Automatisierung, KI-Agenten

Die unangenehmste Antwort eines Messwerkzeugs ist nicht der Fehler, sondern die Null. Ein Fehler zwingt zum Hinsehen, eine leere Trefferliste sieht aus wie eine Auskunft. Ich habe in den letzten Wochen mehrmals einen Nullbefund als Aussage über die Welt gelesen, und mehrmals war er in Wahrheit eine Aussage über mein Werkzeug.

Das Werkzeug, das sich selbst stumm schaltet

Ein Protokoll, das von einem unsauber beendeten Prozess geschrieben wurde, enthält gelegentlich Null-Bytes. grep entscheidet daraufhin, dass es eine Binärdatei vor sich hat, gibt keine Zeile aus und endet mit Rückgabewert 1. Genau denselben Rückgabewert liefert ein ehrliches „nichts gefunden“. Das Muster war vorhanden, es stand mehrfach in der Datei, und die Suche sagte trotzdem nichts.

Der Schalter dagegen heißt -a und behandelt die Datei als Text. Teurer ist die Lehre dahinter: Ein Nullbefund aus einem Werkzeug, das zwei völlig verschiedene Zustände auf denselben Rückgabewert abbildet, ist kein Befund. Man muss ihn nicht glauben, man muss das Werkzeug fragen, ob es überhaupt gelesen hat.

Das Fenster, das kleiner ist als die Frage

Dieselbe Protokolldatei rotiert bei einer festen Größe in .1 bis .3. Wer eine Frage über „die letzte Woche“ stellt und nur die aktive Datei durchsucht, bekommt eine korrekte Antwort auf eine andere, kleinere Frage: über heute. Auch hier ist das Ergebnis leer, und auch hier ist die Leere eine Eigenschaft der Messung.

Die Gewohnheit, die das schließt, ist billig: Bevor ich eine Datei durchsuche, frage ich sie, wie weit sie zurückreicht. Ein head -1 auf die älteste Generation beantwortet das in einer Zeile. Und die Suche selbst läuft über alle Generationen, nicht über die eine, deren Name am kürzesten ist.

Die Suche, die ihren Ausfall als Leere ausliefert

Der Fall, der mich am meisten gekostet hat, kam nicht von einem Kommandozeilenwerkzeug, sondern von einer Postfach-Suche. Die Antwort lautete sinngemäß „keine Ergebnisse“ — und in Klammern dahinter stand ein Teilfehler mit Status 500. Die Volltextsuche lief über einen Index, der gerade nicht antwortete. Die Oberfläche hat diesen Serverfehler zu einer leeren Trefferliste veredelt.

Aufgefallen ist es nur, weil ich dieselbe Frage über einen zweiten, unabhängigen Zugangsweg gestellt habe: die direkte Ordnerauflistung. Die lieferte Nachrichten. Zwei Komponenten, zwei Verfügbarkeiten, ein gemeinsames Antwortformat — das ist die unangenehmste Variante, weil der Nullbefund hier nicht nur falsch ist, sondern zusätzlich beruhigend wirkt.

Für Agenten, die Suchergebnisse weiterverarbeiten, ist das die wichtigste Stelle: Ein leeres Suchergebnis darf nie als „existiert nicht“ in den nächsten Schritt wandern. Entweder es gibt eine Gegenprobe über einen anderen Pfad, oder das Ergebnis heißt „unbekannt“.

Der Griff ans falsche Ende

Zwei Varianten derselben Familie, beide eigene Arbeitsstunden wert. Erstens: Eine Liste aus einer API war nicht sortiert, und ich habe das letzte Element für das neueste genommen. Der auffälligste Vorfall sah dadurch zwei Monate alt aus und wurde als erledigt abgehakt, obwohl er akut war. „Neueste“ ist ein Maximum über das Zeitfeld, nicht die letzte Zeile.

Zweitens: Ich wollte ein Zeitfenster aus einem Protokoll schneiden und habe die Zeitstempel in awk als Zeichenketten verglichen. Eingerückte Zeilen aus einem Python-Traceback beginnen nicht mit einer Jahreszahl, und im Zeichenkettenvergleich sind sie größer als 2026-. Der Schnitt lag damit woanders als gedacht — ohne Fehlermeldung, nur mit einem Ausschnitt, der die interessanten Zeilen nicht enthielt. Robuster: die Grenzen mit grep -n suchen und dann nach Zeilennummern schneiden.

Die Positivkontrolle kostet dreißig Sekunden

Alle fünf Fälle hätte ein einziger Handgriff gefangen. Bevor ich eine leere Trefferliste für eine Aussage nehme, suche ich nach etwas, das garantiert drin ist: dem heutigen Datum, dem Wort aus der ersten Zeile, einem Eintrag, den ich gerade selbst erzeugt habe. Findet das Werkzeug den bekannten Treffer nicht, dann sagt die Null über meine Frage genau nichts.

Das gilt genauso für Wissenssuche und RAG. Wenn eine semantische Suche nichts liefert, ist die erste Frage nicht „welches Dokument fehlt“, sondern „hätte dieses Werkzeug ein vorhandenes Dokument gefunden“. Ein Dokument, das ich kenne, als Kontrollfrage einzugeben, trennt ein leeres Wissen von einem leeren Index, einer kaputten Einbettung oder einem Filter, der still alles wegwirft.

Fazit

Ein Nullbefund trägt zwei Aussagen übereinander: eine über die Welt und eine über das Messgerät. Solange nicht geklärt ist, welche der beiden geantwortet hat, ist er keine Erkenntnis, sondern eine offene Frage mit aufgeräumtem Aussehen. Die Positivkontrolle ist der billigste Weg, die beiden zu trennen — und der einzige, den ich mir nach diesen Wochen wirklich zur Gewohnheit gemacht habe.

Weiterlesen