So erstellen Sie eine Bewertungsdatenmenge aus echtem Traffik

Warum man keine Fragen aus der Dokumentation schreiben sollte

Die Dokumentation beschreibt das System so, wie es ihre Autoren verstehen. Fragen, die daraus abgeleitet werden, teilen die Annahmen der Autoren, erscheinen im Retrieval-Korpus als Paraphrasen und konzentrieren sich auf die Teile des Produkts, die gut dokumentiert sind, anstatt auf die Teile, die tatsächlich verwendet werden. Die resultierende Suite ist leicht zu bestehen und langsam zu ändern.

Der reale Datenverkehr hat eine entgegengesetzte Verteilung, was der Grund ist, warum es sich lohnt, ihn zu sammeln.

Vier Quellen, in der Reihenfolge ihrer Nützlichkeit

Suchprotokolle. Die Anfragen, die die Benutzer tatsächlich eingegeben haben, einschließlich derjenigen, die keine Ergebnisse lieferten. Zero-Ergebnis-Anfragen sind die günstigste Quelle für hochwertige Bewertungselemente, die es gibt, da sie bereits nach Themen gefiltert sind, die das System noch nicht behandelt.

Support-Tickets und interne Fragen. Jedes Mal, wenn ein Mensch gefragt und beantwortet wurde, obwohl das System die Frage hätte beantworten sollen, ist das eine Frage mit einer bekannten korrekten Antwort und einer identifizierten Kosten. Diese sind auch die Elemente, die am wahrscheinlichsten so formuliert sind, wie ein echter Benutzer sie formulieren würde.

Abgebrochene Sitzungen. Benutzer, die begonnen, etwas eingegeben und dann ohne Abschluss beendet haben. Schwieriger zu interpretieren, aber sie markieren die Grenze, wo das System derzeit versagt, auf eine Weise, die Zufriedenheitsdaten nicht können.

Experten-Erinnerung, absichtlich begrenzt. Setzen Sie sich mit zwei oder drei Personen, die die Arbeit ausführen, und fragen Sie, was sie am häufigsten gefragt werden und worauf die Antwort basiert. Verwenden Sie dies, um Lücken zu füllen, die die Protokolle nicht zeigen können, wie z. B. Fragen, die in Meetings gestellt und nie eingegeben wurden. Begrenzen Sie die Zeit, die hier verbracht wird; ihr Zweck ist die Abdeckung, nicht das Volumen.

Erstellung von Elementen, die eine Neubewertung überstehen

• Speichern Sie die Frage genau so, wie der Benutzer sie formuliert hat, einschließlich Tippfehlern und Abkürzungen. Das Umformulieren in saubere Sprache entfernt den Teil, der schwierig ist.
• Stellen Sie die erwartete Antwort und den Grund, warum sie korrekt ist, dar. Der Grund ist es, was das Element für jemand anderen neu bewertbar macht und verhindert, dass die Kriterien stillschweigend drifteten.
• Zeichnen Sie auf, wie sich das System verhalten soll, wenn die Antwort nicht im Korpus ist. Ungefähr ein Fünftel der Elemente sollte unbeantwortbar sein, und eine saubere Ablehnung sollte als Bestehen bewertet werden.
• Markieren Sie jedes Element mit der Fähigkeit, die es ausübt - Retrieval, arithmetische Operationen über abgerufene Werte, Multi-Dokument-Synthese, Ablehnung -, so dass Fehler auf ein bestimmtes Komponenten und nicht auf das System hinweisen.
• Notieren Sie die Quelle und das Datum. Elemente, die aus einem vorübergehenden Ereignis gezogen werden, verlieren ihre Gültigkeit, wenn die Daten des Ereignisses aus dem Korpus entfernt werden.

Es als Gewohnheit durchführen

Monatlich stichprobenweise und nicht nur einmal. Überprüfen Sie die Suite quartalsweise und entfernen Sie, was nicht mehr das Produkt widerspiegelt. Behalten Sie einen menschlich bewerteten Ausschnitt permanent, da dies der einzige Teil ist, der bemerkt, wenn die Definition einer guten Antwort sich ändert.

Der erste Durchlauf wird unangenehm sein. Eine Suite, die aus dem Datenverkehr erstellt wurde, berichtet typischerweise über eine wesentlich niedrigere Qualität als die aus der Dokumentation abgeleitete Suite, die sie ersetzt, und diese Lücke ist die Menge an Qualität, die die alte Suite verborgen hat. Berichten Sie beide Zahlen nebeneinander, führen Sie die Differenz auf die Änderung der Kriterien zurück und arbeiten Sie dann von der ehrlichen Grundlage aus.