При "правильной" организации инвертированного файла, конечно нет. Все зависит от приоритетов при разработке поисковой структуры - скорость поиска или обновления, насколько критична компактность и т.д.
Если данные часто меняются и требуется большая скорость обновления, то пост-листы бьются на отдельно обновляемые кусочки (что, кстати может улучшать производительность MPMGJN и, соответственно, поиска фраз), позиции в документах делаются устойчивыми к изменению документа и еще десяток известных решений. Тем самым достигается уменьшение на порядки объема изменений по сравнению с обновление "в лоб".
Весь вопрос в том, что такое "словосочетание". Если имеется в виду слова стоящие рядом, то инвертированный файл при правильной организации дает время поиска не хуже (а реально лучше) O(n), где n - число слов запроса. Что, в принципе, не плохо :).
Для того, чтобы получить лучшее время нужно использовать структуры типа NextWord, см. например http://citeseer.ist.psu.edu/bahle02efficient.html ну или скромную мою работу http://rcdl2002.jinr.ru/Reports/Vol_2/vol2_26-37.pdf
Нет, это совсем не про это. А это статьи про удаление дублей и определение стиля. Я не уверен до деталей насчет яндекса, но обычно просто расширяют запрос наиболее "тяжелыми" (в некотором статистистическом смысле) словами и фразами из этого документа.
У всех разработчиков поисковиков несколько свой подход. Возможны два крайних варианта и остальные его промежуточные:
1. каждая позиция в документе может содержать несколько лексем и их комбинаций. Смотрите описание интерфейса IWordBreaker из MS IndexEngine. В этом случае мыла11 можно представить как {мыла11, мыла, 11}
2. бить на как можно меньшие лексемы, а всякие соединенные варианты получаются с использованием координатной информации. За примерами сходите в yahoo и поищите какой-нибудь номер с точками и тире. Другое дело в оригинале может быть мыло/11, а найдется мыло.11.
Какие символы отнести к словам - отдельная беда. Когда появился C# некоторые поисковики не могли искать по #, что приводило к проблемам.
Из личного опыта - введение "лишних" символов может заметно увеличивать словарь и приводить к недоразумениям при поиске обычных слов, но очень помогает, если пользователи часто ищут номера и коды.
А что вы хотите делать с помощью этой структуры? Она не будет ни маленькой, ни быстрой по поиску. Зачем она нужна?
Браво, Борис!
Проблема уровня контроля человека над машиной, она все возрастает и возрастает, но это, вместе с семантическим поиском и вечным двигателем, к философам и фантастам.
Правда, утешив, тезку могу сказать, что подобные продукты сейчас есть, кроме того, MS в Longhorm не очень внятно пишет о "распределенном" поиске. В принципе все логично - если у меня индексируются документы в сетевом ресурсе, то логично предоставить и этот сервис в сеть. Активный прогресс систем обмена файлов, говорит о том, что и в И-нете это в каком-то виде возможно.
Несколько лет назад Влад Жигалов на страницах некоторых журналов толкал такие идеи (http://www.aha.ru/~zhigalov/insearch/index.htm), но сейчас что-то тихо.
Насколько я вижу - товары/услуги (обобщение цен) и новости (RSS и т.п.). Больше не могу придумать. А в этих двух случаях однозначно удастся получить улучшение результатов.
Опять же строго IMHO, но структурированное представление информации, например, о ценах по-моему не очень вяжется с бытующим понятием "онтология" при всей ее расплывчатости. Кроме того, практически все поисковики это сейчас уже умеют. Ну и существуют специализированные системы типа price.ru и т.п. Я сам еще в "довебовскую" эпоху занимался такой системой вытаскивания информации о недвижимости из объявлений. Никто никогда не объявлял это "онтологиями","семантикой" и т.д.
Я совершенно согласен, что пацаны с деньгами и с малым количеством времени - это реальные пользователи. А товарищи, которые ожидают, что поисковик будет разумен как эксперт во всех областях, с помощью примитивных средств WordNet или синтаксического анализа с использованием онтологического словаря профессора Х - пользователи только в умах академических исследователей. Но, как правило, когда написано "семантика и онтология", то подразумеваются вторые.
Я считаю, что движение будет с двух сторон - системы будут лучше разбирать неструктурированную информацию и информация будет структурироваться для поисковиков, но это будет взаимное эволюционное развитие. Прорывов глобально не будет. Будет так - все в мета начнут закладывать географию и поисковики начнут проверять. Это улучшит поиск ближайших магазинов. Почти сразу начнется киберспам и дополнительные проверки поисковиками этой информации по другим критериям, что приведет к тому, что поиск улучшится, но шум все равно будет и т.д.
IMHO никак не повлияет. Не меньшие суммы регулярно тратятся на, например, разработку стандартов по оформлению документов и классификаторов, но никто не ожидает, что завтра произойдет качественное изменение в этой области.
Главная проблема всех этих онтологических изысканий - они бесконечно далеки от практики работы реальных пользователей информации и переполнены демагогией.
На самом деле у вас все немного в кучу. Ваш алгоритм - так называемое "скользящее окно", дает достаточно неплохие результаты и широко применяется. Не вижу только ни в вашей формуле, ни в формуле Ильи нормализации по длине документа. Если подходить к этому вопросу несколько шире, то возможны две ситуации:
1. Взаимное положение используется для учета словосочетаний. Т.е. пользователь задал одно или несколько словочетаний ("цифровая камера", "еврейские анекдоты" и т.п.). Описанный алгоритм хорошо для этого подходит (это частный случай выделения словосочетаний путем учета расстояний), но можно использовать любой статистический/синтаксический алгоритм выделения словосочетаний и взвешивать их как слова (любой известный алгоритм). Литературы по этому поводу - море... Т.к. большинство запросов в и-нете это просто одно словосочетание, то результат неплохой. Если в запросе словосочетаний несколько, то возможны разные эффекты, в т.ч. и не очень приятные.
2. Пользователь ищет по цитате, т.е. берет фразу из документа, возможно с искажениями. Ситуация достаточно редкая для и-нета, но очень вероятная для библиотечных, патентных, правовых баз и т.д. В этом случае описанный подход обычно выкидывает наверх совсем не то, что ожидает пользователь. В этом случае нужно считать что-нибудь типа метрики Левинштейна между запросом и скользящим окном, где под символами рассматривать слова.
В реальной системе, которая должна поддерживать обе ситуации, ищется и так и так, а потом пользователю выдается "комбинированный" результат, где на основании некоторой эвристики решается что все-таки хотел пользователь.
