Действительно, часто бывает полезно в долгом споре выяснить,
о чем спор и оговорить общие определения.
Насколько я помню, данная тема началась с вопроса о выборе
поискового движка для сайта типа государственного портала.
Может быть эта тема несколько ортогональна направлению форума
в целом, но она такая.
И эта тема имеет свою специфику.
Я лично с трудом представляю спам на правительственном портале.
Мне также кажется, что, например, полнота при поиске
по законодательству важна и т.п.
Я надеюсь, что спрашивающий (Игорь) давно уже сделал
свой выбор, а тема сдвинулась в обсуждение некоторых
профессиональных вопросов.
И одним из вопросов был о вопрос об операторе SELECT,
на который я постарался ответить, что это лишь удобный
формализм (типа middleware), а его исполнение приводит
в современных SQL базах к вызовам тех или иных
процедур низкоуровневого доступа к данным.
По памяти ответить трудновато (у меня есть папочки, по крайней
мере на три первых номера в списке, но не дома), но мне кажется,
что первые номера в списке представляют собой надстройки
(интеграторы/анализаторы) над существующими индексами и прежде всего над индексами SQL баз, и слово Oracle там встречается очень часто.
И сколько я помню из личных бесед с представителями
Метатехнологии (Весть-Метатехнологии) для Convera / Excalibur RetrievalWare стандартной платформой является опять-таки
Oracle.
Так что, аргумент в виде приведенного списка я не понял,
мне кажется он для меня более выгоден, чем Вам.
С уважением,
Борис
Чуть-что, сразу переход на личности.
Да, в гимназиях мы не обучались...
Насчет "очень глубоко".
Да, мы работаем с Oracle. В нашей
практике несколько раз возникала проблема ускорения исполнения запросов, и я ЛИЧНО ставил нашим Oracle программистам вопрос:
"либо вы в сжатый срок находите решение задачи под Oracle,
либо пишем на С или чем нибудь подобном".
Так вот, ВСЕГДА удавалось решить проблему средствами Oracle.
Возможно, конечно, я плохой алгоритмист (в смысле у меня заниженные требования к тому, что значит "решить проблему").
Но попробуйте допустить (на секунду) такие допущения:
- программисты Oracle (не самые глупые ребята) оптимизировали
уже доступ к своим объектам (таблицам, индексам) и т.п,
то есть "оптимизировали очень глубоко, с борьбой за каждую лишнюю,
но часто исполняющуюся инструкцию процессора";
- Вы как программист на Oracle можете из этих ЭФФЕКТИВНЫХ
кубиков складывать то, что Вам надо.
Это не значит, что это легче чем программировать на С,
так как трудности перетекают в проектирование адекватных
структур данных, и в само умение расставить "хинты",
опять же в денежки за техподдержку.
Но, повторяюсь, приличный выигрыш - организационный.
Есть рынок программистов на Oracle, логика программ весьма прозрачна,
можно воспользоваться помощью высококвалифицированных экспертов
по всему миру (которым не надо будет много объяснять).
Тут слишком много вопросов. На все ответить трудно.
Что называется "коммерческой" искалкой?
Для меня признаком "коммерческой" является количество продаж/установок
и обший объем продаж.
Здесь искренне желаю Яндексу, Рамблеру и другим достичь уровня оборота и прибылей Oracle.
Мы говорим об одном и том же, но по разному. Вас интересует только
Интернет, меня - корпоративный сектор, а также то, что может быть названо как "тематический Интернет" (часть Интернета под заказ,
с полной, а невыборочной выкачкой страниц, с вычищенным без дублей, спама и т.п. содержанием).
Эти коллекции достаточно большие, но, естественно, меньше чем Интернет.
А нужен ли, с точки зрения отдачи (а не только с точки зрения социальной функции), весь Интернет, если "первичных" страниц там
гораздо меньше общего числа (перепевки, дешевые "размышлизмы" и т.п.)
Стратификация Итернета по темам, кстати, на мой взгляд должно быть более интересно "оптимизаторам" чем раскрутка в общих поисковиках.
Зачем же "торговать электрокабель" на Яндексе или Рамблере -
не лучше ли стараться пробиться в топ-листы специализированных
площадок, деньги - на порядок больше (с бюджетом в 150 уе не подходить), а спама на порядок будет меньше - там банят сразу и навсегда.
Вас интересует только поисковик. Наших клиентов
обычно интересует поисковик, интегрированный с чем-то иным.
Oracle, как наверное и любая современная мощная SQL база
(наиболее, говорят, сильна DB2) подходит и, главное,
УСТРАИВАЕТ наших клиентов
Поэтому я, наоборот, посоветую. Особенно для начинающих.
Для того чтобы выйти (или попытаться выйти) на что-то типа
самоокупаемости - выйдет дешевле.
А то начнет человек что-то делать свое (проходить длинный путь проб и ошибок), а потом ему Илья и Андрей так же уверено заявят,
что "это все придумал Черчиль в 18м году". То есть задешево
сваять свое оригинальное и хорошее не получится.
bvd
1) Насчет PL/SQL и любого алгоритма.
PL/SQL представляет собой обычный язык программирования.
Написать можно по-разному, и даже если я ошибаюсь
насчет мощи PL/SQL, тогда дело решится вставкой в совсем уж узкое место маленького кусочка на С или Java.
В этом случае, надо говорить точнее, конечно, не "средствами Oracle"
а "на основе средств Oracle".
Что я имею в виду. Например, "кишка" Яндекса может быть задана
стандартным объектом типа IOT (Index Organazed Table). То есть
на физически на диске будет лежать аналогично. Можно повозиться и с
битами, но пусть будут байты (пусть размер базы будет на порядок больше).
ORACLE обеспечивает возможность выборки из базы в оперативку
(например, "таблицы" или "массивы" в памяти), которые можно
там крутить и т.д.
2) Насчет будет ли работать в масштабах Google - честно не знаю.
Чтобы проверить в масштабах Google надо пять-десять миллионов долларов. Чтобы проверить в масштабах Яндекса - где-то миллион.
Проблема не в количестве документов, нужны настройки пулов
запросов, в конце концов, разнесение на разные сервера.
Кстати, давно мне уже не удается исполить запрос на Google.com
- все меня перекидывает на Google.ru. Поэтому насчет МНОГИХ тысяч серверов непонятно (в том плане сколько серверов используются
для обработки одного запроса).
3) Я просто хочу сказать, что как-то укрепилась точка зрения,
что раз SQL - то B+ деревья, откуда можно оценить предельную скорость.
На самом деле года с 1996 (может и раньше - не знаю),
по крайней мере ORACLE (наверно и остальные) предоставляет
в распоряжение разработчика гораздо более широкий набор
объектов, доступ к которым пишется на вполне качественном
уровне (низкоуровневом) и совершенствуется от года в год.
Можно, конечно, верить, что русские программисты круче
американских, китайских или индийских, но это неочевидно.
Ответ по сути примерно такой.
SQL, элементом которого является команда SELECT, не более чем язык
программирования (точнее для ORACLE - процедурное расширение PL/SQL),
описывающий правила доступа к данным.
Удобство использования SQL не имеет НИКАКОГО отношения к эффективности
доступа к данным.
Удобство использование SQL - организационное! Вы в значительной
мере ослабляете зависимость от программистов - т.н. "создателей"
кода, уход которых может поставить под угрозу весь проект.
Удобство использования универсальных баз данных в том, что
можно на одной базе решать разные задачи, например, еще
документооборот, расчет зарплаты и т.п.
А эффективность поиска определяется структурами данных хранения индексов, способом доступа к данным, предварительным разбором запроса.
Не стоит думать, что реализация SQL - выборка данных одинакова у всех
производителей. Более того, у каждого серьезного производителя
существует множество параметров, влияющих на эффективность.
При этом Вы можете регулировать доступ к таблицам - как к стандартным
В+ деревьям, по разного рода индексам (можно регулировать последовательность их применения), можно как к хэш-таблицам,
можно использовать бинарные индексы, можно
сливать воедино таблицы и индексы, можно разбрасывать таблицы/индексы
по разным машинам (в том числе по частям) и т.п.
То есть исполнение одного и того же SELECT может быть РАЗНЫМ
в зависимости от установок других параметров.
И все это достигается всего десятком команд PL/SQL и некоторым
временем на перестройку структуры данных.
Лично мне кажется (это и рынок подтверждает) - ORACLE лучше в том плане, что его можно настроить эффективнее чем другие БД на решение
реальных задач - но требует определенной подготовки.
MS SQL, говорят, лучше для задач, где оптимизация не очень важна,
где быстро и удобно получить результат на "среднем" уровне.
Утверждаю, что стандартными ДОКУМЕНТИРОВАННЫМИ средствами Oracle
МОЖНО в точности повторить алгоритм обработки ЛЮБОГО поисковика.
НО! Oracle является платформой для УНИВЕРСАЛЬНЫХ решений.
Это значит, что ЦЕНА берется за большее количество функций,
включая сопровождение прав пользователей, ведение других баз данных,
возможность легкой ИНТЕГРАЦИИ с базами, которые будут созданы в будущем и т.п.
Поэтому использование ORACLE для задач типа Яндекса или Рамблера
будет стоить больше чем специализированная база на ограниченное число функций - надо ставить больше машин, приобретать лицензию на
паралельную версию и т.д.
Причем за это придется платить! Неформальный закон ценообразования ORACLE - лицензия стоит столько же, сколько железо. А "глобальные"-то поисковики в большинстве УБЫТОЧНЫ - платить нечем!
В силу изложенного ORACLE (например) в глобальных поисковиках не используется, но используется в корпоративных информационных
системах. При этом, конечно, RCO - далеко не единственная
система на ORACLE с поддержкой русского языка (я лично знаю штуки четыре, которые поставляются в достаточно уважаемые организации).
В результате для реального проекта все определяется соотношением между Функциональностью, Деньгами и Временем, а не выбором
языка описания доступа к данным.
Добрый день!
Дискуссия несколько отклоняется от первоначальной темы
"отечественая локальная поисковая система для работы в госсекторе"
(сравнительно небольшое число документов - не более ста тысяч -
достаточно чистых - прогнанных через спелчеккеры :) )
в сторону "какая должна быть морфология русского языка".
Но некоторые вопросы весьма примечательны и их стоит обсудить
подробнее.
Периодически возникает вопрос о борьбе за "чистоту языка".
И это ПРОБЛЕМА, а не задача - в смысле, что решить нельзя,
а можно только приблизить тем или иным способом.
Программа морфологического разбора (словаррная или бессловарная)
включает (или не включает) в себя:
- словарь;
- модели и алгоритмы обработки омонимичных словоформ;
- модели и алгоритмы обработки неизвестных словарю слов.
Есть живой русский язык, проявляющийся в корпусе текстов.
Язык достаточно быстро меняется - появляются новые слова,
видоизменяются правила использования существующих и т.д.
Но есть некая "норма", фиксируемая в авторитетных словарях и
сводах правил.
Беда в том, что эту норму в реальных текстах нарушают все
кому не лень.
Но это их дело. Дело же разработчиков программ морфоразбора
ВЫБРАТЬ: какому из принципов следовать:
- бороться за чистоту "нормы" и перекладывать тяжесть на
модели обработки неизвестных слов
- следовать за текстами - расширять словари, в том числе за
счет "полуошибок" (то есть возможное нарушение "нормы",
но в пределах понимания).
Вопрос о "норме" сам по себе очень сложен. Чего стоит, например,
буква "ё". Я, например, не знаю надо ли склонять словоформу "Keva"
(еще один пример - слышал, что Л.Слиска считает правильным,
чтобы ее фамилию не склоняли - в грамматическом смысле :) тоже).
При этом одна и та же программа морфологии (в той или иной модификации в моделях и словарях) может применяться и как
в качестве ядра системы проверки орфографии (тут надо бороться
за "норму"), так и в качестве компонента ядра ИПС.
В последнем случае могут быть разные решения.
В своей работе мы стремимся, не нарушая по-возможности "норму",
все же обеспечить максимальное покрытие.
Что касается конкретного забавного примера о "ненормальности"
множественного числа у некоторых существительных - одно время
(году в 1994-95) мы чистили словарь (исходно Зализняк) и по
этому критерию. Но затем напоролись на реальные случаи употребления,
пришлось иногда и возвращать.
Ведь пишут, а значит, могут и спросить, ожидая именно правильной
модели морфологического словоизменения, а не просто совпадения
словоформы - это-то сделать элементарно.
Кстати, приведенный примерчик (множественное число) встречается
в свалке Интернета (по индексу Яндекса).
Попробуем подвести итоги.
На мой взгляд к любой морфологии (как комплексу словарей и моделей)
можно предъявить кучку претензий (обычно уже известных заранее
- примерчик-то не нов). Но является ли это принципиальным?
Более важна управляемость процесса:
1) либо Заказчика устраивает, что есть
2) либо все весьма быстро должно быть доработано под конкретные
задачи ("норму" или "тексты"). А это вопрос организации
работ, может быть посчитано (например, с привлечением
внешней экспертизы, если только издержки :) не превысят
выгоды)
Еще пара мелких замечаний.
Аннотацию делать легко, можно и без словаоей и т.п. Разница в информативности между аннотациями,
полученными разными методами небольшая (см. <a href="http://www.itl.nist.gov/iaui/894.02/related_projects/tipster_summac/summac-final-report-part2.ps">здесь - 20Мб 😮 файл 1998 года</a>).
Штука в том чтобы сделать СВЯЗНУЮ аннотацию - иногда нужно
(см. на странице 22-23 указанного документа :) ).
Насчет классификаторов. Если количество рубрик не превышает 100,
то предложено туча методов с примерно одинаковыми результатами.
Но! Готов дать два ящика пива тому, кто продемонстрирует свою
работающую автоматическую систему сколько-нибудь качественно равномерно рубрицирующую по 1000 рубрик, например, правовые документы.
А так много чего "есть". Говорят и "синтаксис" есть и "семантика",
чего только не услышишь...
Борис Добров
Уважаемый Keva!
Не я начинал, не мне оправдываться.
Чтобы не спамить - захотите - найдете по фамилии.
Я же не говорю, что наша морфология лучше всех.
Я только утверждаю, что она не хуже Вашей
Есть система ведения словаря, ведут его профессиональные лингвисты.
То есть, если взять массив текстов, осуществить работы по
пополнению словаря, то показатели полноты/точности
по словоформам/леммам будут у всех одинаково высокими
с незначительными отличиями.
У нас своя коллекция текстов, сейчас, как раз 10 Гбайт,
около миллиона документов.
Насчет словарей синонимов - мы используем тезаурус -
нам как раз кажется, что
для того чтобы они помогали при поиске их надо ПРАВИЛЬНО
делать, иначе, действительно только хуже.
Насчет качества поиска - на наших текстах (тестирование
вопрос не простой) в среднем при СОХРАНЕНИИ точности
полнота в 4 раза больше. Результаты опубликованы.
Я в курсе.
Мы, кстати, слово "семантика" сами не любим.
И в своей организации я сам приложил руки к закрытию
такого проекта.
Однако определять тематику общественно-политических текстов
(в том числе на английском языке) мы умеем неплохо, умеем автоматически рубрицировать (в том числе
по большим иерархическим рубрикаторам - более 1000 рубрик),
автоматически порождать достаточно связную аннотацию.
С уважением, Борис Добров
Oops - что-то отказалась система публиковать сообщение,
стерев набранное - послал не то...
Хорошо, что такое не в первый раз - сохранил в буфере.
Keva, Keva, ...
Ах как легко и просто плюнуть походя.
Типа "сам не читал, но считаю своим долгом заявить..."
Уж морфология-то у нас есть и по качеству не хуже
(имени Ж.Аношкиной), по-медленнее, конечно, чем от Keva,
но более чем достаточна для поиска по локальному сайту.
Доказывать что-то бессмысленно, но если работу покупают - значит
это кому-нибудь нужно...
С выводом по софту для локального сайта согласен,
если требуется только морфология.
Те кто реализовал только морфологию (и хорошо реализовал)
- что достаточно в большинстве случаев - уверены, что
ничего другого быть не должно.
Но задачи бывают разные, и правильный ответ - для каждой
задачи нужен свой метод (одной морфологией все не сделать).
Более того, Игорю (судя по всему из города Питера),
стоит учесть, что и конкуренты его придут на тендер
с такой же морфологией (а то и с той же - имени Keva).
Б.Добров
Причина в том, что не проблема не интересна,
а неинтересно содержаемое предлагаемого,
через которое предлагается еще и продираться.
Дело в том, что предлагаемое НЕ НОВО.
Литература по классификации и смежным вопросам огромна.
Наиболее близко по теме: ассоциативные тезаурусы, коллокации,
матрицы смежности, корреляции, LSA и т.д. и т.п.
Есть продукты, см. например, NeuroK.
Проблема в том, что вся статистика и др. механистичные процедуры
неплохо формируют, максимум, верхнюю часть списка "ссылок".
Но все быстро рассыпается с уменьшением частотности и НИКТО
еще не сделал иного. По-моему, так и не сделает, из-за фундаментальной неполноты текстов.
При этом даже верхняя часть списка может быть полезна пользователю,
например, для уточнения запроса.
Но это УЖЕ РАБОТАЕТ в разных системах.
Идеи с претензией, но без сравнения с другими,
опубликованными в литературе или в Интернете,
обсуждать в форуме скучновато.
Следует понимать, что одного словаря Зализняка для
хорошей программы морфологического анализа недостаточно.
<p>
Необходимо 3 части:
<ol>
<li> морфологический словарь.
<p> Словарь Зализняка весьма устарел,
кроме того некоторые вещи в нем не очень хороши для
автоматической обработки. Например, формы прилагательного
ФИНАНСОВ, БЮДЖЕТОВ, ШКАФОВ. Все правильно, но в информационном
поиске плохо.
<p> Есть и несколько проблем концептуального плана:
краткие формы прилагательного, слова с дефисами
<p> Большинство программ со словарной морфологией используют
"клоны" словаря Зализняка собственной выделки. Сначала
сокращают количество статей тысяч на 20-30 .
Затем тысяч на 50 увеличивают.
<p> Кроме того, язык постоянно растет, появляются новые слова.
Нужна система пополнения словаря.
<li> программа быстрого доступа к словарю<p>
<li> обработка неизвестных словарю слов
<p> Реальные словари имеют 100-200 тысяч словарных статей.
Пусть это покрывает более чем 99.7% (реальные цифры)
известных ВХОЖДЕНИЙ словоформ. Считая средний документ
размером в 400-500 словоупотреблений, получаем, что,
для коллекции в 10,000 документов у Вас 10,000 неизвестных слов,
для коллекции в 100,000 документов у Вас 100,000 неизвестных слов.
<p> Это и ошибки, и специально коверкуемые авторами слова (передача
иностранной речи), и имена собственные (в БОЛЬШОМ количестве)
<p> Есть несколько подходов:
<ul>
<li> генерация гипотез, сравнивая с похожими словами,
то есть используя "сложные модели";
<li> отсечение приставок (АВТО-, МОТО-), суффиксов (-ДЗЕ, -ШВИЛИ) и т.п.
("простые модели")
<li> пользовательский словарь, с приближенным описанием морфологической
информации
</ul>
</ol>
Реальность состоит в том, что хорошую программу морфологического анализа
делают только "команды", причем с участем лингвистов.
Да, морфологический разбор - это пол-дела, для поисковых систем надо
еще адекватно подсвечивать результаты (обратная задача), фрагментировать текст
и т.п.
Если нужна морфология:
<li> есть деньги - лучше купить у кого-нибудь существующую
- дешевле выйдет. Только берите с сопровождением
<li> нет - не стоит тратить много времени - делайте самую простую,
но не надейтесь "побить" существующие.
<p> Рекомендую самую простую - отсекайте с конца слова несколько букв,
в зависимости от длины - дешево и сердито.
Всего хорошего,
