Цель
Я пытаюсь создать основанную на онтологии semanti c поисковую систему, специфицирующую c для наших данных.
Постановка задачи
Наши данные - это просто набор предложений, и я хочу дать фразу и получить обратно предложения, которые:
Аналогичны этой фразе
- Имеет часть предложения, которая похожа на фразу
- Предложение, имеющее контекстуально похожие значения
Позвольте мне привести вам пример, предположим, что я ищу фразу «Опыт покупки», я должен получить такие предложения, как:
- Я никогда не думал, что покупка машины может занять менее 30 минут, чтобы подписать и купить.
- Я нашел машину, которую я понравилось, и процесс покупки был простым и легким
- Я абсолютно ненавидел ходить по магазинам, но сегодня я рад, что сделал
Поисковый термин всегда будет от одного до трех слов фразы. Пример: опыт покупки, комфорт вождения, информационно-развлекательная система, интерьеры, пробег, производительность, удобство сидения, поведение персонала.
Реализация уже исследована
OpenSemanticSearch
AWS Comprehend
Текущая реализация
Сейчас я изучаю одну реализацию ('Holmes Extractor'), которая в основном соответствует цели, которую я пытаюсь достичь. Для моего случая использования я использую «Topi c Matching», доступный в Holmes.
Холмс уже включил в свой дизайн много важных концепций, таких как NER, разрешение местоимений, сходство на основе встраивания слов, извлечение на основе онтологий, что делает эту реализацию еще более перспективной.
То, что я до сих пор пробовал на Холмсе
- Вручную курировал помеченный набор с предложениями
- Зарегистрировал и сериализовал наш набор данных с уникальной меткой id для каждого документа (предложения)
- Для сравнения подготовлен шаблон для получения точности, отзыва и f1_score каждой итерации запущенных запросов (поисковый запрос совпадает с меткой)
- Использование spaCy's 'en_core_web_lg' для встраивания слов
Шаблон оценки выглядит примерно так: Query | Предсказанные строки | Фактическое количество строк в запрашиваемом наборе | Точность | Напомним | f1_score
Ниже приведены параметры, используемые в каждой итерации. Для всех итераций были сгенерированы оценки для Manager.overall_simility_threshold в диапазоне (от 0,0 до 1,0) и topic_match_documents_returning_dictionaries_against.embedding_penalty в диапазоне (от 0,0 до 1,0)
Итерация 1:
Без онтологии и Manager.embedding_based_matching_on_root_words = False
Итерация 2:
Без онтологии и Manager.embedding_based_matching_on_root_words = True
Создание пользовательской онтологии с использованием Protege, которая задает c для нашего набора данных
Итерация 3:
С пользовательской онтологией и Manager.embedding_based_matching_on_root_words = False, Ontology.symmetric_matching = True
Итерация 4:
С пользовательской онтологией и Manager.embedding_based_matching_on_root_words = True, Ontology.symmetric_matching = True
На этом этапе Я могу заметить, что
пользовательская онтология,
Manager.embedding_based_matching_on_root_ words = True,
Manager.overall_simility_threshold в диапазоне (0,6-0,8),
topic_match_documents_returning_dictionaries_against.embedding_penalty в диапазоне в диапазоне (0,6-0,8),
вместе дают очень сильные оценки.
средние оценки для 0,8 -> точность: 0,78, отзыв: 0,712, f1_score: 0,738
средние оценки для 0,7 -> точность: 0,738, отзыв: 0,7435, f1_score: 0,726
Тем не менее результаты не настолько точны даже после предоставления пользовательской онтологии из-за отсутствия ключевых слов в графе онтологий.
Например, если в Онтологии мы указали что-то вроде Пробег-> эффективность использования топлива, экономия топлива
Холмс не будет сопоставлять предложения с эффективностью расхода топлива при пробеге, так как «Эффективность использования топлива» не упоминается в графике
Итерация 5:
С пользовательской онтологией и Manager.embedding_based_matching_on_root_words = False, Ontology.symmetric_matching = False
Итерация 6:
С пользовательской Ontology и Manager.embedding_based_matching_on_root_words = True, Ontology.symmetric_matching = False
Итерация 7:
вместе с параметрами Итерации 4 и
topic_match_documents_returning_dictionaries_against.tied_result_quotient в диапазоне (от 0,9 до 0,1)
Снова результаты лучше в диапазоне 0,8-0,9
Итерация 8:
Я предварительно загрузил онтологии из несколько источников:
Автомобильная онтология:
https://github.com/mfhepp/schemaorg/blob/automotive/data/schema.rdfa
Онтология продаж автомобилей:
http://www.heppnetz.de/ontologies/vso/ns
Онтология продукта:
http://www.productontology.org/dump.rdf
Me sh Тезаурус:
https://data.europa.eu/euodp/en/data/dataset/eurovoc
Engli sh Тезаурус:
https://github.com/mromanello/skosifaurus
https://raw.githubusercontent.com/mromanello/skosifaurus/master/thesaurus.rdf
Общие онтологии:
https://databus.dbpedia.org/dbpedia/collections/pre-release-2019-08-30
https://wiki.dbpedia.org/Downloads2015-04#dbpedia - онтология
https://lod-cloud.net/dataset/dbpedia
https://wiki.dbpedia.org/services-resources/ontology
https://meta.wikimedia.org/wiki/Data_dump_torrents#English_Wikipedia
https://tools.wmflabs.org/wikidata-exports/rdf/
Все вышеперечисленные онтологии доступны в формате ttl, n3 или rdf. И экстрактор Холмса (неявно RDFlib) работает по синтаксису OWL. Поэтому преобразование данных форматов в формат OWL для тяжелых файлов является еще одной проблемой.
Я попытался загрузить первые 4 онтологии в Holmes после преобразования в OWL. Но процесс преобразования также требует времени. Кроме того, загрузка больших онтологий на самого Холмса занимает много времени.
Согласно документации Холмса, Холмс лучше всего работает с онтологиями, которые были созданы для определенных c предметных областей и вариантов использования. .
Что дальше
Задачи, с которыми я здесь сталкиваюсь:
- Поиск подходящих онтологий, доступных для клиентов в автомобиле domain
- Ускорение процесса преобразования онтологий
- Как мы можем легко сгенерировать доменную специфику c онтологию из наших существующих данных
- Настройка правильного набора параметров по с онтологией, чтобы получить более точные результаты для поисковых запросов фраз
Любая помощь будет оценена. Большое спасибо за помощь заранее