feat: expanded and added more tasks
This commit is contained in:
@@ -0,0 +1,39 @@
|
||||
# Aufgabe 01: LLM API per CLI ansprechen
|
||||
|
||||
## Ziel
|
||||
|
||||
Du baust eine CLI, die eine Chat-Anfrage an ein LLM sendet und die Antwort ausgibt.
|
||||
|
||||
## Warum ist das wichtig?
|
||||
|
||||
Der spätere Roboter braucht ein kontrolliertes Sprachmodell als Denk- und Dialogkomponente.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
- Rust oder Python
|
||||
- API-Key oder Ollama
|
||||
- HTTP-Grundlagen
|
||||
|
||||
## Theorie
|
||||
|
||||
LLM APIs arbeiten meist mit Nachrichten statt mit einem einzelnen Prompt. Rollen wie system, user und assistant geben dem Modell Kontext und begrenzen Verhalten.
|
||||
|
||||
## Aufgabe
|
||||
|
||||
Implementiere `ask "Frage"` mit konfigurierbarer Provider-URL, Timeout und verständlicher Fehlerausgabe.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
- Eine Frage kann per Terminal gestellt werden.
|
||||
- Antwort und Fehler werden sauber ausgegeben.
|
||||
- Provider-Konfiguration liegt nicht hart im Code.
|
||||
|
||||
## Erweiterungen
|
||||
|
||||
- Speichere Request und Response als JSON-Log.
|
||||
|
||||
## Reflexionsfragen
|
||||
|
||||
- Welche Daten sendest du an den Provider?
|
||||
- Was gehört in Konfiguration statt Code?
|
||||
- Wie erkennst du API-Timeouts?
|
||||
@@ -1,43 +0,0 @@
|
||||
# Aufgabe 01: LLM per Code ansprechen
|
||||
|
||||
## Ziel
|
||||
|
||||
Du baust ein minimales Programm, das eine Chat-Anfrage an ein LLM sendet und die Antwort ausgibt.
|
||||
|
||||
## Aufgabe
|
||||
|
||||
Baue eine kleine CLI-Anwendung:
|
||||
|
||||
```text
|
||||
$ ask "Erkläre mir Servos in 3 Sätzen"
|
||||
```
|
||||
|
||||
Die Anwendung soll:
|
||||
|
||||
- eine User-Nachricht entgegennehmen
|
||||
- sie an ein LLM schicken
|
||||
- die Antwort auf stdout ausgeben
|
||||
|
||||
## Varianten
|
||||
|
||||
Starte mit einer Variante:
|
||||
|
||||
- OpenAI API
|
||||
- lokales Ollama per HTTP API
|
||||
|
||||
## Lernpunkte
|
||||
|
||||
- Wie sieht eine Chat-Message-Struktur aus?
|
||||
- Was ist System/User/Assistant?
|
||||
- Wie unterscheidet sich lokales LLM von API-LLM?
|
||||
- Wie gehst du mit Fehlern, Timeouts und Rate Limits um?
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
- Du kannst per Terminal eine Frage stellen.
|
||||
- Die Antwort kommt vom Modell.
|
||||
- Fehler werden sauber angezeigt, nicht per `unwrap()` beendet.
|
||||
|
||||
## Erweiterung
|
||||
|
||||
Speichere den kompletten Request und Response als JSON in einem `logs/`-Ordner.
|
||||
@@ -0,0 +1,39 @@
|
||||
# Aufgabe 02: Ollama und Cloud API vergleichen
|
||||
|
||||
## Ziel
|
||||
|
||||
Du vergleichst lokale und cloudbasierte LLMs mit denselben Prompts.
|
||||
|
||||
## Warum ist das wichtig?
|
||||
|
||||
Der Roboter muss je nach Datenschutz, Kosten und Latenz mit verschiedenen Modellquellen umgehen können.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
- Aufgabe 01
|
||||
- Ollama optional
|
||||
- Cloud API optional
|
||||
|
||||
## Theorie
|
||||
|
||||
Lokale Modelle geben mehr Kontrolle, brauchen aber Hardware und sind oft schwächer. Cloud APIs sind leistungsfähig, erzeugen aber Kosten und Datenschutzfragen.
|
||||
|
||||
## Aufgabe
|
||||
|
||||
Baue einen Provider-Schalter und teste mindestens fünf Prompts gegen beide Varianten oder dokumentiere eine simulierte zweite Variante.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
- Provider kann per Config gewechselt werden.
|
||||
- Latenz und Antwortqualität werden notiert.
|
||||
- Datenschutz- und Kostenunterschiede sind beschrieben.
|
||||
|
||||
## Erweiterungen
|
||||
|
||||
- Füge einen Fallback auf lokales Modell bei Cloud-Fehler ein.
|
||||
|
||||
## Reflexionsfragen
|
||||
|
||||
- Wann ist lokal besser?
|
||||
- Welche Prompts zeigen Qualitätsunterschiede?
|
||||
- Wie wirkt Modelllatenz auf Sprachdialog?
|
||||
@@ -1,55 +0,0 @@
|
||||
# Aufgabe 02: Tool Calling simulieren
|
||||
|
||||
## Ziel
|
||||
|
||||
Du lernst, wie ein LLM nicht nur Text erzeugt, sondern Aktionen auslösen kann.
|
||||
|
||||
## Szenario
|
||||
|
||||
Der User fragt:
|
||||
|
||||
```text
|
||||
Wie viele Personen sind im Raum?
|
||||
```
|
||||
|
||||
Das LLM soll nicht raten, sondern ein Tool anfordern:
|
||||
|
||||
```json
|
||||
{
|
||||
"tool": "count_people",
|
||||
"arguments": {}
|
||||
}
|
||||
```
|
||||
|
||||
## Aufgabe
|
||||
|
||||
Baue ein Programm mit mindestens 3 Tools:
|
||||
|
||||
- `get_time()`
|
||||
- `count_people()` - erstmal fake: gibt z. B. `2` zurück
|
||||
- `look(direction)` - erstmal fake: gibt `looked left` zurück
|
||||
|
||||
Das Programm soll:
|
||||
|
||||
1. User-Input entgegennehmen
|
||||
2. LLM entscheiden lassen, ob ein Tool nötig ist
|
||||
3. Tool ausführen
|
||||
4. Ergebnis zurück ans LLM geben
|
||||
5. finale Antwort ausgeben
|
||||
|
||||
## Lernpunkte
|
||||
|
||||
- Warum Tool Calling für Robotik zentral ist
|
||||
- Warum ein LLM nicht direkt Motoren steuern sollte
|
||||
- Wie man Tools typisiert und validiert
|
||||
- Wie man gefährliche Aktionen begrenzt
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
- Frage nach Uhrzeit ruft `get_time()` auf.
|
||||
- Frage nach Personen ruft `count_people()` auf.
|
||||
- Befehl "schau nach links" ruft `look("left")` auf.
|
||||
|
||||
## Erweiterung
|
||||
|
||||
Logge jeden Tool-Call mit Timestamp, Argumenten und Ergebnis.
|
||||
@@ -0,0 +1,38 @@
|
||||
# Aufgabe 03: Chat Messages modellieren
|
||||
|
||||
## Ziel
|
||||
|
||||
Du modellierst Chat Messages als strukturierte Daten statt als String-Konkatenation.
|
||||
|
||||
## Warum ist das wichtig?
|
||||
|
||||
Tool Calling und Conversation History funktionieren nur sauber mit expliziten Rollen und Feldern.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
- Aufgabe 01
|
||||
- JSON/Serde oder Pydantic
|
||||
|
||||
## Theorie
|
||||
|
||||
Strukturierte Nachrichten verhindern Prompt-Chaos. Der Code kann validieren, kürzen, speichern und gezielt System- oder Tool-Nachrichten einfügen.
|
||||
|
||||
## Aufgabe
|
||||
|
||||
Definiere Typen für system, user, assistant und tool messages und serialisiere sie in das API-Format deines Providers.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
- Rollen sind typisiert oder validiert.
|
||||
- JSON-Ausgabe entspricht dem Provider-Format.
|
||||
- Ungültige Rollen werden abgefangen.
|
||||
|
||||
## Erweiterungen
|
||||
|
||||
- Schreibe Unit Tests für Serialisierung.
|
||||
|
||||
## Reflexionsfragen
|
||||
|
||||
- Warum sind Rollen besser als ein langer Prompt?
|
||||
- Was muss eine Tool-Nachricht enthalten?
|
||||
- Wie würdest du binäre Daten vermeiden?
|
||||
@@ -0,0 +1,38 @@
|
||||
# Aufgabe 04: System Prompt entwerfen
|
||||
|
||||
## Ziel
|
||||
|
||||
Du schreibst einen System Prompt für den Roboterassistenten mit klaren Grenzen.
|
||||
|
||||
## Warum ist das wichtig?
|
||||
|
||||
Der Roboter darf nicht raten, wenn Sensor-Tools echte Daten liefern sollen.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
- Aufgabe 03
|
||||
- Texteditor
|
||||
|
||||
## Theorie
|
||||
|
||||
Ein guter System Prompt beschreibt Rolle, Grenzen und Entscheidungsregeln. Er ersetzt keine Programmlogik, aber er hilft dem Modell, Tools korrekt zu nutzen.
|
||||
|
||||
## Aufgabe
|
||||
|
||||
Erstelle einen System Prompt, der kurze deutsche Antworten, Tool-Nutzung bei Sensorfragen und sichere Hardwarebefehle vorgibt.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
- Prompt enthält Rolle, Sprache und Sicherheitsregeln.
|
||||
- Sensorfragen sollen Tools nutzen.
|
||||
- Gefährliche Aktionen werden abgelehnt oder bestätigt.
|
||||
|
||||
## Erweiterungen
|
||||
|
||||
- Teste den Prompt mit zehn absichtlich schwierigen User-Fragen.
|
||||
|
||||
## Reflexionsfragen
|
||||
|
||||
- Welche Regeln gehören in Code statt Prompt?
|
||||
- Wie erkennt der Agent eine Sensorfrage?
|
||||
- Welche Antwortlänge passt für Sprache?
|
||||
@@ -0,0 +1,38 @@
|
||||
# Aufgabe 05: Conversation History verwalten
|
||||
|
||||
## Ziel
|
||||
|
||||
Du speicherst und kürzt Dialogverlauf für mehrere Gesprächsrunden.
|
||||
|
||||
## Warum ist das wichtig?
|
||||
|
||||
Ein sprechender Roboter muss Kontext behalten, ohne das Modellfenster zu überladen.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
- Aufgaben 01-04
|
||||
- Grundverständnis Token/Kontext
|
||||
|
||||
## Theorie
|
||||
|
||||
History ist Arbeitsgedächtnis, kein Archiv. Alte Nachrichten müssen zusammengefasst oder entfernt werden, damit wichtige Fakten erhalten bleiben.
|
||||
|
||||
## Aufgabe
|
||||
|
||||
Implementiere eine History mit maximaler Nachrichtenanzahl und einfacher Zusammenfassung alter Runden.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
- Mehrere Gesprächsrunden nutzen Kontext.
|
||||
- Alte Nachrichten werden begrenzt.
|
||||
- Tool-Ergebnisse bleiben nachvollziehbar.
|
||||
|
||||
## Erweiterungen
|
||||
|
||||
- Speichere Sitzungen mit Session-ID.
|
||||
|
||||
## Reflexionsfragen
|
||||
|
||||
- Was darf aus der History gelöscht werden?
|
||||
- Welche Fakten sind langfristig wichtig?
|
||||
- Wie vermeidest du, dass Tool-Logs den Kontext füllen?
|
||||
@@ -0,0 +1,38 @@
|
||||
# Aufgabe 06: JSON Tool Schema definieren
|
||||
|
||||
## Ziel
|
||||
|
||||
Du beschreibst Robotik-Tools als JSON Schema mit Parametern und Grenzen.
|
||||
|
||||
## Warum ist das wichtig?
|
||||
|
||||
Das Modell braucht präzise Werkzeugbeschreibungen, damit Hardware- und Sensortools korrekt aufgerufen werden.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
- Aufgaben 03-04
|
||||
- JSON Schema Grundlagen
|
||||
|
||||
## Theorie
|
||||
|
||||
Ein Tool Schema ist ein Vertrag zwischen LLM und Programm. Es beschreibt Name, Zweck, Parameter, erlaubte Werte und Pflichtfelder.
|
||||
|
||||
## Aufgabe
|
||||
|
||||
Definiere Schemas für `get_time`, `count_people`, `identify_people` und `look`.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
- Alle Tools haben Name, Beschreibung und Parameter.
|
||||
- `look` begrenzt Richtungen oder Winkel.
|
||||
- Ungültige Argumente werden abweisbar.
|
||||
|
||||
## Erweiterungen
|
||||
|
||||
- Generiere aus dem Schema eine kurze Markdown-Doku.
|
||||
|
||||
## Reflexionsfragen
|
||||
|
||||
- Welche Parameter sind gefährlich?
|
||||
- Wie eng sollte ein Schema sein?
|
||||
- Was passiert bei fehlenden Pflichtfeldern?
|
||||
@@ -0,0 +1,38 @@
|
||||
# Aufgabe 07: Tool Dispatcher bauen
|
||||
|
||||
## Ziel
|
||||
|
||||
Du baust einen Dispatcher, der validierte Tool Calls auf lokale Funktionen abbildet.
|
||||
|
||||
## Warum ist das wichtig?
|
||||
|
||||
Das LLM soll Entscheidungen vorschlagen, aber dein Code führt kontrolliert aus.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
- Aufgabe 06
|
||||
- Rust oder Python
|
||||
|
||||
## Theorie
|
||||
|
||||
Der Dispatcher ist die Sicherheitsgrenze. Er validiert Argumente, ruft Funktionen auf, behandelt Fehler und gibt strukturierte Ergebnisse zurück.
|
||||
|
||||
## Aufgabe
|
||||
|
||||
Implementiere einen Dispatcher für mindestens vier Fake-Tools und schreibe Tests für gültige und ungültige Aufrufe.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
- Bekannte Tools werden ausgeführt.
|
||||
- Unbekannte Tools liefern Fehler.
|
||||
- Argumente werden validiert und geloggt.
|
||||
|
||||
## Erweiterungen
|
||||
|
||||
- Füge Berechtigungslevel für Hardware-Tools hinzu.
|
||||
|
||||
## Reflexionsfragen
|
||||
|
||||
- Warum sollte das LLM keine Shell ausführen dürfen?
|
||||
- Welche Fehler soll der Dispatcher verbergen?
|
||||
- Welche Tool-Ergebnisse gehören zurück ins Modell?
|
||||
@@ -0,0 +1,38 @@
|
||||
# Aufgabe 08: Agent Loop implementieren
|
||||
|
||||
## Ziel
|
||||
|
||||
Du baust den Loop User Input -> LLM -> Tool -> LLM -> Antwort.
|
||||
|
||||
## Warum ist das wichtig?
|
||||
|
||||
Der finale Roboter braucht genau diese Schleife, nur später mit echten Services.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
- Aufgaben 05-07
|
||||
- LLM Provider
|
||||
|
||||
## Theorie
|
||||
|
||||
Ein Agent Loop ist eine kontrollierte Iteration. Er endet bei einer finalen Antwort oder nach einer maximalen Anzahl von Tool-Schritten.
|
||||
|
||||
## Aufgabe
|
||||
|
||||
Implementiere einen Loop mit maximal drei Tool Calls pro Anfrage, Tool-Ergebnis-Rückgabe und finaler Antwort.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
- Frage nach Uhrzeit nutzt Tool.
|
||||
- Frage nach Personen nutzt Fake-Tool.
|
||||
- Endlosschleifen werden begrenzt.
|
||||
|
||||
## Erweiterungen
|
||||
|
||||
- Zeige eine Debug-Ansicht aller Loop-Schritte.
|
||||
|
||||
## Reflexionsfragen
|
||||
|
||||
- Wann sollte der Loop abbrechen?
|
||||
- Wie erkennst du Tool-Spam?
|
||||
- Welche Daten sieht das Modell nach einem Tool Call?
|
||||
@@ -0,0 +1,38 @@
|
||||
# Aufgabe 09: Fehlerbehandlung, Logging und Memory
|
||||
|
||||
## Ziel
|
||||
|
||||
Du ergänzt robuste Fehlerpfade, strukturierte Logs und ein kleines Memory.
|
||||
|
||||
## Warum ist das wichtig?
|
||||
|
||||
Robotikfehler entstehen an API-, Sensor- und Hardwaregrenzen. Gute Beobachtbarkeit ist Pflicht.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
- Aufgaben 01-08
|
||||
- Logging-Grundlagen
|
||||
|
||||
## Theorie
|
||||
|
||||
Logs beantworten die Frage, was wirklich passiert ist. Memory speichert ausgewählte Fakten, aber keine ungeprüften Halluzinationen.
|
||||
|
||||
## Aufgabe
|
||||
|
||||
Erweitere den Agenten um strukturierte Logs, Fehlercodes und ein Key-Value-Memory für explizit bestätigte Fakten.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
- Jeder Request hat eine Trace-ID.
|
||||
- Tool-Fehler sind sichtbar.
|
||||
- Memory kann gelesen und geschrieben werden.
|
||||
|
||||
## Erweiterungen
|
||||
|
||||
- Füge Log-Level und JSON-Logs hinzu.
|
||||
|
||||
## Reflexionsfragen
|
||||
|
||||
- Welche Fehler sind wiederholbar?
|
||||
- Welche Fakten darf der Agent speichern?
|
||||
- Wie würdest du Logs in Docker sammeln?
|
||||
@@ -0,0 +1,19 @@
|
||||
# AI-Agent-Grundlagen
|
||||
|
||||
LLM-Zugriff, Nachrichtenmodell, Tool Calling, Agent Loop, Fehlerbehandlung und Memory.
|
||||
|
||||
## Aufgaben
|
||||
|
||||
- [01: LLM API per CLI ansprechen](01-llm-api-per-cli-ansprechen.md)
|
||||
- [02: Ollama und Cloud API vergleichen](02-ollama-und-cloud-api-vergleichen.md)
|
||||
- [03: Chat Messages modellieren](03-chat-messages-modellieren.md)
|
||||
- [04: System Prompt entwerfen](04-system-prompt-entwerfen.md)
|
||||
- [05: Conversation History verwalten](05-conversation-history-verwalten.md)
|
||||
- [06: JSON Tool Schema definieren](06-json-tool-schema-definieren.md)
|
||||
- [07: Tool Dispatcher bauen](07-tool-dispatcher-bauen.md)
|
||||
- [08: Agent Loop implementieren](08-agent-loop-implementieren.md)
|
||||
- [09: Fehlerbehandlung, Logging und Memory](09-fehlerbehandlung-logging-und-memory.md)
|
||||
|
||||
## Arbeitsweise
|
||||
|
||||
Bearbeite die Aufgaben nacheinander. Jede Aufgabe soll ein kleines, überprüfbares Ergebnis liefern und ist bewusst auf etwa 1 bis 4 Stunden ausgelegt.
|
||||
Reference in New Issue
Block a user