Весь план целиком

Зачем

Обходить веб с нуля ради проверки гипотезы — это месяцы. Common Crawl отдаёт более 2 млрд страниц в каждом месячном срезе бесплатно, и из него за две недели получается корпус, на котором проверяется всё остальное.

Что делаем

1. Скачиваем индекс последнего среза, около 250 ГБ в сжатом виде.
2. Фильтруем по зонам .ru, .рф, .su, .by, .kz и по определённому языку.
3. Выкачиваем WARC-сегменты только для отобранных URL, а не весь срез.
4. Складываем в объектное хранилище, ведём учёт: сколько документов, сколько байт, сколько стоило.

Как проверяем

Случайная выборка 100 документов открывается и читается — это действительно русскоязычные страницы, а не мусор и не дубликаты.

Зачем

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

Что делаем

1. Прогоняем Resiliparse и Trafilatura на одной выборке в 1000 документов.
2. Вручную размечаем эталон: для каждого документа человек отмечает, какой текст является основным.
3. Считаем точность, полноту и F1 для обеих библиотек и для их комбинации.
4. Отдельно смотрим типы страниц, где обе ошибаются: форумы, каталоги, лендинги.
5. Фиксируем конфигурацию: что запускаем на всём корпусе, что на кандидатах.

Как проверяем

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

Зачем

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

Что делаем

1. Схема документа по разделу 4.5 документа об обходе и индексации: заголовок, словоформы, леммы, хост, язык, дата, быстрые поля под авторитет, качество и спам.
2. Токенизаторы: словоформы и леммы отдельными полями. Морфология пока грубая, полноценная придёт в фазе 1.
3. Индексация 1 млн документов, замер скорости и размера.
4. Поиск в консоли: разбор простого запроса, выдача топ-10 с оценками.
5. Прямой индекс для сниппетов в простейшем виде, без сжатия.

Как проверяем

50 контрольных запросов отрабатывают за отведённое время; размер индекса на документ сверяется с расчётом — ориентир около 6 КБ горячих данных.

Зачем

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

Что делаем

1. Реализуем BM25F так, чтобы взвешенная частота собиралась по всем полям до применения насыщения — именно это отличает BM25F от суммы независимых BM25 по полям.
2. Стартовые веса: заголовок 8.0, якорные тексты 6.0, подзаголовки 3.0, адрес 2.5, словоформы 1.5, леммы 1.0.
3. Ручная настройка на 50 запросах: смотрим глазами, двигаем веса.
4. Фиксируем конфигурацию в файле, а не в коде — она будет меняться постоянно.

Как проверяем

На 50 запросах вручную: результат с точным вхождением в заголовке стоит выше результата с вхождением только в тексте.

Зачем

Авторитет хоста — второй по важности сигнал после текстовой релевантности. Без него в топе оказываются сайты, где слова запроса встречаются чаще, а не те, которым можно доверять.

Что делаем

1. Извлекаем рёбра из обойденного корпуса, строим хостовый и страничный граф.
2. PageRank с затуханием 0.85, итеративно до сходимости.
3. Ядро доверия: вручную отбираем 500 хостов — государственные ресурсы, вузы, крупные СМИ, известные энциклопедии, отраслевые авторитеты. В фазе 1 ядро расширится до 10 000.
4. TrustRank: распространение доверия из ядра с затуханием.
5. Выгрузка значений в таблицу признаков для индекса.

Как проверяем

Ручная проверка топ-100 хостов по авторитету: там должны быть узнаваемые крупные ресурсы, а не сетки дорвеев. Незнакомый домен в топ-50 разбирается отдельно — это либо находка, либо ошибка.

Зачем

Собственный обход — один из трёх обязательных активов. Проверить нужно не производительность, её проверим в фазе 1, а корректность: соблюдение robots.txt, вежливость, устойчивость к ошибкам.

Что делаем

1. Разбор robots.txt строго по RFC 9309 со сверкой поведения с открытой реализацией Google.
2. Двухуровневые очереди фронтира: передние по приоритету, задние по хостам с меткой времени следующего разрешённого запроса.
3. Политика вежливости: 1 запрос в секунду на хост, не более 2 соединений.
4. Загрузка, запись в WARC, обработка редиректов и ошибок.
5. Свой DNS-кэш: на будущих скоростях системный резолвер станет узким местом.

Как проверяем

Набор из 30 синтетических robots.txt с крайними случаями — поведение совпадает с эталонной реализацией во всех случаях без исключения. Логи 100 обойденных сайтов: ни к одному не было больше одного запроса в секунду. Ни одной жалобы от владельцев сайтов за время теста.

Зачем

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

Что делаем

1. Страница /bot: кто мы, зачем ходим, какой User-Agent, с какой частотой.
2. Публикация диапазонов IP краулера в машиночитаемом виде по фиксированному адресу.
3. Инструкция, как ограничить или запретить обход через robots.txt.
4. Контакт для жалоб с обязательством отвечать в течение суток.
5. Инструмент проверки: по IP сказать, наш это бот или подделка.

Как проверяем

Страница открывается даже при недоступности приложения — отдаётся статикой напрямую из веб-сервера.

Зачем

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

Что делаем

1. Заказываем PTR-записи в поддержке провайдера для всех IP краулера.
2. Настраиваем прямые записи на те же адреса.
3. Документируем процедуру двусторонней проверки.

Как проверяем

Для каждого адреса из публикуемого диапазона: обратный запрос даёт имя в нашей зоне, прямой запрос по этому имени возвращает исходный адрес. Проверка автоматическая и повторяется при КАЖДОМ изменении диапазона: адрес, добавленный без записи, означает, что вебмастер примет нашего бота за подделку и заблокирует его вместе с настоящим.

Зачем

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

Что делаем

1. Отбираем 300 запросов: 200 случайных по частотности, 60 сложных многословных и неоднозначных, 40 навигационных с известным правильным ответом.
2. Пишем инструкцию асессора — первую версию на 10–15 страниц: шкала оценок, разбор пограничных случаев, примеры.
3. Нанимаем 5 асессоров по договору на 3 недели, обучаем по инструкции.
4. Для каждого запроса оцениваем топ-20 нашей выдачи и топ-10 конкурентов — последнее нужно для сравнения, а не для копирования.
5. Перекрытие: каждую пару «запрос — документ» оценивают 3 асессора.
6. Считаем согласие по каппе Коэна; при значении ниже 0.5 дорабатываем инструкцию и переоцениваем.

Как проверяем

Каппа Коэна не ниже 0.5. Порог ниже целевого 0.6, потому что первая инструкция всегда сырая; в фазе 1 требование ужесточается.

Зачем

Метрика, которую считают вручную раз в месяц, не влияет на решения. Метрика, которая считается автоматически и видна всем, влияет.

Что делаем

1. Реализуем pFound с вероятностью прерывания 0.15 и шкалой отображения асессорских оценок в вероятность релевантности.
2. Реализуем NDCG@10, MRR и Recall@100 для сопоставимости с литературой.
3. Скрипт прогоняет корзину, считает метрики и пишет результат с отметкой версии кода.
4. Простая страница с графиком: как менялся pFound от замера к замеру.

Как проверяем

Ручной пересчёт pFound на 5 запросах в таблице совпадает с выводом скрипта до четвёртого знака.

Зачем

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

Что делаем

1. Прогоняем корзину, считаем pFound для нашей выдачи и для выдачи конкурентов.
2. Разбираем 30 запросов с наибольшим разрывом и классифицируем причины: нет документа в индексе, документ есть но не находится, находится но низко.
3. Считаем, какая доля разрыва объясняется полнотой индекса, а какая ранжированием — это ключевое разделение: первое лечится обходом, второе моделями.
4. Пишем отчёт: где мы, почему, что делать в фазе 1.

Как проверяем

Отчёт содержит числа, а не оценки. Формулировка «выдача выглядит неплохо» в отчёт не попадает.

Зачем

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

Что делаем

1. Серверный рендеринг с работой без JavaScript.
2. Вёрстка по дизайн-системе: токены, типографика, компоненты.
3. Генерация сниппетов под запрос: скользящее окно по плотности терминов, подсветка совпадений.
4. Тёмная тема, доступность, работа на мобильных.
5. Служебный режим отладки, показывающий вклад каждого признака в скор — без него отладка ранжирования превращается в гадание.

Как проверяем

Страница открывается с отключённым JavaScript и остаётся полностью работоспособной; контраст текста проходит проверку на 4.5:1.

Зачем

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

Что делаем

1. Регистрируем yottis.ru в Timeweb как у аккредитованного регистратора.
2. Одновременно берём защитные yottis.рф и yottis.com.
3. Включаем автопродление и запрет на смену владельца без подтверждения.
4. Оформляем на юридическое лицо.

Как проверяем

Запрос whois показывает верного владельца и дату продления.

Зачем

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

Что делаем

1. VPS Timeweb: 4 vCPU, 8 ГБ памяти, 80 ГБ NVMe.
2. Отдельный пользователь вместо root, вход только по ключам, нестандартный порт SSH.
3. Межсетевой экран с открытыми только 80, 443 и SSH.
4. Защита от перебора паролей и автоматические обновления безопасности.

Как проверяем

Попытка входа по паролю и под root отклоняется; внешнее сканирование портов показывает только 80, 443 и SSH.

Зачем

Без корректных записей не работает ничего: ни сайт, ни почта, ни выпуск сертификатов.

Что делаем

1. Делегирование на серверы имён Timeweb.
2. Записи A и AAAA на VPS — IPv6 обязателен, часть сетей уже без IPv4.
3. CNAME для www, записи A для поддоменов кабинета, API и бота.
4. Запись CAA с запретом выпуска сертификатов другими удостоверяющими центрами.
5. Записи SPF и DMARC.
6. TTL 300 на боевых записях: переключение при аварии за 5 минут, а не за сутки.

Как проверяем

Каждая запись проверяется с нескольких резолверов ВНЕ нашей сети — публичных и сервера в другой стране: ответы совпадают между собой и с ожидаемыми значениями. Отдельно проверяется запись CAA (запрос возвращает запрет для чужих удостоверяющих центров) и фактический TTL на боевых записях. Запись SPF проверяется дважды: при настройке и в день запуска почты — -all при работающей почте это авария, а не конфигурация.

Зачем

Без HTTPS сайт не воспринимается всерьёз ни браузерами, ни поисковыми системами, ни вебмастерами.

Что делаем

1. Nginx: редирект с http, HTTP/2, сжатие.
2. Сертификат Let's Encrypt сразу на четыре имени: корень, www, кабинет вебмастера, API.
3. HSTS и заголовки безопасности.
4. Автопродление сертификата по таймеру.

Как проверяем

Проверка SSL Labs не ниже A; принудительное продление сертификата проходит без ошибок.

Зачем

Проект должен быть виден снаружи до того, как понадобится доверие: вебмастера, кандидаты и партнёры будут искать, кто мы такие.

Что делаем

1. Страница проекта: что строим, статус, контакты.
2. Макеты по адресу /demo.
3. Свой robots.txt — мы тоже сайт.

Как проверяем

Все адреса витрины открываются с холодного кеша, включая /demo; проверка с мобильного устройства и на медленном канале, а не только с рабочей машины. Свой robots.txt отдаётся с кодом 200 и разрешает индексацию витрины — закрытая от индексации витрина не выполняет своей единственной задачи.

Зачем

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

Что делаем

1. Второй VPS под сборочный агент.
2. Пайплайн: сборка, тесты, выкатка по SSH.
3. Откат через символическую ссылку на каталог релиза: возврат к предыдущей версии — одна команда.
4. Проверка здоровья после выката; нет ответа за 30 секунд — шаг падает.

Как проверяем

Выкатываем заведомо сломанную версию — CI останавливает выкатку; откат возвращает рабочую за меньше чем минуту.

Зачем

Мониторинг, стоящий рядом с сервисом, падает вместе с ним.

Что делаем

1. Внешний монитор доступности на дешёвом VPS у другого провайдера.
2. Проверки: доступность сайта, срок действия сертификата, ответ проверки здоровья.
3. Оповещения в мессенджер.

Как проверяем

Останавливаем сервис — оповещение приходит меньше чем за 2 минуты.

Зачем

Резервная копия, из которой ни разу не восстанавливались, резервной копией не является.

Что делаем

1. Бэкап базы: журнал непрерывно, полный снимок раз в сутки, хранение 30 дней.
2. Снимки VPS средствами провайдера.
3. Конфигурация серверов — в репозитории на Repobase.
4. Секреты не в репозитории.

Как проверяем

Полное восстановление на чистой машине, данные совпадают. Процедура записана и повторяется раз в квартал.

Зачем

Страницы выдачи в чужом индексе — это бесконечное пространство адресов и мусор. Это ещё и правило приличия между поисковыми системами: индексировать чужую выдачу не принято, и мы не создаём такой возможности у себя.

Что делаем

1. Запрет обхода страниц выдачи, личных кабинетов и админки в robots.txt.
2. Мета-тег noindex на самих страницах выдачи: robots.txt запрещает обход, но не гарантирует отсутствие в индексе при наличии внешних ссылок.
3. Sitemap с документацией и инструментами.

Как проверяем

Выдача закрыта двумя независимыми способами, и проверяются оба: Disallow в robots.txt и мета-тег noindex на самих страницах. Карта сайта не содержит ни одного закрытого адреса — расхождение между картой и robots.txt считается ошибкой сборки. Через неделю после публикации панели вебмастера не показывают страниц выдачи в индексе.

Зачем

Без панелей вебмастера мы не видим, как нас индексируют конкуренты, и узнаём о проблемах последними.

Что делаем

1. Подтверждение прав в Яндекс.Вебмастере.
2. Подтверждение прав в Google Search Console.
3. Загрузка карты сайта в обе панели.

Как проверяем

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

Зачем

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

Что делаем

1. Разметка Organization на главной: название, логотип, контакты.
2. Разметка WebSite с описанием поиска по сайту.
3. Проверка валидатором.

Как проверяем

Валидатор структурированных данных не выдаёт ни ошибок, ни предупреждений на главной. Отдельно поля организации сверяются с тем, что написано на странице «О проекте»: расхождение разметки и видимого текста считается ошибкой, а не мелочью — именно на таких расхождениях разметку и перестают учитывать.

Зачем

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

Что делаем

1. Персистентное хранилище очереди с восстановлением после перезапуска.
2. Двухуровневая схема: передние очереди по приоритету — критично, высокий, обычный, хвост; задние очереди по одной на хост с меткой времени следующего разрешённого запроса.
3. Формула приоритета: авторитет хоста, прогноз изменения, спрос на свежесть в теме, сигнал из выдачи, подсказки вебмастера, штрафы за недоступность и за спам.
4. Метрики: длина очереди, лаг, распределение по приоритетам, доля отброшенных.

Как проверяем

Убиваем процесс на полной очереди — после перезапуска очередь восстановлена, порядок сохранён, потерь нет.

Зачем

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

Что делаем

1. Для каждого адреса храним ряд отпечатков содержимого и времён обхода.
2. Экспоненциальное сглаживание интервалов между реальными изменениями.
3. Расписание по непрерывной шкале: страница без изменений за год переобходится раз в месяц, лента новостей — раз в минуту.
4. Отдельная обработка случая «сначала неизвестно»: новый адрес обходится через сутки, затем интервал уточняется.

Как проверяем

На выборке 10 000 адресов с известной историей доля переобходов, не давших изменений, ниже 40% против 75% при фиксированном расписании.

Зачем

Ответ «не изменилось» стоит нам почти ничего и экономит трафик сайта. Это одновременно вежливость и деньги: при 10 000 страниц в секунду разница в разы.

Что делаем

1. Храним время последнего изменения и метку версии для каждого документа.
2. Отправляем условные заголовки при каждом переобходе.
3. Корректно обрабатываем ответ «не изменилось», не перезаписывая документ.

Как проверяем

Метрика доли таких ответов на панели обхода, разбивка по хостам.

Зачем

На скорости 10 000 запросов в секунду системный резолвер становится узким местом: обращения к DNS начинают занимать больше времени, чем сама загрузка.

Что делаем

1. Свой резолвер с кэшем по времени жизни записи, но не меньше 60 секунд.
2. Пул вышестоящих серверов с распределением нагрузки.
3. Обработка отказов и отрицательного кэширования.
4. Метрики попаданий в кэш и времени разрешения.

Как проверяем

Замер под нагрузкой 1000 запросов в секунду: время разрешения не превышает 5 мс на p99.

Зачем

Половина современного веба без выполнения скриптов отдаёт пустой контейнер. Но рендеринг стоит в 50–100 раз дороже простой загрузки, поэтому применяется выборочно и по жёсткой квоте.

Что делаем

1. Пул headless-браузеров с блокировкой изображений, шрифтов, медиа и рекламы.
2. Эвристика необходимости: доля видимого текста в объёме разметки ниже 5%, маркеры одностраничного приложения, хост в списке известных, страница ранее показывалась в выдаче.
3. Самообучающаяся экономия: если прирост текста после рендеринга меньше 20%, хост помечается как не требующий рендера на 30 дней.
4. Жёсткая квота не более 8% обходимых страниц; при превышении приоритет отдаётся страницам с ненулевым сигналом из выдачи.

Как проверяем

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

Зачем

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

Что делаем

1. Машиночитаемый список диапазонов IP по фиксированному адресу, обновляемый при изменении парка.
2. Инструмент проверки по адресу на сайте.
3. Документация процедуры двусторонней проверки DNS.

Как проверяем

Внешняя проверка: адрес из списка проходит двустороннюю проверку, произвольный адрес — нет.

Зачем

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

Что делаем

1. Разбор директивы Sitemap из robots.txt, индексных карт и сжатых карт.
2. Учёт даты изменения и приоритета из карты в приоритете фронтира.
3. Эндпоинт приёма, совместимый с IndexNow, плюс собственный эндпоинт пуша.
4. Защита от злоупотребления: квоты и проверка принадлежности адреса домену.

Как проверяем

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

Зачем

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

Что делаем

1. Двенадцать шагов обработки в потоковом режиме: определение типа, разбор, удаление обвязки, язык, заголовки, структурные данные, ссылки, каноникализация, отпечаток, пассажи, морфология, классификаторы.
2. Изоляция сбоев: падение на одном документе не роняет пачку.
3. Метрики по каждому шагу: пропускная способность, доля ошибок, время.

Как проверяем

Прогон 1 млн документов без остановки, доля необработанных ниже 0.5%.

Зачем

Один и тот же документ, доступный по пяти адресам, попадёт в индекс пять раз и будет пять раз конкурировать в выдаче сам с собой.

Что делаем

1. Строгий порядок шагов: регистр схемы и хоста, порт по умолчанию, префикс www, декодирование экранированных символов, нормализация пути, сортировка параметров и удаление трекинговых, удаление фрагмента.
2. Применение канонического адреса, объявленного страницей.
3. Кросс-хостовые канонические адреса принимаются только для пар доменов, подтверждённых в кабинете вебмастера: указание канонического адреса на чужой хост — распространённый приём угона трафика.
4. Хеш канонического адреса как идентификатор документа.

Как проверяем

Набор из 200 пар «разный адрес — один документ» схлопывается верно, набор из 50 пар «похожие адреса — разные документы» не схлопывается.

Зачем

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

Что делаем

1. SimHash на 64 бита по трёхсловным шинглам.
2. Порог: расстояние Хэмминга не более 3 бит.
3. Поиск кандидатов через разбиение отпечатка на четыре блока по 16 бит с индексацией по каждому — при расстоянии не более трёх хотя бы один блок совпадает точно.
4. Дубли группируются, а не удаляются: в выдаче показывается представитель группы, остальные доступны по ссылке.

Как проверяем

На размеченной выборке из 5000 пар точность не ниже 0.95, полнота не ниже 0.85.

Зачем

Русский язык без лемматизации в поиске не работает: падежная система даёт до двенадцати форм на существительное, и запрос «купить холодильник» обязан находить документ про покупку холодильников. Но искать только по леммам тоже нельзя — теряются точные цитаты и имена собственные.

Что делаем

1. Полная морфология на индексации через словарный анализатор и нейросетевой разбор.
2. Быстрый стемминг там, где полная морфология избыточна.
3. Два поля в индексе: словоформы и леммы, с разными весами в формуле.
4. Обработка омонимии: при неоднозначности индексируем оба варианта.

Как проверяем

Набор из 300 пар «запрос — документ в другой форме» находится; набор из 100 точных цитат находится дословно.

Зачем

Язык нужен для выбора обработки и для фильтра выдачи, регион — для локальных запросов. Ошибка здесь портит и то, и другое.

Что делаем

1. Определение языка с оценкой уверенности, отдельная обработка многоязычных страниц.
2. Определение региона по доменной зоне, языку, адресам и телефонам в тексте, расположению хостинга.
3. Пометка «регион не определён» как отдельное состояние, а не подстановка страны по умолчанию.

Как проверяем

Размеченная выборка из 2000 документов, замер точности по каждому языку отдельно. Отдельно — доля отказов против доли ошибок: система, отказывающаяся в 10% случаев и не ошибающаяся, лучше системы с точностью 0.97 и 3% молчаливых ошибок.

Зачем

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

Что делаем

1. Разбор JSON-LD, микроданных, RDFa и OpenGraph.
2. Приоритет типов: статья, товар, организация, хлебные крошки, вопросы и ответы, рецепт, событие, видео.
3. Валидация: битая разметка не должна ронять обработку документа.
4. Журнал ошибок разметки для показа в кабинете вебмастера.

Как проверяем

На выборке из 1000 страниц с известной разметкой извлекается не менее 95% объявленных типов. Отдельно — доля ложных записей в журнале ошибок: она обязана быть близка к нулю, иначе журнал не читают. Отдельно — прогон на страницах с намеренно испорченной разметкой: ни одна не теряется, а целые блоки не пропадают вместе с битым.

Зачем

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

Что делаем

1. Ключ шардирования — хеш хоста, а не адреса. Это даёт три выигрыша: правило разнообразия сайтов применяется локально в шарде, хостовые признаки грузятся один раз, дедупликация внутри сайта не требует сети.
2. Вторичное расщепление: хосты, превысившие один процент размера шарда, шардируются по хешу от хоста и корзины адреса.
3. Реестр топологии шардов в системе координации.

Как проверяем

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

Зачем

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

Что делаем

1. Репликация с двумя копиями каждого шарда в этой фазе.
2. Публикация новой версии через систему координации, переключение шардов пореплично.
3. Хранение предыдущей версии 72 часа.
4. Откат как переключение указателя.

Как проверяем

Выкатываем заведомо испорченную версию индекса, откатываем, замеряем время — не более 10 минут.

Зачем

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

Что делаем

1. Веерный опрос всех шардов с таймаутом 80 мс на шард.
2. Слияние результатов с сохранением порядка.
3. Пометка неполного ответа и метрика доли таких выдач.
4. Исключение систематически медленного шарда из веера до восстановления.

Как проверяем

Учение: гасим шард под нагрузкой — выдача продолжает отдаваться, задержка не растёт. Задержка меряется снаружи, независимо от собственного замера смесителя. Отдельно — учение на возврат: чиним шард и убеждаемся, что он вернулся без ручного вмешательства.

Зачем

Полный перебор постингов частого термина — это сотни миллионов записей на шард. Без отсечения бюджет задержки не выдержать никакими машинами.

Что делаем

1. Нарезка постингов на блоки с хранением верхней границы вклада для каждого блока.
2. Пропуск блока целиком без декодирования, если его граница не позволяет попасть в текущий топ.
3. Сверка поведения с эталонными реализациями.

Как проверяем

Замер на 100 запросах с частыми словами до и после. Критично: результаты выдачи идентичны полному перебору — отсечение не должно менять топ ни на одну позицию. Сравнение оценок побитовое, а не с допуском. Отдельно — прогон на случайных индексах разной формы, включая вырожденный случай, где все списки стоят на одних и тех же документах.

Зачем

Пересборка всего индекса — путь, от которого Google отказался в 2010 году. Свежая новость должна попадать в индекс за минуты, а не ждать следующей полной сборки.

Что делаем

1. Журнал изменений в шине сообщений с секционированием по шарду.
2. Подход с журнально-структурированным слиянием внутри шарда: новые документы пишутся в малые сегменты, фоново сливаются.
3. Удаления через битовую карту мёртвых идентификаторов, применяемую при слиянии.
4. Отложенные производные: авторитет хоста и ссылочные признаки не пересчитываются на каждый документ, а обновляются пакетом раз в сутки и подмешиваются из отдельной таблицы. Свежий документ получает актуальный текст сразу, а актуальный авторитет — назавтра.

Как проверяем

Публикуем документ на тестовом сайте, замеряем время до появления в выдаче — на выборке из 50 публикаций.

Зачем

Сниппет — не аннотация страницы, а ответ на конкретный запрос. Чтобы собрать его за 35 мс, нужны позиции терминов рядом с шардом, а не поход в объектное хранилище.

Что делаем

1. Колоночная структура «идентификатор документа → позиции терминов, краткий текст, признаки» со сжатием и словарём на сегмент.
2. Алгоритм сниппета: скользящее окно 220 символов по плотности терминов запроса, расширение до границ предложений, склейка одного-двух лучших фрагментов, подсветка лемм.
3. Мета-описание используется в последнюю очередь: его пишут маркетологи, и оно почти всегда хуже отвечает на конкретный запрос.

Как проверяем

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

Зачем

Операторы — это то, чем пользуется профессиональная аудитория, которая первой придёт в новый поиск и первой напишет о нём.

Что делаем

1. Операторы: кавычки для точной фразы, минус для исключения, «или», ограничение сайтом и исключение сайта, поиск по адресу и в адресе, поиск в заголовке, тип файла, язык, диапазон дат, регион, любое слово, синонимы, отключение лемматизации.
2. Синтаксис намеренно совместим с привычным по Яндексу — не переучивать пользователя.
3. Понятные сообщения об ошибках разбора вместо пустой выдачи.

Как проверяем

Набор из 60 запросов с операторами даёт ожидаемые результаты; 20 запросов с намеренно сломанным синтаксисом дают осмысленное сообщение.

Зачем

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

Что делаем

1. Подбор весов по асессорской корзине координатным спуском или байесовской оптимизацией с целевой функцией pFound.
2. Веса версионируются вместе с моделью.
3. Отдельная проверка, что подобранные веса не деградируют на навигационных запросах.

Как проверяем

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

Зачем

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

Что делаем

1. Около 40 дешёвых признаков: BM25F по полям, покрытие запроса, близость терминов, авторитет хоста, качество, свежесть, совпадение региона и языка.
2. Обучение логистической регрессией на асессорских парах.
3. Инференс внутри шарда без обращений наружу.

Как проверяем

Полнота на топ-1000 после предранжирования не ниже 0.95 относительно полного ранжирования.

Зачем

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

Что делаем

1. Ежедневный пересчёт хостового графа, еженедельный — страничного.
2. Расширение ядра доверия с 500 до 10 000 хостов.
3. Компактное кодирование графа: разности идентификаторов и ссылки на похожие списки смежности.
4. Выгрузка значений в таблицу признаков, доступную индексу.

Как проверяем

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

Зачем

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

Что делаем

1. Разметка 10 000 документов по качеству.
2. Обучение градиентного бустинга на признаках: объём текста, отношение текста к разметке, доля рекламы в первом экране, наличие автора и даты, читаемость, структурированность, признаки машинной генерации.
3. Калибровка оценки, чтобы она читалась как вероятность.

Как проверяем

Ручной просмотр 100 документов из нижнего и верхнего децилей: оценка соответствует впечатлению человека. Отдельно — проверка совета вебмастеру на страницах БЕЗ проблем: совет там обязан отсутствовать. Совет, выданный там, где проблемы нет, стоит дороже отсутствия совета: владелец идёт искать несуществующую неисправность и теряет доверие ко всем остальным советам заодно.

Зачем

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

Что делаем

1. Схлопывание групп дублей на выдаче с показом представителя.
2. Правило «не более двух результатов с одного хоста в топ-10» с вытеснением третьего вниз, а не удалением.
3. Ссылка «показать похожие» для схлопнутых групп.

Как проверяем

Прогон корзины из 3000 запросов с автоматической проверкой обоих правил. Проверка обязана отличать превышение, которого можно было избежать, от неизбежного: тревога там, где выбора не было, обесценивает весь отчёт.

Зачем

Промышленная версия вместо отладочного прототипа. Скорость главной — витрина скорости всего продукта.

Что делаем

1. Серверный рендеринг с полной работой без JavaScript: скрипты только улучшают.
2. Ограничения: разметка не более 120 КБ, стили не более 20 КБ, скрипты не более 40 КБ с отложенной загрузкой.
3. Колонка результатов не шире 652 пикселей: длинная строка хуже читается.
4. Резервирование мест под блоки, чтобы не было сдвигов вёрстки.

Как проверяем

Замер в автоматическом аудите на четырёх эталонных страницах в мобильном и десктопном профиле.

Зачем

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

Что делаем

1. Префиксный автомат для автодополнения.
2. Исправление опечаток за постоянное время через симметричное удаление.
3. До восьми подсказок, задержка не более 60 мс.
4. Персональные подсказки из истории с иконкой и крестиком удаления.
5. Клавиатурная навигация: стрелки, дополнение табуляцией, закрытие по Esc.

Как проверяем

Нагрузочный замер на 500 запросах в секунду.

Зачем

Блок с готовым ответом экономит клик. Плотность таких блоков — то, в чём Яндекс сильнее Google, и это заметное продуктовое отличие.

Что делаем

1. Калькулятор, конвертер величин, время в городах, перевод.
2. Правило вытеснения: колдунщик показывается, только если не отодвигает первый органический результат ниже 600 пикселей от верха окна.
3. Не более двух колдунщиков одновременно.

Как проверяем

Автоматическая проверка положения первого органического результата на трёх разрешениях.

Зачем

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

Что делаем

1. Регистрация через ключ доступа как способ по умолчанию и через почту с паролем как запасной.
2. Пароли через современную функцию хеширования, проверка по базам утечек методом k-анонимности.
3. Двухфакторная аутентификация: одноразовые коды по времени, ключи доступа, резервные коды.
4. Сессии: короткоживущий токен плюс ротируемый токен обновления в защищённой cookie.
5. Журнал входов, список устройств, выход на всех устройствах.

Как проверяем

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

Зачем

Блокирующая задача фазы. Без кабинета бот не будет принят вебом, а без обхода нет продукта.

Что делаем

1. Подтверждение прав тремя способами: файл в корне, мета-тег, запись в DNS. Перепроверка раз в сутки.
2. Раздел индексирования: страницы в поиске и исключённые страницы с конкретной причиной из закрытого списка — запрет в robots.txt, мета-тег noindex, канонический адрес на другую страницу, дубликат, мало текста, мягкая ошибка «не найдено», ошибка HTTP, редирект, низкое качество, нарушение правил, не дошла очередь обхода.
3. Статистика обхода: запросы бота, коды ответов, время ответа, объём скачанного.
4. Загрузка карты сайта, ручная отправка на переобход с квотой 20 адресов в сутки.
5. Настройка скорости обхода.

Как проверяем

50 внешних сайтов подтвердили права и пользуются кабинетом.

Зачем

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

Что делаем

1. Тёмная тема через системное предпочтение плюс явный переключатель с тремя состояниями: светлая, тёмная, как в системе.
2. Аудит по стандарту доступности уровня AA: контраст, клавиатурная навигация, видимый фокус, роли ориентиров, объявление изменений выдачи.
3. Работа при двукратном увеличении и при отключённых стилях.
4. Учёт предпочтения уменьшенного движения.

Как проверяем

Автоматическая проверка контраста в сборке плюс ручной проход всей выдачи с клавиатуры и со скринридером.

Зачем

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

Что делаем

1. По адресу показываем: заголовки ответа, цепочку редиректов, извлечённый текст, найденную разметку, определённые язык и регион, статус в индексе.
2. Работает без регистрации.
3. Ограничение частоты, чтобы инструмент не превратился в чужой краулер.

Как проверяем

Результат инструмента совпадает с тем, что реально лежит в индексе, на выборке из 100 адресов.

Зачем

Самая частая причина отсутствия страниц в индексе — неверный robots.txt, и вебмастер обычно не понимает, какое правило сработало.

Что делаем

1. Проверка синтаксиса с указанием номера строки.
2. Проверка конкретного адреса против правил с показом сработавшего правила дословно.
3. Работает без регистрации.

Как проверяем

На наборе из 30 крайних случаев вывод анализатора совпадает с поведением бота во всех случаях.

Зачем

VPS не держит поисковый индекс: ему нужны локальные NVMe и предсказуемая память без соседей по гипервизору. VPS остаются под фронт, шлюз API и служебные сервисы.

Что делаем

1. Заказ и приёмка выделенных серверов по расчётной конфигурации.
2. Приёмочные тесты дисков и сети до ввода в эксплуатацию.
3. Схема размещения ролей по машинам.

Как проверяем

Замер последовательного и случайного чтения дисков, пропускной способности сети между узлами; отклонение от заявленного больше 15% — основание для замены.

Зачем

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

Что делаем

1. Вся конфигурация в коде в репозитории на Repobase.
2. Разворачивание нового узла одной командой.
3. Запрет ручных настроек на серверах как правило, а не пожелание.

Как проверяем

Разворачиваем узел с нуля на чистой машине, засекаем время.

Зачем

Без хранилища событий не работают ни метрики качества, ни аналитика, ни будущее обучение на кликах.

Что делаем

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

Как проверяем

Нагрузочный тест на 20 000 событий в секунду в течение часа без потерь.

Зачем

Систему, в которой не видно, где именно уходит время, невозможно ускорять — можно только гадать.

Что делаем

1. Метрики и панели по каждому сервису: частота, ошибки, длительность.
2. Сквозная трассировка с единым идентификатором запроса через все сервисы.
3. Структурированные логи в аналитическом хранилище.
4. Панели: обход, индекс, выдача, железо.

Как проверяем

Берём произвольный медленный запрос из логов и находим по трассировке, какой именно этап его задержал.

Зачем

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

Что делаем

1. Канареечная выкатка ступенями: один процент, десять, пятьдесят, сто.
2. Автоматический откат по метрикам ошибок и задержки.
3. Пауза между ступенями, достаточная для накопления статистики.

Как проверяем

Выкатываем версию с намеренно увеличенной задержкой — откат происходит автоматически до перехода на следующую ступень.

Зачем

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

Что делаем

1. Замер скорости индексации и поиска на каждой сборке на фиксированном наборе данных.
2. Сравнение с предыдущей сборкой и с эталоном.
3. Падение сборки при деградации больше 10%.
4. История замеров с графиком.

Как проверяем

Вносим намеренную деградацию — сборка падает.

Зачем

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

Что делаем

1. Набор 20 асессоров по договору.
2. Переработка инструкции в полноценное руководство асессора, которое мы планируем опубликовать: открытая инструкция дисциплинирует прежде всего нас.
3. Обучение и аттестация с проходным баллом.
4. Контрольные задания с известным ответом в потоке.

Как проверяем

Замер согласия на пересекающихся заданиях еженедельно; падение ниже 0.6 — повод для переобучения.

Зачем

Корзина фиксируется и не меняется между релизами: иначе цифры несравнимы, и любое «улучшение» может оказаться сменой выборки.

Что делаем

1. Состав: 2000 случайных по частотности, 700 сложных, 300 навигационных с известным ответом.
2. Разметка топ-20 с перекрытием три асессора.
3. Версионирование корзины; изменения только с явным решением и пересчётом истории.

Как проверяем

Повторная разметка случайных 100 пар через месяц даёт согласие с исходной не ниже 0.85.

Зачем

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

Что делаем

1. Прогон корзины по расписанию с привязкой к версии кода и версии индекса.
2. Панель с графиком истории.
3. Оповещение при падении больше 0.01.

Как проверяем

Вносим намеренное ухудшение формулы — оповещение приходит на следующем замере.

Зачем

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

Что делаем

1. Политика конфиденциальности и пользовательское соглашение.
2. Правила для сайтов с описанием того, что считается нарушением, и примерами.
3. Политика обхода: что и как обходит бот.
4. Уведомление регулятора об обработке персональных данных.

Как проверяем

Юридическая проверка на соответствие требованиям законодательства о персональных данных.

Зачем

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

Что делаем

1. Публичная форма подачи обращения.
2. Регламент рассмотрения с фиксированными сроками.
3. Защищённый контур хранения паспортных данных заявителей.
4. Журнал аудита: кто, когда, на каком основании, кто утвердил.
5. Механизм скрытия на уровне выдачи, а не удаления из индекса: решение может быть обжаловано и отменено, а удаление необратимо.
6. Привязка скрытия к паре «запрос — адрес», а не к адресу вообще.

Как проверяем

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

Зачем

Обязанность по статье 10.3 привязана к российской аудитории. Применять российское скрытие к пользователю в Германии или Бразилии значит ограничивать его право на информацию без правового основания. Так же устроены и другие операторы: удаление по европейскому праву применяется к европейским пользователям, по российскому — к российским.

Что делаем

1. Определение юрисдикции пользователя по региону, а не по языку интерфейса: язык ничего не говорит о местонахождении.
2. Раздельные реестры скрытия по юрисдикциям; записи разных юрисдикций не смешиваются.
3. Применение реестра только к пользователям соответствующей юрисдикции.
4. Строка под выдачей о том, что часть результатов не показана по правовым основаниям, со ссылкой на объяснение.

Как проверяем

Один и тот же запрос из России и из-за рубежа даёт разное число результатов; запись, внесённая по одной юрисдикции, не влияет на пользователей другой.

Зачем

Оператор обязан видеть скрытое, иначе он не может ни рассмотреть обращение, ни проверить применение скрытия, ни обработать обжалование. Закон требует прекратить выдачу пользователям, а не уничтожить записи: записи нужны, потому что решение может быть отменено.

Что делаем

1. Просмотр доступен только ролям «юрист» и «администратор». Модератору, аналитику и поддержке доступ к материалам обращений граждан по работе не нужен.
2. Режим включается явным запросом, а не следует из роли: юрист, пользующийся обычным поиском, не должен случайно видеть скрытое.
3. Обязательны текстовое обоснование и второй подтверждающий — просмотр входит в красный список.
4. Каждый просмотр пишется в неизменяемый журнал и виден роли аудитора.
5. Режим недостижим с публичной поверхности: его нет ни в интерфейсе поиска, ни в публичном программном интерфейсе, ни в настройках аккаунта.
6. Значения по умолчанию выбраны так, чтобы забывчивость вызывающего приводила к более строгому поведению.

Как проверяем

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

Зачем

Локальные запросы бессмысленны без города: «шиномонтаж» в Москве и Омске — это разные запросы. Плюс регион нужен аналитике и определению применимой юрисдикции.

Что делаем

1. База соответствия адреса и региона с возможностью замены поставщика одним файлом.
2. Явный выбор пользователя как высший приоритет, сохраняемый на год.
3. Оператор региона в запросе — только для этого запроса.
4. Геолокация браузера только на локальных запросах, с объяснением зачем и с запоминанием отказа.
5. Запасной вариант по языку браузера и доменной зоне.
6. Разрешение конфликтов между источниками по строгому приоритету.

Как проверяем

Набор из 500 адресов с известным городом: точность определения города не ниже 75%, страны — не ниже 95%.

Зачем

Определить регион мало — его нужно использовать. Без признака локальные запросы отвечают одинаково по всей стране.

Что делаем

1. Признаки: совпадение региона документа и пользователя, расстояние между регионами по иерархии, отдельное состояние «документ без региона».
2. Вес признака зависит от класса запроса: на локальном он высокий, на информационном почти нулевой.

Как проверяем

Корзина из 200 локальных запросов с замером по пяти городам; контрольная корзина информационных запросов не деградирует.

Зачем

Единая сущность для поиска, аналитики, кабинета вебмастера и будущего локального поиска. Без неё каждый сервис заводит свой список городов, и они расходятся.

Что делаем

1. Иерархия: страна, федеральный округ, регион, город.
2. Синонимы для распознавания в запросе: «Питер», «СПб», «Мск».
3. Координаты, радиус, часовой пояс, язык по умолчанию.
4. Расстояние между регионами считается по иерархии, а не по прямой: Химки ближе к Москве, чем Тверь, потому что в той же агломерации.

Как проверяем

Проверка на 200 названиях городов и их разговорных форм: все распознаются.

Зачем

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

Что делаем

1. Плашка с иконкой места и названием города рядом со строкой поиска на главной.
2. Клик открывает выбор региона с поиском по справочнику и кнопкой автоматического определения.
3. В выдаче — тем же компонентом в панели инструментов.
4. На локальных запросах — подсказка «результаты для города такого-то» с указанием источника определения.

Как проверяем

Клавиатурная доступность выбора региона и сохранение выбора между сессиями.

Зачем

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

Что делаем

1. Обрезка адреса до подсети через 24 часа.
2. Точное местоположение из браузера не сохраняется: используется в момент запроса, в лог пишется только город.
3. Отключаемое определение по адресу в настройках.
4. Регион не связывается с аккаунтом при выключенной истории.

Как проверяем

Аудит логов: адресов старше суток в полном виде нет.

Зачем

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

Что делаем

1. Роли с раздельными правами, а не единая роль администратора.
2. Вход через Yottis ID с обязательной двухфакторной аутентификацией.
3. Журнал действий: кто, что, когда, зачем, с какого адреса, что было и что стало.
4. Неизменяемость журнала на уровне хранилища.

Как проверяем

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

Зачем

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

Что делаем

1. Состояние: размер, свежесть, шарды, возраст сегментов.
2. Обход: скорость, очередь, проблемные хосты.
3. Ручная переиндексация по хосту и по разделу.
4. Исключения: что и почему не в индексе.

Как проверяем

Сквозной сценарий: находим хост с проблемой, запускаем переиндексацию, видим результат.

Зачем

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

Что делаем

1. Реестр хостов с признаками: страниц, авторитет, качество, спам, кабинет.
2. Наложение санкции только с обязательным текстовым обоснованием.
3. Отображение санкции владельцу в кабинете вебмастера с описанием пути выхода.
4. Снятие санкции с обоснованием, всё в журнале.

Как проверяем

Тестовая санкция на свой домен: она появляется в кабинете с понятным текстом и снимается без остатка.

Зачем

Добавление поля в индекс на 10 млрд документов — это полная переиндексация, недели работы. Пустое поле, заведённое сейчас, стоит почти ничего.

Что делаем

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

Как проверяем

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

Зачем

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

Что делаем

1. Реестр флагов с значением «выключено» по умолчанию для всех будущих точек ИИ.
2. Изменение флага без релиза.
3. Журналирование изменений флагов.

Как проверяем

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

Зачем

Модель съедает от 50 до 150 мс. Если бюджет распределён без резерва, добавление модели означает пересмотр всей архитектуры обслуживания.

Что делаем

1. Резервируем 70 мс на слот нейросетевого реранкера.
2. Резервируем 60 мс на параллельные ИИ-функции.
3. Резерв не расходуется, пока функции выключены, но и не занимается другими этапами.

Как проверяем

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

Зачем

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

Что делаем

1. Интерфейс доступа к состоянию адресов с операциями чтения, записи, пакетного обновления и обхода диапазона.
2. Реализация на встроенном хранилище.
3. Краулер работает только через интерфейс, прямых обращений нет.

Как проверяем

Тесты интерфейса проходят на двух реализациях: боевой и на упрощённой в памяти.

Зачем

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

Что делаем

1. Реляционная база с автоматическим переключением при отказе.
2. Схема аккаунтов, прав и ролей.
3. Миграции в репозитории с обязательной обратимостью.
4. Резервное копирование с журналом транзакций.

Как проверяем

Учение: гасим основной узел, замеряем время переключения — не более 30 секунд.

Зачем

Архив обхода растёт быстрее всего остального, и держать его на дорогих дисках бессмысленно: он пишется один раз и читается редко.

Что делаем

1. Кластер объектного хранилища с совместимым интерфейсом.
2. Политики жизненного цикла: перевод старых данных в холодный класс.
3. Проверка целостности по контрольным суммам.

Как проверяем

Запись и чтение терабайта с проверкой контрольных сумм.

Зачем

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

Что делаем

1. Реестр схем с версионированием.
2. Правило обратной совместимости: поле удаляется не раньше двух релизов после прекращения записи.
3. Проверка совместимости в непрерывной интеграции.

Как проверяем

Вносим ломающее изменение — сборка падает с понятным сообщением.

Зачем

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

Что делаем

1. Обход собственной структуры: документация из файлов, инструменты из реестра маршрутов, статьи из индекса.
2. Дата изменения берётся из системы контроля версий — это точнее любой ручной даты.
3. Приоритет и частота изменений по фактической истории, а не по догадке.
4. Разбиение на файлы по 50 000 адресов с индексной картой.
5. Исключение всего, что запрещено в robots.txt: противоречие между картой и запретом вызывает предупреждения в обеих панелях.

Как проверяем

Число адресов в карте совпадает с числом открытых к индексации страниц; расхождение — ошибка сборки.

Зачем

Регрессии в скорости и разметке проникают незаметно и обнаруживаются через месяцы падения трафика, когда причину уже не найти.

Что делаем

1. Автоматический аудит эталонных страниц в мобильном и десктопном профиле.
2. Пороги: отрисовка основного содержимого, отзывчивость, сдвиги вёрстки, размеры разметки, стилей и скриптов.
3. Валидация структурированных данных на каждой странице-образце.
4. Проверка канонических адресов, заголовков, описаний, единственности главного заголовка.
5. Проверка, что запрещённые разделы не встречаются во внутренних ссылках.
6. Нарушение любого порога роняет сборку.

Как проверяем

Вносим намеренное замедление — сборка падает с указанием нарушенного порога.

Зачем

Документация — главный источник органического трафика для нового поиска: на запросы вроде «как работает поисковая система» мы можем отвечать авторитетнее большинства.

Что делаем

1. Публичная документация о том, как работает поиск.
2. Правила для сайтов с примерами нарушений.
3. Разметка технических статей и раздела вопросов и ответов — но только там, где вопросы реально есть на странице.

Как проверяем

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

Зачем

На инструменты ссылаются как на утилиту, а не как на мнение, поэтому они собирают ссылки лучше статей.

Что делаем

1. Отдельная страница под каждый инструмент с описанием и примерами.
2. Общий раздел инструментов с перелинковкой.
3. Разметка инструкций.

Как проверяем

Каждый инструмент достижим не более чем в два клика от главной.

Зачем

Ускоряет индексацию наших изменений конкурентами и заодно проверяет на себе нашу же реализацию приёма пуша.

Что делаем

1. Сравнение новой карты сайта со старой после выкатки.
2. Отправка изменившихся адресов через открытый протокол пуша.
3. Отправка в панель второй системы через её программный интерфейс с учётом квот.
4. Запись факта отправки и отслеживание появления в индексе.

Как проверяем

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

Зачем

Разные панели показывают разные проблемы, и третий источник данных стоит недели работы.

Что делаем

1. Подтверждение прав в панели третьей поисковой системы.
2. Загрузка карты сайта.
3. Подключение к общему монитору индексации.

Как проверяем

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

Зачем

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

Что делаем

1. Каждый признак — запись с именем, владельцем, версией, описанием смысла, стоимостью вычисления, зависимостями и тестами.
2. Метрика важности, пересчитываемая при каждом обучении.
3. Дата протухания: признак без подтверждения владельца после этой даты автоматически исключается из обучения.
4. Автоматический отчёт о неиспользуемых признаках.

Как проверяем

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

Зачем

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

Что делаем

1. Группа текстовой релевантности: BM25F по полям, покрытие запроса, близость терминов, порядок слов, точная фраза, позиция первого вхождения, языковые модели с двумя видами сглаживания, пассажный максимум.
2. Группа семантики: косинус запроса с документом и с лучшим пассажем, расхождение тематик.
3. Группа ссылок: авторитет документа и хоста, доверие, число и разнообразие ссылающихся хостов и подсетей, возраст домена, доля закрытых ссылок, тематическое соответствие доноров, глубина от главной.
4. Группа качества: объём текста, отношение текста к разметке, доля рекламы, грамматичность, оригинальность, наличие автора и даты, читаемость, структурированность.
5. Группа свежести: возраст документа и последнего изменения, частота обновления, всплеск запросов по теме.
6. Группа региона и языка: совпадение и расстояние, качество языка.

Как проверяем

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

Зачем

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

Что делаем

1. Обучение на асессорских оценках с обязательной группировкой по запросу.
2. Метрика на валидации — pFound@10; NDCG как вторичная.
3. Около 2000 деревьев глубины 6.
4. Инференс через нативный рантайм, батчами, с целевыми 20 микросекундами на документ.
5. Версионирование модели вместе с реестром признаков.

Как проверяем

Интерливинг против линейной модели: победа со значимостью выше 99%.

Зачем

У навигационного и описательного запросов признаки работают принципиально по-разному: на первом решает точное совпадение хоста, на втором — семантика. Одна формула на всё теряет качество на обоих краях.

Что делаем

1. Классификатор на шесть классов: навигационный, информационный, транзакционный, локальный, свежий, мультимедийный.
2. Классификатор отдаёт распределение вероятностей, а не жёсткую метку.
3. Отдельная модель ранжирования на каждый класс.
4. Итоговый скор — взвешенная смесь предсказаний по вероятностям классов. Смесь, а не выбор, потому что запросы часто пограничные, и жёсткий выбор даёт скачки качества на границе.

Как проверяем

Отдельный замер качества по каждому классу запросов: ни один класс не деградировал.

Зачем

Только текстовый поиск даёт полноту около 65%, гибрид — около 91%. Строить оба ретривера надо сразу: ретроспективное добавление второго ломает всю калибровку основной модели.

Что делаем

1. Обучение би-энкодера для русского на парах «запрос — кликнутый документ» и асессорских оценках.
2. Векторы размерности 256 с квантованием в один байт на измерение.
3. Индекс приближённого поиска соседей внутри тех же шардов, что и постинги, а не в отдельной базе.
4. Офлайн-вычисление векторов документов на этапе индексации.

Как проверяем

Замер полноты на корзине отдельно для плотного, разреженного и гибридного поиска. Отдельно — проверка обобщения на корпусе-мосте: цель, содержащая синоним, но ни одного слова запроса.

Зачем

Обучаемая разреженность ложится в тот же инвертированный индекс, что и обычные термины, — то есть достаётся почти бесплатно по инфраструктуре, а качество даёт заметное.

Что делаем

1. Обучение модели расширения терминов с весами.
2. Индексация расширенных терминов в отдельное поле того же индекса.
3. Контроль размера индекса: агрессивное расширение раздувает постинги.

Как проверяем

Замер прироста полноты против роста размера индекса; при неблагоприятном соотношении расширение урезается.

Зачем

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

Что делаем

1. Слияние по обратным рангам с отраслевой константой.
2. Веса ретриверов зависят от класса запроса: на навигационном доминирует текстовый поиск и точное совпадение, на описательном — плотный.
3. Подбор весов по корзине отдельно для каждого класса.
4. Проверка, что развёртка веса имеет внутренний максимум. Если качество растёт монотонно до насыщения на значении «только один ретривер», корзина слишком мала или однородна, чтобы выбрать вес, и выбирать его по ней нельзя.

Как проверяем

Сравнение с каждым ретривером по отдельности на корзине; гибрид выигрывает у лучшего одиночного. Развёртка веса каждого ретривера от 0 до значения, при котором он доминирует, с проверкой формы кривой.

Зачем

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

Что делаем

1. Разбиение документа на окна по 512 токенов с перекрытием 128.
2. Оценка каждого окна.
3. Признаки документа: максимум по окнам, число окон выше порога, позиция лучшего окна.

Как проверяем

Отдельная корзина из 300 запросов, ответ на которые лежит в середине длинных страниц.

Зачем

Кросс-энкодер обрабатывает пару «запрос — пассаж» совместно, что принципиально точнее раздельного кодирования, но применимо только к десяткам кандидатов.

Что делаем

1. Компактная предобученная модель для русского как основа.
2. Дообучение дистилляцией из большой модели-учителя плюс клики с коррекцией смещения.
3. Инференс в едином рантайме с квантованием, батчами по 50.
4. Обязательная отбрасываемость по таймауту: без реранкера отдаём порядок предыдущего уровня.

Как проверяем

Замер задержки под нагрузкой; при превышении бюджета реранкер автоматически отключается, и это видно на панели.

Зачем

Ради этого счётчик и строился: данные о том, что человек делал после перехода из поиска.

Что делаем

1. Агрегация обезличенных признаков: время на странице после перехода из поиска, доля возвратов, глубина просмотра.
2. Признаки уровня хоста и раздела, а не отдельного пользователя.
3. Включение в основную модель ранжирования.
4. Полное разделение с историей поиска: связывания с аккаунтом нет.

Как проверяем

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

Зачем

Интерливинг требует на порядок меньше трафика для статистической значимости, чем обычный A/B-тест, потому что сравнение идёт внутри одного пользователя и одного запроса. При нашем трафике это разница между «проверим за неделю» и «проверим за квартал».

Что делаем

1. Смешивание двух выдач по схеме командного набора: монетка решает, кто добавляет документ первым, затем по очереди.
2. Клик засчитывается той формуле, которая добавила документ.
3. Накопление статистики и биномиальный тест.
4. Панель с результатами и историей экспериментов.
5. A/B-тест как подтверждающий инструмент перед выкаткой на весь трафик.

Как проверяем

Заведомо худшая формула проигрывает в интерливинге со значимостью выше 99% на ожидаемом объёме трафика.

Зачем

Самая трудоёмкая часть антиспама: без размеченного корпуса классификатор не обучить, а разметка спама требует экспертизы, которой у обычного асессора нет.

Что делаем

1. Отбор 50 000 хостов-кандидатов по эвристикам и по жалобам.
2. Разметка по типам нарушений: клоакинг, дорвеи, скрапинг, ссылочные схемы, скрытый текст, автогенерация, взлом, паразитный хостинг, накрутка поведения, домены под запрос.
3. Отдельная разметка добросовестных сайтов, похожих на спам: это самая ценная часть выборки.
4. Перекрытие и контроль согласия.

Как проверяем

Согласие разметчиков по каппе Коэна не ниже 0.7 — для спама требование выше, чем для релевантности.

Зачем

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

Что делаем

1. Градиентный бустинг на признаках корпуса.
2. Теневой режим на семь дней: оценка считается, но не применяется, ложные срабатывания разбираются вручную.
3. Три порога: ниже 0.3 — признак без действий, от 0.3 до 0.8 — понижение и метка для ручной проверки, выше 0.8 — исключение из индекса.
4. Ежемесячное переобучение на новых данных.

Как проверяем

Разбор всех ложных срабатываний за неделю теневого режима; выкатка только при доле ложных срабатываний ниже 5%.

Зачем

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

Что делаем

1. Детектор клоакинга: выборочная сверка страницы, полученной ботом и полученной с браузерным User-Agent.
2. Детектор дорвеев: шаблонность плюс редирект плюс отсутствие добавленной ценности.
3. Детектор скрытого текста: анализ стилей при рендеринге.
4. Детектор скрапинга: определение первоисточника по времени первого обхода.

Как проверяем

Каждый детектор проверяется на своей размеченной выборке из тысячи случаев.

Зачем

Сетки сайтов и обмен ссылками видны структурно: плотный подграф с высокой взаимной связностью и низкой связностью с остальным вебом.

Что делаем

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

Как проверяем

Известные сетки из размеченного корпуса обнаруживаются с полнотой не ниже 0.8.

Зачем

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

Что делаем

1. Наложение санкции только оператором, всегда с указанием типа нарушения.
2. Отображение санкции владельцу в кабинете с описанием пути выхода.
3. Кнопка отправки на пересмотр с очередью и сроком ответа.
4. История санкций по хосту.

Как проверяем

Сквозной прогон: наложение, отображение, заявка на пересмотр, снятие — всё в журнале.

Зачем

Саму вертикаль строит отдельный трек «Картинки» (docs/plan/track-images.md): у неё свой индекс, своё ранжирование и свой правовой режим. В основном плане остаётся то, что принадлежит выдаче, а не вертикали, — вкладка, общее состояние запроса и общие настройки. Описание одной и той же работы в двух местах разошлось бы на первой же правке.

Что делаем

1. Вкладка в переключателе вертикалей с сохранением запроса, региона и языка при переходе.
2. Разбор операторов вертикали (size:, ratio:, color:, imagetype:, license:, imagesite:) общим разборщиком языка запросов.
3. Единая настройка безопасного поиска на продукт, а не отдельная для картинок, — стык с 2.25.
4. Переход из веб-выдачи в вертикаль и обратно без потери фильтров времени и языка.
5. Замер доли переходов между вкладками как входные данные для колдунщика «картинки в строку» (I3.3).

Как проверяем

Сценарный тест из десяти переходов между вкладками с проверкой сохранения каждого параметра; сверка выдачи по оператору size:large и по фильтру «Большие» — списки совпадают.

Зачем

Свежесть — то, по чему новый поиск проверяют в первую очередь. Новость крупного СМИ обязана появляться в индексе за минуты.

Что делаем

1. Отдельный быстрый индекс с обновлением не реже чем раз в десять минут.
2. Определение новостных источников и приоритетный обход их лент.
3. Кластеризация публикаций в сюжеты.
4. Обязательная плюрализация источников внутри сюжета: не более двух материалов одного издания.
5. Хронология сюжета.

Как проверяем

Замер задержки на 100 публикациях; проверка, что в сюжете представлено не менее трёх изданий.

Зачем

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

Что делаем

1. Индексация по структурированной разметке видео.
2. Извлечение превью, длительности, автора, даты.
3. Транскрипты там, где они доступны на странице.
4. Карточки с превью в общей выдаче и отдельная вертикаль.

Как проверяем

Корзина из 300 видеозапросов с замером доли, где нужное видео попало в топ-3. Отдельно проверяется полнота карточки: превью, длительность и дата на месте. Карточка без превью проигрывает обычному текстовому результату — показывать её вместо ссылки значит ухудшить выдачу ради формального наличия вертикали.

Зачем

Документы, таблицы и презентации содержат ответы, которых нет в веб-страницах: стандарты, отчёты, инструкции.

Что делаем

1. Извлечение текста из документов, таблиц и презентаций.
2. Ограничения на размер и время обработки.
3. Оператор фильтрации по типу файла в интерфейсе.
4. Отображение типа и размера в результате.

Как проверяем

Корзина из 200 запросов, ответ на которые лежит в документах.

Зачем

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

Что делаем

1. Погода по партнёрскому источнику.
2. Курсы валют по данным центрального банка и биржи.
3. Определения по открытым данным и собственному корпусу.
4. Быстрый ответ на фактоидный вопрос с проверкой согласованности между тремя источниками.
5. Соблюдение правила вытеснения и лимита в два блока.

Как проверяем

Быстрый ответ показывается только при согласии источников; при расхождении блок не показывается вообще.

Зачем

Фильтры нужны меньшинству пользователей, но это меньшинство самое лояльное и самое громкое.

Что делаем

1. Фильтры по времени, региону, языку, типу файла, уровню безопасного поиска.
2. Сортировка по релевантности и по дате.
3. Фильтры применяются без перезагрузки страницы.
4. Состояние фильтров отражается в адресе страницы, чтобы им можно было поделиться.

Как проверяем

Ссылка с фильтрами, открытая в другом браузере, даёт ту же выдачу.

Зачем

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

Что делаем

1. Раздел «Мои данные»: всё, что известно о пользователе.
2. Показ выведенных интересов с возможностью удалить любой и запретить выведение — обычно такие данные скрывают, мы показываем.
3. Экспорт в архив с машиночитаемыми форматами, готовится асинхронно.
4. Удаление аккаунта с тридцатидневной корзиной и подтверждением по почте.
5. История поиска выключена по умолчанию; включение — осознанное действие с объяснением.

Как проверяем

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

Зачем

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

Что делаем

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

Как проверяем

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

Зачем

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

Что делаем

1. Отчёт по запросам: показы, клики, отношение, средняя позиция с разрезами по запросу, странице, региону, устройству, вертикали.
2. Сравнение периодов и выгрузка данных.
3. Диагностика: ошибки обхода, дубли и канонические адреса, проверка структурированных данных, мобильная пригодность.
4. Внешние и внутренние ссылки с якорными текстами.
5. Работа с картами сайта: статус разбора, ошибки.

Как проверяем

Сверка отчёта по запросам с сырыми логами на выборке из десяти сайтов: расхождение не более 1%.

Зачем

Требование законодательства о защите детей и базовое ожидание семейной аудитории.

Что делаем

1. Классификатор возрастного рейтинга на этапе индексации.
2. Три уровня фильтрации: выключен, умеренный, строгий.
3. Детский режим со строгим фильтром и невозможностью отключения без кода.
4. Умеренный уровень по умолчанию.

Как проверяем

Корзина проверочных запросов: на строгом уровне доля нежелательного содержимого ниже 0.5%.

Зачем

Взломанный сайт вредит пользователям и не знает об этом сам. Уведомление владельца — то, за что вебмастера благодарны и остаются.

Что делаем

1. Проверка страниц на признаки вредоносного кода при рендеринге.
2. Сверка со списками известных угроз.
3. Уведомление владельца с указанием затронутых адресов.
4. Предупреждение в выдаче при подтверждённом заражении.

Как проверяем

Тестовый сайт с известным образцом обнаруживается; ложных срабатываний на выборке из тысячи чистых сайтов нет.

Зачем

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

Что делаем

1. Голосовой ввод через браузерный интерфейс распознавания речи.
2. Корректная деградация при отсутствии поддержки: кнопка просто не показывается.
3. Визуальная обратная связь во время записи.

Как проверяем

Проверка в четырёх браузерах, включая один без поддержки.

Зачем

Подготовка к английскому сегменту следующей фазы: перевод интерфейса задним числом всегда дороже, чем закладка механизма заранее.

Что делаем

1. Вынесение всех строк интерфейса в файлы переводов.
2. Русская и английская версии.
3. Указание языковых версий страниц для поисковых систем.
4. Выбор языка независимо от региона.

Как проверяем

Проверка на отсутствие захардкоженных строк в разметке.

Зачем

Шестикратный рост индекса требует и роста парка, и пересмотра схемы репликации.

Что делаем

1. Расширение до примерно 120 машин.
2. Переход на три копии каждого шарда.
3. Перебалансировка шардов без остановки поиска.

Как проверяем

Учение: гасим целую реплику-группу — выдача продолжает работать.

Зачем

Один дата-центр — единая точка отказа. Плюс подготовка к режиму, когда оба центра обслуживают трафик.

Что делаем

1. Развёртывание второй площадки.
2. Репликация индекса и транзакционных данных.
3. Резервное копирование в другую площадку.
4. Регламент переключения.

Как проверяем

Учебное переключение трафика на второй центр с замером времени и потерь.

Зачем

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

Что делаем

1. Закупка и развёртывание узлов с ускорителями.
2. Разделение на обучение и инференс.
3. Планировщик заданий обучения с очередью.
4. Мониторинг утилизации: простаивающий ускоритель — прямые потери.

Как проверяем

Средняя утилизация парка не ниже 60% за месяц.

Зачем

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

Что делаем

1. Доля выдач с нулём результатов.
2. Доля неполных выдач.
3. Доля выдач без единого клика.
4. Средняя позиция первого клика.
5. Обновление каждые пять минут, оповещения по порогам.

Как проверяем

Искусственное ухудшение выдачи на одном шарде приводит к оповещению в течение десяти минут.

Зачем

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

Что делаем

1. Счётчик на скриптах размером не более 6 килобайт: тяжёлый счётчик портит скорость чужого сайта, и его снимают.
2. Асинхронная загрузка и отправка событий фоновым каналом, не блокирующим выгрузку страницы.
3. Приём событий в аналитическое хранилище через шину.
4. События: просмотр, глубина прокрутки, время на странице, переходы, источник, устройство.
5. Режим без cookie по умолчанию: идентификация сессии без межсайтовых идентификаторов.

Как проверяем

Замер отрисовки основного содержимого на сайте до и после установки счётчика: разница в пределах погрешности.

Зачем

Счётчик без отчётов не имеет ценности для владельца сайта, а без ценности его не установят.

Что делаем

1. Посещаемость, источники, глубина, время на странице, отказы.
2. Устройства, браузеры, разрешения.
3. География по справочнику регионов.
4. Страницы входа и выхода, популярные страницы.
5. Сравнение периодов и выгрузка.

Как проверяем

Сверка отчёта с сырыми событиями на тестовом сайте: расхождение не более 0.5%.

Зачем

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

Что делаем

1. Обрезка адреса до подсети через 24 часа.
2. Отсутствие межсайтовых идентификаторов.
3. Публичное описание того, что именно собирается.
4. Режим полного отказа от cookie.
5. Возможность владельца сайта отключить сбор отдельных категорий.

Как проверяем

Аудит: в хранилище нет данных, позволяющих связать посетителя между двумя сайтами.

Зачем

Владелец сайта не должен подтверждать права дважды — для кабинета вебмастера и для аналитики.

Что делаем

1. Общая сущность подтверждённого сайта.
2. Единый интерфейс переключения между кабинетом и аналитикой.
3. Общие роли доступа.

Как проверяем

Новый сайт, подтверждённый в кабинете, сразу доступен в аналитике.

Зачем

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

Что делаем

1. Пользователи: новые, вернувшиеся, активные.
2. Устройства и браузеры.
3. Удержание по когортам.
4. Источники прихода.

Как проверяем

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

Зачем

Нулевые выдачи — самый короткий путь к пониманию, чего не хватает в индексе.

Что делаем

1. Топ запросов, растущие запросы, нулевые выдачи, переформулировки.
2. Разбор конкретного запроса: выдача глазами пользователя выбранного региона.
3. Вклад каждого признака по каждому документу в разборе.
4. Кнопка заведения запроса в регресс-корзину.

Как проверяем

Разобранный запрос попадает в корзину и появляется в следующем автозамере.

Зачем

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

Что делаем

1. pFound по срезам: класс запроса, регион, вертикаль, длина запроса.
2. История с привязкой к версиям кода и индекса.
3. Отметки выкаток на графике.

Как проверяем

По графику можно найти выкатку, после которой качество упало.

Зачем

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

Что делаем

1. Очередь жалоб с приоритетом и сроком реакции.
2. Спам-кандидаты из среднего диапазона оценки на ручную проверку.
3. Решение с обоснованием, всё в журнале.
4. Обратная связь в обучающую выборку классификатора.

Как проверяем

Замер: срок реакции на жалобу не превышает заявленный в 95% случаев.

Зачем

Администратор, который видит всё и ни перед кем не отчитывается, — это уязвимость, а не роль.

Что делаем

1. Красный список действий, требующих второго подтверждающего: просмотр истории конкретного пользователя, выгрузка персональных данных, санкция на крупный хост, изменение реестра скрытия, изменение ролей, отключение антиспама.
2. Роль аудитора: доступ только к журналу, включая действия администратора, без права что-либо менять.
3. Оповещение аудитора о действиях из красного списка.

Как проверяем

Попытка выполнить действие из красного списка в одиночку отклоняется.

Зачем

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

Что делаем

1. Указание одного или нескольких регионов сайта.
2. Автоматическое предложение по контактам, найденным на сайте.
3. Модерация подозрительных заявок: указание всех регионов сразу — типичный приём.

Как проверяем

Изменение региона тестового сайта отражается в локальной выдаче.

Зачем

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

Что делаем

1. Поиск по справочнику регионов с распознаванием разговорных форм.
2. Недавно выбранные регионы.
3. Кнопка возврата к автоматическому определению.
4. Клавиатурная доступность всего диалога.

Как проверяем

Клавиатурный проход всего диалога без мыши.

Зачем

Первый раздел, который открывают утром: где растём, где падаем, откуда идёт накрутка.

Что делаем

1. Карта посетителей с размером точки по числу сессий.
2. Таблицы по странам, регионам и городам с динамикой.
3. Разбивка по источнику определения региона: явный выбор, база адресов, браузер, не определён.
4. Доля ручных смен региона как прямая оценка ошибок определения.
5. Разрезы по устройствам, языку интерфейса, новым и вернувшимся.
6. Города с посещаемостью ниже пятидесяти сессий схлопываются в «прочие»: по городу с одним посетителем регион перестаёт быть агрегатом.

Как проверяем

Целевое значение доли ручных смен не выше 4%; превышение по конкретному региону заводится как задача на исправление данных.

Зачем

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

Что делаем

1. Запрос только после классификации запроса как локального.
2. Объяснение зачем: «чтобы показать ближайшие».
3. Запоминание отказа: повторно не спрашиваем.

Как проверяем

Доля согласий на запрос геолокации не ниже 40% — при неуместном запросе она была бы втрое ниже.

Зачем

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

Что делаем

1. Разрез отчёта по запросам с фильтром по региону.
2. Карта показов по регионам.
3. Сравнение позиций между регионами.

Как проверяем

Сумма показов по регионам совпадает с общим числом показов в отчёте; расхождение допускается только на долю «регион не определён», и она выводится явно, а не молча списывается. Дополнительно — проверка на сайте с заведомо известной географией: разрез обязан повторять реальное распределение, а не давать ровную картину по стране.

Зачем

По городу с одним посетителем «регион» перестаёт быть агрегатом и становится персональными данными.

Что делаем

1. Порог: города ниже пятидесяти сессий за период схлопываются.
2. Порог применяется во всех отчётах, включая выгрузки и программный интерфейс.
3. Проверка порога тестами, а не соглашением.

Как проверяем

Попытка получить данные по городу ниже порога через любой интерфейс возвращает агрегат «прочие».

Зачем

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

Что делаем

1. Справочник кластеров: кириллица, западная латиница, восточная латиница, иероглифика, письмо справа налево, индийские письменности.
2. Привязка языков к кластерам.
3. Поле кластера в схеме документа и в контрактах.

Как проверяем

Все документы корпуса имеют непустой кластер.

Зачем

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

Что делаем

1. Модель на коротких строках с учётом алфавита, частотности и структуры.
2. Обработка запросов без языка: цифры, артикулы, имена собственные.
3. Отдельное состояние «язык не определён» вместо подстановки языка интерфейса.

Как проверяем

Размеченная выборка из 5000 запросов на пяти языках.

Зачем

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

Что делаем

1. Токенизация и нормализация для английского.
2. Стемминг и обработка сокращений.
3. Стоп-слова с проверкой, что их удаление не ломает фразовый поиск.
4. Проверка на подмножестве англоязычных документов из текущего корпуса.

Как проверяем

Корзина из 500 английских запросов на текущем корпусе.

Зачем

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

Что делаем

1. Карточка обращения: заявитель, основания, приложенные документы.
2. Решение с обязательной мотивировкой.
3. Реестр скрытия по паре «запрос — адрес».
4. Скрытие применяется на выдаче, а не удалением из индекса: решение может быть отменено, а удаление необратимо.
5. Синхронизация с реестрами регулятора.
6. Подготовка данных для отчёта о прозрачности.

Как проверяем

Ни одно обращение не выходит за регламентный срок; проверка на выборке за квартал.

Зачем

Единая точка журналирования, политики данных, учёта стоимости, подмены модели и — главное — выключения. Прямых вызовов моделей из других сервисов не существует.

Что делаем

1. Контракт запроса с обязательными полями: имя функции, срок ожидания, поведение при отказе, потолок стоимости, класс допустимых данных.
2. Контракт ответа: результат, использованная модель и версия, время, стоимость, уверенность, факт деградации.
3. Единственная реализация на старте: «функция выключена» с нулевой стоимостью.
4. Потребители пишутся против настоящего интерфейса с первого дня.

Как проверяем

Отключение шлюза целиком не приводит к отказу ни одного сервиса.

Зачем

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

Что делаем

1. Запись на модель: идентификатор, версия, владелец, задача, среда исполнения.
2. Метрики качества на эталонном наборе с датой замера.
3. Задержка и стоимость на тысячу вызовов.
4. Класс данных, который модели разрешено передавать.
5. Дата протухания и запасная модель при отказе.

Как проверяем

Модель с истёкшей датой действительно перестаёт вызываться.

Зачем

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

Что делаем

1. Запись каждого вызова: функция, модель, версия, время, стоимость, уверенность, деградация.
2. Содержимое входа и выхода — по классу данных, с обезличиванием.
3. Панель по стоимости и задержке в разрезе функций и моделей.

Как проверяем

Модель включается на одном проценте трафика: каждый вызов виден в журнале со входом, выходом и временем, а число записей совпадает с числом вызовов по метрике. Отдельно проверяется, что ДЕГРАДАЦИИ пишутся так же, как успешные вызовы: журнал, где видны только успехи, показывает не работу модели, а её лучшую половину.

Зачем

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

Что делаем

1. Классы данных: публичные страницы, текст запроса, запрос с историей, содержимое писем, персональные данные.
2. Класс проверяется шлюзом при каждом вызове.
3. Нарушение — отказ вызова, а не предупреждение в логе.
4. Содержимое писем — только локальным моделям, внешние интерфейсы запрещены категорически.
5. Персональные данные не передаются моделям ни при каких условиях.

Как проверяем

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

Зачем

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

Что делаем

1. Вычисление эмбеддингов документов через шлюз.
2. Нейросетевой реранкер через шлюз.
3. Замер накладных расходов шлюза: они не должны превышать 2 мс.

Как проверяем

Сравнение задержки прямого вызова и вызова через шлюз.

Зачем

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

Что делаем

1. Отдельный кластер для истории поиска с отдельными учётными данными.
2. Общий кластер для технической аналитики и метрик.
3. Отдельный кластер для событий Метрики.
4. Аудит доступа к кластеру истории.

Как проверяем

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

Зачем

Решение о смене хранилища для базы обхода в фазе 3 должно приниматься по данным, а не по предположениям о том, что «встроенное хранилище не потянет».

Что делаем

1. Замер реальной скорости записи и чтения на текущем объёме.
2. Экстраполяция на объёмы фазы 3.
3. Пробное развёртывание кандидата на замену с тем же нагрузочным профилем.
4. Отчёт с решением.

Как проверяем

Замеры воспроизводимы: повторный прогон даёт те же числа в пределах 10%.

Зачем

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

Что делаем

1. Регламент ежеквартальной проверки восстановления по каждому хранилищу.
2. Первое реальное восстановление всех баз на отдельной площадке.
3. Замер времени восстановления и фиксация как показателя.

Как проверяем

Восстановленная копия проходит проверки целостности данных.

Зачем

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

Что делаем

1. Ежесуточная выгрузка из панелей вебмастера: страницы в поиске, исключённые с причинами, ошибки обхода.
2. Сопоставление с собственной картой сайта.
3. Для отсутствующих страниц — автоматическая проверка доступности, запретов, канонических адресов, объёма содержания.
4. Оповещение при отклонении больше 5% от предыдущего дня.
5. История в аналитическом хранилище.

Как проверяем

Намеренно закрываем страницу от индексации — монитор сообщает об этом на следующий день.

Зачем

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

Что делаем

1. Ядро: 300 брендовых, 500 информационных, 200 инструментальных запросов.
2. Еженедельный съём позиций по десктопу и мобильным, по пяти регионам.
3. Показатель видимости как взвешенная сумма по кривой кликабельности.
4. Выявление страниц, потерявших позиции.

Как проверяем

Данные съёма воспроизводимы при повторном замере в тот же день.

Зачем

Одна работа, два применения: валидатор нужен нам в сборке и вебмастерам как публичный инструмент.

Что делаем

1. Извлечение разметки — переиспользуется код нашего же экстрактора.
2. Проверка по схемам: обязательные поля, типы значений.
3. Проверка соответствия видимому содержимому: заявленные вопросы реально присутствуют на странице.
4. Отчёт с указанием строки.
5. Публикация как инструмента для вебмастеров.

Как проверяем

На выборке из 200 страниц с известными ошибками разметки находит не менее 95% из них.

Зачем

Ссылки от технической аудитории и канал найма. Разборы реальных задач читают и цитируют, в отличие от маркетинговых текстов.

Что делаем

1. Раздел блога с разметкой статей.
2. Первые десять материалов о реальных инженерных решениях.
3. Регулярность не реже двух материалов в месяц.
4. Лента для подписки.

Как проверяем

Материалы индексируются и получают внешние ссылки в течение месяца.

Зачем

Открытая публикация инструкции — редкость в отрасли, поэтому она гарантированно вызовет резонанс. И она дисциплинирует прежде всего нас: инструкцию, которую увидят все, невозможно писать небрежно.

Что делаем

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

Как проверяем

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

Зачем

Складывающийся стандарт для языковых моделей: карта содержания сайта в машиночитаемом виде, отдельная от карты сайта для краулеров.

Что делаем

1. Файл в корне с иерархией разделов и ключевыми фактами о проекте.
2. Однозначные формулировки о себе, повторяющиеся везде одинаково.
3. Обновление при изменении структуры сайта.

Как проверяем

Файл валиден по схеме и обновляется вместе с картой сайта: изменение раздела появляется в обоих файлах за один цикл сборки. Расхождение проверяется автоматически — раздел, попавший в карту сайта, но не в карту содержания, считается ошибкой сборки, а не допустимой рассинхронизацией.

Зачем

Семикратный рост корпуса. На этом объёме перестают работать приёмы, достаточные для трёхсот миллионов: перебалансировка занимает сутки, полная пересборка — неделю.

Что делаем

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

Как проверяем

Замер времени полной пересборки и времени добавления нового шарда.

Зачем

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

Что делаем

1. Горячий слой: примерно два процента документов по трафику и авторитету плюс всё свежее за двое суток, полностью в памяти и на быстрых дисках.
2. Тёплый слой: основной корпус на быстрых дисках.
3. Холодный слой: длинный хвост и архив на объектном хранилище.
4. Автоматическое перемещение документов между слоями по трафику.
5. Разная стратегия обновления для каждого слоя.

Как проверяем

Распределение запросов по слоям на реальном трафике за неделю.

Зачем

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

Что делаем

1. Построение графа соседства на быстрых дисках.
2. Сжатое представление в памяти для навигации.
3. Раздельные стратегии для горячего слоя, где вектора остаются в памяти, и тёплого.
4. Инкрементальное добавление векторов без полной перестройки графа.

Как проверяем

Замер полноты и задержки на контрольном наборе из миллиона запросов.

Зачем

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

Что делаем

1. Шестьдесят узлов загрузки, восемьдесят узлов обработки.
2. Распределение фронтира между узлами с сохранением вежливости: суммарная нагрузка на хост считается глобально, а не по узлам.
3. Адаптивное снижение скорости при росте времени ответа хоста.
4. Мониторинг по каждому крупному хосту отдельно.

Как проверяем

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

Зачем

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

Что делаем

1. Начальный набор доменов из открытого корпуса и из ссылочного окружения уже известных.
2. Приоритизация по авторитету и по спросу из логов запросов.
3. Рост индекса до восьми миллиардов документов.
4. Отдельный контроль вежливости: чужой сегмент, чужие ожидания.

Как проверяем

Покрытие: для девяноста процентов англоязычных запросов корзины в индексе есть страница из топ-3 конкурента.

Зачем

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

Что делаем

1. Кодирование разностями идентификаторов вместо самих идентификаторов.
2. Ссылки на похожие списки смежности: у страниц одного сайта они почти совпадают.
3. Проверка, что распаковка не становится узким местом пересчёта.

Как проверяем

Замер объёма и времени пересчёта на полном графе.

Зачем

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

Что делаем

1. Кликстрим в обучение с коррекцией позиционного смещения; вероятность просмотра позиции оценивается на трафике исследования.
2. Признаки: кликабельность с поправкой на позицию, доля длинных кликов, доля быстрых возвратов, последний клик в сессии.
3. В инференсе используются только сглаженные агрегаты с окном не менее тридцати дней.
4. Лаг не менее семи дней между сбором и применением.
5. Байесовское сглаживание к среднему по позиции: редкие пары не двигаются вообще.

Как проверяем

Проверка на устойчивость: искусственный всплеск кликов по паре не меняет её позицию раньше чем через неделю.

Зачем

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

Что делаем

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

Как проверяем

Рост качества на холодной корзине не отстаёт от роста на обучающей — расхождение означает переобучение на собственную выдачу.

Зачем

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

Что делаем

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

Как проверяем

Доля признаков с нулевой важностью не выше десяти процентов.

Зачем

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

Что делаем

1. Полный онлайн-контур в обоих центрах.
2. Маршрутизация трафика по географии с быстрым переключением.
3. Репликация индекса между центрами.
4. Офлайн-контур остаётся в одном центре.
5. Регулярные учения по переключению.

Как проверяем

Учение с реальным отключением одного центра под нагрузкой.

Зачем

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

Что делаем

1. График дежурств с ротацией.
2. Регламенты реагирования по типам инцидентов.
3. Эскалация и разбор инцидентов без поиска виновных.
4. Бюджет ошибок: при исчерпании выкатки останавливаются до конца периода.

Как проверяем

Учебный инцидент ночью: время до реакции не больше пятнадцати минут.

Зачем

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

Что делаем

1. Развёртывание кластера распределённого хранилища.
2. Реализация интерфейса доступа поверх него.
3. Двойная запись в старое и новое хранилище с постоянной сверкой.
4. Переключение чтения после схождения данных.
5. Всё без остановки обхода.

Как проверяем

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

Зачем

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

Что делаем

1. Формат самодостаточных сегментов индекса на объектном хранилище.
2. Поисковые узлы без состояния, читающие сегменты напрямую.
3. Кэширование горячих участков сегментов.
4. Пометка выдачи как обслуженной холодным слоем для отдельного замера задержки.

Как проверяем

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

Зачем

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

Что делаем

1. Реплики только для чтения в каждом регионе присутствия.
2. Запись остаётся в основном центре.
3. Обработка задержки репликации в интерфейсе: после изменения показываем своё же изменение.

Как проверяем

Замер задержки кабинета из удалённого региона с реального канала, а не из соседнего дата-центра. Отдельно — проверка расхождения реплик: запись в центре видна в реплике за оговорённое время, и это время измеряется, а не предполагается. Сценарий с отставшей репликой проверяется явно: пользователь обязан увидеть свои собственные изменения сразу, даже если реплика ещё не догнала.

Зачем

Поведенческие признаки — самый уязвимый слой ранжирования, и рынок накрутки существует ровно потому, что они работают.

Что делаем

1. Учёт кликов только от сессий с историей не менее семи дней и человеческим профилем поведения.
2. Детектор аномалий: всплеск кликабельности по паре относительно исторической базы.
3. Ограничение вклада одной сессии, одного адреса и одной подсети в агрегат.
4. Сглаживание к среднему по позиции.
5. Лаг применения не менее семи дней, делающий быструю накрутку бессмысленной.

Как проверяем

Учение: имитируем накрутку на тестовом запросе — позиция не меняется, аномалия попадает в очередь модерации.

Зачем

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

Что делаем

1. Предобучение на собственном корпусе, русский и английский.
2. Дообучение под задачу ранжирования на кликах и асессорских оценках.
3. Дистилляция в компактную версию для инференса.
4. Квантование и замер задержки.

Как проверяем

Сравнение на корзине и замер задержки под нагрузкой.

Зачем

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

Что делаем

1. Классификатор пригодности запроса. На чувствительных темах — медицина, право, финансы, политика, безопасность — блок не показывается вообще.
2. Берём топ-8 после реранкера.
3. Семантическая фильтрация до трёх-пяти действительно отвечающих документов.
4. Извлечение релевантных пассажей точным экстрактором.
5. Генерация с обязательной ссылкой на каждое утверждение.
6. Проверка обоснованности каждого предложения отдельной моделью; неподтверждённое вырезается.
7. Если после проверки осталось меньше двух предложений — блок не показывается.

Как проверяем

Ручной аудит двухсот сгенерированных ответов асессорами с проверкой каждого утверждения по источнику.

Зачем

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

Что делаем

1. Перенос вызовов на шлюз.
2. Настройка срока ожидания и поведения при отказе.
3. Флаг с долей трафика.
4. Учёт стоимости.

Как проверяем

Отключение шлюза приводит к исчезновению блока, а не к отказу выдачи.

Зачем

Без учёта в разрезе функций инференс внезапно оказывается крупнейшей статьёй расходов, и непонятно, какая функция её создала.

Что делаем

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

Как проверяем

Прогноз при удвоении доли трафика сходится с фактом в пределах двадцати процентов.

Зачем

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

Что делаем

1. Разбор файла при обходе как подсказки о структуре сайта.
2. Использование в приоритизации обхода.
3. Отсутствие доверия к содержимому файла как к факту: это подсказка, а не источник истины.

Как проверяем

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

Зачем

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

Что делаем

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

Как проверяем

Замер по пяти городам на локальной корзине и контрольный замер на информационной.

Зачем

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

Что делаем

1. Платформа на базе открытого инструмента разметки, чтобы не изобретать интерфейсы заново.
2. Типы заданий: оценка релевантности по шкале, попарное сравнение документов, сравнение выдач целиком.
3. Ловушки-контрольки с заранее известным ответом, вкраплённые в поток.
4. Расчёт согласия исполнителей и рейтинга качества.
5. Своё пишем только там, где специфика поиска: шкала, сравнение выдач, контроль согласия.

Как проверяем

Согласие по каппе Коэна не ниже 0.6 на пересекающихся заданиях.

Зачем

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

Что делаем

1. Набор и обучение по опубликованному руководству асессора.
2. Аттестация с проходным баллом.
3. Рейтинг качества по контролькам, влияющий на доступ к заданиям и на оплату.
4. Выплаты и документооборот.

Как проверяем

Замер пропускной способности за четыре недели подряд.

Зачем

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

Что делаем

1. Автоматическое формирование задания на разметку из гипотезы.
2. Сбор оценок и включение в обучающую выборку.
3. Переобучение и офлайн-замер.
4. Автоматический запуск интерливинга при прохождении офлайн-порога.

Как проверяем

Замер на десяти реальных гипотезах подряд.

Зачем

Качество на языке, для которого нет корзины и асессоров, не измеряется, а значит, не управляется.

Что делаем

1. Пять тысяч английских запросов по той же методике отбора.
2. Пул англоязычных асессоров и перевод руководства.
3. Отдельный автозамер по английской корзине.

Как проверяем

Согласие англоязычных асессоров не ниже 0.6.

Зачем

Внутренние метрики на собственной корзине не позволяют сравнить себя с миром. Публичный набор позволяет.

Что делаем

1. Прогон на многоязычном наборе для оценки поиска.
2. Сравнение с опубликованными результатами базовых методов.
3. Включение в регулярный замер.

Как проверяем

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

Зачем

Снимает спекуляции о секретных критериях и даёт вебмастерам понятную рамку.

Что делаем

1. Публикация полного руководства асессора в открытом доступе, тем же текстом, по которому работают наши асессоры, — сокращённая «версия для внешних» обесценивает всю затею. 2. История изменений с датами и пояснением, что именно поменялось и почему. 3. Раздел с примерами оценок: страница, оценка, обоснование. Правила без примеров каждый понимает по-своему. 4. Форма обратной связи для вебмастеров с обязательным ответом на содержательные замечания.

Как проверяем

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

Зачем

Расхожий совет «один индекс на язык» верен для коллекций до миллиона документов и вреден для веба: многоязычные страницы попадают не туда, кросс-языковые запросы не работают, а число индексов растёт вместе с числом языков.

Что делаем

1. Ключ шардирования — хеш от пары «языковой кластер и хост».
2. Внутри кластера сохраняется хостовая локальность, между кластерами появляется возможность отсечения.
3. Переиндексация корпуса с новым ключом.
4. Обработка многоязычных сайтов: документы одного хоста могут попасть в разные шарды, и хостовые признаки должны быть доступны в каждом.

Как проверяем

Замер числа опрошенных шардов до и после на корзине русских запросов.

Зачем

Отсечение по языку даёт выигрыш, но неаккуратное отсечение теряет лучший ответ.

Что делаем

1. Определение языка запроса и региона пользователя.
2. Правило: свой кластер плюс западная латиница всегда. Русскоязычный пользователь на технический запрос почти всегда хочет видеть и англоязычные результаты.
3. Язык не определён — опрашиваются все кластеры региона.
4. Явный оператор языка — только указанный кластер.

Как проверяем

Контрольный замер на корзине: доля запросов, где полезный англоязычный результат исчез из топ-10, равна нулю.

Зачем

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

Что делаем

1. Дообучение многоязычной модели на собственных данных.
2. Использование английского как языка-моста: модели, дообученные под поиск, выигрывают именно в такой схеме.
3. Общее векторное пространство для всех кластеров.
4. Пометка результата на другом языке в выдаче с кнопкой перевода.

Как проверяем

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

Зачем

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

Что делаем

1. Включение ветви при малом числе результатов на языке запроса.
2. Перевод запроса на английский и поиск дополнительной ветвью.
3. Слияние результатов с понижением веса переведённой ветви.
4. Прозрачность: пользователь видит, что часть результатов найдена по переводу.

Как проверяем

На корзине узких технических запросов доля пустых выдач снижается.

Зачем

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

Что делаем

1. Собственный граф сущностей с начальным наполнением из открытых данных.
2. Связывание сущностей с документами индекса.
3. Извлечение фактов из структурированной разметки.
4. Карточка с изображением, фактами и ссылками.
5. Механизм исправления фактов через кабинет вебмастера.

Как проверяем

Асессорская проверка ста карточек: доля неверных фактов ниже двух процентов.

Зачем

Помогает пользователю уточнить запрос и даёт нам сигнал о том, какие формулировки работают лучше.

Что делаем

1. Кластеризация связанных запросов из логов.
2. Отбор вопросов, на которые есть хороший ответ в индексе.
3. Раскрытие ответа без ухода со страницы: блок не должен конкурировать с выдачей.

Как проверяем

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

Зачем

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

Что делаем

1. Картинки в строку на визуальных запросах.
2. Новости в строку при всплеске темы.
3. Факты и определения из графа сущностей.
4. Соблюдение общего лимита в два блока.

Как проверяем

Замер доли запросов с колдунщиком и соблюдения лимита на их число в выдаче. Отдельно — контрольная корзина обычных запросов: она не должна деградировать. Колдунщик, вытеснивший верный органический результат, считается ошибкой, а не удачным блоком.

Зачем

Первая понятная монетизация: не нужен отдел продаж и рекламодатели, актив уже построен.

Что делаем

1. Эндпоинты: веб-поиск, картинки, новости, подсказки, исправление опечаток, проверка адреса.
2. Ключи доступа с квотами по алгоритму токенного ведра и заголовками остатка.
3. Тарифные планы от бесплатного для разработчиков до корпоративного.
4. Документация с примерами на нескольких языках.
5. Правила использования: запрет на построение конкурирующего индекса из выдачи, обязательная атрибуция, ограничение кэширования.

Как проверяем

Нагрузочный тест на заявленных лимитах; превышение квоты корректно отклоняется.

Зачем

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

Что делаем

1. Установка поиском по умолчанию с честным диалогом, а не подменой настроек.
2. Сохранение страницы в коллекции.
3. Быстрый доступ к поиску по выделенному тексту.
4. Публикация в магазинах трёх браузеров.

Как проверяем

Доля удалений в первую неделю ниже двадцати процентов — выше означает, что расширение навязчиво.

Зачем

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

Что делаем

1. Включается только явным действием пользователя.
2. Переупорядочивает топ-30, но не меняет состав кандидатов.
3. Максимальный сдвиг документа — пять позиций.
4. Сигналы: посещённые ранее хосты, повтор запроса, вектор интересов.
5. Пометка в выдаче и ссылка «показать без персонализации» одним кликом.
6. Сервис персонализации отдаёт производный вектор интересов, а не историю.

Как проверяем

Замер: ни один документ не сдвинулся больше чем на пять позиций; состав топ-30 без персонализации и с ней совпадает.

Зачем

Продукт, о котором никто не знает, не получает пользователей независимо от качества.

Что делаем

1. Пресс-материалы и работа с отраслевыми изданиями.
2. Выступления на профильных конференциях.
3. Работа с техническими сообществами.
4. Кампания в момент открытого запуска.

Как проверяем

Замер охвата и переходов по каждому каналу отдельно, с разделением платного и органического. Главная проверка — не охват, а удержание: доля вернувшихся на второй неделе. Запуск, давший миллион визитов и нулевое удержание, считается несостоявшимся, потому что второй раз тех же людей не привести.

Зачем

Опубликовать расширение мало — нужно, чтобы его находили и устанавливали.

Что делаем

1. Оптимизация страниц в магазинах расширений.
2. Промо-страница на сайте.
3. Отслеживание установок и удалений как отдельной метрики.

Как проверяем

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

Зачем

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

Что делаем

1. Встраиваемая форма поиска по сайту.
2. Настройка внешнего вида в кабинете вебмастера.
3. Обязательная видимая атрибуция.
4. Отчёт по запросам внутри сайта для владельца.

Как проверяем

Внедрение на десяти внешних сайтах с замером нагрузки.

Зачем

Дешёвые каналы дистрибуции, которые стоит занять до того, как о нас узнают.

Что делаем

1. Встраиваемый виджет поиска.
2. Настраиваемая стартовая страница.
3. Инструкции по установке для распространённых браузеров.

Как проверяем

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

Зачем

Сильнейший сигнал первоисточника против воровства контента: автор отправляет текст до публикации, и мы фиксируем время.

Что делаем

1. Форма отправки текста в кабинете вебмастера с квотой.
2. Фиксация времени и отпечатка текста.
3. Использование как признака первоисточника при обнаружении дубля.
4. Защита от злоупотребления: отправка чужого текста ничего не даёт, если он уже зафиксирован.

Как проверяем

Учение: фиксируем текст, публикуем копию на другом сайте — оригинал остаётся выше.

Зачем

Быстрые ссылки формируются автоматически и иногда ведут не туда, куда владелец сайта хотел бы.

Что делаем

1. Просмотр сформированных быстрых ссылок.
2. Скрытие ненужных.
3. Объяснение, почему выбраны именно эти.

Как проверяем

Скрытие быстрой ссылки применяется в выдаче в течение суток — замер по реальному сайту от нажатия до исчезновения. Отдельно проверяется, что скрытие НЕ удаляет страницу из индекса: владелец просит убрать ссылку из блока, а не выкинуть страницу из поиска, и путать эти два действия нельзя.

Зачем

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

Что делаем

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

Как проверяем

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

Зачем

Честный ответ на главную претензию издателей к генеративному поиску: возможность быть в индексе, но не в генеративных ответах.

Что делаем

1. Переключатель в кабинете вебмастера.
2. Учёт при отборе источников для ответа.
3. Учёт директив на уровне страницы.

Как проверяем

Сайт с включённым запретом не появляется среди источников ни в одном из ста проверенных ответов.

Зачем

Для новой поисковой системы это основной инструмент построения доверия, которого у неё пока нет по умолчанию.

Что делаем

1. Число обращений по праву на забвение, доля удовлетворённых, основания отказов.
2. Удаления по реестрам и судебным решениям.
3. Жалобы правообладателей и результат.
4. Запросы государственных органов и доля исполненных.
5. Ручные санкции по типам нарушений.
6. Изменения алгоритмов ранжирования: факт и характер, без раскрытия формулы.

Как проверяем

Данные отчёта воспроизводимы из журнала админ-части.

Зачем

Стоит копейки поверх уже собранных данных аналитики, а даёт постоянное цитирование: аналитики и журналисты ссылаются на такие данные годами.

Что делаем

1. Расчёт долей поисковых систем и браузеров на агрегированных данных Метрики.
2. Публичная страница с историей и выгрузкой.
3. Прозрачная методика расчёта.
4. Соблюдение порогов агрегации.

Как проверяем

Методика воспроизводима третьей стороной по опубликованному описанию.

Зачем

Отчёт в формате документа читают единицы; страница с данными и выгрузкой цитируется годами.

Что делаем

1. Публичная страница с графиками и таблицами.
2. Выгрузка данных в машиночитаемом виде.
3. Разметка набора данных.
4. История отчётов.

Как проверяем

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

Зачем

Постоянный источник ссылок и доказательство того, что у нас есть собственные данные.

Что делаем

1. Страница с агрегированной статистикой по индексу: сколько сайтов, на каких языках, в каких зонах, как менялось за год. 2. Данные обезличены и агрегированы до уровня, на котором ни один отдельный сайт не опознаётся, — иначе страница превращается в инструмент конкурентной разведки. 3. Автоматическое обновление и выгрузка в машиночитаемом виде с явной лицензией на использование со ссылкой. 4. Методика расчёта опубликована рядом: цифра без методики не цитируется, а оспаривается.

Как проверяем

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

Зачем

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

Что делаем

1. Четыре исследования в год на собственном индексе.
2. Публикация методики и наборов данных.
3. Разметка наборов данных.
4. Работа с профильными изданиями.

Как проверяем

Не менее десяти ссылающихся доменов на исследование в течение месяца.

Зачем

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

Что делаем

1. Взаимная разметка языковых версий всех публичных страниц.
2. Указание версии по умолчанию.
3. Проверка корректности в аудите сборки.

Как проверяем

Автоматический аудит разметки языковых версий на всех публичных страницах: ссылки взаимны (каждая версия ссылается на все остальные, включая себя), коды языков валидны, и на каждый набор есть версия по умолчанию. Односторонняя ссылка — самая частая ошибка в этой разметке и молча отключает её целиком.

Зачем

Внедрение поиска по сайту даёт нам одновременно ссылки, брендинг и данные о тематических запросах.

Что делаем

1. Условия партнёрства с обязательной атрибуцией.
2. Пакет материалов для внедрения.
3. Приоритетная поддержка партнёров.
4. Отслеживание внедрений.

Как проверяем

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

Зачем

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

Что делаем

1. Список экспериментов со статусом и владельцем.
2. Запуск интерливинга и A/B из интерфейса.
3. Расчёт значимости и достаточности накопленной статистики.
4. Откат одной кнопкой.
5. История всех экспериментов с результатами, включая неудачные.

Как проверяем

Любой прошлый эксперимент воспроизводим по записи в истории.

Зачем

Выкатка без релиза: включение по долям трафика, регионам и языкам.

Что делаем

1. Управление флагами из интерфейса с журналированием.
2. Условия: доля трафика, регион, язык, класс запроса, тип аккаунта.
3. Постепенное включение с автоматическим откатом по метрикам.

Как проверяем

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

Зачем

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

Что делаем

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

Как проверяем

Попытка открыть историю без процедуры отклоняется.

Зачем

Колдунщики, панель знаний и справочники требуют продуктового управления, а не правки конфигов в репозитории.

Что делаем

1. Управление колдунщиками: включение, пороги, источники данных.
2. Редактирование сущностей панели знаний и исправление фактов.
3. Управление справочниками регионов и категорий.

Как проверяем

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

Зачем

Квоты, потребление и блокировки должны быть видны и управляемы, иначе злоупотребление обнаруживается по счёту за трафик.

Что делаем

1. Список ключей с тарифом, потреблением и остатком квоты.
2. Блокировка и разблокировка с обоснованием.
3. Оповещения о всплесках потребления.

Как проверяем

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

Зачем

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

Что делаем

1. Расширение до примерно двухсот шардов с тройной репликацией.
2. Переход векторного слоя на схему с кластеризацией поверх графа в памяти: по опубликованным замерам она вдвое быстрее предыдущей при той же полноте и той же памяти на трёхмиллиардных наборах.
3. Пересмотр порогов между слоями индекса: доля горячего слоя при росте корпуса падает.
4. Проверка, что время полной пересборки остаётся управляемым.

Как проверяем

Нагрузочный тест на целевом объёме и целевой нагрузке в течение суток.

Зачем

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

Что делаем

1. Замер реальной нагрузки и определение ключа шардирования: по пользователю или по организации.
2. Выбор между шардированием текущей базы и переходом на распределённую транзакционную систему — решение принимается по данным фазы 3.
3. Миграция без простоя с двойной записью и сверкой.

Как проверяем

Нагрузочный тест на утроенной от текущей нагрузке.

Зачем

За пределами пятисот терабайт эксплуатационные свойства становятся важнее простоты: нужны предсказуемое восстановление, управление размещением и работа с деградированным кластером.

Что делаем

1. Оценка текущего решения на целевых объёмах.
2. Пробное развёртывание более зрелой альтернативы.
3. Решение по данным, а не по репутации систем.
4. Миграция при положительном решении.

Как проверяем

Проверка целостности всех объектов по контрольным суммам после миграции.

Зачем

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

Что делаем

1. Приём товарных фидов от магазинов через кабинет вебмастера.
2. Извлечение товаров из структурированной разметки для тех, кто фид не даёт.
3. Сопоставление одинаковых товаров разных продавцов.
4. Карточка товара: цена, наличие, доставка, продавцы.
5. Фильтры по цене, характеристикам, продавцу.
6. Явное разделение органических карточек и рекламных предложений.

Как проверяем

Асессорская проверка сопоставления на тысяче товаров: доля ошибочных объединений ниже двух процентов.

Зачем

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

Что делаем

1. Открытая картографическая подложка как основа, коммерческий фид как дополнение.
2. Слой организаций строим свой — это и есть наша часть работы.
3. Поиск организаций с фильтрами по категории, часам работы, рейтингу.
4. Построение маршрутов через партнёрский сервис.
5. Карточка организации в веб-выдаче на локальных запросах.

Как проверяем

Корзина из пятисот локальных запросов по десяти городам.

Зачем

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

Что делаем

1. Сбор данных из открытых источников, разметки сайтов и заявок владельцев.
2. Подтверждение владения организацией по телефону или почте на домене.
3. Кабинет владельца: адрес, часы, телефон, фото, услуги.
4. Разрешение конфликтов между источниками.
5. Обнаружение закрывшихся организаций: устаревшая карточка хуже отсутствующей.

Как проверяем

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

Зачем

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

Что делаем

1. Отзывы только от подтверждённых аккаунтов с историей.
2. Рейтинг считается внутри категории: иначе кафе сравниваются с автосервисами, и сравнение бессмысленно.
3. Порог: рейтинг показывается от трёх оценок.
4. Обязательное право владельца на публичный ответ.
5. Публикация с задержкой и антинакруточные проверки.
6. Процедура удаления отзыва по обоснованной жалобе.

Как проверяем

Учение: имитация накрутки на тестовой организации обнаруживается до публикации.

Зачем

В вертикали картинок поиск по изображению — способ ввода (I2.4, I2.5). Как отдельный сценарий он решает другие задачи: узнать объект, найти товар, найти источник — и потому имеет собственную точку входа с главной и из мобильного приложения, а не только вкладку.

Что делаем

1. Отдельная точка входа с главной страницы и из приложения, с загрузкой, перетаскиванием и вставкой из буфера.
2. Ответ, собранный вокруг объекта: что это, похожие изображения, товар, источник и более крупные версии.
3. Связь с распознаванием объектов (I4.1) и с товарной вертикалью (4.2).
4. Поиск источника изображения: первоисточник и все известные носители (I2.9).
5. Единое состояние с вертикалью: сценарий и вкладка не расходятся в результатах на одном и том же файле.

Как проверяем

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

Зачем

Продолжение линии на плотность блоков с готовым ответом, теперь на данных партнёрских фидов.

Что делаем

1. Спортивные результаты и расписания матчей.
2. Расписания транспорта.
3. Товарные предложения на транзакционных запросах.
4. Карта и организации на локальных запросах.
5. Соблюдение общего лимита блоков.

Как проверяем

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

Зачем

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

Что делаем

1. Приложения для двух платформ с общей логикой и нативными интерфейсами.
2. Поиск, вертикали, аккаунт, коллекции.
3. Голосовой ввод и поиск по камере.
4. Виджет на домашнем экране.
5. Возможность установки поиском по умолчанию там, где платформа это позволяет.
6. Работа в офлайне для сохранённого содержимого.

Как проверяем

Оценка в магазинах не ниже 4.3; доля удалений в первую неделю ниже двадцати пяти процентов.

Зачем

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

Что делаем

1. Синтез речи для быстрых ответов и генеративного блока.
2. Управление воспроизведением.
3. Отключаемость в настройках.

Как проверяем

Разборчивость проверяется на записях: слушатели, не видевшие текста, воспроизводят факты из ответа. Отдельно — обработка того, что произносится плохо: адреса, номера, сокращения и иноязычные названия проверяются списком, а не выборочно, потому что именно на них озвучивание и ломается.

Зачем

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

Что делаем

1. Организация как контейнер для сайтов, ключей и участников.
2. Единый вход через корпоративные системы аутентификации.
3. Роли внутри организации с раздельными правами.
4. Журнал действий участников.
5. Централизованная оплата.

Как проверяем

Сквозной сценарий: создание организации, приглашение участников, передача сайта, отзыв доступа.

Зачем

Агентства и крупные сайты работают с данными программно; ручная выгрузка для них неприемлема.

Что делаем

1. Эндпоинты: список сайтов, отчёт по запросам, статус индексации, ссылки, отправка на переобход.
2. Приём пуша об изменениях в промышленном режиме с квотами по правам.
3. Аутентификация и разграничение по ролям организации.
4. Документация и примеры.

Как проверяем

Внешняя интеграция от партнёрского агентства проходит без правок с нашей стороны.

Зачем

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

Что делаем

1. Отдельный сервис показа рекламы, не смешанный с органикой ни в коде, ни в логах.
2. Явная маркировка каждого объявления и указание рекламодателя.
3. Не более трёх блоков сверху; первый органический результат не уходит за первый экран.
4. Аукцион и кабинет рекламодателя.
5. Регистрация креативов в учётной системе согласно требованиям законодательства.
6. Отдельный контроль: доля кликов по органике не должна падать после запуска.

Как проверяем

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

Зачем

Программный интерфейс без биллинга не приносит денег, а ручное выставление счетов не масштабируется.

Что делаем

1. Тарифные планы с квотами и лимитами.
2. Учёт потребления и выставление счетов.
3. Оплата и документы для юридических лиц.
4. Уведомления о приближении к лимиту.

Как проверяем

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

Зачем

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

Что делаем

1. Признаки: расстояние, рейтинг, полнота карточки, актуальность часов, наличие сайта.
2. Учёт времени запроса: закрытая сейчас организация понижается.
3. Отдельная модель для локального класса запросов.

Как проверяем

Асессорская корзина локальных запросов с оценкой по расстоянию и актуальности.

Зачем

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

Что делаем

1. Сбор соответствий из явных выборов региона пользователями.
2. Сбор из данных аналитики на сайтах с известной географией.
3. Обучение модели соответствия подсети и региона.
4. Гибрид: своя база для России и стран СНГ, покупная для остального мира.
5. Постоянная проверка по доле ручных смен региона.

Как проверяем

Сравнение доли ручных смен региона до и после по каждому городу.

Зачем

В крупных городах город как единица слишком крупный: «шиномонтаж» в Москве без уточнения района отвечает бесполезно.

Что делаем

1. Иерархия районов для городов свыше миллиона жителей.
2. Распознавание районов и станций транспорта в запросе.
3. Учёт района в локальном ранжировании.

Как проверяем

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

Зачем

Браузерный интерфейс распознавания зависит от платформы, работает не везде и передаёт голос третьей стороне. Своё распознавание снимает все три проблемы.

Что делаем

1. Модель распознавания для русского и английского.
2. Инференс на устройстве там, где это возможно, на сервере в остальных случаях.
3. Адаптация под поисковые запросы: они короткие и содержат имена собственные.
4. Голос не сохраняется после распознавания.

Как проверяем

Замер на размеченном наборе голосовых запросов.

Зачем

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

Что делаем

1. Классификатор сложности запроса: модель вызывается только там, где она нужна.
2. Реранкинг топ-10 большой моделью.
3. Доля трафика не выше двух процентов — параметр управляемый, а не следствие.
4. Жёсткий бюджет стоимости с автоматическим отключением при превышении.

Как проверяем

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

Зачем

Извлечённый фрагмент иногда плохо отвечает на запрос: ответ разбросан по странице или сформулирован иначе. Сгенерированный сниппет решает это, но требует той же строгости, что и генеративный ответ.

Что делаем

1. Классификатор: где извлечённый сниппет плох.
2. Генерация сниппета строго по содержимому страницы.
3. Проверка обоснованности: сниппет не может утверждать того, чего на странице нет.
4. Пометка сгенерированных сниппетов.
5. Отбрасываемость по таймауту с возвратом к извлечённому.

Как проверяем

Асессорская проверка двухсот сгенерированных сниппетов на соответствие странице.

Зачем

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

Что делаем

1. Перевод вопроса на естественном языке в запрос к аналитическому хранилищу.
2. Показ сгенерированного запроса перед выполнением: доверять, но проверять.
3. Ограничение прав: помощник не может обращаться к персональным данным.
4. Журналирование всех запросов.

Как проверяем

На пятидесяти типовых вопросах доля корректных запросов не ниже восьмидесяти процентов.

Зачем

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

Что делаем

1. Токенизация и нормализация с учётом диакритики.
2. Стемминг по каждому языку.
3. Разбиение сложных слов для немецкого: без него половина запросов не находится.
4. Обработка агглютинации для турецкого и венгерского.
5. Обход соответствующих сегментов веба.

Как проверяем

Корзина из тысячи запросов на язык с локальными асессорами.

Зачем

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

Что делаем

1. Расчёт спроса на языковые кластеры по регионам из логов.
2. Автоматическое решение о размещении кластера в регионе.
3. Обслуживание редких для региона запросов из центрального дата-центра с повышенной задержкой.
4. Метрика доли запросов, ушедших в центр.

Как проверяем

Доля запросов, обслуженных из центра, не выше двух процентов в каждом регионе.

Зачем

Качество на языке без корзины не измеряется, а значит, не управляется. Заявлять поддержку языка без замера — обман.

Что делаем

1. По тысяче запросов на каждый новый язык.
2. Пул асессоров-носителей через платформу заданий.
3. Перевод и адаптация руководства асессора.
4. Отдельный автозамер по каждому языку.

Как проверяем

Согласие асессоров по каждому языку не ниже 0.6.

Зачем

Скорость — это ещё и физика: сигнал из Москвы во Франкфурт и обратно занимает заметную долю бюджета задержки.

Что делаем

1. Развёртывание полного онлайн-контура в европейской точке.
2. Маршрутизация европейского трафика по географии.
3. Размещение горячего и тёплого слоёв только для кластеров, которые в этом регионе спрашивают.
4. Соблюдение требований европейского законодательства к данным.

Как проверяем

Замер задержки из европейских точек мониторинга.

Зачем

Реестр признаков растёт, и ручная ревизия перестаёт справляться. Урок из утечки кода конкурента прямой: без автоматики треть признаков мертва в любой момент.

Что делаем

1. Новые группы признаков: товарные, локальные, многоязычные, поведенческие второго порядка.
2. Автоматический расчёт важности при каждом обучении.
3. Автоматический перевод признака в кандидаты на удаление после трёх обучений с нулевым вкладом.
4. Автоматическое отключение по дате протухания.

Как проверяем

Ежемесячный отчёт реестра: число активных, кандидатов на удаление, отключённых.

Зачем

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

Что делаем

1. Расширение парка и числа шардов.
2. Пересмотр соотношения слоёв индекса: горячий слой в долях от корпуса продолжает уменьшаться.
3. Оптимизация стоимости запроса как самостоятельная задача: она определяет юнит-экономику.
4. Проверка, что операции обслуживания — пересборка, перебалансировка, восстановление — остаются выполнимыми.

Как проверяем

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

Зачем

Самая дорогая часть всемирного поиска. Без сегментации иероглифический текст невозможно ни проиндексировать, ни найти.

Что делаем

1. Словарные и статистические сегментаторы для китайского, японского и корейского.
2. Индексация биграмм как страховка на случаях, где сегментатор ошибся: это удваивает размер постингов для кластера, и в расчёте ёмкости учтено.
3. Обработка смешанного текста: иероглифика вперемешку с латиницей встречается постоянно.
4. Традиционное и упрощённое письмо как варианты одного языка.

Как проверяем

Корзина из тысячи запросов на язык с носителями-асессорами.

Зачем

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

Что делаем

1. Отдельная модель эмбеддингов для кластера.
2. Связывание с общим пространством через язык-мост для кросс-языкового поиска.
3. Дообучение на собственных данных по мере накопления.

Как проверяем

Замер на открытых многоязычных наборах для этих языков.

Зачем

Арабский и иврит требуют не только обработки текста, но и перестройки интерфейса: направление письма меняет всю вёрстку.

Что делаем

1. Нормализация огласовок и вариантов написания.
2. Корневая морфология для арабского.
3. Зеркальная вёрстка интерфейса и корректная подсветка в сниппетах.
4. Обработка смешанного текста с латиницей.

Как проверяем

Проверка носителями: вёрстка, подсветка, порядок элементов.

Зачем

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

Что делаем

1. Развёртывание полного онлайн-контура.
2. Размещение иероглифического кластера локально.
3. Маршрутизация трафика по географии.
4. Соблюдение местных требований к данным.

Как проверяем

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

Зачем

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

Что делаем

1. Развёртывание третьей площадки.
2. Пересмотр схемы репликации под три центра.
3. Дежурство по принципу следования за солнцем.
4. Регулярные учения по отказу каждой площадки.

Как проверяем

Учения по отказу каждой площадки по очереди.

Зачем

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

Что делаем

1. По тысяче запросов на язык.
2. Пул асессоров-носителей через платформу заданий.
3. Адаптация руководства с учётом культурной специфики: понятие релевантности в разных культурах различается сильнее, чем кажется.
4. Отдельный автозамер.

Как проверяем

Согласие асессоров не ниже 0.6 по каждому языку.

Зачем

Признак зрелости организации — не размер индекса, а время от гипотезы до выката. Организация, у которой этот цикл занимает квартал, проигрывает независимо от качества инженеров.

Что делаем

1. Автоматизация всех шагов цикла: задание на разметку, сбор оценок, переобучение, офлайн-замер, интерливинг, выкатка через флаг.
2. Автоматический переход между шагами при прохождении порогов.
3. Ручное вмешательство только на принятии решения о выкатке на весь трафик.
4. Замер длительности цикла как отдельного показателя.

Как проверяем

Замер на двадцати последовательных гипотезах.

Зачем

Запрос, сочетающий текст и изображение, отвечает на задачи, которые невозможно сформулировать словами: «такое же, но синее», «где это находится».

Что делаем

1. Общее пространство представлений для текста и изображений.
2. Комбинированный запрос: изображение плюс уточнение текстом.
3. Интерфейс уточнения в мобильных приложениях и вебе.

Как проверяем

Корзина из пятисот комбинированных запросов.

Зачем

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

Что делаем

1. Определение неоднозначности запроса.
2. Уточняющий вопрос с вариантами, а не свободным полем.
3. Сохранение контекста в пределах сессии.
4. Полная отключаемость: пользователь может никогда этого не видеть.

Как проверяем

Доля успешных сессий на неоднозначных запросах растёт; на однозначных уточнение не появляется.

Зачем

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

Что делаем

1. Приём открытых научных метаданных.
2. Связывание версий: препринт, публикация, издательская версия.
3. Индекс цитирований.
4. Фильтры по году, журналу, автору, доступности полного текста.

Как проверяем

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

Зачем

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

Что делаем

1. Компактный блок уточнения над выдачей, не вытесняющий результаты.
2. Уточнение одним кликом, без ввода текста.
3. Возможность игнорировать: выдача полноценна и без уточнения.
4. Запоминание отказа от уточнений.

Как проверяем

Доля кликов по органике не падает после включения блока.

Зачем

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

Что делаем

1. Правовые основания обработки, право на удаление, переносимость данных.
2. Ответственный за защиту данных и представитель в регионе.
3. Оценка воздействия на защиту данных.
4. Публичное описание принципов работы рекомендательных механизмов.
5. Механизм жалоб и отчётность.
6. Разделение контуров: требования разных юрисдикций конфликтуют, и решать это надо разделением, а не компромиссом.

Как проверяем

Внешний аудит без критических замечаний.

Зачем

Работа с европейской аудиторией требует собственного механизма удаления по праву на забвение. Механизм территориальности уже построен в задаче 1.66 — здесь добавляется вторая юрисдикция, а не новая система.

Что делаем

1. Форма обращения и регламент рассмотрения по европейским требованиям.
2. Отдельный реестр юрисдикции, не смешивающийся с российским.
3. Балансировка интересов заявителя и общественного интереса как обязательный этап решения — этого требования нет в российском праве, и решение по одному и тому же обращению может различаться.
4. Отражение в отчёте о прозрачности отдельной строкой по каждой юрисдикции.

Как проверяем

Сквозной прогон обращения; проверка изоляции реестров: запись одной юрисдикции не влияет на пользователей другой.

Зачем

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

Что делаем

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

Как проверяем

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

Зачем

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

Что делаем

1. Компактная модель суммаризации, работающая внутри почтового контура.
2. Пересказ длинного письма и пересказ треда.
3. Полная отключаемость.
4. Техническая невозможность передачи содержимого во внешние интерфейсы, проверяемая шлюзом моделей.

Как проверяем

Аудит сетевых обращений почтового контура: обращений к внешним интерфейсам моделей нет.

Зачем

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

Что делаем

1. Ежеквартальные обновления ядра ранжирования.
2. Постоянный поток гипотез из разбора запросов и обратной связи.
3. Обновление моделей по мере появления новых архитектур.
4. Строгое соблюдение порогов: изменение, ухудшающее любую метрику ворот, не выкатывается.

Как проверяем

Квартальный отчёт по качеству с разбивкой по классам запросов и языкам.

Зачем

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

Что делаем

1. Рост корпуса по мере роста веба.
2. Добавление языков по мере появления спроса, а не по списку.
3. Каждый новый язык проходит полный цикл: обработка, корзина, асессоры, замер.

Как проверяем

Ежеквартальный замер покрытия по каждому языку.

Зачем

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

Что делаем

1. Сокращение задержки от публикации до появления в индексе.
2. Расширение пуш-механизмов и партнёрских каналов уведомлений.
3. Приоритизация источников с высокой частотой публикаций.

Как проверяем

Ежемесячный замер на ста публикациях крупных изданий.

Зачем

Единственное направление, где противник адаптируется в ответ на наши действия. Здесь не бывает состояния «сделано»: любое улучшение антиспама порождает новый обходной приём.

Что делаем

1. Постоянный мониторинг новых приёмов манипуляции.
2. Ежемесячное переобучение классификаторов.
3. Теневой режим перед каждым изменением порогов.
4. Разбор каждого случая массового пропуска и каждого ложного срабатывания.

Как проверяем

Квартальный замер на обновляемой тестовой выборке, включающей новые приёмы.

Зачем

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

Что делаем

1. Регулярный анализ запросов без хорошего ответа.
2. Приоритизация новых блоков и вертикалей по объёму такого спроса.
3. Отказ от блоков с низкой пользой: колдунщик, которым не пользуются, занимает место.

Как проверяем

Ежеквартальный разбор топ-1000 запросов с плохой выдачей.

Зачем

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

Что делаем

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

Как проверяем

Доля крупнейшего канала в притоке не выше сорока процентов.

Зачем

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

Что делаем

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

Как проверяем

Ежеквартальный расчёт полной стоимости обслуживания запроса.

Зачем

Надёжность деградирует сама по себе: система усложняется, люди меняются, знания теряются.

Что делаем

1. Регулярные учения по отказам, включая неожиданные для дежурных.
2. Разбор каждого инцидента без поиска виновных, с обязательными действиями по итогам.
3. Актуализация регламентов и документации.
4. Соблюдение бюджета ошибок: при исчерпании выкатки останавливаются.

Как проверяем

Квартальный отчёт по доступности и по выполнению действий из разборов инцидентов.

Зачем

Доверие набирается годами и теряется за неделю. Для поисковой системы это единственный актив, который нельзя восстановить деньгами.

Что делаем

1. Полугодовой отчёт о прозрачности.
2. Публикация изменений алгоритмов: факт и характер, без раскрытия формулы.
3. Актуализация руководства асессора и правил для сайтов.
4. Открытый диалог с сообществом вебмастеров.

Как проверяем

Соблюдение графика публикаций без пропусков.

Зачем

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

Что делаем

1. Замена моделей на более качественные по мере их появления.
2. Включение зарезервированных слотов по мере созревания технологии и экономики.
3. Ревизия реестра моделей: отключение устаревших.
4. Пересмотр политики данных при появлении новых классов задач.

Как проверяем

Ежеквартальная ревизия реестра моделей.

Зачем

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

Что делаем

1. Статус организатора распространения информации: основания, порядок включения в реестр, обязанности.
2. Требования к хранению содержимого и метаданных: объём, сроки, форма.
3. Требования к техническим средствам для уполномоченных органов.
4. Тайна связи: ограничения на доступ сотрудников к переписке.
5. Ответственность за неисполнение.

Как проверяем

Заключение отвечает на все пять вопросов конкретно, без формулировок «возможно потребуется».

Зачем

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

Что делаем

1. Расчёт объёма контура на горизонте трёх лет при разных сценариях роста числа ящиков.
2. Стоимость хранения, резервирования и эксплуатации контура.
3. Стоимость технических средств и их сопровождения.
4. Сравнение с ожидаемой выручкой почтового направления.

Как проверяем

Расчёт воспроизводим по описанной методике третьим лицом.

Зачем

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

Что делаем

1. Требования к оборудованию и его размещению.
2. Поставщики и сроки поставки.
3. Влияние на архитектуру: точки подключения, изоляция контуров.
4. План внедрения и согласования.

Как проверяем

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

Зачем

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

Что делаем

1. Оценка целевой аудитории по сегментам: частные пользователи, малый бизнес, организации.
2. Тарифная сетка: бесплатный объём, платные уровни, почта для домена.
3. Модель окупаемости на горизонте пяти лет с учётом контура хранения.

Как проверяем

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

Зачем

Ворота трека. Решение принимается один раз, на основании расчётов, и записывается.

Что делаем

1. Сопоставление обязательств, стоимости и ожидаемой выручки.
2. Решение с обоснованием.
3. При отказе — письменная фиксация причины, чтобы к вопросу не возвращались каждые полгода.

Как проверяем

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

Зачем

Обязательное требование. Контур независим от пользовательского: пользователь удалил письмо — из его ящика оно исчезло, из контура нет.

Что делаем

1. Отдельное хранилище только на запись, без операций изменения и удаления.
2. Изоляция от пользовательского контура на уровне сети и учётных данных.
3. Журнал любого доступа к контуру.
4. Автоматическое удаление по истечении установленного срока.
5. Процедура предоставления данных по законному запросу с обязательным журналированием.

Как проверяем

Попытка обращения к контуру из пользовательского сервиса отклоняется на уровне сети.

Зачем

Записи домена нужно спланировать до запуска, а одну существующую — обязательно заменить.

Что делаем

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

Как проверяем

Проверка домена по основным чёрным спискам: записей нет.

Зачем

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

Что делаем

1. Приём на стандартном порту с корректной обработкой всех кодов ответа.
2. Лимиты по отправителю, по соединению, по числу получателей.
3. Отложенный первый приём для новых отправителей как дешёвый фильтр массовых рассылок.
4. Отказ на этапе приёма для явного спама: это дешевле, чем принять и удалить.
5. Заимствование решений из открытого сервера с подходящей лицензией.

Как проверяем

Внешние проверочные сервисы не находят замечаний к поведению приёмника.

Зачем

Без проверки подлинности отправителя невозможно ни отличить фишинг от настоящего письма, ни защитить своих пользователей.

Что делаем

1. Проверка политики отправки домена.
2. Проверка цифровой подписи письма.
3. Проверка согласованности домена в видимом поле отправителя с прошедшим проверку — это отдельное требование, и его чаще всего нарушают.
4. Цепочка проверок для пересланных писем: без неё письма из списков рассылки ломают проверку подлинности.
5. Отчёты о результатах проверок отправителям.

Как проверяем

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

Зачем

Отправка сложнее приёма: нужны очереди, повторы, управление репутацией адресов и обработка отказов принимающих сторон.

Что делаем

1. Очереди с повторами и растущими интервалами.
2. Разбор отказов: временный отказ и постоянный обрабатываются по-разному.
3. Пулы адресов отправки.
4. Раздельные пулы для транзакционных писем и рассылок: проблема с рассылкой не должна ронять доставку кодов входа.
5. Подпись всех исходящих писем.

Как проверяем

Учение: недоступный принимающий сервер — письма не теряются и уходят после восстановления.

Зачем

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

Что делаем

1. Политика обязательного шифрования при передаче.
2. Привязка сертификатов к записям домена там, где это возможно.
3. Отчёты о проблемах с шифрованием.
4. Приём и разбор таких отчётов от других серверов.

Как проверяем

Внешние проверочные сервисы подтверждают корректность всех политик.

Зачем

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

Что делаем

1. Приём на портах отправки с обязательной аутентификацией через Yottis ID.
2. Лимиты отправки по аккаунту с учётом возраста аккаунта.
3. Подпись писем от имени пользователя.
4. Проверка, что пользователь отправляет от своего адреса.

Как проверяем

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

Зачем