Стандартная поставка Oracle Text способна работать со всеми языками, поддерживаемыми Oracle, но в рамках сравнительно простого контекстного поиска, для которого различия языков несущественны. То есть контекстный поиск возможен и для документов на русском.
В то же время продвинутый набор возможностей, включающий морфологический анализ, нечеткий поиск и другое, присутствует в готовом виде только для шести западноевропейских языков. Русского среди них нет.
Стандартная поисковая машина ничего не знает о русском языке, поэтому русский текст для нее представляет собой просто цепочки символов, разделенных пробелами. Именно по таким “словам”, заранее выделенным из текста и занесенным в поисковый индекс, и позволяет искать документы поисковая машина. При этом язык запросов хорошего поисковика разрешает задать различные ограничения на искомые комбинации слов в документе, что позволяет в принципе формулировать очень сложные запросы, точно и полно описывая искомый в тексте смысл. Однако проблема создания хороших информационно-поисковых систем на базе стандартных поисковых машин заключается в том, что пользователь желает сформулировать свой запрос в виде простого набора слов или словосочетаний на русском языке, ожидая от машины понимания хотя бы элементарных способов того, как эти слова могут быть написаны в тексте.
Для контекстного поиска с учетом всех вариантов написания слов запроса в тексте можно в принципе использовать один из компонентов для морфологического анализа, присутствующих на рынке. Такой компонент позволит для каждого слова запроса построить все его грамматические формы, существующие в языке. Однако на практике “лобовое” применение любых таких компонент не может обеспечить высокого качества поиска из-за ряда причин. Так, большинство поисковых запросов, по которым пользователь может найти требуемые тексты, состоят более чем из одного слова. И здесь начинаются проблемы – как обработать запрос из нескольких слов, в каком виде транслировать его поисковой машине?
Во-первых, не ясно, как искать вхождение слов в документ – как цепочку подряд следующих слов (используя оператор языка запросов для поиска “по фразе”), как набор близко расположенных слов (используя оператор типа NEAR) или просто как набор слов, встречающихся совместно в одном документе (используя оператор AND).
Во-вторых, не ясно, как расширять слова запроса грамматическими формами. Если применять морфологию “в лоб”, то естественное решение – это построить все формы для каждого слова запроса и подставить их вместо исходного слова (используя оператор OR). Точность поиска при этом оказывается не высока по двум причинам. Первая из них заключается в том, что без учета грамматических связей слов запроса нет возможности разрешить омонимию: например, при обработке запросов “решение суда” и “грузовые суда” все варианты словоформы “суда” следует строить в первом случае от слова “суд”, а во втором - от слова “судно”. Вторая причина в том, что при поиске словосочетаний, в зависимости от позиции слова в его синтаксической структуре, допустимыми являются не все грамматические формы: например, при обработке запроса “президент России” слово “президент” действительно стоит искать во всех вариантах, а вот слово “Россия” следует искать только в форме родительного падежа, иначе можно “случайно” найти фрагменты текста типа “К встрече американского президента Россия была ...”. Подобных примеров много, и, помимо снижения точности поиска, расширение запроса излишними словоформами приводит к неоправданному усложнению поискового запроса, снижению скорости ответа поисковой системы и даже к отказу от выполнения чересчур длинного запроса. Например, при построении всех искомых фраз по запросу типа “прилагательное + прилагательное + существительное” при “лобовом” подходе может понадобиться построить до 30*30*10 = 900 словосочетаний, тогда как при учете согласования форм прилагательного с существительным по роду, числу и падежу достаточно построить не более 10-ти словосочетаний – по числу возможных форм существительного.