Sechs Wochen stiller Relevanzrückgang

Die Form des Vorfalls

Eine Routineänderung wird verschifft: Der Index wird mit einem leicht unterschiedlichen Analyser neu aufgebaut, oder eine Synonymliste wird hinzugefügt, oder der Korpus wird nach einem Parser-Upgrade neu importiert. Jeder Test wird bestanden, weil jeder Test nur überprüft, ob der Endpunkt antwortet und dass die Antwort etwas Plausibles enthält. Sechs Wochen später liest jemand die Support-Warteschlange in der Reihenfolge durch und bemerkt, dass dieselbe Beschwerde, auf drei unterschiedliche Weisen formuliert, jede Woche erscheint.

Es gibt keinen Fehler zu finden. Es gab nie einen Fehler. Die Rangfolge hat sich geändert, und die Rangfolge ist keine Sache, die einen Test fehlschlagen lässt.

Warum End-to-End-Tests es nicht erkennen können

Eine Antwort-Ebene-Behauptung ist ein grobes Instrument. Wenn die Behauptung ist, dass die Antwort ein Thema erwähnt, wird sie bestanden, wenn der Absatz das Thema erwähnt und die falsche Frage beantwortet. Wenn die Behauptung ein von einem Menschen bewerteter Qualitätscore ist, bewertet der Bewerter normalerweise die Antwort isoliert, nicht im Vergleich zur vorherigen Antwort auf dieselbe Frage - so produziert eine Änderung, die jede Antwort ein wenig weniger relevant macht, ein wenig niedrigere Scores auf einer Skala, auf der ein wenig niedriger nicht von Rauschen zu unterscheiden ist.

Die Messung, die es erwischt hätte, ist vergleichend und mechanisch: Für eine feste Menge von Abfragen die Top-Ergebnisse speichern und sie immer dann diffen, wenn die Retrieval-Konfiguration geändert wird. Ein Chunk, der früher an erster Stelle stand und jetzt nicht mehr unter den Top-Ergebnissen ist, ist ein Signal, und es erfordert keinen Richter, um es zu interpretieren.

Rangfolge-Änderungen diffbar machen

• Eine goldene Abfrage-Menge beibehalten - ein paar hundert reale Abfragen sind ausreichend - und die identifizierten Rangfolge-Ergebnisse für jede als committete Baseline speichern.
• Bei jeder Änderung des Index, des Analyzers, des Einbettungsmodells oder des Chunkers die Rangfolge-Snapshot neu generieren und diffen. Melden, wie viele Abfragen ihr Top-Ergebnis geändert haben, nicht nur, ob der Durchschnitt verbessert wurde.
• Die beiden Richtungen trennen. Churn in einer Richtung ist oft beabsichtigt; Churn in beiden Richtungen, konzentriert in einer Dokumentenfamilie, ist normalerweise ein Parsing- oder Analyser-Defekt.
• Einen Grund für jede beabsichtigte Baseline-Aktualisierung anhängen. Eine Baseline, die ohne Erklärung aktualisiert wird, ist ein Rückgang, der als normal umklassifiziert wurde.
• Auf die Abfragen achten, die von einer korrekten Antwort zu einer falschen geändert haben, nicht auf die, die von falsch zu falsch geändert haben. Aggregierte Scores verbergen richtungsbezogenen Schaden.

Die Gewohnheit, die das zweite Auftreten verhindert

Die Retrieval-Konfiguration als versioniertes Artefakt mit eigenen Release-Notizen behandeln: Was geändert wurde, welche Abfragen verschoben wurden und welche Dokumentenfamilien betroffen waren. Dieser einzelne Absatz ist es, der einen sechswöchigen stillen Rückgang in ein Gespräch am selben Tag verwandelt, weil die Person, die die Änderung vorgenommen hat, den Kontext hat und noch verfügbar ist, um es zu verbessern.

Es legt auch den häufigeren Streit vor seinem Beginn bei. Wenn jemand behauptet, die Relevanz habe nachgelassen, zeigt der Diff entweder, dass es so ist oder nicht, und das Gespräch bewegt sich von Eindrücken zu einer spezifischen Liste von Abfragen.