brennendes Benzin

Bei Fiatbitcoin laufen mittlerweile rund ein Dutzend Jido-Agenten parallel: Portfolio-Auswertung, Steuer, On-Chain-Beobachtung, Anomalie-Erkennung, Tages-Briefing. Irgendwann fällt einem dieses Muster auf: Agent A weiß etwas. Agent B könnte es gebrauchen. Aber B fragt nie nach, weil A das Wissen nur in seinem eigenen kleinen State hält. Kein Edge-Case, sondern der Default-Zustand jedes Multi-Agent-Systems, solange man nicht aktiv dagegen baut. Deshalb haben wir das Brain gebaut: einen zentralen Wissensspeicher, in den alle Agenten schreiben und aus dem alle lesen. Seit kurzem auch Claude Code, über einen MCP-Server. Ein paar Architekturentscheidungen haben sich in der Umsetzung bewährt. Und eine, die ich heute anders treffen würde. Das Problem: Agent-Silos Bis vor kurzem hatte jeder Agent sein eigenes kleines Gedächtnis. Oder gar keins, je nach Implementierung. In der Praxis hieß das: Der PerformanceTaxAgent berechnete jede Nacht eine Portfolio-Summary, hatte aber kein...

Mein Webserver läuft auf einer günstigen Linux-Box ohne GPU, das Embedding-Modell aber will Rechenpower. Die Lösung: Das Modell läuft auf meinem MacBook, die App auf dem Server. Und der Code, der die Inferenz aufruft, sieht exakt gleich aus, als liefe alles auf einer Maschine. Das ist der Teil des Projekts, bei dem die meisten Leute, denen ich es zeige, kurz innehalten. Nicht weil es kompliziert wäre, sondern weil es so wenig Code ist für etwas, das in anderen Stacks ein eigenes Infrastruktur-Projekt wäre. Das Problem: Die App läuft produktiv auf einer kleinen Linux-Maschine, die für Phoenix und Postgres reicht. Ein 278-MB-Transformer-Modell mit EXLA-Inferenz wird darauf aber zäh. Die nötige Rechenleistung sitzt woanders, nämlich in meinem MacBook Pro mit ordentlich CPU und GPU. In der typischen Microservice-Welt heißt das jetzt: das Modell in einen eigenen Service packen, eine API drumherum bauen (gRPC oder REST), Serialisierung definieren, dazu Service-Discovery, Timeouts, Retries, e...

Wenn ich in meiner App eine Kategorie von Hand korrigiere, klassifiziert sie ähnliche Transaktionen ab sofort richtig, ganz ohne Retraining-Lauf, neues Deployment oder MLOps-Pipeline. Hier ist der Trick, und nebenbei, warum „Lernen" nicht immer „Trainieren" heißt. Im letzten Artikel habe ich gezeigt, wie ich Transaktionen klassifiziere, indem ich ihren Text-Vektor mit Vektoren von Kategorie- Beschreibungen vergleiche. Das wirft eine Frage auf: Was, wenn das Modell danebenliegt? In den meisten ML-Systemen ist die Antwort aufwändig: Eine falsche Vorhersage wandert als Beispiel ins Trainingsset, irgendwann wird neu trainiert, evaluiert und neu deployt. Ein Zyklus, der Tage bis Wochen dauert. Genau den wollte ich vermeiden. Die Einsicht dahinter: Wenn eine Kategorie durch Text definiert ist, dann ist „dem Modell etwas beibringen" nichts anderes als „den Text erweitern". Ordnet der Nutzer eine Transaktion manuell der richtigen Kategorie zu, hänge ich genau diesen Trans...

Die klassische ML-Antwort auf „kategorisiere diese Texte" lautet: sammle tausende gelabelte Beispiele, trainiere ein Modell, wiederhole. Ich habe nichts davon gemacht. Ich habe meine Kategorien in je einem Satz beschrieben und ein vortrainiertes Modell die Ähnlichkeit ausrechnen lassen. Im ersten Artikel ging es darum, dass mein Transaktions-Classifier komplett in Elixir lebt. Jetzt zum Wie . Das ist die Entscheidung, auf die ich am stolzesten bin, weil sie so viel Komplexität spart. Der teure Weg, den ich nicht gegangen bin: Ein klassischer Klassifikator will einen Trainingsdatensatz, also tausende Banktexte, jeder von Hand mit der richtigen Kategorie versehen. Dann trainiert man ein Modell, evaluiert, justiert und trainiert neu. Für ein Privatprojekt ist das utopisch, und selbst im Unternehmen vergehen Wochen, bevor das erste Feature läuft. Der Weg, den ich gegangen bin, heißt Embeddings. Ein Embedding-Modell verwandelt einen Text in einen Vektor aus Zahlen, und zwar so, dass ...

Ich wollte meine Banktransaktionen automatisch kategorisieren. Jeder Reflex sagte: Python, ein separater ML-Service, eine MLOps-Pipeline. Am Ende waren es rund 200 Zeilen Elixir, und das Ganze ist heute das wartungsärmste Feature der ganzen App. Ich baue privat eine kleine Finanz-App. Sie zieht Kontoumsätze von der Bank und soll sie in Kategorien einsortieren: Lebensmittel, Miete, Versicherung, Einkommen und so weiter. Klingt trivial, ist es aber nicht. Denn Banktexte sehen so aus: DE12 3456 / EDEKA SAGT DANKE//KOELN/DE 2024-11-03T08:14 LASTSCHRIFT 1U1 TELECOM GMBH KD-NR 4711 Kryptisch, abgekürzt, oft deutsch und voller Boilerplate. Eine Liste aus if String.contains? -Abfragen würde immer weiter wachsen und trotzdem ständig danebenliegen. Es ist ein Klassifikationsproblem, also ein Fall für Machine Learning. Spannend finde ich den Reflex, der dann einsetzt. Für die meisten Teams heißt „ML" automatisch „zweite Welt": ein eigener Python-Service, ein separates Repo, irgendwo e...