Новые технологии поиска документов похожих по содержанию на заданный

Все замечательно, НО:

1. Ваш пример плохой работы "фразового поиск" показывает, что у Вас плохо реализована нормализация документов по длине. Это действительно проблема, но не смертельная и она не обязательно есть во всех других реализациях. Другого обоснования (хотя оно теоретически есть и известно каждому специалисту по IR) почему по короткой фразе трудно хорошо искать не приводится. Это почему?

2. Хорошо известно несколько алгоритмов нахождения "похожих" документов, хорошо бы на них сослаться и дать какое-то сравнение, один пример гугла как-то не убеждает, тем более что он достаточно искусственный. Я за 5 мин. могу для вас обратный соорудить :). Можете кратко сравнить?

Пафосу много, но доверия мало.

В основу положена некоторая механистическая модель (простите, МОДЕЛЬ, конечно), учитывающая:

- вероятно, какую-то функцию от распределения частотностей (в принципе не важно какую) - трудно верить в исключительность -лучше клонов VM25 пока НИКТО не видел.

- список "синонимов" (это еще стоит обсудить на множестве каких значений purchase и obtain, и особенно acquire пересекаются)

- есть еще список стоп-слов, например, почему-то "заявка"

В общем, пример производит впечатление подстроенного.

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

(Leom не первый и не последний), и проводятся мероприятия типа TREC или

РОМИП .

РОМИП честнее - дается 20000 заданий (ручная подгонка практически исключена!), из них случайно отбирается 50 для оценки, пара задание/документ оценивается не менее чем 2 оценщиками.

Даже для короткого "фразового поиска" достаточно простые методы типа BM25 + учет близости по месту встречаемости дают в СРЕДНЕМ 7 (для вэба) - 8 (для правовых актов) релевантных документов среди первых 10.

Конечно, даже небольшое улучшение поиска хорошо, но говорить о качественном улучшении - это куда - находить 11 документов что-ли?

* * *

Насчет примера про похожие из ролика. Ну хорошо, нашли первый документ про покупку IBM чего-то там, далее находятся документы про покупки - и это мол хорошо.

Но ведь, если рассматривать задачу поиска похожих, то почему не являются похожими документы про IBM и технологии и т.п., без всякой покупки?

То есть решается на самом деле специфическая задача того же "фразового поиска", но с заданным дополнительным контекстом.

В целом:

- интересно, но ничего особенно нового, по сравнению с тем же Я., у которого тоже есть поиск похожих - достаточно простой (запрос из десятка слов с максимальным tf*idf) - и разумно работает

- и по крайней мере, ничего такого, чтобы соответствовало пафосу

Нет к сожалению. Хотя портировать нет проблемпо большому счету -- нужна заинтересованность в этом. То есть при наличии серьезных пряников -- без проблем.

Могу дать. Если коротко, то лучше получать сразу патент в Евразийском патентом ведомстве (Москва)и уже оттуда подавать в США -- будет больше вероятность что выдадут -- да и денег в итоге будет потрачено меньше. Ну а если Евразия вдруг отклонит -- то будет не так обидно как если бы сразу подавать в США.

А приоритет идет все равно с дачи подачи заявки в Евразию.

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

Опять таки для примера -- это же не главное в технологии -- все списки можно настроить под конкретную систему.

Так вам никто не мешает откачать EXE и протестить на своих примерах. В Trial версии которая там ограничение на 1 гиг индексируемых текстов и на поддержку форматов (там намерянно только html и txt )

Ну во первых технология только вышла и в этих меропритиях мы не могли учавствовать в принципе. А во вторых -- где идут тесты по поиску похожих в этихз мероприятиях?

У нас тоже учет расстояний между словами во фразе учитывается, но это далеко не всегда помогает

Что за число 11. В тестовой базе около 1000 документов и 300 мег инфы.

И на самом деле от кол-ва документов ничего не зависит. А такой малый объем делалсчя для того чтобы помещалось на СД и хоть для кого то было реально откачать из ИНЕТ.

Если бы были в базе то тоже бы нашлись.

Абсолютно неверный вывод

Э, батенька...

Так может для каждого запроса будем список синонимов и список стоп-слов определять?

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

Вычеркиваем эту функциональность.

Мне времени не хватает на проверку своих систем.

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

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

Процедура РОМИП весьма демократична - предлагайте интересующую Вас дорожку, если будут такие же желающие - будет и дорожка.

Это я типа хотел пошутить: чтобы "качественно" улучшить работу системы, возвращающей 8 релевантных документов из первых 10, надо возращать 11 релевантных документов в первых 10.

Лев, при всём желании разобраться - при наших ценах на трафик это не всего лишь 300 мег, а целых 300 мег. Качать это и дорого и долго.

Почему бы Вам:

- не сделать веб-интерфейс к своей базе в целях тестирования? Кстати, тогда Вы сможете выложить туда хоть 100 гиг, или

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

Погодите, как же так? Вы же говорите - несколькими постами раньше - что поиск похожих работает лучше, чем обычный. Так и сравнивайте с обычным - зачем же Вам особые соперники?

Мы с Вами уже говорили о том, что это plain text, так вроде? Но теперь выходит, что единицей у Вас является документ средним размеров в 150 тысяч символов? Ну, просто для информации - "Капитанская дочка" Пушкина меньше.

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

Привет,

Откачать, протетсить.

Лео, дай пожалуйста определние похожести документов с точки зрения твоей системы.

Вопрос два - чем ваша технология отличается от следующего:

- берем все слова исходного документа

- приводим их к нормальной форме (морфология)

- для слов из списка синонимов добавляем синонимов

- делаем из них запросв вида слово1 OR слово 2 и так далее

- выполняем его

Павел

Павел,

Это характерный пример того, что сложная задача на первый взгляд кажется простой. Но это только кажется.

На самом деле алгоритм, Вами приведённый., работать не будет в принципе, так что и сравнивать с ним нет никакого смысла.

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

Но! Тут вам придётся решить, как объединять полученный список слов в запрос к поисковику. Есть два варианта:

а) все слова запихнуть в один запрос - через ИЛИ, или через И, или даже объединить их в некую ДНФ (в скобках некоторые слова через И, а сами скобки через ИЛИ);

или, напротив,

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

Так вот, в первом случае вы почти гарантированно получите нулевой результат - запрос слишком длинный и слишком сужает перебор.Попробуйте ввести запрос из двух-трёх десятков слов в Яндекс или Рамблер - он в среднем не найдёт вообще ничего. Хоть одно слово да испортит пересечение списков вхождений.

Во втором случае вы получите гигантское количество результатов и должны будете как-то их профильтровать и обьъединить - а как, придётся придумать, и это не так просто.

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

У нас уже была дискуссия про синонимы и как они ухудшают поиск.

В общем, поиск похожих - довольно тонкая задача.

И речь как раз нужно вести о том, чем предлагаемый Львом алгоритм поиска похожих КАРДИНАЛЬНО отличается от существующих в Яндексе и Рамблере, Гугле и прочих поисковиках.

Насколько я понимаю, Лев выдвигает два принципиальных отличия своей технологии: 1) качество поиска, 2) скорость поиска/индексирования на огромных массивах документов.

Коротко скажу, что мы на прошлой неделе протестировали модуль, который Лев передал нам в Москве, нам не понравилось - релевантность поиска пока низкая. То есть находимые документы - на самом деле не очень похожие. Таким образом, по качеству кардинального отличия от других производителей мы пока не усмотрели.

Тестировал Николай Харин, это один из лучших специалистов в России, его алгоримы поиска и ранжирования использовались и используются в ОРФО, Следопыте, МультиЛексе, Рамблере, Спамтесте, Новотеке.

Что касается скорости, тут я ничего сказать не могу - тестовый массив там не очень большой.

Удивительное рядом :)

Lucene, а вместе с ним и nutch, примерно так и делает.

И это работает. Similar

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

К слову, мы не только синонимы стараемся не использовать, но и морфологию. В очень редких случаях.

Это и был вопрос к Лео.

Павел

Еще раз повторю -- это дополнительна возможность которая в примере присутвует только для того чтобы покзать что это возможно. А нормально искать будет и без синонимов

.

Так вам доказывать мне смысла нет, а корпоративныому заказчику -- так это тема отдельная и не для этого форума. Не знаю говорит вам о чем то что например hummmingbird уже этим заинтересовалось.........