Направленное индексирование и вертикальные поиски: специфика и особенности

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

Ранее в блоге я уже публиковал свои рассуждения на эту тему сейчас же остановлюсь на особенностях построения вертикальных поисковых систем и сфокусированного поиска.

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

Например, предположим есть поисковая система по закупкам. Её внешний интерфейс: поисковые возможности, навигация, иные средства подачи информации, всё это слабо зависит от того как именно в неё попадают данные.

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

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

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

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

Итого во всех трёх частях любой подобной системы есть своё пространство для инноваций и технологического развития. Причё развития независимого от остальных. А при некоторой зрелости этих инноваций они могут обратится и в коммеческую ценность конечного решения.

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

Плюс есть ещё ряд специфичных особенностей в оценке соответствия собираемых данных шаблонам, критериев оценки качества неструктурированных данных и так далее.

P.S.

Кстати, кто знает куда пропал Рамблер.бета? Ищу объект для критики, а он исчез куда-то, обидно даже.

About This Author

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