Autofilterung von Suchanfragen erweitert – Über Sprache und Logik in der Suche

Spock: Das Logischste, was Sie hätten tun können, wäre gewesen, mich zurückzulassen. McCoy: Mr. Spock, erinnern Sie mich daran, Ihnen…

Spock: Das Logischste, was Sie hätten tun können, wäre gewesen, mich zurückzulassen. McCoy: Mr. Spock, erinnern Sie mich daran, Ihnen zu sagen, dass ich Ihre Logik satt habe.

Dies ist der dritte Teil einer Reihe von Blog-Beiträgen über eine Technik, die ich Query Autofiltering nenne – die Nutzung des Wissens, das im Suchindex selbst enthalten ist, um Abfragen besser zu analysieren und damit bessere Antworten auf Benutzerfragen zu geben. In der ersten Ausgabe wurde dargelegt, dass ein besseres Verständnis der Sprache und ihrer Verwendung bei der Formulierung von Suchanfragen uns dabei helfen kann, bessere Suchanwendungen zu entwickeln – insbesondere, wie Adjektive und Adverbien – die als Attribute oder Eigenschaften von Subjekt- oder Aktionswörtern (Substantive und Verben) betrachtet werden können – dazu gebracht werden sollten, Suchergebnisse zu verfeinern, anstatt sie zu erweitern – und warum die OOTB-Suchmaschine dies nicht richtig tut. Dies auf der Sprachebene zu lösen, ist ein schwieriges Problem. Eine praktikablere Lösung besteht darin, die beschreibenden Informationen, die wir zum Zwecke der Navigation und Anzeige bereits in unsere Suchindizes aufgenommen haben, zu nutzen, um die eingehende Anfrage zu analysieren. Auf diese Weise können wir Ergebnisse erzeugen, die der Absicht des Benutzers besser entsprechen. Der zweite Beitrag beschreibt einen Implementierungsansatz unter Verwendung des Lucene FieldCache, der automatisch erkennen kann, wenn Begriffe oder Phrasen in einer Abfrage in Metadatenfeldern enthalten sind, und der diese Informationen dann nutzt, um präzisere Abfragen zu erstellen. Anstatt also zu suchen und dann zu navigieren, sucht der Benutzer einfach und findet (auch wenn er kein Glück hat). Aus dieser Arbeit entwickelte sich ein interessantes Problem: Was tun, wenn mehr als ein Begriff in einer Abfrage mit demselben Metadatenfeld übereinstimmt? Es stellt sich heraus, dass die Antwort eine der Lieblingsfloskeln von Softwareberatern ist – „Es kommt darauf an“. Es hängt davon ab, ob das Feld ein- oder mehrwertig ist. Wenn man versteht, warum das so ist, kommt man zu einer sehr interessanten Erkenntnis: Logik in der Sprache ist nicht mehrdeutig, sondern kontextabhängig, und ein Teil des Kontexts ist das Wissen, über welche Art von Feld wir sprechen. Die Lösung dieses Problems versetzt uns in die Lage, korrekt auf boolesche Begriffe („und“ und „oder“) in Benutzeranfragen zu reagieren, anstatt sie einfach zu ignorieren (indem wir sie als Stoppwörter behandeln), wie wir es jetzt normalerweise tun.

Logik in der Mathematik vs. Logik in der Sprache

Die Logik ist natürlich sowohl für die Mathematik als auch für die Sprache grundlegend. In der Computertechnik ist sie besonders wichtig, da sie die Grundlage für den Betrieb eines digitalen Computers bildet. Ein weiterer Bereich, in dem die Logik vorherrscht, ist die Mengenlehre – die Mathematik der Gruppen – und in diesem Bereich kollidieren Sprache und Suche, denn bei der Suche geht es darum, eine Menge von Dokumenten zu finden, die einer bestimmten Anfrage entsprechen (Mengen können null oder mehr Elemente enthalten). Wenn wir uns auf die mathematischen Aspekte von Mengen konzentrieren, müssen wir präzise Operatoren definieren, um sie zu manipulieren – Schnittmenge, Vereinigung, Ausschluss – UND, ODER, NICHT usw. Logik in Software muss explizit sein oder mit globalen Standardwerten gehandhabt werden. Logik in der Sprache ist kontextabhängig – sie kann implizit oder explizit sein. Ein Beispiel für implizite Logik ist die Verwendung von Adjektiven als Verfeinerungen, wie das Beispiel „rotes Sofa“, das ich verwendet habe. Hier sucht der Benutzer eindeutig nach Dingen, die Sofas sind UND die Farbe Rot haben. Wenn der Benutzer nach „roten oder blauen Sofas“ fragt, gibt es zwei logische Operatoren, einen impliziten und einen expliziten – er möchte Sofas sehen, die entweder rot oder blau sind. Was aber, wenn der Benutzer nach „roten und blauen Sofas“ fragt? Er könnte nach Sofas in beiden Farben fragen, wenn er sich auf Sets bezieht, oder nach einzelnen Sofas, die sowohl rot als auch blau sind. Dies ist also etwas unklar, weil das Verfeinerungsfeld „Farbe“ noch nicht eindeutig definiert ist – kann ein einzelnes Sofa mehr als eine Farbe haben oder nur eine? Lassen Sie uns etwas wählen, das definitiv einwertig ist – die Größe. Wenn ich sage: „Zeigen Sie mir große oder extragroße T-Shirts“, ist die sprachliche Verwendung der Logik dieselbe wie die mathematische, aber wenn ich sage: „Zeigen Sie mir große und extragroße T-Shirts“, ist das nicht der Fall. Beide Ausdrücke bedeuten in der Sprache dasselbe, weil wir instinktiv verstehen, dass ein einzelnes Hemd nur eine Größe hat. Wenn wir also „und“ verwenden, meinen wir „zeig mir Hemden in beiden Größen“ und bei „oder“ meinen wir „zeig mir Hemden in einer der beiden Größen“, was in der Mengenlehre der gleichen Operation entspricht – UNION oder OR. Mit anderen Worten: „und“ und „oder“ sind in diesem Zusammenhang Synonyme! Für die Suche kann bei einwertigen Feldern nur ODER unterstützt werden, da die Verwendung von UND das Nichtergebnis – null Datensätze – liefert. Anders verhält es sich bei Attributen, für die eine einzelne Entität mehr als einen Wert haben kann. Wenn ich sage: „Zeige mir Hemden, die weich, warm und maschinenwaschbar sind“, dann meine ich die Überschneidung dieser Attribute – ich möchte nur Hemden sehen, die alle diese Eigenschaften haben. Wenn ich aber sage „Zeigen Sie mir Hemden, die bequem oder leicht sind“, dann erwarte ich Hemden mit mindestens einer dieser Eigenschaften, oder anders gesagt, die Vereinigung von bequemen und leichten Hemden. „Und“ und „oder“ sind jetzt Antonyme, wie in der Mathematik und Informatik. Das ist auch aus der Sicht der Suche sinnvoll, denn wir können entweder AND oder OR im Zusammenhang mit einem mehrwertigen Feld verwenden und erhalten trotzdem Ergebnisse. Um noch einmal auf das implizite vs. explizite zurückzukommen: In diesem Fall ist UND impliziert, denn ich kann sagen „zeige mir weiche, warme, maschinenwaschbare Hemden“, was dasselbe bedeutet wie „weiche, warme und maschinenwaschbare Hemden“. Wir kommen also zu dem Schluss, dass die Interpretation der umgangssprachlichen Verwendung von „und“ und „oder“ davon abhängt, ob die Werte für das betreffende Attribut exklusiv sind oder nicht (d.h. einwertig oder mehrwertig). Das heißt, „und“ bedeutet „beide“ (oder „alle“, wenn mehr als zwei Werte angegeben sind) und „oder“ bedeutet „entweder“ (bzw. „beliebig“). Wenn das Attribut einwertig ist, bedeutet „und“ „zeig mir beide Dinge“, wenn es mehrwertig ist, bedeutet es „zeig mir Dinge mit beiden Werten“. Bei „oder“ bedeuten einwertige Attribute „zeige mir beide Dinge“ und bei mehrwertigen „zeige mir Dinge mit beiden Werten“. Wie Mr. Spock sagen würde, ist das völlig logisch (RIP Leonard – wir werden Sie vermissen!)

Implementierung von kontextbezogener Logik in der Suche

Wenn wir besser verstehen, wie die Logik in der Sprache funktioniert und wie sie mit der Mathematik der Suchvorgänge zusammenhängt, können wir besser auf die implizite oder explizite Logik reagieren, die in Suchanfragen eingebettet ist – WENN – wir wissen, wie Begriffe auf Felder abgebildet werden und auf welche Art von Feldern sie abgebildet werden. Es stellt sich heraus, dass die Komponente Query Autofiltering uns diesen Kontext liefern kann – sie verwendet den Lucene FieldCache, um eine Zuordnung von Feldwerten zu Feldnamen zu erstellen – und sobald sie weiß, welchem Feld ein Teil der Abfrage zugeordnet ist, weiß sie, ob dieses Feld ein- oder mehrwertig ist. Wenn es also mehr als einen Wert für ein bestimmtes Feld in einer Abfrage gibt und dieses Feld einwertig ist, verwenden wir immer OR. Wenn das Feld mehrwertig ist, verwenden wir AND, wenn kein Operator angegeben ist, und OR, wenn „oder“ im Positionskontext der Feldwerte verwendet wird. Mit anderen Worten, wir prüfen, ob der Begriff „oder“ irgendwo zwischen der ersten und der letzten Instanz eines bestimmten Feldwertes vorkommt, wie z.B. in „leicht oder bequem“. Auf diese Weise können wir auch mit Phrasen umgehen, die mehrere logische Operatoren enthalten, wie z.B. „weiche, warme, maschinenwaschbare Hemden, die es in rot oder blau gibt“. Hier setzt das „oder“ das implizite „und“ der Liste der mehrwertigen Attribute nicht außer Kraft, da es sich außerhalb der Liste befindet. Es bezieht sich stattdessen auf die Werte der Farbe – die, wenn es sich um ein einzelnes Wertfeld im Index handelt, ignoriert wird und als Standardwert ODER verwendet wird. Hier ist der Code, der diese kontextbezogene Interpretation vornimmt. Wenn die Unterphrasen in der Abfrage auf Indexfelder abgebildet werden, werden die erste und die letzte Position der Phrasenmenge erfasst. Wenn das Feld dann mehrwertig ist, wird AND verwendet, es sei denn, der Begriff „or“ wurde eingestreut:

  SolrIndexSearcher searcher = rb.req.getSearcher();
  IndexSchema schema = searcher.getSchema();
  SchemaField field = schema.getField( fieldName );

  boolean useAnd = field.multiValued() && useAndForMultiValuedFields;
  // if query has 'or' in it and or is at a position
  // 'within' the values for this field ...
  if (useAnd) {
    for (int i = termPosRange[0] + 1; i < termPosRange[1]; i++ ) {
      String qToken = queryTokens.get( i );
      if (qToken.equalsIgnoreCase( "or" )) {
        useAnd = false;
        break;
      }
    }
  }

  StringBuilder qbldr = new StringBuilder( );
  for (String val : valList ) {
    if (qbldr.length() > 0) qbldr.append( (useAnd ? " AND " : " OR ") );
    qbldr.append( val );
  }

  return fieldName + ":(" + qbldr.toString() + ")" + suffix;

Der vollständige Quellcode für die QueryAutofilteringComponent ist auf github sowohl für Solr 4.x als auch für Solr 5.x verfügbar. (Aufgrund der API-Änderungen, die in Solr 5.0 eingeführt wurden, sind zwei Versionen dieses Codes erforderlich).

Demo

Um diese Konzepte in Aktion zu zeigen, habe ich einen Beispieldatensatz für ein hypothetisches Kaufhaus erstellt (verfügbar auf der github-Seite). Die Eingabedaten enthalten eine Reihe von Feldern, product_type, product_category, color, material, brand, style, consumer_type und so weiter. Hier sind ein paar Beispieldatensätze:

  <doc>
    <field name="id">17</field>
    <field name="product_type">boxer shorts</field>
    <field name="product_category">underwear</field>
    <field name="color">white</field>
    <field name="brand">Fruit of the Loom</field>
    <field name="consumer_type">mens</field>
  </doc>
  . . .
  <doc>
    <field name="id">95</field>
    <field name="product_type">sweatshirt</field>
    <field name="product_category">shirt</field>
    <field name="style">V neck</field>
    <field name="style">short-sleeve</field>
    <field name="brand">J Crew Factory</field>
    <field name="color">grey</field>
    <field name="material">cotton</field>
    <field name="consumer_type">womens</field>
  </doc>  
  . . .
  <doc>
    <field name="id">154</field>
    <field name="product_type">crew socks</field>
    <field name="product_category">socks</field>
    <field name="color">white</field>
    <field name="brand">Joe Boxer</field>
    <field name="consumer_type">mens</field>
  </doc>
  . . .
  <doc>
    <field name="id">135</field>
    <field name="product_type">designer jeans</field>
    <field name="product_category">pants</field>
    <field name="brand">Calvin Klein</field>
    <field name="color">blue</field>
    <field name="style">pre-washed</field>
    <field name="style">boot-cut</field>
    <field name="consumer_type">womens</field>
  </doc>

Der Datensatz enthält eingebaute Mehrdeutigkeiten, bei denen ein einzelnes Token als Teil eines Produkttyps, Markennamens, einer Farbe oder eines Stils auftreten kann. Farbnamen sind gute Beispiele dafür, aber es gibt auch andere (Boxershorts das Produkt vs. Joe Boxer die Marke). Das Feld ‚Stil‘ ist mehrwertig. Hier finden Sie die schema.xml-Definitionen der Felder:

  
  <field name="brand"        type="string" indexed="true" stored="true" multiValued="false" />
  <field name="color"        type="string" indexed="true" stored="true" multiValued="false" />
  <field name="colors"       type="string" indexed="true" stored="true" multiValued="true" />
  <field name="material"     type="string" indexed="true" stored="true" multiValued="false" />
  <field name="product_type" type="string" indexed="true" stored="true" multiValued="false" />
  <field name="product_category" type="string" indexed="true" stored="true" multiValued="false" />
  <field name="consumer_type" type="string" indexed="true" stored="true" multiValued="false" />
  <field name="style"         type="string" indexed="true" stored="true" multiValued="true" />
  <field name="made_in"       type="string" indexed="true" stored="true" multiValued="false" />

Um diese String-Felder über eine „Freitext“-Box-und-eine-Schaltfläche-Abfrage durchsuchbar zu machen (z.B. q=rote Socken ), werden die Daten in das Catch-All-Textfeld ‚text‘ kopiert:

  
  <copyField source="color" dest="text" />
  <copyField source="colors" dest="text" />
  <copyField source="brand" dest="text" />
  <copyField source="material" dest="text" />
  <copyField source="product_type" dest="text" />
  <copyField source="product_category" dest="text" />
  <copyField source="consumer_type"  dest="text" />
  <copyField source="style"  dest="text" />
  <copyField source="made_in"  dest="text" />

Die Datei solrconfig enthält diese Zusätze für die Komponente QueryAutoFilteringComponent und einen Request Handler, der sie verwendet:

  
  <requestHandler name="/autofilter" class="solr.SearchHandler">
    <lst name="defaults">
      <str name="echoParams">explicit</str>
      <int name="rows">10</int>
      <str name="df">description</str>
    </lst>
     
    <arr name="first-components">
      <str>queryAutofiltering</str>
    </arr>
  </requestHandler>

  <searchComponent name="queryAutofiltering" class="org.apache.solr.handler.component.QueryAutoFilteringComponent" />

Beispiel 1: „Weißes Leinenparfüm“ Es gibt viele Beispiele für dieses Abfrageproblem im Datensatz, bei denen ein Begriff wie „weiß“ mehrdeutig ist, weil er sowohl in einem Markennamen als auch als Farbe vorkommen kann, aber dieses Beispiel hat zwei mehrdeutige Begriffe „weiß“ und „Leinen“, so dass es ein gutes Beispiel dafür ist, wie der Autofiltering-Parser funktioniert. Die Phrase „White Linen“ ist aus dem Datensatz als Marke bekannt und „Parfüm“ entspricht einem Produkttyp. Der grundlegende Autofilter-Algorithmus würde also „White“ als Farbe zuordnen und dann für „White Linen“ als Marke ablehnen, da es sich um eine längere Übereinstimmung handelt. Der Artikel „Weißes Leinenparfüm“ wird dann korrekt gefunden. Was aber, wenn ich nach „weiße Leinenhemden“ suche? In diesem Fall wird der einfache Algorithmus nicht übereinstimmen, da er das alternative Parsing „Farbe:weiß UND Material:Leinen“ nicht liefern kann. Das heißt, die Phrase „Weißes Leinen“ ist jetzt mehrdeutig. In diesem Fall wird eine zusätzliche Logik angewandt, um festzustellen, ob es mehr als eine mögliche Analyse dieser Phrase gibt. In diesem Fall erzeugt der Parser die folgende Abfrage:

((brand:"White Linen" OR (color:white AND material:linen)) AND product_category:shirts)

Da es keine Hemden aus weißem Leinen gibt (und wenn doch, wäre das Ergebnis immer noch korrekt), erhalten wir nur die Hemden zurück. Ähnlich verhält es sich mit dem Parfüm: Da es kein Parfüm aus Leinen gibt, erhalten wir nur das eine Produkt. Das bedeutet, dass ein Teil der Filterung hier in der Sammlung stattfindet. Der Parser weiß nicht, was auf globaler Ebene „Sinn“ macht und was nicht, aber der Datensatz weiß es – also erhalten wir die richtige Antwort. Beispiel 2: „weiße und graue Oberhemden“ In diesem Fall habe ich zwei Farbfelder erstellt: „Farbe“, das für einfarbige Artikel verwendet wird und einwertig ist, und „Farben“, das für mehrfarbige Artikel (wie gestreifte oder gemusterte Hemden) verwendet wird und mehrwertig ist. Wenn ich also Hemden im Datensatz habe, die einfarbig weiß und einfarbig grau sind, sowie gestreifte Hemden, die grau und weiß gestreift sind, und ich nach „weißen und grauen Hemden“ suche, wird meine Absicht vom Parser für die automatische Filterung als „zeige mir einfarbige Hemden in weiß und grau oder mehrfarbige Hemden, die sowohl weiß als auch grau enthalten“ interpretiert. Dies ist die boolesche Abfrage, die er erzeugt:

((product_type:"dress shirt" OR ((product_type:dress OR product_category:dress) 
AND (product_type:shirt OR product_category:shirt))) 
AND (color:(white OR grey) OR colors:(white AND grey)))

(Beachten Sie, dass auch eine redundante Abfrage für „Kleid“ und „Hemd“ erstellt wird, da „Kleid“ auch ein Produkttyp ist – aber dieses Abfragesegment liefert keine Ergebnisse, da kein Artikel sowohl ein „Kleid“ als auch ein „Hemd“ ist – es ist also nur eine kleine Leistungsverschwendung). Wenn ich die einfarbigen Artikel nicht haben möchte, kann ich nach „gestreifte weiße und graue Hemden“ suchen und nur diese Artikel erhalten (oder die Facetten verwenden). (Wir könnten auch einen Stil wie „mehrfarbig“ vs. „einfarbig“ verwenden, um eine Unterscheidung zu treffen, aber das ist vielleicht nicht sehr intuitiv). In diesem Fall sieht die Abfrage, die der Autofilter generiert, wie folgt aus:

((product_type:"dress shirt" OR ((product_type:dress OR product_category:dress) 
AND (product_type:shirt OR product_category:shirt))) 
AND (color:(white OR grey) OR colors:(white AND grey)) 
AND style:striped)

Es genügt zu sagen, dass die standardmäßige /select-Anfrageverarbeitung nichts von alledem tut. Fairerweise muss man sagen, dass die Relevanzeinstufung bei diesen Beispielen gut funktioniert, aber die Genauigkeit (Prozentsatz der richtigen oder positiven Ergebnisse) ist sehr gering. Sie können dies sehen, indem Sie die Anzahl der Ergebnisse vergleichen, die Sie mit dem /select Handler im Vergleich zum /autofilter Handler erhalten – in Bezug auf die Präzision ist es wie Tag und Nacht. Aber ist dieser Datensatz „zu künstlich“, um wirklich von Bedeutung zu sein? Für eCommerce-Daten glaube ich das nicht. Viele dieser Beispiele sind reale Produkte und Marketingdaten sind voll von Mehrdeutigkeiten, die Standard-Relevanzalgorithmen, die auf der Ebene einzelner Token arbeiten, einfach nicht berücksichtigen können. Der Autofilter geht mit Mehrdeutigkeit um, indem er feststellt, dass Phrasen in der Regel weniger mehrdeutig sind als Begriffe, aber er geht noch weiter, indem er ein alternatives Parsing anbietet, wenn die Phrase mehrdeutig ist. Wir möchten Mehrdeutigkeiten beseitigen, die sich aus der Tokenisierung ergeben, die wir an den Dokumenten und Abfragen vornehmen – echte Mehrdeutigkeiten können wir nicht beseitigen, wir müssen vielmehr angemessen auf sie reagieren.

Überlegungen zur Leistung:

Oberflächlich betrachtet scheint es, dass die Komponente zur automatischen Filterung von Suchanfragen einen gewissen Mehraufwand beim Parsen von Suchanfragen verursacht – wie viel, muss ich noch untersuchen. Eine höhere Präzision der Suchergebnisse hilft sowohl bei der Qualität der Ergebnisse als auch bei der Leistung, insbesondere bei sehr großen Datensätzen, denn zwei der teuersten Aufgaben, die eine Suchmaschine erledigen muss, sind Sortierung und Facettierung. Für beides ist der Zugriff auf die gesamte Ergebnismenge erforderlich. Weniger falsch-positive Ergebnisse bedeuten also, dass weniger Dinge sortiert (d.h. zurückgestuft) und facettiert werden müssen – und insgesamt schnellere Antworten. Und während das Relevanzranking falsch positive Ergebnisse von der ersten Seite verdrängen kann (oder sie sozusagen unter den Teppich kehren kann), kann die Facettierungsmaschine das nicht – sie zeigt alles an. In einigen der hier gezeigten Beispiele sind die Präzisionsgewinne enorm – in einigen Fällen um eine Größenordnung besser. Bei sehr großen Datensätzen würde man erwarten, dass sich dies deutlich positiv auf die Leistung auswirkt.

Autofilterung vs. Autophrasierung

Vor einiger Zeit habe ich eine andere Lösung für den Umgang mit Phrasen und den Umgang mit Synonymen mit mehreren Begriffen vorgestellt, die „Autophrasierung“(1,2). Was ist der Unterschied zwischen diesen beiden Dingen? Sie tun im Grunde das Gleiche – sie behandeln Substantivphrasen als einzelne Dinge, verwenden aber unterschiedliche Methoden und unterschiedliche Ressourcen. Beide können das Problem der Synonyme mit mehreren Begriffen lösen. Die Autophrasing-Lösung erfordert eine zusätzliche Metadaten-Datei „autophrases.txt“, die eine Liste von Mehrwortbegriffen enthält, die zur Darstellung einzelner Entitäten verwendet werden. Die Autofilter-Lösung bezieht dieselben Informationen aus den Sammlungsfeldern, so dass sie diese zusätzliche Datei nicht benötigt. Sie kann auch feldübergreifend arbeiten und andere Probleme lösen, wie z.B. die Umwandlung von umgangssprachlicher Logik in Suchmaschinenlogik, wie in diesem Beitrag beschrieben. Im Gegensatz dazu fehlt der Autophrasing-Lösung dieser „relationale Kontext“ – sie weiß zwar, dass eine Phrase eine einzelne Sache darstellt, aber sie weiß nicht, um welche Art von Sache es sich handelt und wie sie mit anderen Dingen zusammenhängt. Daher kann sie nicht wissen, was zu tun ist, wenn Benutzeranfragen logische semantische Konstrukte enthalten, die Feldgrenzen überschreiten. Wenn also bereits strukturierte Informationen in Ihrem Index vorhanden sind, was bei eCommerce-Daten in der Regel der Fall ist, sollten Sie die automatische Filterung verwenden. Autophrasierung ist besser geeignet, wenn Sie keine strukturierten Informationen haben – wie bei Datensätzen, die viel Text enthalten (bibliografisch) – und Sie einfach eine Disambiguierung von Phrasen wünschen. Oder Sie können die für die automatische Filterung benötigten strukturierten Daten generieren, indem Sie Ihre Inhalte mithilfe von NLP oder taxonomischen Ansätzen kategorisieren. Die Wahl der Kategorisierungsmethode kann von der Notwendigkeit eines „relationalen Kontextes“ abhängen, über den ich oben gesprochen habe. Taxonomisches Tagging kann diesen Kontext liefern – eine Taxonomie kann Dinge über Begriffe und Phrasen „wissen“, z.B. welche Art von Entitäten sie darstellen. Dies verschafft ihr einen Vorteil gegenüber Klassifizierungstechniken des maschinellen Lernens, bei denen die Beziehungen zwischen Begriffen und Zusammenhängen eher statistisch als semantisch definiert sind. Wenn ich zum Beispiel Dokumente über Softwaretechnologie durchsuche und auf die Begriffe „Cassandra“, „Couchbase“, „MongoDB“, „Neo4J“, „OrientDB“ und „NoSQL DB“ stoße, können sowohl maschinelles Lernen als auch taxonomische Ansätze feststellen/wissen, dass diese Begriffe miteinander in Beziehung stehen. Die Taxonomie versteht jedoch den Unterschied zwischen einem Begriff, der eine Klasse oder einen Typ von Dingen repräsentiert („NoSQL DB“) und einer Instanz einer Klasse/eines Typs („MongoDB“), während ein ML-Klassifikator dies nicht tun würde – er lernt zwar, dass sie verwandt sind, aber nicht, wie diese Beziehungen semantisch strukturiert sind. Die Taxonomie würde auch wissen, dass „Mongo“ ein Synonym für „MongoDB“ ist. Es ist zweifelhaft, dass ein ML-Algorithmus das verstehen würde. Dies ist ein entscheidender Aspekt für die automatische Filterung, denn sie muss sowohl wissen, welche Gruppen von Token eine Phrase bilden, als auch, was diese Phrasen darstellen. Es können auch Techniken zur Entitätsextraktion verwendet werden – reguläre Ausdrücke, Personen-, Firmen- und Ortsextraktoren – die ein lexikalisches Muster mit einem Metadatenfeldwert verknüpfen. Gazetteer oder White-List-Entity-Extraktoren können dasselbe für allgemeine Phrasen tun, die auf eine bestimmte Art und Weise gekennzeichnet werden müssen. Sobald dies geschehen ist, kann die Autofilterung all diese Bemühungen auf die Abfrage anwenden , um den gefundenen Kontext in den Mittelpunkt der Suche zu rücken. So wie wir traditionell die gleiche Token-Analyse in Lucene/Solr sowohl auf die Abfrage als auch auf die indizierten Dokumente anwenden, können wir dasselbe mit Klassifizierungstechnologien tun. Es ist also nicht so, dass die Autofilterung herkömmliche Klassifizierungstechniken ersetzen kann – diese arbeiten in der Regel an dem Dokument, in dem es viel Text zu verarbeiten gibt. Die Autofilterung kann diese Bemühungen unterstützen, da sie mit der Abfrage arbeitet, bei der es nicht viel Text zu verarbeiten gibt. Auch hier ist die Zeit von entscheidender Bedeutung. Wir können es uns nicht leisten, teure Textverarbeitungsalgorithmen zu verwenden, wie wir es bei der Indizierung von Daten tun (nun ja … sozusagen), denn in diesem Fall haben wir es mit dem zu tun, was ich HTT nenne – Human Tolerable Time. Erwarten Sie in naher Zukunft einen Blogbeitrag zu diesem Thema.