Нет, вы получите именно «Yes, pineapplesis the best!».
Смотрите, у нас в dialogflow есть entity $fruit примерно такого вида:
entity — синонимы
«Pineapples» — «pineapple»
«Cherries» — «cherry»
«Coconuts» (Их тоже считают фруктами!) — «coconut», «coco»
Даже если вы скажете «Coco is the best!», то в качестве распозанной entity $fruit вы получите «Coconuts». Это так называемая reference form.
Если вы хотите получить именно ту форму, которую сказал пользователь, то вам нужно использовать $fruit.original. Тогда вы получите именно синоним. В случае с ананасом — «pineapple». Другое дело, что тогда ваш ответ должен быть готов к тому, что это может быть как единственная форма, так и множественная. И ответы «is the best» / «are the best» в таком случае вам не подойдут
maxzhurkin, спасибо большое что заметили!
Изначально, я часть примеров сделал на английском, чтобы показать сравнение использования entity на английском и русском. Мне показалось это интересным в процессе перехода написания приложения с английского на русский.
Перед публикацией было решено перевести эту часть и смысл потерялся. Сейчас я переписал примеры на русский и мы обновили статью.
Если интересно, вот изначальный пример про фрукты:
П: "Pineapples are the best"
A: "Yes, pineapples are awesome!"
В этом примере у нас есть entity: "Pineapples"
Но что если пользователь говорит "Pineapple"? Мы можем добавить синоним.
П: "I like pineapple"
A: "Yes, pineapples are awesome!"
По умолчанию используется reference form — т.е. именно исходная форма entity, не синонимы. Именно поэтому приложение не говорит "pineapple are awesome!"
Стоит это также учитывать при написании ответов. Если бы у нас был ответ "Yes, $fruit is the best!", то мы бы получили следующее:
П: "I like pineapple"
A: "Yes, pineapples is the best!"
Вы про взаимодействие с android приложением через App Actions, верно?
Насколько я понимаю, App Actions не позволяют сделать кастомный intent. Есть набор частых действий/запросов, которые совершают пользователи, и ваше android приложение может быть предложено, например, при выделении текста, если оно может им как-то в этом помочь.
И опять же, насколько я понял, они пока не связаны напрямую с ассистентом и голосовыми командами. Это скорее такие shotcut'ы внутри самого Android.
Если мы говорим про гугл ассистента и приложения для него (Action), то там ситуация похожая — пользователь просит шутку, и если ваш Action поддерживает соответствующий intent (actions.intent.GET_JOKE), то ассистент может предложить именно ваш Action и пользователь может перейти в ваше приложение и общаться с ним.
Так что в целом вы правы.
Но мне кажется, можно построить все это и иным образом.
Вы можете сделать свое приложение для ассистента (Action), общаясь с которым, пользователь будет отдавать команды своим умным дверям. И получится что у вашего сервиса теперь есть 2 точки входа — android приложение и ассистент.
Если же вам нужно перейти в мобильное приложение, то можно внутри ассистента запросить устройство (surface), у которого есть экран — например, android устройство с ассистентом. И уже там отобразить карточку с deeplink'ом в android приложение.
Ребят, спасибо за статью, интересно!
Сколько у вас в итоге весит моделька?
Если оптимизировали для tf-lite под мобильные, то расскажите насколько уменьшилась :)
Есть такое дело. Есть и другие решения для синхронизации буфера, они похожи в том, что нужно поставить приложение на оба устройства и затем связать их.
Когда используется какой-то основной, желательно личный девайс — это не проблема, да и дополнительные плюшки наверное пригодятся.
Когда же множество устройств используется разными людьми (QA + dev отделы), это может быть не удобным. С adb все проще: достаточно подключить телефон и нажать кнопку.
Тут кому что удобней :)
Выглядит интересно, не знал! ADB поддерживает ограниченный набор символов, здесь же эта проблема должна решиться.
Правда нужно будет установить отдельное приложение и, как я понял, поставить хотя бы часть зависимостей от KDE. Если нет необходимости подключать разные телефоны и используется GNU/Linux, то это может быть неплохим решением.
Смотрите, у нас в dialogflow есть entity $fruit примерно такого вида:
entity — синонимы
«Pineapples» — «pineapple»
«Cherries» — «cherry»
«Coconuts» (Их тоже считают фруктами!) — «coconut», «coco»
Даже если вы скажете «Coco is the best!», то в качестве распозанной entity $fruit вы получите «Coconuts». Это так называемая reference form.
Если вы хотите получить именно ту форму, которую сказал пользователь, то вам нужно использовать $fruit.original. Тогда вы получите именно синоним. В случае с ананасом — «pineapple». Другое дело, что тогда ваш ответ должен быть готов к тому, что это может быть как единственная форма, так и множественная. И ответы «is the best» / «are the best» в таком случае вам не подойдут
maxzhurkin, спасибо большое что заметили!
Изначально, я часть примеров сделал на английском, чтобы показать сравнение использования entity на английском и русском. Мне показалось это интересным в процессе перехода написания приложения с английского на русский.
Перед публикацией было решено перевести эту часть и смысл потерялся. Сейчас я переписал примеры на русский и мы обновили статью.
Если интересно, вот изначальный пример про фрукты:
В этом примере у нас есть entity: "Pineapples"
Но что если пользователь говорит "Pineapple"? Мы можем добавить синоним.
По умолчанию используется reference form — т.е. именно исходная форма entity, не синонимы. Именно поэтому приложение не говорит "pineapple are awesome!"
Стоит это также учитывать при написании ответов. Если бы у нас был ответ "Yes, $fruit is the best!", то мы бы получили следующее:
Насколько я понимаю, App Actions не позволяют сделать кастомный intent. Есть набор частых действий/запросов, которые совершают пользователи, и ваше android приложение может быть предложено, например, при выделении текста, если оно может им как-то в этом помочь.
И опять же, насколько я понял, они пока не связаны напрямую с ассистентом и голосовыми командами. Это скорее такие shotcut'ы внутри самого Android.
Если мы говорим про гугл ассистента и приложения для него (Action), то там ситуация похожая — пользователь просит шутку, и если ваш Action поддерживает соответствующий intent (actions.intent.GET_JOKE), то ассистент может предложить именно ваш Action и пользователь может перейти в ваше приложение и общаться с ним.
Так что в целом вы правы.
Но мне кажется, можно построить все это и иным образом.
Вы можете сделать свое приложение для ассистента (Action), общаясь с которым, пользователь будет отдавать команды своим умным дверям. И получится что у вашего сервиса теперь есть 2 точки входа — android приложение и ассистент.
Если же вам нужно перейти в мобильное приложение, то можно внутри ассистента запросить устройство (surface), у которого есть экран — например, android устройство с ассистентом. И уже там отобразить карточку с deeplink'ом в android приложение.
Сколько у вас в итоге весит моделька?
Если оптимизировали для tf-lite под мобильные, то расскажите насколько уменьшилась :)
Когда используется какой-то основной, желательно личный девайс — это не проблема, да и дополнительные плюшки наверное пригодятся.
Когда же множество устройств используется разными людьми (QA + dev отделы), это может быть не удобным. С adb все проще: достаточно подключить телефон и нажать кнопку.
Тут кому что удобней :)
Правда нужно будет установить отдельное приложение и, как я понял, поставить хотя бы часть зависимостей от KDE. Если нет необходимости подключать разные телефоны и используется GNU/Linux, то это может быть неплохим решением.