AI-Orchestrator: Automatisierte Portfolio-Analyse mit RAG
Value Proposition
Abschnitt betitelt „Value Proposition“Dieses Projekt implementiert eine End-to-End-Lösung für das automatisierte Management und die KI-gestützte Analyse eines Multi-Asset-Portfolios. Es kombiniert klassische ETL-Prozesse (Extract, Transform, Load) mit moderner GenAI-Architektur (RAG - Retrieval Augmented Generation), um nicht nur Daten zu aggregieren, sondern aktive Investment-Beratung basierend auf Echtzeit-Daten und makroökonomischen Analysen zu liefern.
Problem Statement
Abschnitt betitelt „Problem Statement“- Ich nutze unterschiedliche Konten, um Investitionen und Trades auszuführen. Hier ist es sehr schwer, den Überblick zu behalten. So habe ich bisher händisch ein Excel File genutzt, um eine anteilsmäßige Gesamtallokation nach Asset-Klassen, Regionen und Themenbereiche zu erreichen.
- Ich nutze unterschiedliche definierte Quellen, die ich zur Informationsbeschaffung heranziehe. Im Kopf kombiniere ich nun die Quellen zu einem gemeinsamen Verständnis. Dieses Verständnis prüfe ich dann wieder mit meinem Portfolio gegen und leite Handlungen ab.
1. Systemarchitektur & High-Level Design
Abschnitt betitelt „1. Systemarchitektur & High-Level Design“Das System wurde entwickelt, um die Fragmentierung von Finanzdaten (Krypto-Wallets, Neobroker, Bankkonten) zu überwinden. Anstatt statischer Excel-Tabellen kommt eine ereignisgesteuerte Architektur zum Einsatz, die Daten in Echtzeit normalisiert und anreichert.
Der Core-Stack
Abschnitt betitelt „Der Core-Stack“- Orchestrierung & Logik: n8n (Self-hosted)
- Datenbank & UI: Airtable (Relationales Schema)
- Intelligence Layer: Google Gemini (via LangChain in n8n)
- Knowledge Base: Vektordatenbank (für Substack-Analysen)
Abbildung 1: Der “AI Orchestrator” Workflow in n8n. Hier läuft die Logik zusammen: Der AI-Agent empfängt User-Queries, zieht Kontext aus der Datenbank und formuliert Antworten.
2. Datenmodellierung in Airtable (Single Source of Truth)
Abschnitt betitelt „2. Datenmodellierung in Airtable (Single Source of Truth)“Airtable fungiert nicht nur als Frontend, sondern als relationales Datenbanksystem (RDBMS). Das Schema wurde normalisiert, um Redundanzen zu vermeiden und präzise P/L-Berechnungen (Profit/Loss) zu ermöglichen.
Schema-Design
Abschnitt betitelt „Schema-Design“Basierend auf der Datei Airtable_ Projekt Assets - Schema und Beschreibung.md besteht die Architektur aus drei Kern-Tabellen:
- Holdings (Aggregations-Layer):
- Zeigt die konsolidierte Position pro Asset.
- Technik: Nutzt
Rollup-Felder, um Daten aus der Trades-Tabelle zu summieren (Total Quantity, Avg. Buy Price) und vergleicht diese mittelsLookupmit aktuellen Preisen aus Asset Data.
- Asset Data (Stammdaten):
- Enthält statische Daten (Symbol, ISIN, Sektor) und dynamische Marktdaten.
- Besonderheit: Dient als Referenzpunkt für Preis-Updates via API.
- Trades (Transaktions-Log):
- Unveränderliches Log aller Käufe/Verkäufe.
- Verknüpft mit Asset Data.
Abbildung 2: Die konsolidierte Ansicht in Airtable. Berechnung von unrealisierten Gewinnen in Echtzeit basierend auf den aggregierten Transaktionsdaten.
Automatisierung innerhalb Airtable
Abschnitt betitelt „Automatisierung innerhalb Airtable“Zusätzlich zu n8n werden native Airtable-Automatisierungen genutzt, um einfache Trigger-Events (z.B. “Statusänderung”) intern abzuwickeln, was die API-Last auf n8n reduziert.
Abbildung 3: Ereignis-Trigger innerhalb der Datenbank für sofortiges Feedback im UI.
3. ETL-Pipelines & Daten-Ingestion
Abschnitt betitelt „3. ETL-Pipelines & Daten-Ingestion“Die Datenbeschaffung erfolgt vollautomatisiert über n8n-Workflows. Hierbei wurden spezifische Pipelines für unterschiedliche Asset-Klassen entwickelt, um API-Rate-Limits und unterschiedliche Datenstrukturen zu handhaben.
3.1 Crypto-Trades (Binance API)
Abschnitt betitelt „3.1 Crypto-Trades (Binance API)“Dieser Workflow verbindet sich direkt mit der Binance API, um die Transaktionshistorie zu synchronisieren.
- Herausforderung: Gezielt die Trades für Wertepaare abrufen, für die Transaktionen stattgefunden haben. Sicherstellen, dass nur neue Trades gespeichert werden.
- Lösung:
Schritt 1: Abrufen des Kontostandes von Binance
Abschnitt betitelt „Schritt 1: Abrufen des Kontostandes von Binance“Um den aktuellen Kontostand von Binance abzurufen, wird eine Authentifierung mit einem HMAC-SHA256 (Hash-based Message Authentication Code) eingesetzt.
*Abbildung 4: Der ETL-Prozess um den aktuellen Kontostand abzurufen.
Schritt 2: Abrufen der getätigten Transaktionen
Abschnitt betitelt „Schritt 2: Abrufen der getätigten Transaktionen“Auch hier wird wieder eine HMAC-SHA256 zur Authentifizierung mit der Binance API genutzt. Da nun die aus dem ersten Schitt der Bestand an Coins in Erfahrung gebracht worden ist, wird dieser systematisch mit den möglichen Wertepaaren USDC, USDT und Euro kombiniert. Für diese Wertepaare wird die Binance API dann nach getätigten Transaktionen gequiried. Über die Transaktions wird als Unique Identifier sichergestellt, dass die Trades nicht schon in der Airtable-Tabelle vorhanden sind.
Abbildung 4: Der ETL-Prozess für Krypto-Transaktionen. Abruf -> Transformation -> Deduplizierung -> Load.
3.2 Preis-Aktualisierung (Multi-Source)
Abschnitt betitelt „3.2 Preis-Aktualisierung (Multi-Source)“Da Assets auf verschiedenen Märkten gehandelt werden (Aktien vs. Krypto), nutzt der Workflow ein Routing-System.
- Crypto: CoinGecko API / Binance API
- Traditional Finance: Yahoo Finance / Bavest API
- Logik: Der Workflow iteriert über die Asset Data Tabelle, prüft die
Price-SourceSpalte und routet die Anfrage an den entsprechenden API-Knoten.
Abbildung 5: Dynamischer Preis-Abruf. Der Workflow entscheidet basierend auf dem Asset-Typ, welche API angefragt wird.
4. Der AI-Analyst (RAG-Implementierung)
Abschnitt betitelt „4. Der AI-Analyst (RAG-Implementierung)“Das Herzstück des Projekts ist der “Senior Financial Advisor” Agent. Dieser geht über einfache Datenanzeige hinaus und interpretiert das Portfolio im Kontext makroökonomischer Entwicklungen.
Die RAG-Architektur (Retrieval Augmented Generation)
Abschnitt betitelt „Die RAG-Architektur (Retrieval Augmented Generation)“Um Halluzinationen zu vermeiden und fundierte Analysen zu liefern, nutzt der Agent zwei Kontext-Quellen:
- Strukturierter Kontext: Die aktuellen Portfolio-Daten aus Airtable (Bestand, Exposure, Performance).
- Unstrukturierter Kontext: Experten-Analysen von Substack (“Global Capital Flows”), die in einer Vektordatenbank (“Magic Minds”) gespeichert sind.
Knowledge Ingestion
Abschnitt betitelt „Knowledge Ingestion“Ein dedizierter Workflow scrapt relevante Substack-Artikel, chunked den Text und generiert Embeddings, die in der Vektordatenbank abgelegt werden.
Abbildung 6: Pipeline zur Befüllung der Vektordatenbank. Artikel werden in maschinenlesbare Vektoren umgewandelt.
Der Agent in Aktion
Abschnitt betitelt „Der Agent in Aktion“Der Agent (siehe Abbildung 1) nutzt LangChain-Tools in n8n. Wenn der User fragt: “Wie ist mein Exposure im Tech-Sektor und wie beeinflussen aktuelle Zinsentscheidungen mein Portfolio?”, führt der Agent folgende Schritte aus:
- Tool Call 1: Abfrage der Asset-Allokation aus Airtable (gefiltert nach “Theme/Sector”).
- Tool Call 2: Vektor-Suche in “Magic Minds” nach Artikeln zu “Interest Rates” und “Tech Valuations”.
- Synthese: Google Gemini generiert eine Antwort, die die persönlichen Holdings mit den Macro-Insights verknüpft.
5. Fazit & Ausblick
Abschnitt betitelt „5. Fazit & Ausblick“Dieses Projekt demonstriert, wie Low-Code-Tools (n8n, Airtable) in Kombination mit Enterprise-Grade AI-Modellen (Gemini) komplexe Finanzanalysen demokratisieren können.
Erreichte Meilensteine:
- Vollständige Eliminierung manueller Dateneingabe für Trades und Preise.
- Echtzeit-Überblick über Net-Worth und Asset-Distribution.
- Integration von qualitativem Expertenwissen (Substack) in quantitative Analysen.
Nächste Schritte:
- Implementierung von “Sentiment Analysis” auf News-Headlines für kurzfristige Warnsignale.
- Erweiterung der Steuer-Logik (FIFO/LIFO Berechnung) direkt in n8n.