Про целевую аудиторию: сугубо с моей персональной точки зрения, это либо те, кому нужна полная автономность (т.е. встраиваемые устройства и десяток-другой команд), либо те, кому хочется потратить свое время и полностью контролировать то, что происходит при голосовых командах.
Есть «магазин приложений», где можно взять уже готовые модели, созданные компанией либо обычными энтузиастами. Как раз пример с музыкой на сегодня существует (не уверен, в публичном ли уже доступе), проиндексировано порядка пары тысяч композиций.
То есть, говоря о втором примере целевой аудитории, предполагается такой конструктор, где можно как собрать всё самому с нуля, так и загрузить уже предоставленное кем-то, что сильно снизит трудозатраты.
Вопрос про обновление, действительно, мне видится самым больным. Работа полностью оффлайн накладывает сильные ограничения. Даже для банального «какая погода сейчас в Париже?» надо иметь доступ к интернету, пусть само NLU и происходит оффлайн. Да и музыку просто так не запустить, даже если точно понять, что именно надо запускать — нужна интеграция с проигрывателем. Работы в этом направлении тоже ведутся, но тут я не могу сказать больше.
Второй козырь (помимо оффлайн работы) — работа с персональными данными. Они никуда не утекут просто потому, что не могут (оффлайн же всё). Насколько это важнее потенциально более удобного использования условной Алексы — решать каждому самому. В моем понимании, «в светлом будущем» Snips видит себя как полноценный игрок на рынке голосовых помощников, за счет магазина типичных приложений, а также интеграции со сторонними железками типа колонок, телевизора, стиралки и тд.
И про тренировку моделей онлайн: сейчас проверяется работоспособность federated learning для распределенного обучения непосредственно на устройствах, proof-of-concept работает.
Вот именно это snips.ai (который я ниже упоминал) делает. Полноценное оффлайн распознавание речи, работа на девайсах вплоть до MCU, ну и продвижение с точки зрения «защиты ваших персональных данных».
Не совсем, KN представляет собой куда более узкоспециализированную и ограниченную штуку. А вообще, «давайте сделаем набор случайных несвязанных ad-hoc возможностей» — modus operandi котлина в целом.
Собирает, но без "мелочей" типа invokedynamic (сейчас анонимные классы, по-старинке) и всего остального, что недоступно на текущей андроид jvm.
Возможная аргументация: тогда будет весьма проблематично распостранять библиотеки. Скажем, написал кто-то утилиту под 11 jvm, с ранее несуществующими фичами, залил jar, и при попытке использовать на старой jvm эти самые ранее недоступные фичи будет ошибка. Даже не при попытке, а при подгрузке байткода.
Это решается (можна снова глянуть на пример скалы), но ценой некоторого удобства пользователя. Ну и таких фич немного. Тем не менее, "android-first" развитие, если в 12 jvm выпустят что-то этакое, то котлин очень нескоро будет генерировать соответствующий байткод.
Ещё немного:
1) котлин хочет усидеть на 3 стульях (js, jvm, native) сразу, и это несовместимо с совместимостью с джавой (put intended). Логика простая: появлятся pure kotlin библиотеки, которые будут частично дублировать функционал уже существующих, но их можно будет использовать в мультиплатформенных проектах. Это приведет к расслоению экосистемы, так как все эти библиотеки будут развиваться независимо друг от друга. Что, в свою очередь, убивает совместимость с джавой; речь не про техническую возможность вызвать код, а про удобство этого процесса.
Пример такого расслоения — scala, где либо есть отдельные java-api, либо библиотеку невозможно использовать из джавы. История повторяется?
Само по себе это разделение не является плохой вещью, но исчезает позиционирование языка как «better java». Что, в случае котлина, является основной selling point для не-андроидоводов.
2) туда же корутины и так называемый kotlin-dsl — библиотека, фундаментально построенная на этом, не будет использоваться из джавы. За примером далеко ходить не надо — ktor пишут лучшие котлинисты мира, но java api там нет.
3) mobile-first развитие => отсутствие плюшек из более новых jvm (8+) в сгенеренном байткоде.
Без понятия про регистрацию, если честно. В новом private window, наверное, должно открываться.
Там же много более пространных постов о том, как оно всё работает.
Есть «магазин приложений», где можно взять уже готовые модели, созданные компанией либо обычными энтузиастами. Как раз пример с музыкой на сегодня существует (не уверен, в публичном ли уже доступе), проиндексировано порядка пары тысяч композиций.
То есть, говоря о втором примере целевой аудитории, предполагается такой конструктор, где можно как собрать всё самому с нуля, так и загрузить уже предоставленное кем-то, что сильно снизит трудозатраты.
Вопрос про обновление, действительно, мне видится самым больным. Работа полностью оффлайн накладывает сильные ограничения. Даже для банального «какая погода сейчас в Париже?» надо иметь доступ к интернету, пусть само NLU и происходит оффлайн. Да и музыку просто так не запустить, даже если точно понять, что именно надо запускать — нужна интеграция с проигрывателем. Работы в этом направлении тоже ведутся, но тут я не могу сказать больше.
Второй козырь (помимо оффлайн работы) — работа с персональными данными. Они никуда не утекут просто потому, что не могут (оффлайн же всё). Насколько это важнее потенциально более удобного использования условной Алексы — решать каждому самому. В моем понимании, «в светлом будущем» Snips видит себя как полноценный игрок на рынке голосовых помощников, за счет магазина типичных приложений, а также интеграции со сторонними железками типа колонок, телевизора, стиралки и тд.
И про тренировку моделей онлайн: сейчас проверяется работоспособность federated learning для распределенного обучения непосредственно на устройствах, proof-of-concept работает.
Disclaimer: я там работаю.
Собирает, но без "мелочей" типа invokedynamic (сейчас анонимные классы, по-старинке) и всего остального, что недоступно на текущей андроид jvm.
Возможная аргументация: тогда будет весьма проблематично распостранять библиотеки. Скажем, написал кто-то утилиту под 11 jvm, с ранее несуществующими фичами, залил jar, и при попытке использовать на старой jvm эти самые ранее недоступные фичи будет ошибка. Даже не при попытке, а при подгрузке байткода.
Это решается (можна снова глянуть на пример скалы), но ценой некоторого удобства пользователя. Ну и таких фич немного. Тем не менее, "android-first" развитие, если в 12 jvm выпустят что-то этакое, то котлин очень нескоро будет генерировать соответствующий байткод.
1) котлин хочет усидеть на 3 стульях (js, jvm, native) сразу, и это несовместимо с совместимостью с джавой (put intended). Логика простая: появлятся pure kotlin библиотеки, которые будут частично дублировать функционал уже существующих, но их можно будет использовать в мультиплатформенных проектах. Это приведет к расслоению экосистемы, так как все эти библиотеки будут развиваться независимо друг от друга. Что, в свою очередь, убивает совместимость с джавой; речь не про техническую возможность вызвать код, а про удобство этого процесса.
Пример такого расслоения — scala, где либо есть отдельные java-api, либо библиотеку невозможно использовать из джавы. История повторяется?
Само по себе это разделение не является плохой вещью, но исчезает позиционирование языка как «better java». Что, в случае котлина, является основной selling point для не-андроидоводов.
2) туда же корутины и так называемый kotlin-dsl — библиотека, фундаментально построенная на этом, не будет использоваться из джавы. За примером далеко ходить не надо — ktor пишут лучшие котлинисты мира, но java api там нет.
3) mobile-first развитие => отсутствие плюшек из более новых jvm (8+) в сгенеренном байткоде.