11 Часть I. Компоненты 14 Глава Компьютерная
жүктеу/скачать 4,29 Mb.
|
nikolaev is mitrenina ov lando tm red prikladnaia i kompiute
- Бұл бет үшін навигация:
- Стандартные запчасти
- Расширения
- Расстояния
- Еще немного поисковой лингвистики
А где же лингвистика?Может сложиться впечатление, что раз полноценный анализ докумен- тов и запросов для поиска практически невозможен, то поисковая система прекрасно обходится вообще без компьютерной лингвистики и достигает приемлемого качества одним только машинным обучением поверх доста- точного количества факторов и оценок релевантности. Это не так. 1 Здесь df посчитана с помощью Национального корпуса русского языка (ruscorpora.ru), а N, как легко видеть, можно выбрать любым, потому что оно одинаковое для любого термина и любого документа; я взял 108. Стандартные запчастиВо-первых, для нормализации терминов нужен морфологический анализатор — стеммер или лемматизатор. Помимо прочего, анализатор должен хорошо управляться с несловарными словами, которых много в запросах (в особенности это касается различных имен собственных). Кроме того, поскольку запросы обрабатываются в реальном времени, мо- гут возникать ограничения на размер модели словоизменения, «зашитой» в лемматизатор. Чтобы уложиться в эти ограничения, потеряв как можно меньше в полноте срабатываний, может потребоваться, скажем, выбросить часть редких форм из слишком обширных парадигм, или выбросить мак- симум словарных форм, правильно разбираемых модулем несловарного анализа, или придумать более компактный способ хранения модели, или еще что-нибудь. Все это не такие уж тривиальные задачи. Кстати, для того, чтобы выбрать правильный морфологический ана- лизатор для данного документа или запроса, нужно уметь определять их язык — даже если используется смесь языков или транслитерация. Чем больше языков мы хотим поддержать, тем больше шансов, что они начнут путаться между собой, и тем более хитрая модель распознавания языка может понадобиться. (Хотя обычно все сводится к вероятностям N-грамм символов и некоторой добавки из частотных слов.) Другой очень важный компонент — модуль исправления опечаток. Около 10–15 % запросов содержат опечатки, которые требуется исправить, чтобы извлечь из запроса настоящую информационную потребность. Дело отчасти осложняется тем, что запросы — это очень короткие тексты, и часто контекста недостаточно для выбора нужного варианта исправления из нескольких. К примеру, если мы получили запрос [тстер], то пользова- тель мог иметь в виду как тестер, так и тостер, и даже остер, но [циф- ровой тстер] намекает на то, что это все-таки тестер. В зависимости от того, доступен ли контекст, можно использовать модель, учитывающую или не учитывающую его. По сравнению с некоторыми другими ситуациями, где нужен модуль опечаток (например, в текстовом редакторе), при поиске используется расширенный набор стратегий обработки слова с предполагаемой опечат- кой: при достаточной степени уверенности можно просто заменить оши- бочное слово в запросе на правильное (об автозамене см., например, свежую статью [Панина и др. 2013]); если уверенности меньше, можно показать пользователю подсказку («Возможно, вы имели в виду…»); в некоторых случаях, когда в результате опечатки получается другое существующее слово (допустим, [отель астра] вместо [опель астра]), можно подмешать к результатам поиска по исходному запросу ре- зультаты поиска по исправленному и тем самым увеличить вероят- ность нахождения хотя бы одного релевантного документа. Где-то рядом с проблемой опечаток находится проблема диакритики. Для русского языка она стоит не слишком остро (омонимов на е-ё сравни- тельно немного), но в некоторых других языках, таких как турецкий или венгерский, много букв с диакритикой, и пользователи регулярно ленятся набирать их (ведь это иногда требует двух нажатий клавиш вместо одно- го!), заменяя, например, ç на c или ğ на g. В результате образуется особый класс регулярных опечаток, проблематичных именно своей регулярностью: легко может оказаться, что вариант с «неправильной» диакритикой встре- чается в запросах чаще, чем с настоящей, а такого рода статистика — важная часть модуля обработки опечаток. РасширенияПоиск, как мы уже начинали обсуждать, страдает от неоднозначности, присущей естественным языкам. Одна из сторон этой неоднозначности — синонимия, причем в наиболее широком смысле: когда два термина (или даже еще шире — две подстроки) взаимозаменяемы в некоторых контек- стах. Скажем, по запросу [где купить картошку недорого] наверняка будет релевантным документ, предлагающий [купить картофель дешево]. В этом примере фигурирует самый очевидный для лингвиста вид синонимов, да- вайте назовем их «просто синонимы». Как известно, полных синонимов вообще очень мало, вот и картошка/картофель тоже заменяют друг друга не всегда: допустим, [пирожное картофель] — это запрос не про пирож- ное картошка. Кроме «просто синонимов», можно выделить еще такие классы (см. [Соловьев 2010]): словообразовательные: [законы физики] vs [физические законы]; транслиты: [Bosch] vs [Бош], [Metallica] vs [Металлика]; аббревиатуры: [ИП] vs [индивидуальный предприниматель]; склейка-разрезание: [авто кредит] vs [автокредит]. Как это использовать? Если мы знаем, что термин Голландия является синонимом термина Нидерланды, то можно сделать приблизительно вот что: при обработке запроса [нидерланды достопримечательности] до того, как обращаться к инвертированному индексу за словопозициями, преобра- зовать запрос так, чтобы на месте первого термина стояла дизъюнкция терминов. Это можно записать как [(нидерланды ^ голландия) достопри- мечательности], и в данном случае можно сказать, что мы расширили тер- мин запроса другим термином. Такие расширения практически не услож- няют алгоритм поиска нужных документов в индексе. Где найти и как потом хранить такие данные? Традиционно информа- ция о связях между словами содержится в тезаурусах. Например, в струк- туре WordNet предусмотрены связи двух из пяти видов («просто синони- мы» и словообразовательные), плюс аббревиатуры в принципе могут вхо- дить в тезаурус как отдельные слова и образовывать стандартные связи. Если тезаурус многоязычный, там можно найти в каком-то количестве и «транслитные» синонимы. Применение в поиске таких «классических» тезаурусов описано в [Лукашевич 2011: 201–222]. Наши пять видов рас- ширений можно считать тезаурусными расширениями. Но в реальности готового тезауруса достаточной полноты не сущест- вует, особенно с учетом того, что новые аббревиатуры и транслиты появ- ляются постоянно. В такой ситуации приходится собирать тезаурус из разных источников. В вышеупомянутом докладе Евгения Соловьева опи- сан процесс такой сборки в том виде, в каком он использовался в Яндексе в 2010 году. Этот процесс работает во многом одинаково для всех классов синонимов и включает 4 стадии: генерация исходных гипотез; фильтрация с помощью лингвистической модели; фильтрация с помощью статистики совместной встречаемости; очистка полученного словаря с помощью модели, полученной ма- шинным обучением на данных ручной разметки пар гипотез. Как может выглядеть лингвистическая модель? Для «просто синони- мов» это может быть один из множества вариантов семантического рас- стояния по тезаурусу типа WordNet; для словообразовательных — соот- ветственно, модель словообразования, которая знает обо всех допустимых аффиксах и их продуктивности; для транслитов — написанные вручную правила и имеющиеся стандарты транслитерации (с которыми сталкивал- ся любой, кто получал загранпаспорт) и/или статистическая модель, обу- ченная на большом параллельном корпусе транслитераций. Для аббревиа- тур и слитных-раздельных синонимов достаточно более простых моделей. Под совместной встречаемостью подразумевается не только, допус- тим, появление обоих членов гипотетической синонимической пары на одной веб-странице, но и регулярная замена одного члена другим в пере- формулировках: например, пользователь не удовлетворен результатами поиска по запросу [айфон 6] и переформулирует запрос как [iphone 6]; такие события можно найти в накопленных данных и выделить статисти- чески значимые частые замены, предположим, с помощью мер взаимной информации. Фильтрация по совместной встречаемости помогает отсеять среди прочего случаи вроде магазин/magazine, то есть когда хороший транслит не является хорошим расширением. Одна из проблем полученных синонимов — неоднозначность, разре- шаемая только в контексте: hugo в запросе [hugo boss] — это хьюго, а в запросе [victor hugo] — гюго. Из этого следует, во-первых, что готовый словарь расширений — структура несимметричная (расширять хьюго до hugo безопасно, видимо, всегда, а наоборот — нет), во-вторых, что к паре синонимов в словаре может прилагаться в каком-то виде список контек- стов, в которых данное расширение имеет смысл. Примечательно, что контекст необязательно должен быть текстовым. Безобидная аббревиатура МГУ, оказывается, может означать не только Московский государственный университет, но и еще несколько учебных заведений (к примеру, Монгольский или Могилевский государственный университет). И если к нам приходит запрос [поступление в МГУ] из Са- ранска (а поисковая система обычно может определить, в каком регионе находится пользователь), то мы можем расширить МГУ до Мордовский государственный университет. А вот если тот же самый запрос задан из Подмосковья, то, пожалуй, это расширение не добавит полезных докумен- тов. Получается, что контекстом становится регион пользователя. В качестве резюме можно сказать, что тезаурусные расширения серь- езно помогают повысить полноту поиска, и это всецело оправдывает уси- лия по сбору словарей расширений. РасстоянияКак использовать лингвистику для повышения точности? До сих пор мы внимательно рассматривали только модель tf-idf, для которой порядок следования слов запроса в документе был несуществен. Однако есть слу- чаи, когда он имеет значение: вряд ли по запросу [нижний новгород] поль- зователь будет рад документу о маршруте из Нижнего Тагила в Великий Новгород. Координатный инвертированный индекс, хранящий инфор- мацию о конкретных позициях терминов в документе, позволяет обраба- тывать запросы с ограничениями на расстояния типа [нижний /1 новгород] (такая запись означает, что второй термин должен находиться на расстоя- нии 1 от первого, то есть идти сразу за ним). Типичная ситуация, когда расстояния полезны — наличие в запросе имен и названий: имени-фамилии человека ([дмитрий менделеев]), топо- нима ([улица маршала жукова]), названия произведения искусства ([вино из одуванчиков]) и т. п. С людьми, правда, есть некоторая загвоздка, пото- му что, скажем, в русской культуре у людей есть опциональные отчества, и надо предусмотреть их корректную обработку, чтобы по запросу [вла- димир даль] находить документы «Владимир Даль» и «Владимир Ивано- вич Даль» и не находить (или ранжировать ниже) документ «Князь Вла- димир всматривался в голубеющую даль». Это немного похоже на задачу извлечения именованных сущностей, но в запросе обычно не хватает контекста для использования стандартных мо- делей извлечения, поэтому более осмысленное решение здесь — исполь- зовать словари и некоторые простые модели (допустим, можно предполо- жить, что цепочка вида «имя из словаря + слово на -вич/-вна + любое сло- во» является полным обозначением человека и все три термина надо ис- кать вплотную). На эту тему см. [Ландо 2013]. Расстановка ограничений на расстояние — возможно, менее строгих может принести пользу и при обработке сочетаний типа [белая ворона], [юридическое лицо], [спальный вагон] и т. п. Если смотреть шире, то если мы в состоянии выделить в запросе, например, именную группу, то можно попробовать искать слова-члены этой группы недалеко друг от друга. Что такое «недалеко», можно подобрать эмпирически или машинным обуче- нием. В сущности, все это способы аппроксимировать структуру смысла запроса без привлечения полного анализа. Как и во многих других случа- ях — например, со скрытыми марковскими моделями для снятия грамма- тической неоднозначности, — это явно очень сильное упрощение, но даже в таком виде оно бывает полезно. Еще немного поисковой лингвистикиЛингвистика может пригодиться и в некоторых других компонентах информационного поиска. Например, некоторые информационные запро- сы предполагают один короткий правильный ответ, который можно пока- зать вместе со списком найденных документов: [дата основания петербур- га], [высота эйфелевой башни], [столица албании]. Это практически иде- альная ситуация для использования простых семантических баз данных, в частности, обычных троек RDF. Данные можно со сравнительно неболь- шими усилиями собрать даже из открытых источников (Википедия, Wikidata, Freebase и т. п.). Остается научиться понимать, на какие запросы нужно отвечать таким образом. Здесь с помощью относительно малого количества шаблонов можно достичь приемлемой полноты. Цель многих запросов неясна. Допустим, что следует искать по за- просу [скутер]: транспортное средство или музыкальный коллектив? В отсутствие контекста надо искать все, чтобы обеспечить разнообразие поисковой выдачи. Но есть риск, что вся выдача заполнится документами с одним из значений (заметим, вполне релевантными с обычной точки зрения). Чтобы избежать этого, можно заранее с помощью классификатора пометить документы тем или иным значением, а на этапе ранжирования проследить, чтобы все значения были равномерно представлены в выдаче. Задача текстовой классификации документов исследована очень хорошо, но здесь может возникнуть сложность с полнотой словаря многозначных терминов и полнотой списка возможных значений. Часть этой информа- ции можно взять из тезауруса или онтологии, если они есть в наличии, но этого, конечно, недостаточно, и поэтому придется обращаться к статисти- ке. В частности, это может быть статистика запросов с термином в заранее отобранных контекстах вроде [скутер mp3] или [скутер техобслуживание]. На хорошей странице поисковой выдачи есть не только ссылки на найденные документы, но и короткие фрагменты текста этих документов, чтобы пользователь мог составить какое-то мнение о документе еще до перехода по ссылке. Эти короткие фрагменты называются сниппетами (snippets) или — в отечественной литературе — аннотациями. Хорошая аннотация очень помогает пользователю, потому что экономит его время: иногда уже по сниппету понятно, что документ нерелевантный, и можно его даже не открывать. При этом особенно ценятся динамические снип- петы, то есть зависящие от запроса и содержащие слова из него, а не ста- тические, которые создаются один раз для документа и показываются с любым запросом. Задача генерации сниппетов напоминает задачу анноти- рования/реферирования текста (text summarization), но не совпадает с ней главным образом потому, что при реферировании получаются статиче- ские аннотации, отражающие содержание документа целиком, а не в кон- тексте запроса. Кроме того, судя по литературе, алгоритмы реферирования не рассчитаны на работу в реальном времени. Проще говоря, они очень медленные. Говорят, однажды на одной из конференций некий докладчик сказал: «Все эти Яндекс и Гугл работают очень тупо, по ключевым словам. А мы у себя догадались применить семантику». Теперь, прочитав эту главу, ка- ждый сможет сам определиться с перспективами использования серьезной семантики в информационном поиске. Однозначного ответа на этот во- прос пока нет. жүктеу/скачать 4,29 Mb. Достарыңызбен бөлісу:
|