Поиск информации в Интернете: подводные камни.Михаил Талантов, «КомпьютерПресс», №91999 | |||||||||||||||||||||
Этой публикацией мы продолжаем разговор о проблемах поиска в сети Интернет,
с которыми неизбежно приходится сталкиваться пользователям и рядовым, и
Увы, источником подобной информации обычно является не документ, доступный
с головной страницы поискового сервера, а разбросанные по Сети, книгам и компьютерным
журналам публикации отдельных авторов. К причинам такого положения дел, | |||||||||||||||||||||
Проблема № 1: наполнение базы данных. | |||||||||||||||||||||
Любая поисковая машина или каталог регламентирует свою работу по сбору данных
из Сети. Очевидно, что формирование поискового образа информационного объекта,
или, другими словами, его «отражения» в «зеркале» поисковой системы, неизбежно
связано с некоторыми искажениями. По сути, главным при этом становится вопрос
о том алгоритме, на основе которого создается поисковый образ. Фильтрация может регламентироваться как на техническом, так и на лингвистическом уровне, однако задача у нее одна при минимальных материальных затратах добиться реальной эффективности поиска. В связи с этим на практике часто возникает вопрос что становится причиной неудачного поиска: высокая ли вероятность отсутствия в Сети на данный момент времени информации, релевантной запросу, или то, что эта информация потенциально не доступна для рассматриваемой поисковой системы. «Подводным камнем» этот аспект становится, когда получен ненулевой отклик на поисковый запрос, а доля недополученных данных оказывается неконтролируемой. Некоторый свет на особенности работы глобальных ИПС проливает сравнительный анализ их возможностей, который был приведен в прошлой публикации. Однако, если детали алгоритма фильтрации не известны, наиболее чувствительные потери данных возникают именно при использовании специализированных поисковых служб. Рассмотрим несколько примеров. Немало специализированных систем имеет собственный интерфейс для ввода поисковых запросов. Тем не менее можно считать веянием времени ситуацию, когда многие подобные сервисы интегрируются в шаблоны глобальных ИПС в виде фильтров. Такими возможностями всегда отличался HotBot; недавно соответствующие элементы были внедрены на AltaVista; есть они и на Еxcite. Постоянно расширяется набор фильтров поисковой системы Lycos (см. рис. 1), на которой мы остановимся подробнее. рис. 1 Представьте себя на месте пользователя, впервые посетившего такую известную
глобальную поисковую систему, как Lycos, с целью найти в Сети сведения о некоем
книжном издании. Введя соответствующие ключевые слова и выбрав фильтр Books,
он получает отклик, который, при отсутствии дополнительной информации, нельзя
расценить иначе, как получение данных о книгах, собранных по всему Интернету.
Интересно было бы задать вопрос, а может ли в масштабе Сети автоматически вестись
отбор подобных сведений? Если говорить только о пространстве WWW, то в большинстве
случаев <book>Название книги и автор</book>
(сами элементы <book> в окне браузера не должны отображаться.) При этом вся информация о книгах, публикуемая в WWW подобным образом, могла бы благополучно и без участия человека накапливаться в базе данных ИПС. Но элемента book в стандарте HTML пока не существует. Следовательно, приходится прибегать либо к «ручному» отбору, либо к автоматическому просмотру некоторых, заданных наперед каталогов отдельных узлов, возможно, имеющих отношение к продаже книжной продукции или к библиотекам. В случае Lycos все гораздо проще. Поиск происходит Не менее серьезно звучат опасения в случае, когда поиск связан с информацией,
привязанной к определенному формату ее хранения, например к звуковым файлам.
В течение нескольких месяцев поиск «звуков в Интернете» на Lycos оставался Ясно, что, если интересующий вас формат не входит в поддерживаемый на данный момент системой перечень, вы получите нулевой отклик, причину которого следовало бы четко представлять с самого начала. Происхождение сопроводительных записей к звуковым файлам на Lycos, которые отображаются в результатах поиска, по-прежнему не регламентировано разработчиком. Аналогичные проблемы существуют и на других ИПС. Хотелось бы отметить типичный
в этом отношении прием: использование шаблона глобальной ИПС как для поиска
информации, относящейся ко всему | |||||||||||||||||||||
Проблема № 2: язык поисковых запросов . | |||||||||||||||||||||
Ситуация может осложниться тем, что на поисковом сервере вы не найдете исчерпывающего описания того, как работают операторы языка запросов. C этим можно столкнуться даже на «зрелых», не первый год работающих ИПС. Рассмотрим на примере AltaVista, каким образом это может стать источником определенных проблем. Несмотря на недавнее появление графического фильтра (рис. 2), многие пользователи системы продолжают эксплуатировать прозрачный по своей природе оператор image, позволяющий находить в индексе графические файлы. На этот счет справка AltaVista исчерпывается тем, что рекомендует ввести в шаблон запрос, в котором вслед за указанным оператором должно следовать имя или часть имени искомого файла. Таким образом, для поиска файла с изображением акрополя следует задать запрос в виде image: acropolis. рис. 2 Увеличит ли наши шансы на успех знание того, как реально отрабатывает оператор
image? Если посмотреть на откликнувшиеся документы, а затем на их <IMG SRC="http://citforum.ru/buildings/acropolis.gif">
Фактически же Web-страница дает отклик, если ключевое слово входит не только
в имя файла, но и в название любого каталога и в доменное имя сервера, содержащихся
в URL элемента <IMG>, то есть документ, включающий в себя приведенную
выше строку, откликнулся бы и на запрос image:buildings. Следовательно,
поиск по имени каталога, которое так же, как и имя файла, несет смысловую нагрузку,
позволяет получить графические данные, которые нельзя извлечь в первом случае.
Предположим, что <IMG SRC="http://www.citforum.ru/buildings/acr1.gif">
В расширенном поиске AltaVista используются логические операторы и скобки. Однако на сервере ничего не говорится о том, допустимо ли применять их внутри специальных полей поиска, таких как поле image. Уже заведомо зарегистрированный в индексе графический файл, найденный ранее, можно использовать для проверки работоспособности отдельных поисковых запросов. Так, если предположить, что файл с URL из последнего примера существует, то тестовый запрос в виде image:(buildings AND acr1) должен дать корректный ненулевой отклик и таким образом подтвердить, что комбинирование операторов допустимо. На практике это действительно возможно. Хотелось бы еще раз подчеркнуть, что речь здесь идет не о несовершенстве отдельных поисковых систем, а о конструктивном подходе к разрешению возникающих вопросов. При этом нередки и ситуации, предугадать которые крайне сложно. Если, скажем, на той же AltaVista организовать поиск по ключевому слову «президент»
(оно специально выбрано в качестве тестового как довольно распространенное),
легко убедиться, что отклик зависит от двух факторов: какой язык выбран в меню
шаблона (см. рис. 2, справа вверху) русский (Russian)
или любой (any language), а также какая русская кодировка установлена в меню
браузера. Результаты поиска приведены в табл. 1. Анализ
списка отклика показывает, что,
табл. 1
В шаблоне расширенного поиска популярной рис. 3 Как видно из рисунка, шаблон позволяет задать свое поле поиска для каждого термина, а затем связать термины с помощью логических операторов. Однако как только терминов становится больше двух возникает вопрос: в какой последовательности будут отрабатывать операторы и, соответственно, что будет представлять собой результат. Даже для такого простого запроса, как term1 AND term2 OR term3, разумно предположить двоякую интерпретацию, которую можно проиллюстрировать с помощью выделения в скобки логических единиц (в самом шаблоне скобки не применяются). И вариант (term1 AND term2) OR term3, и вариант term1 AND (term2 OR term3) кажутся приемлемыми, давая при этом совершенно разный отклик. Тестовый запрос и последующий анализ откликнувшихся документов показывают справедливость первого варианта, то есть то, что операторы выполняются по мере их появления в шаблоне и в документе будут присутствовать либо term1 и term2 одновременно, либо только term3. Как в таком шаблоне вводить запросы с участием фраз (а это возможно) автор предлагает выяснить читателям самостоятельно. В данном случае приходится констатировать очевидную небрежность разработчика по отношению к пользователям системы. Подавляющее большинство ИПС Интернета сегодня активно работает с так называемыми
стоп-словами ( При появлении стоп-слов в поисковом запросе, не содержащем специальных ухищрений,
ИПС может не учитывать их при поиске и ранжировании результатов, при этом иногда
информируя об этом пользователя, а иногда нет. В целом неучет Хотя стоп-слова и могут игнорироваться в простых запросах, в индексе полнотекстовой
ИПС они присутствуют наряду с остальными. Такой системой является, например,
AltaVista (индексируются все слова документа). HotBot, напротив индексирует
все, кроме Тем не менее и HotBot выполняет полнотекстовое индексирование отдельных значимых
полей документа, так что запросы со Перечень стоп-слов не стандартизован, так что он может быть оригинальным для каждого сервиса. Разработчики редко приводят сведения об этом аспекте работы ИПС, однако при необходимости поиск по ключевым словам stop, words плюс название интересующей вас поисковой машины позволяет обнаружить в Сети версии соответствующих перечней. Наиболее общие принципы выхода из проблемной ситуации следующие: по возможности
избегать употребления Если же без стоп-слов в запросе обойтись нельзя, то следует включить их во
фразу, что во многих системах означает заключение в кавычки. В отдельных случаях
полезно протестировать работу шаблонов простого и расширенного поиска ИПС, в
которых техника поддержки | |||||||||||||||||||||
Проблема № 3: отклик поисковой системы. | |||||||||||||||||||||
Самая захватывающая интрига Сети, которую порождают ИПС, связана с особенностями
работы алгоритма, ранжирующего результаты в списке отклика. Эти сведения обычно
не предаются широкой огласке, но они крайне необходимы Тем не менее и при решении поисковых задач во время работы со списком отклика
В предыдущем выпуске мы говорили о том, что простые тестовые запросы позволяют
с самого начала работы с ИПС понять, насколько широко в индексе представлена
искомая информация. Однако не всякая ИПС дает полное число документов, содержащихся
в отклике на запрос (например, Lycos, не дает). В Обычно в списке отклика появляется информация, которая включает в себя заголовок
страницы, адрес и аннотацию. Аннотация берется либо из специального Другая обескураживающая неприятность это возможное отсутствие в найденных
документах тех самых ключевых слов, по которым проводился поиск. Причиной подобного
явления, если не считать незарегистрированного обновления страницы без изменения
адреса, становится тот факт, что ключевые слова были заданы автором в специальном
поле элементе META. Оно доступно для сканирования роботом ИПС, но не отображается
на странице. В этом случае путем просмотра метаэлементов Еще одна проблема вообще не очевидна для единичного пользователя. Речь идет
о том, как поисковый сервер обрабатывает запросы в случае, когда их поступает
слишком много, то есть в режиме переполнения. Так, автору статьи не раз приходилось
сталкиваться с тем, что, например, на AltaVista при одинаковом и практически
одновременном тестовом запросе с | |||||||||||||||||||||
Проблема № 4: небрежность и мистификации. | |||||||||||||||||||||
Здесь нам хотелось бы остановиться на некоторых более чем реальных опасностях, которые подстерегают пользователя, доверившегося малоизвестному поисковому серверу. Написать об этом автора заставил такой случай. Человеку была срочно необходима информация о наличии прямых электропоездов между двумя городами СНГ. Воспользовавшись каталогом Rambler, он быстро сумел локализовать сервер, предлагающий необходимые сведения (рис. 4). http://pavel.physics.sunysb.edu:8080/
рис. 4 После введения станций отправления и назначения система ответила отрицательно (см. рис. 4, строка внизу). Такой категоричный ответ сервера заставил человека прекратить дальнейшие поиски и принять решение, о котором ему скоро пришлось пожалеть. Предъявить претензии к разработчику системы также оказалось невозможным. Дело в том, что чуть ниже под результатом поиска пользователем не была замечена одна важная деталь, а именно надпись «Расписание рекламное, возможны изменения, за которые не несут ответственности ни распространитель, ни МПС». При этом если бы фраза об отказе была сформулирована чуть мягче, пользователь, вероятно, смог бы продолжить поиск в Сети и достичь положительного результата. В некоторых случаях маркетинговая агрессивность разработчика начинает носить вызывающий характер. Вот уже не один месяц на серверах HotBot и AltaVista находится рекламное объявление крупнейшей книготорговой компании Amazon (http://www.amazon.com), а также ряда других. При этом на любой запрос в ИПС рядом с результатами поиска появляется баннер, намекающий на то, что как раз по тематике выполненного поиска и можно найти информацию на Amazon, даже если в запросе фигурировал мистический «господин Иванов» (см. рис. 5). рис. 5 Подстановка терминов из поискового шаблона в баннер производится путем их механического переноса и безо всякого контроля на предмет действительного наличия книг по данной тематике на сервере компании. К тому же найти «Иванова» на Amazon нельзя в принципе, поскольку вплоть до последнего времени русскоязычная литература там не продавалась. В данном случае плата за доверчивость это несколько минут напрасно потраченного времени. Таким образом, от привычного уважения к печатному слову в Сети лучше отказаться,
особенно если сервер генерирует реплики автоматически. | |||||||||||||||||||||
Заключение. | |||||||||||||||||||||
Практика показывает, что создать качественную поисковую систему, во всех отношениях прозрачную для пользователя, не всегда в интересах разработчика и по силам ему. В конечном итоге разрешить львиную долю проблем можно лишь совместными усилиями пользователей и создателей ИПС при активном обмене мнениями. На западе с этой целью уже издается журнал Searchers (http://www.infotoday.com/searcher), предназначенный для людей, занимающихся поиском профессионально. В табл. 2 представлен перечень серверов, публикующих информацию о проблемах поиска, а также их краткая характеристика. Некоторые серверы с материалами по поиску информации в Интернете
табл. 2
В заключение хотелось бы отметить, что основная цель этой статьи, которую ставил
перед собой автор, была далека от того, чтобы перечислить некоторый набор полезных
сведений об отдельных поисковых сервисах Сети. Цель заключалась совсем в другом
привлечь внимание читателя к более важному моменту: инструмент, с помощью которого
нам приходится решать реально значимые для себя задачи, требует осторожности,
изучения и «обкатки». В особенности если этот инструмент является всегда наполовину
чужим, каким остается для пользователя поисковая система Интернета. В противном
случае последствия его применения будут слабо предсказуемы.
|
Источник: akmac.narod.ru/st/st16.htm