Ну, Илья, я и не говорил ничего плохого про обычные искалки, а отвечал на изначальный вопрос про окно фактов - см. первое сообщение. Это вы зачем-то противопоставляете и спорите, а я, в общем не против полнотекстовых искалок, я их сам всю жизнь делал.
А то, что не все такие задачи решаются именно искалками типа Гугля/Я/Р..., да ещё за три минуты, это очевидно.
Как всё-таки составить упомянутый выше отчёт о сравнительной упоминаемости тридцати основных политических фигур в СМИ различных категорий, с временной шкалой?
Это не умозрительная задача - я видел такие отчёты, за них платят реальные деньги, потом над ними медитируют и стараются сделать какие-то выводы для себя. И таких задач много.
Например, поиск новых тем. Не каких-то известных и явно представленных в сети, пусть и запутанных нарочно сведений или ситуаций, как в кубке по поиску, а только что появившихся. Вот, например, SARS. Или ранее не существовавший мифично-эпический Б.Л.Усамов со своей присной Аль Каидой. Или неожиданно выявившаяся, но сразу всем сторонникам прогресса очевидная, полная, 100% подлючесть Саудовской Аравии - следующего кандидата на избиение.
Вот тема появилась, быстро стала актуальной, её нужно бы автоматически детектировать, локализовать, проследить, составить дайжест и так далее. Да, кстати, и угасание темы - тоже факт многозначительный, тоже стоит проанализировать.
Ну как тут Яндекс запустишь - в пакетном режиме по многим запросам? Роботов заметят и не пустят, знаем-знаем.
А результаты как сводить, кто составит дайджест, как получить статистику и распределение упоминаний?
Временная компонента, совместная встречаемость, вложение тем, сложные объекты с многими реализациями в тексте - не обрабатываются искалками.
Да, деятельность актёров Интернет-сцены - вебмастеров и пользователй интересна, оставляет след в логах Яндекса, но это всего лишь один узкий аспект происходящего в реальном мире, за чем можно следить с помощью текстов. Ведь также можно записывать и анализировать те же частоты и объекты по передачам ТВ, радио и тоже делать выводы.
Так что искалки, хоть и занимают большую часть нашей жизни, а в некоторые периоды и 100% мыслей и действий, как у некоторых из нас, всё-таки не решают всех проблем с текстами и извлечением фактов из них.
Ну, а что искалка - это человеко-машинный кентавр, кто ж спорит. Как, впрочем, и телевизор, автомобиль, компьютер, лопата.
Вопрос в том, что кентавры могут быть разных пород. Например, аналитическая искалка с фиксированной или медленно пополняемой коллекцией, сложным анализом, долгими итеративными поисками-навигациями, сохранением результатов и теоретико-множественными операциями над ними вполне находит своего потребителя и далека от веб-искалки.
Вот например, типовая реализация такой ИС, дающая годовой оборот значительно, на порядок больше Яндекса+Рамблера+Апорта - Консультант+ или Гарант.
Ну, возьмём и прикрутим Яндекс к правовой базе данных - и что? Никому не нужно. Простой поиск там давно есть, а нужен совсем иной. Нужен аналитический сервис, который и продаёт Консультант+ (там кстати, на самом деле оборот на два порядка больше всех веб-искалок в той же самой России).
Да у нас было трое детей и таскать их с собой было непросто. Мы были в Коктебеле пару часов, купили сердоликов с яшмой и поехали обратно.
Дело в том, что такие системы существуют и уже работают. Тот же Ватсон и прочие. Работают с шумом - ну и что? Это же не интернет-искалка.
Я же говорю не о поиске документов, а об анализе совместной встречаемости объектов.
Какой уровень шума устроит аналитика или оперативника, если позволит ему найти новую связь между объектами? Я думаю, в некоторых обстоятельствах и 90% шума его устроит. Если система покажет ему 9 ложных связей, а одну - истинную - и при этом необнаружимую другими средствами - будет ли он доволен? Думаю, да. Ведь альтернативой является ручной просмотр всех документов по делу, а также документов по другим делам (а каких именно и по каким именно, неизвестно).
Более того, он и так целыми днями ходит по ложным следам.
Также вообще не вижу, чем погрешность при распознавании может мешать. Предположим, я хочу сделать отчёт о темперированной частоте упоминания наиболее известных политиков в региональных и центральных СМИ (я видел такой отчёт, сделанный руками за очень хорошие деньги).
Распознавание упоминания политика будет ошибаться, но довольно редко. Ложных срабатываний почти не будет, но часто будет возникать неопределённость - тот Петров или нет. Ну пусть даже в 5 или 10% случаев. На статистику, на качественную картину это не повлияет.
Кстати эту задачу можно решить и спомощью обычной искалки - давать по каждому СМИ запрос с именем политика и смотреть, сколько вхождений. Только долго получится.
И неаккуратно - будет пропущено много вхождений. Ведь у Зюганова кроме канонической формы есть добрая сотня реализаций в тексте. А вот если есть универсальный распознаватель персон, то каждого политика достаточно ввести в него в канонической форме, добавить должности по вкусу и пожалуйте анализировать.
Что касается актуальности, то часть данных и типов объектов почти не устаревает - география, например. А с высокомобильными типами объектов нужно и обращаться аккуратнее.
Здесь просто нужно разделять данные и алгоритмы - распознаватель персон отдельно, со всеми автоматическими подстановками должностей, отчеств и инициалов, а сами актуальные персоны с текущими должностями - отдельно, загружаются и редактируются по месту.
А с Экскалибуром - хороший пример. Экскалибур - традиционная полнотекстовая искалка, причём довольно слабая с точки зрения релевантности. Словарь синонимов в ней либо сделан ручками для показа, либо станартный - из так называемого Русского Семантического Сервера. А делал этот сервер как раз я сотоварищи. В нашем общеязыковом словаре, конечно, Ельцина не было.
Делать заключения об аналитических системах по Экскалибуру неправильно.
Кстати, сейчас в Экскалибуре (его новое имя - Конвера) есть и автоматическая классификация документов, и выделение объектов в тексте, и, кажется, отчёты по их совместной встречаемости - согласно их маркетинговым материалам. Работают ли новации - не знаю, не уверен.
Нет, я, конечно, невыразимо велик, даже по ночам просыпаюсь с бьющимся сердцем и думаю "елы-палы, как же я велик", но в данном случае это просто цитата из детской книжки.
Я забыл ответить с цитатой, поэтому реплика попала логически уже в другую часть перепалки. Там на первой странице дискуссии произошёл наезд на Симакова, причём не мотивированный - просто участнику дискуссии показалось, что указанные запросы "не такие", а Симаков не въезжает в тему. А он въезжает не первый год.
Вообще, хочется призвать участников форума различать в себе мнения и убеждения, потому что дискуссия между обладателем мнения ("я вот впервые задумался об этом и твёрдо считаю") и убеждения ("я думал, проверял и готов доказать") - неравновесна и потенциально конфликтна.
Господа, ну вот, вы уже начали ругаться. Крошки, не ссорьтесь!
Вообще хочу заметить, что Константин Симаков как раз продаёт автомобили МАЗ через сеть и очень успешно. Он практик именно в данной области. Так что скорее всего, его представление о продающих запросах - правильное.
Вот я появился. Был в Крыму, в Лисьей бухте.
Да, поиск новой информации - это одно дело. Важное.
Поиск сущностей больших, чем слова - другое.
Немного основных понятий общей теории всего:
Спор в соседнем топике про то, использовать ли SQL-базы для поисковых машин, как ни странно, не касается основного отличия SQL-баз от текстовых искалок. Видимо, потому, что БД узко понимают как место хранения чего-то там.
БД сделаны для аналитической работы с цифрами. В этом они сильны, для них написан толстый слой аналитики, гиперкубов и так далее. Если данные уже переведены в цифры, дальше их можно вывернуть наизнанку и напечатать на цветном принтере форматом А0 для представления начальству.
Но текст - это не цифры. Фактически, граница между текстом и цифрой ещё не преодолена. Вообще, конечно, тот факт, что Яндекс переводит текст в набор координат вхождений слов - и есть де-факто переход этой границы. Как только вместо линейной последовательности слов у нас появляется массив чисел (номера лексем с координатами), мы можем дальше навернуть любую аналитику.
Правда, Яндекс, по причине объёмов и нагрузок, делает только простейшие вычисления близости и плотности слов и т.п.
То есть яндексовский переход сакраментальной границы - скорее партизанский набег. С Гуглом ситуация примерно такая же. И те и другие ещё применяют соображения относительно структуры гипертекста (индексы цитирования), но это специфично для Интернета, так что пока об этом забудем.
А теперь представим себе, что:
а) в системе нет жёстких ограничений по времени и нагрузке,
б) в тексте обнаруживаются не просто слова, а объекты - персоны, даты, географические объекты, должности, посты и позиции, организации и фирмы, номера ГНИ, телефонов, авто, оружия и так далее, и тому подобное.
в) в БД заносятся цифровые данные о вхождениях объектов (координаты в тексте, включая даты документов).
Таким образом, из "аналогового" текста получаем цифры совместной встречаемости объектов.
Цифровой Рубикон перейдён.
Теперь достаточно применить те самые гиперкубы OLAP, чтобы получить генерацию сколько угодно глубинных отчётов о связях между объектами. В отличие от простейших соображений Яндекса/Рамблера о связях между словами в тексте получаем заключения о связях субъектов и объектов реального мира. Обязательна, конечно, временная координата.
"Тот самый господин, что обратился к нам в банк за кредитом в 5 млн. от ЗАО "Лабеан", оказывается, в 1991 году был женат на соучредителе фирмы, владевшей неким ЗАО "Ясокан", не вернувшим кредит в 2 млн долл. другому банку".
"Тот Петров, которого мы хотим сманить из Газпрома, в 1993-1995 работал в Стиплере, где в те же годы работала и Иванова, тоже в маркетинговой должности. Сейчас она - в Оракле, куда мы недавно пристроили Сидорова. То есть подобраться к Петрову можно через неё".
"Депутат Думы от Лютерально-аллергической партии Откатнов в 1985-1988 гг. работал бригадиром в стройотряде МИСИСа, где тогда же комсоргом работал Безинштейн, в настоящее время работающий топ-менеджером в американском инвестиционном фонде "Kick Back". В дочерней структуре этого фонда - экологической службе Гринбакс в настоящее время служит секретарём-референтом жена сына Откатного. В совет попечителей Фонда, в свою очередь, входят люди, близкие Чейни, вице-президенту США. Можно сделать и проверить предположения об ангажированности депутата".
Все эти выводы можно делать по открытой прессе.
Ясно, кому в первую очередь нужны подобные системы - МВД, ФСБ, ГРУ. А ещё рекрутерам, политологам, маркетологам.
Кое-что разрабатывают они сами, кое-что - для них коммерческие фирмы.
Основной камень преткновения - распознаватели объектов. Объекты все разные, поведения ветреного. Попробуйте хотя бы прикинуть алгоритм распознавания и нормализации всех форм записи даты в тексте. Ведь мало распознать - нужно свести к канонической форме.
Кроме того, объекты, очевидно, не плоские, а организованы в сложную тезаурусную структуру. Общее к частному, часть-целое, синонимы, гипонимы-гиперонимы, и так далее. Топ-менеджер, директор, президент, исполнительный директор. Владивосток, Приморье, Курилы, Дальний Восток.
Этим тоже занимаются разные фирмы. Мы занимались в Медиалингве, но пока перестали - занимаемся фильтрацией, спам фильтруем.
Люди, в общем, работают. В частности, Гарант в апреле объявил о выпуске библиотеки распознавания объектов. Есть мощная система мониторинга периодики у IBS, где никто не заморачивается особенно насчёт автоматического распознавания, а просто объекты мониторинга (30,000) помечаются руками (мышками) технического персонала.
Ну и так далее.
Увы, Борис, тут есть теоретический предел: при приближении объёмов простого текста к 10-12 Гбайт, поисковики с хранением индекса в реляционных базах перестают работать.
А сейчас типовой объём данных в копрорации включая периодику,
интернет-контент и пр. уже близок к этим цифрам.
Как раз тут уверенности в реализуемости всех нужных идей - нет.
Выше было указано, что и Оракл, и MS SQL не хранят полнотекстовый индекс в своей БД, а используют специальные структуры данных, как впрочем, и все интернет-поисковики. В этом смысле можно пользоваться было бы и Ораклом, если бы он открывал доступ к своим полнотекстовым возможностям. Так ли это - не знаю.
Ну, а то, что Оракл эмулирует стандартный запрос типа Select и потом внутри подменяет его на полнотекстовый аналог - это хорошо, программировать проще. Если вы эту возможность имели в виду, то и спорить не о чем.
Что касается коммерческой целесообразности для больших массивов данных, то пример интернет-поисковиков даёт совершенно однозначный ответ. Они весьма прибыльны (обороты Гугла и Увертюры очень впечатляющие), доля их в мировом интернет-бизнесе и абсолютные доходы быстро растут, и при этом они используют свои собственные БД.
При этом качество поиска - второстепенно, в первую очередь влияет актуальность, скорость, полнота, отсутствие спама при хорошей релевантности. Очевидно, что в лабораторных условиях или условиях неспешного внедрения у крупного заказчика легко получить релевантность выше, чем у Яндекса или Гугла, а вот построить бизнес-процесс в масштабах Рунета или Интернета в целом - очень трудно.
Заметим, что и MSN только что начала делать свой собственный поисковик, и Увертюра купила пару поисковиков - вместо того, чтобы покупать универсальную базу данных.
Зарабатывают они на поиске, конечно. Как иначе назвать контекстную поисковую рекламу?
Или Вы считаете, что зарабатывать на поиске - это брать центы за запросы? Или продавать поисковики компаниям - ну и тогда, Гугл и Верити как раз на поиске и зарабатывают. Гугл лицензирует поисковик
очень широко, в том числе крупнейшим интернет-игрокам, Верити - лидер рынка корпоративных поисковиков.
Фактически, мы спорим о разных вещах - о различных бизнес-моделях. Вы для себя выработали работающую схему своего бизнеса, когда Вы думаете о семантике, о качестве услуги, а о хранении и эффективности думать считаете не обязательным при прочих равных условиях (и в вашем бизнесе это может быть оправданно - пусть Оракл об этом заботится, на среднем, но стандартном уровне), а Илья думает в первую очередь об эффективности и хранении, а во вторую - о семантике (но думает!), и если он не будет так делать, его проект рост Интернета сожрёт за полгода.
При том, что вы ведёте клиентов годами, годами внедряете систему, обучаете пользованию, подстраиваете тезаурусы, действительно лучше использовать стандартные решения там, где это не касается вашей ключевой компетенции - качества очень углублённого поиска по чистым и выверенным массивам данных. Ну и хорошо.
Но нельзя советовать пламенным борцам со змеем экспоненты поступать так же.
По поводу указанных Ильёй наиболее популярных (и дорогих, кстати) искалок, то Оракла как хранилища текстового индекса там нет, конечно. То есть, может, документы и графику они и позволяют хранить в Оракле, но полнотекстовые индексы, естественно, самописанные.
Как, вы, однако, раздухарились! Перешли от тезаурусов к Ораклу! Не дай Бог начнёте Windows и Linux сравнивать.
Мне всегда казалось, что проблема с Ораклом и другими универсальными базами данных в том, что полнотекстовый индекс представляет собой очень своеобразную структуру - длинные записи существенно переменной длины. И хранить их в SQL-базе ну очень невыгодно. Отсюда и прогнозируемые Борисом расходы на невозможное и ненужное внедрение Оракла в Гугл. Я, кстати тоже думаю, как и Илья, что там ошибка примерно на порядок или два в меньшую сторону.
Язык просто очень отличается от цифр, а SQL-ные базы были заточены всё-таки под хранение цифр.
Я наблюдал, например, как писали полнотекстовый поисковик на Постгресе. После двухнедельной эйфории и шапкозакидательства любители данной БД пришли к нам за данными о популярности слов и начал слов - слишком большие перекосы в алфавитном индексе возникли, пришлось резать на куски, а куски неравновесные и т.п....
Ну и по поводу Oracle Context Option - там, по-моему, индекс-то как раз отдельный и именно полнотекстовый, традиционный для поисковиков? Впрочем, могу ошибаться - Андрей поправит. По крайней мере, Index Server в MS SQL - точно всегда был совершенно отдельный.
Что касается рассуждений о цене перехода на Оракл - а фишка-то в чём? Зачем Гуглу Оракл, я никак не возьму в толк? Чобы опять стать убыточным, ради чистой любви к СУБД?
Получается, что бедные Оракл не покупают (хотя тайно вожделеют), а как разбогатеют, так сразу давай. Оракл - что-то вроде актрис и шампанского получается, способ спустить деньги с шиком.
Да, насколько я знаю, все, кто прислал запрос, получили.
Ну, там редактирование поверхностное - сколько я успел сделать за три-четыре дня, столько там и отредактировано. Ещё две недели на неё тратить я уже не мог.
