IR на собеседовании (FAANG)

Представь: финальный раунд собеседования в Google. Интервьюер задаёт вопрос: «Спроектируй поиск Google». 45 минут. Слабый кандидат начинает с формулы TF-IDF. Сильный кандидат сначала уточняет масштаб (сколько документов? RPS? latency?), потом строит каскадную архитектуру и обсуждает компромиссы. Эти 45 минут показывают не знание формул, а способность мыслить системно - то самое, ради чего FAANG нанимает senior-инженеров.

• **Google search infrastructure** - 100+ миллиардов проиндексированных страниц, latency p99 < 200ms; именно эта архитектура - предмет собеседований
• **Elasticsearch / OpenSearch** - индустриальный стандарт для doc-based sharding с replication; используется в Netflix, GitHub, Stack Overflow
• **Lambda architecture в Twitter Search** - real-time индекс твитов плюс batch индекс старых постов; знаменитый пример успешного применения паттерна

Вопросы про ранжирование

Классический вопрос с собеседования в Google: «Как бы вы построили ранкер для поиска по веб-страницам, имея 100 миллиардов документов?». Сильный кандидат не бросается сразу в TF-IDF или BM25. Сначала уточняются требования: какой latency budget (50ms? 200ms?), какое recall vs precision соотношение нужно, есть ли личные сигналы пользователя. Потом строится pipeline: candidate generation (inverted index + ANN) -> early ranking (lightweight model) -> deep ranking (BERT/cross-encoder) -> re-ranking с бизнес-сигналами.

Типичная ловушка - предложить один тяжёлый ранкер. На 100 миллиардов документов даже самый быстрый cross-encoder невыполним: 100B документов * 10ms = 30+ лет на запрос. Правильный ответ - каскад: inverted index сужает до ~10K кандидатов, lightweight model (gradient boosting на TF-IDF + PageRank) - до ~1K, тяжёлый BERT-ranker - до top-100, бизнес-логика - до top-10. Каждый уровень дороже, но кандидатов меньше.

Вопросы про индексацию

Вопрос: «Как организовать обновление индекса для быстро меняющегося контента (новости, твиты)?». Слабый ответ: «Перестраиваю весь индекс каждый час». На 100B документов это невозможно (часы построения, гигабайты диска). Сильный ответ - **lambda architecture**: фоновый главный индекс (обновляется раз в день), плюс real-time delta-index (свежие документы за последний час). Поиск идёт по обоим индексам параллельно, результаты мержатся.

Тонкости: real-time index часто хранится в памяти, без сжатия, оптимизирован под insertion. Главный индекс - на диске, сжат через delta-encoding и Variable-Byte. Когда delta-index переполняется (скажем, миллион документов), запускается incremental merge: старые документы переносятся в главный, а на их место приходят новые. Это - известная задача LSM-tree, та же логика что в Cassandra и LevelDB.

Вопросы про оценку качества

Вопрос: «Как оценить качество вашего поискового ранкера?». Слабый ответ: «Считаю precision@10». Сильный ответ начинается с уточнения: офлайн-метрики или онлайн? Офлайн - NDCG@10 на размеченных пулах из manual judgments или click data; online - A/B тесты с метриками CTR, dwell time, abandonment rate, success rate. Главная ловушка - оптимизировать только офлайн: ранкер может улучшить NDCG, но ухудшить пользовательский опыт из-за clickbait или sensitive content.

Тренды: NDCG@10 (Discounted Cumulative Gain) учитывает позицию релевантного результата, что критично - результат на позиции 1 ценнее, чем на позиции 10. MRR (Mean Reciprocal Rank) - быстрый sanity check для топ-1 поиска. Online: A/B тесты разделяют пользователей 50/50 на старый и новый ранкер, метрики собираются 1-2 недели для статистической значимости. Sequential testing позволяет остановить эксперимент раньше при сильном эффекте.

System Design: типичные сценарии

Финальный вопрос: «Спроектируйте поиск по 1 миллиарду документов с RPS 10K и latency 100ms». Хороший ответ строится по шагам: (1) capacity planning - сколько шардов нужно, исходя из размера индекса и RAM на машину; (2) sharding - по doc_id (равномерно) или по hash(token) (term-based); (3) replication - x2-x3 для отказоустойчивости и load balancing; (4) caching - топ-N популярных запросов кэшируются на edge, ~50% всех запросов читаются из кэша.

Decision points: doc-based sharding проще, каждый шард делает локальный top-K, потом aggregator мержит; term-based sharding эффективнее по диску, но требует синхронной координации между шардами для каждого запроса. Production-системы (ElasticSearch, Solr) используют doc-based. Latency budget на каждый компонент: parse (5ms), candidate retrieval (30ms), ranking (40ms), aggregation+formatting (15ms), сетевые накладные расходы (10ms) = 100ms.

Ключевые идеи

• **Каскадное ранжирование** - inverted index -> lightweight scorer -> heavy ranker -> business rules; стандартный паттерн для масштабов FAANG
• **Lambda architecture** - real-time delta-индекс плюс batch главный индекс; решает компромисс между freshness и стоимостью полного перестроения
• **NDCG vs A/B тесты** - офлайн-метрики измеряют exact-match разметки, online-метрики ловят реальное поведение; оба нужны
• **Doc-based sharding** - стандарт production-систем; embarrassingly parallel, без межшардовой координации, лёгкая балансировка нагрузки

Связанные темы

Возврат к мотивации: вопросы FAANG - не отдельная дисциплина, а синтез всего курса. Связь с предыдущими уроками:

• Learning to Rank — Лежит в основе всех ранкеров верхнего уровня; gradient boosting и cross-encoder - то, что упоминается на собеседованиях
• Inverted Index — Базовая структура нижнего уровня каскада; lambda-архитектура - продолжение этой идеи в реальном времени
• Evaluation Metrics — NDCG, MRR, MAP - офлайн-метрики, через которые оценивается работа кандидата на собеседовании

Вопросы для размышления

• Если каскадное ранжирование настолько эффективно, почему многие startups вначале используют один тяжёлый ранкер? Какие сигналы говорят, что пора переходить на каскад?
• На собеседовании спросили: «Ваш ранкер выдаёт высокий NDCG, но пользователи жалуются». Какие гипотезы стоит проверить в первую очередь и почему?
• Возврат к мотивации: интервьюер за 45 минут ищет не правильный ответ, а способ думать. Какие вопросы должен задавать сам кандидат, чтобы продемонстрировать инженерное мышление?

Связанные уроки

• ir-13 — System design - база для interview вопросов
• ir-02 — Инвертированный индекс - фундаментальный вопрос
• ir-10 — Метрики оценки - обязательная тема на собеседовании
• ir-05 — Neural ranking - продвинутый трек FAANG интервью
• alg-01-big-o — Сложность поиска - Big-O вопросы в контексте IR
• ds-01-intro — Distributed search - пересечение IR и distributed systems
• ml-01-intro