Die Antwort, die in zwei Dokumenten steht
Die Frage war, ob eine Lieferung noch im vereinbarten Zeitfenster lag. Das Lieferdatum stand in einem Dokument, das vereinbarte Fenster in einem anderen — und keine einzelne abgerufene Passage konnte je beides enthalten.
Die Frage, die beides brauchte
Nutzer eines Kundenassistenten fragten häufig, ob eine bestimmte Lieferung innerhalb der vereinbarten Frist lag. Für einen Menschen ist das eine Frage, für ein System sind es zwei Fakten: wann die Ware ankam, was im Auftrag steht, und wie das vereinbarte Fenster lautete, was eine Klausel in einem Rahmenvertrag ist.
Der Abruf lieferte das eine oder das andere und nie beides, und die erzeugten Antworten waren plausibel und unzuverlässig — denn ein Modell, das nur das Lieferdatum bekommt, argumentiert bereitwillig über ein Fenster, das es angenommen hat.
Die Antwort, die wir nicht gebaut haben
Das Verfahren, zu dem alle greifen, ist ein Wissensgraph: Entitäten und Relationen über den Bestand hinweg extrahieren und zur Anfragezeit traversieren, damit Fakten aus verschiedenen Dokumenten zusammenfinden. Gutiérrez und Kollegen veröffentlichten in jenem Monat eine Arbeit in diese Richtung, die einen Graphen über den Bestand baut und über einen assoziationsbasierten Abrufschritt verstreute Fakten in einem Schritt zusammenführt.
Das ist die richtige allgemeine Antwort, und wir haben sie nicht umgesetzt. Bevor wir einen allgemeinen Mechanismus bauen, haben wir die Anfragen gezählt: Dieses Muster machte rund drei Prozent des Verkehrs aus, und jeder einzelne Fall verband zwei Dokumente über eine Vertragsnummer, die beide bereits als Feld tragen.
Was wir stattdessen gebaut haben
Einen Join. Der Extraktionsschritt schreibt für beide Dokumenttypen ohnehin strukturierte Datensätze, beide Datensätze haben die Vertragsnummer, und die Frage zu beantworten ist eine Abfrage gegen diese zwei Tabellen plus ein Datumsvergleich im Code.
Das Modell ist am Vergleich überhaupt nicht beteiligt. Es liest die Frage, ruft eine Funktion mit einer Auftragsnummer auf und erhält ein kleines strukturiertes Ergebnis mit Lieferdatum, vereinbartem Fenster und der Angabe, ob das eine im anderen liegt. Danach schreibt es einen Satz — den Teil, in dem es gut ist.
| Situation | Was wir bauen würden |
|---|---|
| Dokumente teilen eine Kennung | Einen Join auf das Feld. Deterministisch und billig |
| Verbindung ergibt sich aus der Formulierung | Entitätsextraktion, dann einen Graphen |
| Die Verbindung ist selbst die Antwort | Einen Menschen. Das ist ein Urteil, kein Nachschlagen |
| Unter etwa fünf Prozent der Anfragen | Messen, bevor irgendetwas Allgemeines entsteht |
Warum hier die langweilige Variante gewinnt
Ein Join auf eine Kennung ist exakt, prüfbar und im Betrieb kostenlos. Es gibt keine Ähnlichkeitsschwelle zu justieren, keinen Extraktionsschritt aktuell zu halten, und wenn er nichts liefert, ist das eine Aussage über die Daten und kein Abruffehler, dem man nachgehen muss.
Ein Graph verdient seine Komplexität, wenn die Verbindung nirgends niedergeschrieben ist: wenn zwei Dokumente dieselbe Sache unterschiedlich benennen oder die Beziehung sich aus der Formulierung ergibt statt in einem Feld zu stehen. Unsere Dokumente waren nicht so, und ein allgemeiner Mechanismus für eine bereits vorhandene Verbindung wäre aufwendige Maschinerie um einen Fremdschlüssel herum.
Wie wir die drei Prozent gefunden haben
Wir haben einen Monat Fragen genommen, zweihundert davon gezogen und von Hand klassifiziert: beantwortbar aus einem Dokument, beantwortbar aus zweien, gar nicht aus Dokumenten beantwortbar. Das kostete einen Nachmittag und entschied die Architektur.
Dieser Schritt wird nach unserer Erfahrung am häufigsten übersprungen, von uns eingeschlossen. Die Versuchung ist, für die schwerste je gestellte Frage zu entwerfen statt für die Verteilung — und die Verteilung ist meist weit schiefer, als es sich aus einem Supportgespräch heraus anfühlt.
Der wirklich schwierige Teil
Nicht der Join. Schwierig war, dass etwa jeder neunte Auftrag eine Vertragsnummer nannte, die abgelöst worden war, und das richtige Fenster im Nachfolgevertrag stand. Mit dem ursprünglichen Vertrag zu antworten war auf eine Weise falsch, die keine Retrieval-Technik behoben hätte — denn der Abruf arbeitete korrekt auf einer veralteten Verbindung.
Wir haben die Nachfolgekette in der Abfrage mitverfolgt und geben sowohl das geltende Fenster als auch den Vertrag zurück, aus dem es stammt. Nutzer sehen, auf welchen Vertrag sich die Antwort stützt — was ihnen in strittigen Fällen wichtiger war als die Antwort selbst.
Wann wir umdenken würden
Stiege der Anteil der Zwei-Dokumente-Fragen Richtung eines Fünftels des Verkehrs, oder käme ein Bestand hinzu, in dem die Verbindungen keine Kennungen sind, würden wir den allgemeinen Mechanismus bauen. Wir lassen die Klassifikation der Anfragen quartalsweise laufen, damit das eine Zahl bleibt und kein Eindruck.
Das ist die eigentliche Position: nicht, dass Graphen überflüssig wären, sondern dass eine Messung entscheiden sollte — und dass diese Messung billig genug ist, dass Dringlichkeit sie nie rechtfertigt zu überspringen.
Was wir nicht behaupten
Wir behaupten nicht, ein Join ersetze assoziativen Abruf. Er funktioniert genau deshalb, weil unsere Dokumente ein Feld teilen, und ein Bestand, in dem die Verbindung semantisch statt eingetragen ist, braucht den Mechanismus, den wir nicht gebaut haben.
Wir behaupten auch nicht, unsere drei Prozent seien übertragbar. Sie sind eine Eigenschaft der Fragen eines Kunden und eines Dokumentbestands — übertragbar ist der Nachmittag des Zählens, nicht die Zahl, die dabei herauskam.