Об особенностях направленного сбора информации

Я ранее не раз поднимал вопрос о направленном индексировании здесь: http://ivan.begtin.name/2008/10/14/направленное-индексирование-и-верти/ и здесь http://ivan.begtin.name/2009/04/08/информационная-архитектура-наоборот/

В общем-то это именно та задача которой в разных формах я в последнее время сталкиваюсь постоянно,

Предположим есть группа сайтов с которых необхдимо собрать некую информацию. К примеру, пройтись по сайтам всех периодических печатных и собрать с них: код ISIN, ФИО главного редактора, адрес редакции и реквизитов ИНН/КПП/ОГРН если они доступны. Например, это может быть нужно для задачи обогащения информации — составления полного списка сайтов и сопоставления его с базой номеров ISIN.

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

А теперь поговорим о решении технологическом. Технологический подход заключается в том чтобы поиск и обход необходимых сайтов осуществляла программа/робот, а не человек. Также программа должна автоматически найти всю нужную информацию и заполнить необходимые поля в таблице для данного объекта анализа. Технологическое решение заведомо проигрывает решению задачи человеком, если только число сайтов идёт не десятки/сотни, а на тысячи. Но вот если число сайтов исчисляется тысячами, то тут решение основанное на людях уже не подходит.

Технологическое же решение состоит из решения следующих подзадач:

1. Определить носитель информации — искомый сайт

2. Найти на сайте контейнер

3. Определить форму контейнера

4. Разобрать контейнер и извлечь из него необходимые данные

Подробнее по каждой подзадаче:

1. Определить носитель информации

Прежде чем информацию извлечь необходимо найти сайт где она присутствует. И здесь изначальная постановка задачи может варьироваться в рамках одного из 3-х случаев:

  • сайт известен заранее, например, если в начальном наборе данных он присутствует
  • сайт изначально неизвестен, но есть ключевая текстовая информация (например, название организации или информационного продукта)
  • сайт изначально неизвестен как и текстовое описание. Есть лишь ряд признаков определения таких сайтов из общей группы.

В первом случае всё очень просто. Искать сайт ненужно, он заранее известен.

Во втором случае задача сводится в сопоставлению известного текста с искомым сайтом. Здесь помогают каталоги сайтов и API поисковых систем.

В третьем случае ситуация наиболее сложная — необходимо перебрать все ресурсы обладающие необходимыми признаками. В некоторых случаях могут помочь поисковые машины, но чаще это задача по анализа сайтов по списку в поиске искомых.

2. Найти на сайте контейнер

Контейнер — это суть веб-страница или файл содержащий необходимую информацию. Иногда этих страниц больше чем одна. Поиск контейнера суть локализация наиболее вероятных участков  в общем массиве информации где может находится искомое. Главная задача его поиска в том чтобы далее анализировать не весь сайт, а только те участки где наибольшая вероятость найти нужную информацию

3. Определить форму контейнера

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

4. Разобрать контейнер и извлечь из него данные

Финальная часть когда контейнер найден извлечь из него информацию. Осуществляется это HTML парсером или разбором найденного файла — в зависимости от ситуации.

А теперь собственно нюансы реализации. Главное то что практически все эти задачи дробятся ещё более простым:

  • для того чтобы найти контейнер информации есть два основных подходов: определение контейнера по его типу и по ключевым меткам. Оба этих случая требуют понимания навигационной структуры сайта — где главная страница, где страница описания, страница контактов и так далее. Определение навигационной структуры сводится к двум алгоритмам:
    • определения навигационных меню сайта — главного и вспомогательных
    • классификация внутренних ссылок сайта
  • в свою очередь вопрос классификации внутренних ссылок требует понимания их структурной модели. Ответов на вопросы: используются ли человекочитаемые ссылки, каков уровень вложенности, как навигацию где страницы подгружаются через GET запросы и так далее. В результате алгоритм классификации внутренних ссылок работает гораздо эффективнее при определении этой структурной модели. Определить её возможно как динамически, накоплением базы внутренних ссылок сайта, так и определением CMS сайта.
  • определение формы контейнера упирается также в две подзадачи:
    • локализация значимого участка страницы — блока в HTML где содержатся искомые данные
    • определение формы представления данных в этом блоке.
  • локализация значимого участка может быть осуществлена несколькими способами: по ключевым навигационным и стилевым меткам в разметке страницы, по выявлению значащего блока страницы путём последовательного сравнения и анализа нескольких других страниц сайта и определение блоков с изменяющимся содержимым и по ключевым меткам в тексте, например, поиском по ключевым словам и регулярным выражениям в тех случаях когда известна ключевая информация о метках.
  • определение формы представления данных это то что уже необходимо превратить из неструктурированного блока информации в структурированное описание. Я именно про это писал ранее неоднократно про то есть конечное число способов представления информации и вполне можно их определять как в контексте, так и вне его. Неполный перечень форм это: таблица, несколько таблиц, различные одностраничные списки,  многостраничные списки, неформатированный текст.

Зачем всё это нужно?

Главная причина в том что подавляющее число вертикальных поисковиков по форумам, объявлениям, вакансиям полноценно работают только в условиях доступности машиночитаемой информации или ограниченно числа больших источников для которых можно написать и поддерживать парсеры.  А вот проблема сбора структурированной информации из тысяч и десятков тысяч источников пока не решена.

Ну и могу сказать что решением как раз этой задачи я и занимаюсь.

About This Author

  • Санитар

    Хе-хе… http://newsroll.pcmag.ru/ — примерно 4 тыс. сайтов, откуда берется информация типа «только текст и заголовок новости» (скоро будет дата, атрибуты и еще всякое), причем, _без знания формата страницы_. Никаких сигнатур, даже в общем-то и правил полторы штуки. И решается задачка достаточно тривиально, если подойти с правильной стороны.

    • http://ivan.begtin.name Ivan Begtin

      И зачем же там формат страницы ежели там RSS/Atom используется?

      • Санитар

        Там нет RSS. RSS, как показал первый же обход базы ИТ-сайтов, есть примерно на 15%. Корректный — на 10%. Вся прелесть именно в отсутствии RSS.

        Вот на blogroll.pcmag.ru да, там на RSS, поскольку у блогоплатформ он обычно есть.

        А вот мелкие товарищи из регионов этого слова и не знают часто (а когда знают, то лучше бы не знали 8).

        • http://ivan.begtin.name Ivan Begtin

          Весьма интересно. У меня есть схожая штука — http://www.skyur.ru где решалась та же задача, но с полным восстановлением новости и алгоритмы довольно ресурсоёмкие так что тема знакомая.
          А можно ли почитать где-нибудь подробности по Вашему решению или может расскажете? Интересно. сколько сайтов проверялось, из скольки удаётся извлечь информацию, какие данные извлекаются и так далее.

          • Санитар

            Немного тут http://www.pcmag.ru/club/user/119/blog/504/

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

            ее месяц—другой будет собирать статистику, потом тюнинг, причесать дизайн и видимо пойдет в дело 8)

  • http://catismad.com/ madcat

    А я занимаюсь созданием подобного парсера для уточнения и расширения данных о контрагентах (в том числе потенциальных) внутри CRM-системы.

    • http://ivan.begtin.name Ivan Begtin

      И как, есть успехи?

      • https://www.testlab2.com madcat

        Пока на этапе проектирования и тестовых набросков кода.
        Я отнюдь не разработчик поэтому даже простые вещи занимают у меня неприлично много времени :)

Яндекс.Метрика