Самое то смешное, что я слышу это от челика, который аппелирует такими терминами, как:
применительно к URI. ИМХО, это показатель профнепригодности - не отличать HTTP от HTML 😂
Проблема в том, что из-за некомпетентных людей, вроде вас, бросающихся терминами налево и направо, даже не понимая их смысла, но при этом имеющие наглость спорить когда им указывают на очевидную ошибку, страдает репутация сеошников как таковых)
А причем тут хопы, на которые вы ссылаетесь? Покурите модель стека TCP/IP. Хоп - это понятие, применимое только на уровне IP-протокола, когда речь идет о маршрутизации. Да и причем тут HTTP-метод, когда речь про ограничения на длину URI? Хоть POST или DELETE передавайте ;)
И в устаревшем еще в 2014 году RFC 2616, на который вы ссылаетесь, прямо сказано что никаких лимитов нет:
А если переводить процитированный фрагмент и то, что чуть выше него, смысл такой - веб-сервер может сам вводить дополнительные ограничения на длину, тогда при её превышении он должен вернуть статус 414. А дальше идет предостережение, мол некоторые старые клиенты (на практике - времён 90х) могут сами иметь ограничения на длину урла. Собственно, подтверждение моих слов)
В контексте этого вопроса разницы никакой, потому что старые реализации http-клиентов в большинстве случаев не поддерживали юникод, потому для них что байт, что символ - одно и то же.
Вернемся все-таки к сабжу. Разумеется, у поисковиков есть некий порог на длину URI, и если он превышается - индексатор такой урл пропустит. В качестве очевидного - если урл будет длиной в несколько мегабайт. Такое только экспериментально можно проверить.
Хопам нет дела до того, какие данные вы передаете в IP-пакетах, хоть HTTP/2 передавайте. Проблемы с длинными урлами могут быть только при использовании криво реализованных прокси-серверов, или таких же систем DPI, и только при использовании незащищенного http.
На канальном уровне есть некая максимальная длина передачи одного фрейма (MTU), на которую вы особо влиять не можете, т.к. это зависит от настроек устройств и используемой технологии, а на промежуточных узлах на MTU не может влиять даже ваш непосредственный провайдер. Если IP-пакет слишком большой, он просто фрагментируется на несколько фреймов, и собирается обратно на стороне принимающего.
Ограничение длины в 255 идет не на урл, а только на домен:
Отсрочка не по 54-ФЗ, а по ст. 2 ФЗ-129 от 6 июня 2019. С бланками строгой отчетности вот непонятки - типографские отменили, а автоматизированные уже попадают под ККТ. Похоже, что тоже не нужны.
Ну если будет все чисто в плане отсутствия сотрудников и налоговая не признает подрядные отношения трудовыми - тогда норм. Разве что обязательные взносы к пенсии можно вложить более удачно в случае самозанятых.
Если не хотите нарваться на крупные штрафы - обязательно. Технически - не обязательно интегрировать кассовый сервис с яндексом, можно отбивать чеки через сторонние API.
Бесплатных точно нет. Этот закон не предусматривает полностью программные решения (как например vECR в Словакии), поэтому и ценники соответствующие. Плюс необходимо платить по договору с ОФД.
Есть сервис Робочеки, который их будет отбивать за вас, выступая агентом.
Затраты на аренду онлайн-кассы примерно равны обязательным взносам за ИП. Если услуги оказываете лично вы, возможно выгоднее будет перейти на самозанятость, там нет ни взносов, ни требования использовать кассы.
Не претендую на "гуру", но пока этот список слов из ваших моделей выглядит очень бесполезно, применительно к SEO-копирайтингу. Гораздо лучшего эффекта можно добиться простым подсчетом пересечений каждого слова между различными документами из топа и дальнейшей ручной отбраковкой неподходящих слов.
Применение LSI в том виде, в котором оно у вас, навскидку, такое - можно определять неоднозначные запросы, попробуйте на примере топов по запросам в яндексе "цезарь" или "наполеон" разбить пространство прямой линией на два класса - назовем их условно "кулинария" и "история". Если получится, значит есть-таки полезный кейс у "настоящего" LSI.
Самый главный из них - что подразумевает большинство сеошников под LSI. То, что предлагается на практике, совершенно таковым не является. Это всё равно, что называть системник процессором.
https://moikrug.ru/alsafr вот тут подробная инфа из первых рук - он уже 9,5 лет уже как разработчик только в этом направлении, а сейчас еще и совмещает это с руководительской должностью.
Тут вопрос в том, что вы понимаете под этим. Если спеца, который непосредственно реализует (на C/C++) просчёт факторов ранжирования или хранение поискового индекса (что близко к специальности data engineer), то его в первую очередь интересует производительность, ресурсоемкость и отказоустойчивость поискового движка, а не влияние ранжирующих факторов факторов на качество выдачи. А вот руководитель такой службы вполне может играть роль data scientist, который формирует гипотезы и дает техзадание своим подчиненным, и он же в итоге принимает решение, какой алгоритм выкинуть в помойку, а какой выкатить в прод. Data scientist всегда ближе к разработчику. Уж точно, это не менеджер, который не разбирается в матчасти, а только рисует диаграммы Ганта и считает KPI.
Но источник всё равно более авторитетный, чем статьи сомнительных авторов из SEO комьюнити, называющих вещи не своими именами.
В видео упоминается Палех, и кроме того, на следующем же слайде, среди "работающих" методов идет DSSM, лежащий в основе как Палеха, так и Королева. Королёв, как известно, это почти Палех, только расширенный с тайтла+заголовков на весь текст документа, и вычисляемый теперь не в рантайме, а фоново при индексировании. Андромеда вообще никак не соотносится с текстовой релевантностью, это просто маркетинговое название для нескольких фич (значки для сайтов, быстрые ответы и т.п.). Если прослушать еще дальше - там будет как раз про выделение "значимых" для ранжирования слов, но не по LSI, а по поведенческим факторам (больший вес словам, которые присутствуют на страницах с лучшим CTR в выдаче - положительная обратная связь, по факту).
Поисковые алгоритмы - это не то, что делается и выкатывается за короткий срок - это могут быть годы экспериментов и поиска рабочего решения. Вот маркетинговые названия очередным алгоритмам могут придумать достаточно быстро - сегодня Королёв, завтра какой-нибудь Циолковский.
BM25 там употребляется в контексте того, что авторы всех этих чудо-алгоритмов в своих академических работах любят сравнивать с ним результаты, полученные этими алгоритмами. Т.е. типа "наша модель работает лучше, чем BM25, на столько-то процентов". Но на практике ничего из этого не используется в реальных системах. Тоже самое можно сказать про кучу простых ML-алгоритмов, таких как k-means, decision trees, svm - всё это хорошо для обучения начинающих DS, работает на специально отобранных датасетах, а стоит только попытаться сделать на базе этих методов что-то практическое - результат сильно разочарует.
Есть ряд очевидных ограничений, почему LSI в чистом виде не может применяться поисковиками.
Во-первых, необходимость жестко задавать количество тем - а это в масштабах поисковой системы попросту невозможно - темы практически безграничны и ежедневно появляются новые. Суть алгоритма LSI вкратце: исходно есть матрица слово-документ в масштабах корпуса, LSI её сжимает по количеству документов до жестко зашитого числа документов, которые обзывает темами. DSSM это тоже по сути сжатие с потерями, но оно сохраняет больше информации за счет наличия нелинейных связей. Связи, выдаваемые LSI, получаются всегда линейны. И никакой магии - LSI не в состоянии определить реальное количество тем в корпусе - можно лишь прогнать алгоритм с несколькими жестко заданными значениями и попытаться выбрать наилучшую модель исходя из каких-то метрик качества.
Во-вторых, в любом маломальски крупном тексте упоминается множество разных тем, даже в рамках одного абзаца. А ранжировать на соответствие запросу нужно целые документы.
И наконец, метод очень вычислительно тяжелый. Сложность пропорциональна квадрату количества документов в степени количества тем. Для масштаба веб-корпуса не применимо в принципе. Зато в различных публикациях на искусственных корпусах в десяток тыщ документов считаются и хвастают, как обгоняют по качеству bm25. Кроме того, авторы этих работ редко берут веб-корпус, обычно ограничиваются литературными документами. Особенность веб-корпусов - не всегда правильно с точки зрения языка строятся фразы, и не всегда можно правильно извлечь абзацы (пример - карточки товара, там нет абзацев как таковых), да еще и спамный контент может подпортить всю статистику.
Про RTFM посмешило, учитывая что поисковики не особо где разглашают внутренние детали реализации своих алгоритмов. Но совет дельный, если применять его к тем, кто употребляет аббревиатуру LSI не к месту :)
Говоря о понимании поисковиком смысла, надо сначала договориться об определениях. Навскидку, чтобы роботу понять смысл фразы "салоны красоты рядом", вычисленная модель LSI или даже DSSM для этого будет бесполезна - нужен переколдунщик, который оттригерится на слово "рядом" в запросе, возьмет регион выдачи, услугу и поищет организации в базе знаний, в том же яндекс.справочнике или на картах.
Да ладно? А вот тут один из разработчиков поиска утверждает, что LSI не применим на практике 🤣 https://youtu.be/QkUmCnDe3xI?t=1715
И LSI это уж точно не про "смысл" текста.
Этот сервис и по habr.com показывает, что "санкции обнаружены" 🤣 скрин: https://ibb.co/xfQrV5d
После закрытия тулбара тИЦа корректные данные по санкциям можно только в панели вебмастера увидеть.
Проблемы могут быть и у Google. Примерно с полгода назад у них был баг с деиндексированием страниц, о котором активно писали в буржунете. Баг официально признали, потом объявили, что исправили, но по факту не у всех всё восстановилось.
Видимо он про wordstat как источник данных для КК говорил, но тоже вышла неточность 😂
На самом деле, не все виды частотностей можно снять через "прогноз бюджета" в директе, с которым КК также работает. Например, там нет оператора квадратных скобок для фиксирования порядка слов в запросе и фильтрации показов на десктоп/мобилки, и еще имеются ограничения на количество слов и длину запроса. Но у wordstat другой минус - нельзя пробить больше одной фразы за один раз.
