Релевантность поиска — что это такое, как ее оценить и повысить

Релевантность страницы поиска — это то, насколько результат поиска соответствует ожиданиям человека. Синоним релевантности — это адекватность выдаваемой поисковиками информации.

Например, если вы ищете в Интернете рецепт оливье или борща, то скорее всего хотите найти ингредиенты для него и пошаговую инструкцию, а не историю блюда. То есть для запроса «как приготовить оливье» будут релевантными страницы с рецептами, а не с рассказом о древних традициях приготовления.

От того, насколько полно статья раскрывает вопрос, зависит индекс релевантности. В поисковых сервисах наиболее релевантные ответы показываются выше, менее релевантные — ниже. Уровень релевантности и позиция веб-страницы становятся выше, если поисковики Google и Яндекс решат, что страница лучше других соответствует запросу. Уже запутались? Давайте по порядку.

Содержание статьи

Для чего нужна релевантность?

Типы релевантности

Что влияет на релевантность сайта?

Внутренние факторы релевантности
Внешние факторы релевантности
Поведенческие факторы релевантности

Особенности релевантности у Яндекса и Google

Как оценить релевантность страницы?

Как повысить релевантность страницы?

1. Проработайте URL
2. Доработайте мета-теги
3. Используйте LSI-копирайтинг
4. Добавляйте картинки и видео
5. Структурируйте контент
6. Делайте контент актуальным

Заключение

Для чего нужна релевантность?

Главная задача релевантности — определить пользу каждой страницы сайта для пользователя и вывести на основании данных индекс.

Индекс релевантности — это своеобразный показатель того, насколько точно ответ на сайтах совпадает с вопросом, который искал пользователь. Этот индекс будет учитываться при ранжировании страниц сайта по поисковым запросам. Высокая релевантность сайта позволяет добиться верхних позиций в результатах поисковой выдачи.

Высокая релевантность — это еще и показатель качества. Если ваш сайт полно, адекватно и по существу отвечает на вопросы пользователей, значит, ваш контент качествен, приносит пользу и ценится у аудитории.

Допустим, вы ввели в Яндексе запрос «как сделать длинный скриншот на ноутбуке». Поисковик попытается в огромном количестве доступной ему информации найти ту страницу, которая лучше всего подойдет вашему запросу.

1. Сначала Яндекс выдает «быстрый ответ» — цитату из самой релевантной страницы с ключевыми словами вашего запроса. Эти ключи он выделяет жирным. Если ответ вы нашли в этих строках — бинго! Дальше искать не придется. Это наиболее релевантный ответ по мнению Яндекса.
2. Ниже поисковик выдаст подборку видеоинструкций по созданию таких скриншотов. Понятно, что по такому запросу проще посмотреть наглядный ответ, чем читать длинную статью-инструкцию.
3. Под видео Яндекс разместит страницы с информационными материалами — они также располагаются по степени релевантности. 

Типы релевантности

Есть три типа релевантности, которые зависят от поведения конкретных лиц или программ:

• Формальная — означает, что решение принимает робот. Он автоматически сравнивает страницы в поисковой выдаче со своими представлениями об идеальном ответе на запрос. Таким образом на основе полученных данных он создает «рейтинг релевантных страниц».
• Содержательная — за релевантность отвечает живой человек — асессор. Он заходит на сайт, проводит аудит и выносит вердикт, насколько та или иная страница подходит запросу.
• Пертинентная — здесь за удовлетворение запросов людей отвечают непосредственно пользователи. Алгоритм простой — если люди переходят по запросу на страницу, значит, она подходит.

Что влияет на релевантность сайта?

Есть прямая зависимость между контентом страницы, качеством его seo-оптимизации и ее позицией в поисковой выдаче.

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

Есть и другие факторы: их можно разделить на внешние и внутренние.

Внутренние факторы релевантности

Они влияют на релевантность страницы изнутри:

• подходящие мета-теги (название, дескрипшн) и ключевые слова;
• семантический (человекопонятный) URL;
• хорошая структура материала с заголовками, подзаголовками и списками;
• наличие атрибутов alt на изображениях;
• отсутствие ошибок, битых ссылок, долго загружающихся материалов.

Ключевые слова должны располагаться не слишком плотно — избыток ключей поисковики могут посчитать спамом, поэтому важно не перебарщивать и использовать только естественные вхождения ключей. Стоит располагать их в подзаголовках, alt-тегах и в мета-тегах. Главное — без фанатизма, который был присущ seo-оптимизации начала 2000-ых:

Пример переоптимизированного текста

Внешние факторы релевантности

Под внешним фактором часто понимают популярность материала на других ресурсах. Это то, как часто на конкретную страницу ссылаются в сети — чем чаще, тем лучше. Однако это не единственный критерий оценки популярности:

• Ссылки должны идти с авторитетных сайтов, схожих по тематике. Хорошо, если на вашу инструкцию «как сделать длинный скриншот на ноутбуке» идет ссылка с какого-нибудь тематического форума. Плохо, если такая ссылка ведет со страницы о детских товарах.
• Будет плюсом, если сайт, где ссылаются на вашу страницу, имеет хороший авторитет у поисковиков: лояльную базу пользователей и грамотную оптимизацию.

Поведенческие факторы релевантности

Бесполезные страницы с высоким seo-соответствием будут удерживать высокую релевантность поиска, но только до тех пор, пока не добавятся поведенческие факторы ранжирования:

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

Читайте также: 10 обязательных техник внешней SEO-оптимизации

Особенности релевантности у Яндекса и Google

Обе поисковые системы схожи в своих алгоритмах, хотя их алгоритмы до конца не изучены. Выдача результатов в Яндексе и Google различается из-за приоритетов систем.

Яндекс использует специальную формулу MatrixNet: в ней построением формулы занимается специальный алгоритм, информацию на вход дают асессоры. Всего Яндекс имеет порядка 500 критериев оценки релевантности страницы.

У Google меньше критериев оценки — примерно 150, а также формулы расчета отличаются лишь по странам (у Яндекса еще и по регионам).

В отличие от Google, Яндекс сначала ведет пользователей на сервисы своей экосистемы — Яндекс.Кью или Яндекс.Дзен.

Читайте также: Яндекс.Дзен: настройка новостной ленты, создание канала и варианты его монетизации

Как оценить релевантность страницы?

В интернете есть несколько специальных бесплатных сервисов, которые автоматически проверяют индекс релевантности в процентах по ссылке на материал:

• MEGAINDEX — раздел «Аудит»;
• Serpstat;
• PR-CY.

Как повысить релевантность страницы?

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

1. Проработайте URL

URL должен отображать суть содержимого страницы, поэтому лучше избегать автоматических адресов — их не понимают ни роботы, ни люди. Лучше всего делать URL в виде транслита заголовка с вхождением основного запроса или перевод на английский язык. 

2. Доработайте мета-теги

Из всех внутренних факторов ранжирования теги Title и Description — самые важные. Они участвуют в формировании сниппета, от них зависит показатель CTR в выдаче.
Наши рекомендации по мета-тегам, которые помогут улучшить их релевантность:

• включите в Title основное ключевое слово или фразу;
• дополнительные запросы и призыв к действию добавляйте в Description;
• для региональных сайтов топоним (название города) желательно располагать ближе к началу Title.

3. Используйте LSI-копирайтинг

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

• используйте синонимы и слова, схожие по смыслу;
• анализируйте поисковые подсказки при формировании семантического ядра;
• анализируйте правую колонку Яндекс Wordstat — рекомендации из блока «запросы, похожие на…».

4. Добавляйте картинки и видео

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

5. Структурируйте контент

Это оценят не только роботы, но и люди — по структурированному документу куда проще ориентироваться. Используйте теги h2-h4, списки, выделения, сноски и другие элементы форматирования.

Упоминать основное ключевое слово лучше в первых двух-трех абзацах страницы: это повысит вероятность попадания фрагмента в «быстрые ответы» в поиске.

6. Делайте контент актуальным

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

поисковые системы отслеживают изменение содержимого страницы;
это влияет на поведенческие факторы — людям нужен актуальный контент.

Читайте также: 3 ключевых компонента успешной контент-стратегии

Заключение

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

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

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

Высоких вам конверсий!

23-11-2021

Релевантность и оценка — Azure Cognitive Search

• Статья
• 11/29/2022
• Чтение занимает 5 мин

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

Релевантность применяется только к полнотекстовом поиску. Запросы фильтров, автозавершение и предлагаемые запросы, поиск с подстановочными знаками или нечеткие поисковые запросы не оцениваются и не ранжируются по релевантности.

В Когнитивный поиск Azure можно настроить релевантность поиска и повысить оценку поиска с помощью следующих механизмов:

• Настройка алгоритма оценки
• Семантический ранжирование (в предварительной версии, описано в этой статье)
• Профили оценки
• Пользовательская логика оценки, включенная с помощью параметра featuresMode

Примечание

Матчи оцениваются и ранжируются от высокого к низкому. Оценка возвращается как «@search.score». По умолчанию в ответе возвращаются первые 50 элементов, но можно использовать параметр $top, чтобы вернуть меньше или больше элементов (до 1000 в одном ответе) и параметр $skip, чтобы получить следующий набор результатов.

Оценка релевантности

Оценка релевантности означает вычисление оценки поиска, которая служит индикатором релевантности элемента в контексте текущего запроса. Чем выше оценка, тем более релевантен элемент.

Оценка поиска вычисляется на основе статистических свойств строковых входных данных и самого запроса. Когнитивный поиск Azure находит документы, соответствующие условиям поиска (некоторые или все в зависимости от searchMode), отдавая предпочтение документам, которые содержат несколько экземпляров условия поиска. Оценка поиска возрастает, если условие поиска редко встречается в индексе данных, но часто — внутри документа. Основу для такого подхода к вычислению релевантности называют TF-IDF или частотой условия — инверсная частота в документе.

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

Если вы хотите разорвать связь между повторяющимися оценками, вы можете добавить предложение $orderby, чтобы упорядочить элементы по оценке, а затем упорядочить по другому сортируемому полю (например, $orderby=search.score() desc,Rating desc). Дополнительные сведения см. в статье Синтаксис $orderby OData в Когнитивном поиске Azure.

Примечание

@search.score = 1 указывает на результирующий набор без оценивания или без ранжирования. Оценка одинакова для всех результатов. Неохваченные результаты возникают, когда форма запроса является нечетким поиском, запросами с подстановочными знаками или регулярными выражениями или пустым поиском (search=*иногда в сочетании с фильтрами, где фильтр является основным средством для возврата совпадения).

Алгоритмы оценки в поиске

Когнитивный поиск Azure предоставляет алгоритм ранжированияBM25Similarity. В более старых службах поиска вы можете использовать ClassicSimilarity.

Как BM25, так и классические — это функции извлечения, подобные TF-IDF, которые используют частоту терминов (TF) и обратную частоту документов (IDF) в качестве переменных для вычисления оценок релевантности для каждой пары «документ-запрос», которая затем используется для ранжирования результатов. Хотя концептуально похоже на классический, BM25 коренится в вероятностном получении информации, что дает более интуитивно понятные совпадения, как измеряется исследованиями пользователей.

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

Примечание

Если вы используете службу поиска, созданную до июля 2020 г., скорее всего, используется предыдущий алгоритм оценки по умолчанию, ClassicSimilarityкоторый можно обновить для каждого индекса. Дополнительные сведения см. в статье Включение оценки BM25 в старых службах .

В следующем видео-фрагменте приводится краткое объяснение алгоритмов ранжирования, которые используются в Когнитивном поиске Azure. Дополнительные сведения можно получить, просмотрев полное видео.

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

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

Если вы предпочитаете вычислять оценку на основе статистических свойств всех сегментов, вы можете сделать это, добавив scoringStatistics=global в качестве параметра запроса (или добавив «scoringStatistics»: «global» в качестве параметра текста запроса).

POST https://[service name].search.windows.net/indexes/hotels/docs/search?api-version=2020-06-30
{
    "search": "<query string>",
    "scoringStatistics": "global"
}

Использование scoringStatistics гарантирует, что все сегменты в одной реплике обеспечивают одинаковые результаты. Тем не менее, разные реплики могут немного отличаться друг от друга, так как они всегда обновляются с последними изменениями в индексе. В некоторых случаях вам может потребоваться, чтобы пользователи во время «сеанса запроса» получали более согласованные результаты. В таких случаях вы можете предоставить sessionId как часть запросов. sessionId является уникальной строкой, которую вы создаете для ссылки на уникальный сеанс пользователя.

POST https://[service name].search.windows.net/indexes/hotels/docs/search?api-version=2020-06-30
{
    "search": "<query string>",
    "sessionId": "<string>"
}

Пока используется та же самая строка sessionId, будет предпринята максимальная попытка нацеливания на одну и ту же реплику, что повысит согласованность результатов, которые увидят пользователи.

Примечание

Повторное использование одних и тех же значений sessionId может повлиять на балансировку нагрузки запросов по репликам, а также негативно повлиять на производительность службы поиска. Значение, используемое в качестве sessionId, не может начинаться с символа «_».

Профили оценки

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

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

Параметр featuresMode (предварительная версия)

В запросах поиска документов имеется новый параметр featuresMode, который может предоставить дополнительные сведения о релевантности на уровне полей. В то время как @searchScore вычисляется для всего документа (насколько этот документ является релевантным в контексте этого запроса), с помощью параметра featuresMode можно получать сведения об отдельных полях, как указано в структуре @search.features. В этой структуре содержатся все поля, используемые в запросе (определенные поля используются с помощью конструкции searchFields из запроса или все поля с атрибутом доступные для поиска в индексе). Для каждого поля можно получить следующие значения:

• Число уникальных токенов, найденных в поле
• Оценка подобия или мера того, насколько содержимое поля сходно с термином из запроса
• Частота термина или количество раз, когда термин из запроса был найден в поле

Для запроса, предназначенного для полей «description» (описание) и «title» (заголовок), ответ, который содержит @search.features, может выглядеть следующим образом:

"value": [
 {
    "@search. score": 5.1958685,
    "@search.features": {
        "description": {
            "uniqueTokenMatches": 1.0,
            "similarityScore": 0.29541412,
            "termFrequency" : 2
        },
        "title": {
            "uniqueTokenMatches": 3.0,
            "similarityScore": 1.75451557,
            "termFrequency" : 6
        }

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

См. также раздел

• Профили оценки
• Справочник по REST API
• Поиск документов (REST API Когнитивного поиска Azure)
• Библиотеки службы «Поиск Azure» для .NET

Упрощенный рейтинг релевантности. Как на самом деле работает поисковая система | by Luthfi Ramadhan

Упрощенный рейтинг релевантности. Как на самом деле работает поисковая система | Лутфи Рамадан | На пути к науке о данныхОткройте в приложении

Обработка естественного языка

Как на самом деле работает поисковая система

Фото Джошуа Голда на Unsplash

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

Модель векторного пространства

Модель векторного пространства — это модель, используемая для измерения сходства между набором документов и запросом. Запрос и документ представлены в виде векторов в n-мерном пространстве. Процесс преобразования запроса и документа в вектор называется векторизацией текста. Одним из наиболее часто используемых векторизаторов текста является векторизатор TF-IDF. Подробнее о TF-IDF здесь.

TF-IDF Simplified

Краткое введение в векторизатор TF-IDF

в направлении datascience. com

Чтобы получить наиболее релевантный документ, мы вычисляем сходство между запросом и каждым документом в коллекции. Основываясь на этих сходствах, мы можем оценить релевантность документа. Документ с наибольшим сходством с запросом должен быть извлечен и ранжирован вверху.

Косинусное сходство

Косинусное сходство — это метрика для измерения сходства между двумя векторами. Говоря математическим языком, он измеряет косинус угла между двумя векторами в многомерном пространстве.

Изображение автора

Таким образом, это мера направления, а не величины. Два вектора с одинаковым направлением имеют косинусное подобие 1, два вектора, направление которых отклоняется на 90° относительно друг друга, имеют косинусное подобие 0, так как косинус 90° равен 0, а два диаметрально противоположных друг другу вектора имеют подобие -1, потому что косинус 180° равен -1. Косинусное подобие особенно используется в положительном пространстве, где результат ограничен в диапазоне от 0 до 1. Косинусное подобие определяется как:

Изображение автора

И положительное пространство задается:

Изображение автора

В случае ранжирования релевантности текста косинусное сходство должно быть ограничено между 0 и 1, поскольку матрица TF-IDF не содержит отрицательных значений.

Пример

Дан текст документа следующим образом:

Изображение автора

И текст запроса следующим образом:

Изображение автора

Векторизация текста документа с помощью TF-IDF

Изображение автора

Векторизация текста запроса с помощью TF-IDF

Изображение автор

Вычислить косинусное сходство между запросом и текстом каждого документа

Изображение по автору

Отсортировать результат по возрастанию

Изображение по автору

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

Пререквизиты

TF-IDF Упрощенное

Краткое введение в TF-IDF Vectorizer

На пути сходство. Модель предполагает, что релевантность документа…

www.sciencedirect.com

Модель векторного пространства

Модель векторного пространства или терм-векторная модель — это алгебраическая модель для представления текстовых документов (и любых объектов, в…

en.wikipedia.org

Косинусное сходство

Косинусное сходство — это мера сходства между двумя ненулевыми векторами пространства внутреннего произведения. Он определяется как…

en.wikipedia.org

Косинусное сходство — Понимание математики и как она работает? (с python)

Косинусное сходство — это метрика, используемая для измерения того, насколько похожи документы независимо от их размера. Математически…

www.machinelearningplus.com

Понимание сходства косинусов и его применения

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

На пути к DATASCIence.com

TF-IDF Упрощенное

Краткое введение в TF-IDF Vectorizer

Название DATASTASCIENCE.com

, Ранки и поиск

Интересное путешествие в поисках

. ком

Наука о данных

Машинное обучение

Искусственный интеллект

Follow

Ваш дом для науки о данных. Публикация на Medium, в которой делятся концепциями, идеями и кодами.

О насПомощьУсловияКонфиденциальность

---

Получить приложение Medium

Лутфи Рамадан

502 Подписчики

Студент компьютерных наук в Университете Индонезии. Свяжитесь со мной по адресу https://www.linkedin.com/in/luthfi-ramadhan/ или https://www.instagram.com/luthfir9.8/

Статус

Авторы

Карьера

Конфиденциальность

Преобразование текста в речь

Поиск по табличным данным с помощью поиска Dataverse (Microsoft Dataverse) — Power Apps

• Статья
• 12. 01.2023
• 5 минут на чтение

Примечание

Не знаете, какая сущность или таблица? См. раздел Разработчики: понимание терминологии в Microsoft Dataverse.

Поиск Dataverse обеспечивает быстрые и исчерпывающие результаты поиска по множеству таблицы в одном списке, отсортированном по релевантности. Поиск по данным должен быть включен в вашей целевой среде администратором, прежде чем вы сможете использовать особенность. Дополнительные сведения: Использование поиска Dataverse для поиска записей

Чтобы начать использовать поиск Dataverse, ваше приложение просто отправляет запрос HTTP POST. запрос (в настоящее время только веб-API), чтобы начать поиск Dataverse. При поиске данные, укажите необязательные параметры запроса, чтобы установить критерии того, как среда данные нужно искать.

Существует три метода поиска Dataverse, которые можно использовать в Интернете Power Apps. Пользовательский интерфейс приложения:

• Поиск : Предоставляет страницу результатов поиска.

• Предложения : Предоставляет предложения по мере того, как пользователь вводит текст в поле формы.

• Автозаполнение : Обеспечивает автозаполнение ввода, когда пользователь вводит текст в поле формы.

В следующих разделах описано, как получить доступ к вышеупомянутому поиску. возможности из кода приложения.

Поиск

Минимальный синтаксис HTTP-запроса поиска Dataverse показан ниже.

 POST [URI организации]/api/search/v1.0/query
{
  "search": "<поисковый запрос>"
}
 

Значение параметра search содержит искомый термин и имеет Ограничение в 100 символов.

Ответ на успешный поиск возвращает HTTP-статус 200 и состоит из:

• значение: список таблиц. По умолчанию возвращается 50 результатов. Это также включает ключевые моменты поиска, которые указывают на совпадения с параметром поиска значение, содержащееся в crmhit тег ответа.

• totalrecordcount: общее количество результатов (типа long). Значение −1 возвращается, если для returntotalrecordcount установлено значение false (по умолчанию).

• граней: Результаты граней.

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

Параметры запроса

Для поиска Dataverse поддерживаются следующие параметры запроса.

entity=[list] (необязательно)

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

facets=[list] (необязательно)

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

 POST [URI организации]/api/search/v1.0/query
{
  "поиск": "мария",
  "facets": ["@search.entityname,count:100",
    "account.primarycontactid,количество:100",
    "ID владельца,количество:100",
    "modifiedon,values:2019-04-27T00:00:00|2020-03-27T00:00:00|2020-04-20T00:00:00|2020-04-27T00:00:00",
    "создано,значения:2019-04-27T00:00:00|2020-03-27T00:00:00|2020-04-20T00:00:00|2020-04-27T00:00:00"]
}
 

filter=[string] (необязательно)

Фильтры применяются при поиске данных и указываются в стандартном OData синтаксис.

 POST [URI организации]/api/search/v1.0/query
{
  "поиск": "мария",
  «фильтр»: «учетная запись: изменена на ge 2020-04-27T00:00:00,
    действия: в отношении кода типа объекта eq «учетная запись», аннотация: код типа объекта eq «учетная запись»,
    инцидент: (приоритетный код экв. 1 или приоритетный код экв. 2)"
}
 

returntotalrecordcount = true | false (необязательно)

Укажите true , чтобы вернуть общее количество записей; иначе ложь . По умолчанию ложь .

skip=[int] (необязательно)

Указывает количество результатов поиска, которые необходимо пропустить.

top=[int] (необязательно)

Указывает количество результатов поиска для извлечения. Значение по умолчанию — 50, максимальное значение — 100.

orderby=[list] (необязательно)

Список предложений, разделенных запятыми, где каждое предложение состоит из имени столбца, за которым следует ‘asc’ ( по возрастанию, что является значением по умолчанию) или ‘desc’ (по убыванию). Этот список указывает, как упорядочить результаты в порядке приоритета. По умолчанию результаты перечислены в порядке убывания оценки релевантности (@search.score). Для результатов с одинаковыми баллами порядок будет случайным.

Для набора результатов, который содержит несколько типов таблиц, список предложений для orderby должен быть глобально применимым (например, модифицировано, создано, @search. score). Обратите внимание, что указание параметра orderby переопределяет значение по умолчанию. Например, чтобы ранжировать результаты (в порядке старшинства) по релевантности, за которыми следуют самые последние измененные записи, перечисленные выше:

"orderby": ["@search.score desc", "modifiedon desc"]

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

режим поиска = любой | all (необязательно)

Указывает, должны ли совпадать какие-либо или все условия поиска для подсчета документ как совпадение. По умолчанию «любой».

Примечание

Параметр searchMode в запросе запроса определяет, будет ли термин с оператором NOT объединяться по И или по ИЛИ с другими терминами в запросе (при условии, что в других терминах нет оператора + или |). .

Использование searchMode=any увеличивает количество запросов, включая больше результатов, и по умолчанию будет интерпретироваться как «ИЛИ НЕ». Например, «wifi -luxury» будет соответствовать документам, которые либо содержат термин «wifi», либо не содержат термина «luxury».

Использование searchMode=all повышает точность запросов за счет включения меньшего количества результатов и по умолчанию будет интерпретироваться как «И НЕ». Например, «wifi -luxury» будет соответствовать документам, которые содержат термин «wifi» и не содержат термин «luxury».

тип поиска= простой | полный (необязательно)

Тип поиска определяет синтаксис поискового запроса. Использование «простого» выбора простой синтаксис запроса, а «полный» выбирает синтаксис запроса Lucene. По умолчанию ‘простой’.

Простой синтаксис запроса поддерживает следующие функции:

Функциональность	Описание
Логические операторы	оператор И; обозначается + оператор ИЛИ; обозначается | оператор НЕ; обозначается —
Операторы приоритета	Поисковый запрос «отель+(wifi | роскошь)» будет искать результаты, содержащие термин «отель» и либо «wifi», либо «роскошь» (или и то, и другое).
Подстановочные знаки	Подстановочные знаки в конце поддерживаются. Например, «Альп*» ищет «альпийский».
Точные совпадения	Запрос, заключенный в кавычки » «.

Синтаксис запроса Lucene поддерживает следующие функции:

Функциональность	Описание
Логические операторы	Предоставляет расширенный набор по сравнению с простым синтаксисом запроса. оператор И; обозначается оператором И, + ИЛИ; обозначается ИЛИ, || оператор НЕ; обозначается НЕ, !, –
Операторы приоритета	Те же функции, что и у простого синтаксиса запроса. 92 electronic» вернет результаты, в которых совпадения со словом «рок» более важны, чем совпадения со словом «электронный».
Поиск близости	Возвращает результаты, в которых термины находятся в пределах x слов друг от друга, для более контекстуальных результатов. Например, запрос «отель в аэропорту»~5 возвращает результаты, в которых слова «аэропорт» и «отель» находятся в пределах пяти слов друг от друга, что увеличивает шансы найти отель, расположенный рядом с аэропортом.
Поиск по регулярным выражениям	Например, /[mh]otel/ соответствует «мотель» или «гостиница».

Примечание

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

Чтобы использовать любой из операторов поиска как часть искомого текста, экранируйте символ, поставив перед ним одинарную обратную косую черту (\). К специальным символам, требующим экранирования, относятся следующие: + — & | ! ( ) { } [ ] ^ » ~ * ? : \ /

Пример: базовый поиск

Ниже приведен пример базового поискового запроса и ответа.

Запрос

 POST [URI организации]/api/search/v1.0/query
{
  "поиск": "мария",
  "facets": ["@search.entityname,count:100",
    "account.primarycontactid,количество:100",
    "ID владельца,количество:100",
    "modifiedon,values:2019-04-27T00:00:00|2020-03-27T00:00:00|2020-04-20T00:00:00|2020-04-27T00:00:00",
    "создано,значения:2019-04-27T00:00:00|2020-03-27T00:00:00|2020-04-20T00:00:00|2020-04-27T00:00:00"]
}
 

Ответ

 {
    "ценить": [
        {
            "@search.score": 0,4547767,
            "@search.highlights": {
                "адрес электронной почты1": [
                    "{crmhit}мария{/crmhit}@contoso.com"
                ],
                "имя": [
                    "{crmhit}Мария{/crmhit}"
                ],
                "полное имя": [
                    "{crmhit}Мария{/crmhit} Салливан"
                ]
            },
            "@search.entityname": "контакт",
            "@search.objectid": "16ffc791-d06d-4d8c-84ad-89a8978e14f3",
            "id владельца": "bb2500d1-5e6d-4953-8389-bfedf57e3857",
            "owneridname": "Кори Грей",
            "@search. ownerid.logicalname": "системный пользователь",
            "@search.objecttypecode": 2,
            "fullname": "Мария Салливан",
            "entityimage_url": **нуль**,
            "создано": "9.10.2020 17:27",
            "modifiedon": "9.10.2020 17:27",
            "адрес электронной почты1": "maria@contoso.com",
            "address1_city": **"Сиэтл"**,
            "адрес1_телефон1": **"206-400-0200"**,
            "parentcustomerid": **null**,
            "parentcustomeridname": **null**,
            "телефон1": **"206-400-0300"**
        }
    ],
    "грани": {
        "account.primarycontactid": [],
        "ИД владельца": [
            {
                "Тип": "Значение",
                "Значение": "31ca7d4b-701c-4ea9-8714-а89а5172106е",
                "OptionalValue": "Кори Грей",
                "Количество": 1
            }
        ],
        "@search.entityname": [
            {
                "Тип": "Значение",
                "Значение": "контакт",
                "Количество": 1
            }
        ],
        "модифицированный": [
            {
                «Тип»: «Диапазон»,
                «Кому»: «27. 04.2019 00:00»,
                "Количество": 0
            },
            {
                «Тип»: «Диапазон»,
                "От": "27.04.201912:00 УТРА",
                «Кому»: «27 марта 2020 г., 00:00»,
                "Количество": 0
            },
            {
                «Тип»: «Диапазон»,
                "От": "27.03.2020 00:00",
                «Кому»: «20.04.2020 00:00»,
                "Количество": 0
            },
            {
                «Тип»: «Диапазон»,
                "От": "20.04.2020 00:00",
                «Кому»: «27.04.2020 00:00»,
                "Количество": 0
            },
            {
                «Тип»: «Диапазон»,
                "От": "27.04.2020 00:00",
                "Количество": 1
            }
        ],
        "создано на": [
            {
                «Тип»: «Диапазон»,
                "Кому": "27.04.201912:00 УТРА",
                "Количество": 0
            },
            {
                «Тип»: «Диапазон»,
                "От": "27. 04.2019 00:00",
                «Кому»: «27 марта 2020 г., 00:00»,
                "Количество": 0
            },
            {
                «Тип»: «Диапазон»,
                "От": "27.03.2020 00:00",
                «Кому»: «20.04.2020 00:00»,
                "Количество": 0
            },
            {
                «Тип»: «Диапазон»,
                "От": "20.04.2020 00:00",
                «Кому»: «27.04.2020 00:00»,
                "Количество": 0
            },
            {
                «Тип»: «Диапазон»,
                "От": "27.04.2020 00:00",
                "Количество": 1
            }
        ]
    },
    "общее число записей": -1
}
 

Предложения

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

Минимальный синтаксис HTTP-запроса поиска предложений показан ниже.

 POST [URI организации]/api/search/v1.0/suggest
{
  "search": "<текстовый фрагмент>"
}
 

Значение параметра поиска предоставляет текстовую строку для поиска, чтобы соответствовать и имеет минимальную длину в три символа.

Ответ на успешный поиск возвращает статус HTTP 200 и содержит «значение», который представляет собой список, состоящий из текста или документа, где текст является предложение с выделением, а документ представляет собой словарь результата предложения. По умолчанию возвращаются пять результатов. Подсветка предложений указывает на совпадение со значением параметра поиска и содержится в crmhit тег в ответе.

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

Параметры запроса

usefuzzy=true | false (необязательно)

Используйте нечеткий поиск, чтобы помочь с орфографическими ошибками. По умолчанию false .

top=[int] (необязательно)

Количество предложений для извлечения. Значение по умолчанию — 5.

orderby=[List] (необязательно)

Список предложений, разделенных запятыми, где каждое предложение состоит из имени столбца, за которым следует «asc» (по возрастанию) или «desc» ( по убыванию). Этот список указывает, как упорядочить результаты в порядке приоритета. По умолчанию результаты перечислены в порядке убывания оценки релевантности (@search.score). Для результатов с одинаковыми баллами порядок будет случайным.

Для набора результатов, содержащих несколько типов таблиц, список предложений для orderby должен быть глобальным (например,modifiedon, createdon, @search.score). Обратите внимание, что указание параметра orderby переопределяет значение по умолчанию. Например, чтобы ранжировать результаты (в порядке старшинства) по релевантности, за которыми следуют самые последние измененные записи, перечисленные выше:

"orderby": ["@search.score desc", "modifiedon desc"]

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

entity=[list] (необязательно)

По умолчанию выполняется поиск по всем таблицам, настроенным для поиска Dataverse.

filter=[string] (необязательно)

Фильтры применяются при поиске данных и указываются в стандартном OData синтаксис.

Запрос

 POST [URI организации]/api/search/v1.0/suggest
{
  "поиск": "март",
  «фильтр»: «учетная запись: изменена на ge 2020-04-27T00:00:00,
    действия: в отношении кода типа объекта eq «учетная запись», аннотация: код типа объекта eq «учетная запись»
}
 

Пример: поиск предложений

Ниже приведен пример основного запроса на поиск предложений.

Запрос

 POST [URI организации]/api/search/v1.0/suggest
{
  "поиск": "март"
}
 

Ответ

 {
"ценить": [
{
"text": "{crmhit}Мар{/crmhit}я Салливан",
"документ": {
"@search.objectid": "52a33850-8f0a-eb11-a813-000d3a8ab142",
"@search.entityname": "контакт",
"@search.objecttypecode": 2,
"fullname": "Мария Салливан",
"entityimage_url": **null**,
"emailaddress1": "maria@contoso.com",
"address1_city": **null**,
"address1_telephone1": **null**,
"parentcustomerid": **null**,
"parentcustomeridname": **null**,
"телефон1": **нулевой**
}
}
]
}
 

Автозаполнение

Обеспечивает автозаполнение пользовательского ввода. Автозаполнение основано на таблице основной столбец записи.

Минимальный синтаксис HTTP-запроса поиска Dataverse следующий.

 POST [URI организации]/api/search/v1.0/autocomplete
{
  "search": "<текстовый фрагмент>"
}
 

Ответ на успешный поиск возвращает HTTP-статус 200 и состоит из «значение», которое является строкой.

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

Параметры запроса

usefuzzy=true | false (необязательный)

Нечеткий поиск для помощи с орфографическими ошибками. По умолчанию false .

entity=[list] (необязательно)

Областью действия по умолчанию является поиск по всем таблицам, настроенным для поиска Dataverse. и столбцы.

filter=[string] (необязательно)

Фильтры применяются при поиске данных и указываются в стандартном OData синтаксис.

Запрос

 POST [URI организации]/api/search/v1.0/autocomplete
{
  "поиск": "март",
  «фильтр»: «учетная запись: изменена на ge 2020-04-27T00:00:00,
    действия: в отношении кода типа объекта eq «учетная запись», аннотация: код типа объекта eq «учетная запись»
}
 

Пример: поиск автозаполнения

Ниже приведен пример базового запроса автозаполнения.