Erweiterte Rechtschreibprüfung mit Fusion 4

Schauen wir uns an, wie wir die Rechtschreibprüfung in Fusion 4 erweitern und verbessern können, indem wir die Anzahl der…

Schauen wir uns an, wie wir die Rechtschreibprüfung in Fusion 4 erweitern und verbessern können, indem wir die Anzahl der Vorkommen von Wörtern in Abfragen oder Dokumenten nutzen, um Rechtschreibfehler zu finden. Wenn z.B. zwei Abfragen ähnlich geschrieben sind, aber die eine zu viel Traffic (Kopf) und die andere zu wenig oder gar keinem Traffic (Schwanz) führt, dann ist sehr wahrscheinlich die Schwanzabfrage falsch geschrieben und die Kopfabfrage ist die richtige Schreibweise.

Der Auftrag „Rechtschreibkorrektur für Token und Phrasen“ in Fusion 4 extrahiert Schwanz-Token (ein Wort) und Phrasen (zwei Wörter) und findet ähnlich geschriebene Kopf-Token/Phrasen. Wenn für jedes Ende mehrere übereinstimmende Köpfe gefunden werden, kann der Auftrag diese vergleichen und die beste Korrektur anhand mehrerer konfigurierbarer Kriterien auswählen.

Wie Sie Rechtschreibkorrekturaufträge in Fusion 4 ausführen:

Wir werden einen E-Commerce-Datensatz von Kaggle verwenden, um zu zeigen, wie man Rechtschreibkorrekturen anhand von Signalen durchführt.

Fügen Sie in der Auftragsverwaltung von Fusion einen neuen Auftrag „Rechtschreibkorrektur für Token und Phrasen“ hinzu und geben Sie die Parameter wie folgt ein:

Sie können die Rechtschreibprüfung auf zwei Arten von Daten anwenden: Signaldaten oder Nicht-Signaldaten. Wenn Sie daran interessiert sind, Rechtschreibfehler in Abfragen aus Signaldaten zu finden, markieren Sie das Feld „Eingabe ist Signaldaten“.

Die Konfiguration muss angeben:

• Welche Sammlung die Signale enthält (der Parameter Input Collection)
• Welches Feld in der Sammlung die Abfragezeichenfolge enthält (der Parameter Abfragefeldname)
• Welches Feld die Zählung des Ereignisses enthält (wenn z.B. die Signaldaten der Standardeinstellung von Fusion folgen, ist count_i das Feld, das die Zählung des Rohsignals aufzeichnet, aggr_count_i ist das Feld, das die Zählung nach der Aggregation aufzeichnet)

Der Auftrag ermöglicht es Ihnen, die Abfrageleistung auf der Grundlage von zwei verschiedenen Ereignissen zu analysieren: Hauptereignis und Filterung/Sekundärereignis. Wenn Sie beispielsweise als Hauptereignis Klicks mit einer Mindestanzahl von 0 und als Filterereignis Abfragen mit einer Mindestanzahl von 20 angeben, filtert der Auftrag die Abfragen heraus, die mindestens 20 Mal durchsucht wurden, und überprüft unter diesen beliebten Abfragen, welche gar nicht oder nur wenige Male angeklickt wurden. Wenn Sie nur einen Ereignistyp haben, lassen Sie den Parameter Filtering Event Type leer. Sie können Ihr Wörterbuch auch in eine Sammlung hochladen, um die Schreibweisen damit zu vergleichen, und den Speicherort des Wörterbuchs im Parameter Wörterbuchsammlung und Wörterbuchfeld angeben. In E-Commerce-Anwendungsfällen kann z.B. der Katalog als Wörterbuch dienen, und der Auftrag prüft, ob die gefundenen Rechtschreibfehler nicht im Wörterbuch auftauchen, während die Korrekturen angezeigt werden.

Wenn Sie daran interessiert sind, Rechtschreibfehler in Inhaltsdokumenten (z.B. Beschreibungen) und nicht in Abfragen zu finden, dann deaktivieren Sie das Kontrollkästchen „Eingabe ist Signaldaten“. Außerdem müssen Sie die oben genannten Parameter für den Anwendungsfall Signaldaten nicht angeben.

Nachdem Sie die Konfiguration festgelegt haben, klicken Sie auf Ausführen > Starten. Wenn der Lauf abgeschlossen ist, sollte links neben der Schaltfläche Start der Status Erfolg angezeigt werden. Wenn der Lauf fehlschlägt, sollten Sie die Fehlermeldungen in der Auftragshistorie überprüfen. Wenn die Auftragshistorie Ihnen keinen Aufschluss darüber gibt, was schief gelaufen ist, können Sie den folgenden curl-Befehl in einem Terminal eingeben:

tail -f var/log/api/spark-driver-default.log | grep Rechtschreibfehler:

Nach Beendigung des Laufs werden Rechtschreibfehler und Korrekturen in der Ausgabesammlung ausgegeben. Ein Beispielsatz sieht folgendermaßen aus:

Sie können die Ergebnisausgabe zur einfachen Auswertung in eine CSV-Datei exportieren.

Verwendung der Ergebnisse der Korrektur von Rechtschreibfehlern

Die daraus resultierenden Korrekturen können auf verschiedene Weise verwendet werden. Zum Beispiel:

1. Geben Sie Rechtschreibfehler in die Synonymliste ein, um eine Autokorrektur durchzuführen. Bitte sehen Sie sich unseren Synonymdateimanager in Fusion an. (https://doc.lucidworks.com/fusion/3.0/Collections/Synonyms-Files.html)
2. Helfen Sie mit, die Konfiguration der Rechtschreibprüfung zu bewerten und zu steuern.
3. Fügen Sie Rechtschreibfehler in die Vorschlagslisten für Tippfehler oder Autosuggest ein.
4. Bereinigen Sie Dokumente (z.B. Produktkataloge oder Krankenakten), indem Sie Rechtschreibfehler in Korrekturen umwandeln.

Wenn Sie die Rechtschreibprüfung von Fusion mit der Rechtschreibprüfung von Solr vergleichen, ergeben sich folgende Vorteile:

1. Verfügen Sie über grundlegende Einstellungen für die Solr-Rechtschreibprüfung, wie z.B. minimale Präfixübereinstimmung, maximale Editierdistanz, minimale Länge des Rechtschreibfehlers, Zählschwellen für Rechtschreibfehler und Korrekturen.
2. Wenn die Signale erfasst werden, nachdem die Solr-Rechtschreibprüfung eingeschaltet wurde, dann sind die in den Signalen gefundenen Rechtschreibfehler hauptsächlich auf fehlerhafte Korrekturen oder keine Korrekturen von Solr zurückzuführen.
3. Der Job vergleicht potenzielle Korrekturen auf der Grundlage mehrerer Kriterien, nicht nur des Bearbeitungsabstands. Der Benutzer kann ganz einfach die Gewichtung der einzelnen Kriterien konfigurieren.
4. Anstatt einen festen Maximalwert für die Editierdistanz zu verwenden, verwenden wir einen Schwellenwert für die Editierdistanz im Verhältnis zur Abfragelänge, um mehr Spielraum für lange Abfragen zu haben. Genauer gesagt, wenden wir einen Filter an, so dass nur Paare mit edit_distance <= query_length/length_scale beibehalten werden. Wenn wir z.B. length_scale=4 wählen, muss bei Abfragen mit einer Länge zwischen 4 und 7 der Editierabstand 1 sein, um ausgewählt zu werden. Bei Abfragen mit einer Länge zwischen 8 und 11 kann die Editierdistanz 2 sein.
5. Da der Auftrag offline ausgeführt wird, kann er die Solr-Rechtschreibprüfung von teuren Aufgaben entlasten. So wird beispielsweise die maximale Anzahl der zu prüfenden Übereinstimmungen nicht begrenzt (der Parameter maxInspections in Solr) und es können umfassende Listen von Rechtschreibfehlern gefunden werden, die durch falsch gesetzte Leerzeichen entstehen (breakWords in Solr)
6. Dies ermöglicht eine Offline-Überprüfung durch einen Menschen, um sicherzustellen, dass alle Änderungen korrekt sind. Wenn Sie ein Wörterbuch (z.B. einen Produktkatalog) haben, das mit der Liste abgeglichen werden soll, geht der Auftrag die Ergebnisliste durch, um sicherzustellen, dass keine Rechtschreibfehler im Wörterbuch vorhanden sind und dass die Korrekturen im Wörterbuch vorhanden sind.

Korrektur von Rechtschreibfehlern Ergebnisse Auswertung

Oben sehen Sie ein Beispielergebnis, das in eine CSV-Datei exportiert wurde. Zur Erleichterung des Überprüfungsprozesses sind mehrere Felder vorgesehen. So werden die Ergebnisse beispielsweise standardmäßig nach „mis_string_len“ (absteigend) und „edit_dist“ (aufsteigend) sortiert, um die wahrscheinlichsten Korrekturen an die Spitze zu setzen. Auch „Tonübereinstimmung“ oder „Übereinstimmung des letzten Zeichens“ sind gute Kriterien, auf die Sie achten sollten. Sie können auch nach dem Verhältnis von Korrekturen zu Rechtschreibfehlern sortieren (das Feld „corCount_misCount_ratio“), um nur Korrekturen mit hohem Datenverkehr zu erhalten.

Mehrere zusätzliche Felder (wie in der Tabelle oben gezeigt) werden bereitgestellt, um Beziehungen zwischen den Token-Korrekturen und den Phrasen-Korrekturen offenzulegen und so die Liste weiter zu reduzieren. Die Intuition basiert auf der Idee einer Solr-Zuordnungsprüfung, d.h. eine legitime Token-Korrektur wird mit größerer Wahrscheinlichkeit in den Phrasenkorrekturen auftauchen. Konkret werden bei falsch geschriebenen Phrasen die falsch geschriebenen Token herausgetrennt und in das Feld „token_wise_correction“ gestellt. Wenn die zugehörige Token-Korrektur bereits in der Liste der Ein-Wort-Korrekturen enthalten ist, wird das Feld „collation_check“ als „Token-Korrektur enthalten“ gekennzeichnet, und der Benutzer kann wählen, ob er diese Phrasen-Fehlschreibungen auslassen möchte, um Doppelungen zu vermeiden.

Wir zählen auch, wie viele solcher Phrasenkorrekturen durch dieselbe Token-Korrektur gelöst werden können und tragen die Zahl in das Feld „token_corr_for_phrase_cnt“ ein. Wenn z.B. sowohl „outdoor servailance“ als auch „servailance camera“ durch die Korrektur von „servailance“ zu „surveillance“ gelöst werden können, dann ist diese Zahl 2, was ein gewisses Vertrauen für das Fallenlassen solcher Phrasenkorrekturen schafft und weiter bestätigt, dass „servailance“ zu „surveillance“ legitim ist. Es gibt auch Fälle, in denen die tokenweise Korrektur nicht in der Liste enthalten ist. Zum Beispiel wird „xbow“ zu „xbox“ nicht in die Liste aufgenommen, da es gefährlich sein kann, eine Editierdistanz von 1 in einem Wort der Länge 4 zuzulassen. Wenn jedoch mehrere Phrasenkorrekturen durch Änderung dieses Tokens vorgenommen werden können, können Sie diese Token-Korrektur in die Liste aufnehmen. (Beachten Sie, dass Phrasenkorrekturen mit einem Wert von 1 für „token_corr_for_phrase_cnt“ und mit „collation_check“, das als „token correction not included“ gekennzeichnet ist, potenziell problematische Korrekturen sein könnten).

Bei den Token-Korrekturen können Sie auf die Paare mit kurzer Zeichenlänge achten, die keine Zusammenstellung in Phrasen aufweisen. Es ist aber auch möglich, dass die Token-Korrekturen ihre entsprechenden Korrekturen auf Phrasenebene nicht im Signal erscheinen lassen oder nur in Ein-Wort-Abfragen auftauchen. Zum Beispiel wurde „broter“ nur als Ein-Wort-Abfrage verwendet, so dass keine Kollation in Phrasen gefunden wurde. Schließlich kennzeichnen wir Rechtschreibfehler, die auf falsch gesetzte Leerzeichen zurückzuführen sind, mit „combine/break words“ im Feld „correction_types“. Wenn es ein vom Benutzer bereitgestelltes Wörterbuch gibt, gegen das geprüft werden kann, und beide Schreibweisen mit und ohne Leerzeichen in der Mitte im Wörterbuch enthalten sind, können wir diese Paare als bidirektionale Synonyme behandeln („combine/break words (bi-direction)“ im Feld „correction_types“).

Die gute Nachricht ist, dass Sie sich nicht um die oben genannten Regeln für die Überprüfung kümmern müssen. Es gibt ein Feld mit der Bezeichnung „suggested_corrections“, das explizit Vorschläge zur Verwendung der Token-Korrektur oder der Korrektur des ganzen Satzes enthält. Wenn das Vertrauen in die Korrektur nicht hoch ist, wird das Paar in diesem Feld als „Überprüfung“ gekennzeichnet. Sie können den Paaren mit der Kennzeichnung „review“ besondere Aufmerksamkeit widmen.

Wenn wir die mit Fusion gelieferte Solr-Rechtschreibprüfung verwenden, um neue und seltene Rechtschreibfehler zu korrigieren, und die erweiterte Rechtschreibprüfliste von Fusion, um die Korrekturgenauigkeit bei häufigen Rechtschreibfehlern zu verbessern, können wir in Kombination ein besseres Sucherlebnis für den Benutzer bieten.