Modulentwicklung für Rhasspy Sprachassistent

[Beta-User]

...weiß nicht, ob mit "Produkt" ein Buch gemeint gewesen war, hätte eher auf das Modul getippt...

Ansonsten ist Rhasspy/RHASSPY ja "unvergleichlich", mir unerklärlich, zu welcher Konkurrenz man wechseln wollte .

Und bei "Blut" kommen mir alternativ auch gleich "Schweiß und Tränen" in den Sinn (obwohl es bis 40,000 Headmen noch weit ist, https://www.youtube.com/watch?v=q0zaGcSjKgM)

[JensS]

@Beta-User
https://community.rhasspy.org/t/whats-the-craziest-thing-you-can-or-cannot-do-with-rhasspy/3648/3 gefällt mir. 

Das aktuelle Bild in der WIKI finde ich gut. In das Dialog-Element könnten ASR und NLU als Unterelemente rein oder man leitet Pfeile für ASR+NLU durch das Dialogelement. Man hat einen ersten Eindruck, wie Rhasspy aufgebaut ist - das genügt.

Gruß Jens

[Prof. Dr. Peter Henning]

Vielleicht für diese Mehrheit wie in der Anlage...?

MQTT Broker wird als Bezeichnung nicht mehr verwendet, heißt jetzt schon länger MQTT Server.

LG

pah

[Beta-User]

MQTT Broker wird als Bezeichnung nicht mehr verwendet, heißt jetzt schon länger MQTT Server.

Danke für den Hinweis, hab's geändert.

Du hattest "intentNotRecognized" zur Sprache gebracht - hier ist eine Idee dazu. 

...ich mache mal hier weiter, das scheint mir hier besser aufgehoben...

Ja, ich habe pah's Anregung aus

Eine klare Erkenntnis aus meinen Forschungsprojekten kann ich nicht oft genug zitieren: Jedes Sprachsteuerungssystem benötigt eine "dialog closure" am Ende, die auf noch so absurde Fragen und Antworten der Nutzer reagiert und immer irgendetwas zurückliefert,

aufgegriffen und (an der falschen Stelle) die/eine "Übersetzung" in die Rhasspy-Sprache vorgenommen, und dann eben an der falschen Stelle die Rückmeldung gegeben, dass meine aktuellen Überlegungen dazu keinen wirklichen Fortschritt gebracht haben...

Beim intentNotRecognized wird ja etwas erkannt und ausgegeben. Von der NLU wird nur kein passender Intent gefunden.

Das ist soweit verstanden .

"wie spät ist es jetzt" wird nicht erkannt, weil "jetzt" zuviel ist. Wird der Text mit den vorhandenen Intents verglichen, kann der enthaltene Intent "wie spät ist es" gefiltert werden und der Intent könnte nach einer Rückfrage: "Meinst du - wie spät ist es?" per sessionContinue an die Session zurückgegeben werden.

Das Problem dabei ist folgendes: das würde funktionieren, wenn man genau eine RHASSPY-Instanz voraussetzt und die zuliefernde Rhasspy-Installation dazu da wäre, genau diese eine RHASSPY-Instanz zu versorgen.

Sobald aber derselbe MQTT-Server für
- mehrere RHASSPY-Instanzen und/oder
- mehrere Rhasspy-Installationen
"zuständig" ist, ist komplett unklar, wer
- die "intentNotRecognized"-Message verursacht hat,
- warum das der Fall ist
- wer dafür zuständig ist, den Faden aufzugreifen (es könnte auch eine andere externe Logik den rawInput "abgreifen", z.B. pah mit MQTT2_DEVICE->notify->Babble, oder eine eigene python-App in den Weiten des Universums suchen...?!?)?

Im Moment sehe ich noch keine wirklich befriedigende "automatische" Lösung. Sehr eventuell wäre was denkbar, das
- der "Konfigurator" aktiv anschaltet, und
- ggf. mit einem Timer kurz wartet, ob nicht doch noch jemand anderes was in dieser Sache unternimmt, um dann eben die Sitzung zuzumachen.

PS: Fall sich jemand wundert, warum das z.B im Rahmen der Tests scheinbar doch klappt: Da kommt die jeweilige Anfrage aus FHEM, und aus diesem Grund haben wir dann auch die Info, dass "uns" die Daten gehören...

[JensS]

Ok, "intentNotRecognized" wird vom Dialogmanager ausgeworfen. Dieser gibt auch zwingend eine sessionId und eine siteId mit. Eine Eindeutigkeit ist also gegeben.
Sollte eine zweite Rhasspy/RHASSPY-Instanz existieren, würde das Topic mit der fremden sessionId verworfen, da die sessionId vom Audio-Server der betreffenden Instanz generiert wurde.

p.s. Eine Konstellation mit mehreren RHASSPY- und Rhasspy-Instanzen an einem MQTT ist denkbar - aber auch sinnvoll? Dazu sollte doch eher eine zusätzliche MQTT-Instanz mit einem anderen Port genutzt werden.

[Beta-User]

Ok, "intentNotRecognized" wird vom Dialogmanager ausgeworfen. Dieser gibt auch zwingend eine sessionId und eine siteId mit. Eine Eindeutigkeit ist also gegeben.

Jein. Eine RHASSPY-Instanz weiß mAn. nämlich erst, ob eine sessionId "ihr" gehört, wenn die "intent-id" paßt. Alles andere findet "außerhalb" der FHEM-Sphäre statt, nur ist z.B. das Aktualisieren eines Wakeword-Events kein Eingriff in die laufende session, von daher ist das in dem Fall egal, dass etwas "auf Verdacht" passiert...

Sollte eine zweite Rhasspy/RHASSPY-Instanz existieren, würde das Topic mit der fremden sessionId verworfen, da die sessionId vom Audio-Server der betreffenden Instanz generiert wurde.

Vielleicht übersehe ich ja was, aber ein "normaler Sitzungsstart" ergibt doch einfach eine zufällige sessionId, oder? Man kann zwar die siteId und das wakeword (letzteres vermutlich nur, wenn eines benutzt wurde) daraus ableiten, aber im "multi-language-Fall" hören alle Rhasspy-Installationen zu und es wird ggf. anhand des wakewords entschieden, welche den "Zugriff" tätigt.
Eine von mehreren RHASSPY-Instanzen weiß aber ggf. nicht, welche davon "zu ihr" gehört...

[JensS]

... da die sessionId vom Audio-Server der betreffenden Instanz generiert wurde.

ist natürlcih Quatsch. Das wird vom Dialog-Manager erledigt, sobald eine Session durch hermes/dialogueManager/startSession gestartet wurde.
Am besten, ich schreibe ein kleines Script zur Veranschaulichung. Das kann aber etwas dauern, da mir im Moment die Hände teilweise gebunden sind.
Trotz aller Bedenken sollte es in allen Konstellationen funktionieren, da auf die eindeutige Ursprungs-Session zurückgesprungen wird.

Gruß Jens

[Beta-User]

Das wird vom Dialog-Manager erledigt,
[...]
Trotz aller Bedenken sollte es in allen Konstellationen funktionieren, da auf die eindeutige Ursprungs-Session zurückgesprungen wird.

Nach meinem Verständnis ist es der Dialog-Manager, der (in der Regel) eine Session startet (EDIT: oder besser formuliert: der auf Anforderung eine SessionId vergibt) - wohl meist ausgelöst durch ein Wakeword.

Aber nochmal: sobald man zwei Rhasspy-Installationen hat, die denselben MQTT-Server nutzen (multi-language-Umgebung), kennt RHASSPY mAn. die eigentliche Veranlassung für das Öffnen der session nicht, und weiß auch nicht, ob es der Dialogmanager von "Rhasspy-de" oder (z.B.) von "Rhasspy-es" war, der eine Sitzung aufgemacht hatte. Erst, wenn eine Sitzung bekanntermaßen einer RHASSPY-Instanz zugeordnet war ("continouos session"), könnte man mehr dazu wissen. Das ist aber die Ausnahme...

[JensS]

Nach meinem Verständnis ist es der Dialog-Manager, der (in der Regel) eine Session startet (EDIT: oder besser formuliert: der auf Anforderung eine SessionId vergibt) - wohl meist ausgelöst durch ein Wakeword.

Richtig - sobald eine Wakeword erkannt wurde oder eine hermes/dialogueManager/startSession-Anweisung (von außen) zum MQTT geschickt wird, startet der Dialog-Manager eine Session mit hermes/dialogueManager/sessionStarted und vergibt die eindeutige sessionId.

Edit: Einen Sonderfall gibt es bei der Android-App. Dort wird offensichtlich das ASR mit hermes/asr/toggleOn direkt eingeschaltet und die App vergibt dann die sessionId mit hermes/asr/startListening.

Aber nochmal: sobald man zwei Rhasspy-Installationen hat, die denselben MQTT-Server nutzen (multi-language-Umgebung), kennt RHASSPY mAn. die eigentliche Veranlassung für das Öffnen der session nicht, und weiß auch nicht, ob es der Dialogmanager von "Rhasspy-de" oder (z.B.) von "Rhasspy-es" war, der eine Sitzung aufgemacht hatte. Erst, wenn eine Sitzung bekanntermaßen einer RHASSPY-Instanz zugeordnet war ("continouos session"), könnte man mehr dazu wissen. Das ist aber die Ausnahme...

Zu einer "RHASSPY-ES"-Instanz muss eine "Rhasspy-es"-Instanz mittels "rhasspy -p es" gestartet sein. Ein Zugriff auf eine "Rhasspy-de"-Instanz würde u.a. wegen der Intentbezeichnung de.fhem.... scheitern. Es gibt also keine sinnvolle Verbindung zwischen den Instanzen verschiedener Sprachen. Daher finde ich einen eigenen MQTT pro Sprache sinnvoll.

[Beta-User]

Zu einer "RHASSPY-ES"-Instanz muss eine "Rhasspy-es"-Instanz mittels "rhasspy -p es" gestartet sein. ... Es gibt also keine sinnvolle Verbindung zwischen den Instanzen verschiedener Sprachen. Daher finde ich einen eigenen MQTT pro Sprache sinnvoll.

Es gibt aber uU. gemeinsam genutzte Hardware. Es mag nicht sinnvoll erscheinen, aber es ist denkbar, genauso, wie es denkbar ist, dass mehrere FHEM-Instanzen auf "die eine" Rhasspy-Installation "lauschen".

Wie sinnvoll das im einzelnen ist, sei mal dahingestellt, ich will ja erst mal nur deutlich machen, dass es wegen dieses offenen Zusammenspiels der einzelnen Komponenten zu Verwirrung kommen _kann_ und es sich daher m.E. verbietet, "einfach alles abzugreifen".

Ein Zugriff auf eine "Rhasspy-de"-Instanz würde u.a. wegen der Intentbezeichnung de.fhem.... scheitern.

Genau diese Intentbezeichnung existiert aber in dem "not recognized"-Fall gerade nicht... Also entweder ist vorher schon was passiert, das die laufende Sitzung gerade dieser RHASSPY-Instanz zuordnet, oder es ist eben unklar.

Edit: Einen Sonderfall gibt es bei der Android-App. Dort wird offensichtlich das ASR mit hermes/asr/toggleOn direkt eingeschaltet und die App vergibt dann die sessionId mit hermes/asr/startListening.

Das stimmt aber auch nur dann, wenn ein bestimmter Haken in der App _nicht gesetzt_ ist... Man kann auch bei Nutzung der App das session management der base übergeben .

[JensS]

Es gibt aber uU. gemeinsam genutzte Hardware.

Ok, das sollte für zwei eigenständigen Instanzen mit einer gemeinsam genutzten Audiohardware über PulseAudio möglich sein. Die Unterscheidung müsste dann per Wakeword passieren.

Wie sinnvoll das im einzelnen ist, sei mal dahingestellt, ich will ja erst mal nur deutlich machen, dass es wegen dieses offenen Zusammenspiels der einzelnen Komponenten zu Verwirrung kommen _kann_ und es sich daher m.E. verbietet, "einfach alles abzugreifen".
Genau diese Intentbezeichnung existiert aber in dem "not recognized"-Fall gerade nicht... Also entweder ist vorher schon was passiert, das die laufende Sitzung gerade dieser RHASSPY-Instanz zuordnet, oder es ist eben unklar.
Das stimmt aber auch nur dann, wenn ein bestimmter Haken in der App _nicht gesetzt_ ist... Man kann auch bei Nutzung der App das session management der base übergeben .

Die Verwirrung kann es nicht geben, da die Weichen bereits bei sessionStarted gestellt sind. Dort wird per "customData" das Wakeword mitgegeben.
Oder wie ordnet Rhasspy/RHASSPY die Sprachen zu?

[Beta-User]

Die Unterscheidung müsste dann per Wakeword passieren.

So war auch mein Verständnis.

Die Verwirrung kann es nicht geben, da die Weichen bereits bei sessionStarted gestellt sind. Dort wird per "customData" das Wakeword mitgegeben.
Oder wie ordnet Rhasspy/RHASSPY die Sprachen zu?

"customData" ist aber volatil und kann im Prinzip beliebig geändert werden. Das Wakeword wird zwar zum Bestandteil der sessionId, von daher hätte man diese Info durchaus - aber nur in den Fällen, in denen wirklich ein wakeword involviert ist (nicht: App+"Knopf"+session management@Rhasspy)...
Aber das hat nach meinem Verständnis dann wieder nicht wirklich was mit Sprachen zu tun, und ob die Sprachinfo in den "not recognized"-Fällen überhaupt enthalten ist, wäre ggf. zu klären.
RHASSPY interessiert sich übrigens eigentlich gar nicht für die Sprache, für das Modul ist alles Text und die Sprache ein "Neutrum", das ggf. einfach als Info mitgegeben wird. Ansonsten spielt die mAn. keine eigenständige Rolle (wenn man von der erwarteten Intent-Namensgebung und der Vergaben der slot-Namen absieht).

[JensS]

Das Wakeword wird zwar zum Bestandteil der sessionId, von daher hätte man diese Info durchaus - aber nur in den Fällen, in denen wirklich ein wakeword involviert ist (nicht: App+"Knopf"+session management@Rhasspy)...

Ein Punkt mehr, eine eigene MQTT-Instanz pro Sprache aufzumachen.

RHASSPY interessiert sich übrigens eigentlich gar nicht für die Sprache, für das Modul ist alles Text und die Sprache ein "Neutrum"...

Lustig ist es, eine "RHASSPY language=en" an eine "rhasspy -p de" zu koppeln.

Gruß Jens

[Beta-User]

Lustig ist es, eine "RHASSPY language=en" an eine "rhasspy -p de" zu koppeln.

klingt so, als hättest du das mal ausprobiert...?
Wenn es wirkt, wie ich vermute, klingt es manchmal (?) lustig...

Ein Punkt mehr, eine eigene MQTT-Instanz pro Sprache aufzumachen.

Prinzipiell habe ich auch die Vermutung, dass so eine Empfehlung an sich berechtigt wäre. Nur: Erzwingen will ich das nicht, denn es kommt bestimmt sonst "morgen" jemand um's Eck, der kreativer ist wie meine Gedankenwelt...

Also sollte alles, was mit "not recognized" zu tun hat, durch Konfiguration durch den "Administrator" beeinflussbar sein.

Diese Themenkreise habe ich dazu bisher wahrgenommen:
1. Rückmeldung an den Sprecher: "so geht es nicht"
2. Logging entsprechender "Sätze"
3. "Weiterverarbeitung" (bis hin zur Ergänzung der sentences.ini)

Die Punkte 1 und 2 wären (dem Bauchgefühl nach) relativ einfach* per "tweak" einzubauen, und bei 3 wird es vermutlich sehr schnell individuell. 3 könnte man daher als Alternative zu 1 als "Unterform" von "handleCustomIntent" aufgefasst werden, und ich wäre fast geneigt, das (also diese (optionale!) Umleitung) direkt einzubauen.

* Ein Problem bleibt dabei aber: "not recognized" kann (!) auch vorkommen, wenn ein Satz an sich bekannt, der betreffende Intent aber grade deaktiviert ist (über "intent filter" global bzw. für die laufende Sitzung)... Innerhalb einer laufenden Sitzung sollte dann vermutlich keine "externe"  Verarbeitung angestoßen werden. Wie wir mit diesen Fällen allerdings umgehen sollten, war eine der seit längerem ungeklärten Fragen, und ich habe bis dato auch noch keine für mich selbst halbwegs schlüssige Antwort gefunden...

[drhirn]

Übrigens: https://www.amazon.science/blog/amazon-releases-51-language-dataset-for-language-understanding