Довольно часто нас спрашивают, почему мы не устраиваем соревнований дата-сайентистов. Дело в том, что по опыту мы знаем: решения в них совсем не применимы к prod. Да и нанимать тех, кто окажется на ведущих местах, не всегда имеет смысл.



Такие соревнования часто выигрывают с помощью так называемого китайского стекинга, когда комбинаторным способом берут все возможные алгоритмы и значения гиперпараметров, и полученные модели в несколько уровней используют сигнал друг от друга. Обычные спутники этих решений — сложность, нестабильность, трудность при отладке и поддержке, очень большая ресурсоёмкость при обучении и прогнозировании, необходимость внимательного надзора человека в каждом цикле повторного обучения моделей. Смысл делать это есть только на соревнованиях — ради десятитысячных в локальных метриках и позиций в турнирной таблице.

Совсем недавно мы искали дата-сайентиста в команду (и нашли — привет, nik_son и Арсений!). Пока общались с кандидатами, поняли, что многие хотят сменить место работы, потому что делают что-то «в стол».

Например, берутся за сложное прогнозирование, которое предложил начальник, но проект останавливается — потому что в компании нет понимания, что и как включить в продакшен, как получить прибыль, как «отбить» потраченные на новую модель ресурсы.



У HeadHunter нет больших вычислительных мощностей, как у «Яндекса» или Google. Мы понимаем, как нелегко катить в продакшен сложный ML. Поэтому многие компании останавливаются на том, что катят в прод простейшие линейные модели.

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

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

Для нормальной работы поиска крайне важна система метрик — локальных, A/B-тестов, очередей на проде и т. д., и эта система требует отдельного внимания и ресурсов. Неправильно думать, что достаточно просто запилить крутой ML и прикрутить все эти метрики «скотчем»; недостаточно также измерять качество работы уже работающей системы — не так уж важно, использует ли она ML или представляет собой Lucene «из коробки».

Больше половины соискателей ничего не ищут, а создают резюме и просто ждут, когда их пригласят на собеседование или хотя бы пришлют подходящую вакансию. Когда мы думали, как для них должен выглядеть сайт по поиску работы, то поняли, что им нужна всего одна кнопка.



Делать такую систему мы начали полтора года назад — решили построить на машинном обучении алгоритм, который сам выбирал бы подходящие пользователю вакансии. Но мы очень быстро поняли: вакансии, похожие на резюме, и вакансии, на которые владельцу резюме хочется откликнуться, — далеко не одно и то же.

UPD. Спустя несколько часов после публикации на Хабре англоязычная версия этого исследования команды Безопасного поиска Яндекса вышла на Virus Bulletin. Чуть больше деталей и ссылки на библиографию.

Ботнеты из зараженных серверов под управлением ОС на базе *nix становятся все более популярными у злоумышленников. Широкий канал, отличный uptime и мощное железо делают сервера привлекательной целью для заражения. Принято считать, что для полноценного заражения *nix-системы нужно обладать правами root. Однако злоумышленники придумывают все новые и новые способы извлечения из зараженного сервера максимума пользы, довольствуясь при этом маленькими привилегиями. В этом посте мы расскажем о довольно нестандартном ботнете под названием MAYHEM, состоящем из зараженных серверов.



Изначально MAYHEM представляет собой php-скрипт, который после запуска определяет архитектуру системы (x86 или x64) и наличие прав на запись в текущую директорию. Эти привилегии в подавляющем большинстве случаев есть у пользователя, под которым запущен веб-сервер, и в данном случае их достаточно для работы бота.

В последнее время в нашу службу поддержки стали больше жаловаться на сомнительную рекламу и всплывающие окна на главной странице Яндекса. Люди сообщали, что нежелательная реклама преследует их и на других популярных ресурсах и в социальных сетях (Mail.ru, Вконтакте и т.п.). Команда безопасного поиска Яндекса решила разобраться в чём же дело.



Мы проанализировали состояние систем обратившихся пользователей и увидели, что у них всех на компьютере было установлено рекламное программное обеспечение класса Adware, которое и было источником появления баннеров с сомнительной рекламой, порнографией и другим нежелательным контентом. Выяснилось, что существует целый ряд программ с разными названиями, но действуют они похоже, а результат работы практически идентичен. Аналитики решили не останавливаться на достигнутом, копнуть глубже и проанализировать алгоритмы работы этих программ.

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

Злоумышленники постоянно совершенствуют методы внедрения вредоносного кода на веб-страницы зараженных сайтов. Если раньше это бывала модификация статического контента или php-скриптов CMS, то сейчас прибегают к использованию более сложных техник.



В наши дни чаще всего заражению подвергается веб-сервер: устанавливаются вредоносные модули, внедряются вредоносные shared objects, либо же исполняемый файл перекомпилируется с вредоносной функциональностью. Для внедрения вредоносного JavaScript активно используется, например, Flash.