Suchsysteme, die KI-Agenten ein Gedächtnis geben, testen und fair vergleichen

## Nur behaupten, was die Testergebnisse wirklich zeigen Unterscheide Aussagen über das Gesamtsystem von Aussagen über einzelne Funktionen. Die Behauptung, ein vollständiges Informationsabrufsystem sei das beste, erfordert Belege zu Abrufqualität, Langkontextgedächtnis, Kalibrierung, Zuverlässigkeit, Kosten und Betriebsverhalten. Eine einzelne Funktion oder Vergleichsprüfung kann dies nicht belegen. Frage bei der Bewertung einer Funktion, ob sie den Nutzern des Systems einen bedeutsamen Nutzen bringt. Verwende die Bewertung nicht darauf, die Überlegenheit eines geschützten Algorithmus gegenüber einem anderen zu beweisen, wenn die Produktentscheidung von Nutzerergebnissen abhängt. Schreibe vor einem Versuch die Aussage, die Analyseeinheit, die erwartete Wirkung, den Entscheidungsschwellwert und die Bedingungen auf, unter denen sich das Ergebnis nicht verallgemeinern lässt. Verwirf Schlussfolgerungen, deren Umfang über die geprüfte Grundgesamtheit, Arbeitslast, Systemkomponente oder Konfiguration hinausgeht. ## Datenbank und die Quelle darin getrennt auswählen Modelliere die Wissensweiterleitung anhand zweier unabhängiger Achsen: - das Korpus oder die Datenbank, das beziehungsweise die Speicherung und Zugriffsrichtlinie besitzt; - die Quelle oder Sammlung innerhalb dieses Korpus. Bestimme beide Achsen über eine ausdrückliche Vorrangkette, etwa Aufrufeingabe, authentifizierte Erlaubnis, Sitzungskontext, Repository-Markierung, Benutzerkonfiguration und schließlich Standardwert. Zeichne die bestimmten Werte mit jeder Anfrage auf, damit sich eine unbemerkte Fehlleitung untersuchen lässt. Behandle entfernte oder für Agenten vorgesehene Aufrufer als nicht vertrauenswürdig, solange Vertrauen nicht ausdrücklich hergestellt wurde. Wende den Quellenbereich über eine gemeinsame Hilfsfunktion auf jeden Lesepfad an. Baue Filter nicht einzeln in Anfragen nach. Prüfe Kennungen, bevor du sie in Verknüpfungen oder zur Schlüsselbildung verwendest, und definiere Eindeutigkeit über den vollständigen quellenbezogenen Schlüssel. ## Suchmodi mit allen Einstellungen zusammen vergleichen Definiere benannte Modi als zusammenhängende Pakete aus Zwischenspeicherrichtlinie, Token-Budget, Anfrageerweiterung, relationaler Suche, Absichtsgewichtung und Ergebnisgrenze. Bestimme die Konfiguration über eine einzige feste Vorrangkette, wobei aufrufbezogene Überschreibungen vor der Bereitstellungskonfiguration und einem dokumentierten Rückfallwert stehen. Vergleiche Modi als vollständige nutzerseitige Auswahlmöglichkeiten, statt einen günstigen Einzelparameter herauszugreifen. Gib für jeden Parameter den aktiven Wert und seine Quelle an. Führe die Modusbestimmung im untersten gemeinsamen Suchpfad durch, damit Produktionsanfragen und wiederholte Auswertungen dasselbe Verhalten ausüben. Wenn ein neuer Suchzweig nur für eine erkannte Anfrageart gilt, gestalte ihn deterministisch und lasse ihn andernfalls wirkungslos. Biete eine Überschreibung je Anfrage für kontrollierte Versuche an, ohne den systemweiten Standard zu ändern. ## Kosten bei realer Nutzungsmenge schätzen Berechne nachgelagerte Kosten aus Anfragevolumen, bereitgestellten Kontexttokens, Modelleingabepreis, Erweiterungsaufrufen und Trefferquote des Zwischenspeichers. Zeige mindestens geringe, typische und hohe Nutzungsstufen, damit Leser das Ergebnis skalieren können, ohne von einer einzelnen Anfrage hochzurechnen. Trenne isolierte Kosten je Anfrage von den tatsächlichen Ausgaben einer Agentenschleife. Zwischengespeicherte Anweisungen, Abrufspeichertreffer, wechselnde Präfixe und wiederholte Werkzeugaufrufe können den tatsächlich erreichten Gesamtbetrag erheblich verändern. Kennzeichne Einsparungen als gemessen, angenommen oder ausgeschlossen. Bewerte Abrufmodus und nachgelagertes Modell als Paar. Ein übergroßer Kontext kann ein leistungsschwaches Modell überfordern, während ein zu knappes Budget ein teures Modell mit zu wenig Informationen versorgt. Bevorzuge natürliche Paarungen und kennzeichne Fehlpaarungen als eigene Fehlerarten, statt nur die Kosten zu ordnen. ## Vor dem Test festlegen, was gemessen und wie bewertet wird Veröffentliche für jede gemeldete Kennzahl neben dem maschinenlesbaren Ergebnis eine allgemein verständliche Definition. Verwende ein maßgebliches Glossar für Begriffe wie Präzision bis zu einem Grenzrang, diskontierten Zugewinn, reziproken Rang, Überschneidung, Kalibrierung, Latenz und Kosten. Lege vor der Ergebniserfassung Datensätze, Stichprobenauswahl, erwartete Richtung, Hauptkennzahlen, Gefahren für die Gültigkeit und Ausschlussregeln fest. Verwende für gepaarte Vergleiche ein gepaartes Wiederholungsstichprobenverfahren und korrigiere für Mehrfachvergleiche, wenn du mehrere Kennzahlen oder Varianten prüfst. Bewahre sowohl menschenlesbare Zusammenfassungen als auch strukturierte Metadaten auf. Füge nicht neben einzelnen Werten beliebige Glossarfelder hinzu, sondern hänge je Antwort einen einheitlichen Metadatenblock an, damit nachgelagerte Werkzeuge ihn zuverlässig auswerten können. ## Tests zur Weiterleitung von Fragen für alle wiederholbar machen Trenne Trainingsprüffälle von zurückgehaltenen Prüffällen. Bewerte sowohl nach strengen als auch nach ausdrücklich dokumentierten großzügigen Kriterien, wenn Formatabweichungen eine inhaltlich richtige Weiterleitung verdecken können. Ändere die Kriterien jedoch nicht, nachdem du die zurückgehaltenen Ergebnisse gesehen hast. Speichere für jeden modellübergreifenden Lauf einen Beleg, der Modellkennung, Hash der Anweisungsvorlage, Hash der Prüffälle, Revision des Prüfgerüsts, Zeitstempel und Bewertungsversion miteinander verbindet. Bewahre die Rohvorhersagen auf, damit sich die Bewertungslogik verbessern oder prüfen lässt, ohne eine erneute Modellausführung bezahlen zu müssen. Nutze Ablationsversuche, um tragende Signale zu erkennen. Entferne jeweils genau eine Weiterleitungsregel, Hierarchieebene oder ein Kontextfeld und vergleiche mit demselben zurückgehaltenen Satz. Ein Leistungsabfall stützt eine ursächliche Entwurfsaussage; eine ungepaarte Vorher-Nachher-Anekdote tut dies nicht. ## Verhindern, dass gespeicherte Suchergebnisse (Cache) zwischen Einstellungen vermischt werden Nimm jede verhaltensändernde Eingabe in den Zwischenspeicherschlüssel auf: Quellenbereich, Modusparameter, Ergebnisgrenze, Erweiterungszustand, Suchzweige und -tiefe, Einbettungsanbieter, Einbettungsspalte oder -modell sowie jeden Funktionsschalter, der die Rangfolge verändert. Versioniere den Vertrag des Zwischenspeicherschlüssels. Erhöhe bei geänderter Bedeutung die Version, damit alte Zeilen über einen gewöhnlichen Nichttreffer unerreichbar werden, statt unter der neuen Konfiguration ausgelegt zu werden. Prüfe die Trennung zwischen Modi, Quellen und Anbietern sowie zwischen aktivierter und deaktivierter relationaler Suche. Führe Gleichheitsprüfungen für jedes unterstützte Speichersystem aus, da ein eingebettetes System Kodierungs- oder Typverhalten verbergen kann, das erst in einer Produktionsdatenbank auftritt. ## Private Daten schützen und Sicherheitskorrekturen erklären, ohne Schwachstellen zu verraten Speichere Auswertungsaufzeichnungen im Prüfbereich des Projekts und niemals im tatsächlich genutzten privaten Korpus eines Benutzers. Verwende erfundene Namen und Organisationen in Prüffällen, Beispielen, Berichten, Versionshinweisen und öffentlichen Erörterungen. Ersetze Anfragen, die Beziehungen erkennen lassen, durch allgemeine Platzhalter. Beschreibe Sicherheitskorrekturen in öffentlichen Unterlagen funktional. Erkläre den Schutzmechanismus und die notwendige Maßnahme für Betreiber, ohne eine aufbereitete Liste empfindlicher Datensätze, die Dauer der Offenlegung oder den einfachsten Prüfpfad für ungepatchte Systeme zu veröffentlichen. Bewahre die ausführliche Offenlegungsanalyse in zugriffsbeschränkten Prüfbelegen auf. Frage vor einer Veröffentlichung, ob Leser ohne Vorwissen private Beziehungen ableiten oder eine ältere Bereitstellung direkt angreifen könnten. Verallgemeinere in diesem Fall die Formulierung. ## Forschungsdokumente mit automatischen Prüfungen aktuell und kurz halten Verwende eine geschichtete Dokumentationsstruktur: - eine stets geladene Orientierung mit Forschungsziel, Weiterleitungsmodell, Architektur und bereichsübergreifenden Invarianten; - Referenzdokumente zum aktuellen Zustand, die nur für das betreffende Teilsystem geladen werden; - ein Änderungsprotokoll und einen Versionsverlauf für früheres Verhalten. Hänge keine versionsweise Erzählung an Referenzen zum aktuellen Zustand an. Aktualisiere den bestehenden Eintrag auf die neue Wahrheit und bewahre geschichtliche Einzelheiten in der Versionsverwaltung und im Änderungsprotokoll auf. Erzwinge Größenbegrenzungen, verbotene historische Marker, die Aktualität des erzeugten Glossars und die Aktualität des Dokumentationspakets in der fortlaufenden Integration. Eine Textregel ohne automatische Schutzprüfung ist keine dauerhafte Beschränkung. ## Ausgabe und Einstellungen jedes Laufs vollständig aufbewahren Schreibe Fortschritt in einen von den Datenergebnissen getrennten Kanal. Halte Phasennamen stabil, mache strukturierten Fortschritt zu einer ausdrücklichen Option und stelle sicher, dass lang laufende Vorgänge Lebenszeichen senden, ohne maschinenlesbare Ergebnisse zu beschädigen. Erfasse bei Prüfungen und Auswertungen das vollständige Ergebnis in einer Datei, bevor du ein Ende oder eine gefilterte Zusammenfassung anzeigst. Zeichne den Endecode des ursprünglichen Befehls auf, bevor du ein Anzeigeprogramm startest. Leite eine Qualitätsprüfung niemals direkt durch einen kürzenden Befehl, weil die Verarbeitungskette den Erfolg des Anzeigeprogramms melden und zugleich die tatsächlichen Fehlerdetails verwerfen kann. Jeder Lauf muss Konfiguration, bestimmten Modus, Datensatzkennung, Hashes, Kennzahlen, Kosten, Warnungen, Endestatus und Zeitstempel aufbewahren. Ein Ergebnis ist nur dann entscheidungstauglich, wenn ein anderer Prüfer den Lauf rekonstruieren und gemessene Tatsachen von Annahmen unterscheiden kann.