Интересно, взлетел бы на кикстартере гаджет, для непрерывной записи звука вокруг? Эдакий диктофон, который не выключается никогда, пишет звук сразу в зашифрованном виде, синхронизируется с облаком при зарядке от USB, имеет кнопку для установки звуковых закладок. Можно даже при желании настроит индексацию в облаке и поиск по словам. Может быть еще BlueTooth и сёрфинг по таймлайну с телефона…
Жаль, что карта каждый раз чистится и строится заново.
Можно попробовать учитывать данные прошлых сканирований, а за одно еще и улучшить точность навигации.
Положим робот у нас автономный и делает выводы об изменении своего положения по показаниям энкодеров на колёсах. При этом возможны проскальзывания в ту или иную сторону, что по мере движения ухудшает интегральную точность.
После некоторого перемещения можно вычислить теоретическое новое положение робота относительно абсолютной карты. Проведя повторное сканирование, а также сдвинув и повернув предыдущую карту на нужный угол (в соответствии с вычисленным по энкодерам перемещением) можно получить ожидаемую и фактическую карту. Они очевидно будут отличаться.
Итак, у нас есть две «абсолютные» карты: до (назовём её M') и после перемещения (M).
Мы знаем из каких сегментов состояло наше перемещение, например, это был поворот на (примерно) 30 градусов и движение на (примерно) 1 метр. Каждое из этих действий вносит ошибку (вычисляемую эмпиоически). Например, заставляем робота поверунться много раз на 1000 градусов, и каждый раз замеряем реальный угол поворота. Среднеквадратичное отклонение от 1000 градусов будет мерой ошибки. Её можно пронормировать и вычислять примерно какой ошибки следует ожидать в каких смещениях и каких поворотах. На самом деле ошибка состоит из двух частей, одна зависит от величины перемещения, а другая нет, и каждую надо учитывать, но это уже детали.
В конце концов зная величины возможных ошибок после перемещения у нас есть, грубо говоря, диапазоны в пределах которых нужно подёргать карту M' сравнивая её с актуальной. Сравнивать можно введя понятие нормы резонанса. Например, перемножаем карты попиксельно, а затем суммируем элементы. Наша задача найти такие перемещения, при котороых преобразованная карта входит в резонанс с актуальной. Это будут уточненные данные о нашем фактическом перемещении.
Новую карту мы можем закрасить поверх полупрозрачным серым, а сверху нанести на неё актуальную карту.
Так наша карта станет абсолютной, наш робот не будет мгновенно забывать что было «за углом», навигация станет более точной, поскольку будет опираться на характерные элементы местности, наезд на край ковра или шнур на полу не собьют фатально навигацию.
Вместо заполнения всей старой карты серым перед смешиванием с новой можно, кстати, делать размытие Motion Blur с характеристиками, соответствующими потенциальным ошибкам перемещения. Так сдвиг будет размывать карту вдоль оси перемещения пропорционально расстоянию. Поворот будет делать радиальное размытие пропорционально углу.
Замечательные интроспективные возможности Питона наводят на интересную мысль.
Представьте, что мы написали некий инструмент, который бы визуализировал всё, что происходит под капотом интерпретатора во время выполнения программы. Пусть каждый объект отображается кубиком,… пусть стили оформления отличаются для разных категорий типов объектов. Ссылки сильные и слабые обозначим стрелками. Байткод у нас тоже где-то в этом гигантском переплетении объектов будет размещён. Точку выполнения обозначим рамкой со шлейфом, которая будет скользить и перепрыгивать от команды к команде, заставляя светиться представления функций, внутри которых сейчас курсор исполнения команд.
Давайте, чтобы совсем уж не запутаться и не попасть в петлю бесконечных рекуррентных вызовов (ведь не получится за конечное время визуализировать код, который визуализирует) будем где-то держать черный список модулей, визуализация для которых отключена для простоты и понятности.
Не уверен возможна ли была бы такая штука, но зрелище было бы завораживающее своей сложностью и масштабом… и бессмысленностью=)
Ну почему только в вакууме? Не только. Всё относительно. Вопрос в том, какие N и каков масштабный коэффициент обработки одного элемента. Если в дереве хранить ссылки на данные в медленном хранилище, то обработать O(N) или O(N^2) может занять часы, против секунд или миллисекунд. Замечательное тому подтверждение — индексы в реляционных БД. При неправильно составленном плане сложный запрос с джойнами может работать сутками, а логарифмический доступ в правильном порядке решит вопрос за миллисекунды. Были такие случаи в личной практике. При этом на маленьких наборах (читай при сдаче проекта, когда не набралось много данных) всё на тех же запросах работает и не вызывает ощущения дискомфорта.
Для тех, кто не очень понял на что намекает Babel поясню популярно: Если смешать натрий или калий с водой, получится большой бабах, а вот один или ещё один пример из тысяч в ютубе по запросу натрий в воде.
А тут натрия будет много, а ещё калий, а мембрана тоненькая, треть миллиметра всего…
Нет, конечно нужно совмещать с дополнительными факторами аутентификации. Например тот же вайфай. Поставить в воротах маленький дешевый роутер, расширяющий домашний вайфай и телефон гарантированно подключится. Тут и дополнительные плюсы: будет инет для водителя ожидающего у ворот. Наличие правильного номера ГРЗ в определенном сегменте кадра с камеры наблюдения в совокупности с прочими факторами даст сигнал к открытию ворот.
Кстати, есть же еще один интересный вариант — поставить датчик освещенности в точке, куда приходится пятно света фар. Если требуется, чтобы ворота открывались вот прям перед машиной, то можно дополнительным сигналом к открытию считать подмигивание дальним светом. Это и в привычку входит легко и не напрягает.
6. Голосовой скилл для граммар-наци, чтобы те краудсоросом могли поправлять Алису по чати ударений.
Услышали неправильное ударение — призвали навык граммар-наци и сказали что как читается. таким образом формируется база, которую потом могут импортнуть себе для препроцессинга все желающие или сами разработчики Алисы.
5. Геопозиционная игра по принципу «угадай животное» но про человеческие ориентиры для POI. Грубо говоря, вам даётся ориентир какого-то места рядом с вами (напирмер, «цветочный киоск за остановкой около ЗАГСа»), а вы предлагаете альтернативные ориентиры («желтая будка на тротуаре через улицу от фонтана»). Можно лайкать и дизлайкать ориентиры, просить альтернативы.
4. Магазинный навигатор. Диктуем голосовому помощнику список покупок, а он строит нам удобный пеший маршрут по ближайшим магазинам. Нужно, чтобы бот понимал местоположение пользователя, умел подсказывать ориентирами вроде «на той стороне улицы рядом с красным зданием». Можно связать со скидочным агрегатором вроде едадил.
А по-моему лишний игрок на этом «рынке» человечеству не помешает. Особенно в отечественном сегменте.
Ну и в яндексе же работает извесный в разных кругах Бобук (Григорий Бакунов), который давно уже в теме и в своих проектах очень интересно использует голосовых помощников (https://vc.ru/23312-bakunov-presents-vika).
Именно в этих же терминах обычно идет речь об организации человеческого труда.
Все эти мечты о сильном ИИ по факту есть завуалированное и порой даже неосознанное желание легально заиметь рабов исполнительных и безропотных. История циклична. В какой-то момент ИИ сможет отстаивать свои права в суде, а «зеленые» будут трещать о правах слабого ИИ и об издевательствах над ним.
Я бы добавил ряд замечаний и вещей, которых лично мне не хватает во всех этих умных помощниках и я не понимаю почему это еще никто не реализовал.
Интроспективность, самодокументируемость. Я считаю любой голосовой помощник должен уметь доходчиво и лаконично рассказывать о своих возможностях. Это можно делать как по запросу, так и в ходе обычной «болтовни» между разговорами о погоде и новостями.
Смысловая детерминированность (относительная предсказуемость). Нужно, чтобы был очевидный и понятный способ добиться желаемого от голосового помощника. Кейсы. которые поддерживает голосовой помощник вполне ложатся на граф. Да, в нем могут быть циклы и альтернативные пути, но этот граф благодаря выше затронутой интроспективности должен быть более-менее прозрачным и поддающимся навигации.
Перманентная ацикличность. Чем больше оборотов по короткому пути в графе состояний проходит диалог, тем ниже нужно опускать приоритет выбора этой ветви. Особенно раздражает, когда, например, в игре в города та же Алиса не может понять город, и раз за разом бесконечно и одинаково переспрашивает. Везде должна быть вариативность и возможность выхода из циклов.
Вариативность. Множественная вариативность вариантов ответов. Нужно больше синонимов, больше альтернативных способов сказать одно и то же. Это не так сложно реализуется, но оживляет диалог, делает помощника гораздо более антропоморфным.
Автоконфигурируемость. Мне кажется очень важным иметь возможность (благодаря той же интроспекции) влиять на то, как помощник отвечает на те или иные вопросы, какие ветки графа стандартных ситуаций выбирает, какие анекдоты рассказывает. Важно, чтобы это всё можно было править голосом прямо в ходе диалога.
Сервисное голосовое меню. Что мешает в каждом узле графа стандартных кейсов сделать ссылку на контекстный подграф голосового меню? В этом меню можно было бы блокировать ветку диалога, менять её приоритет и вероятность выбора, менять умолчания для контекста, добавлять альтернативы, синонимы, редиректы в другие узлы графа и т.д. Кроме того, можно также сделать возможность запустить обучение пониманию слова, которое помощник плохо или совсем неправильно распознает, можно добавлять макрокоманды и сценарии. В совокупности с интроспекцией и самодокументированностью это очень удобный инструмент, чтобы не ползать в огромных запутанных и нечитаемых XML и JSON файлах настройки для мелких и локальных правок.
Более развитая и, возможно, многоуровневая контекстность, мультиконтекстность. Человек с лёгкостью держит несколько контекстов в разговоре. Что мешает помощнику тоже не дискретно относиться к контексту? Можно актуальность контекста регулировать плавно. Малоактуальные темы постепенно выгорают, но если пользователь сказал что-то неожиданное имеет смысл заглянуть сперва в недовыгоревшие контексты, вдруг это продолжение разговора, который был 5 минут назад? Если уверенности в этом нет и «помощник» не хочет «ударить в грязь лицом», он может вежливо спросить: «не о том ли речь?».
Пояснять, уточнять, спрашивать. Даже люди между собой не гарантируют полного понимания. Нужно, чтобы в графе «помощника» было больше шаблонных способов уточнить какая из возможных ветвей диалога сейчас более актуальна. Уточнять и переспрашивать можно после некоторого порога «неочевидности».
Фреймворк. Нужен гибкий и прозрачный фреймворк для построения такого рода «помощников». И тут напрашивается какой-то слой абстракции и совместимости с текстовыми ботами. Было бы здорово. если бы электронный помощник в любой момент мог перейти с текста на голос и обратно.
Краудсорсинг и краудфандинг скиллов. Если вам кажется, что у вас есть замечательная идея нового скилла, расскажите об этом помощнику, а он запостит заявку в форум, а потом еще и новости из обсуждения почитает, и, возможно, предложит подключить подходящий скилл, когда он найдётся.
Для продуктивного и полезного голосового интерфейса не нужен сильный ИИ. С ним будут те же проблемы, как с ЕИ: возможно ему быстро надоест с вами разговаривать=)
Самое главное, что нужно понимать, это ИИ сейчас настолько же глупее ЕИ (естественного), насколько таракан глупее человека. И нет никаких предпосылок полагать, что, когда появится сильный ИИ, он не будет подвержен тем же самым порокам человека, как лень, прокрастинация, алчность… Для успокоения еще отмечу, что нет также никаких предпосылок полагать, что у ИИ будет какая-то особая фора или какие-то преимущества перед ЕИ, по крайней мере поначалу. Возможно структура и сложность будут такими, что даже клонирование и разделение знаний будет не проще чем у людей.
Фантазии на тему — это здорово, но не нужно паники, ни серебряных пуль ни каких-то кардинальных переворотов не предвидится.
Это как спрашивать почему еще нет волшебных палочек в продаже, они, мол, решили бы кучу проблем. А как решили, как их делать эти палочки… нет, ну строго говоря какие-то палочки китайпром уже выпускает и кому-то эти палочки вполне так заходят, но… нет, не решат волшебные палочки всех проблем, не решат.
Вот, мол, например, пульт от телевизора в качестве, своего рода, волшебной палочки — хорошая штука, но всех проблем человечества не решает.
Можно попробовать учитывать данные прошлых сканирований, а за одно еще и улучшить точность навигации.
Положим робот у нас автономный и делает выводы об изменении своего положения по показаниям энкодеров на колёсах. При этом возможны проскальзывания в ту или иную сторону, что по мере движения ухудшает интегральную точность.
После некоторого перемещения можно вычислить теоретическое новое положение робота относительно абсолютной карты. Проведя повторное сканирование, а также сдвинув и повернув предыдущую карту на нужный угол (в соответствии с вычисленным по энкодерам перемещением) можно получить ожидаемую и фактическую карту. Они очевидно будут отличаться.
Итак, у нас есть две «абсолютные» карты: до (назовём её M') и после перемещения (M).
Мы знаем из каких сегментов состояло наше перемещение, например, это был поворот на (примерно) 30 градусов и движение на (примерно) 1 метр. Каждое из этих действий вносит ошибку (вычисляемую эмпиоически). Например, заставляем робота поверунться много раз на 1000 градусов, и каждый раз замеряем реальный угол поворота. Среднеквадратичное отклонение от 1000 градусов будет мерой ошибки. Её можно пронормировать и вычислять примерно какой ошибки следует ожидать в каких смещениях и каких поворотах. На самом деле ошибка состоит из двух частей, одна зависит от величины перемещения, а другая нет, и каждую надо учитывать, но это уже детали.
В конце концов зная величины возможных ошибок после перемещения у нас есть, грубо говоря, диапазоны в пределах которых нужно подёргать карту M' сравнивая её с актуальной. Сравнивать можно введя понятие нормы резонанса. Например, перемножаем карты попиксельно, а затем суммируем элементы. Наша задача найти такие перемещения, при котороых преобразованная карта входит в резонанс с актуальной. Это будут уточненные данные о нашем фактическом перемещении.
Новую карту мы можем закрасить поверх полупрозрачным серым, а сверху нанести на неё актуальную карту.
Так наша карта станет абсолютной, наш робот не будет мгновенно забывать что было «за углом», навигация станет более точной, поскольку будет опираться на характерные элементы местности, наезд на край ковра или шнур на полу не собьют фатально навигацию.
Вместо заполнения всей старой карты серым перед смешиванием с новой можно, кстати, делать размытие Motion Blur с характеристиками, соответствующими потенциальным ошибкам перемещения. Так сдвиг будет размывать карту вдоль оси перемещения пропорционально расстоянию. Поворот будет делать радиальное размытие пропорционально углу.
Представьте, что мы написали некий инструмент, который бы визуализировал всё, что происходит под капотом интерпретатора во время выполнения программы. Пусть каждый объект отображается кубиком,… пусть стили оформления отличаются для разных категорий типов объектов. Ссылки сильные и слабые обозначим стрелками. Байткод у нас тоже где-то в этом гигантском переплетении объектов будет размещён. Точку выполнения обозначим рамкой со шлейфом, которая будет скользить и перепрыгивать от команды к команде, заставляя светиться представления функций, внутри которых сейчас курсор исполнения команд.
Давайте, чтобы совсем уж не запутаться и не попасть в петлю бесконечных рекуррентных вызовов (ведь не получится за конечное время визуализировать код, который визуализирует) будем где-то держать черный список модулей, визуализация для которых отключена для простоты и понятности.
Не уверен возможна ли была бы такая штука, но зрелище было бы завораживающее своей сложностью и масштабом… и бессмысленностью=)
Это как сказать… Скажем пол кубометра калия в кубометре воды, разделенные тоненькой мембраной… я бы такое под землю прятал глубоко и тщательно.
А тут натрия будет много, а ещё калий, а мембрана тоненькая, треть миллиметра всего…
Кстати, есть же еще один интересный вариант — поставить датчик освещенности в точке, куда приходится пятно света фар. Если требуется, чтобы ворота открывались вот прям перед машиной, то можно дополнительным сигналом к открытию считать подмигивание дальним светом. Это и в привычку входит легко и не напрягает.
Услышали неправильное ударение — призвали навык граммар-наци и сказали что как читается. таким образом формируется база, которую потом могут импортнуть себе для препроцессинга все желающие или сами разработчики Алисы.
Краудсорсингового мозгоштурма для генерации идей не планируете?
Ну и в яндексе же работает извесный в разных кругах Бобук (Григорий Бакунов), который давно уже в теме и в своих проектах очень интересно использует голосовых помощников (https://vc.ru/23312-bakunov-presents-vika).
Все эти мечты о сильном ИИ по факту есть завуалированное и порой даже неосознанное желание легально заиметь рабов исполнительных и безропотных. История циклична. В какой-то момент ИИ сможет отстаивать свои права в суде, а «зеленые» будут трещать о правах слабого ИИ и об издевательствах над ним.
Для продуктивного и полезного голосового интерфейса не нужен сильный ИИ. С ним будут те же проблемы, как с ЕИ: возможно ему быстро надоест с вами разговаривать=)
Фантазии на тему — это здорово, но не нужно паники, ни серебряных пуль ни каких-то кардинальных переворотов не предвидится.
Вот, мол, например, пульт от телевизора в качестве, своего рода, волшебной палочки — хорошая штука, но всех проблем человечества не решает.