Как и всё в Новостях, построение такой выжимки должно быть полностью автоматическим. До внедрения выжимки текстовая часть сюжета выглядела так:
Теперь она выглядит так:
Задача
Реферирование (или аннотирование, или суммаризация) — процесс получения краткой версии документа, которая раскрывала бы его суть. Вы наверняка сталкивались с аннотациями книг, газетных и новостных статей, составленными людьми. Автоматическое же реферирование происходит с помощью компьютерной программы.
Автоматическим реферированием инженеры занимаются с 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
- Улучшаем определение плохих фрагментов текстовым классификатором.
- Добавляем новую информацию: подсвечиваем ссылки и сущности.
Очевидно, что текущие разметки проверяют лишь «внешний вид» выжимки, а хотелось бы ещё понимать, как хорошо выжимка вытаскивает важные подробности и насколько она информативна. Будем продолжать исследования в этом направлении.
Мы надеемся, что все будут в выигрыше от внедрения дайджестов.
Комментарии (20)
Mr_Floppy
02.11.2021 12:23+2Что толку от ваших новостей, если материалы в них попадают только из "зарегистрированных СМИ", которые управляются из Кремля? В результате в новостной ленте видно только то, как Путин замечательно отдохнул в тайге, как мы окончательно победили короновирус и т.п., при этом замалчивая действительно актуальные темы.
webwork
02.11.2021 13:04+9Статья техническая же, зачем сюда ваш комментарий?
Bromka
02.11.2021 15:30-6Это как обсуждать медицинские данные полученные врачом во время работы в концлагере. Абстрагироваться от контекста их получения можно, но стоит ли?
webwork
02.11.2021 15:38+2Ну если, интересно обсудить именно техническую сторону, а не жаловаться на то как все вокруг плохо - стоит.
Применительно к этму контексту, зачем писать такие комментарии - вы надеетесь, что их прочитает сами знаете кто и что-то изменит? В интернете итак много мест, где обитают отборные тролли и прочая нечисть. Хочется почучаствовать в святой войне - идите на youtube, например.
Хочется менять мир - меняйте, только прилагайте действия, которые приведут или должны привести к результату.Bromka
02.11.2021 15:42-6Мы, в большинстве своем, не можем пообщаться с месье пыткиным. Но те, кто добровольно выбирает работать на его пользу, вполне в зоне нашего влияния. И можно сказать фи хотя бы таким способом.
PS Не надо, пожалуйста, говорить куда мне пойти и что делать. Поставьте минус и проходите дальше, для остального есть правила пользования ресурсом.
webwork
03.11.2021 05:57Прошу прощения, если вас как-то обидел или задел ваши чувства - не имел ввиду никого конкретного.
Chuviks2
02.11.2021 13:23+4Там можно настраивать избранные источники, т.е добавляешь туда всех, кого охота читать, а остальных – в нежелательное и всё
dm_deko
03.11.2021 09:35Вот мне интересно, каким образом выбирается базовая направленность новостей.
Поясню:
Алиса на вопрос "Расскажи новости ИТ области", считает своим долгам рассказать кто какие игры выпустил или готовит. Остальных новостей заметно меньше. Меня пугает такой расклад в вашей целевой аудитории )))
Takagi Автор
04.11.2021 19:19На самом деле это зависит от того, где читать/слушать новости.
В рубрике "Технологии" на самом сервисе первые 5 новостей являются общими для всех, и среди них не очень много новостей про игры (обычно 1-2 из 5). Выбираются эти 5 новостей на основе кучи факторов, например по количеству документов в сюжете, по количеству просмотров этих документов, по авторитетности источников, и так далее.
А вот ниже уже персональные новости, и то, что показывается там, зависит от истории читателя. В Алисе скорее всего тот же принцип.
elingur
03.11.2021 09:54Фильтруем в кластерах предложения с местоимениями,
А почему бы не прикрутить анафору. На таких объемах тормозить не должно, а выглядеть будет куда читабельнее.
Takagi Автор
03.11.2021 13:51+1Тут несколько причин.
Основная проблема в том, что фрагменты дайджеста из разных документов. Разрешение анафоры в пределах одного документа скорее всего действительно работало бы неплохо, но как легко связать местоимения из одного документа с сущностями в другом документе с ходу не очень понятно.
Существующие системы для разрешения анафоры работают далеко не идеально (опираюсь на статью DP).
В итоге быстрое и недорогое решение — просто удалить все предложения с анафорическими местоимениями, пусть и чуть-чуть пожертвовав читаемостью.
Alexwoodmaker
03.11.2021 16:55-2В 2008 работал в Яндексе. Не мог понять логики поиска на примере слова БЕТХОВЕН: в первой десятке была сплошная реклама корма собак. GOOGLE напротив выдавал про композитора. Прошло время и что я вижу: движки поиска практически выдают в унисон, но корм на первом месте. Money talks????
aamonster
Так автоматические выжимки человеком модерируются или нет?
А то про ваши выжимки из отзывов на товары анекдоты ходят... С новостями, вероятно, ситуация получше, но какой-то процент бреда неизбежен, как его отсеять?
Takagi Автор
Выжимки модерировались примерно в течение месяца после запуска в прод, сейчас уже нет.
Во-первых это дорого. Новости обновляются примерно раз в 3-4 минуты, выжимки перестраиваются примерно с такой же частотой. Каждый раз их переотправлять в Толоку или Янг - это огромный объём разметки, даже если кэшировать вердикты по отдельным предложениям. Плюс real-time разметка всегда сложна: толокерам нужно успевать за условные 1-2 минуты разметить несколько выжимок.
Во-вторых это всё-таки экстрактивная суммаризация из профессиональных источников, в отличие от UGC отзывов, которые могут писать любые люди. Поэтому бреда в наших выжимках на порядки меньше. В статье есть график "плохих" выжимок, так даже среди них явного бреда практически нет.
aamonster
Погодите. Каким образом тот факт, что отзывы могут писать любые люди, а не профи, делает их разбор сложнее?
Впрочем, я уже осознал реальную разницу: выжимка делается из одной статьи, а не из массы совершенно разных, порой даже противоположных, отзывов, так что для бреда по образу выжимки из отзывов надо, чтобы в статье фигурировало несколько противоположных утверждений (например, цитаты из мнений разных сторон конфликта), алгоритм выхватил именно их и склеил. Понятно, что тут это будет случаться не так часто.
Так что два других вопроса:
А в каких-то источниках есть семантическая разметка, позволяющая не играть в ИИ, а взять выделенный автором фрагмент текста? Если да – это используется?
Есть кнопка, позволяющая быстро указать, что алгоритм ошибся? Или это не имеет смысла, пока человек обработает такой отзыв – новость уйдёт из выдачи?
Takagi Автор
Опечатки, оборванные фразы, другая лексика. Появляются проблемы уже на уровне разбиения на предложения.
Не совсем так, выжимка делается из нескольких статей, но про одно событие.
Всё верно, и такое случалось на моей памяти. Если кластеризация ошиблась, то статьи могут быть про разные события, и в этом случае выжимка может быть не самосогласована. Но это всё ещё редкое явление, много факторов должно сойтись.
У некоторых источников есть "description" HTML-тег, в которым лежит аннотация. Но их не очень много, и не все они хорошего качества, поэтому мы их не используем.
Отдельной кнопки нет, и скорее всего не будет. У нас был долгий заход с опросами по качеству разных компонент сервиса, но люди часто тыкают в кнопки, если им не нравится сама новость, и получается очень шумно. Как и с любыми другими ошибками можно написать в поддержку, и это обычно работает.
aamonster
(к последнему абзацу) Я не имел в виду отправку разработчикам – скорее ручную проверку/правку, если многие помечают резюме как бредовое. Грубо говоря, очередь с приоритетами, нажатие кнопки "резюме не соответствует статье" повышает приоритет, топ 50 из очереди каждый день проверяет модератор.
Takagi Автор
Концепт красивый, но в варианте быстрой постмодерации действительно есть вот эта проблема:
Плюс не только новость уйдёт, но и сама выжимка может за это время исправиться/испортиться. Короче сложно с модерацией.
Остаются системные изменения алгоритма. Условно, взяли пачку жалоб за месяц; подкрутили гиперпараметры; посмотрели, сколько жалоб исправлено и не сломалось ли в остальных местах. Вот так это сейчас и работает.
aamonster
Ладно, всё равно живых журналистов с заголовком "конец Путина в устах Березовского" алгоритм вряд ли переплюнет)