В одном администратор популярного узла Web может быть уверен - объем информационного наполнения будет расти. Узел roga&kopyta.com призван стать источником и сокровищницей коллективного гения компании, так что неудивительно, если служащие начнут помещать туда все, что, по их мнению, представляет интерес.

К сожалению, успех порождает свои проблемы: актуальная информация рискует оказаться погребенной под массой ненужных сведений. Иными словами, посетители обращаются на ваш узел в поисках информации о концентраторах и оказываются на http://www.ford.com/, где они обнаруживают длинный список запчастей для спортивных автомобилей.

Итак, когда на узле Web скапливается слишком много информации, то организация встроенного механизма поиска становится просто необходимой. Тогда пользователи смогут выполнять поиск по ключевым словам, встречающимся в документах на данном сервере (или на нескольких серверах в некоторых предопределенных границах, например в пределах корпоративной сети Intranet). Размещение механизма поиска на самом узле упрощает процесс нахождения информации, а также снижает число избыточных ссылок, получаемых в ответ на запрос. Пользователям будут значительно меньше досаждать слова, значение которых зависит от контекста. Программист из IBM, ищущий для себя подходящую мышь, не получит в этом случае сведений о повадках австралийских грызунов.

Владельцы многих крупных узлов уже поняли выгоду встроенных механизмов поиска, и на их узлах, как, например, у той же IBM, на каждой странице присутствует кнопка для обращения к механизму поиска. Каждый, кто пользуется Web, уже знает, что с этой кнопкой делать. Однако, даже если ожидаемый результат очевиден, нужную ссылку еще предстоит поискать - инструменты индексации пока не столь известны, как сами механизмы поиска.

Серверы многих компаний до сих пор не имеют встроенных средств поиска. Только около трети из 95 исследованных нами узлов предлагали возможности поиска (во всяком случае, в остальных не было очевидных указаний на наличие таких средств на первых страницах). Конечно, многие из мощных, часто посещаемых узлов, таких как Pathfinder компании Time Warner или узел The New York Times, имеют поисковые механизмы, тем более удивительно, что у некоторых крупных узлов, например у узла NASA, до сих пор нет таких средств.

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

Функция поиска в Web имеет две стороны. С одной стороны, серверная составляющая представляет собой процесс, осуществляющий индексацию и формирующий ту или иную пригодную для поиска базу данных. Структура базы данных здесь значения не имеет и рассматриваться не будет; она может представлять собой просто дерево ключевых слов со ссылками на соответствующие файлы.

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

Существующие инструменты поиска решают эти задачи по-разному, но можно выделить два основных подхода к индексированию и два подхода к выдаче результатов. Что касается индексирования, старомодный подход состоит в чтении и создании индекса всех отобранных файлов с помощью специальной утилиты, а новомодный подход - в использовании программы-"паука". "Паук" ползает по иерархии горячих ссылок, начиная с домашней страницы узла Web, создавая по пути базу данных.

Преимущество первого привычного подхода состоит в простоте и возможности четко определить рамки поиска (если не включить файл в список подлежащих индексированию, он будет просто пропущен). "Паук" отслеживает каждую ссылку, поэтому все, что так или иначе было добавлено к узлу, окажется проиндексированным независимо от того, знает администратор о существовании этих объектов или нет. Правда, хорошие реализации "пауков" предусматривают правила автоматического исключения, позволяющие помечать определенные страницы и таким образом исключать их из обработки.

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

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

Если отвлечься от архитектурных и функциональных различий, поисковые механизмы подразделяются на три категории по одному, но весьма существенному признаку: бесплатные, поставляемые в пакете, и коммерческие, т. е. дорогие. Так же, как и большинство серверов Web, наиболее популярны бесплатные механизмы поиска.

Ближе всего к идеалу поискового механизма для Internet, безусловно, Swish (Simple Web Indexing System for Humans). Он написан на старом добром языке С разработчиком EIT Кевином Хеджесом. Этот типичный UNIX-пакет распространяется в виде исходного кода и компилируется пользователем на его машине. (Каждый желающий может проделать это сам, загрузив его с www.eit.com/software/swish/.) В итоге будет получен исполняемый модуль SWISH.EXE. Эта программа способна выполнить большую часть (хотя, определенно, не всю) работы, необходимую для индексирования и поиска.

Прежде всего, Swish предназначен для чтения файлов узла Web и создания индексного файла. Файл конфигурации позволяет определить, какие типы файлов и какие каталоги следует обработать. Типичный подход предполагает простую обработку всех файлов с расширениями .HTM или .HTML в дереве каталогов узла Web. В любом случае Swish умеет правильно обрабатывать только HTML- и текстовые файлы, поэтому добавлять другие типы файлов к списку индексируемых, например Adobe Acrobat, бессмысленно.

Swish формирует единый индексный файл, объем которого не превышает пяти процентов общего объема всех проиндексированных файлов.

Чтобы каждый мог попробовать подать запрос, Swish имеет готовый индексный файл SAMPLE.SWISH. Например, задав команду

в результате вы получите следующее:

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

Для получения информации в надлежащем виде администраторы Swish могут воспользоваться программой-упаковщиком (wrapper). Эта программа принимает запросы с сервера Web, передает их в Swish и представляет полученный результат в презентабельном виде. В качестве упаковщика чаще всего используется бесплатная утилита под названием WWWWais; найти ее можно по адресу: www.eit.com/software/wwwwais/.

Система Swish пользуется большой популярностью, и все же это не единственный бесплатный поисковый механизм. Excite for Web Servers (EWS) представляет собой "урезанную" версию поискового механизма Excite. Индексация в нем осуществляется по тому же принципу, что и в оригинальном Excite. EWS можно найти по адресу: www.excite.com/navigate/.

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

Как и Swish, EWS для связи с сервером Web использует интерфейс CGI, но работа с ним намного проще благодаря использованию шлюза CGI и для таких задач как начальная конфигурация продукта. При помощи браузера пользователь заполняет несколько форм, после чего EWS "перемалывает" его файлы и создает базу данных понятий (эта программа обрабатывает примерно 300 Мбайт в час).

Сейчас предлагаются и некоторые другие продукты (пять из них перечислены в Таблице 1), из них EWS, безусловно, обеспечивает наиболее интеллектуальный поиск, а Swish наиболее широко распространен.

Таблица 1 - БЕСПЛАТНЫЕ МЕХАНИЗМЫ ПОИСКА
Создатель	Продукт	Поддерживаемые платформы	узел Web
CNIDR (Center for Networked Information Discovery and Retrieval)	Isite	UNIX, Linux	http://vinca.cnidr.org/software/Isite/Isite.html
Excite	EWS	UNIX, Windows NT	http://www.excite.com
Кевин Хьюз	Swish	UNIX	http://www.eit.com/software/swish/swish.html
Muscat Limited	Muscat FX	Windows NT, UNIX	http://www.muscat.com
Университет Сан-Диего	Ht://Dig	UNIX	http://htdig.sdsu.edu
Университет Аризоны	Glimpse	UNIX	http://glimpse.cs.arizona.edu
Бернский университет	HTGrep	UNIX	http://Iamwww.unibe.ch/

Другие средства поиска предлагаются в пакете с тремя самыми популярными коммерческими серверами - продуктами компаний Microsoft, Netscape и O'Reilly and Associates (см. Таблицу 2). И O'Reilly, и Netscape положили в основу своих продуктов распространяемые бесплатно индексы Web, Microsoft же построила собственную систему поиска. При этом Microsoft и O'Reilly предлагают довольно простые функции, в то время как Netscape претендует на большее. Если механизм поиска, поставляемый с Netscape Enterprise Server 3.0, весьма примитивен, то покупатели SuiteSpot Professional Edition получают вместе с дюжиной серверов еще и Compass Server 3.0 (пересмотренную версию Catalog Server 1.0). Compass Server представляет собой надстройку над поисковой утилитой Harvest (эта система предназначалась совсем для другого проекта, но тот был свернут). O'Reilly использовала в качестве поискового механизма перенесенную на NT и усовершенствованную версию Swish.

Таблица 2 - ПОСТАВЛЯЕМЫЕ В ПАКЕТЕ МЕХАНИЗМЫ ПОИСКА
Производитель	Продукт	Поддерживаемые платформы	узел Web
Microsoft	Index Server	Windows NT	www.microsoft.com
O'Reilly and Associates	WebFind	Windows NT Windows 95	www.ora.com
Netscape Communications	Compass Server	UNIX	www.netscape.com

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

Время от времени Microsoft делает попытки убедить общественность в техническом превосходстве ее продукта, ссылаясь на то, что Index Server использует для взаимодействия с сервером Web свой интерфейс Internet Server API (ISAPI) вместо традиционного CGI, поддерживаемого всеми серверами Web. Объясняется это тем, что порождение нового процесса, а именно так осуществляются вызовы CGI, отнимает времени больше, чем выполнение заданий в рамках одного процесса, как это реализовано в ISAPI.

Однако Боб Денни, один из первых разработчиков сервера WebSite компании O'Reilly, категорически не согласен с подобным мнением. Для порождения процесса CGI надо около 100 миллисекунд, а это ничтожно мало по сравнению с несколькими секундами - именно столько времени уходит подчас на просмотр большого индексного файла и создание страницы Web с результатами. Достаточно обратиться к десятку крупных узлов и просмотреть их URL, как станет ясно, что на всех этих узлах используется CGI (вызовы CGI имеют характерный формат). Если бы CGI действительно настолько замедлял работу, администраторы узлов давно отказались бы от него.

В случае всех трех механизмов поиска, запуск сервера и индексация не особенно сложны. В продукте O'Reilly, например, процедура первоначальной загрузки сервера WebSite приводит к установке административной утилиты WebView, работающей на платформах Windows 95 и NT (как и сам сервер). При нажатии клавиши мыши на панели управления WebView запускается утилита Index Wizard. Она позволяет создавать различные индексные файлы для конкретного среза узла Web. Эта функция просто необходима при работе с различными виртуальными доменами на одном сервере, чтобы результаты поиска по какому-либо узлу Web, принадлежащему некоему виртуальному домену, не содержали данные другого узла Web только потому, что он развернут на том же сервере. Для каждого индексного файла вы можете определить, какие каталоги и типы файлов следует рассматривать.

Узел Web можно оснастить средствами поиска посредством размещения специальной формы на каждой странице, где они могут потребоваться пользователю. Создать эту форму при помощи эксперта несложно. Эксперт предлагает задать набор основных параметров, а всю остальную работу берет на себя. Кроме того, помимо настройки страниц, с которых будет запускаться процедура поиска, вы можете сконфигурировать утилиту WebFind так, чтобы она подготавливала и присоединяла файлы HTML в качестве заголовка и хвоста для страниц с результатами.

Настройка важна по нескольким причинам. Во-первых, она позволяет включить средства поиска таким образом, чтобы они гармонировали с общим видом страницы Web, и, во-вторых, разместить кнопки навигации и поиска на страницах с результатами поиска. Слишком на многих узлах Web пользователю приходится прокручивать множество страниц с результатами только затем, чтобы убедиться, что им необходимо переформулировать запрос, но вернуться к странице поиска или даже к "началу" узла оказывается невозможно. Вопиющим примером такой неэффективной организации был (по крайней мере, во время написания этой статьи) поисковый узел Netscape.

Уникальным для рассматриваемых поисковых механизмов свойством обладает Compass Server компании Netscape: он рассылает пользователям результаты предопределенного поиска по электронной почте или при появлении новой ссылки Web.

Compass Server поставляется бесплатно только вместе с высокоуровневым серверным пакетом. Его можно приобрести отдельно, но это обойдется в 1000 долларов. Утилита WebFind компании O'Reilly, напротив, поставляется только с WebSite. Механизм Index Server, предлагаемый Microsoft, можно загрузить бесплатно. Но кто захочет платить за механизм поиска, если можно получить аналогичный бесплатно или в пакете?

По словам Анила Ревари, менеджера по продуктам компании Verity, специализирующейся в разработке технологии поиска старшего класса, ответ на вопрос, "а стоит ли овчинка выделки", зависит от того, насколько необходимы нетипичные функции механизма поиска. Так, бесплатные механизмы поиска не имеют целого ряда важных функций. Вот их примеры.

Суммирование. Эта функция позволяет подсчитать частоту употребления терминов в документе, а также выделить предложения, в которых эти термины встречаются.

Группировка понятий. Данная функция объединяет похожие типы документов в группы так, чтобы пользователь мог сразу просматривать взаимосвязанные документы, не прибегая к помощи запросов.

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

"Большинство пользователей механизмов поиска, - пояснил Ревари, - просто выбирают одно или несколько ключевых слов для поиска и не применяют сложных функций булевой логики. Это означает, что поисковый механизм сам должен быть достаточно интеллектуальным. Если при поиске можно использовать некоторую контекстно-зависимую информацию, то результат будет более точным".

Помимо механизма поиска Search97 компании Verity поисковые продукты старшего класса производят Fulcrum, Lycos, Infoseek и Muscat (см. Таблицу 3). Продукты Verity и Fulcrum характеризуются более широкими возможностями поиска. Кроме того, системы этих компаний отличаются от недорогих и бесплатных продуктов для индексации тем, что они способны обрабатывать не только текстовые файлы, но и файлы многих других форматов.

Таблица 3 - КОММЕРЧЕСКИЕ МЕХАНИЗМЫ ПОИСКА
Производитель	Продукт	Поддерживаемые платформы	Примерная цена	узел Web
Fulcrum	SearchServer	UNIX, Windows NT	6000 долларов плюс 295 долларов за пользователя	http://www.fulcrum.com
Infoseek	UltraSeek	UNIX, Linux	от 1000 до 5000 долларов	http://vinca.cnidr.org/software/Isite/Isite.html
Lycos/InMagic	Lycos and InMagic Intranet	Windows NT Spider	от 1000 до 7500 долларов	http://www.inmagic.com
Muscat Limited	Muscat	Windows NT, UNIX	от 6500 до 21 000 долларов	http://www.muscat.com
Verity	Search97	Windows NT, UNIX	минимум 500 долларов	http://www.verity.com
Comptek	Яndex.Site	Windows 95, Windows NT, UNIX	от 99 до 14 950 долларов	http://www.comptek.ru/arcadia/yansite.html

Так, например, система компании Fulcrum способна различать и независимо индексировать вложения в сообщения электронной почты в папке Microsoft Exchange. Продукт фирмы Lycos под названием Inmagic DB/Text Intranet Spider извлекает метаинформацию из файлов различных типов, т. е., скажем, поля автора, заголовка и описания из файлов Microsoft Office.

Анализируя коммерческие механизмы поиска, можно понять, какие сервисы будут на повестке дня, после того как средства поиска станут привычным делом. И Compass фирмы Netscape, и продукт компании Verity, названный IntelliServ, имеют функцию автоматического поиска в соответствии с профилем пользователя, с последующей рассылкой нового информационного наполнения конкретным получателям. Compass Server создает настраиваемый бюллетень новостей с информацией о новых ссылках на документы, содержание которых соответствует заданным фильтрам. IntelliServ способен уведомлять пользователей о появлении интересующей их информации средствами электронной почты, пейджинговой связи или экранных служб новостей.

Выбирая механизм поиска, который облегчил бы поиск нужных сведений, стоит задуматься, насколько он подходит узлу Web. Многое будет зависеть от уровня функциональности, которым механизм поиска должен, по вашему мнению, обладать, чтобы пользователи могли быстро найти необходимый файл. Если только у вас не перегруженный узел, где поиск является основным способом нахождения информации, производительность поискового механизма не имеет решающего значения. Для узлов, частота посещения которых не превышает нескольких раз в минуту (а сами запросы не отличаются чрезмерной сложностью), практически любое решение способно обеспечить адекватную производительность.

Единственный вопрос, касающийся производительности, с которым вы можете столкнуться, - сколько времени занимает переиндексация узла и каков будет размер индексного файла. Если объем информационного наполнения узла очень велик (например, достигает нескольких гигабайт), индексный файл может разрастись до таких размеров, что ему просто не хватит места на диске.

Кроме того, обработка такого файла может чрезмерно загрузить центральный процессор. Если в этом случае индексация проводится на сервере, выполняющем одновременно и другие задачи, все остальные процессы могут остановиться, пока процедура индексации не завершится.

Другая сложность возникает, когда индексируемые файлы хранятся вне структуры каталогов основного узла Web. Так, Swish можно, в принципе, заставить обрабатывать файлы на других серверах, хотя этот "род деятельности" ему не свойственен. Из встроенных механизмов только Compass Server компании Netscape рассчитан изначально на индексацию файлов из различных источников. Тем, кто планирует выполнять индексацию файлов всего предприятия, возможно, лучше приобрести специальный инструментарий.

Если все требования к поиску ограничиваются простым поиском по ключевым словам, стоит остановиться на поставляемом в пакете механизме. Вообще говоря, получить дополнительные функции, которые EWS предлагает бесплатно, весьма соблазнительно, но тогда единственным вашим источником поддержки будут конференции. Если же вы хотите, чтобы кнопка поиска открывала доступ к документам и в других форматах, то придется раскошелиться и подписать контракт с Verity или Fulcrum.

Роберта Ричардсона можно разыскать по ключевым словам "независимый автор и консультант" или через его узел Web: http://www.smallofficetech.com/

Не все поисковые механизмы способны эффективно работать с русским текстом. Если в случае английского языка, например, вы задаете в поисковой строке слово в именительном падеже единственного числа, то этого практически всегда (за редким исключением некоторых архаичных форм множественного числа вроде mouse-mice) достаточно для поиска всех возможных его вхождений в тексты. Морфология же русского языка такова, что все комбинации падежей и чисел (для существительных и прилагательных), а также наклонений, чисел и времен (для глаголов) могут включать в себя варианты, радикально отличающиеся друг от друга ("хочет-хотела" - "хотят-хочу"), и одним словом в строке запроса не обойтись. Если же поиск делается по словосочетанию, то количество вариантов шаблона запроса растет сообразно формулам комбинаторики. Точно такие же проблемы возникают при индексации русских текстов, поскольку различные формы одного и того же слова могут восприниматься механизмом индексации как независимые смысловые единицы.

Неудивительно, что для поиска по "русскому" Internet мы используем отечественные поисковые серверы, которых с течением времени становится все больше и больше. Однако далеко не все эти механизмы являются коммерческими разработками.

Т. е. сами поисковые серверы, разумеется, имеют в себе известный коммерческий посыл, но как отдельные продукты они пока не продаются. Первой ласточкой стало семейство продуктов Яndex московской компании Comptek. Используя единое ядро морфологического анализа, разработчики компании предоставили различные интерфейсы его использования. Продукт Яndex.Site обеспечивает индексацию и поиск на Web-сервере пользователя (лицензирование производится в зависимости от объема обрабатываемого текста); Яndex.CD предназначен для работы со статическим (однажды индексируемым) текстом; Яndex.Dict предоставляет "русскоязычный" интерфейс к другим поисковым механизмам; Яndex.Lib - библиотека, позволяющая интегрировать механизм поиска и индексации в различные системы. Интересной особенностью системы Яndex является наличие механизма гипотез, учитывающего способность русского языка абсорбировать иностранные слова и позволяющего подвергать не входящие в базовый словарь продукты "новояза" таким же морфологическим процедурам, что и традиционную лексику.

Александр Авдуевский