Агрегирование значимых текстовых фрагментов

Агрегация `significant_text` намеренно не поддерживает добавление дочерних агрегаций, потому что:

Объем кандидатных терминов, как правило, очень высок, и они сильно сокращаются, прежде чем будут возвращены окончательные результаты. Поддержка дочерних агрегаций приведет к дополнительным издержкам и будет неэффективной. Клиенты всегда могут взять сильно сокращенный набор результатов из запроса significant_text и выполнить последующий запрос, используя агрегацию terms с клаузой include и дочерними агрегациями для дальнейшего анализа выбранных ключевых слов более эффективным способом.

В настоящее время агрегация `significant_text` также не может использоваться с текстовыми полями во вложенных объектах, потому что она работает с исходным JSON-документом. Это делает эту функцию неэффективной при сопоставлении вложенных документов из хранимого JSON, учитывая соответствующий идентификатор документа Lucene.

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

Как и большинство проектных решений, это компромисс, в котором мы выбрали быструю производительность в ущерб некоторым (как правило, небольшим) неточностям. Тем не менее, параметры size и shard size, о которых говорится в следующем разделе, предоставляют инструменты для управления уровнями точности.

Эта агрегация поддерживает те же эвристики оценки (JLH, mutual_information, gnd, chi_square и т.д.), что и агрегация значимых терминов.

Параметр size может быть установлен для определения количества корзин терминов, которые должны быть возвращены из общего списка терминов. По умолчанию узел, координирующий процесс поиска, запросит каждый фрагмент предоставить свои собственные верхние корзины терминов, и после получения всех ответов фрагментов он сократит результаты до конечного списка, который затем будет возвращён клиенту. Если количество уникальных терминов больше, чем size, возвращённый список может быть немного неточным и некорректным (счётчики терминов могут быть немного неточными, а термин, который должен был быть в верхней части корзин размера, может быть не возвращён).

Для обеспечения лучшей точности используется кратное конечной size в качестве количества терминов, запрашиваемых у каждого фрагмента (2 * (size * 1.5 + 10)). Для ручного управления этим параметром можно использовать параметр shard_size для контроля объёма кандидатных терминов, производимых каждым фрагментом.

Низкочастотные термины могут оказаться самыми интересными после объединения всех результатов, поэтому агрегация significant_terms может давать результаты более высокого качества, когда параметр shard_size устанавливается в значениях, значительно превышающих значение size. Это гарантирует, что больший объём перспективных кандидатных терминов будет просмотрен консолидированно узлом сокращения перед окончательным выбором. Очевидно, что большие списки кандидатных терминов приведут к дополнительному сетевому трафику и использованию оперативной памяти, поэтому необходимо найти баланс между качеством и затратами. Если shard_size установлен в -1 (по умолчанию), то shard_size будет автоматически оценён на основе количества фрагментов и параметра size.

Можно возвращать только термины, которые соответствуют большему количеству совпадений, чем заданное число, используя параметр min_doc_count. Значение по умолчанию равно 3.

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

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

GET news/_search
{
  "query": {
    "match": {
      "content": "madrid"
    }
  },
  "aggs": {
    "tags": {
      "significant_text": {
        "field": "content",
        "background_filter": {
          "term": { "content": "spain" }
        }
      }
    }
  }
}

Вышеуказанный фильтр поможет сфокусироваться на терминах, характерных для города Мадрид, а не на раскрытии терминов, таких как «испанский», которые нетипичны для всего мирового контекста полного индекса, но распространены в подмножестве документов, содержащих слово «Испания».

Обычно имя индексированного поля и имя исходного поля JSON, которое извлекается, совпадают. Однако с более сложными соответствиями полей, использующими функции, такие как copy_to, исходное поле(я) JSON и индексированное поле, по которому выполняется агрегация, могут отличаться. В этих случаях можно перечислить поля _source JSON, текст которых будет анализироваться, с помощью параметра source_fields:

GET news/_search
{
  "query": {
    "match": {
      "custom_all": "elasticsearch"
    }
  },
  "aggs": {
    "tags": {
      "significant_text": {
        "field": "custom_all",
        "source_fields": [ "content", "title" ]
      }
    }
  }
}

Можно (хотя и редко необходимо) отфильтровать значения, для которых будут созданы корзины. Это можно сделать с помощью параметров include и exclude, которые основаны на строке регулярного выражения или массивах точных терминов. Эта функциональность повторяет функции, описанные в документации по агрегации терминов.