Vom Versuch zum verlässlichen Dienst
Sie müssen nicht alles selbst bauen.
Ein Dirigent spielt nicht jedes Instrument. Er weiß aber, wann welches Instrument gebraucht wird. Genauso arbeiten Sie hier: Sie verstehen die Aufgabe, wählen das richtige Werkzeug und prüfen das Ergebnis. Code ist nur ein Anschauungsbeispiel. Sie müssen ihn nicht auswendig lernen.
Ein Service trennt UI, Orchestration, Model Access, Retrieval, Policy und Telemetry durch explizite Contracts. Das erlaubt unabhängige Tests und begrenzte Fehlerausbreitung.
- service architecture
- Englischer Fachbegriff für das in diesem Abschnitt erklärte technische Konzept.
- orchestration
- Englischer Fachbegriff für das in diesem Abschnitt erklärte technische Konzept.
- failure boundary
- Englischer Fachbegriff für das in diesem Abschnitt erklärte technische Konzept.
Ein Notebook-Demo beweist eine Idee; ein Service muss Wiederholung, Parallelität, Teilausfälle und Versionswechsel überstehen. Operational Behaviour gehört zur Produktfunktion.
Zuerst verstehen. Dann entscheiden. Erst danach bauen.
Das Problem aus dem Alltag: Ein Versuch funktioniert auf einem Laptop. Nun sollen hundert Menschen ihn benutzen. Dafür braucht es einen geordneten Dienst.
Die einfache Regel: Erst muss klar sein, was richtig sein soll. Danach wird geprüft, ob es wirklich richtig ist.
Sie müssen dafür nicht alles selbst programmieren. Sie müssen entscheiden, welche Aufgabe das normale Programm, die KI oder ein Mensch übernimmt.
Merksatz: Vertrauen ist gut. Ein sichtbarer Test ist besser.
Ein Versuch funktioniert auf einem Laptop. Nun sollen hundert Menschen ihn benutzen. Dafür braucht es einen geordneten Dienst.
- 01
Wir schreiben in einem Satz auf, was am Ende richtig sein muss.
- 02
Wir bestimmen, wer diese Aufgabe übernimmt: das normale Programm, die KI oder ein Mensch.
- 03
Wir probieren zuerst einen gewöhnlichen Fall.
- 04
Danach probieren wir einen schwierigen oder fehlerhaften Fall.
- 05
Wir halten das Ergebnis fest. So können wir denselben Fehler später wieder prüfen.
Am Ende sehen wir klar: Was funktioniert? Was funktioniert noch nicht? Und wann muss ein Mensch übernehmen?
Erklären Sie die Kernidee mit Ihren eigenen Worten.
Nicht abschreiben. Ein oder zwei einfache Sätze genügen.
Noch mindestens 12 eigene Wörter in einem verständlichen SatzLösen Sie den konkreten Arbeitsauftrag „Vom Versuch zum verlässlichen Dienst“. Zeigen Sie dabei in einem kleinen Beispiel, wie Sie die Regel „Ein Service trennt UI, Orchestration, Model Access, Retrieval, Policy und Telemetry durch explizite Contracts. Das erlaubt unabhängige Tests und begrenzte Fehlerausbreitung.“ anwenden. Prüfen Sie außerdem den häufigen Fehler: Ein Notebook-Demo beweist eine Idee; ein Service muss Wiederholung, Parallelität, Teilausfälle und Versionswechsel überstehen. Operational Behaviour gehört zur Produktfunktion.
async def handle(request, env, trace):
# TODO: validate, budget, call, observe, redact
return {"status": 501, "body": "not implemented"}- Ein gewöhnlicher Fall wurde ausprobiert.
- Ein schwieriger oder fehlerhafter Fall wurde ausprobiert.
- Ein Fehler wird klar angezeigt.
- Sie können in eigenen Worten sagen, was das Programm, die KI und der Mensch tun.
Hilfe 1 anzeigen
Hinweis 1: Denken Sie an diesen Fall: Ein Versuch funktioniert auf einem Laptop. Nun sollen hundert Menschen ihn benutzen. Dafür braucht es einen geordneten Dienst. Schreiben Sie nur auf, was am Ende sichtbar richtig sein muss.
Hilfe 2 anzeigen
Hinweis 2: Für „Vom Versuch zum verlässlichen Dienst“ brauchen Sie einen normalen Fall und einen Fehlerfall. Ihr Nachweis lautet: Arbeitsprobe 6.1: ein sichtbares Ergebnis zu „Vom Versuch zum verlässlichen Dienst“, ein passender Normaltest, ein Fehlerfall und zwei einfache Sätze zu Ihrer Entscheidung.
Hilfe 3 anzeigen
Hinweis 3: Vermeiden Sie diesen Denkfehler: Ein Notebook-Demo beweist eine Idee; ein Service muss Wiederholung, Parallelität, Teilausfälle und Versionswechsel überstehen. Operational Behaviour gehört zur Produktfunktion. Bauen Sie zuerst den kleinsten Weg und prüfen Sie danach genau diese Annahme.
Erst verstehen, dann ändern.
Ein Versuch funktioniert auf einem Laptop. Nun sollen hundert Menschen ihn benutzen. Dafür braucht es einen geordneten Dienst.
Reparieren Sie nicht sofort. Notieren Sie für „Vom Versuch zum verlässlichen Dienst“: Was sehen Sie? Wo könnte der Fehler liegen? Welcher kleine Test trennt zwei mögliche Ursachen? Was müsste dabei herauskommen?
Diagnose und Reparaturprinzip anzeigen
Eine gute Lösung prüft die Annahme „Ein Notebook-Demo beweist eine Idee; ein Service muss Wiederholung, Parallelität, Teilausfälle und Versionswechsel überstehen. Operational Behaviour gehört zur Produktfunktion.“. Sie macht den Fehler sichtbar, begrenzt den Schaden und bewahrt den Fall als Wiederholungstest auf.
Lösen Sie den konkreten Arbeitsauftrag „Vom Versuch zum verlässlichen Dienst“. Zeigen Sie dabei in einem kleinen Beispiel, wie Sie die Regel „Ein Service trennt UI, Orchestration, Model Access, Retrieval, Policy und Telemetry durch explizite Contracts. Das erlaubt unabhängige Tests und begrenzte Fehlerausbreitung.“ anwenden. Prüfen Sie außerdem den häufigen Fehler: Ein Notebook-Demo beweist eine Idee; ein Service muss Wiederholung, Parallelität, Teilausfälle und Versionswechsel überstehen. Operational Behaviour gehört zur Produktfunktion.
Arbeitsprobe 6.1: ein sichtbares Ergebnis zu „Vom Versuch zum verlässlichen Dienst“, ein passender Normaltest, ein Fehlerfall und zwei einfache Sätze zu Ihrer Entscheidung.
Aufbau der Musterlösung anzeigen
- 1
Ziel: Ein Service trennt UI, Orchestration, Model Access, Retrieval, Policy und Telemetry durch explizite Contracts. Das erlaubt unabhängige Tests und begrenzte Fehlerausbreitung.
- 2
Praxisfall: Ein Versuch funktioniert auf einem Laptop. Nun sollen hundert Menschen ihn benutzen. Dafür braucht es einen geordneten Dienst.
- 3
Vorgehen: Lösen Sie den konkreten Arbeitsauftrag „Vom Versuch zum verlässlichen Dienst“. Zeigen Sie dabei in einem kleinen Beispiel, wie Sie die Regel „Ein Service trennt UI, Orchestration, Model Access, Retrieval, Policy und Telemetry durch explizite Contracts. Das erlaubt unabhängige Tests und begrenzte Fehlerausbreitung.“ anwenden. Prüfen Sie außerdem den häufigen Fehler: Ein Notebook-Demo beweist eine Idee; ein Service muss Wiederholung, Parallelität, Teilausfälle und Versionswechsel überstehen. Operational Behaviour gehört zur Produktfunktion.
- 4
Prüfung: Testen Sie den normalen Fall und zusätzlich den beschriebenen Fehlerfall.
- 5
Nachweis: Arbeitsprobe 6.1: ein sichtbares Ergebnis zu „Vom Versuch zum verlässlichen Dienst“, ein passender Normaltest, ein Fehlerfall und zwei einfache Sätze zu Ihrer Entscheidung. Nennen Sie außerdem offen, was noch unsicher ist.
Die Musterlösung ist ein Vergleich. Ihre Lösung darf anders aussehen, wenn sie dieselbe Aufgabe nachvollziehbar erfüllt.
Lösen Sie ohne Vorlage folgende Situation: Ein Versuch funktioniert auf einem Laptop. Nun sollen hundert Menschen ihn benutzen. Dafür braucht es einen geordneten Dienst. Ihre Antwort muss die Grundidee anwenden, mindestens einen konkreten Test enthalten und ein sicheres Verhalten im Fehlerfall nennen.
Noch mindestens 35 unterschiedliche Wörter in drei verständlichen Sätzen; alle fünf Prüfpunkte markieren · Automatische Plausibilitätsprüfung, keine fachliche Bewertung.Was haben Sie entschieden – und warum?
Schreiben Sie: „Ich habe … gewählt, weil … Geprüft habe ich es mit … Unsicher ist noch …“
Noch mindestens 20 eigene Wörter in zwei verständlichen SätzenW6.1 · Vom Versuch zum verlässlichen Dienst
Sammeln Sie diese Dinge. So kann eine andere Person Ihre Arbeit später verstehen:
- Arbeitsprobe 6.1: ein sichtbares Ergebnis zu „Vom Versuch zum verlässlichen Dienst“, ein passender Normaltest, ein Fehlerfall und zwei einfache Sätze zu Ihrer Entscheidung.
- Eine Seite mit Ihrer Entscheidung
- Ergebnis des gewöhnlichen Falls
- Ergebnis des schwierigen Falls
- Was noch unsicher ist und was Sie als Nächstes prüfen würden