Mein Weg ins AI/ML Engineering: Lernpfad zum MAKEathon 2026

01 · Warum ich mich damit beschäftige

Aus der Softwareentwicklung bringe ich Erfahrung darin mit, Anforderungen in funktionierende Anwendungen zu übersetzen. Bei AI Agents interessieren mich inzwischen vor allem die Fragen hinter einer überzeugenden Demo: Wann hilft ein Agent tatsächlich? Wie zuverlässig nutzt er Tools? Und wie erkenne ich, ob eine Änderung das System verbessert?

Ich möchte mein Wissen in Richtung AI/ML Engineering vertiefen: Modelle sinnvoll in Software einbinden, Daten und Schnittstellen verstehen, Fehler analysieren und Ergebnisse systematisch bewerten. Ein funktionierender Prototyp ist dabei ein Anfang. Mein Lernziel ist, seine Entscheidungen und Grenzen erklären zu können.

02 · Der Ausgangspunkt: MAKEathon und Apertus

MAKE steht für Machine leArning and Knowledge Engineering. Der MAKEathon verbindet maschinelles Lernen mit explizitem Fachwissen. Die Veranstaltung findet am 24.–25. Oktober 2026 am FHNW Campus Olten statt. Informationen zum MAKEathon

Mein persönlicher Lernplan zur Challenge 4 setzt den Schwerpunkt auf einen kleinen Agenten mit strukturierten Entscheidungen und einer nachvollziehbaren Evaluation. Als Modell möchte ich Apertus, ein offenes Schweizer Sprachmodell, kennenlernen. Apertus: Übersicht und Dokumentation

Mich interessiert, was das Modell in einem konkreten Ablauf leisten kann und welche Aufgaben besser in gewöhnlicher Software aufgehoben sind. Modellversion, Ausführungsumgebung und Konfiguration dokumentiere ich beim ersten Versuch.

03 · Mein Lernpfad: In kleinen Schritten zum Experiment

Ich orientiere mich an der Reihenfolge LLM-Grundlagen → strukturierte Ausgaben → Tool Calling → Agent → Evaluation → Apertus. Pro Lerneinheit plane ich ungefähr 60–90 Minuten. Die Termine sind eine Planung; einen Abschluss halte ich erst im Lernlog fest.

Geplant	Schwerpunkt	Greifbares Ergebnis
4.–6. Oktober	Tokens, Kontext, Inferenz und Prompting	Ein einzelner Modellaufruf und beobachtete Unterschiede zwischen Prompts
7.–9. Oktober	JSON Schema und Validierung	Eine strukturierte Ausgabe mit erlaubten Werten und Fehlerprüfung
10.–12. Oktober	Tool Calling und Schnittstellen	Zwei kleine Tools mit definierten Parametern
13.–15. Oktober	Ablauf, Zustand und Abbruchbedingungen	Ein kleiner Agent mit begrenzten Schritten und Fehlerbehandlung
16.–18. Oktober	Baseline und Evaluation	20–30 synthetische Testfälle mit erwarteten Ergebnissen
19.–21. Oktober	Apertus integrieren	Derselbe Testlauf mit dokumentierter Modellkonfiguration
22.–23. Oktober	Experiment und Demo vorbereiten	Repository, Hypothese, Messplan und kurze Demonstration

Aktueller Fortschritt: noch im Lernlog zu dokumentieren. Falls eine Etappe mehr Zeit benötigt, passe ich den Umfang des Experiments an.

04 · Ein kleiner Use Case statt einer riesigen Plattform

Als Arbeitsidee für die Vorbereitung wähle ich einen synthetischen Entscheidungsprozess: Eine fiktive Spesenanfrage wird anhand vorgegebener Regeln als approve, reject oder manual_review eingeordnet. Das ist ein überschaubares Lernbeispiel mit künstlichen Daten. Der endgültige Use Case für den MAKEathon bleibt eine Entscheidung im Team.

Der Agent könnte zwei Tools nutzen: eines für die Angaben zur Anfrage und eines für die dazugehörigen Regeln. Die Anwendung führt die Tools aus, validiert ihre Parameter und prüft die abschliessende Ausgabe. Fehlende oder widersprüchliche Angaben gehören bewusst in die Testfälle.

Die erste Version soll genau einen Ablauf verständlich machen. Eine regelbasierte Umsetzung dient, soweit passend, als zusätzlicher Vergleich: Wenn einfache Regeln die Aufgabe bereits lösen, muss der Einsatz eines Agenten einen nachvollziehbaren Mehrwert zeigen.

05 · Meine technische Hypothese

Offene Hypothese: Ein begrenzter Agent mit klaren Tool-Schemas und validierter Ausgabe kann die Regeln im gewählten Use Case zuverlässiger anwenden als ein einzelner Modellaufruf. Ob dieser Vorteil den zusätzlichen Aufwand und die längere Laufzeit rechtfertigt, muss der Vergleich zeigen.

Ich trenne dabei drei Verantwortlichkeiten: Das Modell schlägt Tool-Aufrufe und eine Entscheidung vor. Die Anwendung kontrolliert Parameter, Ausführung und Abbruchbedingungen. Das Ausgabeschema definiert, welche Daten die nachfolgende Software akzeptiert. Eine gültige JSON-Ausgabe allein belegt noch keine richtige Entscheidung.

Das vorläufige Schema enthält decision, reason und optional eine vom Modell angegebene confidence. Eine solche Selbsteinschätzung behandle ich ohne Kalibrierung nicht als verlässliche Wahrscheinlichkeit. Tool-Ergebnisse sollen als Daten verarbeitet werden und keine Anweisungen des Ablaufs überschreiben.

Vor dem Test festzuhalten: Schema-Version, erlaubte Tools, maximale Schritte, Fehlerbehandlung und Kriterien für manual_review.

06 · Evaluation: Was ich tatsächlich messen will

Ich bereite 20–30 synthetische Fälle mit vorab definierten erwarteten Entscheidungen vor. Dazu gehören klare Fälle, fehlende Angaben, Widersprüche und Tool-Fehler. Fälle, die ich zur Anpassung des Prompts nutze, trenne ich von den Fällen für die abschliessende Bewertung.

Für einen fairen Vergleich erhalten Baseline und Agent dieselben verfügbaren Fakten und dieselben fachlichen Regeln. Die Baseline bekommt die Daten direkt im Prompt; der Agent kann sie über Tools abrufen. Für diesen Vergleich bleiben Modell, Konfiguration und abschliessendes Schema möglichst gleich. Einen Modellwechsel zu Apertus werte ich separat aus.

Messgrösse	Was sie beantworten soll
Richtige Entscheidungen / bewertbare Fälle	Trifft die Ausgabe die vorab definierte Erwartung?
Gültige Ausgaben / alle Fälle	Werden Schema und erlaubte Werte eingehalten?
Korrekte Tool-Aufrufe / bewertete Aufrufe	Passen Tool-Auswahl und Parameter zum Fall?
Laufzeit p50 und p95	Wie schnell ist ein typischer Lauf, und wie langsam sind die längeren Läufe?
Fehler und Abbrüche	Wo scheitert der Ablauf, und erholt er sich kontrolliert?

Ich protokolliere Modellversion, Prompt, Datensatz, Hardware bzw. Dienst, Wiederholungen und Messmethode. Ein kleiner Test ist ein erster Hinweis; er reicht nicht aus, um allgemeine Zuverlässigkeit zu behaupten.

07 · Lernlog: Was ich ausprobiert habe

Status: laufend ergänzen · Noch keine Versuchsergebnisse eingetragen.

Für jede Lerneinheit halte ich einen kurzen Eintrag fest. Interessant sind auch Versuche, die nicht funktioniert haben.

Eintrag · [Datum und Thema ergänzen]

• Ziel: Welche Frage wollte ich beantworten?
• Versuchsaufbau: Modell und Version, Prompt, Schema, Tools und Testfall.
• Beobachtung: Was ist tatsächlich passiert? Screenshot, Ausgabe oder Log ergänzen.
• Fehler oder Überraschung: Was wich von meiner Erwartung ab?
• Erkenntnis: Was kann ich daraus begründet ableiten?
• Nächster Schritt: Welche einzelne Änderung teste ich als Nächstes?

Platz für Bilder: Hier passen später Screenshots eines Tool-Aufrufs, ein kleines Ablaufdiagramm oder ein Vergleich von zwei Ausgaben. Mehrere zusammengehörige Bilder können in diesem Article Block als Slider ergänzt werden.

08 · 24.–25. Oktober: Das Experiment im Team

Status: nach dem MAKEathon ergänzen. Die Veranstaltung ist für den 24.–25. Oktober 2026 in Olten angekündigt. Meine Vorbereitung soll mir helfen, im Team gezielte Fragen zu stellen und einen kleinen, prüfbaren Beitrag zu leisten.

Nach dem Wochenende dokumentiere ich:

• Unsere Aufgabe: Welchen Use Case haben wir gewählt und warum?
• Meine Rolle: Welche Teile habe ich umgesetzt oder untersucht?
• Unser Ansatz: Was haben wir aus der Vorbereitung übernommen, was geändert?
• Zusammenarbeit: Welche fachlichen Rückmeldungen haben das Experiment verbessert?
• Demo und Artefakte: Repository, Ablaufdiagramm und tatsächlicher Stand des Prototypen.

Platz für Bilder: Ein Foto des Arbeitsprozesses oder ein Screenshot der Demo ergänzt später den Bericht. Ergebnisse und Teambeiträge beschreibe ich erst nach der Durchführung.

09 · Resultate: Baseline gegen unseren Ansatz

Status: noch nicht gemessen. Die Tabelle wird erst nach reproduzierbaren Testläufen ausgefüllt. Für jede Variante dokumentiere ich die Anzahl Fälle und Wiederholungen; Prozentwerte ohne diese Bezugsgrössen wären wenig aussagekräftig.

Variante	Modell / Version	Fälle	Richtige Entscheidungen	Gültige Ausgaben	Tool-Aufrufe korrekt	Laufzeit p50 / p95
Einzelner Modellaufruf	Offen	Offen	Nicht gemessen	Nicht gemessen	Nicht anwendbar	Nicht gemessen
Agent mit Tools	Offen	Offen	Nicht gemessen	Nicht gemessen	Nicht gemessen	Nicht gemessen
Variante mit Apertus	Offen	Offen	Nicht gemessen	Nicht gemessen	Falls verwendet	Nicht gemessen

Falls sinnvoll, ergänze ich eine regelbasierte Baseline. Neben den Zahlen zeige ich mindestens einen gelungenen und einen gescheiterten Fall. Dabei halte ich fest, ob eine Verbesserung mit dem Tool-Zugriff, dem Prompt, dem Modell oder einer anderen Änderung zusammenhängt.

Offene Auswertung: Was wurde besser? Welche zusätzliche Laufzeit oder Komplexität entstand? Welche Aussage erlaubt der Test – und welche nicht?

10 · Grenzen, Irrtümer und nächste Iteration

Status: nach den ersten Versuchen ergänzen. Ich möchte nicht nur die überzeugenden Ausgaben sammeln, sondern die Ursachen der Fehler verstehen. Eine falsche Entscheidung kann zum Beispiel aus fehlenden Daten, unklaren Regeln, einem ungeeigneten Prompt oder einem fehlerhaften Tool-Aufruf entstehen.

Fehlerfall · [Beispiel ergänzen]

• Erwartung und tatsächliche Ausgabe: Was sollte passieren, was ist passiert?
• Vermutete Ursache: Welche Erklärung habe ich, und welche Belege fehlen noch?
• Änderung: Welche einzelne Komponente passe ich an?
• Erneuter Test: Hilft die Änderung auch auf bisher ungenutzten Fällen?

Ein kleines synthetisches Beispiel bildet reale Abläufe nur begrenzt ab. Der spätere Bericht soll diese Grenze sichtbar machen. Fine-Tuning ist für mich eine mögliche weitere Lernrichtung; zuerst möchte ich verstehen, welche Probleme sich mit besseren Daten, klareren Schnittstellen, Prompts oder gewöhnlicher Programmlogik lösen lassen.

11 · Was am Ende zählt

Für mich ist dieses Projekt ein Schritt auf dem Weg ins AI/ML Engineering. Entscheidend ist nicht, möglichst viele AI-Begriffe in einer Demo unterzubringen. Ich möchte am Ende einen kleinen Ablauf selbst bauen, seine Ergebnisse messen und begründet erklären können, wann ein Agent sinnvoll ist.

Nach dem Experiment beantworte ich hier drei Fragen: Was verstehe ich jetzt besser? Was kann ich anhand von Ergebnissen belegen? Was möchte ich als Nächstes lernen? Daraus entsteht mein nächster Lernschritt – etwa eine vertiefte Evaluation, ein besserer Datensatz oder ein gezieltes Experiment zur Modellanpassung.

Grundlage und Einordnung

Die Kapitel orientieren sich an meinem Lernplan «MAKEathon 2026 – Challenge 4» für die Vorbereitung vom 4.–23. Oktober. Geplante Schritte, Beobachtungen und gemessene Resultate halte ich getrennt fest. Das Cover ist eine mit AI gestaltete Illustration des Lernpfads. Fotos, Screenshots und Diagramme aus dem tatsächlichen Experiment ergänze ich später.