Computer, lokale AI und Game Development

2. Anwenden

Im Support begegnet dir Computer-Hardware: CPU, RAM, Storage, GPU als Teil eines realen Arbeitsablaufs: Anfrage aufnehmen, Risiko einschaetzen, Fakten prüfen, Ergebnis dokumentieren.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Was ist der kleinste testbare Prototyp?

  Der kleinste testbare Prototyp ist die simpelste Version, mit der du eine Annahme prüfen kannst. Du baust nur so viel, dass sichtbar wird, ob der Kern funktioniert, bevor du Zeit in Details steckst.
• Welche Eingabe verändert welchen Zustand?

  Gemeint ist: Welche konkrete Nutzeraktion, Datei, Anfrage oder Messung verändert welchen Zustand im System? Benenne Eingabe, Verarbeitung, Ergebnis und sichtbares Feedback getrennt.
• Wie merkt der Spieler oder Nutzer, dass etwas funktioniert?

  Der Nutzer erkennt Funktion daran, dass eine erwartete Rückmeldung erscheint: Bild, Ton, Status, gespeicherte Änderung, Fehlermeldung, Messwert oder reproduzierbares Verhalten.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, Computer-Hardware: CPU, RAM, Storage, GPU nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird Computer-Hardware: CPU, RAM, Storage, GPU in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Dieser Begriff ist ein Einstiegspunkt und setzt nur Grundverständnis sowie sauberes Lesen voraus.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: CPU, RAM, SSD (Solid State Drive).

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei Computer-Hardware: CPU, RAM, Storage, GPU heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Tickets enthalten Lösungsversuche, aber keine Faktenlage, Repro-Schritte oder klare Auswirkung.
• First Level versucht zu lange allein zu lösen, statt sauber zu eskalieren.
• Sicherheitsprüfungen werden aus Zeitdruck übersprungen, besonders bei Passwort, MFA und Remote-Zugriff.
• Symptome werden beseitigt, aber Ursache, Workaround und Dokumentation bleiben offen.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

Im Support begegnet dir Terminal, Shell und CLI als Teil eines realen Arbeitsablaufs: Anfrage aufnehmen, Risiko einschaetzen, Fakten prüfen, Ergebnis dokumentieren.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Was ist der kleinste testbare Prototyp?

  Der kleinste testbare Prototyp ist die simpelste Version, mit der du eine Annahme prüfen kannst. Du baust nur so viel, dass sichtbar wird, ob der Kern funktioniert, bevor du Zeit in Details steckst.
• Welche Eingabe verändert welchen Zustand?

  Gemeint ist: Welche konkrete Nutzeraktion, Datei, Anfrage oder Messung verändert welchen Zustand im System? Benenne Eingabe, Verarbeitung, Ergebnis und sichtbares Feedback getrennt.
• Wie merkt der Spieler oder Nutzer, dass etwas funktioniert?

  Der Nutzer erkennt Funktion daran, dass eine erwartete Rückmeldung erscheint: Bild, Ton, Status, gespeicherte Änderung, Fehlermeldung, Messwert oder reproduzierbares Verhalten.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, Terminal, Shell und CLI nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird Terminal, Shell und CLI in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Dieser Begriff ist ein Einstiegspunkt und setzt nur Grundverständnis sowie sauberes Lesen voraus.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: PowerShell.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei Terminal, Shell und CLI heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Tickets enthalten Lösungsversuche, aber keine Faktenlage, Repro-Schritte oder klare Auswirkung.
• First Level versucht zu lange allein zu lösen, statt sauber zu eskalieren.
• Sicherheitsprüfungen werden aus Zeitdruck übersprungen, besonders bei Passwort, MFA und Remote-Zugriff.
• Symptome werden beseitigt, aber Ursache, Workaround und Dokumentation bleiben offen.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

Du willst interne Notizen auswerten, ohne sie an einen Cloud-Dienst zu senden. Lokale AI verschiebt Verantwortung, Hardwarebedarf und Datenschutz zu dir.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Welche Aufgabe soll das Modell wirklich lösen?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du willst interne Notizen auswerten, ohne sie an einen Cloud-Dienst zu senden. Lokale AI verschiebt Verantwortung, Hardwarebedarf und Datenschutz zu dir.
• Welche Daten dürfen lokal, intern oder extern verarbeitet werden?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du willst interne Notizen auswerten, ohne sie an einen Cloud-Dienst zu senden. Lokale AI verschiebt Verantwortung, Hardwarebedarf und Datenschutz zu dir.
• Woran misst du, ob die Antwort gut genug, schnell genug und verlässlich genug ist?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du willst interne Notizen auswerten, ohne sie an einen Cloud-Dienst zu senden. Lokale AI verschiebt Verantwortung, Hardwarebedarf und Datenschutz zu dir.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, Lokale AI Grundlagen nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird Lokale AI Grundlagen in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Die wichtigsten Engine-Kategorien 2026 (Stand 2026-07-20):

vLLM (HW-06): Apache-2.0-lizenzierter Inference-Server für echte Nebenläufigkeit. Schlüsselfeature: PagedAttention — KV-Cache wird in Pages organisiert (ähnlich virtuellem Speicher im OS), wodurch Memory-Fragmentierung stark sinkt und mehrere Requests effizient gebatcht werden. In der Praxis skaliert vLLM mit der Concurrency: von 1 auf 8 gleichzeitige Requests werden etwa 3,9- bis 5,4× mehr Gesamt-Throughput gemessen ([HW-06]). Damit ist vLLM die übliche Wahl, wenn mehr als eine Handvoll Nutzer gleichzeitig dasselbe Modell bedienen wollen — also genau dort, wo Ollama/LM Studio an ihre Grenze kommen.

MLX (HW-07): Apple-Framework (MIT, nur Apple Silicon) für GPU/CPU/Unified-Memory-Inferenz auf M-Chips. Zusammen mit dem MLX-Quant-Format und MLX-LM ist das 2026 der Standardweg für lokale LLMs auf Macs; performanter als CPU-Only-Backends, da Unified Memory direkt genutzt wird. Apple-Vergleichsstudien (HW-09) zeigen, dass M-Serie für viele Open-Modelle gut geeignet ist, aber bei bandbreitekritischen großen Modellen hinter dedizierten NVIDIA-GPUs liegt.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Dieser Begriff ist ein Einstiegspunkt und setzt nur Grundverständnis sowie sauberes Lesen voraus.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: LLM-Grundlagen, AI-Hardware für lokale Modelle.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei Lokale AI Grundlagen heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Ein Modell wird nach Hype ausgewählt, nicht nach Datenlage, Hardware, Lizenz, Latenz und Qualitätsmessung.
• Falsche Engine für den Use Case: llama.cpp/Ollama für Produktionsservices mit hoher Nebenläufigkeit (statt vLLM), oder vLLM für den Einzelplatz-Mac (statt MLX).
• PagedAttention-Skalierung als „5× schneller pro Anfrage" missverstanden — sie skaliert den Gesamt-Throughput bei mehreren gleichzeitigen Requests, nicht die Einzel-Anfrage-Latenz.
• Token/s ohne vollständigen Kontext (CPU/GPU, Quant, Kontext, Batch, Runtime, Quelle) sind wertlos; Herstellers-Benchmarks (LocalAI Master, Spheron, mustafa.net u.a.) sind Eigenmessungen und teils spekulativ.
• RAG wird als Wahrheitssystem missverstanden, obwohl Retrieval, Kontext und Modellantwort getrennt validiert werden müssen.
• Lokale Verarbeitung wird automatisch als datenschutzsicher betrachtet, obwohl Logs, Plugins, Downloads und Benutzerrechte weiter relevant sind (siehe Datenschutz bei lokaler AI).
• Benchmarks ersetzen keine eigenen Testfälle aus der echten Arbeit.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

Du prüfst ein LLM immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit. Drei schnelle Fragen:

• Welche Aufgabe soll das Modell wirklich lösen?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst ein LLM immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit. Drei schnelle Fragen:
• Welche Daten dürfen lokal, intern oder extern verarbeitet werden?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst ein LLM immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit. Drei schnelle Fragen:
• Darf ich das Modell frei verwenden, nur intern oder nur gegen Bezahlung? → Lizenz!

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Nimm ein Modell aus der Snapshot-Tabelle unten und notiere in zwei Sätzen, in welche der drei Gruppen (proprietär / open weight / Open Source) es fällt – und warum.

Vorher solltest du Token und Lokale AI Grundlagen verstanden haben.

3. Technisch einordnen

Auf Level 2 trennst du proprietär, open weight und Open Source sauber und erkennst die typischen Snapshot-Fakten eines Modells.

Drei Lizenzgruppen (Stichtag 2026-07-20)

• Proprietär / Cloud-API: Modell nur über API nutzbar, Gewichte nicht veröffentlicht. Beispiele: GPT-5.2 (OpenAI, LLM-01, Release 2026-06-26), Claude Opus 4.5 (Anthropic, LLM-03, Release 2025-11-24), Gemini 3 Pro (Google, LLM-05, Release 2025-11-18, 1M–2M Kontext).
• Open Source (OSI-konform): Freie Lizenz wie Apache 2.0 oder MIT. Beispiele: Qwen3 (LLM-07, Apache 2.0, Release 2025-04-29), DeepSeek V3.2 (LLM-10, MIT, 671B/37B aktiv), Phi-4 (LLM-15, MIT, 14B), GLM-4.6 (LLM-17, MIT, 355B/~32B).
• Open weight (NICHT OSI-konform): Gewichte herunterladbar, aber mit eigener Lizenz. Beispiele: Llama 4 Scout (LLM-12, Llama Community License mit MAU-Cap), Gemma 3 (LLM-14, 1B–27B, Gemma License), Mistral Large 2 (LLM-18, Mistral Research License – oft fälschlich als Apache bezeichnet).

Wichtig: „Open weight" ist nicht gleich „Open Source". Apache 2.0 und MIT sind OSI-konform; Llama-, Gemma- und Mistral-Lizenzen sind es nicht. Für Hobbyisten ist der MAU-Cap der Llama-Lizenz praktisch oft irrelevant, für kommerzielle Nutzung muss er aber geprüft werden.

Spezialisierungen (Beispiele)

• Coder-Modelle: Qwen3-Coder 480B/35B, 256K Kontext, Apache 2.0 (LLM-09) – SWE-bench via OpenHands-Harness.
• MoE mit Sparse Attention: DeepSeek V3.2 mit DSA (LLM-11).
• Sehr großes MoE, Modified MIT: Kimi K2 1T/32B (LLM-16).

Runtime für lokale/self-hosted Modelle

Für Server-Serving ist vLLM (HW-06, Apache 2.0, PagedAttention) der Standards – skaliert deutlich besser als Convenience-Tools. Mehr dazu in llama.cpp, Ollama, LM Studio.

Schema für die Praxis

1. Eingang: Welche Beobachtung, Anfrage oder Aufgabe startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten (Lizenz, Kontextlänge, Größe, Benchmark) müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du (Modellversion + Datum + Lizenz + Quelle)?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Für Benchmark-Zahlen gilt das Pflichtwissen aus Modelle benchmarken: Jede Zahl braucht Quelle, Harness und Stichtag.

Verwandte Begriffe für die Vertiefung: Token, Prompt Design (Engineering), Lokale AI Grundlagen, Modelle benchmarken.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen.

Snapshot ist nicht Ewigkeit

Eine Modell-Lizenz kann sich zwischen Releases ändern – Apache 2.0 in Version N bedeutet nicht Apache 2.0 in Version N+1. Prüfe bei jedem Upgrade die aktuelle Model Card und das Datum.

Praxisfallen

• „Open Source" = „Gewichte vorhanden": Falsch. Llama 4, Gemma 3 und Mistral Large 2 sind „open weight", nicht OSI-konform „Open Source".
• Hersteller-Benchmark ohne Harness-Info: Herstellerzahlen sind Selektion – siehe Modelle benchmarken.
• Mistral Large 2 als Apache 2.0 bezeichnen: Häufiger Fehler. Es steht unter der Mistral Research License (LLM-18).
• Ein Modell nach Hype auswählen: Statt Datenlage, Hardware, Lizenz, Latenz und eigener Qualitätsmessung zu prüfen.
• RAG als Wahrheitssystem: Retrieval, Kontext und Modellantwort müssen getrennt validiert werden.
• Lokale Verarbeitung automatisch als sicher betrachten: Logs, Plugins, Downloads und Benutzerrechte bleiben relevant.
• Benchmarks als einziger Maßstab: Sie ersetzen keine eigenen Testfälle aus der echten Arbeit.

Goldstandard

Du kannst einem Laien die drei Lizenzgruppen erklären, ein Modell korrekt zuordnen, Modellversion + Datum + Lizenz + Quelle dokumentieren und die Grenze zwischen Snapshot und Ewigkeit benennen.

2. Anwenden

Du prüfst ein Modell immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit. Bevor du irgendwelche Benchmark-Zahlen vergleichst, kläre vier Punkte:

• Aufgabe: Welche Aufgabe soll das Modell wirklich lösen (z. B. Python-Code reparieren, deutsche Texte zusammenfassen, SQL generieren)?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst ein Modell immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit. Bevor du irgendwelche Benchmark-Zahlen vergleichst, kläre vier Punkte:
• Harness: In welcher Umgebung wird gemessen? Dasselbe Modell in zwei Harnesses kann sehr verschieden abschneiden.
• Stichtag: Wann wurde gemessen? Eine Zahl von 2025 kann heute veraltet sein.
• Eigene Suite: Hast du eigene Testfälle aus deiner echten Arbeit, anstatt nur öffentliche Benchmarks zu vertrauen?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst ein Modell immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit. Bevor du irgendwelche Benchmark-Zahlen vergleichst, kläre vier Punkte:

Als Anfänger arbeitest du mit dieser Prüfliste. Das Ziel ist nicht, sofort Experte zu sein, sondern den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Nimm eine öffentliche Benchmark-Zahl (z. B. „Modell X erreicht 80% auf SWE-bench") und notiere in zwei Sätzen: Wer hat gemessen, mit welchem Harness, an welchem Datum? Wenn du das nicht beantworten kannst, ist die Zahl nicht verwendbar.

Vorher solltest du LLM-Grundlagen und AI-Hardware für lokale Modelle verstanden haben.

3. Technisch einordnen

Auf Level 2 geht es um die Mechanismen, die Benchmarks vertrauenswürdig oder täuschend machen. Wer diese Punkte nicht kennt, liest Benchmark-Tabellen falsch.

1. Kontamination (Data Contamination)

Wenn Aufgaben oder Lösungen einer Benchmark im Trainingsdaten des Modells enthalten waren, sind die Ergebnisse wertlos – das Modell „weiß" die Antwort, statt sie zu lösen. OpenAI hat SWE-bench Verified 2026 offiziell als kontaminiert eingestuft und evaluiert es nicht mehr (Quelle: LLM-20). Auch das Hugging Face Open LLM Leaderboard wurde deshalb eingestellt (LLM-25). Überblick: LLM-26.

2. Statisch vs. erneuert

• Statisch (fester Satz Aufgaben, z. B. SWE-bench Verified, MMLU): anfällig für Kontamination, sobald der Satz bekannt ist.
• Erneuert (z. B. LiveBench, LiveCodeBench): neue Aufgaben regelmäßig, schwerer zu kontaminieren. Bevorzugen für aktuelle Vergleiche.

3. Modell vs. Agent/Harness

Das ist der wichtigste Punkt überhaupt. SWE-bench Verified misst nicht „das Modell", sondern Modell + Scaffolding/Harness. Die Epoch-AI-Analyse (LLM-28) zeigt: Ein Teil der Punktzahl kommt aus dem Werkzeug, das das Modell umgibt, nicht aus dem Modell selbst.

Konkretes Beispiel Claude Opus 4.5 (LLM-04, Stand 2025-11-24):

• Herstellerangabe Anthropic: 80,9% SWE-bench Verified – im Anthropic-eigenen Harness.
• Leaderboard (unabhängig): 76,80% SWE-bench Verified – im Standard-Harness mini-SWE-agent v2.0.0 (swebench.com, Stand 2026, Zugriff 2026-07-20).

Die Differenz von über 4 Punkten entsteht nicht durch das Modell, sondern durch den Harness. Eine Scaffolding-Analyse (LLM-29, 2026-06) fand Harness-bedingte Differenzen bis zu 28 Punkte. Deshalb sind SWE-bench-Scaffolds nicht direkt zwischen Herstellern vergleichbar – jeder misst im eigenen Werkzeug.

Analog bei Gemini 3 Pro (LLM-06): 76% Herstellerangabe Google vs. 69,60% Leaderboard. Gleicher Effekt: Harness-Unterschied.

4. pass@1 vs. pass@k

• pass@1: Eine Lösung, ein Versuch – entspricht der realen Nutzung in der Produktion.
• pass@k (k=5, 10 …): Mehrere Lösungen generieren, eine davon stimmt. Sieht beeindruckend aus, ist aber eine andere Aussage (LLM-27). Verwechsle die beiden nie beim Vergleich.

5. Self-Reported vs. unabhängig gemessen

Herstellerangaben sind Selektion: Sie werden im günstigsten Harness, mit der besten Sampling-Strategie und oft ohne Kontamination-Prüfung erhoben. Behandle Herstellerzahlen immer als „Herstellerangabe, eigener Harness" – nicht als Fakt. Beispiel GPT-5.2: 80% SWE-bench Verified (LLM-02) ist eine reine Herstellerangabe im OpenAI-eigenen Harness.

6. Test-Time-Compute

Ein Modell darf „nachdenken" (Reasoning, Tool-Use, mehrere Versuche) und dabei mehr Rechenzeit verbrauchen. Mehr Compute verbessert oft die Punktzahl – ohne dass das Modell selbst besser ist. Beim Vergleich muss das Compute-Budget gleich sein (LLM-27).

7. ELO / Arena-Grenzen

LMArena sammelt menschliche Präferenzen zu Chat-Antworten und errechnet einen ELO-Wert. Nützlich für „wie das Modell im Chat ankommt", aber: subjektiv, sprachlich verzerrt (viel Englisch), und innerhalb der Top 10 liegen oft nur etwa 20 ELO-Punkte – eine klare Rangfolge „das beste Modell" ist daraus nicht ableitbar (LLM-23).

8. Composite-Scores (Intelligence Index)

Artificial Analysis Intelligence Index V2 fasst mehrere Benchmarks zu einer Zahl zusammen. Praktisch, aber immer eine Redaktion – prüfe, welche Benchmarks eingehen und wie gewichtet wird (LLM-24).

9. Warum die eigene Aufgabensuite nötig ist

Öffentliche Benchmarks sind ein Stichproben-Indikator, kein Beweis für deinen Fall. Wenn du Python-Code mit einer internen Bibliothek reparieren willst, misst SWE-bench (Open-Source-Repositories) eine andere Welt. Bau eine kleine eigene Suite aus echten Aufgaben – 20–50 Fälle reichen für einen ersten Realitätscheck. Benchmarks ersetzen keine eigenen Testfälle aus der echten Arbeit.

Snapshot SWE-bench Verified (Stand 2026, Zugriff 2026-07-20)

Snapshot-Warnung: Die Leaderboard-Werte ändern sich täglich. Herstellerangaben sind Selektion.

Verwandte Begriffe für die Vertiefung: AI-Hardware für lokale Modelle, Quantisierung lokaler Modelle, LLM-Grundlagen.

4. Vertiefen

Auf Expertenniveau geht es darum, Benchmarks nicht zu überschätzen und Saturierungseffekte zu erkennen.

Warum alte saturierte Benchmarks keine aktuelle Frontier-Rangliste beweisen

Sobald eine Benchmark „saturiert" ist – fast alle Frontier-Modelle liegen eng beieinander nahe der 100% – verliert sie Trennkraft. MMLU und der ursprüngliche Open LLM Leaderboard sind Beispiele: Sie trennen nicht mehr zwischen aktuellen Top-Modellen. Wer heute aus einem saturierten Benchmark eine Rangliste „das beste Modell" ableitet, überschreitet die Aussagekraft der Daten.

Praxisfallen

• Herstellerzahl = Fakt: Eine Herstellerangabe ist eine Selektion, kein unabhängiger Befund. Immer Harness und Datum prüfen.
• Apples-to-Oranges: Verschiedene Harnesses, Sampling-Strategien und Compute-Budgets in einer Tabelle vermischen.
• Snapshot als Ewigkeit: Eine Zahl von vor 6 Monaten für „das beste Modell heute" halten, obwohl Live-Benchmarks sich täglich bewegen.
• Kontamination ignoriert: Eine statische Benchmark verwenden, ohne zu prüfen, ob sie kontaminiert ist.
• Eine Zahl für alles: SWE-bench misst Software-Engineering. Es sagt nichts über Zusammenfassen, Übersetzen oder Reasoning in deinem Anwendungsfall.
• Hype-Auswahl: Ein Modell nach viralen Rankings wählen, nicht nach Datenlage, Hardware, Lizenz, Latenz und eigener Qualitätsmessung.
• Lokale Verarbeitung = sicher: Lokal heißt nicht automatisch datenschutzsicher – Logs, Plugins, Downloads, Benutzerrechte bleiben relevant.

Goldstandard

Du kannst einem Laien erklären, warum eine Benchmark-Zahl allein nichts beweist; den Harness-Effekt am Claude-Opus-4.5-Beispiel (80,9% vs. 76,80%) nachvollziehbar zeigen; eine eigene Mini-Suite aus realen Aufgaben bauen; Grenzen sauber benennen; und deine Entscheidung mit Quelle, Harness und Datum dokumentieren.

2. Anwenden

Du prüfst Kontextfenster immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Welche Aufgabe soll das Modell wirklich lösen?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst Kontextfenster immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.
• Welche Daten dürfen lokal, intern oder extern verarbeitet werden?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst Kontextfenster immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.
• Woran misst du, ob die Antwort gut genug, schnell genug und verlässlich genug ist?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst Kontextfenster immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, Kontextfenster nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird Kontextfenster in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Vorher solltest du LLM-Grundlagen verstanden haben.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: Token, Prompt Engineering, Lokales RAG.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei Kontextfenster heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Ein Modell wird nach Hype ausgewählt, nicht nach Datenlage, Hardware, Lizenz, Latenz und Qualitätsmessung.
• RAG wird als Wahrheitssystem missverstanden, obwohl Retrieval, Kontext und Modellantwort getrennt validiert werden müssen.
• Lokale Verarbeitung wird automatisch als datenschutzsicher betrachtet, obwohl Logs, Plugins, Downloads und Benutzerrechte weiter relevant sind.
• Benchmarks ersetzen keine eigenen Testfälle aus der echten Arbeit.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

Du prüfst Embedding immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Welche Aufgabe soll das Modell wirklich lösen?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst Embedding immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.
• Welche Daten dürfen lokal, intern oder extern verarbeitet werden?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst Embedding immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.
• Woran misst du, ob die Antwort gut genug, schnell genug und verlässlich genug ist?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst Embedding immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, Embedding nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird Embedding in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Vorher solltest du LLM-Grundlagen verstanden haben.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: Vektor-Datenbank, Lokales RAG.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei Embedding heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Ein Modell wird nach Hype ausgewählt, nicht nach Datenlage, Hardware, Lizenz, Latenz und Qualitätsmessung.
• RAG wird als Wahrheitssystem missverstanden, obwohl Retrieval, Kontext und Modellantwort getrennt validiert werden müssen.
• Lokale Verarbeitung wird automatisch als datenschutzsicher betrachtet, obwohl Logs, Plugins, Downloads und Benutzerrechte weiter relevant sind.
• Benchmarks ersetzen keine eigenen Testfälle aus der echten Arbeit.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

Du prüfst Vektor-Datenbank immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Welche Aufgabe soll das Modell wirklich lösen?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst Vektor-Datenbank immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.
• Welche Daten dürfen lokal, intern oder extern verarbeitet werden?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst Vektor-Datenbank immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.
• Woran misst du, ob die Antwort gut genug, schnell genug und verlässlich genug ist?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst Vektor-Datenbank immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, Vektor-Datenbank nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird Vektor-Datenbank in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Vorher solltest du Embedding verstanden haben.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: Embedding, Lokales RAG.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei Vektor-Datenbank heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Ein Modell wird nach Hype ausgewählt, nicht nach Datenlage, Hardware, Lizenz, Latenz und Qualitätsmessung.
• RAG wird als Wahrheitssystem missverstanden, obwohl Retrieval, Kontext und Modellantwort getrennt validiert werden müssen.
• Lokale Verarbeitung wird automatisch als datenschutzsicher betrachtet, obwohl Logs, Plugins, Downloads und Benutzerrechte weiter relevant sind.
• Benchmarks ersetzen keine eigenen Testfälle aus der echten Arbeit.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

Du prüfst Prompt Engineering immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Welche Aufgabe soll das Modell wirklich lösen?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst Prompt Engineering immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.
• Welche Daten dürfen lokal, intern oder extern verarbeitet werden?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst Prompt Engineering immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.
• Woran misst du, ob die Antwort gut genug, schnell genug und verlässlich genug ist?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst Prompt Engineering immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, Prompt Engineering nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird Prompt Engineering in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Vorher solltest du LLM-Grundlagen verstanden haben.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: LLM-Grundlagen, Kontextfenster.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei Prompt Engineering heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Ein Modell wird nach Hype ausgewählt, nicht nach Datenlage, Hardware, Lizenz, Latenz und Qualitätsmessung.
• RAG wird als Wahrheitssystem missverstanden, obwohl Retrieval, Kontext und Modellantwort getrennt validiert werden müssen.
• Lokale Verarbeitung wird automatisch als datenschutzsicher betrachtet, obwohl Logs, Plugins, Downloads und Benutzerrechte weiter relevant sind.
• Benchmarks ersetzen keine eigenen Testfälle aus der echten Arbeit.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

Du prüfst AI-Hardware für lokale Modelle immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Welche Aufgabe soll das Modell wirklich lösen?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst AI-Hardware für lokale Modelle immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.
• Welche Daten dürfen lokal, intern oder extern verarbeitet werden?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst AI-Hardware für lokale Modelle immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.
• Woran misst du, ob die Antwort gut genug, schnell genug und verlässlich genug ist?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst AI-Hardware für lokale Modelle immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, AI-Hardware für lokale Modelle nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird AI-Hardware für lokale Modelle in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Vorher solltest du Computer-Hardware: CPU, RAM, Storage, GPU verstanden haben.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: RAM, Quantisierung lokaler Modelle.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei AI-Hardware für lokale Modelle heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Hardware-Matrix nach VRAM/RAM-Klassen (Stand 2026-07-20)

Modellgrößen sind Beispiele aus offiziellen Model Cards als Q4_K_M (≈ 96-96,5% der Basisqualität, siehe Quantisierung lokaler Modelle). Die Angabe „Dateigröße" ist das auf der Platte gemessene Quant. „RAM-Reserve" zusätzlich zur Modell-Datei für KV-Cache, Runtime und Betriebssystem.

Beispiel-Speicherbedarf (HW-02):

• Qwen3-8B Q4 ≈ 5 GB Datei → ~6-7 GB RAM/VRAM praktisch (Apache-2.0, LLM-07)
• Phi-4-14B Q4 ≈ 9 GB Datei → ~10-11 GB praktisch (MIT, LLM-15)
• DeepSeek-V3 Q4 ≈ 404 GB Datei → mehr als 400 GB VRAM/RAM (MIT, LLM-10) — nur Multi-GPU/Server oder über Streaming-Ansätze (Proof-of-Concept, siehe Colibrì: 744B-MoE von Platte streamen auf sehr langsamen Boxen)

KV-Cache wächst mit Kontextlänge: Bei 8B-Modellen kann ein 32K-Kontext den Cache auf mehrere GB anwachsen lassen. Wer lange Dokumente verarbeitet, reserviert VRAM lieber großzügig oder arbeitet mit kontexteffizienten Architekturen (MLA/DSA bei DeepSeek/GLM).

Lizenz/Privacy-Kurzhinweis (HW-10): Qwen3, DeepSeek und Phi-4 sind MIT/Apache-2.0 (OSI-konform). Llama 4 nutzt die Llama Community License mit MAU-Cap — für Hobbyisten irrelevant, für kommerzielle Dienste prüfenswert. Lokal bedeutet nicht automatisch DSGVO-sicher: Logs, Plugins und Update-Checks können weiterhin Daten senden (siehe Datenschutz bei lokaler AI).

Wann Cloud besser ist (Faustregel): Frontier-Qualität (GPT-5.2, Claude 4.5, Gemini 3 Pro), sehr lange Kontexte jenseits der eigenen VRAM-Reserve, mehrstufige Agenten, hohe Nebenläufigkeit (>5 gleichzeitige User) oder wenn Anschaffungskosten für passende Hardware den Cloud-Verbrauch für Monate übersteigen.

Apple Silicon (HW-07, HW-09): MLX (MIT, Apple-only) ist 2026 der Standard-Pfad für M-Serie-Chips. Unified Memory macht das VRAM/RAM-Splitting einfacher; eine 64-GB-Max-Kiste entspricht grob einer „48-56 GB nutzbaren VRAM"-Klasse bei niedrigerer Bandbreite als dedizierte HBM-GPUs.

Die wichtigsten Praxisfallen

• Ein Modell wird nach Hype ausgewählt, nicht nach Datenlage, Hardware, Lizenz, Latenz und Qualitätsmessung.
• KV-Cache wird vergessen: Ein „8 GB"-Modell in „8 GB VRAM" läuft, aber nur mit winzigem Kontext.
• CPU-Benchmarks werden mit GPU-Zahlen verwechselt — Token/s ohne vollständigen Kontext (CPU/GPU, Quant, Kontext, Batch, Runtime, Quelle) sind wertlos.
• Herstellers-Benchmarks (LocalAI Master, Spheron, mustafa.net u.a.) sind oft Eigenmessungen und teils spekulativ; bevorzuge offizielle Repos und Model Cards.
• RAG wird als Wahrheitssystem missverstanden, obwohl Retrieval, Kontext und Modellantwort getrennt validiert werden müssen.
• Lokale Verarbeitung wird automatisch als datenschutzsicher betrachtet, obwohl Logs, Plugins, Downloads und Benutzerrechte weiter relevant sind.
• Benchmarks ersetzen keine eigenen Testfälle aus der echten Arbeit.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

Du prüfst Quantisierung lokaler Modelle immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Welche Aufgabe soll das Modell wirklich lösen?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst Quantisierung lokaler Modelle immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.
• Welche Daten dürfen lokal, intern oder extern verarbeitet werden?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst Quantisierung lokaler Modelle immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.
• Woran misst du, ob die Antwort gut genug, schnell genug und verlässlich genug ist?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst Quantisierung lokaler Modelle immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, Quantisierung lokaler Modelle nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird Quantisierung lokaler Modelle in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Vorher solltest du LLM-Grundlagen verstanden haben.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: AI-Hardware für lokale Modelle, LLM-Grundlagen.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei Quantisierung lokaler Modelle heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Container- und Quant-Formate (Stand 2026-07-20)

Qualitätsverluste pro Stufe (Richtungswerte)

Die folgenden Werte sind branchenbekannte Richtwerte, nicht fixe Konstanten. Das tatsächliche Perplexity/Differenz hängt am konkreten Modell und Task.

• FP16 → Q8_0: praktisch kaum messbarer Qualitätsverlust (~99%+)
• FP16 → Q6_K: sehr nah an FP16 (~98%+)
• FP16 → Q5_K_M: minimale Einbußen (~97-98%)
• FP16 → Q4_K_M: ~96-96,5% der Basisqualität (HW-01) — Standard-Kompromiss 2026
• FP16 → Q3 / Q2: spürbarer Qualitätsabfall (Schema-Verlust, Halluzinationen); nur als Notlösung bei extrem limitiertem VRAM

Mnemonic: „Q4 ist der Sweet Spot, Q8 ist fast wie Original, unter Q3 wird es dünn." Für AWQ/EXL2 gelten ähnliche Werte auf der 4-Bit-Ebene, EXL2 erlaubt variable Bit-Breiten pro Schicht (z.B. 4.5 bpw).

Die wichtigsten Praxisfallen

• Ein Modell wird nach Hype ausgewählt, nicht nach Datenlage, Hardware, Lizenz, Latenz und Qualitätsmessung.
• Quants als „verlustfrei" missverstanden — Q4 ist gut, aber nicht FP16.
• Format mit Hardware verwechselt: AWQ/EXL2 brauchen NVIDIA, GGUF läuft nahezu überall, MLX nur auf Apple.
• Herstellers-Benchmarks (LocalAI Master, Spheron, mustafa.net u.a.) oft Eigenmessungen — Token/s ohne CPU/GPU, Quant, Kontext, Batch, Runtime und Quelle sind wertlos.
• RAG wird als Wahrheitssystem missverstanden, obwohl Retrieval, Kontext und Modellantwort getrennt validiert werden müssen.
• Lokale Verarbeitung wird automatisch als datenschutzsicher betrachtet, obwohl Logs, Plugins, Downloads und Benutzerrechte weiter relevant sind.
• Benchmarks ersetzen keine eigenen Testfälle aus der echten Arbeit.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

Du brauchst maximale Kontrolle über lokale Inference, Quantisierung und Hardware-Backends, statt nur eine fertige App zu nutzen.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Welche Aufgabe soll das Modell wirklich lösen?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du brauchst maximale Kontrolle über lokale Inference, Quantisierung und Hardware-Backends, statt nur eine fertige App zu nutzen.
• Welche Daten dürfen lokal, intern oder extern verarbeitet werden?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du brauchst maximale Kontrolle über lokale Inference, Quantisierung und Hardware-Backends, statt nur eine fertige App zu nutzen.
• Woran misst du, ob die Antwort gut genug, schnell genug und verlässlich genug ist?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du brauchst maximale Kontrolle über lokale Inference, Quantisierung und Hardware-Backends, statt nur eine fertige App zu nutzen.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, llama.cpp nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird llama.cpp in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Was llama.cpp auszeichnet (Stand 2026-07-20, [HW-03]):

• GGUF-Standard: llama.cpp definiert das GGUF-Format, das 2026 der portabelste Container für lokale LLMs ist. Q4_K_M, Q5_K_M, Q8_0 usw. laufen alle in GGUF (Details siehe Quantisierung lokaler Modelle).
• MIT-Lizenz: kommerziell nutzbar, OSI-konform, keine MAU-Caps o.ä.
• Hardware-Support: CPU (AVX2/AVX-512/NEON), CUDA (NVIDIA), Metal (Apple Silicon), Vulkan, SYCL, ROCm, OpenCL. Damit läuft GGUF praktisch überall — von alten Laptops über Macs und NVIDIA-GPUs bis zu AMD-Karten.
• Portabilität: Keine obligatorische Python-Runtime, einzelne kompilierte Binaries. GGUF-Dateien sind zwischen Plattformen austauschbar.

Typische Aufrufmuster: llama-server (lokaler HTTP-Server mit OpenAI-kompatibler API), llama-cli (Kommandozeilen-Chat), llama-bench (Messung). GUIs wie LM Studio und Tooling-Layer wie Ollama setzen 2026 ganz oder teilweise auf llama.cpp.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Vorher solltest du LLM-Grundlagen verstanden haben.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: Quantisierung lokaler Modelle, AI-Hardware für lokale Modelle.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei llama.cpp heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Ein Modell wird nach Hype ausgewählt, nicht nach Datenlage, Hardware, Lizenz, Latenz und Qualitätsmessung.
• Backend und Build werden verwechselt: Eine CPU-only-Binary auf einer GPU-Maschine läuft, ist aber langsam. Performance erfordert passend kompilierte Binaries (CUDA/Metal/Vulkan).
• Token/s ohne vollständigen Kontext (CPU/GPU, Quant, Kontext, Batch, Runtime, Quelle) sind wertlos — Herstellers-Benchmarks (LocalAI Master, Spheron, mustafa.net u.a.) sind Eigenmessungen und teils spekulativ.
• RAG wird als Wahrheitssystem missverstanden, obwohl Retrieval, Kontext und Modellantwort getrennt validiert werden müssen.
• Lokale Verarbeitung wird automatisch als datenschutzsicher betrachtet, obwohl Logs, Plugins, Downloads und Benutzerrechte weiter relevant sind.
• Benchmarks ersetzen keine eigenen Testfälle aus der echten Arbeit.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

Du startest ein lokales Modell per CLI und bindest es später über eine lokale API in ein Tool oder Script ein.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Welche Aufgabe soll das Modell wirklich lösen?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du startest ein lokales Modell per CLI und bindest es später über eine lokale API in ein Tool oder Script ein.
• Welche Daten dürfen lokal, intern oder extern verarbeitet werden?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du startest ein lokales Modell per CLI und bindest es später über eine lokale API in ein Tool oder Script ein.
• Woran misst du, ob die Antwort gut genug, schnell genug und verlässlich genug ist?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du startest ein lokales Modell per CLI und bindest es später über eine lokale API in ein Tool oder Script ein.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, Ollama nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird Ollama in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Was Ollama konkret bietet (Stand 2026-07-20, [HW-04]):

• Bibliothek / Library: Ein kuratierter Katalog fertiger Modelle (z.B. ollama pull qwen3, ollama run phi4), das Modelfile-Format für eigene Varianten.
• Model-Management: Pull, Run, List, Remove über eine einheitliche CLI — kein manuelles Herunterladen von GGUF-Dateien nötig.
• OpenAI-kompatible API: /v1/chat/completions out-of-the-box, damit Tools wie LangChain, OpenWebUI oder eigene Scripts direkt angeschlossen werden.
• Engine: Baut auf llama.cpp auf. Damit erbt Ollama GGUF-Support, CPU/CUDA/Metal/Vulkan und die Q4_K_M/Q5_K_M/Q8_0-Quants (siehe Quantisierung lokaler Modelle und llama.cpp).

Wichtige Grenze: Ollama ist auf einzelne Nutzer oder kleine Nebenläufigkeit ausgelegt. Praktische Erfahrungswerte und das Repo-Feedback zeigen, dass es ab etwa 5 gleichzeitigen Nutzern spürbar abbricht (Warteschlange, Latenzspitzen, kein echtes Batching) ([HW-04]). Für Mehrnutzer-Produktion ist vLLM mit PagedAttention die übliche Wahl (siehe Lokale AI Grundlagen).

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Vorher solltest du Lokale AI Grundlagen verstanden haben.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: Lokale AI Grundlagen, llama.cpp.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei Ollama heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Ein Modell wird nach Hype ausgewählt, nicht nach Datenlage, Hardware, Lizenz, Latenz und Qualitätsmessung.
• Ollama als Produktionsserver missverstanden — es bricht ab ~5 gleichzeitigen Nutzern ab ([HW-04]); für echte Nebenläufigkeit ist vLLM der richtige Pfad.
• Token/s ohne vollständigen Kontext (CPU/GPU, Quant, Kontext, Batch, Runtime, Quelle) sind wertlos; Herstellers-Benchmarks (LocalAI Master, Spheron, mustafa.net u.a.) sind Eigenmessungen und teils spekulativ.
• RAG wird als Wahrheitssystem missverstanden, obwohl Retrieval, Kontext und Modellantwort getrennt validiert werden müssen.
• Lokale Verarbeitung wird automatisch als datenschutzsicher betrachtet, obwohl Logs, Plugins, Downloads und Benutzerrechte weiter relevant sind (siehe Datenschutz bei lokaler AI).
• Benchmarks ersetzen keine eigenen Testfälle aus der echten Arbeit.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

Du testest verschiedene Modelle in einer Desktop-App, vergleichst Speicherbedarf, Antwortqualität und lokale Server-Funktion.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Welche Aufgabe soll das Modell wirklich lösen?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du testest verschiedene Modelle in einer Desktop-App, vergleichst Speicherbedarf, Antwortqualität und lokale Server-Funktion.
• Welche Daten dürfen lokal, intern oder extern verarbeitet werden?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du testest verschiedene Modelle in einer Desktop-App, vergleichst Speicherbedarf, Antwortqualität und lokale Server-Funktion.
• Woran misst du, ob die Antwort gut genug, schnell genug und verlässlich genug ist?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du testest verschiedene Modelle in einer Desktop-App, vergleichst Speicherbedarf, Antwortqualität und lokale Server-Funktion.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, LM Studio nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird LM Studio in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Kernfakten zu LM Studio (Stand 2026-07-20, [HW-05]):

• Desktop-GUI: Einfacher Modell-Browser mit Hugging-Face-Suche, Speicher- und VRAM-Schätzung vor dem Download und Chat-Oberfläche; typischer Einstieg für Leute ohne CLI-Präferenz.
• Proprietär, aber gratis: Kostenlos für persönliche Nutzung; binär-only. Lizenzdetails für kommerzielle/Team-Szenarien beim Anbieter prüfen.
• Engine: Setzt auf llama.cpp, d.h. es lädt GGUF-Quants (Q4_K_M, Q5_K_M, Q8_0, siehe Quantisierung lokaler Modelle). Auch MLX-Modelle auf Apple Silicon werden unterstützt.
• Lokaler Server: Eingebauter OpenAI-kompatibler Endpunkt — gleicher Pattern wie bei Ollama (siehe Ollama), aber ohne CLI-Bedienung.
• Grenze: Wie Ollama nicht für hohe Nebenläufigkeit gedacht (Einzelplatz oder kleine Gruppe, nicht Produktion unter Last).

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Vorher solltest du Lokale AI Grundlagen verstanden haben.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: Lokale AI Grundlagen, LLM-Grundlagen, Ollama.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei LM Studio heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Ein Modell wird nach Hype ausgewählt, nicht nach Datenlage, Hardware, Lizenz, Latenz und Qualitätsmessung.
• Proprietäre Gratis-Tools als Open Source missverstanden — LM Studio ist binär-only und nicht frei lizenziert ([HW-05]).
• LM Studio für Produktionsservices unter Last verwendet — dafür sind vLLM/TGI der Standard.
• Token/s ohne vollständigen Kontext (CPU/GPU, Quant, Kontext, Batch, Runtime, Quelle) sind wertlos; Herstellers-Benchmarks (LocalAI Master, Spheron, mustafa.net u.a.) sind Eigenmessungen und teils spekulativ.
• RAG wird als Wahrheitssystem missverstanden, obwohl Retrieval, Kontext und Modellantwort getrennt validiert werden müssen.
• Lokale Verarbeitung wird automatisch als datenschutzsicher betrachtet, obwohl Logs, Plugins, Downloads, Auto-Update-Checks und Benutzerrechte weiter relevant sind (siehe Datenschutz bei lokaler AI).
• Benchmarks ersetzen keine eigenen Testfälle aus der echten Arbeit.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

Du prüfst Colibrì immer gegen den konkreten Zweck: Willst du das Modell nur zum Laufen bringen, oder willst du damit interaktiv arbeiten?

Als Anfänger prüfst du drei Dinge:

• „Läuft mit 25 GB RAM" bedeutet nicht „interaktiv schnell". Auf der beworbenen Dev-Box (WSL2, 12 Cores, NVMe via VHDX ~1 GB/s) misst das Projekt selbst 0,05–0,1 Token/Sekunde („cold") ([COL-02/03], Hardware-Spezifikation im Repo). Rechnerisch entspricht das bei typischen Antworten von ~60-120 Token etwa 10-40 Minuten pro Antwort — das ist eine eigene Ableitung aus der Token-Rate, nicht eine Zahl aus dem Repo.
• Resident sein heißt: Das Modell ist im Speicher und startet. Interaktiv sein heißt: Es reagiert innerhalb von Sekunden, nicht Minuten.
• Das Repo selbst wurde am 2026-07-01 erstellt, die erste Release v1.0.0 am 2026-07-19 veröffentlicht. Die früher zitierte Formulierung „production since late June 2026" ist im Repo nicht belegt und wurde deshalb entfernt — korrekt ist: Repo 01.07.2026, v1.0.0 am 19.07.2026.

Miniübung: Lies die Projekt-Bewerbung und markiere alle Aussagen als entweder „Hersteller-Messung", „unabhängig bestätigt" oder „ungeprüft". Genau diese Trennung ist das eigentliche Lernziel.

3. Technisch einordnen

Auf Level 2 wird Colibrì in die Architektur und die Engpässe eingeordnet. Du erkennst, was resident ist, was von der Platte kommt und warum das I/O-limitierend ist.

Architektur ([COL-04], [COL-05]):

• Dense-Teil (~10 GB int4) ist dauerhaft resident im RAM. Das steuert jede Token-Erzeugung und hält Kontext.
• ~370 GB Experten liegen auf einer NVMe-SSD. Da MoE nur wenige Experten pro Token aktiviert, müssen nicht alle gleichzeitig im Speicher sein.
• ~11 GB Lesezugriff pro kaltem Token müssen von der NVMe kommen. Achtung — Engpass ist kontextabhängig: Bei kaltem Decode + kleinem RAM ist NVMe-I/O tatsächlich der Engpass; mit ausreichend RAM wechselt der Flaschenhals zur Matmul (CPU); beim Prefill (Prompt-Verarbeitung) ist er Attention-bound, nicht Disk-bound. Die pauschale Aussage „NVMe ist immer der Engpass" trifft also nicht zu ([COL-04], Repo benchmarks.md + Issue #153).
• GLM-5.2-spezifisch: MLA-Attention, DSA und nativer MTP sind hardcoded für dieses Modell ([COL-05]).

Engpässe getrennt betrachten:

1. NVMe-I/O: Lesebandbreite limitiert Tokens/Sekunde. Mehr RAM-Residenz senkt I/O, erhöht aber die RAM-Anforderung.
2. RAM-Größe: Begrenzt, wie viele Experten gleichzeitig resident sein können.
3. CPU-Matmul: Auf Geräten ohne GPU läuft die Matrizenmultiplikation auf der CPU und ist selbst dann langsam, wenn I/O schnell ist.

Wann Colibrì interessant ist:

• Rechner mit ≥128 GB RAM, weil dann ein größerer Teil der Experten resident wird und die I/O-Last sinkt.
• Multi-GPU-Setup, weil die Matmul dann beschleunigt wird und I/O der einzige Engpass bleibt.

Wann Colibrì ungeeignet ist:

• 25 GB-RAM-Chat-Szenario — läuft, aber mit ~20 Min/Antwort ([COL-03]).
• Produktion — der Status „production" ist nur ein Projektclaim ([COL-06]); unabhängige Reviews beschreiben es als „smart but slow" ([COL-07]).

Status des Projekts: ausgereifter Proof-of-Concept / Early-Alpha. Lizenz: Apache-2.0. Keine Runtime-Dependencies (pure C). Plattformen: Windows/Mac/Linux ([COL-01]).

Vorher solltest du LLM-Grundlagen und AI-Hardware für lokale Modelle verstanden haben.

4. Vertiefen

Auf Expertenniveau geht es um die saubere Trennung zwischen Herstellers-, unabhängiger und ungeprüfter Aussage sowie um Security.

Praxisfallen:

• „production since late June 2026" ([COL-06]) ist NUR Projektclaim. Keine unabhängige Bestätigung gefunden. Nicht als Reifegrad-Beleg verwenden.
• Residenz ≠ Interaktivität. Die unabhängig gemessenen 0,05–0,1 tok/s ([COL-03]) gelten auf der beworbenen Maschine und machen Chat unrealistisch.
• NVMe als Engpass wird in der Bewerbung unterbetont. ~11 GB/Token I/O ist die eigentliche Determinante der Geschwindigkeit, nicht das Modell selbst.
• Modell ist hardcoded für GLM-5.2 ([COL-05]) — generalisiert nicht ohne Weiteres auf andere MoE-Architekturen.

Security-Risiken:

• 370 GB Fremd-Weights müssen von einer vertrauenswürdigen Quelle geladen werden. Manipulierte Weights sind ein klassisches Supply-Chain-Risiko.
• Python-Konvertierung der Weights bedeutet, dass Code aus dem Modell-Umfeld in deinem Build-Prozess läuft — Reproduzierbarkeit und Integritätsprüfung der Konvertierungsschritte sind Pflicht.
• Apache-2.0 und „zero runtime deps" (pure C) reduzieren die Angriffsfläche der Runtime selbst, heben aber das Weights-Risiko nicht auf.

Goldstandard: Du kannst einem Laien erklären, warum ein 744B-Modell zwar mit 25 GB RAM startet, aber nicht chat-tauglich ist; du trennst Hersteller-Messung ([COL-02]) von unabhängiger Messung ([COL-03]); du kennst die NVMe-I/O-Falle; und du weißt, dass der „production"-Status ein Projektclaim bleibt ([COL-06]).

Verwandte Begriffe für die Vertiefung: Modelle benchmarken, AI-Hardware für lokale Modelle.

2. Anwenden

Du prüfst Datenschutz bei lokaler AI immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Welche Aufgabe soll das Modell wirklich lösen?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst Datenschutz bei lokaler AI immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.
• Welche Daten dürfen lokal, intern oder extern verarbeitet werden?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst Datenschutz bei lokaler AI immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.
• Woran misst du, ob die Antwort gut genug, schnell genug und verlässlich genug ist?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst Datenschutz bei lokaler AI immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, Datenschutz bei lokaler AI nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird Datenschutz bei lokaler AI in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Vorher solltest du Lokale AI Grundlagen verstanden haben.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: Lokale AI Grundlagen, Lokales RAG.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei Datenschutz bei lokaler AI heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Ein Modell wird nach Hype ausgewählt, nicht nach Datenlage, Hardware, Lizenz, Latenz und Qualitätsmessung.
• RAG wird als Wahrheitssystem missverstanden, obwohl Retrieval, Kontext und Modellantwort getrennt validiert werden müssen.
• Lokale Verarbeitung wird automatisch als datenschutzsicher betrachtet, obwohl Logs, Plugins, Downloads und Benutzerrechte weiter relevant sind.
• Benchmarks ersetzen keine eigenen Testfälle aus der echten Arbeit.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

Ein Modell soll auf eigene Dokumente antworten. RAG sucht passende Textstellen und gibt sie dem Modell als Kontext mit.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Welche Aufgabe soll das Modell wirklich lösen?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Ein Modell soll auf eigene Dokumente antworten. RAG sucht passende Textstellen und gibt sie dem Modell als Kontext mit.
• Welche Daten dürfen lokal, intern oder extern verarbeitet werden?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Ein Modell soll auf eigene Dokumente antworten. RAG sucht passende Textstellen und gibt sie dem Modell als Kontext mit.
• Woran misst du, ob die Antwort gut genug, schnell genug und verlässlich genug ist?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Ein Modell soll auf eigene Dokumente antworten. RAG sucht passende Textstellen und gibt sie dem Modell als Kontext mit.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, Lokales RAG nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird Lokales RAG in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Vorher solltest du LLM-Grundlagen verstanden haben.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: Embedding, Vektor-Datenbank, LLM-Grundlagen.

Als Lernroute führt lokales RAG von RAG (Retrieval Augmented Generation) über Information Retrieval (IR) zu konkreten Retrieval-Modellen wie Vector Space Model. Wenn später Bilder, Audio oder Video durchsucht werden, wird daraus Multimedia Retrieval.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei Lokales RAG heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Ein Modell wird nach Hype ausgewählt, nicht nach Datenlage, Hardware, Lizenz, Latenz und Qualitätsmessung.
• RAG wird als Wahrheitssystem missverstanden, obwohl Retrieval, Kontext und Modellantwort getrennt validiert werden müssen.
• Lokale Verarbeitung wird automatisch als datenschutzsicher betrachtet, obwohl Logs, Plugins, Downloads und Benutzerrechte weiter relevant sind.
• Benchmarks ersetzen keine eigenen Testfälle aus der echten Arbeit.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

Du prüfst AI-Agent-Grundlagen immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Welche Aufgabe soll das Modell wirklich lösen?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst AI-Agent-Grundlagen immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.
• Welche Daten dürfen lokal, intern oder extern verarbeitet werden?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst AI-Agent-Grundlagen immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.
• Woran misst du, ob die Antwort gut genug, schnell genug und verlässlich genug ist?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst AI-Agent-Grundlagen immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, AI-Agent-Grundlagen nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird AI-Agent-Grundlagen in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Vorher solltest du Prompt Engineering verstanden haben.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: Prompt Engineering, Lokales RAG.

Für echte Agentenarbeit kommen mehrere Unterbegriffe zusammen: Ein Agent Tool beschreibt die nutzbare Aktion, Agent Guardrails begrenzen riskante Ausgaben, Agent Evaluation (Evals) prüft Qualität und Agent Cost Optimization hält Laufzeit und Credits kontrollierbar. Vibe Coding ist ein verwandter Arbeitsstil, aber kein Ersatz für Reviews, Tests und klare Aufgaben.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei AI-Agent-Grundlagen heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Ein Modell wird nach Hype ausgewählt, nicht nach Datenlage, Hardware, Lizenz, Latenz und Qualitätsmessung.
• RAG wird als Wahrheitssystem missverstanden, obwohl Retrieval, Kontext und Modellantwort getrennt validiert werden müssen.
• Lokale Verarbeitung wird automatisch als datenschutzsicher betrachtet, obwohl Logs, Plugins, Downloads und Benutzerrechte weiter relevant sind.
• Benchmarks ersetzen keine eigenen Testfälle aus der echten Arbeit.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

Du prüfst Caveman immer gegen drei klar getrennte Ebenen:

• Skill (Prompt): „antworte wie ein Höhlenmensch". Reduziert NUR Output-Token, NICHT Reasoning oder Input-Token. Das sagt das Repo selbst explizit ([CAV-02], [CAV-03]).
• Code-Agent (Tooling): Caveman Code ist ein separater Coding-Agent. Herstellerclaim: 1,93× weniger verbrauchte Token als Codex CLI (524.703 vs. 1.010.185 tokens_fresh; NICHT „1,93× schneller" — die Wall-Clock-Zeit variiert task-abhängig) — keine unabhängige Bestätigung ([CAV-07]).
• Prinzip (Token-/Code-Minimalismus): Der übergeordnete Leitfaden zum sparsamen Umgang mit Tokens und Code.

Die häufigste Falle: Die Hersteller-Zahl „65% Output-Reduktion" ([CAV-04]) wird als harter Fakt gelesen. Sie ist ein Projektclaim, gemessen an nur 10 Prompts mit einer Spanne von 22–87%. Unabhängig reproduziert wurde eher ~31% statt 65–75% ([CAV-05], cipherfoxie, 5 Modelle).

Miniübung: Lies die Projekt-Bewerbung und ordne jede Zahl einer der drei Ebenen zu. Markiere jede Zahl als „Hersteller-Messung", „unabhängig reproduziert" oder „ungeprüft".

3. Technisch einordnen

Auf Level 2 geht es um die echten Fakten — strikt zwischen Hersteller-Claim und unabhängiger Bestätigung getrennt.

Echte Fakten zum Caveman-Skill

• Reduziert NUR Output-Token, nicht Reasoning, nicht Input ([CAV-02], [CAV-03]). Das Repo dokumentiert diesen Mechanismus in HONEST-NUMBERS.md selbst.
• Herstellerclaim: 65% Output-Reduktion ([CAV-04]). Gemessen an 10 Prompts, Spanne 22–87%. Nur Projektclaim.
• Unabhängig reproduziert: ~31% statt 65–75% ([CAV-05], cipherfoxie Discussion #520, 5 Modelle). Die einzige verfügbare unabhängige Mehr-Modell-Messung.
• Bei Coding-Anwendungen vernachlässigbar bis negativ. Coding ist cache-dominiert — Cache-Reads machen ~97% der Token aus. Dort hat Caveman keinen positiven Effekt auf die Rechnung. Das Repo räumt das in HONEST-NUMBERS.md selbst ein ([CAV-06], romainfjgaspard + Issue #550).
• arXiv 2604.00025 „Brevity Constraints Reverse Performance Hierarchies" ([CAV-08], Hakim, eingereicht 2026-03-11, Preprint): Brevity-Constraints verbessern Accuracy um 26 Prozentpunkte über 31 Modelle (0,5B–405B) und 1.485 Probleme. Hinweis: Preprint, noch kein Peer-Review.

Fakten zu Caveman Code (Code-Agent)

• Herstellerclaim: 1,93× vs. Codex CLI ([CAV-07]). 25 Tasks, Modell gpt-5.5, Schwierigkeit xhigh.
• Genau hingeschaut: 14/25 vs. 15/25 resolved — das ist NICHT „gleiche Genauigkeit". Es ist ein leichter Genauigkeitsverlust zugunsten von Geschwindigkeit.
• Keine unabhängige Bestätigung gefunden.

Token-Minimalismus-Leitfaden (10 Ebenen)

1. Auftrag: Klare, kompakte Aufgabenstellung statt offener Essays.
2. Kontext: Nur relevante Quellen, unnötige Historie entfernen.
3. Suche: Gezielt statt breit, Treffer begrenzen.
4. Antwort: Längenbegrenzung, kompakte Antwortformate.
5. Code-Diffs: Nur geänderte Zeilen, kein vollständiger Re-Output.
6. Tools filtern: Nicht jedes Tool pro Schritt aufrufen.
7. Memory: Wiederverwenden statt neu erzeugen.
8. Caching: Cache-Reads nutzen, identische Abfragen vermeiden.
9. Model Routing: Kleine Aufgabe → kleines Modell.
10. Stop-Bedingung: Früh abbrechen, wenn Ziel erreicht.

Code-Minimalismus-Regeln

• Kleinster korrekter Patch: Nur ändern, was geändert werden muss.
• Keine unnötige Abstraktion/Dependency: Nicht jede Wiederholung rechtfertigt eine Klasse oder Lib.
• Keine zweite Source of Truth: Ein Datenpunkt lebt an einem Ort.
• Kommentare erklären das Warum, nicht das Was.
• Tests nach Risiko: Kritische Pfade zuerst, nicht „überall 100%".

Vorher solltest du LLM-Grundlagen und Prompt Engineering verstanden haben.

4. Vertiefen

Auf Expertenniveau geht es um die Nachteile, die modellabhängige Wirkung und die Security.

Nachteile und Praxisfallen:

• Verlorene Nuance: Kompakter Output verliert oft Feinheiten, Einschränkungen und Warnungen.
• Übersehene Warnungen: Gerade in sicherheitskritischen Antworten ist „kurz" gefährlich, wenn Warnhinweise entfallen.
• Schlechtere Wartbarkeit: Komprimierter Code kann schwerer lesbar sein, weil Lokalität und Kommentare zurückgehen.
• Modellabhängig: Fable 5 produzierte in einer Messung 18% längere Outputs statt kürzere. Der Effekt ist kein Naturgesetz, sondern hängt vom Modell ab.
• Herstellerclaims kritisch lesen: 65% ([CAV-04]), 1,93× ([CAV-07]) und „production since late June 2026" sind Projektclaims — nicht mit unabhängig gemessenen Fakten ([CAV-05], [CAV-06]) gleichsetzen.
• Coding-Anwendungen: Weil Cache-Reads ~97% der Token ausmachen, ist der Effekt von Output-Reduktion auf die Rechnung bei Coding-Anwendungen „vernachlässigbar bis negativ" ([CAV-06]).

Security:

• Keine Telemetrie, nur lokale Dateien ([CAV-09], SECURITY.md). Datentechnisch unauffällig.
• Pipe-to-shell-Installationsrisiko: Ein curl … | bash oder vergleichbarer Installationspfad bleibt ein klassisches Supply-Chain-Risiko, auch wenn die Runtime selbst unauffällig ist.

Goldstandard: Du kannst einem Laien erklären, warum ein Prompt-Skill nicht mit einem Code-Agent zu verwechseln ist; du trennst Hersteller-Messung ([CAV-04], [CAV-07]) von unabhängiger Reproduktion ([CAV-05], [CAV-06]); du kennst den arXiv-Beleg-Stolperstein ([CAV-08]); und du erkennst, dass Token-Minimalismus nicht bei jedem Lastprofil spart.

Verwandte Begriffe für die Vertiefung: Modelle benchmarken, AI-Hardware für lokale Modelle, LLM-Grundlagen.

2. Anwenden

In einem kleinen Prototyp zeigt Game-Development-Pipeline, ob eine Idee wirklich spielbar, testbar und weiter ausbaubar ist.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Was ist der kleinste testbare Prototyp?

  Der kleinste testbare Prototyp ist die simpelste Version, mit der du eine Annahme prüfen kannst. Du baust nur so viel, dass sichtbar wird, ob der Kern funktioniert, bevor du Zeit in Details steckst.
• Welche Eingabe verändert welchen Zustand?

  Gemeint ist: Welche konkrete Nutzeraktion, Datei, Anfrage oder Messung verändert welchen Zustand im System? Benenne Eingabe, Verarbeitung, Ergebnis und sichtbares Feedback getrennt.
• Wie merkt der Spieler oder Nutzer, dass etwas funktioniert?

  Der Nutzer erkennt Funktion daran, dass eine erwartete Rückmeldung erscheint: Bild, Ton, Status, gespeicherte Änderung, Fehlermeldung, Messwert oder reproduzierbares Verhalten.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, Game-Development-Pipeline nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird Game-Development-Pipeline in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Dieser Begriff ist ein Einstiegspunkt und setzt nur Grundverständnis sowie sauberes Lesen voraus.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: Gameplay-Programmierung.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei Game-Development-Pipeline heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Zu frueh wird an Assets gearbeitet, bevor der spielbare Kern bewiesen ist.
• Frameabhaengige Logik erzeugt unterschiedliche Spielgeschwindigkeit auf verschiedenen Rechnern.
• Engine-Funktionen werden benutzt, ohne Build, Plattform, Lizenz und Teamwissen mitzudenken.
• AI-generierte Inhalte werden ohne Stilkontrolle, Lizenzprüfung und technische Nachbearbeitung übernommen.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

In einem kleinen Prototyp zeigt Game Prototyping, ob eine Idee wirklich spielbar, testbar und weiter ausbaubar ist.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Was ist der kleinste testbare Prototyp?

  Der kleinste testbare Prototyp ist die simpelste Version, mit der du eine Annahme prüfen kannst. Du baust nur so viel, dass sichtbar wird, ob der Kern funktioniert, bevor du Zeit in Details steckst.
• Welche Eingabe verändert welchen Zustand?

  Gemeint ist: Welche konkrete Nutzeraktion, Datei, Anfrage oder Messung verändert welchen Zustand im System? Benenne Eingabe, Verarbeitung, Ergebnis und sichtbares Feedback getrennt.
• Wie merkt der Spieler oder Nutzer, dass etwas funktioniert?

  Der Nutzer erkennt Funktion daran, dass eine erwartete Rückmeldung erscheint: Bild, Ton, Status, gespeicherte Änderung, Fehlermeldung, Messwert oder reproduzierbares Verhalten.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, Game Prototyping nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird Game Prototyping in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Vorher solltest du Game-Development-Pipeline verstanden haben.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: Game Loop, Gameplay-Programmierung.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei Game Prototyping heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Zu frueh wird an Assets gearbeitet, bevor der spielbare Kern bewiesen ist.
• Frameabhaengige Logik erzeugt unterschiedliche Spielgeschwindigkeit auf verschiedenen Rechnern.
• Engine-Funktionen werden benutzt, ohne Build, Plattform, Lizenz und Teamwissen mitzudenken.
• AI-generierte Inhalte werden ohne Stilkontrolle, Lizenzprüfung und technische Nachbearbeitung übernommen.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

In einem kleinen Prototyp zeigt Engine-Auswahl, ob eine Idee wirklich spielbar, testbar und weiter ausbaubar ist.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Was ist der kleinste testbare Prototyp?

  Der kleinste testbare Prototyp ist die simpelste Version, mit der du eine Annahme prüfen kannst. Du baust nur so viel, dass sichtbar wird, ob der Kern funktioniert, bevor du Zeit in Details steckst.
• Welche Eingabe verändert welchen Zustand?

  Gemeint ist: Welche konkrete Nutzeraktion, Datei, Anfrage oder Messung verändert welchen Zustand im System? Benenne Eingabe, Verarbeitung, Ergebnis und sichtbares Feedback getrennt.
• Wie merkt der Spieler oder Nutzer, dass etwas funktioniert?

  Der Nutzer erkennt Funktion daran, dass eine erwartete Rückmeldung erscheint: Bild, Ton, Status, gespeicherte Änderung, Fehlermeldung, Messwert oder reproduzierbares Verhalten.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, Engine-Auswahl nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird Engine-Auswahl in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Vorher solltest du Game-Development-Pipeline verstanden haben.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: Godot Engine, Game-Development-Pipeline.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei Engine-Auswahl heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Zu frueh wird an Assets gearbeitet, bevor der spielbare Kern bewiesen ist.
• Frameabhaengige Logik erzeugt unterschiedliche Spielgeschwindigkeit auf verschiedenen Rechnern.
• Engine-Funktionen werden benutzt, ohne Build, Plattform, Lizenz und Teamwissen mitzudenken.
• AI-generierte Inhalte werden ohne Stilkontrolle, Lizenzprüfung und technische Nachbearbeitung übernommen.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

Du baust einen 2D-Prototyp, strukturierst ihn in Szenen und Nodes und verbindest Verhalten mit Scripts.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Was ist der kleinste testbare Prototyp?

  Der kleinste testbare Prototyp ist die simpelste Version, mit der du eine Annahme prüfen kannst. Du baust nur so viel, dass sichtbar wird, ob der Kern funktioniert, bevor du Zeit in Details steckst.
• Welche Eingabe verändert welchen Zustand?

  Gemeint ist: Welche konkrete Nutzeraktion, Datei, Anfrage oder Messung verändert welchen Zustand im System? Benenne Eingabe, Verarbeitung, Ergebnis und sichtbares Feedback getrennt.
• Wie merkt der Spieler oder Nutzer, dass etwas funktioniert?

  Der Nutzer erkennt Funktion daran, dass eine erwartete Rückmeldung erscheint: Bild, Ton, Status, gespeicherte Änderung, Fehlermeldung, Messwert oder reproduzierbares Verhalten.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, Godot Engine nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird Godot Engine in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Vorher solltest du Game-Development-Pipeline verstanden haben.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: Game-Development-Pipeline, Game Loop.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei Godot Engine heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Zu frueh wird an Assets gearbeitet, bevor der spielbare Kern bewiesen ist.
• Frameabhaengige Logik erzeugt unterschiedliche Spielgeschwindigkeit auf verschiedenen Rechnern.
• Engine-Funktionen werden benutzt, ohne Build, Plattform, Lizenz und Teamwissen mitzudenken.
• AI-generierte Inhalte werden ohne Stilkontrolle, Lizenzprüfung und technische Nachbearbeitung übernommen.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

In einem kleinen Prototyp zeigt Gameplay-Programmierung, ob eine Idee wirklich spielbar, testbar und weiter ausbaubar ist.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Was ist der kleinste testbare Prototyp?

  Der kleinste testbare Prototyp ist die simpelste Version, mit der du eine Annahme prüfen kannst. Du baust nur so viel, dass sichtbar wird, ob der Kern funktioniert, bevor du Zeit in Details steckst.
• Welche Eingabe verändert welchen Zustand?

  Gemeint ist: Welche konkrete Nutzeraktion, Datei, Anfrage oder Messung verändert welchen Zustand im System? Benenne Eingabe, Verarbeitung, Ergebnis und sichtbares Feedback getrennt.
• Wie merkt der Spieler oder Nutzer, dass etwas funktioniert?

  Der Nutzer erkennt Funktion daran, dass eine erwartete Rückmeldung erscheint: Bild, Ton, Status, gespeicherte Änderung, Fehlermeldung, Messwert oder reproduzierbares Verhalten.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, Gameplay-Programmierung nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird Gameplay-Programmierung in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Dieser Begriff ist ein Einstiegspunkt und setzt nur Grundverständnis sowie sauberes Lesen voraus.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: Game Loop, Delta Time.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei Gameplay-Programmierung heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Zu frueh wird an Assets gearbeitet, bevor der spielbare Kern bewiesen ist.
• Frameabhaengige Logik erzeugt unterschiedliche Spielgeschwindigkeit auf verschiedenen Rechnern.
• Engine-Funktionen werden benutzt, ohne Build, Plattform, Lizenz und Teamwissen mitzudenken.
• AI-generierte Inhalte werden ohne Stilkontrolle, Lizenzprüfung und technische Nachbearbeitung übernommen.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

Ein Spiel liest Eingaben, aktualisiert die Welt und zeichnet ein neues Bild. Dieser Ablauf passiert viele Male pro Sekunde.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Was ist der kleinste testbare Prototyp?

  Der kleinste testbare Prototyp ist die simpelste Version, mit der du eine Annahme prüfen kannst. Du baust nur so viel, dass sichtbar wird, ob der Kern funktioniert, bevor du Zeit in Details steckst.
• Welche Eingabe verändert welchen Zustand?

  Gemeint ist: Welche konkrete Nutzeraktion, Datei, Anfrage oder Messung verändert welchen Zustand im System? Benenne Eingabe, Verarbeitung, Ergebnis und sichtbares Feedback getrennt.
• Wie merkt der Spieler oder Nutzer, dass etwas funktioniert?

  Der Nutzer erkennt Funktion daran, dass eine erwartete Rückmeldung erscheint: Bild, Ton, Status, gespeicherte Änderung, Fehlermeldung, Messwert oder reproduzierbares Verhalten.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, Game Loop nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird Game Loop in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Dieser Begriff ist ein Einstiegspunkt und setzt nur Grundverständnis sowie sauberes Lesen voraus.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: Delta Time.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei Game Loop heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Zu frueh wird an Assets gearbeitet, bevor der spielbare Kern bewiesen ist.
• Frameabhaengige Logik erzeugt unterschiedliche Spielgeschwindigkeit auf verschiedenen Rechnern.
• Engine-Funktionen werden benutzt, ohne Build, Plattform, Lizenz und Teamwissen mitzudenken.
• AI-generierte Inhalte werden ohne Stilkontrolle, Lizenzprüfung und technische Nachbearbeitung übernommen.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

Eine Figur soll auf schnellen und langsamen Rechnern gleich weit laufen. Delta Time skaliert Bewegung mit vergangener Zeit.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Was ist der kleinste testbare Prototyp?

  Der kleinste testbare Prototyp ist die simpelste Version, mit der du eine Annahme prüfen kannst. Du baust nur so viel, dass sichtbar wird, ob der Kern funktioniert, bevor du Zeit in Details steckst.
• Welche Eingabe verändert welchen Zustand?

  Gemeint ist: Welche konkrete Nutzeraktion, Datei, Anfrage oder Messung verändert welchen Zustand im System? Benenne Eingabe, Verarbeitung, Ergebnis und sichtbares Feedback getrennt.
• Wie merkt der Spieler oder Nutzer, dass etwas funktioniert?

  Der Nutzer erkennt Funktion daran, dass eine erwartete Rückmeldung erscheint: Bild, Ton, Status, gespeicherte Änderung, Fehlermeldung, Messwert oder reproduzierbares Verhalten.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, Delta Time nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird Delta Time in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Vorher solltest du Game Loop verstanden haben.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: Game Loop.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei Delta Time heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Zu frueh wird an Assets gearbeitet, bevor der spielbare Kern bewiesen ist.
• Frameabhaengige Logik erzeugt unterschiedliche Spielgeschwindigkeit auf verschiedenen Rechnern.
• Engine-Funktionen werden benutzt, ohne Build, Plattform, Lizenz und Teamwissen mitzudenken.
• AI-generierte Inhalte werden ohne Stilkontrolle, Lizenzprüfung und technische Nachbearbeitung übernommen.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

In einem kleinen Prototyp zeigt Asset Pipeline, ob eine Idee wirklich spielbar, testbar und weiter ausbaubar ist.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Was ist der kleinste testbare Prototyp?

  Der kleinste testbare Prototyp ist die simpelste Version, mit der du eine Annahme prüfen kannst. Du baust nur so viel, dass sichtbar wird, ob der Kern funktioniert, bevor du Zeit in Details steckst.
• Welche Eingabe verändert welchen Zustand?

  Gemeint ist: Welche konkrete Nutzeraktion, Datei, Anfrage oder Messung verändert welchen Zustand im System? Benenne Eingabe, Verarbeitung, Ergebnis und sichtbares Feedback getrennt.
• Wie merkt der Spieler oder Nutzer, dass etwas funktioniert?

  Der Nutzer erkennt Funktion daran, dass eine erwartete Rückmeldung erscheint: Bild, Ton, Status, gespeicherte Änderung, Fehlermeldung, Messwert oder reproduzierbares Verhalten.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, Asset Pipeline nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird Asset Pipeline in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Vorher solltest du Game-Development-Pipeline verstanden haben.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: AI-generierte Game Assets, Game-Development-Pipeline.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei Asset Pipeline heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Zu frueh wird an Assets gearbeitet, bevor der spielbare Kern bewiesen ist.
• Frameabhaengige Logik erzeugt unterschiedliche Spielgeschwindigkeit auf verschiedenen Rechnern.
• Engine-Funktionen werden benutzt, ohne Build, Plattform, Lizenz und Teamwissen mitzudenken.
• AI-generierte Inhalte werden ohne Stilkontrolle, Lizenzprüfung und technische Nachbearbeitung übernommen.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

2. Anwenden

Du prüfst AI-generierte Game Assets immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

• Welche Aufgabe soll das Modell wirklich lösen?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst AI-generierte Game Assets immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.
• Welche Daten dürfen lokal, intern oder extern verarbeitet werden?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst AI-generierte Game Assets immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.
• Woran misst du, ob die Antwort gut genug, schnell genug und verlässlich genug ist?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du prüfst AI-generierte Game Assets immer gegen einen konkreten Zweck: Datenschutz, Kosten, Geschwindigkeit, Qualität und Automatisierbarkeit.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, AI-generierte Game Assets nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

3. Technisch einordnen

Auf Level 2 wird AI-generierte Game Assets in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Arbeite mit diesem Schema:

1. Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?

   Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
2. Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?

   Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
3. Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?

   Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
4. Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?

   Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Vorher solltest du Game-Development-Pipeline verstanden haben.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Dieser Begriff dient als Einstieg und wird in späteren Batches weiter mit verwandten Begriffen verknüpft.

4. Vertiefen

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei AI-generierte Game Assets heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

• Ein Modell wird nach Hype ausgewählt, nicht nach Datenlage, Hardware, Lizenz, Latenz und Qualitätsmessung.
• RAG wird als Wahrheitssystem missverstanden, obwohl Retrieval, Kontext und Modellantwort getrennt validiert werden müssen.
• Lokale Verarbeitung wird automatisch als datenschutzsicher betrachtet, obwohl Logs, Plugins, Downloads und Benutzerrechte weiter relevant sind.
• Benchmarks ersetzen keine eigenen Testfälle aus der echten Arbeit.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.