Der Rohstoff für das ESG-Scoring ist überwiegend Fließtext. Ein Unternehmen weist seine Scope-1-Emissionen in einem 140-seitigen Nachhaltigkeitsbericht aus, versteckt in einem Absatz neben einer Fußnote, die unauffällig die Grenze dessen verschiebt, was überhaupt gemessen wurde. Der nächste Emittent meldet dieselbe Kennzahl in einer Tabelle, in anderen Einheiten und mit einem anderen Basisjahr. Multiplizieren Sie das mit ein paar tausend Berichtspflichtigen, und Sie haben das eigentliche Problem, das die ESG-Datenextraktion lösen muss: Die Information existiert, aber nicht in einer Form, die ein Modell direkt bewerten könnte.
An dieser Stelle unterschätzen Teams den Aufwand. Das Schwierige ist nicht, die Zahl von der Seite abzulesen. Es ist die Frage, ob zwei Zahlen von zwei Emittenten dasselbe bedeuten – und ob Sie das belegen können, wenn jemand danach fragt.
Die Extraktions-Pipeline
Die Architektur, die hier trägt, ist ein LLM in Kombination mit Retrieval über die Quelldokumente. Forschungssysteme wie ESGReveal beschreiben eine sinnvolle Aufteilung, die sich gut auf die Produktion übertragen lässt. Es gibt ein Metadaten-Modul, das die Kriterien kodiert, gegen die Sie extrahieren: was als Scope 2 zählt, welche Definition welches Rahmenwerks gilt, welche Einheiten zulässig sind. Es gibt ein Preprocessing-Modul, das den unübersichtlichen Berichtskorpus in eine abfragbare Datenbank überführt. Und es gibt einen Extraktions-Agenten, der die relevanten Passagen abruft und den strukturierten Wert herauszieht.
Ein RAG-ESG-Aufbau ist aus einem bestimmten Grund wichtig. Sie wollen nicht, dass das Modell aus seinen Trainingsdaten antwortet, denn diese wissen nicht, was ein bestimmtes Unternehmen im letzten Quartal offengelegt hat. Sie wollen, dass es aus den tatsächlichen Nachhaltigkeitsberichten antwortet – mit der abgerufenen Passage angehängt an jeden Wert, den es zurückgibt. Dieser Anhang ist keine nette Beigabe. Er ist es, der die nächsten beiden Schritte überhaupt erst ermöglicht.
Eine praxistaugliche Pipeline umfasst in der Regel:
- Dokumenten-Preprocessing, das die Seiten- und Tabellenstruktur erhält, sodass eine abgerufene Zahl ihren Fundort mitführt und nicht nur ihren Text
- Kriterien-Metadaten, die jede Zielkennzahl vor dem Extraktionslauf an eine Definition und eine erwartete Einheit binden
- Retrieval, das auf die richtige Meldung eingegrenzt ist, sodass der Wert von genau dem Emittenten und dem Zeitraum stammt, nach dem Sie gefragt haben
- Einen Extraktionsschritt, der den Wert jedes Mal zusammen mit der Passage zurückgibt, aus der er stammt
Normalisierung über Emittenten hinweg
Sind die Werte erst einmal extrahiert, sind sie noch nicht vergleichbar – und so zu tun, als wären sie es, ist der Weg zu schlechtem ESG-Scoring. Definitionen verschieben sich zwischen Emittenten und zwischen Berichtsjahren. Die Wasserverbrauchszahl des einen Unternehmens schließt aufbereitetes Wasser ein, die des nächsten nicht. Berichtsgrenzen verschieben sich nach einer Übernahme. Einheiten erscheinen im selben Datensatz in Tonnen, Kilotonnen und Short Tons.
In der Normalisierung steckt die eigentliche Beratungsarbeit. Sie bauen das Mapping von der lokalen Definition jedes Emittenten auf eine gemeinsame Definition, Sie dokumentieren die Umrechnungen, und Sie halten die Herkunftskette vom normalisierten Wert zurück bis zur Rohextraktion und zur Quellpassage aufrecht. Das ist dieselbe Disziplin der Entitätsauflösung und Abstimmung, die Finanzdaten verlangen – nur angewandt auf Offenlegungen statt auf Kurse. Wenn sich ein bewerteter Wert zwischen zwei Quartalen verändert, sollten Sie sagen können, ob das Unternehmen sein Verhalten geändert hat oder lediglich seine Definition. Ohne das misst ein ESG-Score ebenso sehr den Berichtsstil wie die tatsächliche Leistung.
Validierung und Ehrlichkeit gegenüber den Daten
Jeder extrahierte Wert sollte gegen seine Quellenangabe überprüfbar sein. Wenn die Pipeline sagt, die Emissionen eines Unternehmens betragen X, sollte ein Prüfer per Klick zur Seite springen und es bestätigen können – genauso, wie Sie eine Modellausgabe bis zu einem Quelldatensatz zurückverfolgen würden. Bauen Sie das Eval-Set aus Passagen, die ein Mensch bereits annotiert hat, und behandeln Sie die Extraktionsgenauigkeit als Kennzahl, die Sie über die Zeit verfolgen, statt sie einfach vorauszusetzen. Berichte ändern ihr Format von Jahr zu Jahr, und eine Pipeline, die mit den Vorlagen des letzten Jahres funktioniert hat, driftet bei denen dieses Jahres unbemerkt ab.
Die schwierigere Ehrlichkeit betrifft die Daten selbst. Ein großer Teil der ESG-Offenlegung ist selbst berichtet und nicht geprüft. Manches ist geschätzt, manches großzügig dargestellt, und manche Kennzahlen werden schlicht gar nicht offengelegt – sie hinterlassen Lücken, die Sie imputieren können, aber nicht kaschieren sollten. Gute Extraktion macht das sichtbar, statt es glattzubügeln. Wir geben lieber einen Wert mit dem Hinweis “selbst berichtet, Grenze unklar, geringe Konfidenz” zurück als eine saubere Zahl, die eine Genauigkeit suggeriert, die die Quelle nie hatte.
Genau darum geht es. Die Aufgabe der Pipeline ist nicht, ESG-Daten solide aussehen zu lassen. Sie besteht darin, sie nutzbar zu machen und zugleich klar zu benennen, wie solide jeder einzelne Wert tatsächlich ist – damit das darauf aufbauende Scoring gegenüber demjenigen verteidigbar bleibt, der danach handeln muss.