Конечно же, я очепятался: не SE, но SEO.
Смешной топик.
Любая новая тематика встпечает определенные трудности
(поэтому масса работ по "углубить" и "о ...").
Если есть проблемы с позиционированием, то есть
простой способ поднять "научность".
Достаточно, двинуться немного в сторону.
Не абстрактный SE, но:
- автоматизация SE по алгоритму (автоматическая подстройка под изменяющийся во времени алгоритм поисковика!);
- автоматизация SE по количеству (снижение трудоемкости
сопровождения одновременно многих сайтов);
- отделение честного SE от нечестного
и т.д.
А вот чемпионская тема - Вам понравится:
"Противодействие SE"
Bye
посмотрите http://www.dialog-21.ru/specific_direction.asp?dir_id=1278&forum_id=1408&parent_message_id=1408 ,
а также
http://bokrcorpora.narod.ru
Но для реальных нужд - для Вашего словаря - лучше
прогнать Ваш же собственный корпус, затем посмотреть,
чем надо дополнить словарь, а что у Вас будет считаться ошибками.
Я не понял.
Это проверка состава словаря или Вы сомневаетесь в качестве
кодирования?
Добрый день, Александр!
IMHO для задач информационного поиска (индексирования, расширения запроса и подсветки) требуется своя морфология
(например, полезно соединять "итало", "итальяно", "(по-)итальянски",
"итальянский"; но, возможно, разделять глаголы и причастия),
для других задач своя.
Выверенный по какому-то основанию корпус - это неявное задание
правил того "русского языка", с которым приходится иметь дело.
А так я попробовал дать формальный ответ на формальный вопрос.
По-моему (могу ошибиться с точностью цитаты), также "бюджетов"
от "бюджетный", "шкафов" от "шкафовый". Это, конечно, очень интересно,
но сильно вредит в практических приложениях.
Вы не могли бы объяснить зачем это может быть нужно,
и как ВЫ собираетесь сравнивать?
Если посмотреть программу конференции WWW2003:
http://www2003.org/detailed.htm, то там густо рассыпаны
слова Semantic Web (XML, RDF).
Если основным игрокам удастся договориться по стандартам,
то поисковая машина нового поколения будет работать в Semantic Web.
Так как, если им удастся договориться, то сначала на RDF/XML
перейдут крупнейшие провайдеры контента, затем появятся специальные браузеры и "Front Page'и", и за два-три года, учитывая экспоненциальный характер роста количества страниц,
БОЛЬШИНСТВО страниц станет какими надо.
Semantic Web предназначен для профессиональной работы,
для автоматического поиска одним компьютером в поисковой базе
другого.
При этом, например, в России, опять же учитывая экпоненциальный рост,
но уже новых пользователей, еще в течение двух-пяти лет, то
абсолютное большинство будет ПОЛНОСТЬЮ УДОВЛЕТВОРЕНО возможностями
существующих систем.
И хотя где-то с Semantic Web связывают перспективы для приличной доли рынка, но не у нас, по причине отсутствия хороших больших ресурсов,
как их не размечай.
День добрый!
Чтобы говорить о методике надо определиться с тем, что
понимается под ошибкой.
Дело в том, что и в русском "литературном" языке масса
спорных моментов, которые разные исследователи толкуют по
разному. Кроме того, язык развивается и постоянно изменяется.
Плюс для реальных задач можно пойти на некоторые упрощения.
В общем случае, проще всего взять корпус текстов побольше
(лучше авторитетный - то есть выверенный кем-то),
прокрутить, проанализировать неизвестные программе разбора слова.
Если словоформа написана без ошибок, лемма есть в словаре, но не найдена - неправильная парадигма.
"Избыточность" парадигмы (лишние словоформы для леммы) проверять сложнее, но это достаточно мало критично в задачах обработки текста
(если не требуется проверка орфографии). Формально можно предложить
прокрутить ОЧЕНЬ большой корпус текстов - чтобы там встречались ВСЕ
словоформы словаря. И посмотреть, что не было употреблено.
Но это утопия - нет больших выверенных корпусов, а пока их будут
создавать, они немножко устареют.
О, и мне тоже интересно!
Когда-то (довольно давно) были вполне реальные (но скорее практические) трудности для локальных реляционных баз данных,
индекс которых основан на B-деревьях, - для ускорения работы
производителями закладывалось внутрь определенное предположение
о предельном размере индекса. При превышении этого размера начинались
разные проблемы.
У меня Oracle (несколько баз на разных компьютерах), самая
большая примерно на 10 Гбайт текстов (что-то типа 500 млн. записей,
может больше),
дисковое пространство особенно не экономим. И есть у меня стойкое
ощущение, что могу я без всяких проблем увеличить базу где-то
на порядок - пока дисков хватит (можно еще паковать индексы).
В случае чего, разнести на разные машины, прозрачно использовать несколько баз и т.п.
Но - не проверял.
В целом же, я согласен с И.Ашмановым.
Существует несколько разных бизнес-моделей, которые и определяют
требования на поисковую машину. Требования разные - и машины разные,
хотя имеют много общих черт.
Есть несколько обстоятельств:
1) Я ввязался в эту дискуссию совсем не как сторонник навязывания
Oracle всем и вся. В течение некотого времени наблюдается
несколько поверхностный взгляд на возможности больших SQL баз данных
в задачах поиска, среди которых много разных и интересных помимо
поиска во всем глобальном Интернет.
Я попробовал объяснить, что большие SQL базы имеют массу возможностей
для эффективной обработки данных. Производителей SQL баз очень много, большие игроки отличаются тем, что там многое оптимизировано
(исполнение вложенных запросов, исполнение длинных запросов,
выбор специальных, но стандартных объектов, работа в оперативной памяти и т.п.).
Почему же ранжирование не может делаться? Выборка формируется в памяти - ее можно там оставить или в худшем случае (сложная обработка)сохранить в кэшируемую область, выглядеть она по-прежнему будет как стандартная таблица, затем делайте, что хотите.
2) Ну зачем кому-то писать новый поисковик для глобального Интернет?
Здесь больше не технологических проблем, а финансовых,
в смысле ну сделает, а где профит? Делать из академического интереса?
Яндекс, Рамблер и пр. НЕ ПОЛУЧАЮТ деньги за поиск, а получают
совсем за другое - за рекламу, за спец сервисы.
За лицензирование своих технологий (типа Яндекс.Сайт) - то есть
работы на корпоративном рынке.
А вот по последнему пункту уже возможна конкуренция, в том числе
и с решениями на основе реляционных баз данных.
При этом потребителя часто (но не всегда, конечно) собственно поиск интересует незначительно, простой поиск еще меньше.
Потребителю надо совместить поиск с поиском, например, по собственным базам или подавай "анализ" (именно здесь работают Autonomy и Verity -
и они востребованы).
А для своих БД он уже либо купил что-то из большой SQL базы
(Oracle, MS SQL, Sybase, DB2, Informix, ...) либо готов купить.
3) То есть, выбор, например, Oracle в качестве платформы информационной системы обусловлен:
3а) уверенностью, что все что захотите сделать, будет
можно реализовать
3б) относительно слабой зависимостью от текучки персонала
3в) ориентацией на самоокупаемость собственно технологических
решений
Я не очень понимаю в общей постановке что такое "полнотекстовый
индекс".
В качестве справки (года до 1996 мы пользовали Oracle TextRetrieval
- предыдущее название Oracle interMedia Server) Oracle хранил
поисковый индекс в битных строках, хитро их записывая, и хитро
(весьма быстро) их доставая и обрабатывая. Затем мы перешли на
свои структуры данных. Фишка в том, что данные достаются как в том
так и вдругом случае SELECTом, а как на самом деле - даже не знаю - но для наших целей вполне эффективно.
С уважением,
Борис
