Die Persönlichkeit meines Assistenten

Am Anfang der Instruktionen stand eine ziemlich grundlegende Erklärung: Was bist du? Welchen Zweck sollst du erfüllen? Wie sollst du mit mir umgehen?

Ich hatte viel Zeit damit verbracht, meinem Assistenten Fähigkeiten zu geben. Jetzt beschrieb ich die Rolle, die er für mich einnehmen sollte. Er sollte wissen, wofür ich ihn gebaut hatte und wie ich mir unsere Zusammenarbeit vorstellte.

Dabei konnte ich auch festlegen, wie er mich ansprechen sollte. Ich fand es schon ziemlich cool, als er mich seinen Meister und Schöpfer nannte. Das hatte genau diesen leicht übertriebenen Assistentencharakter, der mir Spaß machte.

Es war mein eigenes Projekt, und solche Kleinigkeiten gehörten für mich dazu. Nach all den Schnittstellen, der Sprachverarbeitung und den Regeln bekam auch die Art, wie er mit mir sprach, eine persönlichere Note.

Das war es, was ich seine „Persönlichkeit“ nannte: die Beschreibung dessen, was er sein sollte, welchen Zweck er hatte und wie er sich verhalten sollte.

Besonders wichtig war, was er lassen sollte

Mit der Rollenbeschreibung allein war es allerdings nicht getan. Ich wollte vor allem die erfundenen Aussagen aus dem vorherigen Teil in den Griff bekommen.

Also ergänzte ich Verbote:

• Keine unbelegten Annahmen als Tatsachen darstellen.
• Keine Dinge erfinden.
• Bei Fakten bleiben.
• Keine ausgeführten Aktionen behaupten, für die es keine Grundlage gibt.

In meinen Versuchen half das recht schnell. Ich merkte aber auch, wie wichtig es war, diese Grenzen ausdrücklich zu formulieren. Zu beschreiben, wie ich mir meinen Assistenten wünschte, war nur ein Teil der Aufgabe. Mindestens genauso wichtig war, ihm zu sagen, welches Verhalten ich nicht wollte.

Die Verbotsliste bekam dadurch einen größeren Stellenwert, als ich anfangs erwartet hatte. Seine Ansprache machte ihn persönlicher. Ob ich seine Antworten gebrauchen konnte, hing aber wesentlich davon ab, wie er mit fehlendem Wissen und seinen eigenen Grenzen umging.

Damit war nicht jede mögliche Falschaussage ausgeschlossen. Für mich war es eine spürbare Verbesserung, die ich weiter prüfen wollte. Ich brauchte einen Weg, seine Antworten mit dem tatsächlichen Ablauf abzugleichen.

Dafür hatte ich die Protokolle

Logging hatte ich von Anfang an mitgedacht. Ich wollte Aktionen und Ausführungen nachvollziehen können, einschließlich der Schritte dazwischen.

Der Weg durch die Intent-Pipeline, die Auswahl einer Aktion und schließlich ihre Ausführung sollten im Protokoll sichtbar sein. So konnte ich nachsehen, welchen Weg meine Anwendung genommen hatte und welches Ergebnis zurückgekommen war.

Gerade nach den erfundenen Erfolgsmeldungen war das wichtig. Wenn mein Assistent sagte, er habe etwas erledigt, wollte ich überprüfen können, ob die passende Aktion überhaupt aufgerufen worden war und was dabei passiert war.

Das half mir, Probleme einzugrenzen. War schon der erkannte Intent falsch? War die Ausführung fehlgeschlagen? Oder passte erst die anschließende Antwort nicht zu dem, was tatsächlich passiert war?

Ohne diesen Einblick hätte ich immer wieder nur festgestellt, dass sich etwas falsch anfühlte. Mit den Protokollen konnte ich gezielter nach der Ursache suchen.

Und plötzlich konnte ich genauer messen

Wie lange dauerte die Verarbeitung wirklich? Welcher Abschnitt brauchte besonders lange? Wo wartete ich, obwohl ich den Ablauf vielleicht noch verbessern konnte?

Diese Fragen kannte ich bereits aus der Arbeit an den Sprachpipelines. Mit den erfassten Zeiten konnte ich genauer hinschauen. Spracherkennung, Routing, Ausführung und Sprachausgabe waren einzelne Abschnitte, deren Dauer ich vergleichen konnte.

Wenn sich eine Antwort langsam anfühlte, musste ich nicht sofort das Sprachmodell verdächtigen. Ich konnte erst prüfen, an welcher Stelle die Verzögerung entstand.

Auch Änderungen ließen sich dadurch besser beurteilen. Eine Optimierung sollte sich gut anfühlen, aber ich wollte ebenso sehen, ob sie an der erwarteten Stelle tatsächlich Zeit sparte.

So halfen mir dieselben Einblicke sowohl beim Nachvollziehen von Fehlern als auch beim Verbessern der Geschwindigkeit. Ich verstand mein eigenes Programm immer besser und fand weitere Stellen, an denen ich arbeiten konnte.

Trotzdem wollte ich mehr sehen

Bei all der technischen Optimierung blieb irgendwann ein anderer Wunsch übrig. Ich wollte meinem Assistenten eine Oberfläche geben, die mehr von dem sichtbar machte, was inzwischen in ihm steckte.

In der Konsole konnte ich meine Eingaben, die Antworten meines Assistenten und die technischen Protokolle mitlesen. Das half mir beim Entwickeln und bei der Fehlersuche. Doch mit den vielen Abläufen und Fähigkeiten war die Anwendung gewachsen. Die Konsole allein genügte mir nicht mehr.

Ich wollte mehr als vorbeilaufende Textzeilen. Wie würde es sich anfühlen, meinen Assistenten über eine richtige Oberfläche zu bedienen? Eine, die ansprechend aussah und mir zeigte, was gerade passierte?

Damit stand ich vor einer neuen Entscheidung: Sollte ich auf dem bestehenden Aufbau weiterarbeiten oder noch einmal neu anfangen? Eine Desktop-Anwendung bauen? Oder wäre eine Webanwendung der bessere Weg?

Im bisherigen Projekt steckte viel Arbeit. Gleichzeitig hatte ich Lust, ihm ein neues Gesicht zu geben. Nur wusste ich noch nicht, welche Form dazu passte.

Also ließ ich das Projekt eine Weile ruhen. Bevor ich weiterprogrammierte, wollte ich mir darüber klar werden, wie ich meinen Assistenten künftig nutzen wollte.