Alexander snakers4

Для полноты повествования нужно осветить ряд вещей, о которых авторы вероятно немного постеснялись высказаться для "красивой истории":

• Зачем выкладывать чужой код, но не в виде форка, а виде отдельного репо с минимальными изменениями — честно говоря не совсем понятно;

  
  

• Скорость конструкции Такотрон + WaveGlow примерно в 100 — 1000 ниже (понятное дело на CPU) чем коммерчески рентабельно, да и вообще ради синтеза ставить GPU довольно непонятная для "бизнеса" затея;

  
  

• "Естественность" у оригинальных английских реализаций понятно на уровень выше, но английский как ни странно фонетически сложнее, но "секретный" соус естественно никто не раскрывает. Имеет место неограниченный доступ к compute и черри-пикинг со стороны Нвидии (они очень любят показывать примеры WaveGlow на оригинальной спектрограмме, а комбинацию с Tacotron засунуть в низ страницы);

  
  

• Также смотря на описанные планы:

  
  

Полноценный нормализатор текста для раскрытия чисел, аббревиатур и сокращений;

Не могу сказать про полноценность, но мы выкладывали уже такое https://github.com/snakers4/russian_stt_text_normalization

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

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

будет также не лишним, если вы представитесь и опишите свои аффилиации

ну собственно вы своим комментарием подтвердили две вещи:

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

И, простите мне мою необразованность, что такое «ad hominem»?

https://en.lmgtfy.app/#gsc.tab=1&gsc.q=ad%20hominem

А там есть виджеты для аудио? Ну, медиа плейер с кнопками какими-то, например?
Просто адопшен таковых на всех платформах довольно низкий как показывает практика

Насчет закрытых академических соревнований наверное бессмысленно ломать копья, пару лет назад довольно раскрученный товарищ из ОДС под ником ternaus довольно неплохо на эту тему срывал покровы — но tldr см GoodHarts Law. Тут я тоже довольно подробно про это писал, не вижу смысла повторяться.

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

Я открыто говорю про наши аффилиации и открыто описываю методологию тестирования. Верить или нет — ваше дело. Нормальной практикой на рынке считаются маркетинговые материалы в духе "все классно". Валидно критиковать или оставлять комментарии в духе ad hominem — тоже выбор каждого.

Но ведь в вашем последнем сравнении результаты ЦРТ не представлены.

Это довольно трудоемкий процесс, и как правило присутствует некая инерция, поэтому действовали по следующему принципу:

• Мы не говорили разработчикам систем, (i) что планируем снимать метрики (ii) в каких доменах будем это делать, чтобы метрики были "честными", т.к. в спиче все прекрасно "накручивается" =);

  
  

• Сначала сняли метрики в меру возможности по доступным нам системам (иногда приходилось это делать немного по-партизанки, но как правило мы просто покупали квоты) в соответствии с общей методологией (https://www.silero.ai/stt-quality-metrics/). Там где не указано название конкретной модели, мы показывали лучшие метрики, которые выдавали системы (для систем где много моделей). Там было некоторое мясо по датам тестов, но это можно дисконтировать т.к. не все системы меняли свои метрики потом;

  
  

• Потом выбрали системы, которые генерализуются — то есть более менее сносно работают "из коробки" без дополнительных настроек;

  
  

• Эти генерализующиеся системы мы оставили в финальном списке, который обновили тут — https://www.silero.ai/russian-stt-benchmarks-update2/ — рекурсивно можно пройти по более старым статьям;

  
  

• Все могло конечно поменяться, я свечку не держал. Я бы предположил что в методологии может быть небольшой bias из-за нормализации и некоего упрощения (lower, замена буквы ё на е), но мы тестили без таких штук, разница была всегда 1-2 пп WER;

  
  

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

Sad but true.

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

со своими моделями для микрофонного

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

Пост-процессинг тоже везде одинаковый. Нет накрутки на словарях, кастомных LM итд итп.

по части Open Source я общался недавно с Юрием

Юрий, к сожалению, за некоторые "заслуги" был исключен из авторов
Но это не первый раз, когда он общался насчет совместной наработки не ставя в известность других авторов, но к сожалению прошлого не вернуть)

насчет остального — пишите в личку в телегу

Вы тестировали VoiceNavigator или VoiceKey? Все основные вендоры за последние полгода показали очень хороший рост

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

https://www.silero.ai/russian-stt-benchmarks/
https://www.silero.ai/russian-stt-benchmarks-update1/
https://www.silero.ai/russian-stt-benchmarks-update2/

Будем рады сравнить со всеми и ваше решение для русского языка, если предоставите доступ или выложите модели!

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

мы пошли по пути подготовки отдельных моделей для разных доменов

как интересно

Абсолютно непригодна для сбора качественнго датасета Яндекс.Толока: добиться качественной работы с разметчиками Толоки не получится, нужна плотная работа с разметчиками.

меня лично в работе с ней останавливало другое — слово на букву "Я" и дарение результатов своей работы им же
плюс слухи, что мол пока не спустишь там 500к-1000к не научишься обходить местный хайв-майнд

а вы ее запускали? у меня руки не дошли

Мы начали делать свой ASR зимой 2019 года
недавно был опубликован датасет Open STT для русского языка

Зимой как раз мы опубликовали версию 1.0 Open STT.
Но если не изменяет память, к нам эта компания за лицензией на датасет к нам не обращалась.
Интересно.

Вообще мы уже не раз видели "коммерческие" компании, кто пытается продавать "свои" (на самом деле конечно академические оверфитнутые чекппойнты) решения. Начинаешь общаться — оказывается, что "они просто показывают их", а в продакшене "будут тренировать на данных заказчика".

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

Для английского, можете глянуть наши модели тут

PS
Их даже зафичерили на главной странице PyTorch и даже Сумит Чинтала лично поблагодарил

В меру своих возможностей постараюсь добавить немного критики и объективности к этому посту.

Новость. Недавно мы выложили свою нейросетевую библиотеку в Open Source. Всем, кому интересно пощупать, вот Github, а вот документация.
на нашем фреймворке можно найти в документации.

То есть для решения частной задачи (ASR), вы решили написать свой DL фреймворк?
Но при этом вы не включили туда такие критические вещи как CTC и LM?
Это странно.

Я не спорю (да и я много раз говорил, что описанные выше фреймворки скорее имеют минусы и "strings attached" которые перекрывают их плюсы с головой) что доступные решения имеют большие минусы, но написание DL фреймворка это задача на порядки более сложная чем решение и тренировка доменных моделей.

Еще глупый вопрос, а почему просто не взяли PyTorch?
В открытом репозитории 9 коммитов и документация весьма куцая.
Просто не до конца понимаю какая цель такого упражнения. Написать условный PyTorch это десятки миллионов долларов + по сути ему уже в районе 5 лет активной работы с коммьюнити.

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

Описание пути и боли по работе с данными тут ± похоже на правду.

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

В указанных тестах (я так понял, что на 2 доменах — звонки и записи с микрофона) — почему-то в топе всегда присутствует ЦРТ. По факту, когда мы делали подобные тесты на паре десятков доменов — модели ЦРТ очень плохо генерализовались при прочих равных. Может конечно они сильно выросли, но хз.

Почитать результаты наших тестов можно тут.

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

Таким образом у нас накопилась база в 1700+ часов.
Относительно недавно был опубликован датасет Open STT для русского языка, но перед использованием важно обратить внимание на происхождение данных в этом датасете + ограничения лицензии.

Странно, по ссылке всего 100+ часов. Это баг или фича?

1700+ часов.

Тут верно подмечено, что это нижняя грань плюс минус.
Но тут важно отметить, что это нижняя грань на один домен.

фонд РВК
Федерального проекта «Искусственный интеллект».
Нейросети Ашманова

Для объективности отмечу, что мы (silero.ai) являемся мы одними из немногих независимых вендоров STT на рынке. Является ли это плюсом или минусом при оценке непредвзятости нашего мнения — решайте сами.

Среди прочего можно упомянуть наиболее на наш взгляд интересные разработки

Позволю себе добавить еще вот эти две ссылки:

• https://www.silero.ai/tag/our-speech-to-text/
• https://github.com/snakers4/silero-models

Собирайте нетривиальный датасет (не просто common voice). Отдельно собирайте вал сеты
Можно будет добавить в список моделей но наверное без ЕЕ версии

50 в 2 раза быстрее чем 200
20 не сделали ещё
подробнее тут https://www.silero.ai/stt-system-speed-quantize-final/

Меньше места, быстрее, есть меньше compute?
Я до конца не разобрался — в современных реалиях хоть как-то коррелирует ли прунинг с продом

А квантизация — это продовая тема

Если вопрос о том поступаем ли мы также как раньше было модно репортить результаты на Imagenet (по 5 кропам) — то нет — всегда берется верхняя гипотеза, а не топ-N.

В остальном — wiki в репозитории и статья выше по идее содержат всю информацию.

Чтобы сделать такое надо решить 4 задачи

Детекция голоса (VAD) уже решена
Выделение голоса
Подавление шума
Распознавание

Все они решаются если сам спич пока нигде — то производные от него задачи ещё дальше

Но денойз не так сложно сделать, в скорых планах есть

Прунинг не делали ещё. Дальше планируем прунингом как раз и улучшением архитектуры.

Механизм расчета метрик тут аналогичен описанному в статье, которую вы нашли.

Для английского мы ещё нормализовали частые вещи типа that is и that's и так далее, тк нет унификации ращметки. Для немецкого пробовали без числительных тк результаты гугла не очень оказались — но разница была маленькая.

А насчёт лучших результатов — я довольно подробно расписывал в своих статьях на The Gradient все детали по этому поводу и какие там реально иетрики.

По сути к сожалению результаты премиум модели Google говорят что вы скорее всего стали жертвой маркетинга евангелистов / корпораций / академиков которым надо оправдать освоение бюджета. Sad but true. Tldr — оверфит на один датасет и общая генерализуемая модель — это разные фрукты.

Можете посмотреть прошлые сравнения. Если коротко — то мы сначала сравнивали все что можно, а потом оставили только системы которые хорошо работают из коробки на всем или генерализуются

Да

Так сделали же — https://www.silero.ai/tag/our-speech-to-text/

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

Когда RTX Voice появился, кажется оригинальный тред был этот
https://forums.guru3d.com/threads/nvidia-rtx-voice-works-without-rtx-gpu-heres-how.431781/

А кто-то влазил внутрь wpkg файла внутри папочки models?
Какая там архитектура модели?

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

Из нашего опыта в создании Open STT и нашей системы Silero могу сказать, что что-то из Калди можно выжать и на паре сотен часов на VoxForge. Да на более мелких языках даже наша гибридная модель будет показывать что-то, если правильно подобрать словари и вторичные языковые модели. Но!

Но реальные моменты тут будут такие:

• Скорее всего модель не будет генерализоваться как по вокабуляру, так и по голосам. По доменам скорее всего тоже, но это не нужно. Примеры выше явно были cherry-picked;
• Мы видели как примерно похожие модели подгоняют показывать "метрики" на конкретных доменах, например если взять языковую модель и вокабуляр ТОЛЬКО из слов своего датасета, это сразу докидывает 5-10 WER. Но когда люди скажут слова, которых не было в вокабуляре… ну вы поняли. Немного ситуацию упрощает то, что это фонемные модели, но постоянно искать ошибки и добавлять новые слова это муторно. Но с учетом поставновки задачи, вряд ли кто-то нормально снимает метрики;
• Скорее всего будут вопросы с поддержкой;

Это все конечно, если авторы говорят правду или правда прошла через пиар сито без искажения.

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

Утверждаю, что с калди на vox forge результата, годного для продакшен использования достичь очень трудно. Использование калди также очень тяжело оправдать с точки зрения поддержки и развития в будущем. Поэтому такие статьи можно и нужно воспринимать или как браваду / оголтелый пиар (обратите внимание, что каких-то метрик которые как-то можно сравнить с чем-то общеизвестным в статье нет). Тренировать свою STT систему в рамках нефтяной компании — это и есть как раз изобретение велосипеда.

Соответственно это или оно, или на самом деле используют другие датасеты или модели.

На российском рынке часто встречаются такие ситуации:

• Коммерческие компании строят все "с нуля сами" не имея соответствующей экспертизы, нанимают команды, тратят время, а в итоге получается как пресловутое"отечественное ПО";
• "Исследовательские" организации показывают "демо"-решения на базе систем и датасетов, на которые у них нет ни лицензий ни банальной технической экспертизы и понимания как оно работает;

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

Меня всегда радует, когда берется огромная стеклянная пушка (которая кстати не особо пошла в массы), чтобы забить микроскопический гвоздь. Да эмбеддинги это классная штука, но:

• Описанная выше задача решается тупо словарем (словарем, Карл!) или н-граммным поиском. Ну или комбинацией этих методов вместе с регулярками. Сетки и вектора оправданно тащить уже когда корпуса состоят из сотен тясяч или миллионов примеров;
• Даже если вектора это почему-то must-have (как недавно был перл в приватной беседе — мы готовы покупать работающее решение для решения реальной проблемы — ой, там нет нейросетей, тогда не готовы! верните нейросети), то как минимум не надо сразу брать starspace, а надо попробовать готовые вектора, ну или на крайний случай потыкать FastText. Как правило основной вопрос тут — чистка текста и кастомная токенизация. Как правило результаты со 100% метриками — это или плохие метрики, или неправильно поставленная задача;

1. Планируете ли вы выкладывать модели и датасеты в публичный доступ?
2. Какие у вашей системы метрики на различных валидационных выборках?
3. Сравнивали ли вы ваш multi-stage подход допустим с тем, чтобы делать так — классификация => вырезание ROI со словами (глобально не важно как это делать) => e2e сетка с CTC лоссом для распознавания конкретного слова? Почему так не делалили?
4. Я верно понял, что вся игра с "ручной" генерацией разметки из прописей сделана из-за того, что у вас попросту не было датасета с ручными паспортами?
5. Правильно ли я понимаю, что вследствие пунктов (1) и (4) — качество низкое (про него в статье нет ни слова!)?;
6. Оценивали ли качество каждого алгоритма в пайплайне? Классификация, детекция, нарезка на буквы, классификация? Мне кажется полный e2e тут не оправдан, но первые два и последние два этапа можно слить (CenterNet + UNet на фразы, вместо второго этапа — просто CTC сетка). Все таки оптимизировать 2 алгоритма лучше, чем 4. Хотя первый и четвертный тут очень простые.

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

А для всех доменов — писать общую либу токенизации это благие намерения.

Библиотеки старые, не развиваются.
Плохо поддерживают русский язык.
Работают только с чистым, специально подготовленным, текстом
Плохо поддерживают UTF-8. Например, SriLM с флагом tolower ломает кодировку.
Из списка немного выделяется KenLM. Регулярно поддерживается и не имеет проблем с UTF-8, но она также требовательна к качеству текста.

Можно глупый вопрос в лоб.
KenLM вроде работает с русским. Даже питоний враппер есть.
Да и никто не мешает просто все эти "проблемы" решить пре-процессингом на питоне без C++. Даже будет мало кода и код легко поддерживать.

Соответственно глупый вопрос — зачем еще одна библиотека?

https://github.com/anyks/alm/#training-using-your-own-features

А токены из нескольких букв?
Или нужно делать "замену алфавита"?

Requirements Python3

Может я пропустил что-то, а интерфейса для вызова на питоне нет?

https://github.com/anyks/alm/#build-on-linux-and-freebsd

А вы планируете поддерживать пакеты в apt / pip?
Это повысит аудиторию проекта раз в 10.

Посмотрев в статью и увидев «x% при обучении на librispeech» (или switchboard/fisher/chime) я уже что-то понимаю.

Там compute может отличаться на 2 порядка
Это делает такие сравнения даже вредными

Про compute и time2market никто не пишет, да, но это ведь инженерно-коммерческие вопросы, там еще огромная пачка переменных

В NLP и CV уже люди дошли, что таки писать все-таки надо про эти вещи
Хоть как-то

метод (гибрид/LAS/...) — сравниваем на распространенном в мире бенчмарке.

Правильно все нормировать по времени и по compute
В идеале по косту, но это сказка конечно уже

Из статей это не всегда очевидно. Придется импровизировать или переделывать. Это долго.

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

Хорошо сравнить именно методы, думаю, сейчас можно только на либриспиче

Но никто, почему-то, не сравнивает (буду рад ошибиться).
И не пишет обзорных статей, в т.ч. сравнивая compute и time-to-market ...

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

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

По-прежнему, калди just works и просто даёт приличный результат.

Тут сложно сравнивать яблоки с апельсинами, но на сайте Николая написано, что он мол 10 лет пилит свое решение — ну то есть оно явно уже "зрелое".

Но судя по тестам — решение довольно неплохо работает на доменах, на которых его тренировали, а вот с генерализацией беда. Но данные там явно брались из широкого числа доменов. То есть получается это проблема подхода в целом? Или дело в чем-то ином? Может Николай ответит.

В то же время, end2end методы, если их как следует накормить данными, позволяют получать такие же результаты, что гибриды HMM/NN (которые часто делают на калди). Ну, плюс-минус три копейки. Да и данные, чтобы ими накормить end2end'ы, сейчас у многих появляются, а не только у гугля с фейсбуком.

Ну, фишка в том, что если бездумно кормить e2e, то вряд ли что-то хорошее получится)
Там еще и часто пишут про 8 — 100 видеокарт.
Прямо e2e это наверное и правда про 100к часов, но генерализацией там тоже пахнуть не будет.

сложность сделать стриминг; сложность сделать персонализацию или адаптировать под тематику;

Почему? У нас проблема со стримингом состоит только в том, что его надо поддерживать, а если оно и так быстро работает ...

зависимость от длины записи;

Опять же почему?
Короткие записи немного грустят, но это логично — мало контекста.

Но и можно получить необычные для гибридов плюшки: возможность сделать удобную для некоторых мобильных девайсов распознающую нейроночку, возможность распознавать OOV (некоторые умеют), применимость опыта из распространенных в cv и nlu тулов. Это все можно и на гибридах, но не из коробки.

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

Там как бы 3 датасета, считали метрики на каждом отдельно
Остальные системы — старались минимум 1-2 часа опрашивать
Где лимиты не жесткие — опрашивали все целиком. Допустим не очень система из Англии… вообще округляет до 60 секунд)

Также вот только что сравнили локальную модель с внутренней нормализацией и АПИ с публичной нормализацией — разница меньше 0.5пп WER

Про первое — написал им, мне даже уже ответили.
Может сделаем проект с ними)

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

Одна из рабочих групп MLPerf — Datasets работает над большим публичным набром данных для SST. Сейчас размер примерно 70 тысяч часов, цель — 100 тысяч.

А где вы нашли про 70к часов?
Просто ваша ссылка введет на закрытую Google группу.

Референсная модель RNN transducer, которая (грубая оценка) должна обучиться на 100к часах за 10-30 дней на 64х RTX 2080 картах

Ну… как обычно =)

Libri Speech & Common Voice ~ 2к часов
Некоторые (не помню, что точно значит) данные из интернета ~ 2к часов
Синтезированная речь (Текст модели GPT-2 начитан Voicery) ~ 1k часов

Это норм, чтение тоже довольно простой домен

Аудиокниги (LibriVox) — 65k часов

В реальности это сильно избыточно, т.к. домен книг не то, чтобы важный или сложный.

У этой группы крутые советники — Kelly Davis, Mark Liberman, Andrew Ng и Dan Povey.

Интересно, по ссылке написаны другие люди
Если они сделают так же как ChexNet, то наверное они только отбросят прогресс в этой области на несколько лет =)

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

модель везде одна и та же, она же в демке
т.е. нет джерримендеринга

и да оставлю это на будущее тут

Да она тюнится на всем чем есть. Но не вал сетах, которые дают внешние люди

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

Даже вы бросились комментировать не дочитав)