Я сам занимаюсь текстом, поэтому про картинки знаю по большей части только из статей. Собственно, это информация из одной из первых статей на adversarial examples.
Потому что можно будет найти новые паттерны шума, которые будут так же убивать сеть на картинках. И это не лечится повторением (те так можно играть в кошки-мышки сколько угодно).
Нейросетевые модели машинного перевода по сути дела — наврорченные языковые модели, которые имеют ещё и некоторый вход и сильно обусловлены им. Гугл, насколько я знаю, собирает свой корпус для обучения моделей полу-автоматически из интернет текстов. Так как английские новости в основном используют слово annex в отношении Крыма и действий России с ним, то языковая модель выберет этот вариант. То же самое про Штаты и Техас. С именами уже сложнее, так как я думаю что такой комбинации слов в примерах для обучения гораздо меньше, поэтому всё начинает плавать при замене одного слова на другое.
С NFC точки зрения Фелика (NFC-F, проприетарный стандарт от Сони) довольно крутая штука имхо. Там на одной карте может висеть большое количество сервисов, причём каждый со своей аутентификацией. Поддерживается яблофонами начиная с 7 и андродиами с непонятно каких времён, правда железка (секюрный юнит) на андроидах есть только в японских моделях, увы. С секюрным юнитом не нужно не включать телефон, ни разблокировать его.
Правда для доступа к сдк/закрытой части документации нужно дружить с Сони.
Можно начинать уже сейчас, используя mmap и друзей вместо read/write. Есть конечно оговорки, но для случайного доступа, когда некоторые места могут читаться чаще чем остальные — самое то.
Проще на мой взгляд как в плане кода (не нужно убиваться с экспоненциальным взрывом количества гипотез в декодере, например), так в плане того, что меньше компонентов. Статистические модели так же гораздо хуже работали для сильно непохожих друг на друга языков без использования всяких безумных моделей типа tree-to-tree/tree-to-string (английский-японский из близкого мне, например). Как пример, у нас в лаборатории группа машинного перевода за пару месяцев написали движок для нейросетевого перевода с нуля за пару месяцев и он работал сильно лучше старого статистического, который разрабатывали много лет.
То, что для нейросетей требуется больше текста — это конечно да. И что у него есть свои болячки — это тоже факт. Гугл же, насколько я понимаю его внутреннюю кухню, смог выпустить нейросетевой перевод в машинное плавание когда у них вычислительные ускорители стали доступны в большом количестве. В железо это дело сильно упирается и на обычных серверах выехать очень тяжело.
Но корпуса-то в любом случае собирать (и открывать) нужно.
В статье никак не отражено, что с приходом NMT системы машинного перевода стали гораздо _проще_ по внутренней структуре. И несмотря на это оно работает и показывает приличные результаты.
А так вообще — был бы корпус внутри домена — будет роскошный перевод.
Нейросетевая архитектура — интересное обыгрывание seq2seq с использованием конволюций.
Может быть кстати идеи из seq2seq (типа attention) как раз помогут ещё улучшить точность прогноза.
По поводу лосса: а нельзя сделать вычислить карту прогноза выпадения осадков, собрать реальные данные и минимизировать разницу между предсказаниями и фактами, давая приоритет например городу, а не лесу.
Я могу ошибаться, но TBB умеет представлять вычисления только в виде орграфа, те без циклов. akka-stream умеет в циклы в том числе.
Кроме этого, если использовать много исполнителей, делающих мелкие вычисления, то смен контекста в таком вычислительном графе будет много и ничего хорошего не выйдет. Нужно иметь какой-то баланс между проведением вычислений и передачей данных.
Корутины и continuations — это хорошо, я не спорю, оно мне самому нравится.
Задачи — они разные, решения тоже есть разные, поэтому да, нужно смотреть что лучше подходит в каждом конкретном случае. Но мне кажется, что протокол, когда обработчик говорит, сколько сообщений он может принять и не умереть (плюс возможно что делать с другими сообщениями) вполне имеет право на жизнь почти везде.
Частично, пожалуй, то, что вы говорите, частично на мой взгляд — это создание API для работы с типизированными данными.
akka-stream — это ведь не только про обработку линейных потоков данных. В akka-stream модель вычислений — граф, с циклами и прочим весельем при желании. Поэтому чисто на потоках например реализован akka-http.
Сами акторы в akka-stream используются только для разруливания проблем с concurrency (по сути единственный актор там — это GraphInterpreter, который исполняет действия над пайплайном обработки).
А по поводу протоколов для доставки можете посмотреть на https://github.com/real-logic/Aeron где есть настраиваемая надёжность доставки с приоритетами поверх UDP.
Штуки, про которые я рассказывал реализованы вместе с буферизацией на асинхронных границах http://doc.akka.io/docs/akka/2.4.14/scala/stream/stream-rate.html
Правда akka-stream штука достаточно сложная для понимания с наскока, и возможно будет лучше именно что познакомиться получше с документацией и может почитать исходники. Мне в akka-stream очень нравятся примитивы для написания собственной логики обработчиков (GraphStage), которую нельзя описать встроенными комбинаторами. Для обработки потоковых данных на мой взгляд akka-stream гораздо проще и удобнее, чем обычные акторы.
Да, для вашего юзкейса возможно правильнее дропать какие-то сообщения на получателях если они не успевают обрабатывать весь поток.
ReactiveStreams — это такой минимальный API/протокол для реализации async non-blocking backpressure. Например необязательно посылать следующий сигнал когда обработаны все текущие сообщения, можно сделать это когда есть какое-то место в буфере обработчике например.
Akka Streams например поверх протокола ReactiveStreams реализует много чего. И отбрасывание лишних сообщений, и группировку, и непосылание новых запросов.
Основная документация с TCK: http://www.reactive-streams.org/
TCK он для джавы, но одним из вдохновителей лежат авторы akka как раз.
API даже войдёт в JDK9.
https://community.oracle.com/docs/DOC-1006738
А почему нельзя реализовать протокол подобный ReactiveStreams в таком случае?
По-моему весьма удобный инструмент для работы с backpressure, у grpc тоже очень похожее внутреннее API.
В принципе почти хватает и сейчас, без метапрограммирования
Нейросетевые модели машинного перевода по сути дела — наврорченные языковые модели, которые имеют ещё и некоторый вход и сильно обусловлены им. Гугл, насколько я знаю, собирает свой корпус для обучения моделей полу-автоматически из интернет текстов. Так как английские новости в основном используют слово annex в отношении Крыма и действий России с ним, то языковая модель выберет этот вариант. То же самое про Штаты и Техас. С именами уже сложнее, так как я думаю что такой комбинации слов в примерах для обучения гораздо меньше, поэтому всё начинает плавать при замене одного слова на другое.
Правда для доступа к сдк/закрытой части документации нужно дружить с Сони.
То, что для нейросетей требуется больше текста — это конечно да. И что у него есть свои болячки — это тоже факт. Гугл же, насколько я понимаю его внутреннюю кухню, смог выпустить нейросетевой перевод в машинное плавание когда у них вычислительные ускорители стали доступны в большом количестве. В железо это дело сильно упирается и на обычных серверах выехать очень тяжело.
Но корпуса-то в любом случае собирать (и открывать) нужно.
А так вообще — был бы корпус внутри домена — будет роскошный перевод.
Может быть кстати идеи из seq2seq (типа attention) как раз помогут ещё улучшить точность прогноза.
По поводу лосса: а нельзя сделать вычислить карту прогноза выпадения осадков, собрать реальные данные и минимизировать разницу между предсказаниями и фактами, давая приоритет например городу, а не лесу.
Кроме этого, если использовать много исполнителей, делающих мелкие вычисления, то смен контекста в таком вычислительном графе будет много и ничего хорошего не выйдет. Нужно иметь какой-то баланс между проведением вычислений и передачей данных.
Корутины и continuations — это хорошо, я не спорю, оно мне самому нравится.
Задачи — они разные, решения тоже есть разные, поэтому да, нужно смотреть что лучше подходит в каждом конкретном случае. Но мне кажется, что протокол, когда обработчик говорит, сколько сообщений он может принять и не умереть (плюс возможно что делать с другими сообщениями) вполне имеет право на жизнь почти везде.
akka-stream — это ведь не только про обработку линейных потоков данных. В akka-stream модель вычислений — граф, с циклами и прочим весельем при желании. Поэтому чисто на потоках например реализован akka-http.
Сами акторы в akka-stream используются только для разруливания проблем с concurrency (по сути единственный актор там — это GraphInterpreter, который исполняет действия над пайплайном обработки).
Правда akka-stream штука достаточно сложная для понимания с наскока, и возможно будет лучше именно что познакомиться получше с документацией и может почитать исходники. Мне в akka-stream очень нравятся примитивы для написания собственной логики обработчиков (GraphStage), которую нельзя описать встроенными комбинаторами. Для обработки потоковых данных на мой взгляд akka-stream гораздо проще и удобнее, чем обычные акторы.
ReactiveStreams — это такой минимальный API/протокол для реализации async non-blocking backpressure. Например необязательно посылать следующий сигнал когда обработаны все текущие сообщения, можно сделать это когда есть какое-то место в буфере обработчике например.
Akka Streams например поверх протокола ReactiveStreams реализует много чего. И отбрасывание лишних сообщений, и группировку, и непосылание новых запросов.
TCK он для джавы, но одним из вдохновителей лежат авторы akka как раз.
API даже войдёт в JDK9.
https://community.oracle.com/docs/DOC-1006738
По-моему весьма удобный инструмент для работы с backpressure, у grpc тоже очень похожее внутреннее API.