Waymo2026-03-05
Разбор кейса: Waymo: ML System Design
System design text-to-scene поиск: dual encoder, ANN, temporal segment embeddings, reranker, labeling и drift monitoring.
Этапы
5
Вопросы
11
Практика
11
Кейс простыми словами
Кейс Waymo про внутренний поиск дорожных сцен по тексту. Пользователь такой системы - инженер, safety analyst или команда simulation, которая хочет быстро найти редкие ситуации в логах автономного автомобиля.
Система не должна просто "натравить CLIP на видео". Сначала нужно выбрать единицу поиска: кадр, клип или дорожный segment. Затем использовать существующие perception/map metadata, собрать пары текст-сегмент, построить candidate retrieval и добавить reranker.
В продуктовой выдаче полезен не только список клипов. Система показывает временной интервал, key frames, совпавшие признаки, score/confidence, фильтры и ссылку на исходный лог, чтобы инженер мог быстро проверить сцену.
Карта разбора
5
этапов с вопросами, просадками и сильной структурой ответа.
Быстро подтянуть
4
повторяющихся слабых мест вынесены наверх перед деталями.
Практика
11
связанных вопросов открываются прямо из этапов разбора.
Главные просадки
- Не хватило явной роли пользователя: engineer, safety analyst, simulation team. От роли зависит top-K, recall, latency и формат результата.
- Текущая AV-система была упомянута, но ее outputs можно было сразу превратить в требования и metadata filters.
- Text encoder можно было привязать к доменному словарю Waymo: crosswalk, occlusion, lane merge, unprotected left turn.
- В labels нужно явно отделить weak labels из perception metadata от human-reviewed редких сценариев.
Вопросы для добивки
Этап 1
Постановка: кто ищет сцены и что система возвращает
Что спрашивали
- Интервьюер задал задачу text-to-scene retrieval и уточнил, как учитывать уже существующую autonomous vehicle систему.
- Нужно было связать текстовые запросы, архив дорожных данных и реальных пользователей поиска.
Что было хорошо
- Кандидат быстро понял, что речь про retrieval-систему, а не про обычную классификацию кадров.
- В ответе появилась важная идея: искать нужно не произвольную картинку, а релевантный road segment из последовательности данных.
Где просело
- Не хватило явной роли пользователя: engineer, safety analyst, simulation team. От роли зависит top-K, recall, latency и формат результата.
- Текущая AV-система была упомянута, но ее outputs можно было сразу превратить в требования и metadata filters.
Сильная структура ответа
- 1Сильнее было бы начать с user flow: инженер пишет "pedestrian crossing at night", система возвращает 10-20 секундные segments, показывает key frames, matching tags и ссылку на лог.
- 2Дальше зафиксировать требования: высокий recall для rare safety cases, precision@top для ручной проверки, freshness индекса, фильтры по погоде/дороге/объектам и latency интерактивного поиска.
Этап 2
Текстовые запросы, labels и pairs для обучения
Что спрашивали
- После framing интервьюер спросил про text encoder и про пары "текстовый запрос - дорожный сегмент".
- Этот блок проверял, откуда берется supervised signal для мультимодального поиска.
Что было хорошо
- Кандидат обсуждал text encoder и не забыл про необходимость пар query-segment.
- В ответе появились contrastive learning и идея использовать существующие теги дорожных сцен.
Где просело
- Text encoder можно было привязать к доменному словарю Waymo: crosswalk, occlusion, lane merge, unprotected left turn.
- В labels нужно явно отделить weak labels из perception metadata от human-reviewed редких сценариев.
Сильная структура ответа
- 1Сильнее было бы начать с general sentence encoder или CLIP text tower, затем проверить доменные запросы и дообучить encoder на внутренних query-segment pairs.
- 2Пары собираются из perception tags, scenario metadata, query logs, ручной разметки и synthetic captions после review. Hard negatives нужны для похожих сцен, которые отличаются одной важной деталью.
Этап 3
Представление видео: кадры, segment vectors и ANN index
Что спрашивали
- Интервьюер перешел к dual encoder retrieval для последовательностей изображений.
- Отдельно обсуждались frame embeddings, Vision Transformer для video и незавершенные части retrieval до reranker.
Что было хорошо
- Кандидат правильно двигался к dual encoder: text tower кодирует запрос, visual/temporal tower кодирует segment.
- Было понятно, что каждый кадр отдельно индексировать шумно, а сегмент дает больше контекста.
Где просело
- Нужно было четче выбрать window: сколько секунд в сегменте, нужен ли overlap и что делать с событием на границе окна.
- ANN index, versioning embeddings, metadata store и freshness индекса можно было проговорить до reranker.
Сильная структура ответа
- 1Сильнее было бы описать pipeline: режем поездки на sliding windows, считаем frame embeddings, агрегируем их pooling/temporal attention, сохраняем segment embedding и metadata.
- 2Для поиска строим ANN index, храним encoder version, source clip id, time interval, perception tags и quality flags. Candidate stage отдельно оценивается recall@K, потому что reranker не найдет сцену, которая не попала в кандидаты.
Этап 4
Reranker, metadata-признаки и ответ пользователю
Что спрашивали
- Дальше разговор перешел к reranker, metadata features и мониторингу деградации retrieval.
- Интервьюер хотел увидеть, как candidate retrieval превращается в полезную выдачу для инженера.
Что было хорошо
- Кандидат начал добавлять metadata и думал про drift embedding-распределений.
- В ответе прозвучали pedestrians, trajectories, map/location metadata и score distributions.
Где просело
- Metadata-признаки стоит описывать как входы reranker, а не как отдельный список слов.
- Мониторинг качества нужно связать с action: human review top-K, fixed regression queries, slice metrics и alerts по empty results/index lag.
Сильная структура ответа
- 1Сильнее было бы сказать: reranker получает top-K segments, query, similarity scores, object counts, trajectories, road type, weather, time, location, model versions и quality flags.
- 2Продукт возвращает clips с временным интервалом, key frames, совпавшими tags и confidence. Качество измеряется nDCG/Recall@K, precision@top для review и slices по ночи, дождю, пешеходам и перекресткам.
Этап 5
Simulation data: где стоимость и как не заменить реальные логи
Что спрашивали
- В конце прозвучал follow-up про bottleneck генерации synthetic/simulation data.
- Это не центральный блок retrieval, но он важен для редких дорожных сценариев.
Что было хорошо
- Кандидат увидел, что synthetic data может помочь с редкими cases.
Где просело
- Нужно было назвать не только compute/rendering, но и сценарный дизайн, проверку реализма и domain gap.
- Simulation нельзя подать как замену реальным логам без human-reviewed validation.
Сильная структура ответа
- 1Сильнее было бы сказать: bottleneck находится в выборе сценариев, вариациях, physics/behavior realism, labels и проверке, что synthetic examples похожи на реальные логи.
- 2В retrieval simulation полезна как augmentation и hard negatives. Финальную оценку команда делает на real-world logs и ручной проверке редких safety slices.
Практика по просадкам
Термины
- Segment
- Короткий временной фрагмент поездки, например 5-20 секунд. Его удобнее искать, чем одиночный кадр, потому что дорожное событие развивается во времени.
- Dual encoder
- Архитектура, где текстовый запрос и visual segment кодируются отдельно, а поиск идет по близости embeddings.
- ANN index
- Индекс approximate nearest neighbors, который быстро находит похожие segment embeddings в большом архиве.
- Hard negative
- Похожий, но нерелевантный пример. Для запроса про пешехода ночью hard negative может быть сцена с пешеходом днем.
- Slice metrics
- Метрики по важным подгруппам: ночь, дождь, пешеходы, перекрестки, construction zones. Они показывают деградацию, которую средняя метрика скрывает.