Инженер -программист из Нью -Йорка настолько сыт по горло неактуальными результатами и SEO -спамом в поисковых системах, что он решил создать лучшую. Два месяца спустя у него есть демонстрационная поисковая система. Вот как он это сделал, и четыре важных понимания того, что он чувствует, являются препятствиями для создания высококачественной поисковой системы.
Одним из мотивов создания новой поисковой системы стало восприятие того, что основные поисковые системы содержали все большее количество SEO -спама. Через два месяца инженер -программист написал об их создании:
«Что здорово, так это сопоставимое отсутствие SEO -спама».
Содержание
Нейронные вторжения
Инженер -программист, Уилсон Лин, решил, что лучшим подходом будут нейронные встроены. Он создал небольшой тест, чтобы подтвердить подход, и отметил, что подход встраивания был успешным.
Контент для подъема
Следующим этапом было то, как обработать данные, как они должны быть разделены на блоки параграфов или предложений? Он решил, что уровень предложения был самым детальным уровнем, который имел смысл, потому что он позволил определить наиболее релевантный ответ в предложении, а также позволил создать более крупные встроенные подразделения уровня для контекста и семантическую когерентность.
Но у него все еще были проблемы с выявлением контекста с косвенными ссылками, в которых использовались такие слова, как «это» или «The», поэтому он сделал дополнительный шаг, чтобы иметь возможность лучше понять контекст:
«Я обучил модель классификатора дистильберта, которая займет предложение и предыдущие предложения, и пометил, от какой (если таковой имеется) это зависит от того, чтобы сохранить значение. Следовательно, при внедрении заявления я бы следовал« цепочке », чтобы гарантировать, что все иждивенцы также предоставляются в контексте.
Это также имело выгоду от маркировки предложений, которые никогда не должны соответствовать, потому что они не были «листовыми» предложениями сами по себе ».
Определение основного содержания
Задача ползания заключалась в разработке способа игнорировать неконтентные части веб-страницы, чтобы указать то, что Google называет основным контентом (MC). Что сделало это сложным, так это то, что все веб -сайты используют разные разметки, чтобы сигнализировать о частях веб -страницы, и, хотя он не упомянул об этом, не все веб -сайты используют семантический HTML, что облегчит сканеры, где находится основной контент.
Таким образом, он в основном полагался на теги HTML, такие как тег абзаца
Чтобы определить, какие части веб -страницы содержали содержание, а какие — нет.
Это список тегов HTML, на которые он полагался, чтобы определить основной контент:
- Blockquote — цитата
- DL — список описаний (список описаний или определений)
- OL — заказанный список (например, пронумерованный список)
- P — элемент абзаца
- Предварительный текст
- Таблица — элемент для табличных данных
- UL — неупорядоченный список (например, пули)
Проблемы с ползанием
Ползание было еще одной частью, которая возникла с множеством проблем для решения. Например, он обнаружил, к своему удивлению, что разрешение DNS было довольно частой точкой отказа. Тип URL был еще одной проблемой, когда ему пришлось блокировать любой URL -адрес от ползания, который не использовал протокол HTTPS.
Это были некоторые из проблем:
«У них должен быть https: протокол, а не FTP:, данные:, JavaScript:, и т. Д.
У них должно быть действительное Etld и имя хоста, и не могут иметь порты, имена пользователей или пароли.
Каноникализация сделана для дедупликации. Все компоненты имеют процент декодированы, а затем повторно кодируются с минимальным согласованным charset. Параметры запроса сбрасываются или отсортированы. Происхождение в более низком уровне.
Некоторые URL -адреса очень длинные, и вы можете столкнуться с редкими пределами, такими как заголовки HTTP и размеры страниц индекса базы данных.
У некоторых URL также есть странные персонажи, которые, как вы не думаете, будут в URL, но будут отклонены вниз по течению таких систем, как PostgreSQL и SQS ».
Хранилище
Сначала Уилсон выбрал Oracle Cloud из -за низкой стоимости передачи данных (выходные затраты).
Он объяснил:
«Первоначально я выбрал Oracle Cloud для инфрационных потребностей из -за их очень низких расходов по выходу с 10 ТБ бесплатно в месяц. Поскольку я хранил терабайты данных, это было хорошим уверенностью в том, что, если мне когда -нибудь нужно было перемещать или экспортировать данные (например, обработка, резервные копии), у меня не было бы дыры в моем обозревании. Их компонент был также далеким, чем другой, хотя все еще не было подходящим.
Но облачное решение Oracle сталкивалось с проблемами масштабирования. Таким образом, он перенес проект в PostgreSQL, столкнулся с другим набором технических проблем и в конечном итоге приземлился на RockSDB, который работал хорошо.
Он объяснил:
«Я выбрал фиксированный набор из 64 осколков RockSDB, который упрощал операции и маршрутизацию клиента, одновременно обеспечивая достаточную дистрибутив для обозримого будущего.
… На своем пике эта система могла пить 200 тыс. В секунду в секунду у тысяч клиентов (скаулеры, анализаторы, векторизаторы). Каждая веб -страница состояла не только из необработанного HTML, но и нормализованных данных, контекстуализированных кусков, сотен высокомерных встроений и множества метаданных ».
Графический процессор
Уилсон использовал вывод на GPU с помощью GPU для создания семантических векторных встроений из ползал веб-контента с использованием моделей трансформаторов. Первоначально он использовал встроенные внедорожники через API, но это стало дорогим, поскольку проект масштабировался. Затем он переключился на самостоятельное решение для вывода, используя графические процессоры от компании под названием Runpod.
Он объяснил:
«В поисках наиболее экономически эффективного масштабируемого решения я обнаружил Runpod, который предлагает графические процессоры с высокой производительностью на доллар, такие как RTX 4090 с гораздо более дешевыми показателями в час, чем AWS и лямбда. Они работали из DC уровня 3 со стабильной быстрой сетью и большим количеством надежных компонентов».
Отсутствие спама SEO
Инженер -программист утверждал, что в его поисковой системе было меньше поискового спама, и использовал пример запроса «лучшие блоги программирования», чтобы проиллюстрировать его точку зрения. Он также указал, что его поисковая система может понять сложные запросы и привлек пример ввода всего абзаца контента и обнаружения интересных статей о темах в абзаце.
Четыре вывода
Уилсон перечислил много открытий, но вот четыре, которые могут представлять интерес для цифровых маркетологов и издателей, заинтересованных в этом путешествии по созданию поисковой системы:
1. Размер индекса важен
Одним из наиболее важных выводов, которые Уилсон учился на двух месяцах построения поисковой системы, является то, что размер индекса поиска важен, потому что, по его словам, «покрытие определяет качество». Это
2. Ползание и фильтрация — самые сложные проблемы
Хотя ползание как можно больше контента важно для всплеска полезного контента, Уилсон также узнал, что фильтрация низкокачественного контента было трудным, потому что это требовало уравновешивания необходимости количества против бессмысленности ползания, казалось бы, бесконечной паутины бесполезного или нежелательного контента. Он обнаружил, что способ отфильтровать бесполезный контент был необходим.
Это на самом деле проблема, которую Сергей Брин и Ларри Пейдж решены с рангом страницы. Страница моделировала поведение пользователя, выбор и голоса людей, которые проверяют веб -страницы по ссылкам. Хотя звание страницы почти 30 лет, базовая интуиция остается настолько актуальной сегодня, что поисковая система ИИ с недоумением использует модифицированную версию для своей собственной поисковой системы.
3. Ограничения мелких поисковых систем
Еще один вывод, который он обнаружил, заключается в том, что существуют ограничения для того, насколько успешной может быть небольшая независимая поисковая система. Уилсон назвал неспособность ползти всей Интернета в качестве ограничения, которое создает пробелы в освещении.
4. Судить доверие и подлинность в масштабе сложны
Автоматическое определение оригинальности, точности и качества по неструктурированным данным нетривиально
Уилсон пишет:
«Определение подлинности, доверия, оригинальности, точности и качества автоматически не является тривиальным… если бы я начал все сработать, я бы сначала уделял больше внимания исследованию и разработке этого аспекта.
Печально, поисковые системы используют тысячи сигналов на рейтинге и фильтрации страниц, но я считаю, что новые подходы, основанные на трансформаторах, в отношении оценки контента и анализа связей должны быть проще, экономически эффективными и более точными ».
Заинтересованы в поисковой системе? Вы можете найти это здесь И вы можете прочитать, как полные технические детали того, как он это сделал здесьПолем
Показанное изображение от Shutterstock/Red Vector
