Любая поисковая машина или каталог регламентирует свою работу по сбору данных из Сети. Очевидно, что формирование поискового образа информационного объекта, или, другими словами, его "отражения" в "зеркале" поисковой системы, неизбежно связано с некоторыми искажениями. По сути, главным при этом становится вопрос о том алгоритме, на основе которого создается поисковый образ. Объектом-оригиналом при этом может стать как Web-страница, так и файл "закрытого" формата, который не доступен для проникновения сканирующих программ ИПС, например видео - или аудиозапись. Определенный шаблон обычно используется и при построении поискового образа для физического или юридического лица в момент его регистрации в поисковой службе. Отсечение, фильтрация информации от оригинала свойственны всем без исключения ИПС, в том числе и полнотекстовым системам глобального охвата и самого общего назначения.
Фильтрация может регламентироваться как на техническом, так и на лингвистическом уровне, однако задача у нее одна - при минимальных материальных затратах добиться реальной эффективности поиска.
В связи с этим на практике часто возникает вопрос - что становится причиной неудачного поиска: высокая ли вероятность отсутствия в Сети на данный момент времени информации, релевантной запросу, или то, что эта информация потенциально не доступна для рассматриваемой поисковой системы. "Подводным камнем" этот аспект становится, когда получен ненулевой отклик на поисковый запрос, а доля недополученных данных оказывается неконтролируемой. Некоторый свет на особенности работы глобальных ИПС проливает сравнительный анализ их возможностей, который был приведен в прошлой публикации. Однако, если детали алгоритма фильтрации не известны, наиболее чувствительные потери данных возникают именно при использовании специализированных поисковых служб.
Рассмотрим несколько примеров. Немало специализированных систем имеет собственный интерфейс для ввода поисковых запросов. Тем не менее можно считать веянием времени ситуацию, когда многие подобные сервисы интегрируются в шаблоны глобальных ИПС в виде фильтров. Такими возможностями всегда отличался HotBot; недавно соответствующие элементы были внедрены на AltaVista; есть они и на Еxcite. Постоянно расширяется набор фильтров поисковой системы Lycos (см. рис.1), на которой мы остановимся подробнее.
Представьте себя на месте пользователя, впервые посетившего такую известную глобальную поисковую систему, как Lycos, с целью найти в Сети сведения о некоем книжном издании. Введя соответствующие ключевые слова и выбрав фильтр Books, он получает отклик, который, при отсутствии дополнительной информации, нельзя расценить иначе, как получение данных о книгах, собранных по всему Интернету. Интересно было бы задать вопрос, а может ли в масштабе Сети автоматически вестись отбор подобных сведений? Если говорить только о пространстве WWW, то в большинстве случаев программы-пауки, сканирующие Сеть, используют для распознавания типа данных специальные элементы языка HTML, с помощью которых в Web-страницу внедряются определенные информационные блоки. Название элемента может нести смысловую нагрузку и отождествляться с типом информации. Так, если бы гипотетически существовал элемент HTML book, заключающий в себе сведения о книге и ее авторе, он мог бы размещаться на странице и в простейшем случае иметь следующий вид:
<book>Название книги и автор</book>
(сами элементы <book> в окне браузера не должны отображаться) При этом вся информация о книгах, публикуемая в WWW подобным образом, могла бы благополучно и без участия человека накапливаться в базе данных ИПС. Но элемента book в стандарте HTML пока не существует. Следовательно, приходится прибегать либо к "ручному" отбору, либо к автоматическому просмотру некоторых, заданных наперед каталогов отдельных узлов, возможно, имеющих отношение к продаже книжной продукции или к библиотекам.
В случае Lycos все гораздо проще. Поиск происходит всего-навсего по одному-единственному узлу компании (http://www.barnesandnoble.com), заинтересованной в реализации своего товара. К чести разработчика следует сказать, что после нескольких лет молчания по поводу фильтра "books" в недрах предлагаемой документации сегодня можно найти скромное упоминание об арендаторе фильтра. Ранее его владельца просто нельзя было идентифицировать, и только спустя некоторое время стало понятно, что система работает с довольно незначительной по объему и специфически пополняемой базой данных.
Не менее серьезно звучат опасения в случае, когда поиск связан с информацией, привязанной к определенному формату ее хранения, например к звуковым файлам. В течение нескольких месяцев поиск "звуков в Интернете" на Lycos оставался чем-то таинственным, напоминающим работу с небольшой, но со вкусом собранной коллекцией. Тестирование системы с помощью простых запросов показывало, что в основном в ней представлены форматы WAV и AU. Недавно стало известно, что теперь поддерживаются также и MP3, MID, RA, RAM и AIF. При этом объем накопленных записей, доступных через большинство фильтров, продолжает сохраняться в тайне.
Ясно, что, если интересующий вас формат не входит в поддерживаемый на данный момент системой перечень, вы получите нулевой отклик, причину которого следовало бы четко представлять с самого начала.
Происхождение сопроводительных записей к звуковым файлам на Lycos, которые отображаются в результатах поиска, по-прежнему не регламентировано разработчиком.
Аналогичные проблемы существуют и на других ИПС. Хотелось бы отметить типичный в этом отношении прием: использование шаблона глобальной ИПС как для поиска информации, относящейся ко всему Интернет-пространству, так и для поиска по некоторым избранным базам данных или коллекциям. К сожалению, реальное поле поиска оговаривается далеко не всегда, и часто его приходится выяснять самостоятельно во избежание неверных выводов в дальнейшем
Ситуация может осложниться тем, что на поисковом сервере вы не найдете исчерпывающего описания того, как работают операторы языка запросов.
C этим можно столкнуться даже на "зрелых", не первый год работающих ИПС. Рассмотрим на примере AltaVista, каким образом это может стать источником определенных проблем.
Несмотря на недавнее появление графического фильтра (рис.2), многие пользователи системы продолжают эксплуатировать прозрачный по своей природе оператор image, позволяющий находить в индексе графические файлы. На этот счет справка AltaVista исчерпывается тем, что рекомендует ввести в шаблон запрос, в котором вслед за указанным оператором должно следовать имя или часть имени искомого файла. Таким образом, для поиска файла с изображением акрополя следует задать запрос в виде image: acropolis.
Увеличит ли наши шансы на успех знание того, как реально отрабатывает оператор image? Если посмотреть на откликнувшиеся документы, а затем на их HTML-источник, то легко убедиться, что в каждом из них в месте вставки графического образа присутствует элемент <IMG>. Внутри него в качестве обязательного атрибута стоит URL, с которого, собственно, и извлекается сам файл:
<IMG SRC="http://citforum.ru/buildings/acropolis. gif">
Фактически же Web-страница дает отклик, если ключевое слово входит не только в имя файла, но и в название любого каталога и в доменное имя сервера, содержащихся в URL элемента <IMG>, то есть документ, включающий в себя приведенную выше строку, откликнулся бы и на запрос image: buildings. Следовательно, поиск по имени каталога, которое так же, как и имя файла, несет смысловую нагрузку, позволяет получить графические данные, которые нельзя извлечь в первом случае. Предположим, что Web-мастер неосторожно назвал искомый файл ACR1. GIF, но разумно положил его в каталог buildings. Тогда по запросу image: buildings могут откликнуться релевантные документы с изображением акрополя, вставленным в Web-страницу с помощью строки:
<IMG SRC="http://www.citforum.ru/buildings/acr1. gif">
В расширенном поиске AltaVista используются логические операторы и скобки. Однако на сервере ничего не говорится о том, допустимо ли применять их внутри специальных полей поиска, таких как поле image. Уже заведомо зарегистрированный в индексе графический файл, найденный ранее, можно использовать для проверки работоспособности отдельных поисковых запросов. Так, если предположить, что файл с URL из последнего примера существует, то тестовый запрос в виде image: (buildings AND acr1) должен дать корректный ненулевой отклик и таким образом подтвердить, что комбинирование операторов допустимо. На практике это действительно возможно.
Хотелось бы еще раз подчеркнуть, что речь здесь идет не о несовершенстве отдельных поисковых систем, а о конструктивном подходе к разрешению возникающих вопросов. При этом нередки и ситуации, предугадать которые крайне сложно.
Если, скажем, на той же AltaVista организовать поиск по ключевому слову "президент" (оно специально выбрано в качестве тестового как довольно распространенное), легко убедиться, что отклик зависит от двух факторов: какой язык выбран в меню шаблона (см. рис.2, справа вверху) - русский (Russian) или любой (any language), а также какая русская кодировка установлена в меню браузера. Результаты поиска приведены в табл.1. Анализ списка отклика показывает, что, во-первых, при вводе запроса только в одной кодировке неминуемо теряются данные. Во-вторых, становится ясно, как система идентифицирует тот или иной язык документа. Оказывается, если некоторая начальная часть документа написана на языке, отличном от русского, то этот документ уже не описывается ИПС как русскоязычный. Результат этой недокументированной особенности - максимальный отклик индекса при поиске по русскоязычному термину достигается при установке пункта меню "any language", а не "Russian".