Project AI - das Kind ohne Namen

0.0(0 votes)

ProjectAI ist ein in Python geschriebenes Workflow-Framework, das ich derzeitig hauptsächlich im Finanzwesen (Börsenhandel) nutze, um solide Aktien ausfindig zu machen. Noch hat das Kind keinen finalen Namen, intern nenne ich es aber schlicht ProjectAI.

Es ermöglicht, lokale und Cloud-basierte KI-Modelle nahtlos über Schnittstellen in bestehende, fremde Ökosysteme zu integrieren. Ein Workflow definiert einen sequenziellen Ablauf von Datenabrufen, Aktionen und Signalen über Module. Die Daten und Resultate von Workflows werden mittels JINJA2 Templates für die KI inhaltlich aufbereitet übergeben. Es steckt aktuell noch in einer frühen Entwicklung, aber es werden hier in zeitlichen Abständen die Analyseresultate aus Testläufen hochgeladen, in der Hoffnung, dass diese dem ein oder anderen helfen.

Vorwort

KI-Nachrichten sind allgegenwärtig, vielen geht das Thema mittlerweile fast schon auf die Nerven, während wieder andere darin eine fundamentale Bedrohung sehen.
Ich betrachte die Entwicklung gelassen: Eine KI sollte den Menschen ergänzen, nicht ersetzen. Warum also nicht das enorme Potenzial produktiv nutzen?

Rückblickend war und ist es für mich weit mehr als nur ein Projekt. Es war eine intensive Exkursion durch die Welt der künstlichen Intelligenz – voller Aha-Erlebnisse und verbunden mit einem massiven Wissensaufbau über technische Zusammenhänge sowie die noch bestehenden Grenzen der Technologie. Mehr dazu in der Vorgeschichte.

Vorgeschichte

Ende 2024 wollte ich wissen, wie tief sich eine KI mit häuslichen Mitteln in den Börsenhandel integrieren lässt. Was als kleines Experiment startete, hat sich inzwischen zu einem ernstzunehmenden Softwareprojekt entwickelt.

Machen wir uns nichts vor: Nirgendwo sonst trifft man auf so viele egozentrische Überredungskünstler wie im kapitalgetriebenen Finanzsektor.
Ihr Ziel? Kleinanleger gezielt in gehypte Aktien zu treiben, um Kurse künstlich zu pushen. By the way: Die Versicherungsbranche steht dem übrigens in nichts nach.

Zwar gibt es namhafte Big-Player, die derartige KI-Analysedienste anbieten, allerdings zu horrenden Abopreisen – für gelegentliche Privatanleger ist das völlig unwirtschaftlich. Daher begann ich, mit lokalen Modellen zu experimentieren. Ich wollte ein Gefühl dafür bekommen, wie sich kompakte, lokal betriebene Open-Source-Modelle im Vergleich zu den großen, bekannten Cloud-Modellen schlagen. Meine KI-Erfahrungen waren zu diesem Zeitpunkt noch rein grundlegender Natur.

Meine ersten Versuche basierten auf den Modellen BERT und BART (für Textzusammenfassungen), Qwen, DeepSeek, Ace Reason und NVIDIA's Nemotron-Reasoning-Modellen (für logische Operationen) sowie Llama, Mistral und Mixtral (für textuelle Auswertungen) bis hin zum aktuell eingesetzten Google Gemma 4, das hier in drei Ausführungen arbeitet und einen enormen Fortschritt zeigt. Mithilfe von Ollama, Oobabooga und aktuell KoboldCpp, habe ich die Modelle systematisch evaluiert und Benchmarks unterzogen.

Dabei zeigten sich schnell die drastischen Unterschiede in den Modellarchitekturen: Große Modelle hielten zwar mal mehr mal weniger fast fehlerfrei den roten Faden, waren auf einer reinen CPU jedoch quälend langsam. Kleine Modelle agierten zwar extrem flink, blieben dafür oberflächlich, verloren schnell den Kontext und begannen zu halluzinieren.

Um die Grenzen auszuloten, entwickelte ich ein Needle-in-a-Haystack-Szenario (Die Nadel im Heuhaufen). Ich fütterte die Modelle mit umfangreichen SEC-Finanzberichten von Unternehmen und setzte sie gezielt auf die Daten an. Über penibel optimierte Prompts (KI Persona und Anweisungen) ließ ich sie nach versteckten Risiken suchen:

  • Aktienverwässerungen
  • Management-Drifts
  • toxische Darlehen
  • kritische Asset-Beurteilungen
  • Wettbewerbsrisiken
  • Zu guter Letzt: Technische Charts inklusive Indikatoren interpretieren und auswerten

Besonders wichtig war mir dabei der Abgleich zwischen euphorischen PR-Aussagen und den nackten Zahlen der SEC-Dokumente.

Die kleinen Modelle scheiterten erwartungsgemäß, ihnen fehlte die kognitive Tiefe für derart komplexe Analysen. Größere Modelle erkannten immerhin bis zu 80 % der versteckten Informationen. Der eigentliche Durchbruch gelang jedoch erst, als ich die Gesamtaufgabe in kleinere Teilaufgaben splittete.

Vor mir lagen nun zwei Wege:

  1. Der Wechsel auf ein Cloud-Modell mit massivem Kontextfenster, Google bietet beispielsweise mit seinem GoogleOne Abo günstige Einstiege in die Gemini Pro Welt.
  2. Die Entwicklung eines lokalen Workflows, der komplexe Aufgaben intelligent auf mehrere spezialisierte KIs aufteilt.

Fasziniert von der zweiten Option, die sich zur Not mit einem kostenpflichtigen Abo Modell kombinieren lässen würde - sofern die Ergebnisse nicht überzeugen, begann ich mit der Entwicklung eines eigenen Python-Frameworks, das folgende Kernkriterien erfüllt:

  • Zentrale Task-Verwaltung: Eingehende Anfragen landen in einer zentralen Warteschlange (Queue) und werden von dort intelligent an die passende Verarbeitungseinheit übergeben.
  • Dynamisches Routing: Ein integrierter Router analysiert Aufgaben und entscheidet autonom, welches KI-Modell oder Modul optimal für die Lösung geeignet ist.
  • Modell-Lebenszyklus-Management: Das Framework integriert diverse lokale und Cloud-Modelle. Um Systemressourcen zu schonen, lädt und entlädt es Modelle vollautomatisch und bedarfsgesteuert.
  • Modulare Architektur: Eigenständige Module übernehmen die Dateneingabe, -verarbeitung und -ausgabe. Sie lassen sich flexibel kombinieren und für neue Funktionalitäten erweitern.
  • Cluster-Fähigkeit: Mehrere Instanzen können sich im Netzwerk zu einem Cluster zusammenschließen. Dies ermöglicht eine verteilte Aufgabenverarbeitung und nahtlose Skalierbarkeit.
  • YAML-Konfiguration: Das gesamte Systemverhalten – inklusive Modulketten, Clustereinstellungen und Modellparameter – wird zentral über lesbare YAML-Dateien gesteuert.
  • Memory & Session-Management: Eine persistente Session- und Memory-Komponente sorgt dafür, dass Konversationsverläufe und Kontextdaten über lange Zeiträume hinweg erhalten bleiben.
  • Tool Agent Layer: Ein Agenten-Layer befähigt die Modelle, eigenständig "Tools" (spezifische Programmierfunktionen der Module) aufzurufen und auszuführen.

Obwohl mein Fokus ursprünglich auf dem Finanzwesen lag, sind die Einsatzmöglichkeiten schlicht unbegrenzt. Die Workflows lassen sich tiefgreifend individualisieren. Module können nicht nur Daten beschaffen, sondern auch Workflows / KI's triggern. Dadurch agiert die KI proaktiv statt nur reaktiv.

In der ersten Version von ProjectAI nutzte ich transformers und llama.cpp, um die lokalen Modelle nativ anzusprechen. Die Sessions und die Memory-Funktion stellten sicher, dass wesentliche Informationen nicht verloren gingen. Um die Hardwarebeschränkungen zu Hause zu lösen, wurden die lokalen Modelle per Clustering im LAN auf meine PCs verteilt. Aufgaben wurden so vollautomatisch an freie Ressourcen und nach Eignung der Modelle vergeben. ProjectAI läuft in dieser Konfiguration seit einiger Zeit erfolgreich auf meinem Home-Server als Master-Instanz.

Zusätzlich wäre auch eine aktuelle Grafikkarte zur KI Beschleunigung ideal, zu dem Zeitpunkt schoßen die Preise jedoch in die Höhe, weswegen ich lange zögerte. Inzwischen habe ich aber für einen guten Kurs eine Sapphire Radeon 9600XT ergattern können, der Geschwindigkeitssprung im Vergleich zur reinen CPU Berechnung, ist milde ausgedrückt, enorm.

Rückblick: ProjectAI 2.0

ProjectAI 2.0 ist ein reiner lokaler MCP Tool Server der Workflows abarbeitet, im Grunde ein extrem abgespecktes ProjectAI 1.0, dass nur Tools bzw. Workflows zur Verfügung stellt. Die Datenstruktur ist identisch zur Vorversion, jedoch nur für den reinen lokalen Einsatz mit KoboldCpp, Gemini-CLI, Codex etc., geeignet.

Aktueller Stand: ProjectAI 3.0

ProjectAI 3.0 ist ein wieder etwas anderer Ansatz und wird aktuell intensiv von mir weiterentwickelt: Ein standalone Framework, service-orientierter Gateway, der mittels MCP Schnittstelle (fastmcp) lokal oder entfernt an Clients angebunden werden kann. Es kombiniert quasi die Features von V1 und V2 und macht den Einsatz universell, beherbergt zusätzlich ein Dashboard sowie Skills und einen Watchdog (Daemon) der zeitliche Aktionen triggert.

Kernfunktionen im Überblick

  • Framework: Ausgelegt für Workflow processing, Content preparing mittels JINJA2 Templates, Scheduling von Aktionen oder Workflow Ausführungen.
    • MCP Schnittstelle: Stellt eine MCP Schnittstelle (wahlweise stdin oder http) für KI Tool Calling bereit.
      • Tools: Workflows werden über YAML Dateien definiert, jeder Workflow entspricht einem Tool für die KI.
    • Datenbank: Derzeitig über primitive JSON Daten für:
      • Assets
      • Events
      • Schedulings
      • Watchlists, Depots
    • Workflow: Workflows sind Abfolge von Aktionen, die ausgeführt werden, wenn die KI ein "Tool" aufruft oder der Watchdog einen Task triggert.
    • Dataflow: Zentrale Engine zur Transformation und Standardisierung von Daten
      • Daten von verschiedenen Modulen (z.B. APIs) werden in ein einheitliches, kanonisches Format überführt, bevor sie im Workflow weiterverarbeitet werden.
    • Skills: Programmlogiken zur Datenauswertung
    • Gemeinsame Queue: Stapelverarbeitung nach FiFo und Routing:
      • Tool Callings (Workflows)
      • Dashboard Requests
      • Watchdog Scheduler Tasks
      • Signal Module
    • Watchdog: Läuft permanent und besitzt einen eigenen Scheduler
      • Überwacht Assets
      • Führt zeitlich gesteuerte Aktionen aus
  • Module: Datenabrufe über Module die in Workflows definiert werden.
    • Provider Module zur Datenbeschaffung (OnDemand Pull: APIs etc.)
    • Message Module zur Kommunikation (OnDemand Push: Telegram)
    • Signal Module zur Überwachung (Trigger: DBus Schnittstelle, RSS Feeder, TradingView Screener)
  • Dashboard: Visuelle Datenverwaltung:
    • Watchlists: Assets, Sektor, Datum hinzugefügt, Notizen
    • Depots: Positionen, Währung, Stückzahl, Notizen sowie einem Positionsrechner (FiFo und Nachkauf)
    • Assets
    • Events: Makroökonomische sowie Unternehmens Events / Termine
    • Watchdog Schedule Workflows erstellen / verändern / löschen
    • Workflows erstellen / verändern / löschen sowie debuggen
    • Dataflows erstellen / verändern / löschen
    • Integrierter KI Chat mit Dokumentenanhang für Rückfragen

Wie sieht ein Workflow aus?

Aktuell nutze ich eine Mischung aus Gemini-CLI (Gemini Flash 3) und KoboldCpp (Gemma 4) in Verbindung mit dem Framework. Insgesamt werden hier 7 Sub-Agenten von Gemma oder Gemini orchestriert, wovon jeder dieser Agenten einen speziell abgestimmten Prompt besitzt, der die Persona und die jeweiligen Aufgaben festlegt.

Die Agenten und Ihre Kernaufgaben:

  • SEC Finanzen: Business, Finanzielle Gesundheit, Bewertungen, Risiken und Management
  • SEC Biotech Finanzen: Kapitalverbrauch (Cash Burn), Liquiditätsreichweite (Cash Runway), Toxische Darlehen, Optionsscheinüberhänge, Fortführung der Unternehmenstätigkeit
  • SEC Biotech Pipelines: Alle Produkte / Studien, Meilensteine, Patente, PR vs. Realität, Wettbewerb
  • SEC Biotech Unternehmensführung: Verwässerungen, Bonuszahlungen, Restrukturierungen, Vergangene Fehlverhalten, Bekanntheitsgrad
  • SEC Q&A: Rückfragen / Unklarheiten, Nachrecherchen bei Auffälligkeiten
  • Technical: Insider, Trend, Momentum, Volumen, Zonen Gaps, Warrants. Erstellt einen Tradingplan.
  • Market: Analyse von Markt, Sentiment, Sektoren, Makrodaten zum aktuellen Tag oder Woche mit Prognose

Wenn ich nun eine Analyse anstoße, liest die betreffende KI (Orchestrator / Dirigent) ihren Skill, also eine Reihe von Anweisungen wie vorzugehen ist und wie der Bericht am Ende aussehen soll. Die Orchestrator KI verteilt also nacheinander Anweisungen an die Agenten, die Agenten durchlaufen ihren Prompt, tragen die Daten zusammen und geben sie dem Orchestrator zurück. Anschließend wird der Bericht erstellt und als Markdown in meinem Framework bzw. Datenbank gespeichert, so dass ich diesen im Dashboard mir auch ansehen kann. Eventuell anstehende Events / Termine zur Analyse trägt die KI ebenfalls ein.

Jede dieser KIs nutzt mein Framework bzw. die Workflows (Arbeitsabläufe im YAML Dateiformat) als Tools. Ein Workflow wiederum beinhaltet einen Ablauf von Aktionen, darüber werden dann beispielsweise Daten von der SEC oder APIs abgerufen. Die abgerufenen Daten werden vereinheitlicht und landen in einem großen Datenpool. Wenn alle Daten gesammelt wurden, werden Statistiken und Vorberechnungen durchgeführt, dazu zählen technische Indikatoren zu Charts, aber auch fundamentale Berechnungen. Abschließend werden die berechneten Daten für die KI leserlich als Markdown formatiert aufbereitet und ihr übergeben.

Ein Workflow kann mit wenig Aufwand also nicht nur Daten abrufen, wie eben beschrieben, sondern auch beispielsweise:

  • Meldungen über Telegram absetzen
  • Datenbankeinträge speichern
  • Zeitgesteuerte Aktion setzen, beispielsweise: KI setzt für sich selbst eine Erinnerungszeit, um einen Aktienkurs zu kontrollieren

Grenzen gibt es hier keine, die Module sind da die eigentlichen Horizonte, durch die Module erweitert sich auch der Workflow maßgeblich.

Was sind Module?

Die Module sind Erweiterungen / Fähigkeiten, die von Workflows angesprochen werden können. Aktuell existiert eine Reihe von Modulen für:

  • Diverse API-Knoten (Datenabruf)
  • SEC Edgar
  • Tradingview
  • Yahoo Finance
  • FinViz
  • RSS Feeds
  • Makroökonomische Daten von diversen Quellen
  • Reddit (Sentiment Berechnungen in einschlägigen Subreddits)
  • Kalender
  • Telegram
  • DBus Schnittstelle (Abfangen von News und Nachrichten, aber auch Senden von Mitteilungen an meinen KDE Desktop)
  • AI Module, eine KI kann eine Aufgabe an eine andere KI, plattformübergreifend, delegieren. Beispielsweise von Gemini-CLI an Codex oder KoboldCpp

Was ist ein Watchdog?

Der Watchdog ist im groben Sinne wie ein zeitgesteuerter Workflow, nur nicht von einer KI nutzbar, wird somit nicht als Tool deklariert. Mit einem entsprechenden Workflow kann die KI aber den Watchdog nutzen, um ein zeitgesteuertes Event einzustellen.

Was ist Dataflow?

Der Dataflow ist für das Vereinheitlichen der Daten zuständig. Er wandelt eingehende Daten von Modulen bzw. deren Key-Value-Paare zu kanonischen Daten um.

Warum überwiegend nur Biotechnologische und Pharmazeutische Unternehmen?

Zu großen Technologiewerten findet man stets zuverlässige Daten auf einschlägigen Webseiten. Natürlich gibt es auch hier schwarze Schafe, aber die sind im Vergleich einfacher zu recherchieren. Ein Biotech / Pharma Konzern ist da wesentlich kniffliger. Abgesehen vom medizinischen Aspekt, der ohnehin schon kompliziert werden kann, wenn man keinen Doktortitel hat, sind granulierte Aussagen vom Management, das Verhalten des Managements sowie das finanzielle Wirtschaften äußerst bedeutend. Ein Bio / Pharma Unternehmen erwirtschaftet in klinischen Phasen kein Geld, die Unternehmen sind auf Geldgeber angewiesen, werden zumeist von Darlehensgebern und / oder Investoren getragen, die an das Produkt und seine Erfolge glauben. Toxische Kreditgeber, hoher Kapitalverbrauch und nicht zu vergessen, das Verwässern von Aktienwerten, was direkt den Investor betrifft – all dies muss berücksichtigt werden, um ein klares Bild zu erhalten.

Es fängt bei der Management-Vergütung an, siehe TRAX & ANAB Analyse beispielsweise: Ein CEO für zwei Unternehmen, wovon das Tochterunternehmen nur für klinische Studien genutzt wird und die möglichen (oder auch nicht) Erfolge dem Mutterkonzern zugesprochen werden, obendrein für ein derartiges Spin-off Unternehmen über alle Medien die Werbetrommel gerührt wird. Dazu auch noch eine Doppelvergütung (jeweils von beiden Unternehmen) für den CEO, das sind schon Punkte, von denen ich mich distanziere. Der Grundgedanke, eine Krankheit zu bekämpfen, geht hier aus meiner Sicht völlig unter.