Как стать автором
Обновить

Комментарии 11

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

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

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

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

А вообще, если есть возможность, стоит ставить\пробовать инструменты вроде Sphinx, Apache Solr etc
Я конечно могу ошибаться, но по идее многие вещи должны быть спрятаны внутри модуля (очистка индексов, пред- и постобработка данных и тд), например в модели 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();


(сортировка скорее всего тоже не нужна)
image
а должен ли склонять все слова во фразе или только «читает» последнее слово?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории