Herkunft durch Konstruktion, nicht nachträglich
Extraktion ist LLM-gestützt. Speicherung und Abfrage sind es nicht. Zu sagen, welches welches ist, und es pro Tatsache zu belegen, ist der Unterschied zwischen „auditierbar“ und „vertrauen Sie uns“.
Jeder ernstzunehmende -Anbieter sagt irgendwann eine Version von „keine Halluzinationen“. Die ehrliche Version dieser Behauptung ist enger gefasst und es lohnt sich, sie klar auszusprechen, bevor ein skeptischer Leser fragen muss: Extraktion, der Schritt, der ein Dokument in eine Tatsache verwandelt, ist LLM-gestützt. Speicherung und Abfrage, was passiert, nachdem eine Tatsache im Graphen steht, ist es nicht. Beides zu verwechseln ist, wo das Marketing meist schiefgeht, und beides auseinanderzuhalten ist die Aufgabe der Ingenieursarbeit.
Zuerst das Unbequeme sagen
Ein LLM liest ein Dokument und schlägt eine Tatsache vor. Dieser Schritt erbt alles, was ein LLM erbt: Er kann einen Vorbehalt übersehen, falsch beurteilen, welcher Nebensatz welches Substantiv modifiziert, oder eine Einschränkung zu einer Gewissheit glätten. Das vorab zu benennen, macht den Rest des Arguments glaubwürdig. Ein Anbieter, der behauptet, seine Extraktion tue das nie, ist derjenige, dem ein technischer Käufer weniger trauen sollte, nicht mehr, weil es niemand überprüfen kann.
Was bei der Extraktion verloren geht
Nehmen Sie die Art Nachricht, mit der ein Firmen-E-Mail-Archiv tatsächlich voll ist, der Enron-Korpus, noch immer der öffentliche Standard-Benchmark für genau dieses Problem, ist eine gute Illustration: „Der Deal ist im Grunde durch, hängt noch an der rechtlichen Freigabe.“ Eine glatte Extraktion liest das als eine Tatsache: Deal genehmigt. Eine sorgfältige liest zwei: einen Status und eine an diesen Status geknüpfte Bedingung. Verdichten Sie den Satz zu „Deal 7743: genehmigt“ und der Vorbehalt, der Teil, auf den es ankommt, falls Legal nie unterschreibt, ist weg. Am entstehenden Triple sieht nichts falsch aus. Es ist nur nicht vollständig und ein Triple-Store hat keine native Möglichkeit, seine eigene Unvollständigkeit zu kennzeichnen.
Was Herkunftsnachweis bringt
Die Lösung ist nicht bessere Extraktion, Extraktion wird immer eine Fehlerrate haben. Die Lösung ist, dass sich jede Tatsache genau merkt, woher sie kam: welche Nachricht, von wem, zu welcher Zeit und wie sicher sich der Extraktionsschritt bei dieser Lesart war.
ex:fact-001
a rdf:Statement ;
rdf:subject ex:Deal_7743 ;
rdf:predicate ex:status ;
rdf:object "approved, pending legal sign-off" ;
prov:wasDerivedFrom <mailto:msg-19077@enron-corp.example> ;
prov:generatedAtTime "2001-09-14T11:02:00Z"^^xsd:dateTime ;
ex:confidence 0.71 .Nichts davon ist exotisch, es ist Standard-PROV-O-Reifikation, dasselbe Vokabular, das jeder RDF-Store ohne unser Zutun lesen kann. Was es bringt, ist einfach: Sollte sich „rechtliche Freigabe“ als entscheidend erweisen, ist der Beleg einen Klick von der Antwort bis zur ursprünglichen Nachricht entfernt, kein Vertrauensvorschuss in eine Blackbox.
Was passiert, wenn die Konfidenz niedrig ist
Eine Tatsache, extrahiert aus eindeutigem Text und eine, extrahiert aus einem vagen, informellen, sind nicht austauschbar und ein Graph, der sie identisch speichert, lügt durch Unterlassung. Extraktionen mit niedriger Konfidenz werden markiert, statt mit derselben Autorität präsentiert zu werden wie eine bestätigte Einreichung. Die Markierung beseitigt die Unsicherheit nicht, aber sie hält sie sichtbar.
Eine Behauptung lässt sich beweisen, die andere nicht
„Auditierbar“ ist eine Behauptung, die wir auf Verlangen beweisen können: Nachricht zeigen, Zeitstempel zeigen, Konfidenz zeigen. „Keine Halluzination“ ist keine Behauptung, die irgendjemand je beweisen kann, für irgendein System. Es lohnt sich, jeden Anbieter zu fragen, welche der beiden er gerade aufstellt.
Mehr aus dem Blog