Открытые вопросы и ответы на вопросы стали эталоном для измерения способности системы читать, представлять и извлекать общие знания. Системы ответов на вопросы на основе поиска требуют подключения различных систем и сервисов, таких как текстовый поиск BM25, поиск по векторному сходству, обслуживание модели NLP, токенизаторы и промежуточное программное обеспечение, чтобы склеить все это вместе. Большинство из них являются основными функциями Vespa.ai. В этом посте мы воспроизводим современную основу для поисково-ответных систем в рамках единого масштабируемого готового к производству приложения на Vespa.ai.

Авторы Лестер Солбаккен и Джо Кристиан Бергум.

Вступление

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

В области машинного обучения тесты особенно важны для стимулирования инноваций и прогресса. Новый конкурс «Эффективные ответы на вопросы в открытом доступе» для NeurIPS 2020 направлен на продвижение передовых систем ответов на вопросы. Цель здесь - разработать систему, способную отвечать на вопросы без ограничения темы. Благодаря недавнему прогрессу в обработке естественного языка, эта область стала эталоном для измерения способности системы читать, представлять и извлекать общие знания.

Текущее состояние на основе поиска - это Система поиска плотных проходов, как описано в Поиске плотных проходов для ответов на вопросы в открытой области. Он состоит из набора скриптов, инструментов и моделей Python, разработанных в первую очередь для исследований. В такой системе много деталей. К ним относятся две модели на основе BERT для кодирования текста для встраивания векторов, другая модель на основе BERT для извлечения ответов, приблизительный поиск сходства ближайшего соседа и основанные на тексте методы BM25 для поиска кандидатов, токенизаторов и т. Д. Довести такую ​​систему до производства - нетривиально. Мы подумали, что было бы интересно объединить эти различные части и продемонстрировать, как с помощью Vespa.ai построить систему предоставления ответов на вопросы в открытом доступе, которая обеспечивает высочайшую точность.

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

Большинство компонентов системы ответов на вопросы являются основными функциями Vespa. Некоторое время назад мы улучшили поддержку текстового поиска Vespa для поиска и ранжирования на основе терминов. Недавно мы добавили эффективные аппроксимации ближайших соседей для семантического и плотного вызова векторов. Для гибридного поиска Vespa поддерживает множество типов машинно-обучаемых моделей, например нейронные сети и леса решений. Мы также улучшили нашу поддержку моделей TensorFlow и PyTorch для запуска более крупных моделей NLP и Transformer.

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

В этом сообщении в блоге мы коснемся

  • Быстрое определение ближайших соседей для семантического поиска плотных векторов.
  • Поиск на основе терминов (BM25) для поиска разреженных векторов.
  • Импорт нескольких предварительно обученных моделей на основе BERT в Vespa для кодирования встраиваемых векторов и получения ответов.
  • Собственная логика токенизации и прочего.

Для получения более подробной информации обратитесь к сопутствующему образцу приложения.

Цель этой публикации - воссоздать результаты теста Dense Passage Retrieval (DPR) для теста Natural Questions. Сначала мы рассмотрим общий обзор того, как работает поисковая система ответов на вопросы в контексте этой статьи. Затем мы покажем, как все это может быть реализовано на Vespa без каких-либо внешних сервисов или плагинов, и воссоздадим современные результаты, полученные в статье, которые измеряются путем точного совпадения ответов на набор вопросов. В заключение мы заглянем в будущее и расскажем о следующей публикации этой серии.

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

Тест Natural Questions состоит из вопросов и ответов на естественном языке. Как получить и представить знания, необходимые для ответа на вопросы, зависит от каждой системы. Есть два основных подхода к этому: поисковый и параметрический. Система, основанная на поиске, использует термины поиска или векторы семантического представления для вызова набора предложений или абзацев, впоследствии оцененных с помощью модели машинного обучения для извлечения точного ответа. Параметрическая система хранит ответы более или менее непосредственно в весах большой модели нейронной сети. Также было проведено исследование гибридных поисковых и параметрических систем, таких как Система извлечения-дополненной генерации, которая недавно улучшила современный эталон естественного вопроса в целом. Здесь мы сосредоточимся на системе, основанной на поиске, но рассмотрим параметрический и гибридный подходы в следующих статьях блога.

Система ответов на вопросы на основе поиска обычно хранит свои «знания» в системе поиска информации. Это могут быть предложения, абзацы или целые документы. Здесь мы будем использовать набор данных Википедии, где каждая страница разбита на отрывки по 100 слов каждый. Набор данных содержит 21 миллион таких отрывков. Отвечая на вопрос, мы сначала извлекаем отрывки, которые, скорее всего, включают ответ. Затем они анализируются с помощью модели машинного обучения, чтобы выделить интервалы, которые, скорее всего, приведут к правильному ответу. Эти этапы называются «ретривер» и «читатель» соответственно.

Ретривер

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

Поиск на основе терминов (разреженный)

Поиск на основе терминов - это классический метод поиска информации, охватывающий такие алгоритмы, как TF-IDF и BM25. Концептуально текст представлен вектором, где каждое измерение представляет термин в словаре. Ненулевое значение означает его наличие. Поскольку каждый текст содержит только подмножество возможных терминов в словаре, эти векторы большие и разреженные. Сходство между двумя текстами, например, документом и запросом, можно вычислить с помощью скалярного произведения между разреженными векторами с небольшими изменениями (например, важностью термина) для TF-IDF или BM25. Методы, основанные на терминах, полагаются на структуры инвертированных индексов для эффективного поиска. В некоторых случаях это можно еще больше ускорить с помощью таких алгоритмов, как WAND.

За исключением любой предварительной обработки, такой как лемматизация, выделение корней и, возможно, удаление стоп-слов, термины сопоставляются точно так, как они встречаются в тексте. Это может быть как сильная, так и слабая сторона. Для очень важных терминов, например имена и места, это значительно сокращает пространство поиска. Однако потенциально релевантные документы, не содержащие точного термина, не будут извлечены, если не использовать расширение запроса или связанные методы. В документе Dense Passage Retrieval (DPR) используется ElasticSearch в качестве системы обеспечения для BM25.

Поиск на основе встраивания (плотный)

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

В отличие от разреженного представления не существует точных методов эффективного поиска ближайших соседей. Таким образом, мы жертвуем точностью ради эффективности так называемого приблизительного ближайшего соседа (ИНС). Было предложено много различных методов поиска ИНС. Некоторые из них совместимы со структурами инвертированных индексов, поэтому их можно легко реализовать в существующих системах поиска информации. Примерами являются кластеризация k-средних, квантование продукта (и его родственников) и хеширование с учетом местоположения, при котором центроиды или сегменты могут быть проиндексированы. Метод, несовместимый с инвертированными индексами, - это HNSW (иерархический управляемый маленький мир). HNSW основан на структурах графов, очень эффективен и имеет привлекательное свойство, позволяющее постепенно строить граф во время выполнения. Это контрастирует с большинством других методов, требующих автономного пакетно-ориентированного построения индекса.

Поиск на основе семантических вложений очень хорошо дополняет поиск на основе терминов. Семантически похожие документы можно отозвать, даже если они не содержат одинаковых терминов. В отличие от подхода с использованием набора слов для поиска на основе терминов, порядок слов может обеспечить дополнительный контекст. Однако исторически сложилось так, что поиск на основе терминов превосходит семантические вложения в задачах с ответами на вопросы, но документ DPR показывает, что плотный поиск можно значительно улучшить, если кодирование специально обучено для этой задачи. В документе DPR для поиска сходства используется FAISS с индексом HNSW.

Читатель

В то время как работа компонента извлечения заключается в создании набора отрывков-кандидатов, которые, как мы надеемся, содержат ответ на вопрос, читатель извлекает фактический ответ отрывков. Для этого требуется некоторая форма модели понимания естественного языка, и используются модели BERT (или другие модели Transformer). Эти модели, как правило, огромны и дороги в оценке, поэтому через них проходит лишь небольшое количество отрывков-кандидатов.

Модели преобразователей принимают в качестве входных данных последовательности токенов. Токенизация текста может быть выполнена несколькими различными способами, чтобы сбалансировать размер словаря и длину последовательности. Благодаря механизму полного внимания моделей BERT время оценки увеличивается квадратично с увеличением длины последовательности. Таким образом, необходимо найти разумный баланс, и модели на основе BERT используют WordPiece или аналогичный алгоритм для разделения менее распространенных слов на подслова.

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

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

Собираем все это вместе

Описанная выше система ответов на вопросы на основе поиска, способная выполнять поиск как на основе терминов, так и на основе встраивания, требует, по крайней мере, следующих компонентов:

  • Информационно-поисковая система BM25, хранящая 21 миллион отрывков текста из Википедии.
  • Эффективная система поиска по сходству векторов, хранящая векторы вложения отрывков.
  • Система обслуживания моделей для трех различных моделей на основе BERT: кодировщика запросов, кодировщика документов и модели считывателя.
  • Токенизатор на основе BERT.
  • Промежуточное ПО, чтобы склеить все это вместе.

Токенизатор генерирует последовательность токенов для текста. Эти токены хранятся для использования в модели считывателя. Они также используются в модели кодировщика на основе BERT документа для создания вектора внедрения для плотного поиска. Для быстрого поиска текст и векторы внедрения необходимо проиндексировать.

Аналогичный процесс выполняется для каждого запроса. Токенизатор создает последовательность токенов, используемую для генерации вектора внедрения в кодировщике запроса на основе BERT. Первый этап, получение, выполняется с использованием поиска на основе терминов или на основе внедрения. Первые N проходов передаются модели Reader и ранжируются соответствующим образом. Наилучший отрывок анализируется для извлечения наилучшего отрезка, содержащего ответ.

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

Воспроизведение базовой линии Vespa

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

Схема

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

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

Мы настраиваем все это в единой схеме документа:

schema wiki {
  document wiki {
    field title type string {
      indexing: summary | index
    }
    field text type string {
      indexing: summary | index
    }
    field title_token_ids type tensor(d0[256]) {
      indexing: summary | attribute
    }
    field text_token_ids type tensor(d0[256]) {
      indexing: summary | attribute
    }
    field text_embedding type tensor(x[769]) {
      indexing: attribute | index  
      attribute {
        distance-metric: euclidean
      }
    }
  }
}

Здесь заголовок и текстовое содержание каждого отрывка представлены как строкой, так и полем последовательности лексем. Строковые поля проиндексированы для поддержки BM25 и поддержки WAND для ускоренного поиска. Последовательности токенов представлены в виде тензоров и используются в качестве входных данных для модели считывателя.

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

Поиск и ранжирование

Запрос в Vespa определяет, среди прочего, как Vespa должен отозвать документы (так называемая фаза сопоставления) и как Vespa должен оценивать документы (так называемая фаза ранжирования). Vespa предоставляет богатый API запросов, в котором запросы задаются на языке Vespa YQL. Поскольку разные стратегии поиска (на основе терминов и на основе внедрения) имеют разный синтаксис запросов, мы создали настраиваемый компонент поиска, который позволяет нам создавать унифицированный интерфейс поиска и передавать только фактический вопрос и стратегию поиска в качестве параметров. Это упрощает сравнение методов.

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

rank-profile sparse inherits openqa {
  first-phase {
    expression: bm25(text) + bm25(title)
  }
}
rank-profile dense inherits openqa {
  first-phase {
    expression: closeness(field, text_embedding)
  }
}
rank-profile hybrid inherits openqa {
  first-phase {
    expression: 1000*closeness(field, text_embedding) + bm25(text) + bm25(title)
  }
}

Здесь мы настроили три профиля ранжирования: один для разреженного поиска, один для плотного поиска и один для гибридного поиска. Профиль разреженного ранжирования использует оценку BM25 заголовка и текстовых полей по запросу в качестве функции оценки. Плотный профиль использует близость, например, евклидово расстояние между запросом и полем внедрения документа. Гибридный профиль - это пример, который объединяет оба варианта для гибридного поиска. Эта первая фаза представляет ретривера.

Для модели считывателя мы настроили базовый профиль openqa, который вводит вторую фазу, общую для стратегий поиска:

onnx-model reader {
  file: files/reader.onnx
  input  input_ids: input_ids
  input  attention_mask: attention_mask
  output output_0: start_logits
  output output_1: end_logits
  output output_2: relevance_logits  
}
rank-profile openqa {
  second-phase {
    rerank-count: 10
    expression: onnxModel(reader).relevance_logits
  }
  summary-features {
    onnxModel(reader).start_logits
    onnxModel(reader).end_logits
  }
}

Здесь 10 лучших документов повторно ранжируются моделью читателя, определяемой функцией ранга onnxModel. Фактическая модель, которую мы используем, представляет собой предварительно обученную модель, которую команда DPR опубликовала в репозитории моделей HuggingFace. HuggingFace выпустил отличный экспорт моделей трансформаторов, который упрощает экспорт моделей трансформаторов (из PyTorch или TensorFlow) в формат ONNX. После экспорта модели в ONNX мы можем поместить файл модели в пакет приложения и настроить его использование в схеме документа, как показано выше. Чтобы добиться такого масштабирования, Vespa распределяет эту модель по всем узлам содержимого в кластере. Таким образом, модель оценивается на узле содержимого во время ранжирования, что позволяет избежать передачи данных во внешнюю службу модели.

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

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

Промежуточное ПО для контейнеров Vespa - собираем все вместе

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

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

Результатом является служба, которая принимает текстовый вопрос и возвращает предсказанный ответ - и все это в одном приложении Vespa.

Полученные результаты

Тестом, который мы используем для этого приложения, является набор данных Natural Questions. Все эксперименты в этом разделе выполняются путем запроса экземпляра Vespa и проверки предсказанного ответа на ответ золотой ссылки.

Сводная информация о точности ретривера

Мы используем Recall @ position в качестве основного показателя оценки для ретривера. Очевидная цель ретривера - добиться максимально возможного отзыва в самом нижнем положении. Поскольку заключительные отрывки с верхней позицией повторно ранжируются с помощью считывателя на основе BERT, чем меньше отрывков нам нужно оценить, тем лучше будет сложность и производительность времени выполнения.

В следующей таблице приводится сводная информация о точности ретранслятора с использованием исходных 3610 вопросов разработчиков в задаче Естественные вопросы для ответов на вопросы открытой области (NQ-open.dev.jsonl).

В документе DPR указано, что используется значение @ 20 из 79,4, поэтому наши результаты совпадают с опубликованными результатами для метода плотного извлечения. Мы объясняем небольшую разницу в нашу пользу другим набором настроек для индекса HNSW.

Сводка по точности чтения

Мы оцениваем точность считывателя с помощью метрики «точное совпадение» (EM). Метрика «Точное совпадение» измеряет процент прогнозов, которые точно соответствуют любому из основных истинных ответов. Чтобы получить оценку 1 для запроса, прогноз ответа должен точно соответствовать золотому ответу, указанному в наборе данных. Это сложно. Например, вопрос «Когда была последняя высадка на Луну?» имеет золотые ответы «14 декабря 1972 года по всемирному координированному времени» или «декабрь 1972 года», а прогнозируемый ответ «14 декабря 1972 года» будет иметь 0 баллов.

Результаты относятся к тому же набору данных, указанному выше, с повторным ранжированием 10 лучших результатов от поисковика:

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

Дальнейшая работа

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

Будьте на связи!