Тоже делал такую штуку, когда искал квартиру в Москве. Для этого Cian распарсил + сделал регрессию на цену аренды. Но проблема таких кустарных поделок в том, что нам доступна только база предложений, а не база сделок. И ценность таких поделок не очень велика — воспроизвести легко, а ценность (предсказание цены преложения) сомнительна.
Но когда такую штуку запускает Cian или Яндекс — это значимая новость, поскольку предполагается, что им известна цена сделки. Именно инсайд цены сделки здесь играет главную роль.
С шапками очень популярная, легкая и из разряда не рекомендованных к собеседованиям. Но такого рода задачи интересно просто решать в свободное от работы время.
Вариант этой задачи от Михаила на порядок интереснее, где количество заключенных алеф-0 и нужна бесконечная память: habr.com/post/54824
Если я правильно понял условия, то проще. Нужно не подстроку искать, а просто факт наличия полного слова среди уже введенных. То есть, бора (aka trie) должно быть достаточно. Идем по бору и поддерживаем в переменной количество символов до последней развилки.
Тут возможны варианты:
1) Зашли на терминальную вершину, а слово еще не закончилось. Значит к счетчику символов добавляем длину слова и «дорисуем» бор.
2) Слово закончилось, а в лист мы еще не пришли — добавляем длину слова. И ставим этой вершине статус развилки. Здесь тот момент где внимательность нужна. Пример: aaa aa aaa. После второго слова на вводе третьего мы уже воспользоваться автодополнением с одного символа, а только с трех = вводу слова целиком.
3) Закончили слово ровно на листе. Только в этом случае мы могли воспользоваться автодополнением. Осталось понять сколько символов нужно было ввести — а расстояние от корня до последней развилки мы знаем.
Некоторые моменты звучат очень странно, хотелось бы получить ответы в комментах.
— Нет ничего о метрике качества и чего удалось добиться на отложенной выборке.
— Я правильно понял, что есть 25k фичей и обучающая выборка объемом 100 строк?
Про уменьшение диска для Linux в любом гипервизоре. Я не админ, поэтому лет 10 назад у меня этот рецепт работал с настоящими железками. В случае любого гипервизора делаете тоже самое с виртуальными, а не настоящими дисками:
— делаем бэкап
— добавляем новый PV в LVM группу
— отключаем старый PV (тогда был риск потери данных, но у нас же бэкап)
Добавлю, что объекты все равно создаются. А запись ссылки в переменную — не overhead (не факт что будет). И в более сложных случаях можно сделать запись в несколько строк, давая осмысленные имена получаемым сущностям.
Нет. Немного искусственный пример: вырезание пробелов занимает 5ms, затем стэммер работает 500ms. Если «заоптимизировать» вырезание пробелов до 0ms, то экономия будет не очень заметной: с 505ms до 500ms. А еще можно вспомнить эмпирическое правило, что чем больше ускорение кода, тем больше времени тратится на это ускорение. Тогда как ускорение стэммера даже всего на 10% даст эффект значительно выше. За этим нужно профилировать код, а потом уже что-то оптимизировать.
Кроме того, можно заметить, что вырезание пробелов O(n) задача, тогда как затыки в реальных задачах чаще возникают в другом классе задач. То есть, замечание справедливо.
Другое дело, что это PoC, показывающий как что-то можно ускорить SIMD инструкциями. И этот пример может быть полезен в совершенно других задачах.
Согласен с supersonic_snail по первой статье. Быть может метод и правда хорош, но подтверждений пока не так много.
В теории, если взять слишком малый шаг, нас мало выбьет из локального минимума и мы вновь скатимся к тому же. Как правильно выбратьправильный цикл? Не надёжнее ли на практике действовать как деды и просто снижать шаг? И сравнение берётся с заранее фиксированным временным бюджетом, быть может с другим бюджетом будет уже не так, это на совести авторов статьи, которую ещё предстоит проверить.
А вот и нет. Да, есть проблема, что не всегда генерируется то, что на картинке. Есть вероятность, что сгенерированный код не соберется. Но нет оснований полагать, что LSTM выдаст сложный код.
Лапшу из кода генераторы получают из-за эвристик. Алгоритм разбирает входные данные по кирпичикам и переводит их в код. Это повышает сложность генерируемого кода. Здесь же генератор по дескриптору изображения (выход CNN) делает код как это было обучающей выборке. То есть, похожий на человеческий.
Если дать картинку совершенно непохожую ни на что из обучающей выборки, то скорее все сломается и получится бред, а не код. Но я не вижу сценария, чтобы код получился «нечитаемой лапшой».
Есть только вопросы к классификации. Ок, target в виде просто количества байт учится плохо. Случаются большие ошибки и сеть штрафует так, что она начинает игнорировать контекст и просто предсказывать среднее. Можно попробовать предсказывать не непосредственно выделенное количество байт, а его логарифм. И оптимизировать тот же RMSE.
Отличие от вашей идеи в следующем: если предсказали 1024 байт, а выделилось (A) 1025 (B) 1Gb
A) С точки зрения классификации это ошибка. С точки зрения регрессии на log2 это практически попадание в цель.
B) С точки зрения классификации это точно такая же ошибка как и случай А. С точки зрения регрессии это серьезная ошибка.
Не факт, что станет лучше, но кажется, что стоит попробовать.
Расскажите пожалуйста почему Inception до сих пор не на свалке истории, когда есть DenseNet? Какие у него плюсы? Вроде у DenseNet и качество выше и весов меньше. Из недостатков разве что ResNet MS Research опубликовали.
Ну и сравнение по GitHub popularity как-то не самый сильный аргумент в свете того, что MS явно заявляет, что их CNTK быстрее: https://github.com/Microsoft/CNTK
К тому же они мерятся звездочками с Keras. Keras мало похож на конкурента. Зачем он вообще в этом сравнении?
Я так понял, что Synaptic были первее. Цитата со страницы keras.js. Но да, получается что сейчас keras.js для такой задачи удобнее.
> Inspiration is drawn from a number of deep learning / neural network libraries for JavaScript and the browser, including Tensorflow Playground, ConvNetJS, synaptic, brain, CaffeJS, MXNetJS. However, the focus of this library is on inference only.
Ок, если TF будет бэкэндом, то да, получится js wrapper, который кому-то может быть удобен.
ReLU хорош не сколько тем, что он быстрый, а тем что градиент в области >0 не затухает [Leaky ReLU чтобы совсем везде был]. У сигмоида он нормальный только в окрестности 0, поэтому случается vanishing gradient problem.
Раз затронули быстродействие, то еще наброшу.
Для обучения кажется не так перспективно, потому что сети учатся долго. Не так сложно сделать фреймворк, нужно чтобы он быстро учил сеть. Мне кажется сомнительным, что этот проект окажется быстрее существующих решений. Если я не прав, дайте ссылку на benchmark когда оно станет сравнимым с tensorflow/theano.
Но вещь крайне полезная в плане применения обученной сети на девайсах, где есть js. Аналогично такой штуке: tf на android device
Где-то обучили сеть, закинули веса в protobuf, затем загрузили обученную сеть в tensorflow на мобильном девайсе и (1) не грузим сервер (2) не нужно быть online. Одна из killer features TF.
Правда нужно предварительно загрузить тяжелые веса. Но тут от автора Keras есть приличного качества сеть всего в 100Mb: https://arxiv.org/abs/1610.02357 (речь идет о распознавании картинок)
Но, в силу своей необразованности, я не знаю девайсов js-only. Данный проект был бы крайне полезен именно для них. Придумал только один пример. Prediction на стороне клиента прямо в браузере. Загружаем веса обученной в keras/tensorflow сети в браузер, берем вход клиента, делаем предсказание (а вероятно много предсказаний), не тратя ресурсы сервера. Но есть сомнения, что это реально нужно.
Jabher напиши пожалуйста видишь ли ты применение этого js фреймворка в устройствах? В каких?
Есть еще вопрос ответсвенности. Если я оценил что-то в 70-90 часов, то я должен успеть это в указанное время. Если не успел, то должен нести за это какую-то ответственность. Хотя бы в виде отчета «как так получилось и что нужно сделать, чтобы не случилось опять». Если успел раньше — все равно нужно понять что было не так с оценкой, чтобы следующая получилась точнее.
Оценил аналитик реализацию в 20 часов. Кто несет ответственность, если разработчик не успел? А еще сроки, спущены свыше, снижают мотивацию разработчика в них уложиться.
Общение с заказчиком — ok. Команда оценила требование в 700-900 часов, доносим это до заказчика. Возможно, ему на эти деньги требование окажется не нужным вовсе. Или решат упростить решение так, чтобы уложиться в 90 часов. Но это роль PM, а не аналитика.
Я допускаю, что один человек в команде может выполнять несколько ролей. Но только если он же несет ответственность за свои действия и обладает компетенцией.
Оценки сроков от аналитика одна из частых причин срывов сроков в проекте. Когда стал работать с «русским бизнесом» был неприятно удивлен распространенности этого явления. Хуже разве что архитектура от аналитика.
Здесь опыт нужен, чтобы в беседе с заказчиком определять проблемные места и подробнее доносить их до команды разработчиков. Тогда на встрече с разработчиками будет что обсудить: количество пользователей, лаг на карте, зачем нам все это нужно и какая у нас конечная цель, каковы критерии успеха. А не просто стоять человеком-телефоном и недоумевать.
Главное обходить 2 крайности:
— Заказчик часто озвучивает не функциональные требования, а свои представления о том, как это требование будет реализовано. Нужно уметь определить само требование.
— Заказчик лучше аналитика знает что ему нужно. Не стоит мнить себя мега-экспертом и делать «как лучше». Нужно делать как просят.
Можно пропускать твит через корректор и только потом добавлять его в обучающую выборку/классификатор. Но время на освоение PyEnchant или yandex speller (если проходите по лимитам) будет потрачено. А количество ошибок может остаться прежним. Когда я, например, твиты пишу, мне телефон/браузер явные опечатки исправляет.
С точки зрения последовательности действий подход мне кажется верным. Сначала получаем приемлемый результат, убеждаемся в перспективности подхода, а потом занимаемся тонкой настройкой.
Но сам подход с присвоением баллов словам мне перспективным не кажется. Сейчас я бы попробовал bag of words + svm. Но, уверен, что для данной задачи на текстах есть более хитрые подходы с лучшим качеством.
Но когда такую штуку запускает Cian или Яндекс — это значимая новость, поскольку предполагается, что им известна цена сделки. Именно инсайд цены сделки здесь играет главную роль.
Вариант этой задачи от Михаила на порядок интереснее, где количество заключенных алеф-0 и нужна бесконечная память: habr.com/post/54824
Тут возможны варианты:
1) Зашли на терминальную вершину, а слово еще не закончилось. Значит к счетчику символов добавляем длину слова и «дорисуем» бор.
2) Слово закончилось, а в лист мы еще не пришли — добавляем длину слова. И ставим этой вершине статус развилки. Здесь тот момент где внимательность нужна. Пример: aaa aa aaa. После второго слова на вводе третьего мы уже воспользоваться автодополнением с одного символа, а только с трех = вводу слова целиком.
3) Закончили слово ровно на листе. Только в этом случае мы могли воспользоваться автодополнением. Осталось понять сколько символов нужно было ввести — а расстояние от корня до последней развилки мы знаем.
— Нет ничего о метрике качества и чего удалось добиться на отложенной выборке.
— Я правильно понял, что есть 25k фичей и обучающая выборка объемом 100 строк?
— делаем бэкап
— добавляем новый PV в LVM группу
— отключаем старый PV (тогда был риск потери данных, но у нас же бэкап)
Добавлю, что объекты все равно создаются. А запись ссылки в переменную — не overhead (не факт что будет). И в более сложных случаях можно сделать запись в несколько строк, давая осмысленные имена получаемым сущностям.
Но syntax sugar все же удобен.
В том то и дело, что тогда он вообще не будет работать. Или на основе какой информации, не заглядывая в письмо, алгоритм решит спам это или нет?
Кроме того, можно заметить, что вырезание пробелов O(n) задача, тогда как затыки в реальных задачах чаще возникают в другом классе задач. То есть, замечание справедливо.
Другое дело, что это PoC, показывающий как что-то можно ускорить SIMD инструкциями. И этот пример может быть полезен в совершенно других задачах.
В теории, если взять слишком малый шаг, нас мало выбьет из локального минимума и мы вновь скатимся к тому же. Как правильно выбратьправильный цикл? Не надёжнее ли на практике действовать как деды и просто снижать шаг? И сравнение берётся с заранее фиксированным временным бюджетом, быть может с другим бюджетом будет уже не так, это на совести авторов статьи, которую ещё предстоит проверить.
Лапшу из кода генераторы получают из-за эвристик. Алгоритм разбирает входные данные по кирпичикам и переводит их в код. Это повышает сложность генерируемого кода. Здесь же генератор по дескриптору изображения (выход CNN) делает код как это было обучающей выборке. То есть, похожий на человеческий.
Если дать картинку совершенно непохожую ни на что из обучающей выборки, то скорее все сломается и получится бред, а не код. Но я не вижу сценария, чтобы код получился «нечитаемой лапшой».
Есть только вопросы к классификации. Ок, target в виде просто количества байт учится плохо. Случаются большие ошибки и сеть штрафует так, что она начинает игнорировать контекст и просто предсказывать среднее. Можно попробовать предсказывать не непосредственно выделенное количество байт, а его логарифм. И оптимизировать тот же RMSE.
Отличие от вашей идеи в следующем: если предсказали 1024 байт, а выделилось (A) 1025 (B) 1Gb
A) С точки зрения классификации это ошибка. С точки зрения регрессии на log2 это практически попадание в цель.
B) С точки зрения классификации это точно такая же ошибка как и случай А. С точки зрения регрессии это серьезная ошибка.
Не факт, что станет лучше, но кажется, что стоит попробовать.
> https://arxiv.org/pdf/1608.07249.pdf
И в чем смысл сравнивать количество звездочек с Keras и в 2017 называть Inception революционной архитектурой?
Ну и сравнение по GitHub popularity как-то не самый сильный аргумент в свете того, что MS явно заявляет, что их CNTK быстрее: https://github.com/Microsoft/CNTK
К тому же они мерятся звездочками с Keras. Keras мало похож на конкурента. Зачем он вообще в этом сравнении?
Я так понял, что Synaptic были первее. Цитата со страницы keras.js. Но да, получается что сейчас keras.js для такой задачи удобнее.
> Inspiration is drawn from a number of deep learning / neural network libraries for JavaScript and the browser, including Tensorflow Playground, ConvNetJS, synaptic, brain, CaffeJS, MXNetJS. However, the focus of this library is on inference only.
Ок, если TF будет бэкэндом, то да, получится js wrapper, который кому-то может быть удобен.
Раз затронули быстродействие, то еще наброшу.
Для обучения кажется не так перспективно, потому что сети учатся долго. Не так сложно сделать фреймворк, нужно чтобы он быстро учил сеть. Мне кажется сомнительным, что этот проект окажется быстрее существующих решений. Если я не прав, дайте ссылку на benchmark когда оно станет сравнимым с tensorflow/theano.
Но вещь крайне полезная в плане применения обученной сети на девайсах, где есть js. Аналогично такой штуке: tf на android device
Где-то обучили сеть, закинули веса в protobuf, затем загрузили обученную сеть в tensorflow на мобильном девайсе и (1) не грузим сервер (2) не нужно быть online. Одна из killer features TF.
Правда нужно предварительно загрузить тяжелые веса. Но тут от автора Keras есть приличного качества сеть всего в 100Mb: https://arxiv.org/abs/1610.02357 (речь идет о распознавании картинок)
Но, в силу своей необразованности, я не знаю девайсов js-only. Данный проект был бы крайне полезен именно для них. Придумал только один пример. Prediction на стороне клиента прямо в браузере. Загружаем веса обученной в keras/tensorflow сети в браузер, берем вход клиента, делаем предсказание (а вероятно много предсказаний), не тратя ресурсы сервера. Но есть сомнения, что это реально нужно.
Jabher напиши пожалуйста видишь ли ты применение этого js фреймворка в устройствах? В каких?
Оценил аналитик реализацию в 20 часов. Кто несет ответственность, если разработчик не успел? А еще сроки, спущены свыше, снижают мотивацию разработчика в них уложиться.
Общение с заказчиком — ok. Команда оценила требование в 700-900 часов, доносим это до заказчика. Возможно, ему на эти деньги требование окажется не нужным вовсе. Или решат упростить решение так, чтобы уложиться в 90 часов. Но это роль PM, а не аналитика.
Я допускаю, что один человек в команде может выполнять несколько ролей. Но только если он же несет ответственность за свои действия и обладает компетенцией.
Оценки сроков от аналитика одна из частых причин срывов сроков в проекте. Когда стал работать с «русским бизнесом» был неприятно удивлен распространенности этого явления. Хуже разве что архитектура от аналитика.
Здесь опыт нужен, чтобы в беседе с заказчиком определять проблемные места и подробнее доносить их до команды разработчиков. Тогда на встрече с разработчиками будет что обсудить: количество пользователей, лаг на карте, зачем нам все это нужно и какая у нас конечная цель, каковы критерии успеха. А не просто стоять человеком-телефоном и недоумевать.
Главное обходить 2 крайности:
— Заказчик часто озвучивает не функциональные требования, а свои представления о том, как это требование будет реализовано. Нужно уметь определить само требование.
— Заказчик лучше аналитика знает что ему нужно. Не стоит мнить себя мега-экспертом и делать «как лучше». Нужно делать как просят.
С точки зрения последовательности действий подход мне кажется верным. Сначала получаем приемлемый результат, убеждаемся в перспективности подхода, а потом занимаемся тонкой настройкой.
Но сам подход с присвоением баллов словам мне перспективным не кажется. Сейчас я бы попробовал bag of words + svm. Но, уверен, что для данной задачи на текстах есть более хитрые подходы с лучшим качеством.