Реализация морфологического поиска на Kohana (библиотека phpMorphy)

[Groove]

Запрашиваемый URL-адрес не может быть предоставлен
URL-адрес: cook-room.com/
Заблокирован Веб-Антивирусом
Причина: фишинговый адрес
Нажмите здесь, если считаете, что веб-страница заблокирована ошибочно.
Способ обнаружения: эвристический анализ
Сообщение создано: 14:52:12

[Podpole]

Сайт был взломан в далеком прошлом, с тех пор не осталось и следов взлома… Но видимо в антивирусных базах видимо сохранилась информация…

[Groove]

Вам большое спасибо от жены за такой удобный и красивый сайт :)
И плюсики от меня

[Podpole]

Спасибо большое, буду развивать проект.

[bezumkin]

В своё время прикрутил phpMorphy к MODX, только сделал это попроще.

Давно есть мысль побороть проблемы с релевантностью, так что попробую реализовать вашу логику, на досуге. Большое спасибо за статью!

Я правильно понял, что все слова заносятся по одной штуке в строку таблицы, а вес считается от частоты этого слова на странице?
В таблице индекса, соответственно, миллионы строк?

[Podpole]

Да, в индексе хранятся все уникальные слова по каждой странице. Вес каждого слова считается не только от частоты использования, но и от места его расположения (слово в заголовке получит бОльший вес, чем слово из комментария к материалу). Что касается объемов базы — от размера сайта конечно зависит, в теории может и до миллионов вырасти, но если построить индексы, как предлагается — проблем быть не должно…

[alt-j]

Насколько это релевантный метод поиска — вопрос достаточно спорный. Как мне кажется, минимум не хватает анализа коллокаций. А вообще на выходных обсуждали вопрос релевантности поиска с Otkrick, и как мне кажется, он предложил несколько достаточно интересных идей.

[Podpole]

Да, предложенный мной метод — безусловно не идеален (идеальных методов вообще не бывает). На счет анализа коллакаций (если я правильно понимаю значение этой фразы) — я задумывался над этой темой (и даже нашел логическое и техническое решение) — но не стал нагружать индекс еще одним полем (некий номер слова от начала строки). В общем при разбиении строки на слова — мы получаем массив, и по большому счету, индекс каждого элемента этого массива = номер слова в предложении, и можно проверять при поиске, если в каком либо материале найденные по запросу слова стоят близко друг к другу (как в изначальном запросе пользователя) — увеличивать релевантность данного материала.
Этот подход более нагруженный (в индексе будут храниться дубликаты слов + дополнительные проверки при поиске + суммирование весов слов не при индексации, а при поиске).
За идеи — спасибо большое, возьму на заметку, о некоторых вещах — даже не задумывался. Но на постгресс переходить пока не думал, да и проект у меня не под поиск заточен, основное для меня — комьюнити…

[mac2000]

Забавно, вначале смутило не желание использовать полнотекстовый поиск, но почитав документацию и отзывы в сети пришел к выводу что в mysql с этим пока еще слабо, чему я честно говоря удивлен, тот же mssql умеет вот такое:

SELECT TOP 5 Name FROM Vacancy WHERE FREETEXT(Name, 'киева', LANGUAGE 1049) AND NOT CONTAINS(Name, 'киева')

А вообще, если есть возможность, стоит ставить\пробовать инструменты вроде Sphinx, Apache Solr etc

[dohlik]

Я конечно могу ошибаться, но по идее многие вещи должны быть спрятаны внутри модуля (очистка индексов, пред- и постобработка данных и тд), например в модели Model_Searchindex.

Ну и конечно

$comments = ORM::factory('comment')->where('post_id', '=', $post->id)->order_by('id', 'ASC')->find_all();

меняем на

$comments = $post->comments->order_by('id', 'ASC')->find_all();

(сортировка скорее всего тоже не нужна)

[chudinov]

а должен ли склонять все слова во фразе или только «читает» последнее слово?