Jak radzicie sobie z różnorodnością zapytań o to samo do jolki, np:
czujnik “temperatura na zawnątrz”
komenda: jaka jest temperatura na zewnątrz - działa, natomiast
komenda: jaka jest temperatura na dworze - fajnie byłoby żeby również działała itd.
czujnik “temperatura Kacper”
komenda: jaka jest temperatura Kacper - działa, natomiast
komenda: jaka jest temperatura w pokoju Kacpra - nie zostanie rozpoznana
światło “salon”
komenda: zapal światło salon - jest ok, ale
komenda: zapal światło w salonie - już nie
Fajnie by było gdyby do sensora, światła itd. można by było dodawać kilka nazw “aliasów” które byłyby brane pod uwagę.
Aliasy to dobry pomysł, tak jest w Google Home itd… bo nikt nie pamięta dokładnie komendy. Pracujemy już nad tym.
Pewne rzeczy dopasowujemy wyrażeniami regularnymi z jakimś prawdopodobieństwem (teraz 85%) i to czasami działa, ale czasami to nadal szukanie igły w stogu siana.
W idealnym rozwiązaniu trzeba by było mieć więcej danych i robić wykrywanie intencji nie na podstawie wyrażeń regularnych, ale na podstawie informacji zwrotnej, na zasadzie → “napisz, co chciałeś zrobić, jak powiedziałeś xxxx”.
Ale wróćmy do aliasów.
W ostatniej aktualizacji dodaliśmy możliwość łatwego definiowania komend w interfejsie - wystarczy nazwę automatyzacji poprzedzić słowem “Jolka: …” tu masz dokładny opis jak to działa:
Przykład z życia
Załóżmy, że chcesz o godzinę pytać nie komendą: “godzina” czy “która godzina” itp. ale np. komendą → “która na osi”. Jolka tego nie rozumie. Żeby zrozumiała robisz tak:
dodajesz automatyzację o nazwie “Jolka: która na osi”
dodajesz w automatyzacji akcję → process
akcja ‘‘process’’ to jest to, co robi Jolka, jak słyszy/dostaje komendę, w tej akcji dodajesz tekst → komendę którą rozumie Jolka → “która godzina”
PS
teraz wystarczy, że zrobimy kolejny krok i zamiast “Jolka: która na osi” zaczniemy dodawać coś w stylu “Jolka: która na osi; jaki mamy czas; zegarek”
czyli przedzielamy nazwę średnikiem i już mamy aliasy
(jeszcze nie wiadomo czy tak to docelowo rozwiążemy - testujemy to i zastanawiamy się jak to zrobić najprościej)
PS2
możemy też iść dalej
“Jolka: która na osi; jaki mamy czas; zegarek; what time is it”
i Jolka będzie poliglotką
PS3
Pierwsza Jolka była “trenowana” na platformie wit.ai, mieliśmy kilka intencji wytrenowanych.
Niestety każda zmiana powodowała problemy z działaniem - dodawaliśmy “włącz światło” i Jolka przestała rozumieć “włącz radio zet” które już doskonale znała, itd…
Nie mniej jednak to, co robi wit.ai (projekt FB) jest bardzo ciekawe, może jeszcze do tego wrócimy i zrobimy kolejne podejście, żeby zastosować wit.ai jako silnik do definiowania intencji w AIS.
Widziałem waszą nową funkcją “Dodawanie komend”, spore ułatwienie, natomiast nie do końca chciałem tworzyć nową automatyzację dla każdego możliwego scenariusza.
Natomiast nie wiedziałem o możliwości definiowania wielu możliwości w jednej automatyzacji, to bardzo ułatwi sprawę, przynajmniej tymczasowo, czekam na rozwój tematu z waszej strony.
Nie do końca mi działają wasze komendy w nowej funkcjonalności, dodawanie ich poprzez automatyzacje.
Dodałem sobie przykładową automatyzację:
Jolka: włącz światło w jadalni; zapal światło w jadalni
(najwięcej mam problemów z jadalnią poprzez wbudowane polecenia)
po wywołaniu polecenia nie przełącza światła tylko włącza albo wyłącza automatyzację
czy coś robię nie tak, oczywiście w automatyzacji dodane:
akcja: wywołanie usługi: light.turn_on “lught jadalnia”
akcja: wywołanie usługi: ais_ai_service.say_it “już włączam”
Maiłem tak raz czy dwa razy -zamiast wykonać automatyzację wyłączało lub włączało ją Ale to było losowe - nic nie zmieniałem i w końcu Jolka załapała. Sprawdź jeszcze.
Było to kiedyś w dokumentacji; taki przykład był podany:
conversation.yaml
intents:
WhenEOD:
- ile do końca pracy
- kiedy koniec pracy
- kiedy do domu
intents.yaml
WhenEOD:
speech:
text: Nie wiem, zapytaj szefa :)
action:
service: ais_ai_service.say_it
data_template:
text: "Jest {{ states.sensor.time.state }}. Nie wiem, zapytaj szefa :)."
