Von 3 Tagen Aktenlektüre zu einer 10-Minuten-Abfrage

Drei Investment-Profis. 450 Unternehmen auf ihrer Beobachtungsliste. Vor jeder vierteljährlichen Ausschusssitzung verbrachte jemand zwei bis drei Tage damit, PDFs zu lesen, um eine qualitative Zusammenfassung vorzubereiten. Das haben wir gebaut, um das zu beheben, und was es gekostet hat, es richtig zu machen.

TLDR

Emerald Wealth Partners ist ein privates Family Office. Das tatsächliche Portfolio ist bewusst klein, etwa 20 bis 25 Positionen. Aber die Beobachtungsliste dahinter ist bewusst breit: 450 börsennotierte Unternehmen, verfolgt als künftige Kandidaten, Wettbewerbs-Benchmarks und Branchenkontext. Drei Investment-Profis (ein Principal und zwei Associates) machen die gesamte Recherche.

FactSet deckt die Finanzdaten ab. Alles andere, was das Management über Preissetzungsmacht, Kapitaldisziplin, Wettbewerbsposition oder KI-Investitionen gesagt hat, kam weiterhin aus dem manuellen Lesen der Einreichungen.

Das Problem war die Zeit. Vor jeder vierteljährlichen Sitzung des Anlageausschusses verbrachte jemand zwei bis drei Tage damit, PDFs zu lesen, um eine qualitative Zusammenfassung zu erstellen. Für eine neue Position bedeutete tiefe Recherche, dass ein Associate die letzten vier Jahresberichte eines Unternehmens plus die jüngsten Transkripte der Ergebnis-Telefonkonferenzen (rund 1.200 Seiten) über mehrere Tage durcharbeitete.

Wir haben ein privates KI-Suchtool über ihrem gesamten Recherche-Korpus gebaut: 2.200 Jahresberichte und Transkripte von Ergebnis-Telefonkonferenzen über 400 Unternehmen. Die 50 übrigen Namen der Beobachtungsliste wurden ausgeschlossen, weil sie zum Zeitpunkt der Korpus-Erstellung noch keine vier Jahre SEC-Einreichungshistorie vorweisen konnten. Das Korpus umfasst die vier jüngsten Jahreseinreichungen pro Unternehmen (10-K und 20-F), plus Transkripte aus 8-K-Anhängen, sofern bei der SEC eingereicht.

Stellen Sie eine Frage in einfachem Englisch. Sie bekommen eine kurze, belegte Antwort. Sie sehen die exakte Passage, aus der sie stammt. Sie klicken zur ursprünglichen SEC-Einreichung oder zum Transkript. Alles läuft auf ihrer Infrastruktur. Ihre Abfragen verlassen nie ihre Umgebung.

10 min

Recherche-Vorbereitung für den Anlageausschuss

Vorher: 2–3 Tage manuelle Lektüre pro Sitzungszyklus.

3×

Neue Positionen pro Quartal bewertet

Das Team bewertet jetzt 12–15 neue Namen pro Quartal, vorher 4–5.

0%

Fehler bei Quellenangaben seit dem Go-live

Jede Antwort verlinkt die exakte Passage in der ursprünglichen Einreichung oder dem Transkript.

50+

Abfragen pro Woche nach 60 Tagen

Unternehmensvergleiche und historische Tonanalyse sind die häufigsten Typen.

Der Moment, der das Projekt begründete

Die vierteljährlichen Sitzungen des Anlageausschusses bei Emerald sind um eine qualitative Zusammenfassung herum aufgebaut: wie sich der Ton des Managements im gesamten Portfolio verschoben hat, was sich in der Sprache der Risikofaktoren geändert hat, ob das, was Unternehmen im letzten Jahresbericht angekündigt haben, in den jüngsten Ergebnis-Telefonkonferenzen auftaucht. Die Vorbereitung dieser Zusammenfassung dauerte jedes Quartal zwei bis drei Tage.

Vor einer bestimmten Sitzung wollte der Principal eine einfache Antwort. Hatten 15 Einzelhandels- und Konsumunternehmen in den letzten zwei Jahren konsistent darüber gesprochen, wie sie Zölle und steigende Kosten behandeln, oder hatte sich die Sprache leise verschoben? Um das zu beantworten, musste man etwa 60 Quartalseinreichungen dieser 15 Unternehmen lesen und das Ganze dann gegen das abgleichen, was in jeder Ergebnis-Telefonkonferenz gesagt wurde.

Der Associate arbeitete drei Tage daran. Die Ausschusssitzung fand am zweiten Tag statt. Der Principal kam mit lückenhaften Notizen herein.

Danach sagte sie das, was sie seit einem Jahr sagte: „Es muss einen besseren Weg geben, das zu machen.“ Diesmal bat sie uns, den Umfang zu prüfen.

Was sie bereits ausprobiert hatten

Eine der Associates hatte selbst einen Prototyp gebaut: die OpenAI-API, ein paar pro Sitzung hochgeladene PDFs und eine einfache Chat-Oberfläche. Das funktionierte für Fragen zu einem einzelnen Unternehmen und einer einzelnen Einreichung. Es konnte nicht mehr als ein oder zwei Dokumente im Kontext halten, was jede unternehmens- oder jahresübergreifende Frage ausschloss. Und gelegentlich verwiesen Antworten auf Passagen, die, gegen die ursprüngliche Einreichung geprüft, nicht ganz das sagten, was das Modell behauptete.

Sie nannte es plausible Halluzination. Die falsche Antwort klingt exakt richtig. Sie ist schlimmer als keine Antwort, weil man nicht weiß, dass man prüfen muss.

Zwei Investment-Memos gingen raus, die die Sprache des Managements eines Unternehmens zur Preissetzungsmacht zusammenfassten, mit Zitaten, die das Modell teilweise erfunden hatte. Die zitierten Passagen existierten. Die konkreten zitierten Sätze nicht. Es war keine große Sache, weil beide Memos für die interne Diskussion bestimmt waren.

Als sie zu uns kamen, war die Anforderung einfach: Entweder kommt die Antwort mit einer Quelle, auf die man klicken und sie verifizieren kann, oder es gibt keine Antwort.

FactSet, Bloomberg AI und allgemeine KI-Suchtools reichten nicht aus

Ihr FactSet-Abo behandelt quantitative Daten präzise. Wenn sie Umsätze, Margen, Verschuldungsquoten oder Konsensschätzungen brauchen, ist FactSet das richtige Werkzeug. Was die Standard-Forschungsstation von FactSet nicht kann, ist die Frage zu beantworten: „Wie hat dieses Management seinen Ansatz zur Kapitalallokation in den letzten fünf Jahresberichten beschrieben, und hat sich diese Sprache geändert?“ Diese Frage erfordert Lesen. FactSet hat in den letzten Jahren KI-Funktionen hinzugefügt, aber sie arbeiten über FactSets eigenes Datenuniversum, nicht über ein kuratiertes privates Korpus, das auf die 400 Unternehmen begrenzt ist, die sie tatsächlich verfolgen.

Allgemeine KI-Suchtools (Perplexity, integrierte KI-Funktionen in verschiedenen Research-Plattformen) zitieren Nachrichtenartikel und Analystenkommentare. Für fundamentale Recherche auf Basis von Primärquellen ist eine Paraphrase in einem Nachrichtenartikel keine Quellenangabe. Sie wollen den 10-K-Satz, nicht die Zusammenfassung von jemand anderem.

Der Prototyp der Associate hatte die richtigen Instinkte: privat, lokal, direkt aus Primärquellen arbeitend. Aber er funktionierte nur eine Sitzung lang. Er konnte keine dauerhafte Bibliothek mit 2.200 Dokumenten halten. Er konnte keine unternehmensübergreifenden Fragen beantworten, weil er nur ein oder zwei Dokumente gleichzeitig im Blick halten konnte. Und er erfand Dinge gerade oft genug, um unbrauchbar zu sein.

Was sie brauchten, war etwas, das das gesamte Korpus dauerhaft im Speicher hält, gleichzeitig nach Bedeutung und nach exakten Wörtern sucht und sich weigert zu antworten, wenn die Belege nicht stark genug sind, um eine selbstbewusste Antwort zu stützen. Dieses letzte Verhalten („keine Daten“ sagen, statt zu raten) war das Schwierigste, korrekt zu bauen.

Es gab auch eine Datenfrage, die sie früh aufwarfen und die wir ernst nahmen. Was Emerald recherchiert, ist das sensibelste mögliche Signal für ein Investment Office. Das durch die Systeme eines Drittanbieters zu verarbeiten, schuf ein Risiko, das sie nicht akzeptieren wollten. Das Tool läuft auf ihrer Infrastruktur mit ihren API-Keys. Eine Abfrage dazu, was Nvidia in seinen letzten drei Ergebnis-Telefonkonferenzen über Kapazität gesagt hat, berührt nie einen Server, der ihnen nicht gehört.

Der siebenwöchige Build

Sieben Wochen vom Kick-off bis zu einem Tool, das das Team vor ein echtes Ausschuss-Memo stellen konnte. Jede Woche brachte etwas Konkretes, und eine davon zu überspringen hätte ein Tool hinterlassen, dem niemand wirklich vertrauen konnte.

1. 01

   Discovery + Korpus-Scoping

   Definiert, welche 400 Unternehmen für die Beobachtungsliste wirklich zählten, damit das Tool von Tag eins Fragen zum richtigen Universum beantwortet

2. 02

   Ingestion-Pipeline: Einreichungen + Transkripte

   2.200 Jahresberichte und Ergebnis-Telefonkonferenz-Transkripte in einem durchsuchbaren Korpus vereint, das sich wöchentlich selbst aktualisiert, ohne Engineering-Aufwand

3. 03

   Klügere Suche + Unternehmensabgleich

   Die Engine, die sicherstellt, dass eine Frage zu einem Unternehmen nicht Antworten zu einem anderen liefert

4. 04

   Evaluierungs-Suite (von 13 auf 83 belegte Fälle)

   Ein dauerhafter Test, ob das Tool richtige Antworten liefert, nicht nur plausibel klingende, bevor jemand im Investment-Team es sah

5. 05

   Retrieval-Tuning + drei Versionen desselben Bugs

   Schloss die Lücke zwischen „liefert eine Antwort“ und „liefert jedes Mal die richtige Antwort“, inklusive Bugs, die Zitate dem falschen Unternehmen zugeordnet hätten

6. 06

   Treue-Ebene + Quellen-Viewer

   Jede Antwort verlinkt den exakten Satz, aus dem sie stammt, damit nichts in ein Ausschuss-Memo gelangt, das nicht mit einem Klick verifizierbar ist

7. 07

   CI-Gates + Übergabe

   Verankerte die Genauigkeitslatte dauerhaft, schulte das Team und übergab ein Tool, das sich selbst aktuell hält

Gebaut mit: OpenAI für die Such-Engine, Supabase zum Speichern und Durchsuchen des Korpus, SEC EDGARs öffentlichem Datenfeed zum Abrufen der Einreichungen und einer maßgeschneiderten Pipeline, um alles organisiert und durchsuchbar zu halten. Die Abfrageoberfläche ist eine leichte interne Web-App. Infrastruktur- und API-Kosten liegen bei etwa 150–250 US-Dollar pro Monat beim aktuellen Abfragevolumen des Teams.

Wie 2.200 Dokumente in ein durchsuchbares Korpus kommen

Die ersten zwei Wochen waren reine Einrichtung. Nichts anderes konnte gebaut werden, bis alle 2.200 Dokumente eingezogen, in durchsuchbare Stücke zerlegt und gespeichert waren.

Die Pipeline zieht jede Einreichung direkt von SEC EDGAR, entfernt die Formatierung und zerlegt das Dokument in zwei Ebenen. Kleine Passagen, etwa 220 Wörter pro Stück, sind das, was die Suche tatsächlich scannt, um die richtige Antwort zu finden. Größere Fenster, etwa 650 Wörter pro Stück, sind das, was das Tool liest, um die Antwort zu schreiben. Ein 220-Wörter-Ausschnitt hat selten genug umgebenden Kontext, um für sich allein zu funktionieren. Das Tool braucht die vollständigere Passage, um zu erklären, was es gefunden hat.

Die Transkripte der Ergebnis-Telefonkonferenzen brauchten einen anderen Ansatz. Viele Unternehmen reichen ihre Transkripte kurz nach dem Call bei der SEC ein, als Anhang zu einem Routinebericht. Die Pipeline zieht sie genauso ein wie andere Einreichungen, behandelt sie aber anders, sobald sie sie hat: Sie hält jede Analystenfrage mit ihrer Antwort gepaart, statt das Gespräch auseinanderzureißen.

Das Korpus umfasst auch ausländische Unternehmen der Beobachtungsliste wie ASML, TSMC und SAP, die andere Berichtstypen einreichen als US-Unternehmen. Die Pipeline behandelt beide. Manche dieser ausländischen Einreichungen entpuppen sich als leere Deckblätter ohne echten Inhalt. Sie werden protokolliert und automatisch übersprungen, ohne alles andere zu stoppen.

Ende von Woche 2: 400 Unternehmen, 2.200 Jahresberichte und Transkripte, etwa 160.000 durchsuchbare Passagen.

Die Pipeline läuft außerdem ab jetzt von selbst, im Wochenrhythmus. Sobald neue Einreichungen auf der SEC-Website landen, zieht sie sie ein und fügt sie dem Bestehenden hinzu, ohne etwas zu duplizieren oder von Grund auf neu aufzubauen. Jeder wöchentliche Lauf erzeugt einen Bericht darüber, was aktualisiert wurde und was gegebenenfalls übersprungen wurde. Kein Ingenieur muss es beaufsichtigen.

Die erste Version und warum sie still scheiterte

Die erste Version der Suche war nackt. Eine Frage kam herein, das Tool fand die 12 Passagen, die am ähnlichsten klangen, und das war die Antwort. Keine Prüfung, um welches Unternehmen es in der Frage wirklich ging. Kein Keyword-Abgleich neben der bedeutungsbasierten Suche. Keine Möglichkeit, „ich weiß es nicht“ zu sagen, wenn das Korpus nichts Relevantes hatte.

Sie funktionierte bei unkomplizierten Fragen. „Wie hat Nvidia über KI-Risiken in der Lieferkette gesprochen?“ lieferte Nvidia-Passagen. Alles andere scheiterte.

Eine Frage zum Kostendruck bei Vorleistungen konnte drei Passagen aus derselben Einreichung zu einem völlig anderen Thema liefern, nur weil die Formulierung ähnlich klang. Eine breite Frage wie „welche Unternehmen erwähnten Preisdiziplin in jüngsten Ergebnis-Telefonkonferenzen?“ lieferte sechs Mal dasselbe Unternehmen, weil nichts das Tool dazu trieb, aus mehreren Unternehmen zu schöpfen. Eine Frage zu einem Unternehmen, das gar nicht im Korpus war, bekam trotzdem eine selbstbewusst klingende Antwort.

Wir haben es gemessen. In etwa zwei Dritteln der Fälle war die richtige Passage nicht einmal das oberste Ergebnis. Jede spätere Korrektur zielte auf einen dieser konkreten Fehler.

Der Ticker-Bug: drei Erscheinungsformen

Der lehrreichste Fehler trat dreimal in verschiedenen Verkleidungen auf.

Die erste Version matchte Unternehmensnamen, indem sie prüfte, ob irgendein Teil des Namens irgendwo in der Frage auftauchte. Einbuchstabige Aktienticker brachen das sofort. AT&Ts Ticker ist „T“. Das Wort „discussed“ enthält den Buchstaben T. Jede Frage zur KI-Strategie wurde an AT&T geroutet, und auch an Disney, denn Disneys Ticker DIS steckt direkt im Wort „discussed“. Die Korrektur: nur ganze Wörter matchen, nie Buchstaben, die in anderen Wörtern versteckt sind.

Dann kam dasselbe Problem in neuer Form zurück, diesmal mit gewöhnlichen Wörtern in juristischen Unternehmensnamen. „Companies“ ist Teil von „Lowe’s Companies, Inc.“. Eine Frage wie „welche Unternehmen erwähnten Preisdiziplin?“ filterte die Ergebnisse auf Lowe’s herunter. „Electric“ ist Teil des Namens von General Electric. „Technology“ erscheint im vollen juristischen Namen mehrerer Unternehmen im Korpus. Die Korrektur: Jedes Wort, das im Namen mehr als eines Unternehmens vorkommt, wird aus der Matching-Liste entfernt, sodass nur Wörter übrig bleiben, die tatsächlich ein einzelnes Unternehmen identifizieren.

Drittens, Abkürzungen. Jemand, der „KI“ in eine Frage tippte, matchte keine Einreichungen, die „künstliche Intelligenz“ ausgeschrieben hatten. Ein Analyst, der nach KI-Investitionen suchte, verpasste die Hälfte der Ergebnisse, ohne es zu wissen. Die Korrektur: Das Tool expandiert jetzt gängige Abkürzungen, bevor es sucht.

Keines dieser Probleme zeigte sich allein beim Lesen des Codes. Alle drei wurden gefunden, weil die Test-Suite nach jeder Suche eine einfache Frage stellte: welche Unternehmen kamen tatsächlich zurück, und ist das die richtige Liste?

Der 40-Sekunden-Suchgeist

Etwa eine Woche lang dauerten Suchen 40 Sekunden. Wir hatten den Suchindex gebaut, bestätigt, dass er funktionierte, und beobachteten, wie jede Frage kroch.

Die Ursache war eine einzige Einstellung, vergraben in der Suchkonfiguration der Datenbank. Sie deckelte still jede Suche bei 40 Ergebnissen, egal wie viele tatsächlich angefordert waren. Breite Fragen, die 80 Ergebnisse brauchten, um Antworten aus mehreren Unternehmen zu ziehen, bekamen nur 40, ohne jede Warnung, dass etwas abgeschnitten wurde. Ergebnisse sahen einfach dünn aus, und das Ranking wirkte falsch. Obendrein erledigte die Suche für jede große Frage unnötige Zusatzarbeit im Hintergrund, was sie verlangsamte.

Eine einzige Einstellung zu ändern, behob es. Aber diese Einstellung zu finden, gelang nur, weil die Test-Suite schon die richtige Frage stellte: Warum liefert eine breite Suche ständig Ergebnisse desselben Unternehmens?

Messen, bevor man justiert

Bevor wir irgendwelche Sucheinstellungen anfassten, bauten wir eine beschriftete Test-Suite. Dreizehn handgeschriebene Fälle zum Start: Fragen, die bestimmte Unternehmen liefern müssen, Fragen, die bestimmte Themen an die Oberfläche bringen müssen, und Fragen, die nichts liefern müssen: Unternehmen, die nicht im Korpus sind, Themen, die in keiner Einreichung vorkommen.

Von dort wuchs die Suite, indem sie echte Themen aus dem tatsächlichen Korpus zog und Testfragen rund um sechs Kategorien generierte: ein einzelnes Unternehmen, direkte Vergleiche, historische Trends, Alias-Matching, gefilterte Suchen und absichtlich unbeantwortbare Fragen, die prüfen sollen, dass das Tool „keine Daten“ sagt statt zu raten. Jede generierte Testfrage wird vor ihrer Aufnahme in die Suite gegen das Live-Tool ausgeführt. Wenn das Tool sie mit dem aktuellen Korpus wirklich nicht beantworten kann, schafft sie die Frage nicht. Nichts in der Testdatei erwartet eine Antwort, die das Korpus nicht geben kann.

Die Suite wuchs auf 83 belegte Fälle. Sie zu bauen, fand mehr Probleme als das Code-Review.

Eine wiederkehrende Lektion: Die Testfragen müssen mit dem Korpus mitwachsen. „Welche Unternehmen erwähnten KI-Investitionen?“ wurde geschrieben, als nur eine Handvoll Unternehmen indexiert waren. Gegen die vollen 400 liefert eine gute Antwort 20 oder mehr verschiedene Unternehmen. Der ursprüngliche Test, geschrieben für eine kurze feste Liste, war falsch, nicht das Tool. Jeder solche Test prüft jetzt eine Mindestanzahl von Unternehmen statt einer exakten Liste, damit er Sinn behält, während das Korpus wächst.

29 Justierungsversuche, eine echte Verbesserung

Als die Test-Suite groß genug war, um ihr zu vertrauen, versuchten wir, die Suche zu justieren: wie viel Gewicht der bedeutungsbasierte gegenüber dem Keyword-Abgleich bekommt, wie viele Ergebnisse eine breite Frage einziehen soll und wie streng das Tool sein soll, bevor es einem Treffer genug vertraut, um überhaupt zu antworten. 29 verschiedene Kombinationen, jeweils eine Änderung auf einmal gegen denselben Fallsatz getestet.

Die Starteinstellungen waren bereits nah am Richtigen. Die eine echte Verbesserung: Weniger Ergebnisse für breite Fragen einzuziehen (40 statt 80) ließ die richtige Passage konsistenter höher ranken, ohne Genauigkeitsverlust. Ein kleinerer Pool bedeutete, dass die Passagen, die die Frage wirklich beantworteten, nicht unter schwächeren Treffern begraben wurden.

Der kontraintuitive Teil: Die beste Einstellung aus jeder Kategorie separat zu kombinieren, machte die Dinge schlechter statt besser. Die beste Keyword-Bedeutungs-Balance brach für sich genommen eine Vergleichsfrage. Die beste Poolgröße berührte dieselbe Frage allein nicht. Zusammen richteten beide Schaden an. Jede Änderung, die wir behielten, wurde vor dem Go-live erneut gegen die volle Suite getestet.

Sicherstellen, dass Antworten nicht über die Belege hinausdrifteten

Zu prüfen, dass jede Quellenangabe wirklich auf eine echte, abgerufene Passage zeigt, war die erste Absicherung. Notwendig, aber allein nicht genug. Eine Antwort kann echte Passagen zitieren und trotzdem etwas behaupten, das diese Passagen gar nicht sagen.

Deshalb prüft ein zweites KI-Modell die Arbeit des ersten. Nach jeder Antwort liest es die Antwort gegen ihre zitierten Passagen erneut und markiert jeden Satz, der über das hinausgeht, was die Belege tatsächlich aussagen. Der erste Lauf dieser Prüfung fing zwei Probleme, die die Quellenprüfung übersehen hatte.

Eine Antwort über Apple, Cisco und IBM enthielt einen Satz, der vernünftig klang, aber in keiner zitierten Passage stand. Es war eine kleine Schlussfolgerung des Modells, nichts, was eine Einreichung sagte. Eine Vergleichsantwort zog Passagen von Tesla und Rivian ab, erzeugte aber eine Antwort, die nur Rivian behandelte und still die halbe Vergleichsseite fallen ließ.

Zwei Korrekturen: Das Tool sagt dem Modell jetzt genau, welche Quellenangaben gültig sind, damit es aufhört, Zitatnummern zu erfinden, die ins Leere zeigen. Und wenn nichts, was das Modell schreibt, die Genauigkeitsprüfung besteht, zeigt die Fallback-Antwort jetzt 5 rohe Passagen statt 3, damit beide Seiten eines Vergleichs auch im Fallback auftauchen.

Diese beiden Korrekturen hoben die Bestehensquote der Genauigkeitsprüfung von 8 von 10 auf saubere 10 von 10.

Drei Dinge, die kaputtgingen

Die Evaluierung maß das Falsche

Drei Wochen später führten wir die Suite aus und bekamen eine Bestehensquote, die gesund aussah. Dann schauten wir, was „bestanden“ für eine Fallkategorie tatsächlich bedeutete.

Mehrere Fragen hatten feste Unternehmenslisten-Erwartungen, geschrieben, als das Korpus eine Handvoll Unternehmen hatte. Gegen 400 Unternehmen liefert eine gute Antwort auf „welche Management-Teams erwähnten Versorgungsengpass-Druck in jüngsten Ergebnis-Telefonkonferenzen?“ 30 oder 40 verschiedene Unternehmen. Der Drei-Unternehmen-Test, den wir geschrieben hatten, war falsch, nicht das Tool. Wir markierten richtige Antworten als Fehlschläge und bekamen eine Bestehensquote, die aus dem falschen Grund gesund aussah.

Diese Tests zu korrigieren, dauerte einen halben Tag. Dasselbe passierte zwei Wochen später erneut, als weitere ausländische Unternehmen hinzukamen. Testfragen brauchen laufende Pflege. Sie einmal zu schreiben und zu vergessen, funktioniert nicht.

Die Unternehmenserkennung brach nach einem Korpus-Update

Am Tag, nachdem wir 28 neue Unternehmen zum Korpus hinzugefügt hatten, verpasste das Tool einige von ihnen in den Ergebnissen. Nicht oft. Aber oft genug, um zu zählen.

Zwei der neuen Unternehmen hatten Namenswörter, die vom Matching hätten ausgeschlossen werden müssen, dieselbe „kommt im Namen mehrerer Unternehmen vor“-Regel wie beim Ticker-Bug oben. Aber diese Ausschlussliste war am Anfang von Hand gebaut und nie wieder geprüft worden, als neue Unternehmen hinzukamen. Sie war veraltet.

Die Korrektur: Jedes Mal, wenn ein neues Unternehmen hinzugefügt wird, prüft das System automatisch seinen Namen gegen die bestehende Matching-Liste, markiert Konflikte, bevor das Unternehmen live geht, und schreibt eine klare Zusammenfassung, worauf es matchen wird. Jemand kann diese Zusammenfassung prüfen, ohne Code zu lesen. Diese Prüfung läuft jetzt bei jedem Update, nicht nur beim ersten Mal.

Die Keine-Daten-Grenze verschob sich während der Entwicklung

Das Tool hat eine eingebaute Regel für Fragen, die es nicht wirklich beantworten kann. Wenn die gefundenen Belege zu dünn sind, um eine echte Antwort zu stützen, sagt es „keine Daten gefunden“, statt trotzdem zu raten. Das war von Tag eins eine Kernanforderung. Das Team war bereits einmal von Antworten verbrannt worden, die selbstbewusst klangen und falsch waren.

Aber während das Korpus noch aufgebaut wurde, hatten manche Unternehmen erst zwei oder drei Einreichungen indexiert. Fragen zu diesen Unternehmen überquerten manchmal die Latte für „genug Belege“ aus einem technischen Grund und produzierten Antworten, die technisch belegt, aber zu dünn zum Nutzen waren. Ein Associate konnte nicht sagen, ob eine schwache Antwort bedeutete, dass das Tool ein echtes Problem hatte, oder nur, dass die Einreichungen dieses Unternehmens noch nicht vollständig geladen waren.

Wir fügten ein Coverage-Flag hinzu: Wenn das abgefragte Unternehmen weniger als fünf indexierte Dokumente hat, enthält die Antwort einen Hinweis, dass die Abdeckung begrenzt ist. „Das System kann das nicht beantworten“ und „das Korpus hat noch nicht genug“ sind verschiedene Situationen mit verschiedenen Antworten: Die zweite hat einen Lösungsweg.

Die Ergebnisse nach 60 Tagen

Das Team von Emerald begann ab der ersten Woche nach dem Go-live, das Tool zu nutzen. Das qualitative Feedback war durchgängig: Das Tool entfernte den Flaschenhals, nicht das Denken. Zu finden, was Nvidia in seinen letzten vier Ergebnis-Telefonkonferenzen über Kapazitätsinvestitionen gesagt hat, dauert 10 Minuten und liefert die exakten Passagen mit Quellenlinks. Was das für die Investment-These bedeutet, bleibt die Aufgabe des Associates und dauert so lange, wie es dauern muss.

10 min

Vorbereitung des Anlageausschusses

Eine Research-Zusammenfassung, die früher 2–3 Tage brauchte, wird jetzt am Morgen der Sitzung erstellt.

12–15

Neue Positionen pro Quartal bewertet

Vorher 4–5. Dasselbe Drei-Personen-Team.

50+

Abfragen pro Woche

Meist Unternehmensvergleiche und historische Tonanalyse: die Fragen, die manuelles Lesen gar nicht beantworten konnte.

0

Fehler bei Quellenangaben seit dem Go-live

Jede [1] wurde gegen die Originalquelle verifiziert. Das Treue-Gate läuft bei jeder Antwort.

Der größere Wandel war nicht die Geschwindigkeit einzelner Abfragen. Es war, welche Fragen das Team sich überhaupt zu stellen traut. Etwas wie „wie hat dieses Management seine Kapitalallokationsphilosophie in den letzten fünf Jahren beschrieben, und ist die Sprache konkreter oder unkonkreter geworden?“ war früher eine Woche Arbeit, also lief niemand sie. Jetzt dauert sie 15 Minuten, also läuft sie.

Hier hatte Maßarbeit Sinn, eine Plattform nicht

Für Teams mit kleinen Dokumentsätzen und gelegentlichem Recherchebedarf reicht ein allgemeines KI-Tool (oder sogar ein gut gepflegter NotebookLM-Arbeitsbereich) wahrscheinlich aus. Dieses Projekt ergab für Emerald aus drei konkreten Gründen Sinn.

Erstens ist das Korpus zu groß und ändert sich zu oft für jedes Tool, das nur eine Sitzung lang funktioniert. 2.200 Dokumente bei der Übergabe, und jede Woche wachsend, sobald neue Jahresberichte und Transkripte eingereicht werden. Dokumente in jeder Sitzung neu hochzuladen, kann damit nicht Schritt halten.

Zweitens ist die Integrität der Quellenangaben nicht verhandelbar. Anlageentscheidungen (auch interne) hängen davon ab, die Quelle jeder Behauptung verifizieren zu können. Das Treue-Gate und die Deep-Links zu den ursprünglichen Einreichungen sind keine Nice-to-haves. Sie sind das Produkt.

Drittens, Datensensibilität. Die Rechercheaktivität eines Investment Offices (was sie untersuchen, welche Unternehmen sie sondieren, welche Fragen sie zur Glaubwürdigkeit des Managements oder zur Kapitaldisziplin stellen) ist proprietäres Signal. Das durch eine KI-Plattform eines Drittanbieters zu verarbeiten, schafft eine Offenlegung, die sie nicht akzeptieren wollten. Jede Abfrage bleibt in ihrer Umgebung.

Was wir anders machen würden

Wir würden die Test-Suite in Woche 1 starten, nicht in Woche 4. Der Ticker-Bug wäre in der ersten Woche gefunden worden statt drei Wochen später. Die 40-Sekunden-Verlangsamung wäre von Tag eins offensichtlich gewesen, denn „warum liefert eine breite Frage ständig Ergebnisse desselben Unternehmens?“ ist genau die Art von Frage, die eine Test-Suite stellen soll, nicht etwas, in das man später zufällig stolpert. Wir bauten die Test-Suite als Entwicklungswerkzeug und entdeckten ihren echten Wert erst durch das, was sie unterwegs fing. Wir hätten wissen sollen, wofür sie da ist, bevor wir sie brauchten.

Wir wären auch in Woche 1 aggressiver bei der Korpus-Zusammensetzung. Emerald hatte eine klare Vorstellung davon, welche Unternehmen zählten, aber keine schriftliche Definition des tatsächlichen Coverage-Universums des Tools. Manche Unternehmen standen aus klaren Gründen auf der Beobachtungsliste. Manche waren aus historischen Gründen dabei, die niemand rekonstruieren konnte. Ein Unternehmen erneut durch die Pipeline zu schicken, aktualisiert es nur, statt ein Duplikat zu erzeugen. Je früher die Unternehmensliste also festgezurrt wird, desto früher bleibt das Namens-Matching stabil und die Testfragen gültig.

Drittens würden wir einem Associate in Woche 4 statt Woche 7 eine Read-only-Version vorlegen. Unsere eigenen Tests fangen Logik-Bugs. Echte Recherchefragen fangen alles andere: Unternehmensnamen, die wir nicht eingeplant hatten, Ergebnis-Telefonkonferenz-Transkripte, die ungeschickt gesplittet wurden, Fragen so formuliert, wie Associates tatsächlich sprechen, statt wie wir uns das vorgestellt hatten. Eine Person, die eine Woche lang echte Fragen stellt, lehrte uns mehr als 20 weitere Fragen, die wir selbst geschrieben hätten.

Starten Sie die Evaluierungs-Suite am ersten Tag, finalisieren Sie das Korpus, bevor Sie etwas justieren, und setzen Sie einen echten Nutzer so früh wie möglich vor eine funktionierende Version. Der Build wird einfacher, sobald Sie wissen, was Sie wirklich messen. Alles davor ist fundiertes Raten.