Was 12.727 E-Mails über Graphen lehren
Wir haben vier Verfahren, Fragen aus Dokumenten zu beantworten, auf denselben Korpus und dieselben Fragen gesetzt. Ein lexikalisches Verfahren von 1994 hat gewonnen. Warum wir das veröffentlichen, und warum der Graph, den wir bauen, sein Schema aus Fragen ableitet.
Jeder Anbieter in unserem Feld sagt, seine Suche sei besser. Wenige zeigen eine Tabelle. Das hier ist unsere, und sie beginnt mit einem Ergebnis, das wir lieber nicht bekommen hätten.
Der Korpus ist öffentlich: das Enron-E-Mail-Archiv, der Standard-Benchmark für Fragen an private Firmenpost, weil es der einzige große Bestand echter Unternehmenskorrespondenz ist, den jemand benutzen darf. Wir haben ihn dedupliziert, denn die Hälfte der 517.401 Nachrichten ist dieselbe Mail in mehreren Ordnern, und die ersten fünf Prozent nach Datum genommen: 12.727 E-Mails. Die Fragen stammen aus EnronQA, einem veröffentlichten Satz von über einer halben Million Frage-Antwort-Paaren zu genau diesen E-Mails. 4.783 davon sind aus unserem Ausschnitt beantwortbar, und jede Engine bekam genau diese.
Vier Engines, ein Antwortmodell
Die vier. BM25, ein lexikalischer Index von 1994, ohne Modell darin. Dense , der Einbettungsindex, den die meisten Produkte meinen, wenn sie KI-Suche sagen. AutoSchemaKG mit HippoRAG, eine offene Tripel-Extraktion mit PageRank-Suche über dem entstehenden Graphen. Und Microsoft GraphRAG. Jede Engine reicht ihren gefundenen Kontext an dasselbe Antwortmodell mit demselben Zeichenbudget, die Grafik misst also die Suche und sonst nichts. Nebenher lief ein früher -typisierter Graph von uns, in dem ein Sprachmodell nur extrahieren darf, was eine erlaubt. Er bleibt aus der Grafik heraus: Er war ein erster Versuch mit einem Schema, das zu diesem Korpus nicht passte, und was er gelehrt hat, steht weiter unten.
BM25 gewinnt auf beiden Maßen, kostet im Aufbau nichts und antwortet in 32 Millisekunden. Dense folgt. Beide Graphen liegen dahinter.
Warum wir das trotzdem veröffentlichen
Weil die Zahl eine Eigenschaft der Frage ist, und das zu wissen ist mehr wert als eine schmeichelhafte Grafik. EnronQA-Fragen wurden aus ihrer Quell-E-Mail erzeugt, sie erben also deren Vokabular: Namen, Börsenkürzel, Deal-Nummern. Ein Sprung, ein Postfach. Das ist der Idealfall für Wortabgleich, und es ist nicht das, wofür ein Graph da ist. Ein Graph verdient seine Kosten, wenn die Antwort zwei Dokumente verbinden muss, die kein gemeinsames Vokabular haben, wenn „wer hat das freigegeben“ einer Kette von einem Memo zu einem Namen zu einer Rolle folgen muss. Der öffentliche Mehrsprung-Satz für Enron, ConcurrentQA, enthält 400 reine E-Mail-Fragen. Null davon haben beide Sprünge in unserem Fünf-Prozent-Ausschnitt. Die Achse, auf der der Graph gewinnen sollte, war nicht im Test. Wir haben inzwischen den Korpus gebaut, der sie enthält, 46.151 Nachrichten, definiert über die Belege, die die Fragen nennen, statt über einen Datumsschnitt, und dieser Lauf ist der nächste.
Der zweite Grund ist Disziplin. Wenn eine Grundlinie von 1994 Ihre Engine bei einer Aufgabe schlägt, muss jede künftige Engine sie überspringen, bevor sie eine Verbesserung heißen darf. Diese Latte liegt jetzt dauerhaft in unserem Prüfstand.
Was der Graph über sich selbst verraten hat
Die Punktzahlen verdecken den interessanteren Befund, und der ist struktureller Art. Die offene Extraktion erzeugte einen Graphen mit 236.053 Knoten und 355.914 Kanten, 65 Prozent der Knoten in einer zusammenhängenden Komponente: organisch verdrahtet, weil offene Tripel fast jedes Paar von Entitäten verbinden, das sich einen Satz teilt. Unsere frühe -typisierte Extraktion, auf denselben E-Mails, erzeugte die entgegengesetzte Form. Die meisten ihrer Knoten hatten gar keine direkte Kante. Eine , geschrieben für das Bauen, fand in der Verwaltungspost eines Energiehändlers von Anfang 2000 fast nichts zu typisieren, und ein Graph ohne Kanten lässt sich nicht begehen. Das ist kein Urteil über einen der beiden Ansätze. Es ist eine Messung dessen, was passiert, wenn Schema und Korpus nicht zusammengehören.
Woher das Schema kommen muss
Diese Messung ist der Auftrag für die Pipeline, die wir jetzt bauen. Das Schema wird nicht von uns geschrieben und nicht von einem Modell geraten. Es wird aus Fragen abgeleitet. Jedes Regelwerk, das ein Projekt erfüllen muss, DIN, HOAI, die Landesbauordnung, wird Klausel für Klausel gelesen und in die Fragen übersetzt, die diese Klausel an ein Gebäude stellt. Die Ingenieure ergänzen die Fragen, die sie ihrem eigenen Projekt tatsächlich stellen. Zusammen ist das ein freigegebener Satz von Kompetenzfragen, und die wird daraus Frage für Frage gebaut, jede Ergänzung gegen die Fragen geprüft, die sie beantworten soll. Anforderungen werden zu Regeln, die der Graph durchsetzen kann. Erst dann beginnt die Extraktion, und ein Modell darf nur extrahieren, was diese erlaubt, geprüft, während jede Tatsache ankommt.
Die andere Hälfte ist, dass dieselbe die Fragen beantwortet. Eine Frage, die zu einer der Kompetenzfragen passt, läuft über einen vorbereiteten, deterministischen Pfad und berührt kein Modell. Bei jeder anderen Frage sagt die , ob zwischen den gefragten Dingen überhaupt ein Pfad existiert, bevor irgendetwas erzeugt wird; gibt es keinen, erzeugt auch kein Prompt eine Antwort, und das System sagt das, statt zu raten. Die Rangfolge über Text ist der Rückfall für das, was die nicht ausdrücken kann, nicht der Regelfall.
Deshalb erwarten wir, dass es dort trägt, wo die Graphen oben nicht getragen haben. Der Vokabularbruch, der unseren frühen Graphen geleert hat, kann nicht auftreten, wenn das Schema aus den Fragen an den Korpus selbst abgeleitet ist. Jede Tatsache ist auf einem Pfad typisiert, den die Abfrageseite kennt, der Graph ist also von Konstruktion her begehbar. Und eine Antwort auf eine Kompetenzfrage ist jedes Mal dieselbe Antwort, mit der Klausel und der Seite, aus der sie stammt. Ob sich das in einer Zahl zeigt, ist die Aufgabe des Mehrsprung-Laufs, und gemessen wird es gegen dieselbe lexikalische Grundlinie wie alles andere.
Der Fehler, den die Zahlen gestanden haben
Noch etwas, das der Benchmark getan hat und eine Demo nie tun würde. Dieser frühe Aufbau schrieb jede extrahierte Tatsache allen fünf E-Mails zu, die er gerade las, nicht der einen, aus der sie stammte. Im Code hat es niemand gesehen. Der Graph hat es gezeigt: Bei 99,94 Prozent der Knoten war die Zahl der Erwähnungen durch fünf teilbar. Nachdem die Herkunft repariert war, ohne irgendetwas neu zu extrahieren, hat sich die Trefferquote der Suche auf einer Stichprobe etwa verdoppelt. Eine Tatsache, die die falsche Quelle nennt, ist schlimmer als keine, und gefunden wurde sie nur, weil wir gezählt haben.
Was wir daraus mitnehmen
Drei Regeln, alle inzwischen in Kraft. Gegen das billigste Verfahren messen, das überhaupt funktionieren könnte. Nie zwei Zahlen in eine Tabelle setzen, wenn Korpus, Prüfstand und Bewertung nicht dieselben sind. Und die Struktur des Graphen als eigenes Ergebnis behandeln, weil sie sagt, ob das Schema zu den Daten passt, bevor eine einzige Frage gestellt ist.
Der Mehrsprung-Lauf wird sagen, ob ein Graph dort gewinnt, wo er gewinnen soll. Bis dahin lautet der ehrliche Satz: Bei E-Mail-Fragen mit einem Sprung kauft ein Graph keine Suchqualität, und wir verkaufen ihn nicht so, als täte er es. Was ein Graph kauft, der in seinen eigenen Fragen gründet, ist die Antwort, die ihre Klausel und ihre Seite nennt, stillhält, wenn man zweimal fragt, und begehbar ist, wenn die Frage über mehrere Dokumente reicht. Das ist ein anderes Produkt, und es ist das, das wir bauen.
Daten: EnronQA (arXiv:2505.00263) und ConcurrentQA (arXiv:2203.11027), beide öffentlich. Korpusdefinitionen, Laufprotokolle und die vollständigen Tabellen je Engine liegen in unseren Laborseiten mit Commit und Datum; die Zahlen hier stammen aus dem Lauf vom Juli 2026.
Mehr aus dem Blog