Рантайм

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

Счёт: индекс 100 ГБ, вычислительный слой 4 ГБ. При восьми репликах монолит держит 832 ГБ, разнесённая система — 232 ГБ, в 3.6 раза меньше; разница это шесть лишних копий индекса.

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

Сразу после кандидатогенерации. Две причины.

Первая: иначе тратим дорогое время инференса на айтемы, про которые заранее знаем, что не покажем. При бюджете в 500 кандидатов и 30% отсева поздний фильтр оставляет 350 полезных вместо 500 — это на 43% меньше за те же деньги.

Вторая: выдача может оказаться короткой, что роняет бизнес-метрики. Чтобы гарантированно показать 20 позиций при 30% отсева, надо поскорить 29, иначе дозапрос и рост времени ответа.

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

Тем, что весь трафик одномоментно уходит вниз по стеку, к которому он не готов. И зависимость контринтуитивна: чем лучше работал кеш, тем сильнее удар. При hit rate 0.95 нижний слой рассчитан на 5% трафика и получает 100% — скачок в 20 раз; при 0.99 — в 100 раз.

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

k хеш-функций и битовый массив длины m. При вставке ставим единицы по хешам, при проверке смотрим те же позиции. Вероятность ложного срабатывания \((1 - e^{-kn/m})^k\), оптимум \(k^* = (m/n)\ln 2\), и при нём занята ровно половина бит.

Кривая по k U-образная: при m = 8000 и n = 1000 один хеш даёт 11.75%, шесть — 2.16%, двенадцать — снова 4.83%. Мало хешей — мало различающей силы, много — фильтр забивается.

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

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

Ключевое — зачем нужна интегральная часть. Пропорциональный регулятор даёт воздействие, пропорциональное ошибке, значит при нулевой ошибке нет и буста: система живёт с постоянным недобором. В симуляции при I = 0 доля стабилизируется на 12% вместо 30% — промах 17.7 п.п., и усиление P до 2 сокращает его только до 12.7, добавляя колебания. Убирает статическую ошибку исключительно I.

Обратная сторона — слишком большой P раскачивает контур: при P = 3 разгон доходит до 58% против цели 30%.

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

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

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

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

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

Главное: если вы давно не тестировали свою тыкву, значит, у вас её скорее всего уже нет.

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

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