bvd

Рейтинг
42
Регистрация
02.09.2002
itman:
Хотя, возможно, что Ромип в тепершнем виде не самая хорошая идея, потому как там коллекция маленькая там с PR не очень развернешься.
Kryukov:
Что касается поисковиков - так это мое хобби, к тому же, это замечательное место для экспериментов (правда не очень дешевое). Так что, если кому не жалко - идеи в студию. Возможно я поделюсь опробованными моделями

В РОМИП не один раз обсуждалась идея поэкспериментировать с PageRank.

Проблема была получить разумное тестовое множество.

Обсуждалась задача экспериментировать "поверх" существующей ПМ.

Однако была проблема использовать "больших" игроков - Я. или Р. - чтобы никого не обижать.

Если г-н Kryukov готов предоставить для тестирования свою ПМ (+ в достаточной мере документированные возможности по расчету ссылочной связности), то, мне кажется, это будет интересно.

Собственно и качественные рекомендации могут быть только как результат эксперимента.

Ashmanov:
Борис, а почему сказки-то?
К нам постоянно обращаются, чтобы сделать специальный поисковик по теме, в которой партнёр хорошо разбирается. Например, медицина. При этом мы сами не разбираемся в медицине, и не можем заняться этим профессионально. Но у нас есть поисковик. А партнёр, наоборот, знает, какие категории информации есть, какие сайты нужно индексировать, что показывать и какую рекламу продавать, но у него нет своего поисковика и нет программистов/денег/времени на разработку поисковика.
Вот мы и сделали поисковую платформу, теперь можем дать ему инструмент.
...
Да, и насчёт "качественного". А что это такое? Вот поиск по новостям Новотеки - чем не устраивает, что в нём такого уж некачественного?
Мне кажется, в специализированных поисковиках сам поисковик может быть обычным, а фишка в отборе и структурировании данных.

почти со всем согласен - потребность есть, люди приходят и просят специализированный поиск (даже не поиск но нечто большее, но удобно поставлять решение на поисковике) - это так

Я прицепился к словам "ДЛЯ ВСЕХ"

"качественный" по моему разумению, это когда люди готовы вкладывать деньги не за "развлекаловку-игрушку", но за то, что они будут использовать в своей работе/бизнесе

Давайте рассмотрим гипотетическое применение движка "Новотеки" к упомянутой задаче:

1) не сомневаюсь, что ВСЕМ ИЗВЕСТНЫЕ сведения будут выбираться на раз - и этого-то как раз хватит на полгода промоушена

2) но заказчик ТЕМАТИЧЕСКОГО поиска и так ЗНАЕТ все эти известные сведения

3) заказчику нужны подробности - только за это будет платить - это, по крайней мере, необходимость лезть шире - не только по определенному заранее списку сайтов, необходимость залазить в смежные тематики - уходить в историю и т.п.

наверное, я чего не знаю - может открыты некие чудодейственные методы в Thematic/Topical Crawling - такого рода задачи решаются для конкретных (в том числе и достаточно широких) предметных областей - НО! не менее чем полгода на одну (в качестве примера такой области - Антиспам)...

IMHO - может как-то поаккуратнее с позиционированием...

Ashmanov:
А вот зачем:
в) создание тематических поисковиков для всех. По области, которую вы лично хорошо знаете. Скажем, по медицине или фитнесу.
Сейчас вы не можете этого сделать легко и без усилий - у вас нет технологии, и даже если взять открытый поиск типа многопоиска, то нужно нанимать программистов для наладки и поддержки и т.п. А тут вы просто подписываетесь на услугу, а поисковик хостится у нас, и следит за ним наша служба подержки.

это сказки какие-то - так, конечно, можно порубать вершки,

но ничего качественного "для всех" сделать пока нельзя...

главное будет успеть через полгода запустить еще более глобальный проект

minaton:
Кто мне объяснит что это такое:

И еще - индекс у них собственный?

судя по всему - интерактивное уточнение запроса, каких уже много,

например, www.kartoo.com, и которые работают либо быстро и фигово,

либо долго и ... не всегда хорошо

в общем IMHO, ничего революционно нового - что там еще можно создать этакого с помощью нейронных-то сетей?

есть два забавных момента:

1) ориентация на персональный поиск - локальный пользователь не создает нагрузки и готов ждать ответа

2) разудалая реклама - прокричать погромче, а там хоть пусть солнце не всходит...

pelvis:
любая БД (хоть на мускуле) вытянет 18 миллионов запросов в сутки(а э
то уже не что нибудь), если конечно железяки с каналом вытянут

да, наверное, для простых запросов, однако, для поиска по нескольким словам, когда надо еще сортировать результаты...

(особенно, при допущении развитого языка запросов со скобками, логическими операторами и т.п., что сильно удлиняет SQL запрос)

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

хотел бы я посмотреть на ОДИН сервер, который сможет помещать и пересекать в оперативной памяти выборки для частотных слов, для базы, скажем на 10 миллионов документов (около 3 Г записей, не менее 30 Гбайт индекса) хранимую в реляционной форме. Важно, что основной индекс не может быть целиком засунут в оперативную память.

(я-то лично сомневаюсь, что кроме Oracle это, вообще, что-нибудь потянет)

поглядев на потолок, беру оттуда формулу для типичного сервера реляционной базы данных:

количество выполняемых (поиск и ранжирование) запросов в день

равно

10*количество долларов стоимости железа

поделить на

количество документов в миллионах

(можно помножить, или поделить на три)

Eugen:

Есть идеи, где можно взять эту книгу в электронном варианте? По приведенной ссылке - только название книги ;)

Вам уже Interitus ответил....

Но мой ответ - купить. У Вас какой бюджет? Потратить на нужные книжки 30-300 баксов - обязательно!

Eugen:

Кстати, для хранения инверсного индекса ведь можно применит формат хранения BerkleyDB? Кто-то уде так делал или это мои фантазии? ;) Единственно не ояень понятно, как обрабатывать конкурентные запросы (особенно одновременно чтение и модификация)

Вы чего хотите - сделать что-нибудь или супер-пупер?

Если что-нибудь - хоть контектным поиском по файлам.

Если правильно - как сказано...

Eugen:

Спасибо, учту. Насчет ранжирования по релевантности - это тоже к п.1 ?

См. также статьи Яндекса в РОМИП и статьи М.Губина в RCDL.

Eugen:

Кстати, насчет БД. Если есть опят использования СУБД в качестве "сердца" поискавика - поделитесь опытом. Каие ограничения на размер индекса, узкие места в производительности.

ограничений на размер индекса нет.

Узкие места - это универсальные продукты, следовательно несколько хуже в специальных условиях - например, ORACLE любит хапать все ресурсы для "оптимального" ответа на запрос - это плохо для обслуживания большого числа "одновременных" запросов.

Зато есть и преимущества - поисковик это не только "сердце"...

Eugen:

Возникло много вопросов по организации и выполнения поиска по инверсному индексу.
1) Где можно почитать про способы организации и хранения такого индекса? Если не сложно, то ссылки на статьи/публикации были бы очень кстати.

читайте литературу - например, рекомендованную И.Сегаловичем.

Сейчас весьма популярны алгоритмы аналогичные описанным Ricardo Baeza-Yates.

Eugen:

Есть ли готовые решения? Ведь реализация хранения в файлах при помощи Б-деревьев с "нуля" - трудоемкая задача, т.к. нужно учитывать ограничение на рамер файлов, да и делать уйму работы, которая уже сделана до меня.
2) Очень интересно, каким образом эффективно выполнять поиск для запроса, в которым между словами стоит лог. связка "И". Насколько я понимаю, инверсный индекс позволяет быстро находить индекс документа, в котором встречается одно из слов запроса. Для нахождения результатов многословного запроса (связка И) прийдется находить пересечение множеств всех результатов по каждому из слов. Какие существуют эфффективные алгоримы решения? Сливать все идентификаторы документов (по каждому из слов) в кучу, сортировать и делать фильтрацию? Но ведь по каждому из слов это может быть несколько миллионов докуметов...

не хотите программировать современные схемы - пользуйтесь стандартными базами данных, например, Oracle, где эти проблемы решены до Вас и за Вас

пересекут миллионы документов, проблема с использованием баз данных - тяжело держать много пользователей одновременно

кстати, для действительно многословного запроса не стоит все слова добавлять через "И", если Вас интересует только релевантность

Eugen:

3) Ну и, наконец, больше всего интересует, как правильно сделать поиск на точное вхождение ("поиск в кавычках"). Тут пока никаких идей...

если имеет в виду поиск по одному слову - очевидно - храните и словоформы

если имеется в виду поск по подстроке - см. п.1 - там это есть

lagif:
Кто-нибудь пробовал конвертить словари Lingvo в, скажем, текстовик?

а почему бы не купить?

если планируется делать что-нибудь хоть сколько-нибудь серьезное - покупка дешевле обойдется чем сопровождение халявного ресурса

Как можно решить какие алгоритмы хороши, какие нет, если их не проверять в реальных условиях?

Следует отличать ИДЕИ алгоритмов и РЕАЛЬНЫЕ алгоритмы.

Многое зависит от ЦЕЛИ, для которой создается поисковая машина.

Трудно ожидать, что на форуме возможно собрать все хорошее, что опубликовано в:

trec.nist.gov

sigir.org

www10.org, www2002.org

и т.д.

W.Ed.:
PageRank performs an objective measurement of the importance of web pages ...


Источники:
http://www.google.ru/corporate/tech.html
/ru/articles/344

что за ерунда?

Зачем так обильно цитировать статью И.Сегаловича?

Может лучше более четко поставить свои вопросы?

И что это за РАЗРАБОТЧИК (НОВОЙ) поисковой машины, которому еще нужны какие-то идеи?

Всего: 133