Флаги rewriterule

Нарыл нормальное объяснение работы флагов в mod_rewrite на http://host146.t3n.sotline.ru/manual/mod/mod_rewrite.html – за неимением, вывалю сюда, чтобы было перед глазами:
***
Additionally you can set special flags for Substitution by appending

[flags]

as the third argument to the RewriteRule directive. Flags is a comma-separated list of the following flags:

‘redirect|R [=code]’ (force redirect)
Prefix Substitution with http://thishost[:thisport]/ (which makes the new URL a URI) to force a external redirection. If no code is given a HTTP response of 302 (MOVED TEMPORARILY) is used. If you want to use other response codes in the range 300-400 just specify them as a number or use one of the following symbolic names: temp (default), permanent, seeother. Use it for rules which should canonicalize the URL and give it back to the client, e.g., translate “/~” into “/u/” or always append a slash to /u/user, etc.

Note: When you use this flag, make sure that the substitution field is a valid URL! If not, you are redirecting to an invalid location! And remember that this flag itself only prefixes the URL with http://thishost[:thisport]/, rewriting continues. Usually you also want to stop and do the redirection immediately. To stop the rewriting you also have to provide the ‘L’ flag.

‘forbidden|F’ (force URL to be forbidden)
This forces the current URL to be forbidden, i.e., it immediately sends back a HTTP response of 403 (FORBIDDEN). Use this flag in conjunction with appropriate RewriteConds to conditionally block some URLs.
‘gone|G’ (force URL to be gone)
This forces the current URL to be gone, i.e., it immediately sends back a HTTP response of 410 (GONE). Use this flag to mark pages which no longer exist as gone.
‘proxy|P’ (force proxy)
This flag forces the substitution part to be internally forced as a proxy request and immediately (i.e., rewriting rule processing stops here) put through the proxy module. You have to make sure that the substitution string is a valid URI (e.g., typically starting with http://hostname) which can be handled by the Apache proxy module. If not you get an error from the proxy module. Use this flag to achieve a more powerful implementation of the ProxyPass directive, to map some remote stuff into the namespace of the local server.
Notice: To use this functionality make sure you have the proxy module compiled into your Apache server program. If you don’t know please check whether mod_proxy.c is part of the “httpd -l” output. If yes, this functionality is available to mod_rewrite. If not, then you first have to rebuild the “httpd” program with mod_proxy enabled.

‘last|L’ (last rule)
Stop the rewriting process here and don’t apply any more rewriting rules. This corresponds to the Perl last command or the break command from the C language. Use this flag to prevent the currently rewritten URL from being rewritten further by following rules. For example, use it to rewrite the root-path URL (‘/’) to a real one, e.g., ‘/e/www/’.
‘next|N’ (next round)
Re-run the rewriting process (starting again with the first rewriting rule). Here the URL to match is again not the original URL but the URL from the last rewriting rule. This corresponds to the Perl next command or the continue command from the C language. Use this flag to restart the rewriting process, i.e., to immediately go to the top of the loop.
But be careful not to create an infinite loop!
‘chain|C’ (chained with next rule)
This flag chains the current rule with the next rule (which itself can be chained with the following rule, etc.). This has the following effect: if a rule matches, then processing continues as usual, i.e., the flag has no effect. If the rule does not match, then all following chained rules are skipped. For instance, use it to remove the “.www” part inside a per-directory rule set when you let an external redirect happen (where the “.www” part should not to occur!).
‘type|T=MIME-type’ (force MIME type)
Force the MIME-type of the target file to be MIME-type. For instance, this can be used to simulate the mod_alias directive ScriptAlias which internally forces all files inside the mapped directory to have a MIME type of “application/x-httpd-cgi”.
‘nosubreq|NS’ (used only if no internal sub-request)
This flag forces the rewriting engine to skip a rewriting rule if the current request is an internal sub-request. For instance, sub-requests occur internally in Apache when mod_include tries to find out information about possible directory default files (index.xxx). On sub-requests it is not always useful and even sometimes causes a failure to if the complete set of rules are applied. Use this flag to exclude some rules.

Use the following rule for your decision: whenever you prefix some URLs with CGI-scripts to force them to be processed by the CGI-script, the chance is high that you will run into problems (or even overhead) on sub-requests. In these cases, use this flag.

‘nocase|NC’ (no case)
This makes the Pattern case-insensitive, i.e., there is no difference between ‘A-Z’ and ‘a-z’ when Pattern is matched against the current URL.
‘qsappend|QSA’ (query string append)
This flag forces the rewriting engine to append a query string part in the substitution string to the existing one instead of replacing it. Use this when you want to add more data to the query string via a rewrite rule.
‘noescape|NE’ (no URI escaping of output)
This flag keeps mod_rewrite from applying the usual URI escaping rules to the result of a rewrite. Ordinarily, special characters (such as ‘%’, ‘$’, ‘;’, and so on) will be escaped into their hexcode equivalents (‘%’, ‘$’, and ‘;’, respectively); this flag prevents this from being done. This allows percent symbols to appear in the output, as in
RewriteRule /foo/(.*) /bar?arg=P1\=$1 [R,NE]

which would turn ‘/foo/zed’ into a safe request for ‘/bar?arg=P1=zed’.
‘passthrough|PT’ (pass through to next handler)
This flag forces the rewriting engine to set the uri field of the internal request_rec structure to the value of the filename field. This flag is just a hack to be able to post-process the output of RewriteRule directives by Alias, ScriptAlias, Redirect, etc. directives from other URI-to-filename translators. A trivial example to show the semantics: If you want to rewrite /abc to /def via the rewriting engine of mod_rewrite and then /def to /ghi with mod_alias:
RewriteRule ^/abc(.*) /def$1 [PT]
Alias /def /ghi

If you omit the PT flag then mod_rewrite will do its job fine, i.e., it rewrites uri=/abc/… to filename=/def/… as a full API-compliant URI-to-filename translator should do. Then mod_alias comes and tries to do a URI-to-filename transition which will not work.
Note: You have to use this flag if you want to intermix directives of different modules which contain URL-to-filename translators. The typical example is the use of mod_alias and mod_rewrite..

For Apache hackers
If the current Apache API had a filename-to-filename hook additionally to the URI-to-filename hook then we wouldn’t need this flag! But without such a hook this flag is the only solution. The Apache Group has discussed this problem and will add such a hook in Apache version 2.0.
‘skip|S=num’ (skip next rule(s))
This flag forces the rewriting engine to skip the next num rules in sequence when the current rule matches. Use this to make pseudo if-then-else constructs: The last rule of the then-clause becomes skip=N where N is the number of rules in the else-clause. (This is not the same as the ‘chain|C’ flag!)
‘env|E=VAR:VAL’ (set environment variable)
This forces an environment variable named VAR to be set to the value VAL, where VAL can contain regexp backreferences $N and %N which will be expanded. You can use this flag more than once to set more than one variable. The variables can be later dereferenced in many situations, but usually from within XSSI (via ) or CGI (e.g. $ENV{‘VAR’}). Additionally you can dereference it in a following RewriteCond pattern via %{ENV:VAR}. Use this to strip but remember information from URLs.
‘cookie|CO=NAME:VAL:domain[:lifetime[:path]]’ (set cocookie)
This sets a cookie on the client’s browser. The cookie’s name is specified by NAME and the value is VAL. The domain field is the domain of the cookie, such as ‘.apache.org’,the optional lifetime is the lifetime of the cookie in minutes, and the optional path is the path of the cookie

Яндекс – новый алгоритм.

По сообщению в блоге Cherny (ну и в блоге Яндекса источник) говорят, что:

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

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

— Александр Авдонкин, программист отдела разработки поисковых сервисов

-Фсем медитировать! 🙂
Точность поиска – в основном имеется в виду сужение результатов за счет выпихивания “не очень релевантных” позиций из выдачи (вниз, вероятно, а не совсем выкидывание). Наверное.
А вот “Документы, посвященные именно теме запроса” – это интересно. Я всегда считал, что “именно теме” могут, скорее, быть посвящены сайты, а не документы… Оговорился человек? Или они тему каждому документу приписывают? (с точки зрения программиста – или накладно по ресурсам, или какое-нибудь говно в результате выйдет – типа списка в N “характерных” для документа кейвордов).
А насчет

по названиям компаний наверху чаще встречаются сайты этих компаний, а не их партнеров

-не обойтись без изменений алгоритмов ссылочного ранжирования… Вот тебе и тема. Хотя, может, они просто вес слов в тайтле увеличили? 😀

А программисты отдела разработки самостоятельные пошли. 🙂 Интересно, они у Воложа испрашивают согласия на публикацию в блоге Яндекса? Или у Сегаловича? 🙂

Алгоритм Яндекса by iseg – фсем фтыкать!

Илья Сегалович в своем ЖЖ дает ссылку на статью Яндекс на РОМИП-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».

-хе-хе! “Отсутствие группировки по сайтам” был лучше! 🙂
***
Одно непонятно – а чегой-то они так подобрели? Надо бы еще было коэффициенты выложить…