Zweites Gehirn: Konvertierung von Sitzungsprotokollen in einen abfragbaren Wissensgraphen

Das Problem

Fast jede Organisation ist auf Meetings angewiesen, um die Arbeit voranzutreiben – Planungsbesprechungen, Anrufe mit Kunden, Sprint-Retrospektiven, Workshops zur Problemlösung. Jedes dieser Treffen erzeugt einen stetigen Fluss an Entscheidungen, Handlungsaufgaben, Risiken und Verpflichtungen. Und fast ausnahmslos verschwindet diese Information danach einfach wieder.

Die Protokolle landen irgendwo auf einem gemeinsamen Speicher. Die Handlungsaufgaben bleiben eine Weile in jemandes Notizbuch, verschwinden dann aber aus dem Gedächtnis. Wochen später fragt jemand nach den tatsächlichen Entscheidungen bezüglich eines bestimmten Vorgehens, und niemand kann eine klare Antwort geben.

Es handelt sich dabei eigentlich nicht um ein Speicherproblem – die Daten existieren schließlich irgendwo. Das eigentliche Problem ist, dass der Inhalt von Meetings unstrukturiert ist, über verschiedene Tools verstreut liegt und für jede Art von Suche praktisch unsichtbar bleibt.

Was benötigt wurde, war ein System, das in der Lage ist, Transkripte im großen Maßstab aufzunehmen, strukturiertes Wissen automatisch zu extrahieren und es den Nutzern zu ermöglichen, dieses Wissen in einfachem Englisch abzufragen – und gleichzeitig eine lebendige Karte der Beziehungen zu erstellen, die mit jeder hinzugefügten Besprechung reicher wird. Dieses System wurde Second Brain genannt.

Die Vision: Ein lebendiger Wissensgraph pro Projekt

Die zugrundeliegende Idee ist einfach. Jedes Mal, wenn ein Transkript einer Besprechung hochgeladen wird, analysiert das System es, um herauszufinden, wer über welches Projekt gesprochen hat, welche Entscheidungen getroffen wurden, welche Risiken aufgetreten sind und wer für welche nachfolgenden Schritte verantwortlich ist. All das wird in Azure Cosmos DB gespeichert. Von dort aus kann man eine Frage in natürlicher Sprache stellen und eine mit Aufzählungspunkten versehene, belegte Antwort erhalten.

Sobald immer mehr Transkripte anfallen, entsteht automatisch ein Wissensgraph – ein sich weiterentwickelndes Netzwerk, das Personen, Entscheidungen, Handlungen und Risiken in allen aufgezeichneten Sitzungen miteinander verbindet.

Die Lösungsinterface

Das System bietet eine interaktive Benutzeroberfläche, über die Nutzer Transkripte hochladen, extrahierte Entitäten durchsuchen, Fragen in natürlicher Sprache stellen und den entstehenden Wissensgraph visuell erkunden können.

Ein genauerer Blick auf die Komponenten

1. Extract_Entities_Tool – Parallelisierte Extraktion

Dieses Tool übernimmt die Hauptaufgabe. Ausgehend von einem Rohtextstring teilt es das Transkript in nach Abschnitten gruppierte Blöcke auf, führt für jeden Block gleichzeitig eine Entitätenextraktion mithilfe eines ThreadPoolExecutor durch und fügt die Ergebnisse anschließend zusammen, indem es jedem eindeutigen Wert eine Bewertung zuweist – basierend auf der Zuverlässigkeit der Extraktion sowie deren Häufigkeit.

Sieben Entitätsarten werden in einem mit Pfeilen getrennten Format definiert, dem das Sprachmodell konsequent folgen kann.

Dadurch erzeugt das Modell Ausgaben wie "Review architecture | Owner: Archana | Due: Next sprint" – einen String, den die Anwendung anschließend in strukturierte {task, owner, due}-Dictionaries parsen kann, die für eine detaillierte Darstellung sowie zum Erstellen von Kanten im Graphen bereit sind.

Autonome Entdeckung von Domänenbegriffen

Eine wichtige Gestaltungsoption bestand darin, den Eingabeparameter domain_context gänzlich wegzulassen und stattdessen dem Modell zu ermöglichen, das domänenbezogene Vokabular selbst zu entdecken. Jeder Prompt zur Extraktion von Teilstücken enthält einen speziellen Abschnitt, in dem das Modell aufgefordert wird, die im Text vorkommenden Domänenbegriffe, Abkürzungen und Systemnamen zu identifizieren.

2. Text2SQL_CosmosDB_Tool – Erinnerung in natürlicher Sprache

Dieser Komponente wird eine Frage in einfachem Englisch zusammen mit einem Hinweis zur Beschreibung des Cosmos-Schemas übergeben. Sie wandelt dies in eine Cosmos SQL-Anfrage um, führt sie aus und liefert anschließend eine zitierte Antwort aus den Ergebnissen. Der schwierige Punkt ist, dass der NoSQL-SQL-Dialekt von Cosmos DB es nicht zulässt, CONTAINS() direkt auf Array-Feldern anzuwenden. Die Lösung bestand darin, dem Tool einen expliziten Schema-Hinweis zu geben, der beschreibt, wie stattdessen mit Arrays gearbeitet werden soll.

3. Cosmos DB als das Gehirn selbst

Diese Datenbank bildet den Kern des gesamten Systems. Sie fungiert weder als Cache noch als Protokollspeicher – Cosmos DB ist im Grunde das zweite Gehirn, die persistente Speicherschicht, in der jedes extrahierte Wissensstück gespeichert, akkumuliert und abfragbar gemacht wird.

Jedes Dokument zur Extraktion von Treffen speichert jede Entität zweimal: einmal als flaches Array von Zeichenketten, das Abfragen auf SQL-Basis ermöglicht, und einmal als Array strukturierter Objekte, das eine detaillierte Anzeige in der Benutzeroberfläche sowie die Erstellung von Graphenkanten ermöglicht. Diese Doppelung führt zu einer geringen zusätzlichen Speichernutzung pro Dokument, vermeidet aber das Erfordernis, nach dem Zurückkommen der Daten aus der Datenbank auf Anwendungsebene etwas analysieren zu müssen.

Die Gehirn-Analogie – Zwei Arten von Speicher

Das menschliche Gedächtnis arbeitet in zwei unterschiedlichen Modi: dem episodischen Gedächtnis, das festhält, was während eines Ereignisses tatsächlich geschehen ist, und dem semantischen Gedächtnis, das allgemeine Fakten und Definitionen speichert – was eine Abkürzung bedeutet, wer eine bestimmte Person ist. Das Cosmos-Datenmodell wurde absichtlich so konzipiert, dass es diese Trennung widerspiegelt, indem es ereignisbezogene episodische Aufzeichnungen getrennt vom sich stetig erweiternden semantischen Wörterbuch mit Personen, Begriffen und Systemen speichert.

Wichtige ingenieurtechnische Entscheidungen

Mehrere bewusste Entscheidungen haben das Verhalten des Systems geprägt – von der Entscheidung, manuelle Domänekonfigurationen zugunsten automatischer Erkennung aufzugeben, über die redundante Speicherung von Entitäten für Anforderungen sowohl in SQL als auch in der Benutzeroberfläche, bis hin zur eng gefassten Rolle des LLM, das ausschließlich auf Extraktion und Erstellung von Abfragen beschränkt ist, anstatt Formatierung oder Geschäftsregeln selbst zu steuern.

Gelernte Erkenntnisse

1. Das Verhalten von Streamlit bei erneutem Ausführen erfordert eine bewusste Handhabung des Zustands. Jeder Klick auf einen Button lässt das gesamte Skript von vorne ausführen. Alles, was über mehrere Interaktionen hinweg erhalten bleiben muss, muss vor dem Zeichnen des Buttons, der das erneute Ausführen auslöst, in st.session_state gespeichert werden – und nicht danach.
2. Der SQL-Dialekt von Cosmos DB ist kein standardmäßiger ANSI SQL. Die CONTAINS()-Funktion funktioniert nur mit Zeichenketten, nicht mit Arrays. Daher benötigt das Modell eine explizite Anleitung in den Schema-Hinweisen – einschließlich mindestens eines Beispiels für die falsche Schreibweise der Abfrage.

Man kann Sprachmodellen nicht trauen, dass sie stets den Anweisungen zum Ausgabeformat folgen. Selbst bei klaren Syntheseanweisungen gibt das Modell gelegentlich nur einen kurzen Einleitungs-satz statt der vollständigen Antwort zurück. Aus diesem Grund ist ein deterministischer Ersatzmechanismus, der direkt aus den rohen, abgerufenen Daten eine Antwort erstellt, keine optionalen Verfeinerungen – er ist ein notwendiges Sicherheitsnetz.

Tools sollten enge, klar definierte Aufgabenbereiche haben. Es ist verlockend, Formatierungslogik, Geschäftsregeln oder Fachwissen direkt in ein Tool einzubauen, doch dieser Reiz sollte widerstanden werden – ein Tool sollte genau für eine Aufgabe zuständig sein.

Zum Darstellen von Pyvis-Diagrammen innerhalb von Streamlit muss in eine temporäre Datei geschrieben werden, anstatt einen In-Memory-String zu übergeben. Verwenden Sie tempfile.NamedTemporaryFile und vergessen Sie nicht, die Datei danach zu löschen. Es ist außerdem erwähnenswert, dass st.components.v1.html ab dem 01.06.2026 zur Deaktivierung vorgesehen ist, weshalb künftig st.iframe verwendet werden sollte.

Die zentrale Designidee

Die eigentliche Intelligenz in einem solchen System stammt nicht vom Sprachmodell – sie kommt aus dem dahinterliegenden Speichersystem.

Das Modell selbst verfügt überhaupt nicht über Speicher; es ist von Natur aus zustandslos. Es liest einen Teil des Transkripts und erzeugt eine Reihe von Entitäten. Es liest eine Frage und erzeugt eine SQL-Abfrage. Zwischen den Aufrufen bleibt nichts bestehen – jeder Aufruf beginnt völlig neu.

Cosmos DB ist der Ort, an dem das eigentliche Gedächtnis gespeichert wird. Sobald etwas im „Gehirn“ gespeichert wird, verwandelt sich das ursprünglich temporär aus dem Modell extrahierte Material in eine dauerhafte, strukturierte und suchbare Aufzeichnung. Das Glossar der Fachbegriffe wächst ständig weiter, und das Netzwerk der Beziehungen erweitert sich. Im Laufe der Zeit baut sich das Wissen kontinuierlich auf.

Das gesamte System läuft auf bereits vorhandener Infrastruktur – Azure VMs, Azure Functions, Azure Cosmos DB und Azure OpenAI – die über den AGF Hub koordiniert werden. Es wurden keine neuen Dienste eingeführt, und es war auch kein komplizierter Ablauf erforderlich. Was das System zum Funktionieren brachte, war ein sorgfältig entworfener Speicher für das Gedächtnis, klare Grenzen bezüglich der Verantwortlichkeiten jedes Tools sowie ein Sprachmodell, dessen Aufgabe lediglich darin besteht, Besprechungen vorzulesen, damit die Menschen das nicht selbst tun müssen.

Verwandte Artikel

• Warum die Kosten für agierende KI in die Höhe schießen: Ein kostenorientiertes Modell, das auf der Architektur basiert — Erklärt, warum die Kosten für LLM-Agenten nach abgeschlossenen Aufgaben und nicht nach Anrufen gemessen werden müssen, und skizziert architektonische Ansätze wie Modellrouting, Kontextbudgets und Caching zur Kostenkontrolle.
• AI-Agenten verstehen: Ziele, Werkzeuge, Speicher und der Agentenzyklus — Eine für Anfänger verständliche Erklärung, wie sich AI-Agenten von Chatbots unterscheiden, mit Schwerpunkt auf den Kernkomponenten, dem Entscheidungszyklus, den Autonomiegraden sowie praktischen Anwendungsfällen.

RAG gegen Agentic RAG gegen Graph RAG: Die richtige Sucharchitektur wählen — Erfahren Sie, warum herkömmliches RAG bei mehrstufigen Fragen und strukturierten Daten versagt, sowie wie agentebasierte Schleifen und graphbasierte Suchverfahren jeweils unterschiedliche Schwächen beheben.

Halluzinationen in einem medizinischen RAG-Chatbot-Pipeline reduzieren — Erfahren Sie, wie hybride Suchverfahren, Neubewertung der Ergebnisse und eine strenge Politik gegen das Erfinden von Inhalten zusammenwirken, um einen zuverlässigeren medizinischen Forschungs-Chatbot mit RAG zu erstellen.

Retrieval-Augmented Generation erläutert: Wie man Wissenslücken bei LLMs behebt — Erfahren Sie, warum LLMs Halluzinationen erzeugen und veraltet werden, und sehen Sie anschließend Schritt für Schritt, wie RAG Anfragen abruft, in Blöcke teilt, einbettet und erweitert, um dieses Problem zu lösen.