Выделение найденных слов на страницах с результатами поиска.

А я вообще, честно говоря, не понял смысла оцифровки лексикона, тем более не разрешая коллизий. Но этот способ уже где-то видел, по-моему, у mnogosearch.

Я что-то в толк не возьму - а что, нужно подсвечивать слово "поискового" при поиске слова "поиск"?

А зачем это вам?

А "столовую" при поиске слова "стол" тоже нужно подсвечивать? А "раненый" при поиске "раны"? а "светает" при поиске "светлое"?

А новость по запросу "новый"? Скажем, если по запросу "новый ВАЗ" вам дадут "новости ВАЗа" - нормально?

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

И так невысокая релевантность средней поисковой машины гарантированно опустится просто до нуля.

Полученный уровень шума вас просто приятно удивит. Поиск слова "партия" даст партийные списки, вместо красного вина получите краснуху, на "телефон" вам выдадут телефонизацию Нарьян-Мара в 1995 году и так далее.

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

Мы в 1999 г. встраивали словообразовательный словарь Тихонова и словари синонимов в "Следопыт" и не смогли подавить шум, несмотря на то, что каждой связи был сопоставлен свой вес (синонимам один, антонимам - другой, словообразовательному ряду - ряд понижающихся весов по мере удаления от исходного слова). А мы ведь таки голову приложили, много над этим думали.

Вставили мы по заказу подобный тезаурус и в Русский Смантический Сервер в Экскалибуре. Лично мне совсем не понравилось. Но им для галочки было нужно, клиенты спрашивали.

Короче говоря, единственное применение, которое я видел у словообразовательного расширения запроса - это грузить клиентов. Смотрите, как круто, ни у кого не делается, только у нас.

Во-во. Игорь очень подробно изложил возникающие при учете словообразования проблемы. Еще хуже результаты получатся (если это возможно - хуже), если применить словари синонимов, какой бы привлекательной эта идея ни казалась. Действительно, на первый взгляд, сильно увеличивается полнота поиска. Однако вспомним о том, что слова чаще всего являются синонимами только в определенном контексте, что отражено и в самих словарях синонимов так называемыми группами значений.

Более того, синонимия нетранзитивна, то есть то, что слова A и B являются синонимами, и слова B и C - синонимы, вовсе не означает, что A и C - тоже синонимы. Наглядно в этом можно убедиться, сделав три шага по синонимическим рядам от любого слова и получив абсолютно другое понятие.

Примеров позитивного влияния учета словообразования на качество информационного поиска пока нету, а негативных - масса. Один из них некоторое время назад рассматривал тут Игорь, я же упомяну о другом. Есть такая система - "Алхимик", разработанная харьковской компанией "Велтон-Софт". Там автор не только учитывает словообразовательные ряды, но и, по его словам, оперирует семантическими единицами. Система очень похожа на настоящую, но только не работает. То есть, как и все подобные системы, на специально подобранном авторами массиве текстов она позволяет продемонстрировать их идеи, однако любой шаг в сторону приводит к откровенному бреду.

Отмечу также, что даже хваленый "учет морфологии", которым мы все в свое время козыряли, хоть и нужен при построении качественного поиска, однако должен применяться весьма и весьма осторожно. Библейский пример со словом "сера" уже и приводить как-то неприлично, поэтому возьмем слово "печь", омонимичное с глаголом. Документы, где говорится о пекаре, который что-то там пек, будут найдены наряду с документами, где говорится о кладке печей, и получат ничуть не меньший вес. Чтобы уменьшить этот эффект, точному совпадению формы слова с запросом дается бОльший вес.

Так что находить "поисковый" по запросу "поиск" просто вредно.

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

Только, кажется, тема данного обсуждения все-таки чуть в стороне. Задача конкретна.

Есть словарь, преобразованный через CRC32 (кстати, может словообразование досталось "бесплатно" для экономии объема словаря?), есть слова запроса, также в виде CRC32. И есть тексты документов, где надо найти эти слова запроса. Расходы на CRC32 при этом чересчур велики.

Решение, по-моему, простое:

надо хранить копии текстов в CRC32-преобразованном виде.

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

Правда, нужно решить еще проблему с коллизиями.

Другой вопрос, зачем вообще идти по пути CRC32-преобразования словаря , но уже пройдено 2 года и назад вернуться, возможно, трудно.

Ну надо же, про меня вспомнили!!!

Большая часть веремни уходит не на расчет CRC, а на поиск CRC основной формы слова.

Я храню таблицу CRC-CRC в виде Б-дерева, его размер составляет около 15Mb. На одно слово требуется от 5 до 10 сравнений (а данные хранятся на диске), а таких слов на странице может быть 100 штук. Шерстить 15 мегабайтный файл не очень быстро. Держать его в памяти не имеет смысла, так как поиск производится не более 200 раз в день, а серверу есть чем занятся и без поиска.

Я в этой проблеме особо не разбирался. Какие есть другие варианты ?

Понятно, что затраты на CRC не сводятся только к расчету.

Задачка уточняется по ходу.

А решение (конечно, одно из возможных) было изложено мной еще в прошлом посте. Придется рассказать более подробно с азов.

Если у вас некая операция выполняется часто, но не быстро (выходит за временные рамки ТЗ), то один из способов разрешения ситуации заключается в разбиении операции на несколько этапов и выполнения части из них заранее. Если говорить конкретно относительно данной задачи, то решение может быть в сохранении CRC основных форм слов данного текста. Тогда вам не придется "шерстить" файл, да и считать CRC. Достаточно будет сравнивать CRC форм слов запроса с CRC форм слов данного текста. Уф, вроде бы все.

Хотя, отвлекаясь от постановки задачи, скажу, что и решение экономить память на 15Мб также мне не совсем понятно. А не пробовали память докупить? Если, конечно, сервер - ваш, если не ваш, то все-таки дешевле купить сервер и поставить у провайдера.

Спасибо, идея хорошая. Отправлена в мозг на обработку :)

Сервер не мой. И тратиться я не собираюсь, так как для меня это скорее игрушка, нежели работа.