Christian's Blog

Projekt JARVIS, Tag 1: Einfach mal selbst ausprobieren

Chris //

In den letzten Wochen bin ich in den sozialen Medien immer wieder über Videos gestolpert, in denen sich Leute mit Claude Code ihren eigenen persönlichen JARVIS gebaut haben.

Natürlich angelehnt an Iron Man.

Die Videos waren teilweise erstaunlich gut gemacht. Termine verwalten, Informationen abrufen, sich Dinge merken, verschiedene Systeme steuern und das Ganze möglichst über natürliche Sprache.

Bei solchen Videos stellt sich allerdings immer die gleiche Frage:

Wie viel davon funktioniert wirklich und wie viel davon funktioniert nur im Video?

Also wollte ich es wissen.

Anstatt noch weitere JARVIS Videos anzuschauen, habe ich angefangen, meinen eigenen zu bauen.

Was soll JARVIS eigentlich werden?

Ich möchte nicht einfach einen weiteren Chatbot bauen.

Davon gibt es inzwischen wirklich genug.

Mein Ziel ist ein persönlicher Assistent, der auf meiner eigenen Infrastruktur läuft und nach und nach tatsächlich nützliche Aufgaben übernehmen kann.

Dazu gehören beispielsweise:

  • Wetterinformationen abrufen
  • Termine lesen und später auch verwalten
  • Informationen dauerhaft speichern
  • auf meine eigene Infrastruktur zugreifen
  • verschiedene Dienste miteinander verbinden
  • natürliche Sprache verstehen
  • später möglicherweise auch Smart Home Funktionen übernehmen
  • langfristig eine eigene Weboberfläche bekommen

Wichtig ist mir dabei vor allem, dass das System möglichst unabhängig von einzelnen Cloudanbietern funktioniert.

Die KI soll deshalb zunächst lokal laufen.

Erst einmal klein anfangen

Bei solchen Projekten passiert es schnell, dass man direkt eine riesige Architektur plant.

Frontend, Backend, Datenbank, APIs, Benutzerverwaltung, Docker Container und natürlich noch eine schicke Oberfläche.

Und am Ende funktioniert gar nichts richtig.

Deshalb habe ich mich bewusst für einen anderen Weg entschieden.

JARVIS startet im Terminal.

Keine Weboberfläche.

Keine App.

Keine Spracherkennung.

Erst einmal Python, Konfigurationsdateien und eine lokale KI.

Wenn die grundlegenden Funktionen zuverlässig funktionieren, kann darauf später alles Weitere aufgebaut werden.

Die aktuelle Architektur

JARVIS läuft aktuell auf einem eigenen Linux System.

Als Grundlage verwende ich Python.

Für die KI kommt Ollama zum Einsatz. Dadurch kann das Sprachmodell vollständig lokal betrieben werden.

Aktuell verwendet JARVIS:

LLM Provider: ollama
LLM Model: llama3.2:3b
Timezone: Europe/Berlin
Memory Workspace: /data/workspaces/default

Beim Start beziehungsweise über die Diagnosefunktion werden die wichtigsten Komponenten überprüft.

Der aktuelle Stand sieht so aus:

Validation        OK
Timezone          OK
LLM provider      OK
LLM model         OK
Memory workspace  OK

Damit steht zumindest das Grundgerüst.

Der erste echte Test: Wetter

Als erste Funktion habe ich bewusst etwas Einfaches gewählt.

JARVIS soll das aktuelle Wetter abrufen können.

Der Aufruf erfolgt momentan noch direkt über das Terminal:

jarvis weather now

Und tatsächlich bekomme ich inzwischen eine strukturierte Ausgabe zurück:

Wetter für Geisenheim

Wetter            Überwiegend klar
Temperatur        23.0 °C
Gefühlt           24.5 °C
Luftfeuchtigkeit  64 %
Bewölkung         48 %
Niederschlag      0.0 mm
Wind              3.7 km/h aus N
Böen              6.5 km/h

Das klingt zunächst nicht besonders spektakulär.

Man könnte schließlich auch einfach eine Wetter App öffnen.

Für das Projekt ist dieser Schritt aber ziemlich wichtig.

Denn damit funktioniert zum ersten Mal die komplette Kette:

Befehl → JARVIS → externe Daten → Verarbeitung → strukturierte Ausgabe

Genau auf diesem Prinzip können später deutlich komplexere Funktionen aufgebaut werden.

Warum überhaupt eine lokale KI?

Aktuell läuft llama3.2:3b über Ollama.

Das Modell ist vergleichsweise klein, benötigt nicht Unmengen an Ressourcen und eignet sich deshalb gut für die ersten Tests.

Für mich hat die lokale Verarbeitung mehrere Vorteile.

Die grundlegenden Funktionen funktionieren unabhängig von einem kommerziellen KI Anbieter und persönliche Informationen müssen nicht zwangsläufig an externe Dienste geschickt werden.

Gerade wenn JARVIS später Zugriff auf Termine, Notizen oder Teile meiner Infrastruktur bekommt, ist das durchaus interessant.

Natürlich wird sich noch zeigen müssen, ob ein kleines lokales Modell für alle Aufgaben ausreicht.

Es spricht aber nichts dagegen, später unterschiedliche Modelle für unterschiedliche Aufgaben einzusetzen.

Speicher soll von Anfang an dazugehören

Ein persönlicher Assistent wird erst dann wirklich interessant, wenn er sich Dinge merken kann.

Deshalb besitzt JARVIS bereits jetzt einen eigenen Workspace:

/data/workspaces/default

Dort sollen später Informationen abgelegt werden, die JARVIS dauerhaft verwenden kann.

Dabei möchte ich allerdings nicht einfach sämtliche Gespräche irgendwo in eine Datenbank werfen.

Das Ziel ist ein kontrollierter Speicher.

JARVIS soll unterscheiden können, welche Informationen nur für die aktuelle Anfrage benötigt werden und welche tatsächlich langfristig relevant sind.

Das dürfte wahrscheinlich einer der interessanteren Teile des Projektes werden.

Warum noch keine Weboberfläche?

Eine Oberfläche wäre natürlich schöner.

Und vermutlich würde JARVIS auf Screenshots damit auch deutlich beeindruckender aussehen.

Aber momentan bringt sie mir keinen echten Vorteil.

Wenn

jarvis weather now

nicht zuverlässig funktioniert, wird es durch einen hübschen Button auch nicht besser.

Deshalb möchte ich erst die Funktionen entwickeln und testen.

Wenn die Basis stabil ist, kann später eine Weboberfläche daraufgesetzt werden.

Damit bleibt außerdem offen, ob JARVIS langfristig überhaupt hauptsächlich über eine klassische Oberfläche bedient wird.

Vielleicht wird Sprache irgendwann wichtiger.

Vielleicht reicht für viele Dinge eine API.

Vielleicht landet ein Teil davon im Smart Home.

Das muss jetzt noch nicht entschieden werden.

Und Claude Code?

Claude Code ist tatsächlich ein Teil der Geschichte.

Schließlich waren genau diese JARVIS Projekte der Auslöser dafür, dass ich überhaupt angefangen habe.

Ich möchte das Projekt aber nicht einfach aus einem Video nachbauen.

Viel interessanter finde ich die Frage, wie weit man mit einem solchen Projekt kommt, wenn man es Stück für Stück an die eigene Infrastruktur und die eigenen Anforderungen anpasst.

Und genau das möchte ich hier dokumentieren.

Nicht nur die Dinge, die funktionieren.

Auch die Dinge, die nicht funktionieren.

Gerade die dürften am Ende vermutlich die interessanteren sein.

Stand nach Tag 1

Nach dem ersten Tag kann JARVIS noch nicht besonders viel.

Aber die Grundlage steht.

Aktuell funktioniert:

  • Python Anwendung läuft
  • Konfiguration wird geladen
  • Zeitzone wird korrekt erkannt
  • Ollama ist angebunden
  • llama3.2:3b wird als lokales Sprachmodell verwendet
  • ein persistenter Workspace ist vorhanden
  • eine Diagnosefunktion überprüft die wichtigsten Komponenten
  • Wetterdaten können abgerufen und im Terminal dargestellt werden

Und damit ist der wichtigste Punkt erreicht:

JARVIS existiert nicht mehr nur als Idee.

Er läuft.

Noch sehr rudimentär, noch ausschließlich im Terminal und noch weit entfernt von Tony Starks Assistenten.

Aber irgendwo muss man schließlich anfangen.

Wie geht es weiter?

Als Nächstes soll JARVIS lernen, mit Kalenderdaten umzugehen.

Zunächst möchte ich Termine lediglich auslesen und strukturiert anzeigen.

Danach kann man sich langsam an natürlichere Abfragen herantasten.

Zum Beispiel:

Was steht morgen in meinem Kalender?

Oder irgendwann:

Wie wird morgen das Wetter und wann muss ich losfahren, damit ich rechtzeitig bei meinem ersten Termin bin?

Spätestens an diesem Punkt würde aus mehreren einzelnen Funktionen langsam ein echter persönlicher Assistent werden.

Mal schauen, wie weit ich komme.

Fortsetzung folgt mit Tag 2.