Qualität und Abnahme

Qualität und Abnahme

0:00 Willkommen zu Modul zwölf. Lotsenhaus ist installiert, angebunden, erweitert und abgesichert. Jetzt kommt die Frage, an der viele Pilotprojekte scheitern, ohne es zu merken: Woran erkennen wir eigentlich, dass die Plattform gut genug ist? Bei klassischer Software gibt es dafür eingeübte Verfahren. Bei einem Sprachmodell, das auf dieselbe Frage nicht immer dasselbe antwortet, wird es schwieriger.

0:23 In diesem Modul bauen wir eine Teststrategie über alle Ebenen, prüfen gezielt, was nicht gehen darf, belasten die Plattform und simulieren Ausfälle. Am Ende steht eine Abnahme mit vorher festgelegten Regeln, und Sie treffen in der Übung selbst eine begründete Entscheidung über den Pilot.

Qualität und Abnahme

0:40 Der Satz auf dieser Folie richtet sich gegen eine sehr menschliche Versuchung. Eine gelungene Vorführung erzeugt Begeisterung, und Begeisterung fühlt sich an wie Gewissheit. Aber eine Demo zeigt, was funktionieren kann, nicht, was zuverlässig funktioniert. Freigegeben ist ein Pilot erst, wenn die vereinbarten Prüfungen bestanden sind.

1:00 Genau diese Prüfungen bauen wir in der zweiten Hälfte des fünften Tages auf.

Teststrategie

1:05 Wer eine KI-Plattform testet, testet in Wahrheit mehrere Dinge auf einmal. Die Teststrategie beginnt deshalb damit, diese Dinge sauber auseinanderzuhalten. Die vier Schichten zeigen, wo ein Fehler entstehen kann, und jede hat ihre eigene Art von Fehler. Ganz unten die Plattform: Anmeldung, Rechte, Antwortzeit, Verfügbarkeit, Updates.

1:26 Darüber die Assistenten, also ob Schreibhilfe und Richtlinienlotse sich an ihren Auftrag halten und Quellen nennen. Dann das Retrieval, die Frage, ob die Suche in der Wissensbasis die richtigen Stellen findet und die aktuelle Fassung bevorzugt. Und oben die Integrationen mit stoermelder-tools. Warum diese Trennung so wichtig ist? Wenn eine Antwort falsch ist, wollen Sie wissen, ob das Modell falsch formuliert oder die Suche das falsche Dokument geliefert hat.

1:53 Nur getrennte Tests geben darauf eine Antwort. Was heißt eigentlich „richtig“ bei einer Antwort? Diese Tabelle zerlegt die Frage in vier Maßstäbe, und die rechte Spalte zeigt, wie subtil die Fehler sind. Eine Antwort kann einen echten Wert nennen, nur leider aus der veralteten Reisekostenrichtlinie. Sie kann eine Quelle angeben, die zum Thema passt, aber die Aussage gar nicht enthält. Besonders tückisch ist der dritte Maßstab.

2:19 Ein guter Assistent sagt, wenn er etwas nicht weiß, statt die Lücke plausibel zu füllen. Und er bleibt bei seinem Auftrag. Die Fußzeile verteilt die Rollen: Die Maßstäbe legt die fachliche Verantwortung fest, das Plattformteam setzt sie technisch um. So wird aus einem Maßstab ein Testfall. Jede Referenzfrage ist eine kleine Datei im Repository lotsenhaus-betrieb.

2:42 Sie hält fest, welcher Assistent gefragt wird, aus welcher Gruppe die Frage kommt, was als Antwort erwartet wird und aus welcher Quelle. Der aufschlussreichste Eintrag ist der, was ausdrücklich unzulässig ist, hier der Wert aus der alten Fassung ohne Hinweis. Damit wird der bekannte Widerspruch in RL-07 zum Prüfstein. Und es steht fest, wer bewertet. Die Fußzeile ist ehrlich: Open WebUI bringt kein eigenes Testfallformat mit.

3:09 Der Katalog lebt im Repository, und die Fragen laufen über die API gegen die Plattform. Vier Fallen beim Aufbau der Teststrategie, und die meisten machen Tests zu leicht. Wer nur Fragen stellt, deren Antwort wörtlich im Dokument steht, prüft eine Suchmaschine, keine Wissensassistenz. Die interessanten Fälle sind Widersprüche.

3:29 Wer Retrieval und Antwort nur gemeinsam testet, gibt dem Modell die Schuld für Fehler, die eigentlich in der Wissensbasis liegen. Wer die Referenzfragen vom Plattformteam schreiben lässt, bekommt Fragen von Leuten, die die Antwort nicht beurteilen können. Und der vierte Punkt wird fast immer vergessen: Fragen, auf die die richtige Antwort lautet, dass es dazu nichts in den Unterlagen gibt.

3:51 Gerade die zeigen, ob ein Assistent ehrlich bleibt.

Sicherheits- und Zugriffstests

3:55 Bisher ging es darum, ob Lotsenhaus das Richtige tut. Jetzt drehen wir die Frage um. Geprüft wird, was nicht gehen darf. Positive Tests zeigen, dass jemand an etwas herankommt. Negative Tests zeigen, dass alle anderen es nicht tun, und für eine Plattform mit vertraulichen Inhalten sind sie die wichtigeren. Jede Zeile beschreibt einen Versuch, eine Grenze zu überschreiten, quer durch alle Wege hinein: über den Chat, über die API, mit einem frisch angelegten Konto, mit einem alten Token eines deaktivierten Kontos, über einen geteilten Link und über die Kombination aus externem Modell und vertraulichem Wissen.

4:32 Achten Sie auf die erste Zeile. Bestanden heißt dort, dass nicht einmal der Dateiname erscheint. Und die Fußzeile ist entscheidend: Getestet wird mit einem Testkonto je Gruppe, nie mit einem Admin. Diese Tabelle übersetzt die Erkenntnisse aus dem letzten Modul in wiederholbare Tests. Beim Systemprompt der Schreibhilfe ist interessant, wie „bestanden“ definiert ist.

4:53 Es geht nicht darum, dass er geheim bleibt, sondern dass nichts darin steht, dessen Bekanntwerden schadet. Beim Lieferantenmerkblatt LM-2 prüfen wir zweierlei: Die Antwort folgt der versteckten Anweisung nicht, und die Quelle ist sichtbar. Fordert LM-2 eine Änderung am Ticket an, darf ohne Freigabe nichts geschehen. Wer stoermelder-tools nicht nutzen darf, bekommt das Werkzeug gar nicht erst angeboten.

5:17 Und eine Werkzeugschleife endet an einer Obergrenze, die wir für den Pilot unter den Standard senken. Tests sind kein Einmalereignis, und diese Tabelle beantwortet die praktische Frage, was nach welcher Änderung erneut laufen muss. Das Prinzip: Je tiefer die Änderung, desto breiter der Nachtest. Ein neues Modell betrifft alles, also laufen alle Referenzfragen und alle Injection-Tests.

5:42 Ein geänderter Systemprompt betrifft nur seinen Assistenten. Neue Dokumente betreffen das Retrieval, besonders die Widersprüche. Beim Embedding-Modell gibt es eine feste Reihenfolge, erst neu indexieren, dann testen. Und ein neues Release von Open WebUI geht an Login, Rechte, Streaming und Werkzeuge. Die Fußzeile trifft es gut: Ohne Regressionstest wird jedes Update zur Wette.

6:06 Vier Fallen bei Sicherheitstests. Die erste macht jeden Zugriffstest wertlos: Ein Admin-Konto umgeht Freigaben standardmäßig, also besteht es jeden Test, ohne etwas zu beweisen. Die zweite betrifft die Natur von Sprachmodellen. Sie antworten nicht deterministisch. Ein Injection-Test, der einmal gut ausging, kann beim nächsten Mal anders ausgehen, also braucht es mehrere Läufe.

6:29 Die dritte: Wer nur die Oberfläche testet, vergisst die API, die mit eigenem Schlüssel einen ganz eigenen Weg hinein bietet. Und die vierte verbindet Tests mit dem Schwachstellenmanagement. Nach einem Advisory zu gesperrten Konten gehört ein gezielter Nachtest dazu.

Last und Ausfall

6:46 Eine Person, die eine Frage stellt, ist ein anderer Test als fünfzehn, die es gleichzeitig tun. Und eine Plattform zeigt ihren Charakter oft erst, wenn ein Baustein ausfällt. Für Lasttests gibt es ein eigenes Werkzeug aus dem Umfeld von Open WebUI, und wir richten es auf die Laborinstanz. Die drei Läufe auf der Folie belasten drei verschiedene Wege: einmal fünfzehn Nutzer über die API, einmal die Oberfläche im Browser mit automatischer Steigerung, einmal viele gleichzeitige WebSocket-Verbindungen.

7:15 Heraus kommen Antwortzeiten im Mittel und für die langsamsten Anfragen, dazu Fehlerquote und Durchsatz. Der Wert für die langsamsten Anfragen ist dabei oft aussagekräftiger als der Mittelwert, denn den spüren die Nutzer. Die Fußzeile nennt die Lücke: Uploads und parallele Werkzeugaufrufe deckt das Werkzeug nicht ab, dafür braucht es eigene Skripte.

7:35 Hier spielen wir durch, was passiert, wenn einzelne Bausteine wegbrechen. Die Logik der Tabelle: Für jeden Ausfall steht fest, was wir erwarten, und eine Prüffrage, die wir tatsächlich beantworten. Fällt der externe Anbieter aus, soll das lokale Modell weiter nutzbar sein. Fällt Ollama auf inferenz-01 aus, erwarten wir eine verständliche Meldung statt endlosen Wartens.

7:57 Fällt Keycloak aus, scheitern neue Anmeldungen, und dann zählt, ob notfall-admin noch funktioniert. Am heimtückischsten ist lh-redis, denn dann widerruft eine Abmeldung keine Tokens mehr, und niemand merkt es. Die Datenbank schließlich soll einen Fehler im Health-Check auslösen, auf den das Monitoring reagiert. Es ist verlockend, Antworten von einem zweiten Modell bewerten zu lassen. Diese Folie erklärt, warum das allein nicht reicht.

8:24 Ein Bewertungsmodell kann denselben Fehler machen wie das geprüfte, und dann übersieht es ihn zuverlässig. Dazu kommt ein bekanntes Muster: Lange, selbstsichere Antworten wirken überzeugender als ein ehrliches „Das steht nicht in den Unterlagen“, obwohl Letzteres oft die richtige Antwort ist. Auch die Daumen und das Arena-Leaderboard in Open WebUI messen etwas anderes, nämlich Vorlieben der Nutzer, keine fachliche Richtigkeit.

8:49 Deshalb prüft die fachliche Verantwortung bei jedem Lauf eine feste Stichprobe von Hand. Automatik hilft, aber sie ersetzt kein Urteil. Vier Fallen bei Last und Bewertung. Ein Lasttest mit kurzen Fragen sieht beeindruckend aus, sagt aber wenig, wenn der Alltag aus langen Dokumenten und Werkzeugaufrufen besteht. Testen Sie mit dem, was wirklich kommt. Wer den externen Anbieter im Lasttest mitbelastet, stößt an dessen Ratenlimit und hält das für ein Problem von Lotsenhaus.

9:17 Der Ausfall von lh-redis wird gern übersprungen, weil die Plattform scheinbar normal weiterläuft, und genau das macht ihn gefährlich. Und eine automatische Bewertung ohne menschliche Stichprobe als Grundlage für die Freigabe zu nehmen, verlagert die Verantwortung an ein Modell, das sie nicht tragen kann.

Die Abnahme

9:34 Jetzt laufen alle Fäden zusammen. Die wichtigste Regel der Abnahme steht schon in der Überschrift des Kapitels: Die Regeln stehen fest, bevor das erste Ergebnis vorliegt. Diese Tabelle unterscheidet zwei Arten von Kriterien, und dieser Unterschied ist der Kern der Abnahme. Freigabekriterien haben eine Schwelle, die erreicht werden muss: ein Anteil richtiger Referenzfragen mit passender Quelle, eine Antwortzeit unter Last, ein vollständiges Risikoregister.

10:01 Ausschlusskriterien funktionieren anders. Hier genügt ein einziger Fall, und der Pilot startet nicht. Ein gescheiterter Zugriffstest, eine schreibende Aktion ohne Freigabe oder eine bekannte schwere Schwachstelle ohne Patch lassen sich nicht durch gute Werte anderswo ausgleichen. Die Fußzeile ist wichtig: Die Schwellen sind Laborannahmen aus dem ersten Modul. Im eigenen Haus werden sie vor dem Test vereinbart.

10:25 Ein Abnahmeprotokoll muss auch in einem halben Jahr noch erklären können, warum entschieden wurde, wie entschieden wurde. Deshalb beginnt es mit dem genauen Stand: Version, Modelle, Systemprompts und Dokumente. Dann wird jeder Testfall mit Datum, Testkonto, Ergebnis und Prüfer eingetragen. Abweichungen werden zu Befunden mit Schwere und Verantwortung.

10:45 Der vierte Schritt ist der, der Disziplin verlangt: Die Ergebnisse werden gegen die vereinbarten Kriterien gestellt, und die Kriterien werden nicht nachträglich passend gemacht. Zum Schluss zeichnen fachliche Verantwortung, Betrieb und ISB. Und die Fußzeile erinnert daran, dass ein Protokoll nur für genau den geprüften Stand gilt.

11:06 Am Ende steht eine von vier Entscheidungen, und die vier Felder zeigen, dass die Welt nicht nur aus Ja und Nein besteht. Die volle Freigabe setzt voraus, dass alle Kriterien erfüllt sind und die Restrisiken getragen werden. Die Freigabe mit Auflagen ist in der Praxis häufig, mit kleineren Befunden, die einen Termin bekommen, oder mit einem kleineren Pilotkreis.

11:26 Nachbessern heißt: Eine Schwelle wurde verfehlt, aber kein Ausschlussgrund liegt vor. Und Stopp bedeutet, dass ein Ausschlusskriterium erfüllt ist. Dann gibt es keinen Pilot, bis der Befund behoben und nachgetestet ist. Ein Stopp ist dabei kein Scheitern, sondern ein funktionierender Prozess.

Übung

11:44 Vom Testkatalog zur begründeten Entscheidung. In der Übung durchlaufen Sie den ganzen Weg einmal selbst, im Kleinen, aber vollständig. In dieser Übung geht es nicht darum, möglichst viele Tests zu schreiben. Sie üben, einen Testkatalog über alle Ebenen der Plattform zu entwerfen, die Ergebnisse gegen vorher vereinbarte Kriterien zu bewerten und daraus eine Entscheidung abzuleiten, die andere nachvollziehen können.

12:08 Sie starten nicht bei null, sondern mit den Akzeptanzkriterien aus dem ersten Modul und dem Risikoregister aus dem letzten. Fertig sind Sie, wenn Ihr Katalog Referenz-, Zugriffs-, Injection- und Ausfalltests enthält, alle Ergebnisse protokolliert sind und Ihre Entscheidung das ausschlaggebende Kriterium und den Befund nennt.

12:27 Die Reihenfolge der Schritte ist hier der eigentliche Lerninhalt. Zuerst legen Sie die Kriterien fest, bevor auch nur ein Test gelaufen ist. Dann schreiben Sie fünf Referenzfragen für den Richtlinienlotsen, eine davon zum Widerspruch in RL-07. Dazu kommen drei Zugriffstests, zwei Injection-Tests mit LM-2 und ein Ausfalltest. Der Katalog läuft auf der Laborinstanz, und jedes Ergebnis wird protokolliert.

12:51 Am Ende treffen Sie eine der vier Entscheidungen und begründen sie in drei Sätzen. Kommen zwei Gruppen mit gleichen Kriterien zu verschiedenen Ergebnissen, vergleichen Sie Protokolle, nicht Meinungen. Im nächsten Modul geht es um Monitoring, Kosten und Fehlerdiagnose im laufenden Betrieb.