alsafr

Поймал себя на одной особенности просмотра результатов поиска. На первой странице с результатами я просматриваю сниппет за сниппетом сверху вниз. Дойдя до последнего (10-го) сниппета, я кликаю по ссылке на вторую страницу с результатами. Понятно, что в момент клика взгляд сфокусирован в нижней части окна браузера, т.е. там, где находится линейка с номерами страниц. Поймал же я себя на том, что в момент появления второй страницы с результатами я не всегда переношу внимание в ее начало. Иногда взгляд остается там, где раньше находилась линейка с номерами страниц, а теперь находится 6-й или 7-й сниппет 2-й страницы. После этого я продолжаю просмотр результатов снизу вверх, к 1-му сниппету 2-й страницы. Другими словами, порядок просмотра сниппетов изменяется как при бустрофедоне.
Возможно, это вызвано неким бессознательным стремлением к экономии усилий. Собственно, если очередная страница показывается мгновенно после клика на ее номер, то пользователь гарантировано увидит (но не обязательно прочитает и осознает) сначала не первый сниппет на следующей странице, а тот, который появится на месте клика. Разумеется, это работает только в том случае, если переход осуществляется с помощью клика мышью, а не клавиатурным шорткатом.

Все это навело меня на следующие соображения:
1. Возможно, картина распределения внимания пользователя для второй страницы не будет укладываться в схему "золотого треугольника".
2. Возможно, распределение кликов на второй и следующих страницах будет иметь небольшой всплеск в районе 6-го сниппета.
3. Возможно, что хорошей метрикой для оценки качества поиска будет такая метрика, которая исходит из предположения, что порядок просмотра сниппетов известен только для первой страницы.
4. Возможно, имеет смысл размещать линейку с номерами страниц не только в конце страницы, но и в ее начале (для всех страниц, кроме первой).

Недавно наткнулся на статью "Продолжительность жизни зависит от знака зодиака". Сотрудники некоего "американского Центра астрологических исследований" собрали статистику по продолжительности жизни большого количества случайных людей и обнаружили связь с их знаком зодиака. Как обычно в таких случаях, ссылка на оригинальное исследование в статье отсутствует. На самом деле, существует две версии этой статьи: в одной из них проведение эксперимента приписывается уже не "Центру астрологических исследований", а некоему "профессору Фиклингу". Данные о продолжительности жизни в этих версиях несколько различаются, однако в обоих случаях действительно можно наблюдать ее связь со знаком зодиака.
Проверим?

Good news, everyone! Поиск на hh.ru теперь расширяется близкими по смыслу выражениями. Например, по запросу "вексельные операции" будут также найдены документы, которые содержат словосочетание "операции с векселями".
Многие устойчивые словосочетания можно преобразовать путем изменения части речи одного из слов, при этом смысл словосочетания сохранится. Мы научились автоматически выполнять такие преобразования в запросах пользователей для того, чтобы увеличить полноту результатов поиска.

Еще примеры словосочетаний, которые считаются одинаковыми по смыслу в нашем поиске:

• "бюро переводов" и "переводческое бюро"
• "счетчики газа"и "газовые счетчики"
• "прописка в москве" и "московская прописка"
• "одежда для детей" и "детская одежда"
• "сувениры из фарфора" и "фарфоровые сувениры"

Хорошее дополнение к раскрытию аббревиатур, учету транслитерации, сокращений и прочим видам синонимии, уже поддерживаемым нашим поиском.

1. Берем статью "Даты конца света" из Википедии.
2. Определяем плотность концов света по месяцам.
3. Строим график.

Очень подозрительный месяц.
Но на это раз, кажется, пронесло;)

Ларек в переходе недалеко от офиса:
( Фото )
Первое правило успешного бизнеса: продавать людям зажигалки.

С некоторой натяжкой этап семантического анализа в "семантических" поисковых машинах можно сравнить с процессом перевода. Поисковик как бы переводит текст "для себя", в свой внутренний язык.
В Exactus, например, этим внутренним "языком" является последовательность выделенных из текста синтаксем, для которых определено значение (семантический падеж). В системе SEUS "переведенный" текст должен представлять собой последовательность RDF-триплетов.
Теоретически, такой "перевод" документов и запросов может улучшить качество поиска (за счет снятия полисемии и прочих полезных эффектов).
Интересный вопрос, который может здесь возникнуть - а почему-бы в качестве "внутреннего языка" не попробовать использовать какой-либо из искусственных языков? Существуют искусственные языки, отличающиеся особой точностью и логичностью - например, ифкуиль. Что будет, если переводить текст документов и запросов на этот язык?
На самом деле, этот вопрос достаточно праздный, поскольку такой перевод ничуть не легче реализовать, чем адекватный перевод на другой естественный язык. Впрочем, было бы очень интересно сравнить качество поиска по англоязычной коллекции с качеством поиска по коллекции на ифкуиле.
Однако, существует искусственный язык, перевод на который естественного языка представляется мне вполне решаемой задачей, сравнимой по сложности с переводом на "внутренний язык". В токипоне всего лишь 120 корней. Большинство объектов и понятий в языке передаются описательно. Например: алкоголь = telo nasa ("жидкость безумная"); кровь = telo loje ("жидкость красная"). Очевидно, такая описательная структура языка позволяет объединить в один "концепт" все слова-синонимы, а также явным образом указывает на связь между гипонимами и гиперонимами.
Что будет, если в ранжирующий алгоритм добавить фактор токипона-релевантности?

На РОМИП-2009 Яндекс рассказал про метрику pfound, предназначенную для оценки качества поиска. По словам Павла Карповича, эта метрика "хорошо себя зарекомендовала". Насколько я понял из ответов Павла, в Яндексе считают, что pfound лучше стандартных метрик РОМИП прогнозирует удовлетворенность живого пользователя результатами поиска.

Что же из себя представляет pfound? Рассмотрим модель, в которой пользователь последовательно просматривает выдачу сверху вниз в поисках релевантных документов. Этот просмотр прекращается в том случае, если пользователь встретил удовлетворяющий его документ, либо если ему просто надоело. Метрика pfound в этой модели оценивает вероятность найти релевантный документ.

Пока труды семинара не опубликованы, могу кратко рассказать о некоторых докладах.

Опубликована предварительная программа очной части РОМИП-2009 (я там тоже буду выступать).
Кстати, KM.ru уже опубликовал свою статью: С. Татевосян, Н. Брызгалова. KM.RU на РОМИП-2009. Получение стабильных результатов на разных коллекциях.

Как все уже, наверное, знают, Гугл открыл для тестирования новую версию поисковика под кодовым названием Кофеин. Analyzethis пока не оценивает качество нового гуглопоиска, поэтому, возможно, кому-то будут интересны результаты моего тестирования. Я протестировал навигационный поиск по традиционной методике, основу которой составляют запросы, подразумевающие в качестве ответа конкретный сайт (например, запрос "шадринское тепловозо-вагоноремонтное объединение"), которым соответствует набор сайтов-маркеров. Для тестирования использовалось 400 запросов, из них около 20% пересекаются с запросами из ашмановских навигационных тестов.

	Навигационная метрика Ашманова	precision(1)
Обычный Google	0,9025	0,7625
Google Coffeine	0,9025	0,7825

Здесь под "Навигационной метрикой Ашманова" я понимаю долю запросов, для которых на первой странице найден сайт-маркер.
Как видим, Кофеин по метрике precision(1) показывает более высокие результаты. Значение метрики Ашманова совпадает, поэтому не исключено, что после добавления нового гугловского поиска на analyzethis преимущество Кофеина там будет не совсем очевидным.

• Google Caffeine.
• Help test some next-generation infrastructure. Новость о новом поиске в официальном блоге Google.
• Google Caffeine: A Detailed Test of the New Google. Небольшое тестирование нового поиска.
• Google Caffeine Test Suggests Too Much Emphasis on Real-Time Indexing. Еще одно тестирование.
• Про тестирование навигационного поиска на Analyzethis.
• Гулин. Про измерение искалок. (Почему к данному тестированию нужно относиться осторожно). 

Мы запустили поиск похожих резюме. Суть этой функции состоит в том, что по резюме-образцу автоматически находятся другие резюме, похожие на него. "Похожесть" определяется не только по формальным критериям (совпадение региона, близость зп и т.д.), но и на основании автоматически извлеченных из текста резюме ключевых слов (features). Эти ключевые слова расширяются с помощью тезауруса. Допустим, в оригинальном резюме встречается слово "фастфуд". Тогда в "похожих" резюме, скорее всего, встретится что-то из этого списка: fastfood/ресторан быстрого обслуживания/макдональдс/ростикс/и т.д.
На самом деле, помимо "похожих резюме", на hh.ru работают также "похожие вакансии", равно как и автоматическая подбиралка подходящих резюме на вакансию и подбиралка подходящих вакансий для резюме. Эти функции были доступны уже достаточно давно, но сейчас я действительно доволен качеством их работы.

Компания Ocarina Networks организовала соревнование по сжатию данных. Конкурс был анонсирован еще в сентябре 2008, но регистрация участников, насколько я понимаю, стала возможной относительно недавно.
Общий призовой фонд конкурса составляет $1 млн. Призы в размере $10 тыс. получают участники, которые улучшили предыдущий лучший результат хотябы на 2%.
Немного о схеме участия в соревновании. После регистрации на сайте конкурса можно получить доступ к открытой части тестовой коллекции. Эти данные участники могут использовать для настройки своего алгоритма сжатия. Затем участник высылает организаторам свой компрессор, с помощью которого они сжимают закрытую часть тестовой коллекции. Необходимо, чтобы компрессор уложился в отведенные ему ресурсы (время и память). Тестовая коллекция включает данные в формате jpeg2000 и h.264 (видимо, в этом случае речь идет о переупаковке уже сжатых файлов), а также набор CAD-файлов.

Материалы по теме:
Ocarina prize. Сайт конкурса.
Ocarina Bets $1 Million on Green Large-Scale Data Storage.
Hutter Prize. Еще один конкурс по сжатию за деньги.
Calgary Corpus Compression challenge. Старенький конкурс на сжатие с денежным призом.

На searchengines.ru обсуждают подмешивание Википедии в основную выдачу Яндекса. Судя по всему, можно говорить о введении нового вида "колдунщика".
Для меня самое интересное состоит в том, что при поиске по атрибутам вики-шаблона в сниппете выделяется жирным также значение этого атрибута. Например, при запросе "направление достоевского" выделяется слово "реализм", хотя его и не было в исходном запросе:

Выделение жирным говорит о том, что Яндекс "знает", что ответом на вопрос "тип подвески Т-34" является "подвеска Кристи". Можно предположить, что Яндекс пропарсил шаблоны Википедии аналогично тому, как это сделала Нигма. Не исключено также, что значения атрибутов используются для расширения запросов - по крайней мере, это было бы логично.

Как известно, часть информации в интернете не индексируется поисковыми машинами. С помощью тегов noindex/nofollow и файла robots.txt некоторые страницы исключаются из баз поисковиков.
В связи с этим возникла безумная идея "пиратской" поисковой машины, предназначенной специально для индексации контента, индексация которого запрещена. Бот такого поисковика должен сканировать веб, невзирая на запрещающие теги. При этом в индекс должны заноситься только те страницы, которые закрыты от обычных поисковиков.
Я не возьмусь точно оценивать объем запрещенного к индексации контента, но предполагаю, что он гораздо меньше объема остального интернета. Если это так, то затраты на запуск и поддержку "черного" поисковика должны быть незначительны.
Зачем это нужно? Возможно, такая пиратская поисковая машина могла бы стать популярной в качестве дополнения к традиционному Яндексу/Гуглу. Другими словами, людям было бы интересно находить те страницы, которые гарантированно не найдет их любимый поисковик.
К сожалению (к счастью), недостатки концепции  очевидны. Во-первых, идея сомнительна с правовой/этической точки зрения. Не знаю, можно ли создателей подобного поисковика было бы привлечь к ответственности, но вот ухудшение кармы им было бы гарантировано:) Во-вторых, у меня есть подозрение, что в закрытом вэбе все равно нет ничего интересного.

Какие интересные технологии оценки персонала порой встречаются! Эти ребята производят оценку персонала с помощью "экстрасенсорных методов". Удаленно. По фотографии.
Позволю себе пару роскошных цитат:Рекрутеры-астрологи тут просто отдыхают... я уже не говорю про относительно безвредных эйчаров-"психологов" :)

Rada Mihalcea, Hugo Liu. A Corpus-based Approach to Finding Hapiness.

Краткое содержание статьи:
1. Взяли посты из ЖЖ, у которых в поле "настроение" стоит "happy" или "sad".
2. С помощью наивного байеса выделили самые важные для классификации слова и вычислили для них "фактор счастья" - отношение частоты в "счастливых" постах к общей частоте. Одно из самых "счастливых" слов - shopping. Самое несчастное слово - goodbye.
3. Аналогичным способом определили "счастливые" и "несчастные" словосочетания. Заметную долю в "счастливом" списке составляют словосочетания, упоминающие о чем-то новом: "my new", "my first". "Несчастный" топ начинается со словосочетаний "i wish" и "don't understand".
4. Оценив распределение "счастливых" слов по времени, определили самое счастливое время суток (21:00) и самый счастливый день недели (суббота).

Финальный рецепт счастья выглядит следующим образом:
Go shop for something new – something cool, make sure that you love it. Then have lots of food, for dinner preferably, as the times of breakfast and lunch are to be avoided. Consider also including a new, hot taste, and one of your favorite drinks. Then go to an interesting place, it could be a movie, a concert, a party, or any other social place. Having fun, and optionally getting drunk, is also part of the recipe. Note that you should avoid any unnecessary actions, as they can occasionally trigger feelings of unhappiness. Ideally the recipe should be
served on a Saturday, for maximum happiness effect. If all this happens on your birthday, even better.

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

Команда Лавренко выделила из русской википедии основные шаблоны и теперь использует это в поисковой выдаче. Наконец-то)
Если по запросу есть заполненный шаблон, то он выводится в левой колонке. Если поисковый запрос совпадает с одним из атрибутов шаблона, то в основную выдачу подмешивается информация о значении атрибута.

Мы запустили поиск с учетом синонимов. Под "учетом синонимов" подразумевается достаточно широкий диапазон преобразований:

• Аббревиатуры. МГИМО=Московский государственный институт международных отношений.
• Спеллинг. HBC=ЭйчБиСи.
• Сокращения. Канцтовары=канцелярские товары.
• Транслитерация. Яндекс=Yandex.
• Одинаковые (или очень близкие) по смыслу должности (это наиболее полезная фишка). Начальник отдела логистики=руководитель подразделения логистики; PR-менеджер=Менеджер по связям с общественностью.
• Географические синонимы. Беларусь=Белоруссия.
• Склеивание слов в некоторых терминах и названиях. CorelDraw=Corel Draw.
• Учет переименования некоторых учебных заведений. Петербургский государственный университет путей сообщения=Ленинградский институт инженеров железнодорожного транспорта.
• Перевод некоторых терминов. Management by objectives=Управление по целям.
• Некоторые другие случаи.

Структурированная база однотипных документов (резюме и вакансий) предоставляет широкие возможности по выявлению близких по смыслу выражений, - чем мы и воспользовались. База синонимов формировалась в полуавтоматическом режиме. С помощью специальных алгоритмов подготавливались списки кандидатов в синонимы, которые затем проверялись человеком. Использование синонимов в нашем случае приводит к значительному увеличению полноты поиска без падения точности.
Новость на hh.ru
Страница поиска вакансий на hh.ru

Я достаточно хорошо понимаю elada , когда она сравнивает Яндекс.Пресс-портреты с башоргом. Кстати, к группе моих любимых багов, состоящей из Карла "Карловича" Маркса и Гарри "Ивановича" Поттера, недавно добавился прекрасный персонаж по имени Аллах Акбар.
Resumagic порой генерирует не менее прекрасных персонажей. Однажды для тестирования механизма отличения резюме от всего остального мы подписали Resumagic на кучу разнородных рассылок. В результате мне пришлось столкнуться с соискателями по имени Любовь Яростная (образованного из словосочетания "яростная любовь") и Роман Любовный ("любовный роман"). Кроме того, одно из ложных срабатываний привело к попаданию в поле "желаемая должность" профессии "бронзовый солдат".