Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Фасетная навигация используется для самостоятельной фильтрации результатов запроса в поисковом приложении, где ваше приложение предлагает элементы управления для фильтрации по группам документов (например, категориям или брендам), а Azure AI Search предоставляет структуры данных и фильтры для поддержки взаимодействия с пользователем.
В этой статье описаны шаги по восстановлению структуры фасетной навигации в службе Azure AI Search. Как только вы ознакомитесь с основными понятиями и клиентами, перейдите на раздел Примеры фасетов для изучения синтаксиса различных вариантов использования, включая основные фасеты и уникальные подсчеты.
Дополнительные возможности фасеток доступны через предварительные версии API.
- иерархические структуры аспектов
- Фильтрация аспектов
- агрегации фасетов
Примеры навигации по граням предоставляют синтаксис и использование для предварительных функций.
Фасетная навигация на странице поиска
Аспекты являются динамическими, так как они основаны на каждом конкретном результирующем наборе запросов. Ответ поиска содержит все корзины фасетов, используемые для навигации по документам в результатах поиска. Запрос выполняется сначала, а затем фасеты извлекаются из текущих результатов и собираются в фасетную структуру навигации.
В поиске Azure AI фасеты имеют только один уровень и не могут иметь иерархическую структуру, если вы не используете API предварительного просмотра. Если вы не знакомы с фасетными структурами навигации, в следующем примере показан один из них слева. Счетчики указывают количество совпадений для каждого аспекта. Один и тот же документ можно представить в нескольких аспектах.
Использование фасетов поможет вам найти то, что вы ищете, и гарантирует, что вы не получите нулевых результатов. Используя фасеты, разработчики могут определить наиболее полезные критерии поиска для навигации по индексу поиска.
Фасетная навигация в коде
Фасеты включаются на поддерживаемых полях в индексе, и затем задаются в запросе. В начале ответа возвращается структура фасетной навигации, после чего следуют результаты.
Следующий пример REST — это пустой запрос ("search": "*"
), который находится в пределах всего индекса (см. пример встроенных отелей). Параметр facets
задает поле "Категория".
POST https://{{service_name}}.search.windows.net/indexes/hotels/docs/search?api-version={{api_version}}
{
"search": "*",
"queryType": "simple",
"select": "",
"searchFields": "",
"filter": "",
"facets": [ "Category"],
"orderby": "",
"count": true
}
Ответ для примера начинается с фасетной структуры навигации. Структура состоит из значений "Категория" и количества отелей для каждой. За ним следует остальные результаты поиска, обрезанные здесь до одного документа для краткости. Этот пример хорошо работает по нескольким причинам. Количество аспектов для этого поля попадает под ограничение (по умолчанию — 10), поэтому все из них отображаются, и каждый отель в индексе 50 отелей представлен ровно в одной из этих категорий.
{
"@odata.context": "https://demo-search-svc.search.windows.net/indexes('hotels')/$metadata#docs(*)",
"@odata.count": 50,
"@search.facets": {
"Category": [
{
"count": 13,
"value": "Budget"
},
{
"count": 12,
"value": "Resort and Spa"
},
{
"count": 9,
"value": "Luxury"
},
{
"count": 7,
"value": "Boutique"
},
{
"count": 5,
"value": "Suite"
},
{
"count": 4,
"value": "Extended-Stay"
}
]
},
"value": [
{
"@search.score": 1.0,
"HotelId": "1",
"HotelName": "Stay-Kay City Hotel",
"Description": "The hotel is ideally located on the main commercial artery of the city in the heart of New York. A few minutes away is Time's Square and the historic centre of the city, as well as other places of interest that make New York one of America's most attractive and cosmopolitan cities.",
"Category": "Boutique",
"Tags": [
"pool",
"air conditioning",
"concierge"
],
"ParkingIncluded": false,
},
. . .
]
}
Включение аспектов в полях
Вы можете добавить аспекты в новые поля, содержащие обычный текст или числовое содержимое. Поддерживаемые типы данных включают строки, даты, логические поля и числовые поля (но не векторы).
Вы можете использовать портал Azure, REST API, пакеты SDK Azure или любой метод, поддерживающий создание или обновление схем индекса в службе "Поиск ИИ Azure". В качестве первого шага определите поля, используемые для фасетирования.
Выбор полей для атрибута
Аспекты можно вычислять по полям и коллекциям с одним значением. Поля, которые лучше всего работают в фасетной навигации, имеют следующие характеристики:
- Содержимое, доступное для чтения (не векторное).
- Низкая кардинальность (несколько различных значений, повторяющихся в документах вашего поискового корпуса).
- Короткие описательные значения (один или два слова), которые хорошо отображаются в дереве навигации.
Значения в поле, а не имя поля, создают аспекты в фасетной структуре навигации. Если аспект является строковым полем с именем Color, аспекты — синим, зеленым и любым другим значением для этого поля. Проверьте значения полей, чтобы убедиться, что нет опечаток, значений NULL или различий в регистре. Рекомендуется назначить нормализатор фильтруемому и фасетируемому полю, чтобы сгладить незначительные вариации текста. Например, "Канада", "КАНАДА" и "canada" будут приведены к одной категории.
Избегайте неподдерживаемых полей
Невозможно задать аспекты существующих полей, векторных полей или полей типа Edm.GeographyPoint
или Collection(Edm.GeographyPoint)
.
В сложных коллекциях полей "facetable" должно иметь значение NULL.
Начните с новых определений полей
Атрибуты, влияющие на индексирование поля, могут быть заданы только при создании полей. Это ограничение применяется к аспектам и фильтрам.
Если индекс уже существует, можно добавить новое определение поля, которое предоставляет аспекты. Существующие документы в индексе получают значение NULL для нового поля. Это значение NULL заменяется при следующем обновлении индекса.
На странице служб поиска на портале Azure перейдите на вкладку "Поля " индекса и выберите "Добавить поле".
Укажите имя, тип данных и атрибуты. Рекомендуется добавлять фильтруемые элементы, так как часто фильтры устанавливают на основе корзины аспектов в ответе. Рекомендуется сортировать, так как фильтры создают неупорядоченные результаты, и их может потребоваться отсортировать в приложении.
Можно также сделать поле доступным для поиска, если вы хотите поддерживать полнотекстовый поиск, и сделать его извлекаемым, если хотите включить это поле в ответ на поиск.
Сохраните определение поля.
Возврат аспектов в запросе
Помните, что аспекты динамически вычисляются из результатов ответа запроса. Вы получаете только аспекты для документов, найденных текущим запросом.
Используйте представление JSON в обозревателе поиска, чтобы задать параметры аспектов на портале Azure.
- Выберите индекс и откройте обозреватель поиска в представлении JSON.
- Укажите запрос в ФОРМАТЕ JSON. Его можно ввести, скопировать JSON из примера REST или использовать intellisense для поддержки синтаксиса. Ознакомьтесь с примером REST на следующей вкладке в качестве примера фасетных выражений.
- Выберите "Поиск" , чтобы вернуть аспектные результаты, сформулированные в ФОРМАТЕ JSON.
Вот снимок экрана примера запроса базовых аспектов на образцовом индексе гостиниц. Вы можете вставить другие примеры в этой статье, чтобы вернуть результаты в обозревателе поиска.
Рекомендации по работе с аспектами
Этот раздел представляет собой набор советов и обходных решений, которые полезны для разработки приложений.
Мы рекомендуем использовать C#: добавьте поиск в веб-приложения , например фасетную навигацию, содержащую код для слоя презентации. В этом примере также содержатся фильтры, предложения и автозавершение. Он использует JavaScript и React для слоя презентации.
Инициализация фасетной структуры навигации с неквалифицированной или пустой строкой поиска
Полезно инициализировать страницу поиска с открытым запросом ("search": "*"
), чтобы полностью заполнить фасетную структуру навигации. Как только вы передаете термины запроса в запросе, фасетная структура навигации ограничивается только совпадениями в результатах, а не всем индексом. Эта практика полезна для проверки поведения фасетов и фильтров во время тестирования. Если в запросе указаны критерии соответствия, ответ исключает документы, которые не соответствуют, что имеет потенциальный эффект нижестоящего исключения аспектов.
Очистить грани
При разработке пользовательского опыта не забудьте добавить механизм очистки фасетов. Распространенный подход к очистке аспектов — это выдача открытого запроса для сброса страницы.
Отключите фасетирование для экономии места и повышения производительности.
Для оптимизации производительности и хранения задайте "facetable": false
поля, которые никогда не должны использоваться в качестве аспекта. Примеры включают строковые поля для уникальных значений, таких как идентификатор или имя продукта, чтобы предотвратить их случайное (и неэффективное) использование в фасетной навигации. Эта рекомендация особенно важна для REST API, которое включает фильтры и фасеты в строковых полях по умолчанию.
Помните, что вы не можете использовать Edm.GeographyPoint
или Collection(Edm.GeographyPoint)
поля в фасетной навигации. Помните, что аспекты лучше всего работают на полях с низкой кратностью. Из-за разрешения гео координат в заданном наборе данных бывает редко, что любые два набора координат равны. Таким образом, аспекты не поддерживаются для гео координат. Вы должны использовать поле города или региона для фильтрации по расположению.
Проверка плохих данных
При подготовке данных для индексирования проверьте поля на значения null, ошибки или несоответствия регистра, а также на наличие единичных и множественных форм одного и того же слова. По умолчанию фильтры и аспекты не проходят лексический анализ или проверку орфографии, что означает, что все значения поля "facetable" являются потенциальными аспектами, даже если слова отличаются одним символом.
Нормализаторы могут устранять несоответствия данных, исправляя регистр и различия символов. В противном случае для проверки данных можно проверить поля в источнике или выполнить запросы, возвращающие значения из индекса.
Индекс не является лучшим местом для исправления значений NULL или недопустимых значений. Необходимо устранить проблемы с данными в источнике, если это база данных или постоянное хранилище или в шаге очистки данных, который выполняется перед индексированием.
Упорядочивание групп аспектов
Хотя вы можете сортировать в пределах контейнера, отсутствуют параметры для управления порядком фасетных корзин в общей структуре навигации. Если вам нужны фасетные сегменты в определенном порядке, нужно задать их в коде приложения.
Несоответствия в количестве фасетов
В определенных обстоятельствах вы можете обнаружить, что счетчики аспектов не являются полностью точными из-за архитектуры шардинга. Каждый индекс поиска распространяется по нескольким сегментам, и каждый сегмент сообщает верхние N аспекты по количеству документов, которые затем объединяются в один результат. Так как это просто верхние N-аспекты для каждого сегмента, можно пропустить или недосчитывать соответствующие документы в ответе аспектов.
Чтобы гарантировать точность, можно искусственно увеличить число:<число> до большого значения, чтобы обеспечить полное предоставление отчетов от каждого шарда. Вы можете указать "count": "0"
для неограниченного числа фасетов. Кроме того, можно задать значение count, которое больше или равно количеству уникальных значений фасетного поля. Например, если вы осуществляете фасетирование по полю "size", которое содержит пять уникальных значений, можно задать "count:5"
, чтобы убедиться, что все совпадения представлены в фасетном ответе.
Компромисс с этим обходным решением увеличивает задержку запросов, поэтому используйте его только при необходимости.
Асинхронное сохранение структуры фасетной навигации отфильтрованных результатов
В поиске ИИ Azure аспекты существуют только для текущих результатов. Однако это обычное требование к приложению для сохранения статического набора аспектов, чтобы пользователь могли перемещаться в обратном направлении, отбирая шаги для изучения альтернативных путей с помощью контента поиска.
Если требуется статический набор аспектов вместе с динамическим процессом детализации, его можно реализовать с помощью двух отфильтрованных запросов: одного области результатов, другого, используемого для создания статического списка аспектов для целей навигации.
Смещение больших аспектов с помощью фильтров
Результаты поиска и результаты фасетов, которые слишком большие, можно уменьшить добавлением фильтров. В следующем примере в запросе к облачным вычислениям 254 элементы имеют внутреннюю спецификацию в качестве типа контента. Если результаты слишком большие, добавление фильтров может помочь пользователям уточнить запрос, добавив дополнительные критерии.
Элементы не являются взаимоисключающими. Если элемент соответствует критериям обоих фильтров, он учитывается в каждом из них. Это дублирование возможно при фасетном поиске в полях Collection(Edm.String)
, которые часто используются для обозначения документов тегами.
Search term: "cloud computing"
Content type
Internal specification (254)
Video (10)