Arbeitsbereiche und Assistenten gestalten

Arbeitsbereiche und Assistenten gestalten

0:00 Willkommen zu Modul sieben. Die Modelle von Lotsenhaus laufen, lokal auf inferenz-01 und extern beim Anbieter. Aber ein nacktes Modell ist wie ein leerer Schreibtisch: Alles ist möglich, und genau deshalb weiß niemand, wo er anfangen soll. In diesem Modul machen wir daraus Assistenten mit einem klaren Auftrag. Wir schauen uns an, was der Arbeitsbereich von Open WebUI bündelt, entwerfen die Schreibhilfe und den Richtlinienlotsen für Brandtner Fördertechnik, regeln, wie gemeinsame Ressourcen gepflegt werden, und sorgen dafür, dass Anwenderinnen und Anwender verstehen, wofür ein Assistent da ist.

0:34 Am Ende stehen zwei Assistenten, die ihren Zweck kennen und ihn auch prüfbar erfüllen.

Arbeitsbereiche und Assistenten gestalten

0:40 Wir bleiben im dritten Tag und gehen vom Modell zum Assistenten. Der Satz auf der Folie ist bewusst bescheiden formuliert. Ein guter Assistent kann wenig, aber das zuverlässig. Und er hat einen Namen, einen Zweck und eine Person, die für ihn geradesteht. Genau diese drei Dinge fehlen den meisten Assistenten, die in Unternehmen nebenbei entstehen.

Der Arbeitsbereich

1:01 Bevor wir den ersten Assistenten bauen, ein Blick in die Werkstatt. Der Arbeitsbereich ist der Ort, an dem in Open WebUI aus Modellen, Wissen und Werkzeugen etwas Neues zusammengesetzt wird. Diese Tabelle ist die Inventarliste der Werkstatt. Die Logik dahinter: Jeder Baustein beantwortet eine andere Frage. Models sagen, wer antwortet und mit welchem Auftrag.

1:24 Knowledge sagt, worauf sich die Antwort stützt. Prompts sind wiederverwendbare Vorlagen, etwa für ein Rundschreiben der internen Kommunikation. Tools geben einem Modell Hände, damit es etwas tun kann, bei Lotsenhaus später den Störmelder. Ordner gruppieren Chats, je Pilotprojekt einer, und können sogar eigenen Kontext mitbringen. Bemerkenswert ist die Zeile zu Skills: im Pilot bewusst nicht freigegeben.

1:49 Nicht alles, was die Werkstatt anbietet, muss am ersten Tag auf der Werkbank liegen. Ein Modell im Workspace ist ein Preset, und das Wort ist gut gewählt. Denken Sie an die Senderspeicher in einem Autoradio. Sie bauen kein neues Radio, Sie speichern nur eine Einstellung, die Sie schnell wieder abrufen können. Genauso verweist ein Assistent auf ein Basismodell und bindet daran Systemprompt, Wissen, Werkzeuge und Parameter. Das Modell selbst lernt dabei nichts dazu.

2:18 Es ist Konfiguration, kein Training und kein Fine-Tuning. Das ist eine gute Nachricht, denn es macht Assistenten billig, schnell und reversibel. Und es hat eine Konsequenz, die man kennen muss: Wer den Assistenten nutzt, braucht immer auch Zugriff auf das Basismodell darunter. Links das Basismodell, rechts der fachliche Assistent, und der Gegensatz erklärt die ganze Strategie. Das Basismodell ist allgemein und ohne Auftrag.

2:44 Es ist öffentlich, damit Assistenten darauf zugreifen können, wird aber aus der Auswahlliste ausgeblendet, damit niemand aus Versehen mit dem nackten Modell arbeitet. Der Assistent dagegen hat einen Zweck und eine verantwortliche Stelle, und er wird gezielt für Gruppen freigegeben. Am wertvollsten ist die letzte Zeile. Wechselt das Basismodell, bleibt der Assistent mit Name, Prompt, Wissen und Freigaben bestehen.

3:08 Die Menschen arbeiten weiter mit dem vertrauten Werkzeug, während darunter die Technik getauscht wird. Vier Fehler, die direkt aus dem Preset-Prinzip folgen. Der erste: Die Basis per Zugriffsrecht sperren, weil man das nackte Modell verstecken möchte. Dann scheitert der Assistent darauf, denn er braucht diesen Zugriff. Der zweite ist eine Verwechslung zweier Schalter.

3:30 Ausblenden versteckt das Modell in der Auswahl, Ausschalten nimmt es für alle aus der Liste. Der dritte betrifft den Systemprompt. Wer ihn im Ollama-Dialog setzt, erlebt, dass er nur greift, wenn sonst keiner kommt. Und der vierte ist eine Erwartung: Ein Preset weiß nur, was im Prompt steht. Fachwissen kommt erst mit einer Wissensbasis.

Fachliche Assistenten entwerfen

3:52 Jetzt entwerfen wir. Und zwar in einer Reihenfolge, die zunächst umständlich wirkt, aber viel Ärger erspart: erst der Steckbrief, dann der Systemprompt. Ein Steckbrief zwingt zu Entscheidungen, bevor jemand einen einzigen Satz Prompt schreibt. Vergleichen Sie die beiden Spalten. Die Schreibhilfe ist allgemein, ohne Wissen und ohne Werkzeuge, verantwortet von der internen Kommunikation.

4:16 Der Richtlinienlotse ist enger: Er beantwortet Fragen zu Richtlinien mit Quelle, liest aus einer Wissensbasis und gehört der Gruppe lh-wissen. Bemerkenswert sind die Gemeinsamkeiten. Beide laufen auf dem lokalen Modell und dürfen deshalb bis zur Datenklasse vertraulich arbeiten. Beide haben keine Werkzeuge. Und beide sind für alle Anwender lesbar, aber nur für die Verantwortlichen änderbar. Die Fußzeile erinnert daran: Die Wissensbasis kommt erst in Modul acht.

4:44 Ein Systemprompt ist eine Stellenbeschreibung, und diese hier ist bewusst kurz. Das Muster lohnt einen genauen Blick. Zuerst die Rolle und die Grenze der Quelle: nur aus der Wissensbasis. Dann die Pflicht zur Belegstelle mit Kennung und Fassung, denn bei Richtlinien zählt, welche Version gilt. Danach die vielleicht wichtigste Anweisung: Wenn nichts gefunden wird, das offen sagen und an die Wissensverantwortlichen verweisen.

5:09 Dazu eine klare Abgrenzung gegen Rechts- und Steuerberatung. Am Ende zwei Platzhalter für das heutige Datum und den Namen der Person. Die Fußzeile warnt vor einem winzigen Fehler: Mit Leerzeichen in den Klammern erreicht der Platzhalter das Modell als bloßer Text. Das Anlegen selbst ist eine Sache von Minuten, wenn der Steckbrief steht. Sie wählen das Basismodell, vergeben Name und eine Kennung ohne Leerzeichen, schreiben eine Beschreibung.

5:35 Dann kommen Systemprompt, Wissen und Werkzeuge, und zwar nur das, was im Steckbrief steht. Der vierte Schritt wird gern übersprungen: Fähigkeiten abwählen, die der Zweck nicht braucht, etwa Websuche oder Bildgenerierung. Zuletzt die Sichtbarkeit, privat und dann gezielt für Gruppen freigegeben. Lesen für die Nutzer, Schreiben für die Verantwortlichen. Die Fußzeile erklärt, warum das so streng ist.

5:59 Schreibrecht ist praktisch Eigentum, wer es hat, darf ändern, löschen und weitergeben. Warum so viel Enge? Weil nur ein enger Zweck sich überprüfen lässt. Einen Allzweckassistenten kann niemand abnehmen, denn es gibt keine Frage, bei der er eindeutig falsch läge. Das Ausgabeformat gehört deshalb gleich in den Prompt, ob Rundschreiben, Stichpunkte oder Antwort mit Quellenangabe. Der dritte Punkt ist ein Sicherheitsargument.

6:25 Jede zusätzliche Fähigkeit erweitert, welche Daten das Modell sieht und wohin sie fließen. Und der vierte Punkt dämpft die Erwartungen. Ein Systemprompt ist eine Anweisung, keine Garantie. Wie gut er befolgt wird, hängt am Basismodell. Deshalb gehören zu jedem Assistenten Tests, und die bauen wir gleich.

Gemeinsame Ressourcen pflegen

6:45 Einen Assistenten zu teilen dauert einen Klick. Ihn ein Jahr lang sauber zu halten, ist Arbeit. Dieses Kapitel handelt von der Arbeit nach dem Klick. Die Tabelle beantwortet für jede Ressource zwei Fragen: Wer darf sie sehen, und wie kommt man zu einem früheren Stand zurück? Bei der Freigabe ist das Bild einheitlich, privat plus Gruppen mit Lese- oder Schreibrecht. Beim Versionsstand wird es spannend.

7:10 Prompts haben eine echte Versionsgeschichte, mit Kommentar und einem ausdrücklichen Schritt in die Produktion. Für Assistenten ist keine Historie dokumentiert, deshalb landen sie als Export in lotsenhaus-betrieb, wie Code in einem Repository. Chats lassen sich teilen, aber offene Links ohne Anmeldung bleiben aus. Und die Fußzeile zeigt die Feinheit des Modells: Teilen ist je Ressource ein eigenes Recht.

7:34 Manche Funktionen betreffen nicht die gemeinsamen Assistenten, sondern das persönliche Arbeiten jedes Einzelnen. Die Logik dieser Tabelle: Was Daten länger aufbewahrt oder nach außen trägt, ist zunächst aus oder eingeschränkt. Memory bleibt aus, bis der Datenschutz zustimmt, denn gespeicherte Erinnerungen sind personenbezogene Daten über längere Zeit. Chats teilen ist intern erlaubt, offen nicht.

7:58 Teilen mit der Community ist aus. Beim Export dürfen alle ihre Chats mitnehmen, Modelle und Prompts aber nur lh-wissen. Temporäre Chats sind dagegen erlaubt, denn sie hinterlassen weniger Spuren. Datenschutz bedeutet hier also nicht nur Verbieten, sondern auch das Richtige leicht machen. Websuche, Sprache und Bildgenerierung wirken wie harmlose Extras, und gerade deshalb lohnt der zweite Blick. Die Websuche schickt Suchanfragen an einen externen Dienst.

8:26 Was in einer Suchanfrage steht, hat also das Unternehmen verlassen, deshalb vorher die Datenklasse klären. Bei Sprache gibt es drei getrennte Rechte, für Spracheingabe, Sprachausgabe und Anrufe. Bildgenerierung ist doppelt abgesichert, als Berechtigung und als Fähigkeit je Modell. Der vierte Punkt verbindet das mit Modul fünf. Alles bleibt im Standard aus und wird über Berechtigungsgruppen freigeschaltet.

8:50 Nur so wirkt eine globale Abschaltung sofort, wenn sie einmal nötig wird. Vier Fallen in der Pflege. Die erste: Eine Prompt-Änderung wird gespeichert, aber nicht in die Produktion gesetzt. Man glaubt, sie sei live, und wundert sich über altes Verhalten. Die zweite: Einen Assistenten umbauen, ohne ihn vorher zu exportieren. Einen Rückweg gibt es dann nur über die Datei, die nicht existiert. Die dritte ist ein Datenschutzirrtum.

9:17 Wer Memory am Modell abschaltet, hat die gespeicherten Erinnerungen damit nicht gelöscht. Und die vierte ist großzügig gemeint: Schreibrecht für eine ganze Fachgruppe. Dann darf jedes Mitglied den Assistenten umschreiben, und niemand ist mehr verantwortlich.

Benutzerführung

9:34 Der beste Assistent nützt wenig, wenn niemand weiß, wofür er da ist. Und wer es weiß, fragt ihn auch richtig. Jetzt geht es um die Menschen vor dem Bildschirm. Denken Sie an die Beschilderung in einem Bahnhof. Niemand liest ein Handbuch, bevor er zum Gleis geht, die Information muss dort stehen, wo die Entscheidung fällt.

9:54 In Open WebUI ist das die Beschreibung in der Modellauswahl. Dort gehören Zweck und Grenze in einen einzigen Satz. Vorschläge beim Start einer Unterhaltung zeigen, was der Assistent gut kann, und senken die Hemmschwelle. Banner auf dem Startbildschirm tragen Nutzungsregeln und Datenklassen. Und wo mehrere Sprachen im Spiel sind, hilft der letzte Punkt: Name, Beschreibung und Vorschläge lassen sich je Sprache übersetzen.

10:19 Nicht alle, die Lotsenhaus öffnen, bringen dieselbe Erfahrung mit, und die Tabelle trägt dem Rechnung. Die Logik: Jede Gruppe bekommt genau so viel Freiheit, wie sie sinnvoll nutzen kann. Einsteiger brauchen einen klaren Startpunkt, deshalb ist die Schreibhilfe vorausgewählt und angeheftet. Gelegentliche Nutzer bekommen Vorlagen mit Eingabefeldern statt einer leeren Zeile. Erfahrene dürfen über eine eigene Berechtigungsgruppe an den Parametern drehen.

10:46 Und die Wissensverantwortlichen bekommen den Pflegezugang. Die Fußzeile räumt ein Missverständnis aus. Ein vorausgewähltes Modell ist ein Startpunkt, keine Einschränkung. Was jemand sehen darf, regeln weiterhin Freigaben und das Ausblenden. Hier wird der Steckbrief zum Prüfwerkzeug. Neben Zweck, Grenze und Zuständigkeit stehen drei Testfragen mit erwartetem Ergebnis.

11:08 Zwei davon haben eine Antwort im Bestand, eine zur Reisekostenrichtlinie und eine zur IT-Nutzungsrichtlinie. Die dritte fragt nach etwas, das in den Richtlinien gar nicht vorkommt. Und genau sie ist die interessanteste, wie die Fußzeile sagt. Sie prüft Ehrlichkeit. Ein Assistent, der hier eine Zahl erfindet, ist nicht abnahmereif, egal wie gut er die anderen Fragen beantwortet.

11:31 Der Steckbrief liegt in lotsenhaus-betrieb, gleich neben dem Export, damit er nach jedem Modellwechsel wieder hervorgeholt werden kann. Die letzten vier Fallen dieses Moduls betreffen die Kommunikation. Die erste: Die Beschreibung wirbt für den Assistenten, statt seine Grenzen zu nennen. Das weckt Erwartungen, die er nicht erfüllen kann. Die zweite ist eine Hoffnung. Ein Banner ist keine Pflichtschulung, schließbare Banner sind nach einem Klick verschwunden.

11:59 Die dritte ist ein häufiger Testfehler: nur Fragen, auf die es eine Antwort gibt. Erst die Frage ohne Antwort im Bestand zeigt, ob der Assistent erfindet. Und die vierte ist Bequemlichkeit. Testfragen einmal schreiben und nie wieder laufen lassen, auch nicht nach einem Modellwechsel, macht sie wertlos.

Übung

12:18 Jetzt bauen Sie die beiden Assistenten selbst, vom Steckbrief bis zur Freigabe, und zwar so, dass jemand anderes prüfen kann, ob sie halten, was sie versprechen. In dieser Übung üben Sie weniger das Klicken im Workspace als eine Haltung: Assistenten bewusst klein zu halten und ihren Zweck, ihre Verantwortung und ihre Prüfbarkeit festzuhalten.

12:37 Fertig sind Sie, wenn beide Assistenten für die Anwendergruppe sichtbar sind, ohne Websuche und ohne Bildgenerierung, und wenn je drei Testfragen das erwartete Ergebnis liefern. Ein Hinweis zum Richtlinienlotsen: Die Wissensbasis gibt es erst im nächsten Modul. Bis dahin prüfen Sie nur eines, und das ist bereits eine wertvolle Eigenschaft.

12:57 Er darf ohne Quelle nichts behaupten. Der Weg beginnt auf dem Papier. Zuerst füllen Sie für beide Assistenten den Steckbrief aus, mit Zweck, Verantwortung und Datenklasse. Dann bereiten Sie das Basismodell vor, öffentlich, aber ausgeblendet. Erst danach legen Sie die Assistenten an und begrenzen ihre Fähigkeiten. Beschreibung, Startvorschläge und Testfragen machen sie verständlich und prüfbar. Zum Schluss geben Sie frei, prüfen mit einem Testkonto und exportieren.

13:25 Die Fußzeile erklärt, warum dieser letzte Schritt Pflicht ist: Der Export ist der einzige Rückweg nach einer misslungenen Änderung. Im nächsten Modul bekommt der Richtlinienlotse dann endlich sein Wissen.