Привет! Меня зовут Илья Гусев, я занимаюсь машинным обучением в команде Яндекс.Новостей. У каждого новостного сюжета на сервисе есть своя страница, где собраны новости об одном и том же событии из разных источников. Сегодня мы рассмотрим построение краткой выжимки, дайджеста сюжета. В такой выжимке, состоящей из фрагментов новостных документов, содержится основная информация о событии. Очевидно, почему дайджест полезен для пользователя — мы выводим на экран сюжета самое важное о событии. С похожими задачами сталкиваются многие инженеры: например OpenAI недавно опубликовала статью про реферирование книг. Поэтому я надеюсь, что описанный ниже подход будет вам полезен.
Как и всё в Новостях, построение такой выжимки должно быть полностью автоматическим. До внедрения выжимки текстовая часть сюжета выглядела так:
Теперь она выглядит так:
Реферирование (или аннотирование, или суммаризация) — процесс получения краткой версии документа, которая раскрывала бы его суть. Вы наверняка сталкивались с аннотациями книг, газетных и новостных статей, составленными людьми. Автоматическое же реферирование происходит с помощью компьютерной программы.
Автоматическим реферированием инженеры занимаются с 50-х. Одна из первых работ на эту тему — статья Ханса Петера Луна 1958 года.
Задача мультидокументного реферирования тоже достаточно стара. Её популяризировали ещё в начале нулевых годов серией конференций DUC (Document Understanding Conference). Её основное отличие от обычного реферирования — на вход алгоритму подают не один, а несколько документов.
В Яндекс.Новостях мы реферируем сюжет, то есть коллекцию документов об одном и том же событии. На выходе хотим получить краткую выжимку самых важных подробностей из этих документов.
Важно, что Новости не пишут собственные тексты, даже автоматически: у нас нет своей редакции, все материалы, которые мы используем, получаем от изданий-партнёров. То есть в готовую выжимку обязательно должны попасть текстовые фрагменты из документов на входе. Это отметает все абстрагирующие методы, которые могут писать новые тексты, в том числе и YaLM.
Выжимки бывают разных форматов: они могут отличаться размером и числом фрагментов. После экспериментов мы остановились на 4 предложениях. Выжимки большего размера, как и фрагменты больше предложения, пользователи воспринимают тяжело.
Изначально мы пробовали делать выжимку из одного документа, с помощью довольно простых TextRank и LexRank, использующих PageRank над графом похожести предложений друг на друга, а также более сложного SummaRuNNer'а, суть которого в обучении рекуррентной модели на бинарную классификацию, попадёт ли каждое предложение в выжимку или нет.
Это не могло работать на сервисе в такой постановке. Во-первых, такие алгоритмы никак не могут учитывать важность фрагментов, которые встречаются в нескольких документах. Во-вторых, они очень сильно сдвигают распределение трафика в сторону одного источника, что для нас неприемлемо.
Что касается методов именно мультидокументного реферирования, тяжёлые end-to-end модели мы даже не рассматривали как минимум потому, что не смогли бы объяснить изданиям и пользователям, как они работают. Алгоритмы Новостей должны быть максимально прозрачны и интерпретируемы.
Мы остановились на мультидокументном реферировании через кластеризацию предложений. Во-первых, этот алгоритм крайне прост в понимании, написании и поддержке. Во-вторых, эмбеддинги предложений для кластеризации можно предподсчитывать один раз для каждого документа, что экономит кучу процессорного времени. Это не единственный подходящий способ мультидокументного реферирования, тот же LexRank вполне применим для нескольких документов.
Сразу оговоримся, что идея мультидокументного реферирования через кластеризацию предложений не нова. Существует много статей про этот метод: например, эта и эта. От них наш алгоритм отличается прежде всего способом подсчёта расстояний между предложениями.
В общих чертах алгоритм устроен так:
В итоге получаем выжимку из четырёх предложений, каждое из которых встречается в одном из документов наших партнёров.
В Яндексе существует разделение на офлайн- и онлайн-метрики. Онлайн-метрики считаются в ходе A/B экспериментов на самих сервисах и показывают, как пользователи взаимодействуют с новой функциональностью. А вот офлайн-метрики не требуют этих взаимодействий.
По онлайн-метрикам дайджеста мы видим, что пользователям удобна новая функциональность: активность и время, проведённое на сервисе, увеличиваются.
В качестве основных офлайн-метрик мы используем две разметки в Толоке. Толока — это сервис краудсорсинга, который позволяет выдавать тысячам людей несложные задания. Первая разметка оценивает, хорошая или плохая получилась краткая выжимка, а вторая выявляет проблемы с отдельными фрагментами.
Бинарную разметку мы регулярно снимаем с топовых сюжетов основных рубрик. Каждую выжимку размечает 10 человек. Если только 5 или 6 человек из 10 сказали, что с выжимкой всё в порядке, то мы ставим выжимке вердикт «не уверены». Если 4 и меньше, то «плохая выжимка», а если 7 и больше, то «хорошая». На графике ниже красным цветом отмечена доля плохих выжимок, зелёным — доля хороших. Важно отметить, что вердикт «плохая выжимка» не гарантирует наличие серьёзных проблем, только очевидных. А они могут быть как мелкими, так и серьёзными.
Такую разметку тяжело масштабировать. Чтобы обойти это, мы построили BERT-классификатор, приближающий разметку. На каждое изменение алгоритма можно просто прогнать классификатор и получить примерный эффект от этого изменения. Это позволило нам перебрать гиперпараметры алгоритма и выбрать оптимальные с точки зрения этого классификатора, с последующей проверкой по разметке.
По результатам ручного отсмотра плохих выжимок, мы выделили 4 основных категории ошибок (представлены на картинке), а также отдельно захотели выделять фрагменты про предысторию события. Вторая разметка как раз нацелена на то, чтобы выяснить, какие из ошибок встречаются чаще. Метки надо ставить отдельным фрагментам, но разметчикам доступна вся выжимка.
Основной проблемой на данный момент являются дубли, то есть фрагменты повторяющие друг друга. Одна эта категория занимает более 50% всех ошибок. Берутся они в основном из-за несовершенства эмбеддингов и кластеризации.
Уже больше 3 месяцев автоматическое построение выжимок работает на всех платформах и для всех сюжетов. Пользователи в целом довольны, это видно по росту возвращаемости и активности на сервисе. При этом мы не считаем 20-30% плохих выжимок приемлемой цифрой и активно работаем над её уменьшением:
Очевидно, что текущие разметки проверяют лишь «внешний вид» выжимки, а хотелось бы ещё понимать, как хорошо выжимка вытаскивает важные подробности и насколько она информативна. Будем продолжать исследования в этом направлении.
Мы надеемся, что все будут в выигрыше от внедрения дайджестов.
Как и всё в Новостях, построение такой выжимки должно быть полностью автоматическим. До внедрения выжимки текстовая часть сюжета выглядела так:
Теперь она выглядит так:
Задача
Реферирование (или аннотирование, или суммаризация) — процесс получения краткой версии документа, которая раскрывала бы его суть. Вы наверняка сталкивались с аннотациями книг, газетных и новостных статей, составленными людьми. Автоматическое же реферирование происходит с помощью компьютерной программы.
Автоматическим реферированием инженеры занимаются с 50-х. Одна из первых работ на эту тему — статья Ханса Петера Луна 1958 года.
Задача мультидокументного реферирования тоже достаточно стара. Её популяризировали ещё в начале нулевых годов серией конференций DUC (Document Understanding Conference). Её основное отличие от обычного реферирования — на вход алгоритму подают не один, а несколько документов.
В Яндекс.Новостях мы реферируем сюжет, то есть коллекцию документов об одном и том же событии. На выходе хотим получить краткую выжимку самых важных подробностей из этих документов.
Важно, что Новости не пишут собственные тексты, даже автоматически: у нас нет своей редакции, все материалы, которые мы используем, получаем от изданий-партнёров. То есть в готовую выжимку обязательно должны попасть текстовые фрагменты из документов на входе. Это отметает все абстрагирующие методы, которые могут писать новые тексты, в том числе и YaLM.
Выжимки бывают разных форматов: они могут отличаться размером и числом фрагментов. После экспериментов мы остановились на 4 предложениях. Выжимки большего размера, как и фрагменты больше предложения, пользователи воспринимают тяжело.
Алгоритм
Изначально мы пробовали делать выжимку из одного документа, с помощью довольно простых TextRank и LexRank, использующих PageRank над графом похожести предложений друг на друга, а также более сложного SummaRuNNer'а, суть которого в обучении рекуррентной модели на бинарную классификацию, попадёт ли каждое предложение в выжимку или нет.
Это не могло работать на сервисе в такой постановке. Во-первых, такие алгоритмы никак не могут учитывать важность фрагментов, которые встречаются в нескольких документах. Во-вторых, они очень сильно сдвигают распределение трафика в сторону одного источника, что для нас неприемлемо.
Что касается методов именно мультидокументного реферирования, тяжёлые end-to-end модели мы даже не рассматривали как минимум потому, что не смогли бы объяснить изданиям и пользователям, как они работают. Алгоритмы Новостей должны быть максимально прозрачны и интерпретируемы.
Мы остановились на мультидокументном реферировании через кластеризацию предложений. Во-первых, этот алгоритм крайне прост в понимании, написании и поддержке. Во-вторых, эмбеддинги предложений для кластеризации можно предподсчитывать один раз для каждого документа, что экономит кучу процессорного времени. Это не единственный подходящий способ мультидокументного реферирования, тот же LexRank вполне применим для нескольких документов.
Сразу оговоримся, что идея мультидокументного реферирования через кластеризацию предложений не нова. Существует много статей про этот метод: например, эта и эта. От них наш алгоритм отличается прежде всего способом подсчёта расстояний между предложениями.
В общих чертах алгоритм устроен так:
- Разбиваем каждый документ на предложения. Основными объектами нашей выжимки как раз будут эти предложения.
- Для каждого предложения всех документов считаем эмбеддинг — числовое представление информации, которая содержится в предложении. Эмбеддинги можно строить по-разному, например через FastText, USE, LaBSE. Совершенно необязательно использовать для этого нейросетевые модели, подойдёт и старый-добрый TF-IDF, только он будет хуже определять похожие предложения.
Мы строим эмбеддинги через DSSM, который дистиллирует LaBSE. В нашем варианте дистилляции DSSM обучался предсказывать расстояния между парами предложений, посчитанное по LaBSE, но это не единственный способ. Основная причина, почему мы делаем именно так — высокая производительность DSSM Яндекса: более тяжёлые с точки зрения процессорного времени модели мы пока не можем себе позволить из-за большого потока документов. Когда мы добавим в эту часть сервиса побольше GPU, это снизит ограничения в производительности, и можно будет использовать трансформеры.
- Для каждой пары предложений из разных документов считаем, насколько они похожи друг на друга. Для разных предложений из одного документа считаем, что они заведомо отличаются.
- Запускаем на полученной двумерной матрице сходства алгоритм иерархической кластеризации со склейкой по среднему (например, такой) с подобранной по ручной разметке границей обрезки. На выходе получаем кластеры, состоящие из похожих друг на друга предложений. Таким образом, один кластер равен примерно одной «смысловой единице» нашего сюжета.
Пример кластера:
- Во время эксперимента выяснилось, что у животных, чьи тела размещены параллельно земле, более гибкие позвоночники.
- В рамках эксперимента было определено, что животные, у которых тела располагаются параллельно поверхности земли, имеют куда более гибкий позвоночник
- В процессе эволюции животные приобрели более гибкий позвоночник, который оптимален для длительного соприкосновения ступни с землей.
- У животных же, имеющих тела, расположенные параллельно земле, позвоночник стал весьма гибким.
- «Животные, чьи тела размещены параллельно земле, в процессе эволюции получили более гибкие позвоночники, поэтому четвероногие животные могут бегать быстрее людей», — добавил Гюнтер.
- Предполагаем, что самые важные элементы сюжета упоминали чаще, а значит, предложений в таких кластерах должно быть больше. Оставляем четыре самых крупных кластера с наибольшим количеством документов.
- Сортируем оставшиеся четыре кластера по относительной медианной позиции составляющих их предложений в оригинальных документах. Это нужно для того, чтобы текст выглядел более связным.
- Фильтруем в кластерах предложения с местоимениями, которые непонятно к чему относятся с помощью текстового классификатора и регулярок. Например, во фразе «Она назвала шесть пунктов, в которых высказана озабоченность в отношении производства на этом предприятии» непонятно, к кому относится «она» и о каком предприятии идёт речь.
- Выделяем предложение, которое будет представлять кластер в итоговой выжимке. Алгоритм ранжирования предложений внутри кластеров использует несколько параметров, основной из которых — средняя похожесть предложения на все остальные предложения кластера. Получается, мы отдаём предпочтение предложению, эмбеддинг которого ближе всего к центру масс кластера. Это не единственный возможный критерий выбора, можно, например, для каждой точки брать медиану расстояний до остальных точек, чтобы уменьшить влияние огрехов кластеризации.
В итоге получаем выжимку из четырёх предложений, каждое из которых встречается в одном из документов наших партнёров.
Метрики
В Яндексе существует разделение на офлайн- и онлайн-метрики. Онлайн-метрики считаются в ходе A/B экспериментов на самих сервисах и показывают, как пользователи взаимодействуют с новой функциональностью. А вот офлайн-метрики не требуют этих взаимодействий.
По онлайн-метрикам дайджеста мы видим, что пользователям удобна новая функциональность: активность и время, проведённое на сервисе, увеличиваются.
В качестве основных офлайн-метрик мы используем две разметки в Толоке. Толока — это сервис краудсорсинга, который позволяет выдавать тысячам людей несложные задания. Первая разметка оценивает, хорошая или плохая получилась краткая выжимка, а вторая выявляет проблемы с отдельными фрагментами.
Бинарную разметку мы регулярно снимаем с топовых сюжетов основных рубрик. Каждую выжимку размечает 10 человек. Если только 5 или 6 человек из 10 сказали, что с выжимкой всё в порядке, то мы ставим выжимке вердикт «не уверены». Если 4 и меньше, то «плохая выжимка», а если 7 и больше, то «хорошая». На графике ниже красным цветом отмечена доля плохих выжимок, зелёным — доля хороших. Важно отметить, что вердикт «плохая выжимка» не гарантирует наличие серьёзных проблем, только очевидных. А они могут быть как мелкими, так и серьёзными.
Такую разметку тяжело масштабировать. Чтобы обойти это, мы построили BERT-классификатор, приближающий разметку. На каждое изменение алгоритма можно просто прогнать классификатор и получить примерный эффект от этого изменения. Это позволило нам перебрать гиперпараметры алгоритма и выбрать оптимальные с точки зрения этого классификатора, с последующей проверкой по разметке.
По результатам ручного отсмотра плохих выжимок, мы выделили 4 основных категории ошибок (представлены на картинке), а также отдельно захотели выделять фрагменты про предысторию события. Вторая разметка как раз нацелена на то, чтобы выяснить, какие из ошибок встречаются чаще. Метки надо ставить отдельным фрагментам, но разметчикам доступна вся выжимка.
Основной проблемой на данный момент являются дубли, то есть фрагменты повторяющие друг друга. Одна эта категория занимает более 50% всех ошибок. Берутся они в основном из-за несовершенства эмбеддингов и кластеризации.
Планы
Уже больше 3 месяцев автоматическое построение выжимок работает на всех платформах и для всех сюжетов. Пользователи в целом довольны, это видно по росту возвращаемости и активности на сервисе. При этом мы не считаем 20-30% плохих выжимок приемлемой цифрой и активно работаем над её уменьшением:
- Переходим на трансформерные эмбеддинги, например, на тот же LaBSE
- Улучшаем определение плохих фрагментов текстовым классификатором.
- Добавляем новую информацию: подсвечиваем ссылки и сущности.
Очевидно, что текущие разметки проверяют лишь «внешний вид» выжимки, а хотелось бы ещё понимать, как хорошо выжимка вытаскивает важные подробности и насколько она информативна. Будем продолжать исследования в этом направлении.
Мы надеемся, что все будут в выигрыше от внедрения дайджестов.
Ещё несколько примеров построенных выжимок
