Игнорирование нативных интерфейсов — это вообще не выход. Сразу же все языки, где есть хитрый ввод (китайский, японский, корейский например) перестают поддерживаться. Или нужен будет кросс-платформенный API для доступа к состоянию IME и прочих средств ввода, чего никогда не будет, я думаю.
Нормальный 4G только у нормальных операторов потому что за нормальные (или неприличные) деньги.
Сейчас померял свой 4G на докомо: 32.15 in/4.57 out (до сервера в 100 км отсюда).
По вайфаю скачивание поднимается до 50, если что.
Туристические симки от MVNO довольно таки тормозные.
Живу в Киото, плачу где-то 5000 за гигабит по оптике от docomo, кто провайдер уже не помню. Подключение было бесплатным. Что дороже, чем в России не спорю, пожалуй. Сотовая связь вообще сильно дороже.
По поводу кортежей в скале. Если эта штука будет использоваться в более чем одном месте, то лучше имхо сделать case class. Иногда и для одного места лучше сделать case class. Я почти кортежами не пользуюсь.
Вот на что нейросетевые переводы не похожи, так это на дословный перевод.
Это больше к статистическим системам машинного перевода.
у нейросетей больше проблем с тем, что они «забывают» перевести некоторые слова или делают достаточно бредовые замены одних слов на похожие другие.
Нейросетевой перевод по сути дела — сэмпл из очень очень мощной языковой модели целевого языка, подкрашеный исходным предложением как «темой».
Tensorflow нынче единственный (насколько я знаю, поправьте меня если это не так) фреймворк, в котором интерфейс кернелов асинхронный. Из других я смотрел правда только на Chainer, Theano, DyNet.
XLA тоже очень интересный и правильный шаг здесь. Оптимизация с объединением операций пока что только тут. Но это инженерная база гугла помогает.
Создавать и обучать сетки в Tensorflow сейчас все равно можно практически только в питоне.
Обученные же легко запускаются в виде микросервисов с помощью https://github.com/tensorflow/serving. Нужно только чтобы был grpc.
Интегрировать tensorflow в своё серверное приложение библиотекой я бы не стал. Оно весьма тяжёлое. Заморачиваться с тем, что делается для мобильных приложений для сервера имхо оверкилл, когда есть решение на микросервисах.
Tensorflow и Theano работают в символьном режиме, когда сначала создаётся граф вычислений, а потом он «запускается» и происходит работа нейросети.
Есть и другие подходы.
Иногда процесс вычислений задаётся линейно, как например сделано в dl4j.
DyNet создаёт граф вычислений на каждый вызов и исполняет его.
Chainer производит «ход вперёд» без создания графа, однако запоминает историю для последующего вычисления градиентов и оптимизации.
Веса модели есть везде и их количество будет одинаковым для сети одинаковой конфигурации вне зависимости от фреймворка. Иначе сети не были бы одинаковой конфигурации.
Если бы можно было знать, где сети ошибаются, а где нет, то эта штука помогла бы, но всё немного сложнее. Случаи когда все сети не ошибаются менее интересны, потому что среди уже аннотированных данных достаточно информации для нахождения правильного решения. Случаи когда все сети врут гораздо хуже — они заражают исходные данные, а нейросети сильно чувствительны к плохим аннотированным данным, особенно для языка, где пространство параметров очень разрежено по сравнению с обработкой изображениями.
Подход когда промежуточные результаты, где варианты сетей не сошлись в ответе показывать человеку и использовать проверенные деревья для увеличения примеров будет лучше на мой взгляд.
Насколько я знаю, Гугл для языков с очень большим объёмом параллельных текстов использует end-to-end нейросети, в том числе в продакшне. Для большинства обычных — просто статистический подход с самой простой языковой моделью — Stupid Backoff. Хитрые вещи с морфологией они не делают, надеясь на просто языковую модель. Нейросети правда частично решают эту проблему, так как гугловская модель использует не слова, а subword units, что будет приводить к сегментации на что-то, похожее на морфемы, но я подробностей про русский не слышал. Разве что параллельный корпус у них примерно на 0.3B предложений.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110
Загрузки со стима обычно в районе 30 МБайт/с (50гб игра за 10 минут где-то).
Сейчас померял свой 4G на докомо: 32.15 in/4.57 out (до сервера в 100 км отсюда).
По вайфаю скачивание поднимается до 50, если что.
Туристические симки от MVNO довольно таки тормозные.
Это больше к статистическим системам машинного перевода.
у нейросетей больше проблем с тем, что они «забывают» перевести некоторые слова или делают достаточно бредовые замены одних слов на похожие другие.
Нейросетевой перевод по сути дела — сэмпл из очень очень мощной языковой модели целевого языка, подкрашеный исходным предложением как «темой».
Это библиотека, которая реализует… целочисленное деление на константу… как умножение со сдвигом.
XLA тоже очень интересный и правильный шаг здесь. Оптимизация с объединением операций пока что только тут. Но это инженерная база гугла помогает.
Обученные же легко запускаются в виде микросервисов с помощью https://github.com/tensorflow/serving. Нужно только чтобы был grpc.
Интегрировать tensorflow в своё серверное приложение библиотекой я бы не стал. Оно весьма тяжёлое. Заморачиваться с тем, что делается для мобильных приложений для сервера имхо оверкилл, когда есть решение на микросервисах.
Tensorflow и Theano работают в символьном режиме, когда сначала создаётся граф вычислений, а потом он «запускается» и происходит работа нейросети.
Есть и другие подходы.
Иногда процесс вычислений задаётся линейно, как например сделано в dl4j.
DyNet создаёт граф вычислений на каждый вызов и исполняет его.
Chainer производит «ход вперёд» без создания графа, однако запоминает историю для последующего вычисления градиентов и оптимизации.
Веса модели есть везде и их количество будет одинаковым для сети одинаковой конфигурации вне зависимости от фреймворка. Иначе сети не были бы одинаковой конфигурации.
На текст специализируются похоже только https://github.com/clab/dynet да https://github.com/pfnet/chainer
Learning to learn by gradient descent by gradient descent (NIPS 2016)
Учат оптимизатор как нейросеть
Подход когда промежуточные результаты, где варианты сетей не сошлись в ответе показывать человеку и использовать проверенные деревья для увеличения примеров будет лучше на мой взгляд.