Каково состояние дел в извлечении контента HTML? - PullRequest
17 голосов
/ 26 декабря 2009

Существует много научных работ по извлечению контента HTML, например, Gupta & Kaiser (2005) Извлечение контента с доступных веб-страниц , и некоторые признаки интереса здесь, например, one , два и три , но я не совсем понимаю, насколько хорошо практика последнего отражает идеи первого. Какова лучшая практика?

Указатели на хорошие (в частности, с открытым исходным кодом) реализации и хорошие научные обзоры реализаций - это то, что я ищу.

Постскриптум к первому : Если быть точным, то вид опроса, который мне нужен, будет документом (опубликованным, неопубликованным и т. Д.), В котором обсуждаются как критерии из научной литературы, так и ряд существующих реализации, и анализирует, насколько неудачными являются реализации с точки зрения критериев. И действительно, сообщение для списка рассылки тоже подойдет мне.

Постскриптум второй Для ясности, после ответа Питера Роуэлла, который я принял, мы можем видеть, что этот вопрос приводит к двум подвопросам: (i) решенная проблема очистки неконформного HTML , для которого Beautiful Soup является наиболее рекомендуемым решением, и (ii) нерешенная проблема или отделение крема (в основном от шаблонов сайта и рекламных материалов) от мяса (контент, который люди, которые думают, что страница может быть интересна, на самом деле находят релевантный. Для того, чтобы соответствовать уровню техники, новые ответы должны явно касаться проблемы с мясом.

Ответы [ 8 ]

18 голосов
/ 26 декабря 2009

Извлечение может означать разные вещи для разных людей. Одно дело - иметь дело со всем искаженным HTML, и Beautiful Soup - явный победитель в этом отделе. Но Б.С. не скажет вам, что такое гадость и что такое мясо.

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

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

Трудно отделить мясо от мяса. И (читать между строк вашего вопроса) даже после того, как это масло удалено, без тщательно примененной семантической разметки крайне трудно определить «авторский замысел» статьи. Вывести мясо с сайта, подобного citeseer (аккуратно и предсказуемо с очень высоким отношением сигнал / шум), на 2 или 3 порядка проще, чем при работе со случайным веб-контентом.

Кстати, если вы имеете дело с более длинными документами, вас может особенно заинтересовать работа, проделанная Марти Херст (сейчас профессор в Калифорнийском университете в Беркли). Ее кандидатская диссертация и другие работы по обнаружению подтем в больших документах дали мне глубокое понимание создания чего-то похожего в небольших документах (с которыми, на удивление, может быть сложнее иметь дело). Но вы можете сделать это только после того, как избавитесь от промаха.


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

В 80-х и 90-х годах нашими клиентами были в основном правительственные учреждения, чьи глаза были больше, чем их бюджеты, и чьи мечты делали Диснейленд серым. Они собирали все, что могли, и затем искали технологию «серебряной пули», которая каким-то образом ( гигантская ручная волна ) извлекала «смысл» документа. Правильно. Они нашли нас, потому что мы были этой странной маленькой компанией, которая проводила «поиск по подобию контента» в 1986 году. Мы дали им пару демонстраций (настоящих, а не фальшивых), которые взволновали их.

Одна из вещей, которые мы уже знали (и им потребовалось много времени, чтобы поверить нам), заключалась в том, что каждая коллекция отличается от других и нуждается в собственном специальном сканере для устранения этих различий. Например, если все, что вы делаете - это жонглируете газетными историями, жизнь довольно легка. Заголовок в основном рассказывает вам что-то интересное, и история написана в стиле пирамиды - первый или два абзаца содержат в себе суть кто / что / где / когда, а затем следующие пункты раскрывают эту тему. Как я уже сказал, это легко.

Как насчет журнальных статей? О Боже, не заводи меня! Названия почти всегда бессмысленны, и структура меняется от одного магазина к другому, и даже от одного раздела к другому. Возьмите копию Wired и копию Atlantic Monthly. Взгляните на основную статью и постарайтесь выяснить значимый 1 абзац абзаца о статье. Теперь попробуйте описать, как программа может выполнить то же самое. Применяется ли один и тот же набор правил ко всем статьям? Даже статьи из того же журнала? Нет, не делают.

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

Как ни странно, главная причина того, что Google столь же успешен, как и он (с точки зрения поисковой системы), заключается в том, что они придают большое значение словам в ссылке и вокруг ссылки с другого сайта . Этот текст ссылки представляет собой своего рода мини-сводку , сделанную человеком сайта / страницы, на которую он ссылается, именно то, что вы хотите, когда ищете. И это работает почти во всех жанрах / стилях размещения информации. Это позитивно блестящее понимание, и мне бы хотелось, чтобы оно у меня было. Но это не принесло бы пользы моим клиентам, потому что не было никаких ссылок от вчерашних выпусков московских телепередач на какое-то случайное телетайпное сообщение, которое они захватили, или на какую-то ужасную версию OCR египетской газеты.

/ мини-декламация-и-трип-вниз памяти полоса

14 голосов
/ 26 апреля 2012

Одно слово: котел.

Для новостного домена в репрезентативном корпусе мы сейчас находимся на 98% / 99% точности извлечения (в среднем / медиане)

Также совершенно не зависит от языка (сегодня я узнал, что это работает и для непальцев).

Отказ от ответственности: я автор этой работы.

6 голосов
/ 21 декабря 2010

Вы видели котельную трубу ? Нашел упомянутое в похожем вопросе.

5 голосов
/ 20 декабря 2010

я сталкивался http://www.keyvan.net/2010/08/php-readability/

В прошлом году я портировал удобочитаемость Arc90 использовать в проекте Five Filters. Прошло уже больше года и Читаемость значительно улучшилась - благодаря Крису Дэри и остальным команда на Arc90.

Как часть обновления для полнотекстового RSS сервис я начал портировать более последняя версия (1.6.2) для PHP и код сейчас на сайте.

Для тех, кто не знаком, удобочитаемость был создан для использования в качестве аддона браузера (букмарклет). Одним щелчком мыши превращает веб-страницы для удобного чтения и убирает беспорядок. Apple недавно включил его в Safari Читатель.

Это также очень удобно для контента добыча, вот почему я хотел в первую очередь перенести его на PHP.

3 голосов
/ 08 мая 2011

есть несколько инструментов с открытым исходным кодом, которые выполняют похожие задачи извлечения статей. https://github.com/jiminoc/goose, который был открытым исходным кодом Gravity.com

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

2 голосов
/ 26 июля 2011

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

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

Чтобы ранжировать статьи, даже используя простейшую метрику длины статьи, вы должны быть в состоянии извлечь контент из разметки. Экзотическая разметка и скрипты, которые доминируют в веб-контенте в наши дни, ломают большинство пакетов с открытым исходным кодом, таких как Beautiful Soup, применительно к большим объемам, характерным для Google и подобных источников. Я обнаружил, что 30% или более разрабатываемых статей нарушают эти пакеты, как правило. Это заставило нас переориентироваться на разработку интеллектуальных синтаксических анализаторов очень низкого уровня, чтобы отделить необработанный текст от разметки и сценариев. Чем более точен ваш анализ (то есть разделение контента), тем более интеллектуальными (и сделанными вручную) вашими инструментами должны быть. Чтобы сделать вещи еще более интересными, у вас есть движущаяся цель, поскольку веб-разработка продолжает изменяться и изменяться с развитием новых подходов к написанию сценариев, разметки и расширений языка. Это способствует доставке информации на основе услуг, а не «сжатым» приложениям.

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

2 голосов
/ 26 декабря 2009

Beautiful Soup - надежный анализатор HTML, написанный на Python.

Он изящно обрабатывает HTML с плохой разметкой, а также хорошо спроектирован как библиотека Python, поддерживая генераторы для итерации и поиска, точечные обозначения для дочернего доступа (например, access <foo><bar/></foo>' using doc.foo.bar`) и бесшовные юникода.

0 голосов
/ 16 августа 2011

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

...