Войти
Объединенный поиск извлекает информацию из множества источников через поисковое приложение, построенное на основе поисковой системы (ов). Пользователь выполняет единичный запрос, который распространяется на поисковые системы, базы данных или другие поисковые системы, участвующие в федерации. Затем объединенный поиск объединяет результаты, полученные от поисковых систем, для представления пользователю. Объединенный поиск может использоваться для интеграции разрозненных информационных ресурсов в рамках одной крупной организации («предприятия») или для всей сети.
Объединенный поиск, в отличие от распределенного поиска, требует централизованной координации доступных для поиска ресурсов. Это включает в себя как координацию запросов, передаваемых отдельным поисковым системам, так и объединение результатов поиска, возвращаемых каждой из них.
Федеративный поиск возник, чтобы удовлетворить потребность в поиске нескольких разрозненных источников контента с помощью одного запроса. Это позволяет пользователю выполнять поиск в нескольких базах данных одновременно в режиме реального времени, упорядочивать результаты из различных баз данных в удобной форме и затем представлять результаты пользователю.
По сути, это подход к агрегированию или интеграции информации - он обеспечивает единый доступ ко многим информационным ресурсам и обычно возвращает данные в стандартной или частично гомогенизированной форме. Другие подходы включают создание корпоративного хранилища данных, озера данных или концентратора данных. Объединенный поиск запрашивает много раз разными способами (каждый источник запрашивается отдельно), тогда как другие подходы импортируют и преобразуют данные много раз, обычно в пакетных процессах за ночь. Федеративный поиск обеспечивает просмотр всех источников в реальном времени (при условии, что все они находятся в сети и доступны).
В промышленных поисковых системах, таких как LinkedIn, федеративный поиск используется для персонализации вертикальных предпочтений для неоднозначных запросов. Например, когда пользователь вводит запрос типа «машинное обучение» в LinkedIn, он или она может иметь в виду поиск людей с навыками машинного обучения, вакансий, требующих навыков машинного обучения, или контента по теме. В таких случаях федеративный поиск может использовать намерение пользователя (например, прием на работу, поиск работы или потребление контента) для персонализации вертикального порядка для каждого отдельного пользователя.
Как описано Peter Jacso (2004), федеративный поиск состоит из (1) преобразования запроса и его широковещательной рассылки группе разрозненных баз данных или другой сети. ресурсы с соответствующим синтаксисом, (2) объединение результатов, собранных из баз данных, (3) представление их в кратком и унифицированном формате с минимальным дублированием, и (4) предоставление средств, выполняемых либо автоматически, либо пользователем портала, для сортировки объединенного набора результатов.
Объединенные поисковые порталы, коммерческие или с открытым доступом, как правило, поиск в общедоступных библиографических базах данных, в общедоступных каталогах библиотек в Интернете (OPAC ), Поисковые системы в Интернете, такие как Google и / или с открытым доступом, государственные или корпоративные коллекции данных. Эти отдельные источники информации отправляют обратно в интерфейс портала список результатов поискового запроса. Пользователь может просмотреть этот список совпадений. Некоторые порталы просто извлекают с экрана фактические результаты базы данных и не позволяют пользователю напрямую войти в приложение источника информации. Более сложные будут выводить дубликаты из списка результатов, объединяя и удаляя дубликаты. На многих порталах доступны дополнительные функции, но основная идея та же: повысить точность и релевантность отдельных поисковых запросов, а также сократить время, необходимое для поиска ресурсов.
Этот процесс дает объединенному поиску некоторые ключевые преимущества по сравнению с существующими поисковыми системами на основе искателей. Федеративный поиск не должен накладывать никаких требований или обременений на владельцев отдельных источников информации, кроме обработки увеличившегося трафика. Федеративный поиск по своей сути так же актуален, как и отдельные источники информации, поскольку поиск осуществляется в реальном времени.
Объединение трех поисковых систем Одним из приложений объединенного поиска является метапоисковая машина. Однако подход метапоиска не устраняет недостатки компонентных поисковых систем, такие как неполные индексы. Документы, которые не индексируются поисковыми системами, создают так называемую глубокую сеть, или невидимую сеть. Google Scholar - один из примеров многих проектов, пытающихся решить эту проблему путем индексации электронных документов, игнорируемых поисковыми системами. И подход метапоиска, как и лежащая в его основе технология поисковых систем, работает только с источниками информации, хранящимися в электронной форме.
Одна из основных проблем метапоиска - обеспечить совместимость поискового запроса с компонентами поисковых систем, которые объединяются и объединяются. Когда словарь поиска или модель данных поисковой системы отличается от модели данных одной или нескольких внешних целевых систем, запрос должен быть переведен в каждую из внешних целевых систем. Это может быть выполнено с использованием простого преобразования элементов данных или может потребоваться семантический перевод. Например, если одна поисковая система позволяет цитировать точные строки или n-граммы, а другая - нет, запрос должен быть переведен для совместимости с каждой поисковой системой. Чтобы перевести точный строковый запрос в кавычки, его можно разбить на набор перекрывающихся [N-граммов | N-граммов], которые с наибольшей вероятностью дадут желаемые результаты поиска в каждой поисковой системе.
Еще одна проблема, с которой сталкивается при внедрении федеративных поисковых систем, - это масштабируемость. Трудно поддерживать производительность, скорость отклика федеративной поисковой системы, поскольку она объединяет все больше и больше источников информации. Одной из реализаций федеративного поиска, которая начала решать эту проблему, является WorldWideScience, размещенная в США. Управление научно-технической информации Министерства энергетики. WorldWideScience состоит из более чем 40 источников информации, некоторые из которых сами являются федеративными поисковыми порталами. Одним из таких порталов является Science.gov, который объединяет более 30 источников информации, представляющих большую часть результатов НИОКР федерального правительства США. Science.gov возвращает результаты с наивысшим рейтингом в WorldWideScience, который затем объединяет и ранжирует эти результаты с результатами поиска, полученными из других источников информации, составляющих WorldWideScience. Такой подход каскадного федеративного поиска позволяет выполнять поиск в большом количестве источников информации с помощью одного запроса.
Другое приложение Sesam, работающее как в Норвегии, так и в Швеции, было создано на основе платформы с открытым исходным кодом, специализированной для решений федеративного поиска. Sesat, аббревиатура от Sesam Search Application Toolkit, представляет собой платформу, которая предоставляет большую часть инфраструктуры и функций, необходимых для обработки параллельного и конвейерного поиска и элегантного отображения их в пользовательском интерфейсе, позволяя инженерам сосредоточиться на индексе / настройка конфигурации базы данных.
Чтобы персонализировать вертикальные заказы в федеративном поиске, поисковая система LinkedIn использует профиль пользователя и недавние действия, чтобы сделать вывод о его намерениях, таких как прием на работу, поиск работы и потребление контента, а затем использует намерение, а также многие другие сигналы, чтобы ранжировать вертикальный порядок, который лично актуален для отдельного искателя.
Когда объединенный поиск выполняется в защищенных источниках данных, учетные данные пользователей должны быть переданы каждой базовой поисковой системе, чтобы обеспечить соответствующую безопасность. Если у пользователя разные учетные данные для входа в разные системы, должны быть средства для сопоставления их идентификатора входа с доменом безопасности каждой поисковой системы.
Еще одна проблема - отображение навигаторов списка результатов в общую форму. Предположим, выполняется поиск на 3 сайтах недвижимости, на каждом из которых есть список названий городов с гиперссылками, по которым можно щелкнуть, чтобы увидеть совпадения только в каждом городе. В идеале эти аспекты должны быть объединены в один набор, но это создает дополнительные технические проблемы. Система также должна понимать ссылки «следующая страница», если она позволяет пользователю пролистывать объединенные результаты.
Некоторая проблема сопоставления с общей формой может быть решена, если объединенные ресурсы поддерживают связанные открытые данные через RDF. Онтологии (правила) могут быть добавлены для сопоставления результатов с общими формами с использованием этой технологии.
Еще одна проблема - сортировка и оценка результатов. Каждый веб-ресурс имеет собственное понятие оценки релевантности и может поддерживать некоторый порядок сортировки результатов. Релевантность сильно различается среди «федератов» в поиске, поэтому знать, как чередовать результаты, чтобы показать наиболее релевантные, сложно или невозможно.
Еще одна проблема - надежный запрос. Федеративному поиску, возможно, придется ограничиться минимальным набором возможностей запросов, общих для всех федераций. Например. Если Google поддерживает отрицание и цитируемые фразы, а science.gov - нет, то для федеративного поиска будет невозможно поддерживать отрицательные, цитируемые фразы.
Еще одна проблема - доступность и тайм-аут. По мере роста числа федератов (федеративных источников) вероятность появления одного или нескольких медленных или автономных федератов становится высокой. Федеративный поиск должен решить, когда рассматривать федерацию в автономном режиме или ждать медленного ответа. Время отклика будет определяться самым медленным из всех федератов.
Еще одна проблема - разработка и тестирование на предприятии (а не в общедоступном Интернете). Группы разработчиков, как правило, не должны использовать живые производственные системы, поскольку они выполняют обычную работу, а тем более интенсивное нагрузочное тестирование. Кроме того, некоторые ресурсы безопасны, и их не следует произвольно запрашивать и раскрывать в процессе разработки из соображений конфиденциальности и безопасности. Следовательно, среды разработки, тестирования и тестирования производительности должны включать установку и настройку многих подсистем, чтобы обеспечить безопасное и надежное тестирование.
Еще одна проблема внутри предприятия - HA / DR (высокая доступность и аварийное восстановление ). Чтобы вся федеративная система была HA / DR, каждая подсистема должна быть HA / DR.
Аналогично, моделирование производительности и планирование мощности для объединенной системы требует моделирования, планирования, а иногда и расширения всех объединений.
По указанным выше причинам в рамках предприятия может быть предпочтительнее использовать концентратор данных или озеро данных или гибридный подход. Центры данных и озера упрощают разработку и доступ, но могут возникать задержки во времени, прежде чем данные станут доступны (без специальной логики синхронизации). В сети более типична федерация.
