ivbeg

Сегодня обнаружил интересное явление. Оказывается Гугл научился автоматически индексировать PDF файлы содержащие отсканированные страницы документов. Соответственно эти документы теперь находятся через поиск.

Например, вот такой документ МинЭкономРазвития (ссылка на документ со сканами страниц) можно найти через поиск – например, вот так и щелкнув на ссылку “просмотреть” переходим в Google Docs где ещё одним щелчком на “Обычный формат HTML” документ возвращается в виде текста.

В общем, Google нашли себе ещё один большой срез данных. Осталось лишь дождаться когда поисковик начнет заглядывать в архивы, распознавать текст и объекты на картинках и так далее.

Originally published at Иван Бегтин. You can comment here or there.

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

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

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

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

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

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

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

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

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Прежде чем продолжить рассуждения, а что же такое данные с нечеткой структурой? Начну с примера.

При преобразовании HTML в RSS, как, например, это происходит в Скиуре, очень часта ситуация когда структура данных меняется. Это может быть из-за того что немного подкрутили верстку или, к примеру, у новости появилась метка которая при обучении на данных сайта не встречалась, но была с самого начала предусмотрена, например, “новое” или ещё что-либо не являющееся сменой CMS или реорганизацией структуры сайта, но затрагивающее HTML структуру ленты новостей.

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

• более долгий процесс извлечения структурных блоков;
• невозможность ручной корректировки шаблона распознавания в виду его отсутствия.

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

В случае новостной информации - это довольно просто и даже очень просто, поскольку структура транслируемых новостей давно уже определена в спецификациях RSS/ATOM, и то при распознавании достаточно 10% от специфицированных полей.  Кроме того отслеживание структурных аномалий для частного случая - это однократная и решаемая задача. Поиск решения для новостной информации закодированной в HTML у меня занял пару месяцев - в основном на анализ и систематизацию структуры данных в источниках. 

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

К вопросу о том зачем всё это нужно? Это нужно, поскольку сейчас процесс организации данных в Linked Data и иных связанных машиночитаемых формах - весьма долгосрочен. В каждом случае - это связано с долгим ожиданием когда владелец/контролёр источника данных решит представлять его в более удобной форме. При том что есть множество энтузиастов которые могут оцифровать тот или иной срез данных - как, например, статистические данные США или России, в машиночитаемую форму - тем не менее систематизация источников данных позволит обеспечить доступность данных на потоковой основе. 

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

Всё это к вопрос о том как лично я вижу data.gov.ru  примерно через пару лет, разумеется, в случае его появления.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Моё личное мнение на тему сможет ли Google выдавить Яндекс с места лидируещего поисковика в России или нет заключается в том что решение кроется не только в техническое конкуренции, но и целенаправленном лоббировании своих сервисов на государственном уровне. Благо есть значительное число онлайн сервисов которые государству нужны сейчас или будут нужны далее. Пример того же mail.ru который запустил на школьном портале свой edu.gogo.ru показателен. При том что сам портал был крив как и поиск по началу, но смысл в том что медиа-компаниям а ля Google, Yandex, Rambler, Mail.ru есть что предложить государству, только делают они эти предложения пока довольно слабо.  А смысл то не в том чтобы ждать пока чиновники задумаются о новых ресурсах, а в целенаправленном лобби на их создание.

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

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

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

Например, лично я считаю что рассматривая регулярные выражения с целью их индексирования необходимо забыть про DFA и NFA и не вспоминать столь долго сколь это только возможно.

Для анализа должно быть достаточно развёртывания регулярных выражений как дерева в соответствии с их написанием и последовательное построение “шаблонов шаблонов”, которые, как окажется, будут состоять из вполне измеримых “микроблоков правил”. Причём каждый из этих микроблоков будет обладать собственным набором метрик. Итоговое дерево выражения будет состоять из ветвей непосредственно правил подвергнутых группировке и кластеризации и рассчитанных ветвей метрик для каждого. При этом несмотря на то что хранение этих метрик может оказаться накладным процессом, тем не менее эти объёмы будут несравнимо меньше чем объёмы “распакованных” NFA.

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

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

На самом деле жаль что её так никто и не решил. В моём понимании моделирование алгоритмов анализа дерева HTML и прочих полуструктурированных данных куда увлекательнее чем моделирование алгоритмов анализа деревьев RE. Но пока получается что эта нерешённая задача, тормозит решение остальных.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Социальные сети, Twitter, Evernote и так далее:

• TWHirl - удобное настольное ПО для работы с Twitter’ом изготовленный с помощью Adobe AIR. Бесплатный, удобный, англоязычный. У него есть и российский сайт - http://twhirl.ru, но пока его не пробовал.
• CEO/CIO/CTO Twitters list - большая подборка на Twitter Feeds различных CIO, CTO и CEO американских компаний. Поимённо приводить не буду, каждый найдёт кого-то интересного для чтения.
• Evernote Twitter Feed - лента сообщений о Evernote.
• Evernote as perfect GTD App - статья о  использовании Evernote как GTD
• TarPipe - онлайновый инструмент для множественной публикации сразу во многих сервисах. Между прочим, используют Couchdb внутри сервиса.

Information Retrieval:

• Deep Web Research 2009 - материалы по глубокому индексированию
• Webology.Ir - журнал по Information Retrieval
• Introduction to Information Retrieval - книга по IR онлайн
• Combine - сфокусированный краулер (индексатор) с открытым кодом
• MI Islita - ресурс по Information Extraction

Мои профили в Twitter, FriendFeed и других соц. сетях:

• http://ivan.begtin.name - первоисточник всех записей, стендалаун блог.
• http://ivbeg.livejournal.com - основное зеркало на Livejournal
• http://ibegtin.ya.ru - зеркало на Я.Беточке
• http://twitter.com/ibegtin - лента в Twitter, полностью англоязычная, о технологиях немного
• http://friendfeed.com/ivbeg - всё вместе во FriendFeed
  
• http://delicious.com/ibegtin - публично доступные букмарки для тех кто интересуется темами e-Gov, IR, работой со справочниками и так далее. По возможности всё детализировано по ключевым словам и по ним можно отслеживать новое тем кому это интересно.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Гугл опубликовали у себя в блоге 22 страничный PDF документ с рекомендациями по оптимизации сайтов под поисковые системы.

Нового там мало, основной акцент на правильной подачи собственного контента.

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

Кстати, многие из этих правил поддаются формализации и значительной автоматизации в рамках CMS систем.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

• Alipr - Automatic Photo Tagging and Visual Image Search
• Simplicity - Semantics-sensitive Integrated Matching for Picture LIbraries
• a-LIP - Automatic Linguistic Indexing of Pictures
• Tiltomo - поиск изображений по похожести
• Cydral - поисковик родом из франции (на английском)
• Gazopa - поисковик как венчурный проект Hitachi работающий в полузакрытом режиме.
• Vima Technology - предлагают продукты поиска Vima Search
• LTUTech - также предлагают продукты поиска и распознавания изображений
• TinEye - поиск разработки компании Idee которые кроме того поддерживают проекты визуального поиска в Idee Labs. Их же, кстати, используют в Digg для отслеживания дубликатов размещаемых изображений.

Отличие поисковиков по подобиям в том что они не могут сделать простой фильтр по пропорциям в отличии от фильтров дубликатов и в том что у них нет словарной базы.

Кстати, поиск похожих изображений это один из способов, правда как оказалось не сильно удачных, для выявления “взрослых картинок”.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Что меня удивляло и продолжает удивлять так это так это нерасторопность поисковых машин, за исключением Google,  в продвижении своих сервисов везде где только возможно.

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

Вот я и не могу понять что мешает поисковым машинам:

1. Спонсировать разработчиков open-source CMS для поддержки поиска по внешней системы “из коробки”.

2. Договариваться с разработчиками коммерческих CMS а ля 1С-Битрикс для поддержки внешнего поиска из коробки или же опционально.

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

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

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Относительно недавно, размышляя над антипаттернами юзабилити, там же я упоминал про такое явление как сдвиге идентификаторов элементов веб списках. Это довольно большая тема сама по себе и я раскрою её подробнее.

Вначале озвучу проблему: подавляющее число информационных систем никак не учитывают формы представления информации которую они предоставляют пользователям и не только им.

Рассмотрим несколько примеров.

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

Для того чтобы далее было проще описать ситуацию я введу термин LISA (Last In. Shift All) -построение списка элементов при котором любой новый элемент становится первым сдвигает номера остальных.

Предположим, у нас уже есть 100 опубликованных новостей, 10 страниц по 10 новостей на одной странице. Что произойдёт после того как мы добавим ещё одну новость? Появится 11 страница и полностью изменится содержимое всех остальных 10 поскольку добавленная новость сдвинет все предыдущие на одну позицию в отсортированном списке.

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

Также добавлю что список новостей может быть разным. Если в некоторых случаях это лишь списки дата/текст/ссылка на полное описание, то в других случаях ссылки могут и отсутствовать и тогда LISA списки не просто мешают поисковикам, они мешают и пользователям, поскольку становится бессмысленным сохранение ссылки на страницу списка в закладки, ибо новости с неё “уедут”. Подобные списки нарушают один из ключевых принципов находимости информации - уникальности ссылки на информационный объект и возможности быстрого возврата к нему.

Примеров таких списков более чем множество. Даже Вордпресс на котором работает мой блог нумерует страницы считая последнюю первой.

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

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

В своё время когда только-только появился Google Coop, признаться, я очень порадовался что такая штука стала доступна. У меня всегда было, да и есть, с десяток разных интересов и всегда был интерес находить нужную информацию максимально удобным и быстрым способом.

Собственно движимый этой целью я в своё время создал около 30 частных поисков в Google Coop. Начиная от поиска по ресурсам посвящённым QNX и виртуализации, заканчивая отдельными поисковиками по госзакупкам, региональным органам власти и так далее.

Но, надо сказать, что интерес интересом, но чем более пользуешься таким поиском тем более понимаешь его ограниченность. Например, один из наиболее существенных недостатков Google Coop в том что у него отсутствует полноценное API для управления. Его создатели целиком и  полностью уверены что если кто-либо захочет внести дополнительный сайт, то пусть он это делает через админский интерфейс.

Всё бы хорошо, но, есть и немало случаев когда уже есть каталоги сайтов по которым бы хотелось организовать поиск, не перевбивая их постоянно и не дублируя работу по ведению их в поисковики и у себя на сайте/системе. Собственно разработчики Coop’а мне тогда и не ответили на вопросы добавят ли они API и практически всем своим поисковикам в Coop’е я перестал уделять внимание.

Ну а Coop’овский поиск по закупкам переродился в полноценный поисковик “Енот Поискун”

Похожая ситуация была  с Flexum‘ом на который я попробовал перенести часть поисков - в частности поиск по госсайтам. Но, и тут оказалось тоже самое, API нет, и хотя в переписке с создателями они выразили интерес к добавлению API, но так дело и не продвинулось. Что меня, если честно, удивляет и вот почему.

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

И, причём, владельцам большинства подобных порталов, подозреваю что, было бы интересно предоставлять поиск не только по самому порталу, но и по ресурсам в их каталогах и вот вся загвоздка в том что ни Coop’ом, ни Flexum’ом, ни другими аналогичными сервисами они не будут пользоваться поскольку синхронизовывать информацию в каталоге, с сайтами в поиске придётся вручную.

Кстати, то что Яндекс остановился в развитии этого направления создав Yandex.XML и ничего более, лично я считаю большой ошибкой. Удержание доли рынка поиска можно осуществлять разными способами, например, распространяя влияние на тематические порталы как я это описал выше и стремясь к замене обычных поисковых механизмах на сайтах на свой на базе Yandex.XML, но с настройкой в 1-2 клика и на аналогичного типа частные поиски по тематическим срезам.

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

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Признаться отсутствие в сети поисковика по российским гос. сайтам меня всегда удивляло. например, у того же Гугла есть Google U.S. Government Search, а USA.gov предоставляет аналогичный поиск на базе технологий Live Search + VIvisimo.

Но для Рунета создание такого поиска имеет свои особенности и проблемы:

1. Проект может быть только государственным или некоммерческим. Максимум транляция рекламы в результатах поиска, но не более, да и то врядли.

2. В отличии от штатов домены госсайтов в РФ разбросаны по зонам .ru, .com, .info, но никак не находятся в .gov.ru

3. Нет более-менее сносного и полного каталога государственных сайтов. В разделах “Власть” в существующих каталогах, как правило, перемешаны самые разные политические сайты.

4. Суммарно гос.сайтов в РФ не менее 1000 основных и до 10 000 всего.

Что меня удивляет так это отчего ни Рамблер, ни Mail.ru такой поиск не запустят - хуже не будет, а польза может статься. Про Яндекс я не говорю, по моим наблюдениям они от тем связанных с государством предпочитают дистанцироваться.

Но, в любом случае, вначале потребуется подробный каталог гос. сайтов.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Рецепт удержания и привлечения аудитории в самом деле прост.

Необходимо вместо обычного ранжирования картинок применять “интеллектуальный подход”, а то есть:

1. Уметь отличать мужские поисковые запросы от женских.

2. Желательно уметь отличать возрастную группу ищущего.

3. Уметь выявлять картинки “интересного содержания”, но соответствующие данному запросу.

4. Подмешивать на первую страницу результатов не менее одной такой картинки, но не более 3-х. Не забыть подмешать и на 2-ю, подумать насчёт подмешивания в третью.

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

И пример, вдохновивший меня на эту мысль.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

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

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

Если где-то в самом появления этого интереса я думал и даже ходил на собеседования в несколько “поисковых гигантов”, то сейчас совершенно не жалею что не пошёл туда куда звали и не взяли туда куда не взяли. Работа в больших компаниях имеет свои плюсы и минусы, но по мне так интерес работать на кого-бы то ни было “за зарплату’ уже небольшой. Только если кризис станет перманентным и кушать будет нечего. При том что определённо небольшой интерес в повторении уже проделанной работы над алгоритмами выше для передачи её потенциальному работодателю “за бесплатно”.

И, конечно, стоит добавить что “поисковые технологии” для меня всё ещё серьёзное хобби, не более. Увлекательное, интересное, захватывающее, но хобби.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Оказывается Opera разрабатывают  Metadata Analysis and Mining Application что буквально один в один то чем я занимаюсь (исследую возможности).

У них там больший упор на структуру, у меня на её смысловой анализ, построение объектной карты и онтологии связей.

Например, меня мало интересует частота слов в скриптах сайтах или размеры файлов, зато мои алгоритмы могут распознавать порядка 40 CMS и расширяютсяп под большее число по совокупности признаков и отделять навигационные ссылки от смысловых и “проплаченных”.  Всяческая классификация сайтов - это отдельная, но связанная тема. Суммарно там очень много всего набирается сделать такой поисковик, в самом деле, не так уж сложно, особенно когда есть запас наработок по теме

Как бы то ни было, проект очень интересный, а для меня так особенно.

Моё мнение что создание такого поиска, а ещё правильнее, мета-базы веб страниц явной прибыли не принесёт, но определённо может помочь в создании проектов с коммерческими целями.

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

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

На Роеме проскочила любопытная тема о том как тестируют кандидатов в Яндексе.

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

Но эта же тема меня лично подтолкнула к размышлениям на иную тему. Шаблонность мышления - это не плохо, иногда это даже ощутимый плюс, особенно в том что касается работы, но она же несёт в себе серьёзную проблему того что решения “вне шаблонов” находятся с трудом.

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

Например, куда интереснее задачка и логика решения по тому как отличить некоммерческий веб сайт от коммерческого.

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

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

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

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

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

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

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

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

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

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Вдогонку к тому что я писал про ссылочные биржи, спам в Рунете и SEO - не стоит себя обманывать что спам-ссылки в контексте невозможно выявить. Сейчас не найду, но в мае я уже писал на тему ссылочного анализа где приводил цифры и результаты проверок. Всё возможно и упирается лишь в 3 пункта:

1. Отсутствием политических решений у поисковиков так как есть риски задеть добросовестных оптимизаторов.

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

3. Технологиями - для меня сомнительный тезис, но вполне допускаю что при отсутствии приоритетов именно в борьбе со спамом, то и развитию технологий много внимания не уделяется.

—

Чего определённо нехватает сервису Яндекс.Вебмастер - так это возможности подтверждения личных блогов на блогохостингах типа ЖЖ, Li.ru, blog.ru, ya.ru и так далее. Понятное дело что вставить туда тэг meta или загрузить файл в корень не получится, а вот увидеть статистику запросов по которым пользователи переходят было бы более чем интересно. Ау, в Яндексе, подумайте, ведь людям это реально нужно!

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Читая заметки про SEO, Ашмановскую рассылку про нынешнее обеление финансовой части Sape.ru и другие площадки “продажи ссылкок”, меня в происходящем удивляет лишь одно.

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

Ситуация схожая с ситуацией спама в электронной почте. Если с ним не бороться - он просто уничтожит среду в которой распространяется.

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

Вариантов решений тут масса - начиная от введения коэффициентов пессимизации веса ссылок с сайта, заканчивая TrustRank’ом и распространению зон доверия/недоверия.

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

Так что осталось недоумение, не более. Недоумение и понимание что необходимо формирование “зоны доверия”.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Спасибо, всем кто накидал ссылок и материалов по теме, в данной записи я опишу собранное.

Вот некоторые публикации:

• Wu, Manber “A Fast Algorithm For Multi-Pattern Searching” - описание алгоритма и его реализации в виде Agrep с построением NFA на базе регулярных выражений.
  
• Публикации Gonzalo Navaro и nrgrep - развитие алгоритма построения NFA на базе регулярных выражений, плюс учёт минимальной размерности строк подпадающих под шаблон.
• Parsing Techniques by Grune and Jacobs - описание алгоритма Томпсона на который ссылаются авторы выше.

Самые интересные - это публикации Navaro. Читая его я подтвердился в своих зарождающихся предположениях насчёт учёта минимальной длины строк подпадающей под данное регулярное выражение.

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

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

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

Ещё одна интересная тема - это оценка предсказуемости поступающих данных и выработка метрик оценки этой предсказуемости.

В любом можно говорить что решение у этой задачи есть, пусть даже и не самое простое.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.