У большинства крупных поисковиков и сервисов есть механизм похожих поисковых запросов, когда пользователю предлагаются варианты, тематически близкие к тому, что он искал. Так делают в google, yandex, bing, amazon, несколько дней назад это появилось и у нас на hh.ru!



В этой статье я расскажу о том, как мы добывали похожие поисковые запросы из логов сайта hh.ru.

Недавно прочитал неплохой пост на тему поиска работы QA и подумал, что похожий пост был бы полезен для JavaScript разработчиков. В конечном счёте, веб движется вперед семимильными шагами, и соискателей на позицию JavaScript программиста хоть отбавляй (разумеется, хороших всегда меньше).

Всем привет.
Хочу поделиться своим опытом переезда в Нидерланды.

Краткое предисловие.

Все свои 25 лет я прожил в Киеве, закончил КПИ. На 3м курсе начал заниматься веб-разработкой — пилил сайты на Джумлах — Вордпрессах, рисовал дизайны и потихоньку изучал премудрости PHP и JS. Через 1.5 года устроился в киевский филиал Anzer IT Healthcare и, после года работы там, первый раз серьезно задумался о поиске работы за границей с переездом. Тогда я видел это как успешное продолжение карьеры, еще со школьных-институтские времен, видать, въелись наставления родителей.

Итак…

Здравствуй, Хабр.

Лето на дворе, скоро отпуск и появилось немного свободного времени поделиться наработками, каким-то опытом по написанию Web приложений на Java платформе. Как основной язык я буду использовать Scala. Это будет похоже на небольшой гайд, как человеку с опытом Java постепенно начать использовать Scala и не отказываться от уже имеющихся у него наработок.

Это первая часть из серии статей, в которой мы уделим внимание базовой структуре приложения. Ориентирована на людей знающих Java, работавших со Spring, Hibernate, JPA, JSP и другими 3-4ех буквенными сокращениями. Я попытаюсь рассказать как максимально быстро и безболезненно начать использовать Scala в ваших проектах и по-другому проектировать ваше новое приложение. Все это будет вокруг проекта, который должен выполнять ряд требований:
1. Приложение полностью закрыто, работаем только после авторизации
2. Наличие удобного API (REST мы забудем (он уже история) и напишем что-то вроде Google AdWords API, со своим SQL like запросником)
3. Возможность запуска на сервере приложений так и без него
4. i18n
5. Миграция БД
6. Среда для разработки должна разворачиваться через Vagrant
7. И, по мелочи, логирование, развертывание…

Все это нужно сделать так, чтобы сопровождать и развивать наше приложение было очень легко, чтобы не возникло такой ситуации, когда при добавление нового справочника программист оценивает это сроком в 2 дня. Если я вас заинтересовал, прошу под кат.

Несколько месяцев назад был опубликован цикл статей под общим названием «Логика мышления». Оптимистично планировалось продолжить его через месяц-другой. Но жизнь внесла свои коррективы. Моделирование паттерно-волновой модели коры дало настолько интересные результаты, что пришлось на время отложить все остальное, в том числе и написание продолжения цикла для хабра.

Однако, не так давно я написал и выложил на препринт статью (http://arxiv.org/abs/1406.6901). В чем-то она может быть интересна тем, кто ранее заинтересовался волновой моделью. Напомню, что ключевой момент модели – это утверждение, что нейроны способны запоминать и узнавать не один единственный образ, описываемый весами его синапсов, а еще и огромное количество других отличных от этого образа сигналов. Конечно, такое усложнение нейрона идет в разрез со многими существующими теориями и требует более, чем серьезного обоснования. Ниже я, как раз, и попробую описать один из приведенных в статье аргументов в пользу моей модели.

Этот пост хотелось бы написать скорее в философском ключе, нежели в математическом (точнее алгебраическом): не что это за страшный зверь — ЛСА, а какая от него может быть польза «нашему колхозу», т.е. ИИ.

Ни для кого уже не секрет, что ИИ состоит из многих взаимонепересекающихся или слабо пересекающихся областей: распознавание образов, распознавание речи, реализации моторных функций в пространстве и пр. Но одной из главных целей ИИ – научить «железо» думать, что включает в себя не только процессы понимания, но и генерирование новой информации: свободного или творческого мышления. В связи с этим возникают вопросы не столько разработки методов обучения систем, сколько осмысления процессов мышления, возможности их реализации.

На основах работы ЛСА, как уже упоминалось в начале статьи, я не буду сейчас останавливаться (планирую в следующем посте), а пока отошлю к Википедии, лучше даже английской (LSA). А вот основную идею этого метода постараюсь изложить на словах.

Формально:
ЛСА используется для выявления латентных (скрытых) ассоциативно-семантических связей между термами (словами, н-граммами) путем сокращения факторного пространства термы-на-документы. Термами могут выступать как слова, так и их комбинации, т.наз. н-граммы, документами – в идеале: наборы тематически однородных текстов, либо просто любой желательно объемный текст (несколько млн. словоформ), произвольно разбитый на куски, например абзацы.

«На пальцах»:
Основная идея латентно-семантического анализа состоит в следующем: если в исходном вероятностном пространстве, состоящим из векторов слов (вектор = предложение, абзац, документ и т.п.), между двумя любыми словами из двух разных векторов может не наблюдаться никакой зависимости, то после некоторого алгебраического преобразования данного векторного пространства эта зависимость может появиться, причем величина этой зависимости будет определять силу ассоциативно-семантической связи между этими двумя словами.

Например, рассмотрим два простых сообщения из разных источников (просто пример для наглядности):

Несмотря на огромную популярность аппарата графических моделей для решения задачи структурной классификации, задача настройки их параметров по обучающей выборке долгое время оставалась открытой. В своем докладе Дмитрий Ветров, рассказал об обобщении метода опорных векторов и некоторых особенностях его применения для настройки параметров графических моделей. Дмитрий – руководитель группы Байесовских методов, доцент ВМК МГУ и преподаватель в ШАДе.

Видеозапись доклада.

План доклада:

• Байесовские методы в машинном обучении.
• Задачи с взаимозависимыми скрытыми переменными.
• Вероятностные графические модели
• Метод опорных векторов и его обобщение для настройки параметров графических моделей.

Сама концепция машинного обучения довольно несложная – это, если говорить образно, поиск взаимосвязей в данных. Данные представляются в классической постановке набором объектов, взятых из одной и той же генеральной совокупности, у каждого объекта есть наблюдаемые переменные, есть скрытые переменные. Наблюдаемые переменные (дальше будем их обозначать X) часто называются признаками, соответственно, скрытые переменные (T) — это те, которые подлежат определению. Для того, чтобы эту взаимосвязь между наблюдаемыми и скрытыми переменными установить, предполагается, что у нас есть обучающая выборка, т.е. набор объектов, для которых известны и наблюдаемые и скрытые компоненты. Глядя на нее, мы пытаемся настроить некоторые решающие правила, которые нам позволят в дальнейшем, когда мы видим набор признаков, оценить скрытые компоненты. Процедура обучения приблизительно выглядит следующим образом: фиксируется множество допустимых решающих правил, которые как правило задаются с помощью весов (W), а дальше каким-то образом в ходе обучения эти веса настраиваются. Тут же с неизбежностью возникает проблема переобучения, если у нас слишком богатое семейство допустимых решающих правил, то в процессе обучения мы легко можем выйти на случай, когда для обучающей выборки мы прекрасно прогнозируем ее скрытую компоненту, а вот для новых объектов прогноз оказывается плохой. Исследователями в области машинного обучения было потрачено немало лет и усилий для того, чтобы эту проблему снять с повестки дня. В настоящее время, кажется, что худо-бедно это удалось.

И снова здравствуйте! Сегодня я продолжаю серию статей в блоге Surfingbird, посвящённую разным методам рекомендаций, а также иногда и просто разного рода вероятностным моделям. Давным-давно, кажется, в прошлую пятницу летом прошлого года, я написал небольшой цикл о графических вероятностных моделях: первая часть вводила основы графических вероятностных моделей, во второй части было несколько примеров, часть 3 рассказывала об алгоритме передачи сообщений, а в четвёртой части мы кратко поговорили о вариационных приближениях. Цикл заканчивался обещанием поговорить о сэмплировании — ну что ж, не прошло и года. Вообще говоря, в этом мини-цикле я поведу речь более предметно о модели LDA и о том, как она помогает нам делать рекомендации текстового контента. Но сегодня начну с того, что выполню давнее обещание и расскажу о сэмплировании в вероятностных моделях — одном из основных методов приближённого вывода.

Disclaimer: Я работаю в Google на позиции инженера уже почти 4 года.

По тому, что я пишу про Google, может создаться впечатление, что работа в Google – это предел мечтаний, идеальное место для работы, куда стоит стремиться попасть любой ценой. Google реально очень хорошая компания для программистов, даже отличная. Но идеалов не бывает, и у нее тоже есть некоторые минусы. О них сегодня и пойдет речь.

Думаю, все ниже написанное почти в полной мере справедливо и для других похожих компаний. Поэтому я буду писать “компания” вместо Google. Не ручаюсь, но подозреваю (и подозрения подтверждаются большим количеством знакомых), что примерно то же самое можно сказать и о Microsoft, и о Facebook, и об Amazon, и о других приличных больших компаниях.

От переводчика:

Статья, которую я предлагаю вам почитать, не нова — она опубликована аж 29 марта. Но на Реддите ее запостили всего несколько дней назад, да и актуальности своей она точно не потеряла. Интересность ее в том, что автор на простом и коротком примере демонстрирует практическое применение трех больших и популярных библиотек: numpy, scipy и pygame. Про первые две многие слышали, но все больше в контексте научных работ, так что интересно посмотреть на их применение в «обычной» жизни. В конце статьи прекрасная видео-демонстрация результата, хотя бы ее точно стоит посмотреть.

Авторский код сохранен без изменений, несмотря на то, что он оформлен не по PEP-8 и за его валидность я не ручаюсь. Настоящий рабочий код так или иначе есть на ГитХабе, ссылку вы найдете в конце статьи.

Запишите звук, измените тон 50 раз и сопоставьте каждому новому звуку клавишу на клавиатуре компьютера. Получится Пианопьютер!