Что такое семантический поиск информации в библиотеке

Что такое семантический поиск информации в библиотеке

Факультет: Компьютерных наук и технологий (ФКНТ)
Кафедра: Автоматизированных систем управления (АСУ)
Специальность: Информационные управляющие системы (ИУС)
Тема выпускной работы: Разработка онтологической модели для семантического поиска информации в электронной библиотеке
Научный руководитель: Мартыненко Татьяна Владимировна

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

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

Смысл традиционно является субъективной характеристикой текста. Трудно выявить какие-либо математические методы описания смысловой нагруженности текста и отдельных его понятий. Поэтому выделение смысловых характеристик из реального текста на естественном языке является сложной задачей. Тем не менее исследования в этом направлении активно ведутся. Над решением названных проблемам работают многочисленные коллективы ученых и специалистов во всем мире, в частности, консорциум W3C, где реализуется концепция Семантического Web. Создается множество интеллектуальных поисковых систем таких как RetrievalWare, Nigma, Exactus, Sirius и др.

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

Целью данной работы является повышение эффективности поиска неструктурированной текстовой информации по запросу пользователя на естественном языке.

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

Результаты работы будут использованы в электронной научной библиотеке кафедры АСУ.

Задача семантического поиска в электронной библиотеке является упрощенным аналогом поиска информации в Интернет, т. к. предполагается, что поиск будет осуществляться по запросу пользователя на естественном языке в аналогичной строке поиска.

На рис. 1 показана схема семантического поиска информации. Пользователь вводит запрос, который подвергается лингвистическому анализу, расширяется за счет использования синонимов, затем преобразовывается в ключевые слова и отправляется поисковой машине. Поисковая машина возвращает найденные документы, они также подвергаются лингвистическому разбору и формируются семантические образы документов. Образы документов сравниваются с образом запроса, делается вывод о релевантности каждого из документов и результаты анализа (документы, которые были признаны релевантными) предоставляются пользователю. Схема лингвистического анализа приведена на рисунке 1 [12].

Рис. 1 – Диаграмма потоков данных при поиске.

Рис. 2 – Процесс создания онтологии (анимация: объем 47Кб, размер 534×321, количество кадров 4, задержка между кадрами 50мс, задержка между первым и последним кадром 100мс, количество циклов повторния 7)

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

Наиболее известные инструменты инженерии онтологий, их основные характеристики представлены в таблице 1 [3].

Таблица 1 – Инструменты инженерии онтологий

Как уже говорилось выше, инструменты инженерии онтологий используют специализированные языки. Сегодня выделяют три основных класса языков описания онтологии, что показано на рис. 3:

Рис. 3 – Классификация форматов представления данных

На сегодняшний день редакторы онтологий, кроме своего языка, поддерживают импорт и экспорт данных различных форматов исходя из анализа их применения, следует, что наиболее часто используемым форматом представления данных является RDF(S). Язык RDF обладает рядом преимуществ: представляет данные в виде rdf-триплетов (сущность-объект-предикат), а rdf-схема представляется в виде ориентированного графа, что является удобной для восприятия формой представления данных [1].

Исходя из анализа основных параметров различных редакторов онтологий, наиболее приемлемым является редактор Protégé, именно он будет взят за основу в дальнейшей работе. Среди форматов представления данных, лидирующие позиции занял RDF(S), который будет использован для построения онтологии предметной области электронной библиотеки кафедры АСУ [1].

Семантическая обработка текста выполняется в три этапа: морфологический, синтаксический и собственно семантический анализ (рис. 4). Каждый этап выполняет отдельный анализатор со своими входными и выходными данными и собственными настройками.

Рисунок 4 – Схема лингвистического анализа

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

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

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

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

Рисунок 5 – Морфологический разбор текста.

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

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

При написании данного автореферата магистерская работа еще не завершена. Дата окончательного завершения работы: декабрь 2011 г. Полный текст работы и материалы по теме могут быть получены у автора или его научного руководителя после указанной даты.

Источник

Семантический поиск: мифы и реальность

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

Например, при вводе в строку поиска «Столица Франции», оба метода дают один и то же правильный ответ: «Париж». Кроме того, большинство запросов, которые мы вбиваем в строку поиска в виде аббревиатур, дают те же результаты, если вводить термин полностью. Очевидно, что тут что-то не так. Всем известно, что семантические технологии способны на многое, но почему? И как они работают? Ознакомившись с этой статьей, вы узнаете, что на самом деле, мы просто-напросто задаем не те вопросы.

Ошибка заключается в том, что семантические поисковые системы, по сути, обладают аналогичной с Google строкой ввода, которая позволяет нам вводить запросы в свободной форме. Поэтому мы вводим запросы так, как привыкли – в простейшей форме. Мы никогда не будем вводить в строку поиска «Какой актер снимался в фильмах «Криминальное чтиво» и «Лихорадка субботним вечером»? или «Какие два сенатора США брали взятки от иностранных компаний?». Мы всегда вбиваем простые фразы, но сила семантического поиска не в этом. Чтобы понять, как все работает, предлагаем рассмотреть несколько технологий семантического поиска от Google, SearchMonkey, Powerset и Freebase.

Какую проблему мы пытаемся решить?

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

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

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

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

Обзор семантических поисковых систем

Суть семантического поиска не только в вопросах, задаваемых нами. По причине того, что веб – это набор неструктурированных HTML-страниц, в основе семантического поиска лежит еще и базовая информация. Самой четкой и понятной из всех мы нашли Freebase – семантическая база данных. Freebase работает не только через текстовый поиск, а что наиболее важно, и через — MQL (Metaweb Query Language). MQL это почти тот же JSON (текстовый формат обмена данными), но с более широкими возможностями. С его помощью вы можете составить любой запрос в Freebase и ответом будет тот же запрос, но уже со вставленными результатами поиска.

Powerset, по сути, это тематическая база данных, которая работает с определенной структурированной информацией. С другой стороны есть Google, который в первую очередь ориентируется на статистическую частоту запросов и почти не принимает во внимание семантику. Вызывает интерес новая система SearchMonkey от Yahoo! Эта система ничего не добавляет к найденным результатам, но использует семантические аннотации для более полного, интерактивного и полезного пользовательского интерфейса.

Компании Hakia и Powerset явно работают с максимальной отдачей. Они пытаются создать подобные Freebase структуры, а потом по топовым результатам провести поиск на естественном языке. Отличие в том, что Hakia (как и другие) использует технологию для поиска по всей сети, а Powerset замкнул свой поиск на Wikipedia.

Что общего и где различия?

В связи с этим появляется вопрос: «Какие из этих технологий схожи, а какие кардинально отличаются?» Давайте начнем с простого. SearchMonkey ничем не отличается от Google и любой другой поисковой системы, т.к. суть у них одна, а разница присутствует лишь во внешнем виде. Сервис SearchMonkey хорош тем, что позволят издателям представить результаты поиска в наилучшем виде.

Что же касается Hakia, Powerset и Freebase, то тут ситуация иная. На первый взгляд они совершенно разные: Hakia в поиске использует весь веб, Powerset – лишь Wikipedia и Freebase, а Freebase обладает двумя поисковыми интерфейсами: поисковая строка и язык поиска. Но существует одна проблема: естественный язык не имеет ничего общего с репрезентативностью базовой информации.

Дело в том, что все технологии семантического поиска позволяют пользователям вбивать произвольные сложные вопросы, а затем интерпретируют их и применяют к имеющимся базам данных. Hakia, Powerset, Freebase такими базами являются, и все они обладают системой автоматической обработки естественного языка, которая «переводит» вопрос на стандартный запрос, понятный для базы.

Чтобы понять, как это все устроено, представьте Freebase и его язык поиска MQL. В отличие от естественного языка, который позволяет задать вопрос разными способами, MQL двусмысленности не предполагает. Этот JSON-подобный язык позволяет пользователям формулировать четкие запросы для поиска в базе Freebase. То, что Powerset позволяет строить вопросы на естественном языке, еще не значит, что Powerset не является базой данных. Powerset – это база, т.к. в ее основе лежит поисковая строка Freebase. Отличие Freebase от Powerset заключается в подходах к поиску и способам предоставления его результатов.

Назад в будущее: все дело в пользовательском интерфейсе

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

Слабым местом Powerset является интерфейс. Поисковая строка, с которой знакомы все, кто когда-либо что-то искал в сети, устарела. Слишком простой интерфейс Powerset и Hakia не приносит им пользы, но и не слишком отражается на Freebase, который не позиционирует себя, как поисковая система.

Вспомните недавний старт Powerset. Компания предоставила лучший способ для поиска в одном из самых мощных источников информации в сети — в Wikipedia. Но что говорят критики? Можно ли назвать эту систему главным конкурентом Google? Ответ однозначен — нет.

А что если на Powerset наложены некие ограничения по поиску? Что если вместо поисковой строки использовался другой интерфейс или компания сказала пользователям не искать то, что они легко могут найти в Google? Может, новые компании должны улучшить алгоритм поиска, который существует уже более 10 лет? В любом случае, любые идеи должны быть нацелены на то, чтобы решить задачи, которые не может на сегодняшний день решить Google.

Заключение

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

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

Источник

Семантический поиск: от простого сходства Жаккара к сложному SBERT

В материале, переводом которого мы решили поделиться к старту курса о машинном и глубоком обучении, простым языком рассказывается о семантическом поиске, статья охватывает шесть его методов; начиная с простых сходства по Жаккару, алгоритма шинглов и расстояния Левенштейна, автор переходит к поиску с разреженными векторами — TF-IDF и BM25 и заканчивает современными представлениями плотных векторов и Sentence-BERT. Простые примеры сопровождаются кодом и иллюстрациями, а в конце вы найдёте ссылки на соответствующие блокноты Jupyter.

Поиск сходства — одна из самых быстрорастущих областей в ИИ и машинном обучении. По своей сути, это процесс сопоставления релевантных частей информации друг с другом. Велика вероятность, что вы нашли эту статью через поисковую систему — скорее всего, Google. Возможно, вы искали что-то вроде «what is semantic similarity search?» или «traditional vs vector similarity search». Google обработал ваш запрос и использовал многие основные принципы поиска по сходству, о которых рассказывается в этой статье.

Два видео о двух классах подходов

Традиционный поиск

Мы начинаем с лагеря традиций и там находим нескольких ключевых игроков:

Сходство Жаккара.

Алгоритм шинглов.

Расстояние Левенштейна.

Все это показатели отлично работают при поиске сходства, из них мы рассмотрим три самых популярных: сходство по Жаккару, алгоритм шинглов и расстояние Левенштейна.

Сходство Жаккара

Сходство Жаккара — это простая, но иногда мощная метрика сходства. Даны две последовательности A и B: находим число общих элементов в них и делим найденное число на количество элементов обеих последовательностей.

Сходство Жаккара измеряет пересечение между двумя последовательностями по сравнению с объединением двух последовательностей

Пример: даны две последовательности целых чисел, запишем:

Здесь мы определили два общих неодинаковых целых числа, 3 и 4 — между двумя последовательностями с общим количеством десяти целых чисел в обеих, где восемь чисел являются уникальными значениями — 2/8 даёт нам оценку сходства по Жаккарду 0,25. Ту же операцию можно выполнить и для текстовых данных: всё, что мы делаем, — заменяем целые числа на токены.

Сходство по Жаккару, рассчитанное между двумя предложениями a и b

Мы обнаружили, что, как и ожидалось, предложения b и c набрали гораздо больше баллов. Конечно, это не лучшее решение — два предложения, в которых нет ничего общего, кроме слов ‘the’, ‘a’, ‘is’ и т. д., могут получить высокие оценки Жаккара, несмотря на то, что они неодинаковы по смыслу. Эти недостатки могут быть частично устранены с помощью методов предварительной обработки, таких как удаление стоп-слов, стемминг/лемматизация и т. д. Однако, как мы скоро увидим, некоторые методы позволяют полностью избежать этих проблем.

Алгоритм шинглов

Другая похожая техника — алгоритм использует точно такую же логику пересечения/объединения — но с «шинглом». 2-шингловое предложение a будет выглядеть так:

После можно применить тот же расчёт пересечения/объединения между разбитыми на шинглы предложениями:

При помощи двух шинглов находим три совпадающих шингла между предложениями b и c, в результате сходство составляет 0,125.

Расстояние Левенштейна

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

Формула расстояния Левенштейна

На вид она довольно сложна; если вы её поняли, это прекрасно! Если нет, не волнуйтесь — мы разберём её. Переменные a и b представляют две наши строки, i и j — позиции символов в a и b соответственно. Итак, даны строки:

«Levenshtein» и неправильно написанное «Livinshten»

Индексируем само слово, начиная с 1 до его длины, нулевой индекс означает «ничего» (подробнее об этом — далее).

Это легко! Прекрасный способ понять логику этой формулы — визуализировать алгоритм Вагнера — Фишера, рассчитывающий расстояние Левенштейна при помощи простой матрицы. Мы берём два слова a и b и размещаем их по обеим осям нашей матрицы, включая символ ничего как пустое пространство:

Пустая матрица Вагнера-Фишера — мы будем работать с ней для вычисления расстояния Левенштейна между ‘Levenshtein’ и ‘Livinshten’.

Код инициализации пустой матрицы Вагнера — Фишера:

Переберём все позиции в матрице и применим ту сложную формулу, которую видели ранее. Первый шаг в нашей формуле if min(i, j) = 0 — здесь мы уточняем, не равны ли i и j нулю? Если да, переходим к функции max(i, j), которая присваивает текущей позиции в нашей матрице больше из двух значений — i и j:

Начнём справа, вдоль рёбер, где i и/или j равно 0, значение в матрице будет заполнено max(i, j)

Код операций min(i, j) == 0, за которой следует визуализированная выше max(i, j).

С внешними краями нашей матрицы мы разобрались, но нам всё ещё нужно вычислить внутренние значения — именно там будет проходить оптимальный путь. Вернёмся к if min(i, j) = 0 — что, если ни одно из них не равно 0? Затем переходим к сложной части уравнения в разделе min <. Нам нужно вычислить значение для каждой строки, а после взять минимальное значение. Сейчас эти значения известны — они находятся в нашей матрице:

Для каждой новой позиции берём минимальное значение из трёх соседних позиций (обведено кружком вверху слева)

Эта операция в цикле по всей матрице выглядит так:

Полная реализация расчёта расстояния Левенштейна при помощи матрицы Вагнера — Фишера.

Векторное сходство

Для поиска на основе вектора мы обычно используем один из нескольких методов построения векторов:

В тандеме с некоторыми реализациями приблизительных ближайших соседей (ANN) эти векторные методы в мире поиска сходства, если говорить терминами программирования, — минимально жизнеспособные продукты. Рассмотрим подходы на основе TF-IDF, BM25 и BERT, поскольку они являются наиболее распространёнными и охватывают как разреженные, так и плотные векторные представления.

1. TF-IDF

Почтенный дедушка векторного поиска сходства, родившийся ещё в 1970-х годах. Он состоит из двух частей: Term Frequency (TF) и Inverse Document Frequency (IDF). Компонент TF подсчитывает, сколько раз термин встречается в документе, и делит его на общее количество терминов этого же документа.

Компонент частоты термина (TF) TF-IDF подсчитывает частоту нашего запроса («bananas») и делит её на частоту всех лексем

Это первая половина нашего расчёта, мы имеем частоту запроса в рамках текущего документа f(q, D) в числителе и частоту всех терминов в рамках текущего документа f(t, D) в знаменатели дроби. TF — хороший показатель, но не позволяет нам провести различие между распространёнными и необычными словами. Если бы мы искали слово «the», используя только TF, мы бы присвоили этому предложению ту же релевантность, что и при поиске «bananas». Это хорошо, пока мы не начнём сравнивать документы или искать что-то с помощью длинных запросов. Мы не хотим, чтобы такие слова, как ‘the’, ‘is’ или ‘it’, были оценены так же высоко, как ‘bananas’ или ‘street’.

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

Компонент обратной частоты документов (IDF) TF-IDF подсчитывает количество документов, содержащих наш запрос.

Здесь три предложения. Вычислив IDF для нашего распространённого слова ‘is’, получаем гораздо меньшее число, чем в случае более редкого слова ‘forest’. Если бы после мы искали оба слова ‘is’ и ‘forest’, то объединили бы TF и IDF следующим образом:

Мы вычисляем оценки TF(‘is’, D) и TF(‘forest’, D) для документов a, b и c. Значение IDF относится ко всем документам, поэтому IDF(‘is’) и IDF(‘forest’) вычисляются только один раз. Затем мы получаем значения TF-IDF для обоих слов в каждом документе путём умножения компонентов TF и IDF. Предложение a набирает наибольшее количество баллов для ‘forest’, а ‘is’ всегда набирает 0, поскольку IDF(‘is’) равно 0.

Это замечательно, но где здесь применяется векторное сходства? Итак, мы берём наш словарный запас (большой список всех слов в нашем наборе данных) и вычисляем TF-IDF для каждого слова.

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

Чтобы сформировать векторы TF-IDF, мы можем собрать это воедино:

Отсюда мы получаем вектор TF-IDF. Стоит отметить, что словарь легко может иметь более 20 000 слов, поэтому созданные этим методом векторы невероятно разрежены, а это означает, что закодировать какой-либо семантический смысл мы не можем.

2. BM25

Преемник TF-IDF, Okapi BM25, является результатом оптимизации TF-IDF в первую очередь для нормализации результатов на основе длины документа. TF-IDF — отличный инструмент, но он может давать сомнительные результаты, когда мы начинаем сравнивать несколько упоминаний. Если мы возьмём две статьи по 500 слов и обнаружим, что «Черчилль» в статье А упоминается 6 раз, а в статье Б — 12 раз, должны ли мы считать статью А в два раза менее релевантной? Скорее всего, нет. BM25 решает эту проблему путём модификации TF-IDF:

Формула BM25

Уравнение выглядит довольно неприятно, но это не что иное, как наша формула TF-IDF с несколькими новыми параметрами! Давайте сравним два компонента TF:

TF-часть BM25 (слева) по сравнению с TF-частью TF-IDF (справа)

И затем часть IDF, которая даже не вводит никаких новых параметров — она просто переставляет IDF из TF-IDF.

IDF часть BM25 (слева) в сравнении с IDF TF-IDF (справа)

Итак, каков результат этой модификации? Если взять последовательность из 12 лексем и постепенно подавать в неё всё больше и больше «подходящих» лексем, то получим следующие результаты:

Сравнение алгоритмов TF-IDF (вверху) и BM25 (внизу) с использованием предложения из 12 лексем и возрастающего числа релевантных лексем (ось x)

Показатель TF-IDF линейно увеличивается с ростом числа релевантных лексем. Таким образом, если частота удваивается — увеличивается и показатель TF-IDF. Звучит круто! Но как реализовать это на Python? Опять же напишем простую и понятную реализацию, как с TF-IDF.

Мы использовали параметры по умолчанию для k и b, и наши результаты выглядят многообещающе. Запрос ‘purple’ соответствует только предложению a, а ‘bananas’ набирает приемлемые баллы и для b, и для c, но для c — немного выше благодаря меньшему количеству слов. Чтобы построить векторы на основе этих данных, сделаем то же самое, что и с TF-IDF.

Опять же, как и в случае с векторами TF-IDF, эти векторы разрежены. Мы не сможем кодировать семантическое [смысловое] значение, вместо этого сосредоточимся на синтаксисе.

Теперь давайте посмотрим, как можно начать рассматривать семантику.

3. BERT

Каждый плотный вектор обычно содержит 768 значений, и мы обычно имеем 512 таких векторов для каждого закодированного BERT предложения. Эти векторы содержат то, что мы можем рассматривать как числовые представления языка. Эти векторы также возможно извлечь (если этого захочется) из разных слоёв, но обычно из последнего слоя. Теперь, имея два правильно закодированных плотных вектора, мы можем использовать метрику сходства, такую как косинусное сходство, чтобы рассчитать теперь уже семантическое сходство. Более выровненные векторы семантически схожи, и наоборот.

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

Рассмотрим оба варианта, начиная с подхода через transformers и PyTorch, чтобы получить интуитивное представление о построении векторов. Если вы уже использовали библиотеку трансформаторов HF, первые несколько шагов покажутся вам очень знакомыми: инициализируем SBERT и токенизатор, токенизируем наш текст и обработаем токены моделью.

Мы добавили сюда новое предложение, предложение g несёт тот же семантический смысл, что и b, — без тех же ключевых слов. Из-за отсутствия общих слов все наши предыдущие методы не смогли бы найти сходство между этими двумя последовательностями — запомните это на будущее.

У нас есть векторы длины 768, но это не векторы предложений, так как мы имеем векторное представление каждой лексемы в последовательности (поскольку мы работаем SBERT, их здесь 128, а в случае BERT их 512). Для создания вектора предложений нам необходимо выполнить вычислить среднее значение.

Первое, что мы делаем, — умножаем каждое значение в тензоре embeddings на соответствующее значение attention_mask. Маска attention_mask содержит единицы там, где у нас есть «настоящие токены» (например, не токен заполнения), и нули в других местах — эта операция позволяет нам игнорировать ненастоящие токены.

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

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

Тепловая карта, показывающая косинусное сходство между нашими векторами предложений SBERT: обведена оценка между предложениями b и g

Теперь вспомните замечание о том, что предложения b и g имеют по сути одинаковый смысл, но не имеют ни одного одинакового ключевого слова. Мы надеемся, что SBERT с его превосходными семантическими представлениями языка определит эти два предложения как похожие — и вот, пожалуйста, сходство между ними составляет 0,66 балла (обведено выше). Итак, альтернативный (простой) подход заключается в применении SBERT. Чтобы получить точно такой же результат, как выше, напишем:

Что, конечно, гораздо проще. На этом завершаем прогулку по истории с Жаккаром, Левенштейном и Bert!

[1] Market Capitalization of Alphabet (GOOG), Companies Market Cap.

[2] N. Reimers, I. Gurevych, Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks (2019), Proceedings of the 2019 Conference on Empirical Methods in 2019.

Источник