Project AI - das Kind ohne Namen

ProjectAI ist ein in Python geschriebenes Workflow-Framework, dass 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 Analysen Resultate 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.

Aktuelle 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