Илья Сегалович в своем ЖЖ дает ссылку на статью Яндекс на РОМИП-2004. Некоторые аспекты полнотекстового поиска и ранжирования в Яндекс.
Ну наконец-то что-то полезное.
Хотя многое было интуитивно понятно.
По пунктикам:
Основной поисковый оператор Яндекса — «многоместный оператор AND» с неявно назначенными ограничениями контекста между соседними словами запроса.
– “ограничения контекста” – я сначала подумал, что речь идет о расстояниях в предложениях и словах, которые вставляет колдунщик. Но в конце статьи промелькнуло, что еще в пределах документа – один из возможных контекстов.
Кстати, в ЖЖ Илья объясняет подробнее про это:
Теперь о логическом уровне. О нем говорится фразой “многоместный оператор AND”. Ну то есть мы не делаем так: A /1 B /1 C => X = (A /1 B); Y = X /1 C
Пример:
Опорные слова в пассаже (1) выглядят так: _ _ a b a c _ _
Опорные слова в пассаже (2) выглядят так: _ _ a b c _ _Двуместная логика при упрощенной реализации может привести (и приводило годах в 1995-1996) к нахождению лишних пассажей. Скажем, по указанному выше запросу может быть найден не только пассаж (2) но и пассаж (1). А ведь слова B и C должны стоять рядом!
Что касается неявного назначения контекста, то мы про это писали: контекст назначается как правило, не пользователем, а на стадии препроцессинга запроса.
-ну точно, колдунщик. Спешите видеть. Пока переколдованный запрос еще виден.
Принципиальной особенностью Яндекса является оперирование только позициями слов, удовлетворяющих ограничениям контекста. Это позволяет резко сократить число операций над документами.
-о! ну и позже говорится, что частота вычисляется только по соовам удовлетворяющим огр. контекста.
о процедуре вычисления неявных контекстных ограничений, применяемой в распределенной версии поиска Яндекса. В этом случае на серверах «переднего края» [6] производится синтаксический разбор запроса на основе ATN-грамматики [7], адаптированной к свободному порядку слов русского языка. С учетом рваного «телеграфного» стиля в естественно-языковых фрагментах запросов выявляются несколько видов синтаксической связей (притяжание, перечисление, зависимости цели и места, счетные конструкции и др.) и устанавливаются эмпирически подобранные контекстные ограничения.
…и между словами вставляются расстояния в предложениях, словах и т.п. Так, пойти посмотреть, как они эти притяжания и перечисления в результатах переколдовки представляют. И алгоритм не нужно думать – спасибо, сами сказали. 🙂
синтаксический разбор запроса на основе ATN-грамматики [7], адаптированной к свободному порядку слов русского языка
-не понял, что за грамматика и адаптация к свободному порядку слов. Пойти почитать.
Глобальная для всех коллекций статистика слов используется как для «выравнивания» ранжирования между коллекциями [6]
-не понял. Учет IDF или что… Коллекция – это же вся база документов.
Имея на входе многоместного оператора треугольную матрицу контекстных ограничений между словами запроса
-почему треугольную?… Видимо, это они многоместный оператор “И” так реализуют. Тогда получается, что некоторая кривизна в ограничении контекста между “далекими” словами будет присутствовать…
Яндекс осуществляет процесс нахождения всех пассажей в документах, удовлетворяющих этим ограничениям, с учетом оператора нечеткого поиска с неявно назначенным коэффициентом «мягкости» [8]. Коэффициент мягкости (число от 0 до 100) задается при помощи следующего синтаксиса:
(несколько слов с контекстными операторами)//МЯГКОСТЬ
-теперь понятно, что это за число после //. Хотя по их дальнейшим графикам это скорее жесткость. Проверить на выдаче.
Оператор AND сильно сужает область поиска с каждым новым термином. Применение AND к запросам с большим количеством терминов (более 5) приводит, как правило, к пустому списку найденных документов. Оператор OR, наоборот, расширяет область поиска с каждым новым термином. Применение OR к запросам с большим количеством терминов (более 5) приводит к длинному списку найденных документов. По этой причине: а) неоправданно расходуются ресурсы компьютера, б) длинный список найденных документов труднее адекватно ранжировать.
-таки еще раз… В колдунщике никаких операторов OR нет, там только AND на расстоянии в несколько слов или предложений… Откуда берется OR? 1) либо это было “для поиграться” на РОМИПе, либо 2) видимый нами колдунщик не есть правильный либо 3) OR – это AND с расстоянием в 7 предложений вперед-назад. 🙂
Идея кворума в поиске не нова, ее аналогом в процедуре фильтрации релевантных пассажей можно считать принцип «weighted coordination match» [9], при котором «найденными» считаются все полные пассажи, а также все неполные, сумма весов слов которых превосходит необходимый кворум
-ну понятно, веса написаны в переколдованном запросе… Итак, одно редкое слово может перекрыть много частых. Только не написано, кворум этот самый – он тоже индивидуально рассчитывается для каждого запроса (логично было бы) или жестко установлен от числа слов в запросе? Судя по дальнейшему изложению, могут играть оба варианта – кворум то в словах, то в процентах нарисован… Или мягкость меняется от запроса?
QuorumWeight=(1-Softness)^((ЧислоСлов-1)^-1/2)
-собственно, жестко от числа слов, а мягкость они ставят неизвестно как… Не дочитал. Пока не проговоришь, не поймешь.
при Softness=50 число найденных документов должно быть примерно средним геометрическим чисел найденных документов при поиске всех возможных неполных пассажей
-Как это, softness же в интервале (0,1)…??? Наверное, число за // на 100 делится…
В частности, при равных по весу словах запроса и коэффициенте мягкости 0.06 (того, что использовался при выполнении заданий РОМИП), в пятисловном запросе достаточно 4-х слов (или 76% веса), а в 16-словном всего лишь 8 слов (или 52% веса) для преодоления кворума.
-говорили, 6 – стандартная мягкость…
Формула для вычисления веса слова при голосовании по кворуму отличается от формулы, используемой при ранжировании.
-каком еще голосовании?
Если при ранжировании Яндекс использует классический для IR логарифм обратной частоты, то при вычислении суммы голосов в кворуме применяется степенная функция с показателем между квадратным и кубическим корнем. Отличия состоят в том, что «вариант с корнем» больше ориентирован на учет “тяжелых”, “редких”, “новых” слов, пусть и без полного набора соседей, тогда как логарифм тяготеет к максимальному возможному количеству слов в пассаже независимо от их тяжести
-видимо, это относится к расчету суммарного веса пассажа для сравнения его с “цифиркой” -кворумом… Или, может, не так – сумма весов это, типа, весь кворум, а степенная функция – это голос одного слова… Но на кой это надо… Перечитать.
После того, как все пассажи документа, прошедшие фильтрацию по кворуму, определены, наступает этап ранжирования, то есть вычисление веса документа.
-только по прошедшим границу…
Внутри-документная частота по релевантным пассажам
Формула расчета веса слова по отношению к документу («контрастности») в Яндексе использует внутри-документные частоты слов с учетом этапа фильтрации. Иными словами, в классической формуле SUM(TermFrequency*), вычисляющей вес документа по отношению к запросу как сумму контрастностей слов запроса в документе, в Яндексе используется заниженная TF, учитывающая только те словопозиции, которые попали в «интересные» нам пассажи. Фактически Яндекс считает полностью «нерелевантными» все словопозиции слов запроса, не удовлетворяющие контекстным ограничениям.
-т.е., частоты учитываются только по словам, попавшим в пассаж, т.е., стоявшим достаточно близко с другими словами запроса. Поэтому и оптимальной частоты может не сущаствовать.
Ранжирование на уровне словопозиций: расчет веса словопозиции
Полученная контрастность слова распределяется на все его позиции, прошедшие фильтр.
-контрастность – это что, то, что мы при “голосовании по кворуму” получили для слова или что?
Затем по ним происходит итерирование и вычисление веса каждой словопозиции с учетом расстояния до всех остальных слов из запроса, попавших в пассаж. Учет состоит в вычислении сходства этого расстояния с заданным в запросе оптимальным расстоянием.
-таки идет некий возврат к исходному, незаколдованному запросу…
Наконец, веса словопозиций, взвешенные по сходству их полного контекста, «собираются» обратно и образуют вес документа.
-“Собираются”… 🙂 В шпиёны надо было пойти, однозначно. Складываются? Умножаются? 🙂
Расчет веса словопозиции позволяет максимально точно учесть сходство пассажа и запроса. При этом выигрыш получит документ, у которого более «тяжелые», смыслоразличительные слова окажутся в контексте, более похожем на контекст в запросе
-дык.
Функция контрастности
В классической литературе по IR можно встретить разные функции нормирования и сглаживания внутри-документной частоты при вычислении контрастности TF*IDF.
-а, вот она, контрастность. Сначала употребили термин, а потом его объясним. 🙂 Получается, это какая-то переколдованная частота.
Функция Яндекса, подобно функциям Harman и BM25, нормализует внутри-документную частоту по размеру документа.
-что бы это значило… Судя по ссылкам, функция Яндекса похожа на (12) и (13)…
Следует отметить, что в Яндексе используется дополнительный анализ текстов при индексировании для подавления многократного повторения слов в тексте в расчете на повышение ранга документа в выдаче поисковых машин [8].
-о! Ага, ясно, что с учетом всех хитрвы#####ых алгоритмов преимущество получили бы тупые перечисления запросов в дорвеях… 🙂 Главное – правильно подобрать их количество и расстояние между ними…
Функциям весов пассажей, описанным в литературе:
Присущи следующие общие черты:
• Объемлющие пассажи игнорируются
• Позиции внутренних опор не принимаются во внимание
• Ранг неполных пассажей строго меньше ранга полных
• Вес пассажа — плавно убывающая функция, обратно пропорциональная длине (или корню длины) пассажа и его «неполноте»
В функции Яндекса (табулированный набор коэффициентов) также соблюдаются некоторые их этих принципов, в частности, принцип деградации неполных пассажей. Схожим выглядит и убывание при уменьшении сходства с оптимальным расстоянием.
-ага, ну с дефективностью неполных пассажей как-то все уже знакомы, а вот какой контекст используется?… Функция Яндекса – “табуированный” 🙂 набор коэффициентов.
Яндекс использует учет форматирования при ранжировании дважды. При вычислении контрастности слова используется информация о вхождении его в выделенные области текста (заголовки и т.п.). Кроме того, на этапе вычисления веса пассажа, пассажи, полностью попавшие в некоторые зоны документа, получают дополнительные баллы
-таки есть учет, что бы нам не говорил semaster в рассылке А&П 🙂
Яндекс также анализирует форматирование на этапе индексирования
-интересно, на кой? Разве что дорвеи и спам вычислять.
Для Веб-поиска мы вручную выбрали «лучший» вариант из 8-ми: два вида ограничения контекста (предложение и документ), с группированием или без группирования по хостам. Коэффициент мягкости брался в одном случае равным 6 (значение по умолчанию), а в другом — 10. Для нормативной коллекции выбиралось лишь лучшее контекстное ограничение, а группирование не имело значения. Вариант синтаксического преобразования запроса за нехваткой времени испробован не был.
Лучшим вариантом для обеих коллекций мы посчитали: «документный контекст, отсутствие группировки, мягкость 6».
-хе-хе! “Отсутствие группировки по сайтам” был лучше! 🙂
***
Одно непонятно – а чегой-то они так подобрели? Надо бы еще было коэффициенты выложить…
Женя, я думал, что ты мониторишь такие труды.
Для тех, кто ишет полные материалы РОМИПа:
http://romip.narod.ru/romip2003/
http://romip.narod.ru/romip2004/
Там также интересно почитать задания дорожек – что и как надо искать – т.е. над какими задачами поисковики трудятся.
И еще о Яндексе вдогонку: The main objective of the library is to perform search in one or several fulltext databases. The comparison of texts and queries is mainly boolean. Standard search operators are: "AND", "AND_within_paragraph", "OR", "AND_NOT", "AND_NOT_within_paragraph". Apart from that, all those operations can be executed, without a loss in speed, with a restriction on the distance specified as a continuous interval of words or paragraphs.
Users can input their queries in form of boolean contextual expessions or in natural language. NL-queries can be converted into boolean contextual expessions by a syntactic preprocessor (working only in some special cases). Relevant documents are delivered to user in the descending order of the number of query words found in the document. Apart from this default relevance criterion, there are special operations affecting the order of document output, the "refinement" and "weighting" operators. The words of query are hightlighted in the documents delivered to user. The system can perform fuzzy search and «search of a similar document».
Нет, не мониторю, по крайненй мере таким образом, даже сайта этого не знал. А насчет того, что и как искать, – вряд ли это нам, оптимизатрам, полезно. Это ведь задания придуманные и проверенные потом людьми. Вперед поисковикам надо решить задачу, что и как надо искать по каждому из 3-5 миллионов разных запросов. 🙂
> http://romip.narod.ru/romip2003/
выкачал весь сайт как только узнал слово РОМИП
> преимущество получили бы тупые перечисления запросов в дорвеях…
а ты этого не заметил на 3-х словных запросах ?
Вроде нет. Примерчик кинь, а мы посмотрим. 🙂
Теоретически всегда есть такое N, что для N-словных запросов частота кейвода будет оптимальной для тайтла, например.
Или, скажем так: для пассажа. Может, и в тексте.
я по мобильной тематике спама много выношу регулярно … оттуда ноги …
пластиковые раздвижные окна – 1, 2, 3, 10
алкидные эмали порошковые – 2, 3 и по ссылке с дорвея еще и 1.
мобильные телефоны мелодии – 3, 4, 5
Во! супер примеры:
трехмерные изображения интерьеров – первые 9
входные стеклянные двери – все, кроме 4
Ну и как?
Кстати, не такие уж они и тупые, эти перечисления… Например:
—
Через миг Илья перемахнул низенькое ограждение, встал рядом с Тигренком пластиковые раздвижные окна турция.
… сигарету раздвижные пластиковые турция окна. сгорю вместе с этим креслицем, пепел в сигаретную пачку уместится окна пластиковые турция раздвижные.
Или же он решил проверить безопасность новых хозяев пластиковые раздвижные окна турция.
… турция пластиковые окна раздвижные. всю последнюю войну занималась тем, что прикрывала врагов своей страны от проклятий окна пластиковые раздвижные …
… о своей погасшей трубке раздвижные пластиковые турция окна. то похожий на постаревшего Шурика из старых комедий окна турция пластиковые раздвижные.
А что, теперь для каждого запроса, типа "пластиковые окна" будем программно подбирать Контекстные условия по умолчанию, а затем и формулки подбирать для проверки страничек.
почти все известно 🙂
поиграться с расстоянием и весом слов в запросиках, чтобы выдача совпала со стандартным запросом
нам и двух-трех слов хватит.
Господа!
А правильно ли я понимаю термин "пассаж"?
Пассаж – переколдованный текущий поисковый запрос?
Пассаж – это что-то вроде куска найденного в тексте запроса.
Спасибо. Об одном и том же написали, но по-разному. Можно в wiki-SEO помещать.
Пассаж – это часть текста. Как правило, совпадает с предложением. Но если предложение очень длинное, то оно может разбиваться на несколько пассажей.
Мнения разнятся?
euhenio: "кусок найденного в тексте запроса"
wolf: "это часть текста. Как правило, совпадает с предложением."
В 1-м случае это "запрос", во 2-м – запрос с окружением?
wolf более близок к истине, хотя откуда взялось "как правило" – неизвестно. Пассаж он "запросонезависимый".
У Яндекса посик внутри предложения и поиск внутри документа – разные вещи. Логично предположить, что разбивка на пассажи происходит по предложениям. Т.к. размер пассажа ограничен, то слишком длинные предложения могут разбаиваться на несколько пассажей.
http://company.yandex.ru/articles/romip2004.xml
Имеются в виду ограничения, накладываемые колдунщиком. Как известно, колдунщик может вставлять также и ограничения вида &&/(-7 7)
В этом случае, пассажем может стать часть текста документа, содержащая несколько предложений.
а откуда взялось "запросонезависимый"? 🙂
-ну да, конечно, может. Есть еще оператор && 🙂
Да я просто предложил в терминах Яндекса изъясняться, раз уж топик про него 🙂
А из http://company.yandex.ru/articles/romip2004.xml вроде как вытекает, что пассаж зависит от запроса, вернее от контекстных ограничений, заданных пользователем (при помощи операторов) или самим Яндексом. Поправьте, ежли не прав.
Контекстные ограничения, насколько я понимаю, просто прособствуют фильтрации некоторых пассажей, содержащие термины из запроса. А далее, играют роль при назначении весов пассажам, прошедшим кворум. Как бы так.
-я считаю по-другому. Указатели, "в пределах чего искать" как раз и определяют, будут ли найдены одно или несколько слов запроса вместе в качестве пассажа. Т.е., просто они есть условие на пассаж.
А фильтрация найденных пассажей по кворуму (с расчетом весов и т.п.) происходит уже после отбора пассажей. Это, кстати, по статье можно посмотреть.
Вообще-то, хотелось бы услышать самого начальника транспортного цеха 🙂 Он же сказал, что эта статья чтобы ‘все же объяснить, тем "кто понимает" ‘. Надеюсь, он не откажется от комментариев – мы же, вроде, "пытаемся понять" 🙂
В статье (http://company.yandex.ru/articles/romip2004.xml) есть определенные легкие нестыковки, объясняемые замалчиванием некоторых фактов или оговорками/описками. Но если строго следовать букве статьи, то вывод о "запросонезависимости" пассажа сделать очень затруднительно 🙂
Более того, если проследить за мыслью, можно обнаружить, что сам по себе пассаж, вроде как и не причем. И при ранжировании документов такое понятие, как вес пассажа не используется.
euhenio, Вы, вроде не против "запросозависимости" пассажа 🙂
Хотите вопрос на засыпку? 🙂
Запрос: слово1&&/(-7+7)слово2
Документ:
В этом документе, при таком запросе Яндекс найдет (и подсветит) и слово2 и оба слово1.
Вопрос: сколько в этом документе релевантных пассажей?
Т.е., ты хочешь сказать, что если используется поиск во всем тексте (например, с использованием оператора &&), то весь текст будет одним пассажем? Я так не думаю.
Кот, в статье есть еще магическая фраза "объемлющие пассажи игнорируются". 🙂 Я не знаю точно. как ее понимать, но тут как раз типа запрос А & Б, документ A Б А Б А Б – будет ли все это одним пассажем или несколькими? Оно должно быть несколькими пассажами, т.к. иначе в длинных запросах (с разными словами) за счет повторения одного слова из запроса можно превысить кворум.
wolf,
-я думаю, что сам текст "между" словами не включается в пассаж, а включаются только слова запроса и относительные их позиции. А так – представь себе документ, в разных концах которого слова А и Б, и заспрос А && Б – конечно, сами слова войдут в найденный пассаж. А что между ними – неважно.
-подсветчик может подсвечивать "объемлющие пассажи", у него ведь может быть другой алгоритм – если попадает в контекстные ограничения, то все ОК, он и подсвечивает…
И все-таки я склонен склониться к версии о "запросонезависимости" разбиения документа на пассажи. В данном случае просто оба пассажа (который в начале со словом А и который в конце со словом В) пройдут кворум и потом получат максимальные веса.
-если ты имеешь в виду, что в этом случае ДВА пассажа возникает (неполный для А в начела и неполный для Б в конце), то по расчету при близких весах слов А и Б ни один из пассажей не пройдет кворум. Там есть формула для весов пассажей – пассаж, проходящий кворум должен иметь 0.94 примерно от общего веса (после возведения весов в степень 0.38 ).
Для слов А и Б с близкими весами веса каждого из неполных пассажей будут примерно 0.5 от веса идеального пассажа и кворум не пройдут.
Если следовать букве статьи, то эта фраза не относится к алгоритму Яндекса. А до появления Ильи Сегаловича сотоварищи 🙂 кроме как на букву, ссылаться не на что 🙂
Это легко проверить:) И, потом, что мешает при расчете кворума не учитывать повторяющиеся слова пассажа?
wolf, мне понятно, что Вы имеете в виду. Скажите, не кажется ли Вам, что следующая цитата из http://company.yandex.ru/articles/romip2004.xml опровергает Ваши слова?
Т.е., чтобы пассаж преодолел кворум, надо, чтобы слова, позволяющие ему преодолеть кворум были в нем, а не в других пассажах. В Вашем же примере (со словами А и В, находящимися в разных пассажах) кворум не будет преодолен (например, при сходных весах слов). А это противоречит тому, что мы можем наблюдать.
wolf, почему Вы не хотите увидеть, что такое понятие как "вес пассажа" не используется при ранжировании? Не исключено, конечно, что я ошибаюсь. В таком случае, покажите мне, из чего можно сделать вывод о том, что Яндекс хотя бы вычисляет вес пасажа (не говоря уже про использование этого веса при ранжировании).
Есть еще вот какие соображения.
Учитывая следующее:
Имеем текст "А_Б_Б.", удовлетворяющий контекстным ограничениям запроса "А&Б". Для простоты допустим, что веса слов А и Б одинаковы.
Учитывая приведенную выше цитату, можно предположить, что неважно, состоит этот текст из двух пассажей (А_ _ _Б и А_Б) или из одного (А_Б_Б).
Почему не важно? Потому, что нам надо определить, каким именно образом происходит вычисление веса каждой словопозиции. Именно это является главным вопросом, а вопрос о количестве пассажей всего лишь может послужить ключем (причем, сомнительным) к решению.
Поэтому, предлагаю попытаться решить вопрос о вычислении веса каждой словопозиции, безотносительно вопроса пассажей.
Сперва разберемся с двумя словопозициями слова Б. Очевидно, что вес первой из этих словопозиций выше, чем второй т.к. расстояние от первого слова запроса (А) до первой словопозиции слова Б меньше, чем до второй. Впоследствии, когда будет вычисляться вес документа относительно запроса, веса всех словопозиций всех слов запроса проссуммируются и составят вес документа относительно запроса.
Возникает вопрос: может быть, вес второй словопозиции слова Б не учитывается (т.к. слово А единственное)? Резонный вопрос. Но, если так, то тексты А_Б и А_Б_Б по отношению к запросу А&Б будут иметь одинаковый вес, что сомнительно с точки зрения здравого смысла. Есть и другие доказательства учета второй словопозиции слова Б (основанные на выдержках из статьи).
Самое интересное и неоднозначное начинается на этапе вычисления веса словопозиции слова А. Не совсем понятно, вес этой словопозиции будет иметь одну составляющую, определяемую расстоянием до первой словопозиции слова Б, или к ней приплюсуется составляющая, определяемая расстоянием от слова А до второй словопозиции слова Б? С одной стороны (обращаясь к здравому смыслу), слово А единственное, почему мы должны увеличивать его вес только потому, что в куске текста, удовлетворяющем контекстным ограничениям, присутствует более одного другого слова из запроса?
С другой стороны (также обращаясь к здравому смыслу), обе словопозиции слова Б удовлетворяют контекстным ограничениям запроса. Т.е. однозначно предполагается, что оба слова Б употреблены в контексте слова А. Соответственно, документ (А_Б_Б) где в контексте со словом А употреблены два слова Б должен иметь бОльший вес относительно запроса, чем документ вида А_Б. Но он и так будет иметь больший вес, т.к. выше мы условно доказали, что вес второй словопозиции слова Б учитывается при вычислении веса документа по отношению к запросу. Т.е. речь идет о том, усиливается ли вес документа А_Б_Б по сравнению с документом А_Б еще больше за счет описанного выше увеличения веса слова А за счет второй словопозиции слова Б?
Но Сегалович упоминает понятие веса пассажа в Яндекса как "табулированный набор коэффициентов" в пункте "Коэффициент контекстуального сходства". Лукавит? И почему не используется? Неполные пассажи, к примеру, весят меньше полных, хотя могут содержать больше ключевиков в абсолютном плане. Поэтому очень трудно увидеть, чтобы "нестрогое соотвествие" в выдаче обгоняло бы "строгое". То что длина пассажа не влияет на его вес – это да, очевидно. Но Сегалович упоминает только о том, что в яндексовской функции веса пассажей "соблюдаются некоторые их этих принципов"
А кто сказал, что при запросе типа (фраза1)&&(фраза2) кворум расчитывается по всем словам из конструкции фраза1+фраза2. ИМХО, выбираются пассажи, которые проходят кворум по любой из фраз.
-кворум рассчитывается по запросу целиком. Т.е., по сумме фраз. А какие там стоят операторы – неважно. Вот несколько цитат из статьи:
-полный пассаж, понятное дело – который содержит все слова запроса.
-подписи к иллюстраицям.
-заметьте, никаких операторов! 🙂
Короче говоря, я считаю, что по всем словам запроса считается кворум.
Давайте смотреть:
Явно описан алгоритм расчета веса документа относительно запроса. Алгоритм логичный и самодостаточный. В нем не только не упоминается "вес пассажа", но и нет для него места – все рассчитывается исходя из весов словопозиций.
Он не упоминает понятия веса пассажа в Яндексе. Раздел озаглавлен "Коэффициент контекстуального сходства" и речь в нем идет о сравнении вычисления контекстуального сходства в Яндексе и других системах.
Фраза
демонстрирует результат ранжирования, а не сам процесс.
ИМХО, коэффициент контекстуального сходства применяется яндексом (и это явно указано в статье) при пересчете весов словопозиций – вот тогда-то и применяется этот табулированный набор коэффициентов.
Не используется при ранжировании. Сам термин "вес пассажа" может и использоваться. Он может нагляднее и быстрее объяснить результат работы алгоритма, основанного на расчете веса словопозиции.
Это результат работы алгоритма взвешивания словопозиций с учетом контекстуального сходства. Другими словами, приведенным Вами фактом сложно объяснить наличие учета веса пассажа при ранжировании.
Ну, вот и получается твое ИМХО на мое ИМХО. В статье идет речь об общем случае, а как уж он распространяется на частные – тут каждый домысливает сам. 🙂
Как же не упоминает? Он упоминает свойства, присущие известным функциям весов пассажей, описанным в литературе и сравнивает с ними функцию Яндекса. Функцию чего, позвольте поинтересоваться. 🙂
А вот в следующем пункте "Учет форматирования текста" идет вообще прямое упоминание понятие веса пассажа в Яндексе:
И уж поверьте, вес пассажа, попавшего в тег <title>, при прочих равных отличается от веса такого же пассажа в <body>. Это Вам в качестве наглядного факта, которым можно объяснить наличие учета веса пассажа при ранжировании 😉
-ну почему же, свое мнение я основываю на статье. Если можешь, покажи, где хотя бы теоретическая возможность "частных случаев", при которых ЧАСТИЧНЫЕ соответствия рулят как и полные, в статье рассмативается. 🙂
Везде там только про расчет веса отностиельно ПОЛНОГО запроса, что логично.
Жень, на основании одной только статьи некорректно судить. Вещь в себе получится. Да и статья трехлетней давности, причем, написанная под карманный тест РОМИП… На многое, конечно, глазки открывает, но в качестве Святого Писании ее использовать нельзя… 😉
Имеешь примеры, которые противоречат этому? 🙂 В качестве Святого писания лучше использовать здравый смысл, который находится в согласии со статьей 🙂
ЗЫ Плиз, входи только с одного аккаунта, второй я грохну.
В качестве ответа, процитирую и себя и Вас:
Он не упоминает понятия веса пассажа в Яндексе. Он упоминает свойства, присущие известным функциям весов пассажей, описанным в литературе и сравнивает с ними функцию Яндекса.
Я понят? 🙂
Функцию, при помощи которой рассчитываются веса словопозиций уже с учетом контекстуального сходства. Перед применением этой функции, каждая словопозиция одного и того же слова имела одинаковый вес. Применяем функцию, и она пересчитывает вес каждой словопозиции. В принципе, если после этого пересчета проссумировать веса всех словопозиций пассажа, то получится вес пассажа. В литературе описаны функции весов пассажей, но в литературе нет аналогов Яндексовскому алгоритму. Поэтому, поведение этих, описанных в литературе функций, сравнивается с поведением функции Яндекса. При проведении такого сравнения, удобно оперировать виртуальным понятием веса пассажа в Яндексе.
Снимаю шляпу. За все время изучения статьи я не обратил внимания на эту фразу. Значит вес пассажа все таки вычисляется.
И без этого видно, что в статье явно указано на вычисление веса пассажа. Позже я позволю себе вернуться к этому Вашему высказыванию, но в другом контексте.
Теперь я признаю факт вычисления Яндексом веса пассажа, но это только вносит дополнительную стройность в мое представление о работе алгоритма.
Давайте смотреть:
Допустим алгоритм кворума уже отработал и определил все пассажи, преодолевшие кворум. Уже вычислены контрастности всех слов пассажей по формуле TF*IDF.
Т.е. все словопозиции конкретного слова запроса имеют одинаковые контрастности.
А вот это уже работа той функции (которую мы обсуждали), при помощи которой рассчитываются веса словопозиций уже с учетом контекстуального сходства. В результате работы этой функции происходит пересчет весов (контрастностей) словопозиций во всех пассажах документа. И получаются "веса словопозиций, взвешенные по сходству их полного контекста"
Вот здесь, видимо, я и ошибался. Я думал, все так буквально и происходит – просто просуммировали веса всех словопозиций и получили вес документа. Но, получается, что веса словопозиций суммируются сперва попассажно, образуя вес пассажа. Судя по всему это необходимо, чтобы можно было увеличить вес пассажам, удовлетворяющим каким-либо условиям (например, если пассаж "полностью попал в некоторые зоны документа"). После этого вес документа получается путем сложения весов всех пассажей.
Где-то так… 🙂 Как видите, с Вашей помощью я скорректировал свой взгляд на работу алгоритма. Голову пеплом не посыпаю – выше я допускал, что могу что-то упускать и старался использовать политкорректные формулировки 🙂 Однако, и Вы можете заметить, что произошли мизерные коррективы. Да, вес пассажа вычисляется, но это далеко не основа алгоритма, а последний штрих. Ни та функция, о которой вы говорили, ни другие ключевые моменты алгоритма не используют вес пассажа.
Другими словами, пассаж запросозависим 🙂
В противном случае, наблюдаем противоречие – если тег тайтл является пассажем, то как в него может попасть пассаж?
P.S. Этот пост надо рассматривать в контексте всех предыдущих постов топика.
Как-то Вы уж очень вольно интерпретировали мои слова. Хотелось бы более подробно проследить логическую цепочку, по которой из моих слов следует, что разбиение на пассажи запросозависимо.
Чему противоречат? Статье? Ну, по крайней мере, утверждение о том, что
на данный момент не соотвествует действительности.
Ок. Сорри за создание второго аккаунта, просто пароль в рабочем ящике остался, а мысль боялся забыть… 🙂
А это с какой строны посмотреть. На мой взгляд, неполный пассаж просто глушат каким-нибудь мощным коэффициентом. Т.е. высчитывают веса между вошедшими в него терминами по общей формуле и как бы штрафуют их за отсутствие некоторых терминов. Вот допустим, запрос А В С. Пусть пассаж, содержащий термины А и С, прошел кворум. Вычисляют веса терминов А и С, как будто бы запрос был А любое слово С, т.е. А /+2 С, а потом штрафуют мощно за неполность. Как бы так. Но это чисто гипотеза. Я пока не проверял, ибо жалко время терять на возню с неполными пассажами в виду их низкой ценности. Только если чисто для обеспечения строгости картины когда-нибудь руки дойдут 🙂
wolf, примеры не того, как что там нормализуется :), а примеры того, что:
слова в пределах документа А и Б (в начале и в конце) по запросу А && Б находятся как "частичное соотвествие", когда должно быть "полное". Это и будет означать, как ты говоришь, что здесь пассажей 2 – один неполный с А и один неполный с Б.
Блин, здоровы вы, ребята, какие-то свои выводы делать. Почему при моей гипотезе должно быть "частичное соответствие"? Пассажи будут полные. По отношению к одной из частей запроса. 😉
Я там смайл поставил специально 🙂
И сказал, мол, в контексте всего спора надо рассматривать. Если очень кратко, то скажите, вот Вы считаете, что Тайтл – пассаж, и тут же говорите, что пассаж попал в тайтл. Это как? Другими словами, я хотел обратить внимание, на то, что даже в таких, бытовых фразах проскакивает несоответствие и противоречие.
Проследить цепочку конечно можно. Но это будет повторение всего того, что говорил Евгений и немного я. Вы не находите подобные доводы убедительными.
Не вижу никакого противоречия. Можно для общности допустить, что тег title может разбиваться на N пассажей. Потому я так осторожно и сформулировал. Хотя, похоже, в Яндексе в этом случае всегда N=1. 🙂
Все-таки я не увидел убедительных доводов того, что passage extraction в Яндексе является query sensitive
Блин, приплыли. Так как тогда штрафовать неполные пассажи, если они все, по определению, полные? 🙂
Я понимаю эту точку зрения. Но на мой взгляд, в этом случае табулированный набор коэффициентов будет ну очень уж раздут. Думаю, экономичней просто штрафануть весь пассаж (т.е. уменьшить веса всех терминов пассажа) за неполность.
Все дело в том, на какие части разбивается запрос. Разбивка осуществляется по частям, ограниченным операторами &&, но никак не внутри этих частей. Т.е. в случае запроса (A B) && (C D) релевантными будут считаться пассажи, которые преодолевают кворум по отношению к запросу A B либо по отношению к запросу C D.
Я правильно понимаю, что имеются в виду не только &&, но и, например, &&(-7+7) ?
Да, операторов поиска в пределах документа – && и ~~. Операторы расстояния, на мой взгляд, не влияют на предоление кворума, а играют позже на этапе учета контекстуального сходства. Тогда-то пассажи, не удовлетворяющие им, и штрафуются коэффициентом нуль. Либо на промежуточном этапе сразу после преодоления кворума (так, наверное, будет экономичней). К сожалению, в своей статье Сегалович не коснулся поиска с заданным расстоянием.
Но ведь, получается, что надо добавить всего один коэффициент – для случая, когда разница между заданным в запросе растоянием и фактическим рассоянием бесконечно велика. Т.е. термин запроса, по отношении к которому вычисляется вес словопозиции отсутствует в пассаже.
В этом случае не учтутся в полной мере все индивидуальные "неполности" пассажа. Что, на мой взгляд, не есть хорошо. Особенно, если учесть, что веса словопозиций пересчитываются с учетом весов слов (IDF).
-ну, эта твоя произвольная разбивка на подзапросы впрямую противоречит самой идее учета с разными весами в зависимости от полноты пассажей.
1. понятно, что в статье говорится о ПОЛНОМ запросе, и полнота пассажа рассчитывается относительно общего запроса, примеры из статьи я привел.
2. Ты уже напридумывал "довесков" к статье столько, что впору тебе свой поисковик делать 🙂
3. Ну и примеры, наконец. Теперь ты понимаешь, какой пример интересует. 🙂
ИТАК, по-твоему, это не "частичное", а "полное" соотвествие в выдаче? ОК, можешь привести и пример поиска по запросу А && Б слов с близкими весами, где документ, содержащий одно из этих слов (А, например :)), будет найден как "полное соответствие"?
Слова с близкими весами (цифры за :: в reqtext) нужны для того, чтобы одно из слов не могло быть выброшено из полного пассажа по прохождению кворума (доля 0.94 для двусловного запроса после возведения весов в степень 0.38 ).
Жень, твоя теория о пассаже размером с документ звучит не более правдоподобно. 😉
Пусть документ, состоит из трех предложений, в первое из которых входит только термин A, в второе – только В, в третье – только C.
Вот давай такие запросы рассмотрим:
1) A && (B & C)
2) A && (B && C)
Как документ разобьется на пассажи в этих случаях? Как они пройдут кворум?
Теперь понял, куда ты клонишь. По моей гипотезе пассажи кворум-то пройдут, но зарубятся на следующем этапе. Хотя опять же повторюсь, это – всего лишь гипотеза. 😉
wolf,
-не скажи. Не о "пассаже размером с документ", о "пассаже из двух слов, с цифиркой расстояния между ними – размером с число слов в документе или там с число предложений – зависит от реализации". 🙂
-в колдунщике, во-первых, скобочек нету :), нет порядка выполнения. Если брать запрос A && B & C, то есть уже 2 реализации – А+Б или А+С пройдут. Кворум вообще весами слов определяется… По разному может быть, может и пройти в случае 1. Случай 2 всегда проходит.
-дак они же у тебя "полные", т.е., получат максимум веса, как ты и сказал. 🙂 Какой следующий этап "у тебя", в твоей реализации?
У меня вообще ощущуение, что мы обсуждаем придуманную тобой реализацию. Ты про "святое писание" упоминал – так вот мы обсуждаем толкования, а ты решил его переписать и обсуждать свой вариант. 🙂
При чем тут "в колдунщике, во-первых, скобочек нету"? Я скобочки в запросе поставил – а, значит, они будут и в переколдованном запросе. Проверь на досуге. Ты мне, пожалуйста, на первый вопрос ответь – как документ на пассажи разобьется в обоих случаях. А то пока из твоего
следует, что все таки на 3 пассажа – А, В и С. Или я не так понял? Или это у тебя пассажи такие перекрывающиеся – "А+Б" и "А+С"?
А у меня ощущение, что заковырявшись в колдунщике, ты не хочешь пошире на вопрос взглянуть. 😉 Давай вернемся к основополагающему запросу – по твоему разбиение документа на пассажи в Яндексе зависит от запроса?
Не ко мне вопрос, конечно, но позволю себе вставить реплику 🙂
Так не документ на пассажи разобъется, а "осуществится процесс нахождения всех пассажей в документе, удовлетворяющих контекстным ограничениям".
Что касается Вашего примера, то если для преодоления кворума необходимо наличие всех трех слов в пассаже, то по запросу A && (B & C) документ не будет найден т.к. не будет обнаружено ни одного пассажа, полностью удовлетворяющего контекстным ограничениям, а пассаж, частично им удовлетворяющий не пройдет кворум (буду благодарен за демонстрацию обратного :)). Если В или/и С имеют малый вес (IDF), и кворум может быть преодолен без В или/и С, то документ будет найден благодаря тому, что неполный пассаж пройдет кворум.
В ответ на запрос A && (B && C) документ будет найден независимо от весов (IDF) слов А В и С т.к. найденный пассаж A &&/+1 B &&/+1 C полностью удовлетворяет контекстным ограничениям, заданным в запросе (A && (B && C)).
euhenio, что-то у меня все больше плюсов за то, что в предложении А _ В _ В. содержится два пассажа (A &/+2 B и A &/+4 B), а не один A &/+2 B &/+2 B .
-нет, я имел в виду неполные пассаж "А+Б" или неполный пассаж "А+С". А какой будет найден, из этих данных я не знаю.
-оно зависит от расстановки операторов в переколдованном запросе. Нет, если хочешь знать, если оператор &&, то по моему мнению, слова в начале и в конце документа будут найдены в качестве одного пассажа.
Ты все-таки озвучь "свой алгоритм", в котором найденные, по-твоему, А и Б как "отдельные полные пассажи, получившие максимальный вес", "зарубятся на дальнейших этапах". Что это за дальнейшие этапы?
Все это началось с момента, когда ты сказал, что пассажи все равно по предложениям разбиваются, и дальше началось придумывание тобой своих толкований священного писания 🙂
-в общем согласен. и в качестве ответа на вопрос wolf-а.
-это имхо подсветчик виноват. Учитываться должен только одна пара А Б, т.к. иначе (если каждое слово включается в пассаж и есть дубли слов) дубли слов будут учитываться в весе. Иначе пассаж Б Б Б Б преодолел бы кворум любого запроса А Б С Д с одинаковыми весами.
Кот, правильно ли я понял, что подразумевается, что в зависимости от запроса, Яндекс "слепляет" пассажи из некоторых предложений? Т.е. ему надо сначала разбить текст на предложения, назовем их первичными пассажами. Это операция запросонезависимая. А потом идет запросозависимая операция – формирования из некоторых из этих первичных пассажей вторичных пассажей путем суммирования, которые и проходят проверку на кворум. Так?
P.S. Хотя нет… Исходя из Ваших слов пассажи просто лепятся из слов запроса… Ок, ясно. Я, получается, под запросонезависимым разбиением на пассажи подразумевал первичное разбиение текста на предложения. А под вторым этапом подразумевал то, что Вы имеете в виду под разбиением на пассажи с учетом уже выполненного разбиения текста на предложения… Такая вот петрушка… 🙂
Не ко мне реплика, но позволю поинтресоваться. По-Вашему, в этом случае для запроса А В учет термина А произойдет дважды?
Так вот я и говорю, что все больше склоняюсь к тому, что пассаж – это "слепок" с запроса. Т.е. если запрос А В С, то и найденный пассаж будет А В С даже в том случае, если текст А В С С С. Вернее, в тексте А В С С С будут обнаружены следующие пассажи: A&/+1B&/+1C, A&/+1B&/+2C, A&/+1B&/+3C. И вес документа по отношению к запросу А В С будет состоять из суммы весов этих трех пассажей. Ясно, что с учетом контекстуального сходства, первый пассаж будет весить больше второго, а второй больше третьего.
Если такое представление соответствует действительности, то никаких дублей слов в пассаже не будет, соответственно, не будет и преодоления кворума за счет дублей.
Реплика не к Вам получилась, поскольку она имеет смысл только в контексте запросозависимости пассажа 🙂
Да, в этом случае термин А учтется дважды т.к. запрос А В породит в указанном тексте два пассажа. Я уже рассуждал на эту тему под другим углом:
Да, лепятся из слов запроса. А вот нужно ли первичное разбиение текста на предложения, это вопрос. Ведь можно (на этапе индексирования документа) каждой словопозиции документа присвоить два индекса – номер предложения и номер словопозиции в предложении, этого достаточно для проведения всех рассчетов весов пассажей и словопозиций. Если моя память не спит с другим, то о такой технологии индексации в Яндексе я где-то слышал.
Ну, если не будет первичного разбиения на предложения, то как же узнать номер предложения, в которое входит словопозиция???
А что касается Вашей гипотезы про формирование двух пассажей из текста "А_Б_Б" в ответ на запрос "А&Б", то, в принципе, это все проверяется. По крайне мере не вижу причин, чтобы нельзя было проверить. Только муторно всё это…
А в общем-то мысль я Вашу понял. У меня была другая идея, что сначала предложения-пассажи проходят кворум относительно частей запроса, которые задают ограничения на поиск внутри предложения. А потом прошедшие этот кворум предложения-пассажи анализируются на предмет удовлетворения ограничениям, которые запрос задает в пределах документа. Возможно, я и неправ. 🙂
На этапе индексирования документа, просматриваются и нумеруются последовательно все словопозиции. А когда встречается разделитель предложений, обнуляется счетчик позиции в предложении, а счетчик номера предложения увеличивает свое значение на единицу.
Так давайте обсудим условия эксперимента. У меня есть неиспользуемый домен(небольшой сайт) под фильтром неучета входящих ссылок, можно его использовать. Не плохо было бы и табулированный набор коэффициентов при этом пощупать.
Ну, а что это, как не первичное разбиение на предложения???
В общем, идею вижу в том, что в случае справедливости Вашей гипотезы документы
1) А _ В _ В.
и
2) А _ В. А _ _ _ В.
должны иметь одинаковую текстовую релевантность, т.к. будут разбиты на одинаковые пассажи. Сравнить их можно будет тем же методом ортогональных запросов Миныча.
Я думал, Вы имеете в виду более сложный алгоритм первичной разбивки на предложения.
Придется допустить, что TF для термина А будет высчитываться (в том числе и нормироваться) тоже попассажно, а не исходя из кол-ва термина А в документе. Не думаю, что это однозначно корректное допущение. Хотя, это вроде как плавно вытекает из гипотезы и статьи.
С другой стороны, надо "налить и отойти".
Тогда надо опеределиться, что такое TF. Если это – частота термина во всех релевантных пассажах, то всё корректно. Если что-то другое, тогда возможны нюансы.
Вот если нарвемся на нюансы, тогда и будем думать 🙂
Не будет ли большой наглостью с моей стороны, спросить Вашего мнения о других аспектах этого опыта? Например, нет ли у Вас на примете нескольких пар словосочетаний, пригодных для метода Миныча? (наверное, это лучше в личку) 🙂
Первое, что приходит в голову – обойтись десятком (может, двумя десятками) пар документов, содержащих указанную Вами конструкцию. Использовать в этих документах несколько словосочетаний, для которых заранее подобраны пары для "метода Миныча". Наверное, стоит разбавить Ваши конструкции различным количеством "прочих" слов. Наверное, также надо предусмотреть возможность по ходу проверить работоспособность метода измерения.
Вот такие мысли "на вскидку", может быть у Вас, wolf, и у Вас, euhenio, есть соображения относительно методики, которыми вы можете поделиться?
Добавлено: по поводу пар для метода Миныча, это я наверное погорячился (праздичные возлияния даром не прошли:)). Если опыт проводить в пределах одного домена (что теоретически уже не очень корректно), то придется создавать среду для корректной отработки ортогональных запросов (или использовать другой способ сравнения релевантности). Н-да, задачка усложняется 🙂
Добавлено: зря я пост написал вечером восьмого марта 🙂
Кот, честно говоря, жалко время на думки по поводу такого эксперимента тратить. Текстовая релевантность – это всё интересно, конечно, но не она сейчас бал правит. У меня мысли все сейчас в другой опере. 🙂
Да и у меня, в общем-то, интерес чисто теоретический 🙂
Впрочем, в связи с открывшимися обстоятельствами 🙂 придется все "передумывать" сначала 🙂
Судя по всему, Сегалович отлично справился с задачей ничего не рассказать по сути.