Suchen ohne Antworten zu erfinden

Diesen Beitrag anhören (11 Min.)

Die Frage lautet: „Warum verwendet der Import ein gemeinsames Retry-Budget?“ Eine Suchfunktion muss darauf nicht sofort einen perfekten Absatz schreiben. Ihr erster Auftrag ist kleiner: relevante Stellen finden und offenlegen, was der Bestand tatsächlich enthält.

WikiKit trennt dafür Schritte mit unterschiedlichen Aufgaben: Die Suche liefert Treffer, der Leseweg das vollständige Konzept, der Quellenweg die Herkunft und der Historienweg die Geschichte einer Aussage. Die natürlichsprachige Abfrage bleibt eine optionale Stufe, die von der Wissensbasis, ihren Quellen und ihrem Reviewzustand getrennt ist.

Stand 18. August 2026 beschreibt dieser Text den unten verlinkten WikiKit-Commit. Einzelne Schnittstellen können sich später ändern; die Trennung der Aufgaben bleibt dennoch prüfbar.

Die Suche liefert Treffer, keine Synthese

Die Suche liefert Treffer aus dem Wissensbestand. Sie formuliert daraus keine verbindenden Sätze und ergänzt keine Erklärung, die im Bestand nicht vorkommt.

Die Reihenfolge der Treffer ist kein Wahrheitswert. Ob ein Treffer die Frage inhaltlich beantwortet, zeigt erst das Lesen des vollständigen Konzepts und seiner Herkunft. Eine konkrete Rangfolgeformel ist im aktuellen Repository nicht als Vertrag belegt. Tests sollten daher keine internen Scores festschreiben.

flowchart LR
    Q["Frage"] --> S["Suche<br/>rohe Treffer"]
    S --> R["Lesen<br/>vollständiges Konzept"]
    R --> O["Quellen und Historie<br/>Herkunft prüfen"]
    O --> A{"genug belegt?"}
    A -->|ja| N["Antwort oder Entscheidung"]
    A -->|nein| X["Nichtwissen benennen"]

Der Leseweg holt das vollständige Konzept

Ein Suchtreffer ist ein Ausgangspunkt. Wer den vollständigen Stand braucht, liest das zugehörige Konzept über den dafür vorgesehenen REST- oder MCP-Weg.

Im vollständigen Konzept lässt sich prüfen, in welchem Zusammenhang die gefundene Formulierung steht. Herkunft und Geschichte werden anschließend über getrennte Wege abgerufen, wenn die Prüfung sie verlangt.

Der Agentenablauf lädt zunächst kompakten Kontext und ruft vollständige Konzepte, Herkunft und Geschichte bei Bedarf ab. Ein vollständiger Dump kann dagegen den verwendeten Kontext vergrößern und für die konkrete Aufgabe irrelevante Aussagen enthalten.

Herkunft und Geschichte sind getrennte Prüfschritte

Quellen und Historie beantworten andere Fragen als die Suche. Die Herkunft ermöglicht die Prüfung, worauf eine Aussage zurückgeht und ob der Beleg sie trägt. Die Geschichte zeigt, wie sich der dokumentierte Stand verändert hat.

Umstrittene Claims bleiben ein Reviewfall

Ein Konflikt im Wissensbestand darf nicht durch eine glatt formulierte Antwort verschwinden. Der Reviewzustand der Wissensbasis bleibt von der optionalen natürlichsprachigen Abfrage getrennt. Daraus folgt jedoch keine Garantie, wie eine bestimmte Oberfläche einen Status wie disputed darstellt.

Für eine Person ist der Konflikt der Beginn der Prüfung. In diesem Ablauf sollte ein als disputed geführter Claim die automatische Migrationsplanung stoppen, bis der Geltungsbereich geklärt ist. Die Antwort soll den nächsten prüfbaren Schritt ermöglichen, statt den Konflikt sprachlich aufzulösen.

Der geprüfte Stand legt kein Filter-, Sortier- oder Darstellungsverhalten für einzelne Suchoberflächen fest.

Die natürlichsprachige Abfrage ist optional

Natürlichsprachige Abfragen bilden einen eigenen, optionalen Zugang. Die Wissensbasis, ihre Quellen und ihr Reviewzustand bleiben davon getrennt.

Die Antwort sollte jede wesentliche Aussage auf einen gefundenen Beleg zurückführen und fehlende interne Begründungen nicht durch allgemeines Modellwissen ersetzen. Das ist keine Garantie, die allein durch einen Prompt entsteht. Tests und Leser müssen weiterhin prüfen, ob die Antwort tatsächlich durch den Bestand gedeckt ist.

Dieser Verzicht verhindert, dass eine plausible Standarderklärung mit einer internen Entscheidung verwechselt wird. Vielleicht teilt das Team das Budget wegen einer bestimmten SLA. Vielleicht war es eine Implementierungsvereinfachung. Ohne Quelle bleibt die Ursache offen, und genau das sollte die Antwort sagen.

Begriffe brauchen Kontext

Bei einer begriffsgebundenen Suche kann ein vorhandenes Konzept fehlen, wenn die gesuchten Begriffe nicht im durchsuchten Text vorkommen.

Ein Konzept retry-policy kann beispielsweise retry budget, attempt timeout und einen internen Clientnamen erklären. Das verbessert die Auffindbarkeit und zugleich die Lesbarkeit. Eine unsichtbare Synonymliste außerhalb des Wissensbestands wäre schwerer zu prüfen.

# Retry policy

The internal HTTP client uses one shared retry budget across all attempts.
Teams sometimes refer to this as the request deadline or attempt budget.

Zu viele Schlagwörter verschlechtern den Text. Begriffe lassen sich aus gemeldeten erfolglosen Suchen ergänzen, obwohl das Wissen vorhanden war. Solche Lücken werden als kleine Konzeptänderung vorgeschlagen und geprüft, statt sie unbemerkt nur in einem Suchindex zu korrigieren.

Suche getrennt testen

Bei festgehaltener Suchkonfiguration und festem Datenstand lässt sich ein wiederholbarer Testaufbau herstellen. Geprüft werden dokumentierte Eigenschaften, nicht eine stabile Rangfolge.

Als Teststrategie bietet sich an, bekannte Konzepte anzulegen, eine Suche auszuführen und zu prüfen, ob die erwarteten Einträge in der Treffermenge enthalten sind. Das folgende Beispiel beschreibt eine mögliche Testabstraktion, nicht die öffentliche WikiKit-API:

const hits = await testClient.search({
  space: "engineering",
  query: "retry budget"
});

expect(hits.map(hit => hit.slug)).toContain("retry-policy");

Für die natürlichsprachige Antwort kann ein separater Test mit kontrollierten Antworten arbeiten. Seine Fixtures legen fest, welche Belege verfügbar sind; geprüft wird die Zuordnung zwischen Aussagen und Belegen, nicht eine reale Modellantwort als deterministisches Orakel.

Grenzen gehören ebenfalls zum Testvertrag. Nach Änderungen an der Suchkonfiguration kann sich die Trefferordnung verschieben. Tests sollten deshalb keine exakten Scores oder nicht als Vertrag dokumentierten Rangfolgen festschreiben. Belastbarer sind Mengenerwartungen wie „der passende Claim ist in den Treffern enthalten“ und „ein fachfremder Begriff liefert kein Ergebnis“.

Eine Antwort bis zur Quelle verfolgen

Angenommen, die natürlichsprachige Abfrage antwortet: „Retries teilen ein gemeinsames Budget, damit die Gesamtdauer die Request-Deadline nicht überschreitet.“ Die Antwort sollte ihre beiden Aussagen auf passende Claims oder Entscheidungen zurückführen.

Eine Testfixture kann diese Zuordnung ausdrücklich darstellen:

answer sentence
  -> expected claim identifier
  -> supporting citation
  -> source
  -> revision history

Fehlt die Begründung „damit die Request-Deadline nicht überschritten wird“ in allen Belegen, ist der erste Halbsatz möglicherweise gestützt und der zweite eine Erfindung. Als redaktionelles Prüfkriterium oder Testvertrag lässt sich deshalb für jeden wesentlichen Satz eine erwartete Claim-ID oder ein tragendes Zitat hinterlegen. Bei Unsicherheit sollte die Antwort enger werden: „Die Basis belegt ein gemeinsames Budget; eine Begründung ist nicht hinterlegt.“

Für wichtige Entscheidungen liest ein Mensch die Quelle selbst. Die natürlichsprachige Abfrage verkürzt den Weg, hebt die Prüfpflicht aber nicht auf.

Suche darf keine Zugriffskontrolle umgehen

Wenn ein System getrennte Wissensbestände oder Mandanten verwaltet, muss die Zugriffskontrolle auch für die Suche gelten. Treffer aus einem fremden Bestand dürfen weder in Trefferlisten noch in Vorschlägen auftauchen. Fehlermeldungen sollten keine Bezeichner aus Beständen verraten, auf die der Aufrufer nicht zugreifen darf.

Auch Suchlogs brauchen Datenminimierung, weil eine Anfrage vertrauliche Begriffe enthalten kann. Strukturierte Logs sollten nur die für Betrieb und Fehlersuche erforderlichen Metadaten erfassen. Falls der vollständige Suchtext vorübergehend für die Diagnose benötigt wird, braucht das eine bewusste, geschützte und zeitlich begrenzte Einstellung.

Suchqualität wächst aus echten Fragen

Ein Team kann eine kleine Liste wiederkehrender Fragen als Evaluation pflegen. Jede Frage trägt erwartete relevante Slugs und einen Hinweis, ob ein bewusster Verzicht oder ein Konflikt erwartet wird.

{
  "question": "Why do retries share one budget?",
  "expected_slugs": ["retry-policy", "shared-retry-budget"],
  "expected_state": "answerable"
}

Bei Änderungen an Suche oder Konzepten läuft diese Liste erneut. Sie misst nicht sprachliche Schönheit, sondern Auffindbarkeit und erwartete Zustände. Eine zweite Gruppe absichtlich unbeantworteter Fragen prüft, dass keine neuen Scheinantworten entstehen: Ein leeres Ergebnis muss leer bleiben.

Scheitert eine Frage aus dieser Evaluation, kommen mehrere Ursachen infrage. Vielleicht fehlt die Quelle. Vielleicht ist das Konzept schlecht benannt. Vielleicht fehlt ein verwendetes Synonym im aktuellen Wissensstand. Der Fund wird als Wissens- oder Suchproblem klassifiziert und an der passenden Stelle behoben. Auch diese Änderungen durchlaufen Quellenprüfung und Review.

MCP hält die Wege getrennt

WikiKit bietet über MCP getrennte Werkzeuge für Suche, vollständiges Lesen, Quellen, Entscheidungen und Revisionshistorie. Dadurch kann ein Agent zunächst suchen, anschließend das passende Konzept lesen und Herkunft oder Geschichte nur dann abrufen, wenn die Aufgabe diese Prüfung verlangt.

Die Trennung macht außerdem sichtbar, an welcher Stelle Informationen fehlen. Findet die Suche kein Ergebnis, darf der Agent die Lücke nicht unbemerkt aus Vorwissen füllen. Er kann stattdessen benennen, dass im verfügbaren Bestand kein passender Treffer vorliegt.

Welche konkreten Werkzeugnamen, Antwortfelder und Berechtigungen gelten, hängt von der dokumentierten Version der Schnittstelle ab. Dieser Artikel legt dafür keinen zusätzlichen Vertrag fest.

Vom Grounding-Ansatz zu getrennten Such- und Lesewegen

Sauberes Grounding II beschrieb Retrieval als passenden Weg für Material, das nicht ständig in den Kontext gehört. Konventionen, Dokumente und Schnittstellenbeschreibungen wurden nach Aufgabe und Wiederbeschaffungskosten ausgewählt.

WikiKit setzt diesen Ansatz mit getrennten Such- und Lesewegen um. Die Suche findet rohe Treffer ohne Synthese. Der Leseweg liefert das vollständige Konzept. Quellen und Historie erklären Herkunft und Veränderung. Die natürlichsprachige Abfrage bleibt eine optionale Stufe. Ein Agent kann stoppen, sobald die für seine Aufgabe erforderlichen Belege vorliegen.

Sauberes Grounding I erklärte, weshalb ein Modell plausibel klingende Methoden erfindet. Liefert die Suche keinen Treffer, darf der Agent daraus keine Antwort erfinden. Eine modellgestützte Stufe sollte fehlende interne Belege nicht durch eine plausible Begründung ersetzen.

Ein Suchtest beginnt mit Nichtwissen

Für den Einstieg reicht eine kleine Testmenge als Heuristik. Drei bekannte Fragen können prüfen, ob erwartete Treffer auffindbar sind; zwei absichtlich unbeantwortete Fragen prüfen den Umgang mit leeren Ergebnissen. Fünf Fälle ergeben noch keine belastbare Qualitätsmessung, machen aber Fehler im grundlegenden Ablauf sichtbar.

Ein Wissenssystem muss neben belegten Antworten auch Konflikte und Lücken darstellen können. Eine Suche ohne automatische Synthese hält diese Zustände sichtbar. Eine natürlichsprachige Antwort sollte erst folgen, wenn der Bestand ausreichend Material enthält.

Die Reihenfolge bleibt damit prüfbar: finden, lesen, Herkunft und Geschichte prüfen, dann antworten. Wer vor dem Lesen antwortet, kann unbelegte Begründungen ergänzen. Die getrennten Schritte machen diese Lücke sichtbar.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare