Modulentwicklung für Rhasspy Sprachassistent

Begonnen von drhirn, 11 März 2021, 15:59:50

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: drhirn am 10 Mai 2022, 12:09:02
Übrigens: https://www.amazon.science/blog/amazon-releases-51-language-dataset-for-language-understanding
Vielleicht trägst du den Link noch in pah's "Testsuite-Thread" ein? (Wobei mir auf die Schnelle nicht klar ist, was da alles in den Materialien drin ist, die da verlinkt sind).


Zitat
"wie spät ist es jetzt" wird nicht erkannt, weil "jetzt" [...]
Zitat von: Prof. Dr. Peter Henning am 10 Mai 2022, 12:56:55
ist ein typisches Beispiel für einen Satz, der ohne Kontext nicht interpretierbar ist. Das kann man mit Amazon Alexa gut ausprobieren
"Alexa, wie spät ist es jetzt" ==> aktuelle Uhrzeit
"Alexa, wie früh ist es" ==> aktuelle Uhrzeit
"Alexa, wie spät ist es morgen" ==> Datum von morgen
"Alexa, wie früh ist es morgen" ==> "Das könnte Deine Frage beantworten..." dann Datum von morgen
"Alexa, wie früh ist es vorgestern" ==> "Das weiß ich leider nicht"
"Alexa, wie spät ist es jetzt in Timbuktu" ==> Datum und Uhrzeit in Timbuktu

Hier wird also offenbar zunächst fest substituiert "wie spät" ==> Ausgabe Zeit/Datum.
Dann aber ist ein Zeitpunkt und ein Ort festzustellen, und dafür gibt es default-Annahmen.
Vermutlich ist das hier besser aufgehoben...

Anscheinend spielt da auch noch eine gewisse "Trefferwahrscheinlichkeit" mit rein, was man an den Variante 3 und 4 (bzw. auch 5) ganz gut ablesen kann. 3 +4 gingen vielleicht gerade so noch mit einer reinen Textanalyse und "Nähebetrachtung", aber für logische Implikationen ala "das kann eigentlich nicht gemeint sein", braucht es etwas mehr.

Soweit ich das bisher (im Rhasspy-Forum) überblicken kann, gibt es außer FHEM keine "Musterlösung", das die "confidence"-Angaben auch mit berücksichtigt 8) .

Das Problem mit der semantischen Nähe und der Frage, wie eine Eingabe _wahrscheinlich_ zu verstehen sein soll, war letztlich mit der Grund, warum jetzt die "Choice"-Varianten zusammengeführt worden sind: Sprachlich sind alle Arten einer Auswahl-Antwort ähnlich, sie unterscheiden sich nur in den Schlüsselwörtern, also danach, was (ggf. mit "kleinem Kontext" wie "im" für einen Raum) an "Auswahlwörtern" rund um den (kurzen!) eigentlichen "Content" rum passiert, und zudem ist die Wahrscheinlichkeit relativ hoch, dass ein "normaler menschlicher Sprecher" ggf. auch Dinge wiederholt (oder klarstellt bzw. korrigiert), die vorher ggf. eigentlich schon "klar" waren.

Übrigens bin ich nicht sicher, ob ich heute nochmal eine Unterscheidung zwischen den Einzel- und Gruppenintents machen würde - genau aus dem Grund, dass es beim Sprechen kaum einen Unterschied macht, und uU. dem Sprecher auch gar nicht klar ist, ob er jetzt eigentlich grade eine Gruppe anspricht oder ein einzelnes Device. Tendenziell würde ich versuchen wollen, das mittelfristig wieder zusammenzubringen bzw. "Umleitungspfade" vorzusehen, z.B. für den Fall, dass
- kein Einzelmatch (im Raum) klappt,
- aber eine Gruppenbezeichnung im Raum passen würde.

Sind aber wieder möglicherweise schwerwiegende Eingriffe in das Verhalten des Moduls... (Aber wenn, dann tendenziell jetzt dann...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Prof. Dr. Peter Henning

#1411
Das MASSIVE-Dataset von Amazon hat eine Mitarbeiterin schon gefunden, wir überlegen derzeit, ob wir bei der Konferenz etwas einreichen. In meinem "Test Suite-Thread" habe ich die deutschen Sprachdaten aus MASSIVE kommentiert (und drhirn den Credit für den ersten Hinweis in FHEM gegeben).

Ist aber sehr gemischte Qualität. Ich werde meine Jeannie niemals fragen "Alles fit im Schritt?".


LG

pah

Beta-User

Zitat von: Prof. Dr. Peter Henning am 10 Mai 2022, 14:55:59
Ist aber sehr gemischte Qualität. Ich werde meine Jeannie niemals fragen "Alles fit im Schritt?".
Na ja, die Geschmäcker sind verschieden, und einen "Flirt-Chatbot" zu bauen, der auch anzügliche Witze macht, darf gerne jemand anderes übernehmen, ist auch nicht so meins...

Nicht so meins ist auch das Datenformat. Sollte es für sowas dann nicht eine Art "Intermediär" geben, den man "zeilenweise" abrufen und "füttern" kann? (Eigentlich hatte ich nicht die große Neigung, mich da in irgendein (für mich) obskures Datenformat einzulesen...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Wie versprochen: Hier eine Erkenntnis.

"Welches Szenen kennt die Beleuchtung?"
Rhasspy liest mir dann brav alle Szenen vor, die ich bei dem Device habe. Sind ein paar. Sobald das erledigt ist, bekomme ich die "Fehler-WAV" vorgespielt und RHASSPY meint, da habe etwas zu lange gedauert. Da wird offenbar eine Antwort erwartet?


hermes/dialogueManager/intentNotRecognized

{"sessionId": "wohnzimmer.pc-porcupine_raspberry-pi-5ed6c5a7-f699-4035-be3a-53aa8ca46260", "siteId": "wohnzimmer.pc", "input": "<unk> lass <unk> abbrechen <unk> nimm alles aus", "customData": "Computerlicht,Alles an,Leselicht,Fernsehlicht,Nachtlicht,Schlummerlicht,DunklesFernsehlicht,Esslicht,Alles aus"}

Beta-User

 ;D ...wie angedeutet...: Scheint noch nicht "fertig" zu sein...

Das "Get" in "SetScene" ist als Frage-Antwort-Spiel konzipiert, daher der timeout. Weiß noch nicht, ob das (in Kombination mit dem sentence) glücklich ist...
Hinzu kommt, dass die Antwort uU. recht lang ist, und von daher hier möglicherweise der timer abläuft, bevor man sich überhaupt entscheiden konnte. (Den üblichen timeout für diesen Anwendungsfall einfach zu erhöhen (verdoppeln? Rechnen mit der Zahl der Szenen?), wäre keine große Übung).

Man kann die Anfrage übrigens auch über GetState machen, dann ist es eine reine Info, kann aber dafür auch einfach "alles in einem bestimmten Raum" (Device-los; hoffe ich zumindest ::) )...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Das ganze wird ja via tts/say ausgegeben. Geht das vielleicht auch anders? Damit der dialogueManager wartet?

Aber eigentlich macht da ein "get" keinen Sinn, das geht ja wirklich mit GetState. Aber mit einem "set" und einer Nachfrage, wenn da was nicht verstanden wird, haben wir das Problem trotzdem.

Beta-User

Der Timeout kommt nicht vom dialogueManager, sondern aus dem Modul (ca. #5113). Von daher wäre es nicht das Thema, dort z.B. sowas reinzuschreiben:
return setDialogTimeout($hash, $data, _getDialogueTimeout($hash)*1.5, $response, $toActivate);

Und irgendwie kommt es mir dunkel so vor, als wäre der Plan gewesen, den sentence in die Richtung umzuschreiben, dass sprachlich besser zum Ausdruck kommt, das der Sprecher tatsächlich (am Ende) eine Szene schalten will, aber eben noch nicht genau weiß, welche. In diesem Fall ist es dann auch nicht ganz unwichtig, welchen Intent der Sprecher ursprünglich mal angesprochen hatte, dahin geht dann nämlich prinzipiell (aus "Choice" heraus, war aber bei gesplitteten Choice-Typen auch schon so) auch die Antwort. Könnte man natürlich irgendwie vor dem User verbergen, aber das nimmt kaum Komplexität raus...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

...etwas anderes Thema:
Nachdem ich gestern nochmal drübergestolpert bin, dass der Code keine Antwort bei "intentNotRecognized" liefert, bin ich nochmal über die möglichen Ursachen gegangen - und habe was gefunden, allerdings an anderer Stelle wie vermutet ::) .

Update ist im Nachbarthread zu finden.

Und zumindest nach dem list müßte es auch möglich sein, an der Stelle (vorrangig zur Standardantwort) eigenen Perl-Code anzuflanschen. Müßte beispielsweise so klappen:
attr RHASSPY rhasspyIntents intentNotRecognized=myIntentNotrecognized(NAME,siteId,input)

Damit sollte sich dann auch ggf. der Antwort-Code aus https://community.rhasspy.org/t/whats-the-craziest-thing-you-can-or-cannot-do-with-rhasspy/3648/26 anflanschen lassen (falls es nicht bereits Beispiele gibt, wie man aus FHEM heraus z.B. alexa anfragt. Habe bisher nicht nach sowas gesucht...).

Eventuell braucht man dann auch noch sowas wie einen "asynchronen call", um die session offen zu halten und später die Antwort einschleusen zu können.



Bliebe dann die Frage, wie man am anderen Ende (also auf der Rhasspy-Seite) sinnvollerweise die STT-Einstellungen konfiguriert, damit man wirklich eher "frei" sprechen kann und nicht zwanghaft bei irgendwas landet, was in sentences.ini angelegt war. Ist Neuland für mich - meine Versuche, "open transcription" zu aktivieren haben in endlosen trainings-sessions geendet... Also falls jemand einen "schnellen Tipp" hat: her damit!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

JensS

#1418
Zitat von: Beta-User am 17 Mai 2022, 10:06:40
Eventuell braucht man dann auch noch sowas wie einen "asynchronen call", um die session offen zu halten und später die Antwort einschleusen zu können.

Was in der Theorie einfach ist, lässt sich offensichtlich praktisch nicht umsetzen.
Mit der Wakeworderkennung wird mit hermes/dialogueManager/startSession eine neue Session erzeugt. In dem Standardszenario ist eine Option sendIntentNotRecognized nicht vorgesehen. Auch ein passender Startparameter der Wakeword- und Dialogengine ist nicht vorhanden. Somit endet die Session automatisch mit hermes/dialogueManager/endSession. Man müsste den Rhasspy-Code editieren, was natürlich den Usern nicht zuzumuten ist.
Momentan tue ich mich schwer dabei, eine verständliche Frage für das Rhasspy-Forum zu formulieren...

Gruß Jens

https://github.com/rhasspy/rhasspy-dialogue-hermes/blob/0d697cb1631880688fd484177f1cdf50351f4a3e/rhasspydialogue_hermes/__init__.py#L652
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

Beta-User

Hallo zusammen, habe eben eine neue Version ins svn geschubst - kann sein, dass die an der einen oder anderen Stelle wieder etwas "experimentell" ist....

Verbessert worden sollte v.a. sein
- Rückwärtssuche nach "tauglichen" Geräten anhand des Namens (mein doppeltes verstärkerlein... Kann sein, das man das noch weiter verbessern kann, indem man auch noch die Kombination von "intent" und "typ" auswertet)
- die Rückmeldung bei intentNotRecognized. Das ist jetzt nicht mehr "experimentell", sondern default, wer keine Rückmeldung will, muss ggf. den dazugehörigen Satz auf "leer" stellen ;) .

Zitat von: JensS am 18 Mai 2022, 18:04:14
Was in der Theorie einfach ist, lässt sich offensichtlich praktisch nicht umsetzen.
Mit der Wakeworderkennung wird...
Weiß nicht, ob das unzulässige "Brechstange" ist, aber es müßte m.E. gehen, ggf. die alte Sitzung wieder aufzumachen. RHASSPY kann ggf. die Sitzungsdaten speichern...

Was im Moment noch nicht so richtig klappen wollte, wäre erst eine "Choice" und dann eine Bestätigung. Muss ich mir ansehen, das scheint mir aber auch kein neues Thema zu sein, sondern eher ein bisher unentdecktes.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

JensS

#1420
Zitat von: Beta-User am 18 Mai 2022, 19:13:58
Weiß nicht, ob das unzulässige "Brechstange" ist, aber es müßte m.E. gehen, ggf. die alte Sitzung wieder aufzumachen...

Würde ich so sehen. Lieber die Alte kommentarlos enden lassen und mit hermes/dialogueManager/startSession eine Neue starten. Natürlich ware es schöner, eine neue query in dir Session zurück zu geben.

Zitat
Was im Moment noch nicht so richtig klappen wollte, wäre erst eine "Choice" und dann eine Bestätigung. Muss ich mir ansehen, das scheint mir aber auch kein neues Thema zu sein, sondern eher ein bisher unentdecktes.
Wie soll da der komplette Ablauf aussehen?
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

Beta-User

#1421
Zitat von: JensS am 18 Mai 2022, 22:18:53
Würde ich so sehen. Lieber die Alte kommentarlos enden lassen und mit hermes/dialogueManager/startSession eine Neue starten. Natürlich ware es schöner, eine neue query in dir Session zurück zu geben.
Wie üblich muss man sich die Details dann mal näher ansehen. Allerdings macht es (so nicht intentFilter im Spiel ist) m.E. wenig Sinn, eine neue query zu machen (das Ergebnis war ja grade "not recognized"), sondern wenn, dann geht es m.E. darum, dass man "nach dem Spiel" woanders anfragt, ob z.B. Babble was damit anfangen kann, oder "alexa", oder.... Und wenn dann von da eine "Heureka"-Rückmeldung kommt (es konnte eine Antwort auf die Frage gefunden oder eine Aktion ausgeführt werden), dann muss halt irgendwie die Antwort an den betreffenden Satelliten zurückkommen (und ggf. die Sitzung (? oder nur das Mikrofon?) für weitere Rückfragen offen gehalten werden.

Zitat
Wie soll da der komplette Ablauf aussehen?

Vorausgesetzt, die Rahmenbedingungen sind entsprechend (mehrere gleich benannte Devices, anderer Sprecher-Raum wie beide Devices, Bestätigung erforderlich):
ZitatU: Schalte den Verstärker an!
R: Wohnzimmer oder Esszimmer?!?
U: Esszimmer...
R: Bitte bestätige das
U: Ja mach!
R: OK

So der Soll-Ablauf. Im Moment kommt statt des "OK" halt die Rückmeldung, dass keine Bestätigung erwartet wird...
EDIT: Vermutlich habe ich die betreffenden Stellen identifiziert, die dafür verantwortlich waren. Man muss bei asynchronem Datengeschubse wirklich aufpassen, was man wo wie lange vorhalten sollte...




Weiteres feature der neuen Version:
Für den key "Value" wird ein "custom-flaot-converter" angwandt, also "5 . 77" wird immer zu "5.77". (Thx. @drhirn für das präventive Rausnehmen des bisherigen Codes).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Zitat von: Beta-User am 19 Mai 2022, 09:31:27
Wie üblich muss man sich die Details dann mal näher ansehen. Allerdings macht es (so nicht intentFilter im Spiel ist) m.E. wenig Sinn, eine neue query zu machen (das Ergebnis war ja grade "not recognized"), sondern wenn, dann geht es m.E. darum, dass man "nach dem Spiel" woanders anfragt, ob z.B. Babble was damit anfangen kann, oder "alexa", oder.... Und wenn dann von da eine "Heureka"-Rückmeldung kommt (es konnte eine Antwort auf die Frage gefunden oder eine Aktion ausgeführt werden), dann muss halt irgendwie die Antwort an den betreffenden Satelliten zurückkommen (und ggf. die Sitzung (? oder nur das Mikrofon?) für weitere Rückfragen offen gehalten werden.

Ich hätte das spontan eher als "Fire and Forget" behandelt. Und v.a. optional. Das Progrämmchen, dass dann die nicht erkannten Intents behandelt, muss sich selber um Rückmeldungen kümmern. RHASSPY ist zu dem Zeitpunkt raus.

Zitat(Thx. @drhirn für das präventive Rausnehmen des bisherigen Codes).
Hab nichts gemacht. Nur den Hinweis gelöscht, dass der Code nicht funktioniert. Tut er nämlich schon.

Beta-User

Zitat von: drhirn am 19 Mai 2022, 09:38:48
Ich hätte das spontan eher als "Fire and Forget" behandelt. Und v.a. optional. Das Progrämmchen, dass dann die nicht erkannten Intents behandelt, muss sich selber um Rückmeldungen kümmern. RHASSPY ist zu dem Zeitpunkt raus.
Der Code ist heute (hoffentlich) so strukturiert, dass man einen "custom intent" "intentNotRecognized" ansteuern kann. Wie der dann agiert, ist komplett offen, und im Prinzip auch "fire and forget". Verhindert wird damit in jedem Fall, dass die Standardantwort kommt.
ABER: Man kann zum einen natürlich eine passendere Antwort darüber generieren ("einen Moment, ich frage mal beim alphabet") oder Rückmeldungen dazu von innerhalb aufgerufenem Code (? BabbleDoIt()) weiterleiten, einschließlich der Aufforderung, die Sitzung offen zu halten (was ggf. Probleme machen könnte).
Muss man sich ansehen.

Offen ist auf jeden Fall, wie man damit umgehen müßte, wenn externe Dienste angezapft werden. Das läuft sinnvollerweise asynchron, und die Rückmeldung müßte dann wieder der Sitzung zugeordnet werden, damit auch die Ausgabe wieder an dem Satelliten erfolgt, den der betr. User für die Eingabe genutzt hatte.
Ich habe dazu im Moment keine konkreten Pläne, u.a. auch deswegen, weil mir im Moment noch kein Code über den Weg gelaufen ist, über den man aus FHEM heraus z.B. irgendwelche "handelsüblichen Anfragen" an welchen Dienst auch immer stellen (und verarbeiten) könnte.

Zitat
Hab nichts gemacht. Nur den Hinweis gelöscht, dass der Code nicht funktioniert. Tut er nämlich schon.
Hmm, bei mir wollte das mit dem customConverter nicht, die sentences wollte Rhasspy nicht akzeptieren. Hatte aber bisher auch nicht die Muße, da nochmal nachzusehen, warum es nicht will wie es soll (abgesehen vom Checken, welche Art Zeilenumburch die Datei enthält). Ist auch nicht wirklich wichtig, im Zweifel hält doppelt genäht besser...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Zitat von: Beta-User am 19 Mai 2022, 10:07:23
Offen ist auf jeden Fall, wie man damit umgehen müßte, wenn externe Dienste angezapft werden. Das läuft sinnvollerweise asynchron, und die Rückmeldung müßte dann wieder der Sitzung zugeordnet werden, damit auch die Ausgabe wieder an dem Satelliten erfolgt, den der betr. User für die Eingabe genutzt hatte.
Ich habe dazu im Moment keine konkreten Pläne, u.a. auch deswegen, weil mir im Moment noch kein Code über den Weg gelaufen ist, über den man aus FHEM heraus z.B. irgendwelche "handelsüblichen Anfragen" an welchen Dienst auch immer stellen (und verarbeiten) könnte.

Eigentlich könnte man RHASSPY überhaupt außen vor lassen. Nicht erkannte Intents könnte ja z.B. auch einfach ein Python-Progrämmchen gleich direkt bearbeiten.
Aber, wenn schon RHASSPY im Spiel ist, hätte ich mir gedacht, dass man den Input einfach weiterleitet. Mit siteId. Wie auch immer. Um den Rest kümmert sich dann wer anderer. Auch um die Rückmeldung an die richtige Adresse.