Спроектируйте мультиязычную NLP-платформу для 12 продуктовых команд, 20 языков и 50 миллионов документов в день с доступностью 99,9% и месячным бюджетом $180 000.

Я бы построил общие слои загрузки данных, обучения, оценки, реестра и инференса, оставив специализированные модели за стабильными контрактами. - Kafka и Spark однократно нормализуют документы, сохраняют исходный текст, язык, арендатора и происхождение, затем публикуют версионированные признаки для классификации, NER и поиска. - API платформы предоставляет асинхронные пакетные задания и низколатентные эндпоинты, а квоты и изолированные пространства имен Kubernetes не дают трафику одной команды исчерпать ресурсы другой. - XLM-R служит мультиязычной базовой моделью, но языки с большим трафиком получают отдельные энкодеры только тогда, когда метрики среза оправдывают дополнительные расходы на поддержку. - Я распределю бюджет по измеренным часам CPU и GPU каждой команды, а релизы буду блокировать по качеству каждого языка, p99 задержки и готовности отката.

Десяти командам нужно добавить 30 NLP-задач за 12 месяцев, но в платформенной команде 6 инженеров, а интеграция каждой задачи должна занимать меньше 2 недель. Как вы определите архитектурные контракты?

Я бы стандартизировал контракты данных, моделей, оценки и инференса, а не пытался поместить все задачи в одну модель. - Пакет каждой задачи объявляет схему входа, схему меток, токенизатор, артефакт модели, политику калибровки и метрики в версионированном манифесте, проверяемом в CI. - Общие SDK отвечают за трассировку, батчинг, проверку признаков и доступ к реестру, а команды задач владеют метками, порогами приемки и анализом ошибок. - Обратно совместимые REST- и пакетные интерфейсы скрывают детали PyTorch, spaCy или ONNX, поэтому модель можно заменить без десяти миграций клиентов. - Эталонная задача и контрактные тесты делают цель в 2 недели измеримой, а исключение требует архитектурного ревью с явно назначенным владельцем поддержки.

Спроектируйте классификацию 80 миллионов документов в день по 120 меткам и 6 языкам с пакетным SLA 30 минут и бюджетом $0,20 на 1 000 документов.

Я бы использовал двухэтапный классификатор, где дешевые разреженные признаки обрабатывают очевидные документы, а компактный мультиязычный энкодер разбирает неуверенные случаи. - Spark выполняет нормализацию и инференс TF-IDF по партициям, направляя только примеры с малым отрывом между классами в дистиллированный классификатор XLM-R. - Выходной слой поддерживает калиброванные вероятности для нескольких меток, а пороги настраиваются отдельно по каждой метке с учетом цены precision и recall, а не фиксируются на 0,5. - ONNX Runtime на CPU обслуживает оба этапа крупными пакетами, а GPU добавляются только если измеренный пакетный тест укладывается в целевую стоимость. - Пропускная способность, возраст очереди, macro-F1 и recall по языкам служат эксплуатационными и релизными гейтами, а старый артефакт остается доступен для немедленного перезапуска пакета.

Классификатор поддержки в реальном времени должен обрабатывать 6 000 запросов в секунду на 8 языках, держать p99 ниже 80 мс, достигать macro-F1 0,88 и работать на 160 ядрах CPU. Что вы развернете?

Я бы развернул дистиллированный мультиязычный энкодер в ONNX с быстрым путем на правилах для точных и надежных шаблонов. - Запросы маршрутизируются по языку и длине и динамически объединяются в пакеты не дольше чем на 8 мс, чтобы увеличить пропускную способность в пределах бюджета 80 мс. - INT8-квантизация принимается только при потере менее 0,5 пункта F1 на каждом языке, а длинные входы обрезаются по приоритетам разделов задачи, а не по сырому числу символов. - Реплики Kubernetes масштабируются по числу одновременных запросов и ожиданию пакета, а при перегрузке запрос попадает в ограниченную очередь, после чего сервис просит повторить его позже или явно отказывается от классификации, но не возвращает выдуманную резервную метку. - Перед решением о небольшом пуле GPU вместо 160 ядер CPU я сравню фактическую загрузку ядер и p99 по группам длины.

Спроектируйте распознавание вложенных именованных сущностей на 40 миллионах юридических страниц в месяц для 35 типов сущностей и глубины вложенности до 3, с span-F1 выше 0,90 и ресурсом 20 аннотаторов.

Я бы использовал энкодер с классификацией спанов, потому что плоская BIO-разметка не представляет нужную вложенность. - Кандидатные спаны отсекаются по максимальной длине и оценкам границ, затем классифицируются с отдельными порогами по типам для ограничения квадратичной стоимости. - Разметка хранит каждый спан с родительскими связями и явными правилами пересечений, а двойная разметка 10% данных измеряет согласие по типу и глубине вложенности. - Оценка показывает точный и частичный span-F1 и отдельные срезы для сканов, длинных положений и сущностей третьего уровня, чтобы общий результат не скрывал сбои. - Продакшн-пайплайн сохраняет символьные смещения при нормализации OCR и отправляет неуверенные или структурно некорректные результаты в очередь 20 проверяющих.

Нужно извлекать 18 типов сущностей и 12 типов отношений из 30 миллионов контрактов в квартал, завершать ночной пакет за 6 часов и держать долю ложных обязательств ниже 1%. Как вы спроектируете систему?

Я бы разделил извлечение кандидатных сущностей и классификацию отношений и оптимизировал класс обязательств по precision. - Сначала доменный энкодер выделяет спаны, затем модель отношений оценивает только совместимые по типу пары внутри одного пункта или связанного раздела, избегая комбинаторного роста. - Детерминированные правила контрактов проверяют даты, суммы и обязательные роли аргументов, но отклоняют невозможные структуры, а не додумывают отсутствующие выходы модели. - Spark распределяет работу по контрактам и группирует документы сходной длины на GPU, а результаты OCR и парсинга кешируются, чтобы повторный инференс не дублировал загрузку данных. - Релизные гейты включают точный span-F1, F1 отношений, precision обязательств выше 99% и слепую проверку минимум 1 000 контрактов.

Спроектируйте разрешение сущностей для 250 миллионов клиентских записей на латинице, кириллице, арабском письме и иероглифах, с 2 миллионами обновлений в день, precision выше 99,5% и SLA сверки 4 часа.

Я бы разделил блокировку кандидатов, мультиязычную оценку пар и осторожное формирование кластеров. - Для блокировки используются нормализованные телефоны, адреса электронной почты, транслитерированные ключи имен и фонетические признаки с учетом региона, причем несколько ключей сохраняют recall между системами письма. - Попарная модель объединяет символьные энкодеры, признаки адреса и точные идентификаторы, а пороги калибруются по странам и системам письма из-за разных распределений оценок. - Слияния кластеров требуют транзитивной согласованности и сильных доказательств, а неоднозначные пары остаются разделенными для проверки, потому что ложное слияние сложнее отменить, чем пропуск. - Ежедневные обновления пересчитывают только затронутые блоки и кластеры, а выборочная ручная проверка измеряет precision пар и чистоту кластеров до продвижения.

Спроектируйте иерархическую классификацию по таксономии из 4 000 узлов и 7 уровней для 10 миллионов описаний товаров в день, с точностью верхнего уровня выше 98% и leaf macro-F1 выше 0,75.

Я бы использовал энкодер с учетом иерархии и ограниченное декодирование, чтобы каждый предсказанный лист имел допустимый путь предков. - Общий текстовый энкодер передает представления в отдельные выходные слои уровней, а функция потерь усиливает редкие листья, сохраняя обильный сигнал верхнего уровня. - При инференсе на каждом уровне остаются лучшие кандидатные ветви, что сокращает оценку 4 000 классов и дает уверенность на каждом шаге решения. - Оценка показывает точность пути, иерархический F1, точность верхнего уровня и leaf macro-F1, включая покрытие случаев отказа при низкой уверенности. - Узлы таксономии имеют неизменяемые ID и даты действия, поэтому переименования меток не портят историю обучения и аналитику.

У многометочного классификатора 600 меток, в среднем 15 меток на документ, 2 миллиона размеченных примеров и цель p95 120 мс при 1 500 запросах в секунду. Как вы обработаете дисбаланс и инференс?

Я бы объединил общий энкодер, генерацию кандидатных меток и калибровку по каждой метке. - Частые метки обучаются с асимметричной функцией потерь или управляемой выборкой отрицательных примеров, а редкие получают целевую разметку вместо произвольного увеличения выборки. - Легкий первый слой сокращает 600 меток примерно до 50 кандидатов, после чего более точный слой оценивает только их в пределах задержки. - Пороги выбираются отдельно по каждой метке из кривых precision-recall с минимальным требованием к объему данных, а для слабо представленных меток предусмотрен отказ. - Динамический батчинг ONNX и группы длины тестируются на 1 500 запросах в секунду, а macro-F1 и покрытие меток блокируют релиз.

Пять бизнес-подразделений еженедельно меняют таксономию из 2 500 меток, при этом 300 миллионов исторических документов должны оставаться воспроизводимыми, а новые метки должны запускаться за 24 часа. Как вы организуете эволюцию таксономии?

Я бы версионировал таксономию отдельно от артефактов моделей и указывал обе версии в каждом предсказании. - Стабильные ID узлов сохраняются при переименовании, а разделения, слияния, устаревание и смена родителя записываются как явные сопоставления с датами действия. - Обучающие снимки материализуют метки в одной версии таксономии и никогда молча не переписывают историю при изменении бизнес-иерархии. - Слой совместимости может сопоставить старые предсказания новым родителям для отчетов, но разделенные листья требуют повторной классификации, поскольку однозначного сопоставления нет. - Еженедельные релизы проходят тесты покрытия и согласованности иерархии, затем теневой прогон на свежем трафике до окна продвижения в 24 часа.

Спроектируйте экстрактивный QA по 20 миллионам фрагментов политик на 6 языках, без генерации ответов, с p99 ниже 350 мс, exact match выше 75% и 2 000 запросов в секунду.

Я бы извлекал ограниченный набор кандидатов и запускал экстрактивную модель выбора спана с возможностью отказа при недостатке доказательств. - BM25 и мультиязычный bi-encoder извлекают около 100 фрагментов, reciprocal rank fusion сокращает набор, а cross-encoder выбирает 8 лучших для чтения. - Модель чтения предсказывает начало, конец и оценку отсутствия ответа, затем возвращает точный исходный спан с ID документа, смещениями и версией политики. - Компоненты получают отдельные бюджеты задержки и кеши: около 120 мс на поиск и 180 мс на пакетный инференс модели чтения в пик. - Релизные гейты охватывают recall поиска, exact match, token F1, точность отсутствия ответа и корректность ссылки на источник по каждому языку.

Спроектируйте семантический корпоративный поиск по 100 миллионам документов для 40 000 сотрудников, 3 000 запросов в секунду, p95 ниже 250 мс и контролем доступа на уровне документа.

Я бы использовал BM25, поиск по плотным представлениям и небольшой cross-encoder для переранжирования, применяя авторизацию до возврата результатов. - Раздельные лексический и векторный индексы сохраняют точные идентификаторы и семантические совпадения, затем reciprocal rank fusion формирует около 200 кандидатов. - Фильтры арендатора и ACL компилируются в фильтры индекса или выбор шарда до оценки, а не применяются после извлечения закрытого содержимого. - Переранжировщик оценивает только 50 лучших кандидатов в фиксированном бюджете задержки, а сниппеты берутся из совпавших исходных спанов без генерации текста. - Качество поиска измеряется NDCG@10, recall@50, долей пустых результатов и срезами по подразделениям на оцененных запросах реальных сотрудников.

Сервис семантического поиска обрабатывает 5 000 запросов в секунду и имеет 70 мс на переранжирование 200 кандидатов при бюджете 8 GPU A10. Как вы выберете архитектуру переранжировщика?

Я бы отверг обычный cross-encoder на 50 кандидатах, если аппаратный тест не опровергнет расчет мощности. - При 5 000 запросах в секунду 50 кандидатов требуют 250 000 оценок пар в секунду, или 31 250 на одну A10 без запаса, что нереалистично для обычного cross-encoder. - Для всех 200 кандидатов я применю позднее взаимодействие или легкий дистиллированный переранжировщик, а cross-encoder оставлю для намного меньшего набора, например 8 лучших. - Офлайн-тесты сравнивают NDCG@10 при разном числе кандидатов и на сложных срезах запросов, чтобы сокращение финального набора обосновывалось релевантностью, а не только задержкой. - Релизный гейт требует измеренной пиковой пропускной способности и p99 ниже 70 мс на всех 8 A10 при продакшн-длинах и запасе мощности минимум 30%; иначе я отвергну заданную конфигурацию оборудования.

Спроектируйте дедупликацию 2 миллиардов предложений на 14 языках с recall дублей 95%, долей ложных слияний меньше 0,5% и окном Spark 12 часов.

Я бы объединил точное хеширование, генерацию кандидатов с учетом локальности и мультиязычную модель сходства. - Хеши после Unicode-нормализации и MinHash дешево удаляют точные и близкие по шинглам дубли до работы энкодеров. - Для оставшихся предложений строятся компактные мультиязычные эмбеддинги, затем языковые ANN- или LSH-блоки создают пары кандидатов вместо полного попарного сравнения. - Калиброванный классификатор пар подтверждает кандидатов и использует более строгие пороги для коротких предложений, где общие фразы вызывают ложные слияния. - Spark распределяет данные по хеш-блокам и языкам, а размеченный людьми набор пар контролирует recall дублей и предел ложных слияний 0,5%.

Новостной архив получает 5 миллионов статей в день и должен связывать близкие дубли за 10 минут на 12 языках, сохраняя кластеры за 3 года. Как вы спроектируете инкрементальное сопоставление?

Я бы поддерживал разделенный по времени индекс мультиязычных эмбеддингов и долговечные метаданные кластеров. - Сначала точные хеши URL и содержимого устраняют повторы доставки, затем эмбеддинги новых статей ищут семантических кандидатов в свежих партициях и выбранных постоянных кластерах. - Модель пар объединяет заголовок, текст, источник, время и пересечение именованных сущностей, а пороги калибруются по языку и длине статьи. - Назначение в кластеры выполняется с журналом явных слияний, чтобы ошибочные объединения можно было отменить без перестроения 3 лет истории. - Kafka передает новые статьи, потоковые обработчики соблюдают SLA 10 минут, а ночная сверка находит кандидатов, пропущенных из-за задержки индекса.

Спроектируйте машинный перевод для 8 языковых пар, 100 миллионов символов в день, p95 ниже 900 мс для интерактивного текста, COMET выше 0,82 и месячного бюджета GPU $90 000.

Я бы использовал одну мультиязычную encoder-decoder модель как основу и выделял отдельные модели только парам, где качество или объем оправдывают это. - Обучающие данные дедуплицируются, балансируются по языковым парам, маркируются по доменам и фильтруются по качеству выравнивания до supervised seq2seq-обучения. - Интерактивные запросы используют динамический батчинг TensorRT с коротким ожиданием, а большие файлы идут в оптимизированную по пропускной способности пакетную очередь на тех же версионированных моделях. - Оценка сочетает COMET, BLEU, точность терминологии и слепую человеческую оценку адекватности и беглости для каждой пары и домена. - Планирование мощности выделяет прогретые GPU-реплики по трафику пар, а резерв на CPU для малых пар допускается только после подтверждения цели 900 мс.

Спроектируйте абстрактивную суммаризацию 5 миллионов финансовых отчетов в месяц длиной до 20 000 слов, с итогом до 300 слов, точностью чисел 98% и ночным SLA 6 часов.

Я бы использовал специализированный encoder-decoder суммаризатор с иерархическим кодированием документа и явной проверкой чисел. - Отчеты сегментируются по структурным заголовкам, представления разделов объединяются, а декодер обучается только на утвержденных парах отчетов и итогов. - Механизм копирования или ограниченный словарь чисел снижает искажения, а детерминированные валидаторы связывают каждое число с сущностью, отчетным периодом, валютой и единицей измерения до сравнения с источником. - Оценка включает ROUGE для покрытия, тесты фактической согласованности, точность чисел выше 98% и слепые оценки аналитиков минимум на 500 отчетах в релиз. - Spark планирует пакеты сходной длины на GPU, а отчеты, не прошедшие проверку, удерживаются для ручного ревью и не публикуются автоматически.

Система медицинского перевода охватывает 4 языковые пары и 18 000 обязательных терминов, обрабатывает 20 запросов в секунду и должна держать точность терминологии выше 99% при p95 ниже 1,2 секунды. Как вы обеспечите терминологию?

Я бы объединил доменно адаптированное seq2seq-обучение, декодирование с учетом терминологии и обнаружение терминов в исходном тексте. - Терминологическая база версионируется по языковой паре, специальности и дате действия и содержит морфологические варианты вместо буквальной замены строк. - Обучение смешивает параллельные медицинские тексты и синтетические примеры с терминами, но документы пациентов и списки терминов из одного источника не пересекаются с тестом. - При инференсе найденные термины направляют или ограничивают декодер только при надежном выравнивании, не создавая неграмматичных принудительных подстановок. - Релизные гейты включают COMET, ревью врачей, точность терминологии 99% и задержку при худшей плотности терминов.

Спроектируйте платформу аннотирования для 300 аннотаторов, 6 языков, 4 NLP-команд, 2 миллионов объектов в квартал и доступности 99,95% в рабочее время.

Я бы построил мультитенантную систему задач с версионированными схемами, назначением работы, контролем качества и неизменяемыми событиями разметки. - Определения задач поддерживают спаны, вложенные сущности, отношения, многометочные классы и спаны QA, не заставляя команды использовать свободный JSON. - Планировщик учитывает языковые навыки, сертификацию проверяющих, эталонные объекты и целевую долю двойной разметки, не показывая аннотаторам тестовые данные. - Каждое изменение хранит аннотатора, версию инструкции, время и версию исходных данных, позволяя проводить арбитраж и воспроизводить выгрузки датасетов. - Глубина очереди, задержка сохранения, расхождение, точность на эталонах и свежесть выгрузок контролируются отдельно по командам и языкам.

Двадцать аннотаторов размечают вложенные сущности на 3 языках, согласие равно 0,61, цель 0,80 за 4 недели, а доступно только 160 часов экспертов. Как вы измените инструкции и арбитраж?

Я бы потратил часы экспертов на самые частые причины расхождений и превратил каждое решение в проверяемый пример инструкции. - Матрица расхождений по типу сущности, границе, вложенности и языку показывает, связана ли проблема с неоднозначностью, переводом или инструментом. - Два эксперта совместно разбирают стратифицированную выборку, затем публикуют положительные, отрицательные и граничные примеры в новой неизменяемой версии инструкции. - Аннотаторы проходят сертификационный набор и получают еженедельную обратную связь, а продакшн-объекты размечаются дважды, пока каждый язык не превысит 0,80. - Согласие измеряется span-aware F1 и оценками по типам, а не одним числом на уровне токенов, скрывающим ошибки вложенных границ.

Вопросы на собеседовании: NLP-инженер

100 реальных вопросов с образцовыми ответами и пояснениями для уровня Senior NLP-инженер.

Смотреть пример резюме: NLP-инженер →

Тренировка флешкарточками

Интервальное повторение · Hunter Pass

Вопросы

nlpdesign

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

Kafka и Spark однократно нормализуют документы, сохраняют исходный текст, язык, арендатора и происхождение, затем публикуют версионированные признаки для классификации, NER и поиска.
API платформы предоставляет асинхронные пакетные задания и низколатентные эндпоинты, а квоты и изолированные пространства имен Kubernetes не дают трафику одной команды исчерпать ресурсы другой.
XLM-R служит мультиязычной базовой моделью, но языки с большим трафиком получают отдельные энкодеры только тогда, когда метрики среза оправдывают дополнительные расходы на поддержку.
Я распределю бюджет по измеренным часам CPU и GPU каждой команды, а релизы буду блокировать по качеству каждого языка, p99 задержки и готовности отката.

Зачем это спрашивают: Интервьюер проверяет, умеет ли кандидат отделять переиспользуемую NLP-инфраструктуру от ответственности за отдельные задачи в масштабе организации.

nlparchitecture

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

Пакет каждой задачи объявляет схему входа, схему меток, токенизатор, артефакт модели, политику калибровки и метрики в версионированном манифесте, проверяемом в CI.
Общие SDK отвечают за трассировку, батчинг, проверку признаков и доступ к реестру, а команды задач владеют метками, порогами приемки и анализом ошибок.
Обратно совместимые REST- и пакетные интерфейсы скрывают детали PyTorch, spaCy или ONNX, поэтому модель можно заменить без десяти миграций клиентов.
Эталонная задача и контрактные тесты делают цель в 2 недели измеримой, а исключение требует архитектурного ревью с явно назначенным владельцем поддержки.

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

designbatchclassification

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

Spark выполняет нормализацию и инференс TF-IDF по партициям, направляя только примеры с малым отрывом между классами в дистиллированный классификатор XLM-R.
Выходной слой поддерживает калиброванные вероятности для нескольких меток, а пороги настраиваются отдельно по каждой метке с учетом цены precision и recall, а не фиксируются на 0,5.
ONNX Runtime на CPU обслуживает оба этапа крупными пакетами, а GPU добавляются только если измеренный пакетный тест укладывается в целевую стоимость.
Пропускная способность, возраст очереди, macro-F1 и recall по языкам служат эксплуатационными и релизными гейтами, а старый артефакт остается доступен для немедленного перезапуска пакета.

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

latencydeployment

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

Запросы маршрутизируются по языку и длине и динамически объединяются в пакеты не дольше чем на 8 мс, чтобы увеличить пропускную способность в пределах бюджета 80 мс.
INT8-квантизация принимается только при потере менее 0,5 пункта F1 на каждом языке, а длинные входы обрезаются по приоритетам разделов задачи, а не по сырому числу символов.
Реплики Kubernetes масштабируются по числу одновременных запросов и ожиданию пакета, а при перегрузке запрос попадает в ограниченную очередь, после чего сервис просит повторить его позже или явно отказывается от классификации, но не возвращает выдуманную резервную метку.
Перед решением о небольшом пуле GPU вместо 160 ядер CPU я сравню фактическую загрузку ядер и p99 по группам длины.

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

designcapacity

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

Кандидатные спаны отсекаются по максимальной длине и оценкам границ, затем классифицируются с отдельными порогами по типам для ограничения квадратичной стоимости.
Разметка хранит каждый спан с родительскими связями и явными правилами пересечений, а двойная разметка 10% данных измеряет согласие по типу и глубине вложенности.
Оценка показывает точный и частичный span-F1 и отдельные срезы для сканов, длинных положений и сущностей третьего уровня, чтобы общий результат не скрывал сбои.
Продакшн-пайплайн сохраняет символьные смещения при нормализации OCR и отправляет неуверенные или структурно некорректные результаты в очередь 20 проверяющих.

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

system-designdesignbatch

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

Сначала доменный энкодер выделяет спаны, затем модель отношений оценивает только совместимые по типу пары внутри одного пункта или связанного раздела, избегая комбинаторного роста.
Детерминированные правила контрактов проверяют даты, суммы и обязательные роли аргументов, но отклоняют невозможные структуры, а не додумывают отсутствующие выходы модели.
Spark распределяет работу по контрактам и группирует документы сходной длины на GPU, а результаты OCR и парсинга кешируются, чтобы повторный инференс не дублировал загрузку данных.
Релизные гейты включают точный span-F1, F1 отношений, precision обязательств выше 99% и слепую проверку минимум 1 000 контрактов.

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

reactdesign

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

Для блокировки используются нормализованные телефоны, адреса электронной почты, транслитерированные ключи имен и фонетические признаки с учетом региона, причем несколько ключей сохраняют recall между системами письма.
Попарная модель объединяет символьные энкодеры, признаки адреса и точные идентификаторы, а пороги калибруются по странам и системам письма из-за разных распределений оценок.
Слияния кластеров требуют транзитивной согласованности и сильных доказательств, а неоднозначные пары остаются разделенными для проверки, потому что ложное слияние сложнее отменить, чем пропуск.
Ежедневные обновления пересчитывают только затронутые блоки и кластеры, а выборочная ручная проверка измеряет precision пар и чистоту кластеров до продвижения.

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

classificationdesign

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

Общий текстовый энкодер передает представления в отдельные выходные слои уровней, а функция потерь усиливает редкие листья, сохраняя обильный сигнал верхнего уровня.
При инференсе на каждом уровне остаются лучшие кандидатные ветви, что сокращает оценку 4 000 классов и дает уверенность на каждом шаге решения.
Оценка показывает точность пути, иерархический F1, точность верхнего уровня и leaf macro-F1, включая покрытие случаев отказа при низкой уверенности.
Узлы таксономии имеют неизменяемые ID и даты действия, поэтому переименования меток не портят историю обучения и аналитику.

Зачем это спрашивают: Интервьюер хочет видеть иерархию в модели, инференсе, метриках и жизненном цикле таксономии, а не плоскую классификацию.

model-serving

Я бы объединил общий энкодер, генерацию кандидатных меток и калибровку по каждой метке.

Частые метки обучаются с асимметричной функцией потерь или управляемой выборкой отрицательных примеров, а редкие получают целевую разметку вместо произвольного увеличения выборки.
Легкий первый слой сокращает 600 меток примерно до 50 кандидатов, после чего более точный слой оценивает только их в пределах задержки.
Пороги выбираются отдельно по каждой метке из кривых precision-recall с минимальным требованием к объему данных, а для слабо представленных меток предусмотрен отказ.
Динамический батчинг ONNX и группы длины тестируются на 1 500 запросах в секунду, а macro-F1 и покрытие меток блокируют релиз.

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

reproducibility

Я бы версионировал таксономию отдельно от артефактов моделей и указывал обе версии в каждом предсказании.

Стабильные ID узлов сохраняются при переименовании, а разделения, слияния, устаревание и смена родителя записываются как явные сопоставления с датами действия.
Обучающие снимки материализуют метки в одной версии таксономии и никогда молча не переписывают историю при изменении бизнес-иерархии.
Слой совместимости может сопоставить старые предсказания новым родителям для отчетов, но разделенные листья требуют повторной классификации, поскольку однозначного сопоставления нет.
Еженедельные релизы проходят тесты покрытия и согласованности иерархии, затем теневой прогон на свежем трафике до окна продвижения в 24 часа.

Зачем это спрашивают: Интервьюер проверяет, рассматриваются ли изменения таксономии как версионированные контракты данных, а не как случайные правки меток.

queriesdesignlatency

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

BM25 и мультиязычный bi-encoder извлекают около 100 фрагментов, reciprocal rank fusion сокращает набор, а cross-encoder выбирает 8 лучших для чтения.
Модель чтения предсказывает начало, конец и оценку отсутствия ответа, затем возвращает точный исходный спан с ID документа, смещениями и версией политики.
Компоненты получают отдельные бюджеты задержки и кеши: около 120 мс на поиск и 180 мс на пакетный инференс модели чтения в пик.
Релизные гейты охватывают recall поиска, exact match, token F1, точность отсутствия ответа и корректность ссылки на источник по каждому языку.

Зачем это спрашивают: Интервьюер хочет полную схему поиска и экстрактивного чтения, которая не переходит к генеративным ответам.

queriesdesign

Я бы использовал BM25, поиск по плотным представлениям и небольшой cross-encoder для переранжирования, применяя авторизацию до возврата результатов.

Раздельные лексический и векторный индексы сохраняют точные идентификаторы и семантические совпадения, затем reciprocal rank fusion формирует около 200 кандидатов.
Фильтры арендатора и ACL компилируются в фильтры индекса или выбор шарда до оценки, а не применяются после извлечения закрытого содержимого.
Переранжировщик оценивает только 50 лучших кандидатов в фиксированном бюджете задержки, а сниппеты берутся из совпавших исходных спанов без генерации текста.
Качество поиска измеряется NDCG@10, recall@50, долей пустых результатов и срезами по подразделениям на оцененных запросах реальных сотрудников.

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

retrievalrerankingarchitecture

Я бы отверг обычный cross-encoder на 50 кандидатах, если аппаратный тест не опровергнет расчет мощности.

При 5 000 запросах в секунду 50 кандидатов требуют 250 000 оценок пар в секунду, или 31 250 на одну A10 без запаса, что нереалистично для обычного cross-encoder.
Для всех 200 кандидатов я применю позднее взаимодействие или легкий дистиллированный переранжировщик, а cross-encoder оставлю для намного меньшего набора, например 8 лучших.
Офлайн-тесты сравнивают NDCG@10 при разном числе кандидатов и на сложных срезах запросов, чтобы сокращение финального набора обосновывалось релевантностью, а не только задержкой.
Релизный гейт требует измеренной пиковой пропускной способности и p99 ниже 70 мс на всех 8 A10 при продакшн-длинах и запасе мощности минимум 30%; иначе я отвергну заданную конфигурацию оборудования.

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

queriesdesignspark

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

Хеши после Unicode-нормализации и MinHash дешево удаляют точные и близкие по шинглам дубли до работы энкодеров.
Для оставшихся предложений строятся компактные мультиязычные эмбеддинги, затем языковые ANN- или LSH-блоки создают пары кандидатов вместо полного попарного сравнения.
Калиброванный классификатор пар подтверждает кандидатов и использует более строгие пороги для коротких предложений, где общие фразы вызывают ложные слияния.
Spark распределяет данные по хеш-блокам и языкам, а размеченный людьми набор пар контролирует recall дублей и предел ложных слияний 0,5%.

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

dedupdesign

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

Сначала точные хеши URL и содержимого устраняют повторы доставки, затем эмбеддинги новых статей ищут семантических кандидатов в свежих партициях и выбранных постоянных кластерах.
Модель пар объединяет заголовок, текст, источник, время и пересечение именованных сущностей, а пороги калибруются по языку и длине статьи.
Назначение в кластеры выполняется с журналом явных слияний, чтобы ошибочные объединения можно было отменить без перестроения 3 лет истории.
Kafka передает новые статьи, потоковые обработчики соблюдают SLA 10 минут, а ночная сверка находит кандидатов, пропущенных из-за задержки индекса.

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

designhardware

Я бы использовал одну мультиязычную encoder-decoder модель как основу и выделял отдельные модели только парам, где качество или объем оправдывают это.

Обучающие данные дедуплицируются, балансируются по языковым парам, маркируются по доменам и фильтруются по качеству выравнивания до supervised seq2seq-обучения.
Интерактивные запросы используют динамический батчинг TensorRT с коротким ожиданием, а большие файлы идут в оптимизированную по пропускной способности пакетную очередь на тех же версионированных моделях.
Оценка сочетает COMET, BLEU, точность терминологии и слепую человеческую оценку адекватности и беглости для каждой пары и домена.
Планирование мощности выделяет прогретые GPU-реплики по трафику пар, а резерв на CPU для малых пар допускается только после подтверждения цели 900 мс.

Зачем это спрашивают: Интервьюер оценивает специализированную seq2seq-архитектуру, распределение мультиязычных ресурсов, человеческую оценку и экономику инференса.

designconsistency

Я бы использовал специализированный encoder-decoder суммаризатор с иерархическим кодированием документа и явной проверкой чисел.

Отчеты сегментируются по структурным заголовкам, представления разделов объединяются, а декодер обучается только на утвержденных парах отчетов и итогов.
Механизм копирования или ограниченный словарь чисел снижает искажения, а детерминированные валидаторы связывают каждое число с сущностью, отчетным периодом, валютой и единицей измерения до сравнения с источником.
Оценка включает ROUGE для покрытия, тесты фактической согласованности, точность чисел выше 98% и слепые оценки аналитиков минимум на 500 отчетах в релиз.
Spark планирует пакеты сходной длины на GPU, а отчеты, не прошедшие проверку, удерживаются для ручного ревью и не публикуются автоматически.

Зачем это спрашивают: Сильный ответ рассматривает суммаризацию как управляемую seq2seq-задачу со структурой документа, проверками источника и доменным человеческим ревью.

system-design

Я бы объединил доменно адаптированное seq2seq-обучение, декодирование с учетом терминологии и обнаружение терминов в исходном тексте.

Терминологическая база версионируется по языковой паре, специальности и дате действия и содержит морфологические варианты вместо буквальной замены строк.
Обучение смешивает параллельные медицинские тексты и синтетические примеры с терминами, но документы пациентов и списки терминов из одного источника не пересекаются с тестом.
При инференсе найденные термины направляют или ограничивают декодер только при надежном выравнивании, не создавая неграмматичных принудительных подстановок.
Релизные гейты включают COMET, ревью врачей, точность терминологии 99% и задержку при худшей плотности терминов.

Зачем это спрашивают: Интервьюер хочет конкретную терминологическую архитектуру, сохраняющую грамматичность перевода и проверяющую качество специалистами.

nlpdesign

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

Определения задач поддерживают спаны, вложенные сущности, отношения, многометочные классы и спаны QA, не заставляя команды использовать свободный JSON.
Планировщик учитывает языковые навыки, сертификацию проверяющих, эталонные объекты и целевую долю двойной разметки, не показывая аннотаторам тестовые данные.
Каждое изменение хранит аннотатора, версию инструкции, время и версию исходных данных, позволяя проводить арбитраж и воспроизводить выгрузки датасетов.
Глубина очереди, задержка сохранения, расхождение, точность на эталонах и свежесть выгрузок контролируются отдельно по командам и языкам.

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

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

Матрица расхождений по типу сущности, границе, вложенности и языку показывает, связана ли проблема с неоднозначностью, переводом или инструментом.
Два эксперта совместно разбирают стратифицированную выборку, затем публикуют положительные, отрицательные и граничные примеры в новой неизменяемой версии инструкции.
Аннотаторы проходят сертификационный набор и получают еженедельную обратную связь, а продакшн-объекты размечаются дважды, пока каждый язык не превысит 0,80.
Согласие измеряется span-aware F1 и оценками по типам, а не одним числом на уровне токенов, скрывающим ошибки вложенных границ.

Зачем это спрашивают: Сильный ответ превращает ограниченное время экспертов в измеримые улучшения инструкций и сертификации.

Закрытые вопросы

21
У вас 1 миллион неразмеченных тикетов, бюджет на 50 000 аннотаций, 80 меток, 5 языков и 8 недель, чтобы поднять macro-F1 с 0,72 до 0,82. Как вы примените активное обучение?
22
Соберите обучающий корпус из 20 источников общим объемом 4 ТБ и 9 миллиардов предложений с точным происхождением, менее 2% дублей и SLA предобработки 24 часа на 200 Spark-воркерах.
spark
23
Корпус на 6 языках содержит 600 миллионов сообщений поддержки, должен удалить 99,9% адресов электронной почты и телефонов, сохранить смещения меток сущностей и обработаться за 18 часов с контролями GDPR. Как вы это сделаете?
gdprconcurrency
24
Спроектируйте маршрутизацию 15 языков, когда 20% из 8 000 запросов в секунду содержат смешение языков, p99 маршрутизации должен быть ниже 12 мс, а ошибочная маршрутизация ниже 1%.
latencydesign
25
Для трех новых языков есть только по 20 000 размеченных примеров, 2 миллиона неразмеченных предложений, 10 недель и команда из 4 инженеров, а целевой NER F1 выше 0,80. Какую стратегию вы выберете?
26
У вас 8 миллиардов доменных токенов, 32 GPU A100 на 72 часа и 6 нижестоящих задач классификации и NER, отстающих от общей BERT-модели на 5 пунктов F1. Как вы проведете доменно-адаптивное предобучение?
classificationtokensbert
27
Двенадцати бизнес-доменам нужен собственный классификатор документов, объем разметки колеблется от 30 000 до 3 миллионов примеров, у команды 8 GPU, а все модели нужно выпустить за 6 недель. Как вы организуете дообучение энкодеров?
fine-tuning
28
Девять NLP-задач классификации, NER и экстрактивного QA используют 3 языка, но отдельные энкодеры стоят $140 000 в месяц, а цель составляет $80 000 при средней потере менее 1 пункта F1. Построите ли вы многозадачную модель?
classificationnlpmodel-serving
29
Классификатор XLM-R на 340 миллионов параметров достигает macro-F1 0,91, но стоит $110 000 в месяц; цель составляет $55 000, и ни один из 10 языков не должен потерять больше 1 пункта. Как вы проведете дистилляцию?
30
Дообучите XLM-R на 900 миллионах размеченных токенов с 16 GPU A100 за 24 часа, теряя не более 30 минут работы при сбое узла. Как вы настроите распределенное обучение?
fine-tuningtokensdistributed
31
Обучите модель перевода на 1,2 миллиарда параметров с 64 GPU A100, 40 языковыми направлениями и 6 триллионами параллельных токенов за 5 дней, при потере не более 20 минут между снимками. Какую архитектуру вы примените?
tokensarchitecture
32
Предобработайте 40 ТБ мультиязычных веб-текстов на 500 Spark-воркерах за 16 часов, включая определение языка, разбиение на предложения, дедупликацию и удаление PII, с менее чем 1% неуспешных записей. Как вы организуете задачу?
queriespiispark
33
Нужно провести 500 экспериментов по дообучению энкодеров на 7 задачах за 10 дней, имея 12 GPU и лимит вычислений $35 000, с сохранением воспроизводимости. Как вы используете Ray?
fine-tuningray
34
Спроектируйте Kafka-пайплайн для 15 000 документов в секунду, 10 NLP-обогащений, сквозного p95 ниже 45 секунд и отсутствия дублей в поисковом индексе после повторов.
kafkadesignindexes
35
Ночной NLP-пакет должен классифицировать 600 миллионов записей за 8 часов в 5 регионах, сохранять данные внутри каждого региона и стоить меньше $12 000 за запуск. Как вы его спланируете?
nlpbatch
36
Обслуживайте BERT-классификатор на 110 миллионов параметров при 12 000 запросах в секунду на 240 ядрах CPU, p99 ниже 60 мс и потере точности меньше 0,5 пункта. Как вы его оптимизируете?
optimizationlatencybert
37
Обслуживайте XLM-R для 6 языков при 4 000 запросах в секунду, p99 ниже 100 мс, на 8 GPU A10 с доступностью 99,95%. Как вы используете TensorRT и Kubernetes?
serving-runtimeskuberneteslatency
38
Пайплайн spaCy с токенизацией, правилами, NER и связыванием сущностей должен обрабатывать 50 000 коротких сообщений в секунду на 300 ядрах CPU с p95 ниже 40 мс. Как вы его упакуете и масштабируете?
tokensconcurrencyci-cd
39
Эндпоинт энкодера получает тексты длиной от 8 до 512 токенов при 10 000 запросах в секунду, должен держать p99 ниже 90 мс и может использовать 6 GPU. Как вы спроектируете динамический батчинг?
designbatchendpoints
40
Создайте реестр моделей и релизный процесс для 25 NLP-моделей, которыми владеют 10 команд, с еженедельными релизами, откатом менее чем за 10 минут и отсутствием неотслеживаемых продакшн-предсказаний.
rollbackregistriesconcurrency
41
Определите офлайн-гейты релиза для классификатора на 18 языках и в 6 демографических регионах, с macro-F1 выше 0,86 и запретом регрессии более 2 пунктов в любом срезе регион-язык.
model-serving
42
NER-модель на 7 языках должна сохранять минимум 90% F1 чистого текста на OCR с 8% символьных ошибок, социальных текстах с 15% опечаток и входах до 4 000 символов. Как вы построите оценку устойчивости?
llm-eval
43
Спроектируйте обнаружение дрейфа для 12 текстовых классификаторов с 30 миллионами предсказаний в день, когда подтвержденные метки приходят через 21 день, а ложных тревог должно быть меньше 2 в месяц.
designiac
44
Управляйте индексом семантического поиска на 600 миллионов эмбеддингов, 4 миллиона обновлений документов в день, свежестью менее 15 минут, recall@20 выше 0,94 и без простоя поиска при обновлении энкодера.
nlpembeddingsretrieval
45
Спроектируйте удаление PII в реальном времени для 25 000 сообщений в секунду на 10 языках, p99 ниже 45 мс, recall регулируемых идентификаторов выше 99,95% и хранение аудита 30 дней.
retentiondesignpii
46
Поисковый продукт получает 200 000 событий обратной связи в день от 30 000 пользователей, но их могут проверять только 8 аналитиков, а обновления таксономии должны выходить ежемесячно. Как вы построите таксономию человеческой обратной связи?
feedback
47
Спланируйте мощность для 3 сервисов энкодеров с суммарными 18 000 запросов в секунду, p99 ниже 100 мс, двукратным запасом на пик и месячным лимитом $120 000 для вариантов CPU и GPU.
latencyhardwarecapacity
48
Разверните NER и классификацию в 5 регионах для 14 языков, сохраняя весь текст и эмбеддинги внутри региона, обеспечивая доступность 99,99% и выкатывая один глобальный релиз модели за 48 часов. Как вы это спроектируете?
classificationnlpembeddings
49
Банк должен классифицировать 60 фиксированных описаний транзакций при 20 000 запросах в секунду, p99 ниже 20 мс, команде из 6 инженеров, сроке 12 недель и менее 0,1% критических ошибок. Вы используете правила, модель или оба подхода?
transactionslatency
50
Ваша команда из 7 инженеров должна за 3 недели до начала реализации проверить архитектуру вложенного NER для 25 миллионов клинических записей в месяц, 4 языков, p95 ниже 150 мс и месячного бюджета $70 000. Как вы проведете ревью и менторинг?
mentoringarchitecture
51
После выката чекпоинта F1 классификатора тональности падает на 14 пунктов, а до пикового трафика остаётся 90 минут. Хеш модели верен, но токенизатор взят из прошлого релиза. Что вы сделаете?
tokens
52
После включения нормализации NFC доля промахов поиска по вьетнамским именам растёт с 3% до 19% на 2 миллионах запросов в день, а исправление нужно за четыре часа. Как вы расследуете проблему?
normalizationqueries
53
Обновление OCR-парсера снижает F1 полей счетов с 91% до 63% на 80 000 отсканированных страницах, а цифровые PDF не меняются; финансам нужно восстановление к завтрашнему утру. Каков ваш план?
54
Recall NER для 1 200 новых названий продуктов составляет 48% против 89% для старых продуктов, а поиск по каталогу запускается через 72 часа. Как вы поступите?
55
Клиническая NER-модель пропускает 22% новых названий онкологических препаратов, а сверка лекарств начинается через 48 часов в 14 больницах. Что вы решите?
react
56
Миграция таксономии меток разделяет Billing на Refund, Chargeback и Invoice, но 38% из 9 миллионов исторических тикетов всё ещё имеют старую метку; переключение через шесть дней. Как провести миграцию безопасно?
migrations
57
Релиз entity resolution ошибочно объединяет 3,6% из 600 000 профилей клиентов с похожими транслитерированными именами, а compliance требует локализации за два часа. Что вы сделаете?
58
Обновление language ID ошибочно направляет 11% португальских тикетов в испанские модели, увеличивая время решения на 27%; поддержке нужна мера за три часа. Что вы измените?
59
Recall классификатора модерации падает с 86% до 61% на постах со смешанными хинди и английским во время события для 5 миллионов пользователей, а на стабилизацию есть четыре часа. Как вы ответите?
60
Обновление мультиязычного классификатора повышает общий macro-F1 на 3 пункта, но снижает F1 амхарского с 72% до 49%; запуск назначен через 24 часа. Вы выпускаете его?
61
Подрядчик по разметке сообщает о завершении 98% из 400 000 меток интентов, но у 31% повторно показанных золотых объектов метки не совпадают; обучение начинается через 36 часов. Что вы сделаете?
procurement
62
Три команды разметки спорят, считать ли симптомы в семейном анамнезе меткой PatientCondition, из-за чего kappa равна 0,42 на 12 000 заметок; правила нужно зафиксировать к пятнице. Как разрешить спор?
conflict
63
Символы нулевой ширины и омоглифы снижают recall классификатора токсичности с 88% до 54% на 25 000 текстах для тестирования атак за четыре дня до релиза. Как вы поступите?
64
Аудит корпуса находит имена, телефоны и диагнозы в 2,4% из 18 миллионов обучающих предложений, а юристам нужно решение за 24 часа. Что вы сделаете?
65
Мультиязычный модуль маскирования PII пропускает 17% телефонных форматов на арабском письме и деванагари в 60 миллионах запросов, а экспорт подрядчику назначен на сегодня. Как вы поступите?
procurementpii
66
Модель токсичности показывает 90% F1 офлайн, но только 74% в продакшне после рефакторинга предобработки; решение об откате нужно за 60 минут. Как найти train-serving skew?
refactoringrollbackmodel-serving
67
Система NER и извлечения сущностей из новостей, обученная на данных до 2024 года, за две недели теряет 16 пунктов recall спанов на сущностях выборов 2026 года; редакции нужен план к завтра. Как обработать временной drift?
soft-skillssystem-designiac
68
Модель интентов поддержки переносят из бытовой электроники в промышленное оборудование, и macro-F1 падает с 88% до 59% на 70 000 тикетах; новая очередь открывается через пять дней. Что вы сделаете?
data-structures
69
Снижение порога текстового классификатора мошенничества с 0,62 до 0,51 повышает recall с 78% до 91%, но ежедневно блокирует 14 000 законных апелляций; руководству нужен выбор за два часа. Что вы решите?
thresholding
70
После перевзвешивания классов accuracy интентов остаётся 87%, но expected calibration error растёт с 0,04 до 0,19, ломая политику автоматической эскалации через 24 часа. Как восстановиться?
calibrationescalation
71
Релиз reading comprehension отвечает на 34% вопросов без ответа по политикам вместо отказа, тогда как раньше было 8%, а запуск завтра. Что вы проверите?
comprehensions
72
QA API возвращает правильный текст ответа, но неверные символьные офсеты для 6,8% из 3 миллионов документов после очистки Unicode; клиентам нужен патч за шесть часов. Что вы сделаете?
api
73
Релиз дедупликации предложений снижает recall дублей с 92% до 75% на перефразированных мультиязычных статьях и пропускает 18 миллионов дублей в обучающий корпус; старый пайплайн отключают через 48 часов. Как вы поступите?
queriesci-cd
74
Recall@50 семантического поиска остаётся 94%, но precision@5 падает с 71% до 43%, а переформулировки после нулевого результата растут на 26%; продукту нужен фикс к понедельнику. Что вы измените?
retrieval
75
Пересборка индекса BM25 меняет analyzer, и успешность точного поиска SKU падает с 97% до 52% на 8 миллионах продуктов; возможность отката исчезнет через три часа. Что вы сделаете?
bm25indexesrollback
76
Во время миграции embedding семантического поиска 18% документов всё ещё используют старое векторное пространство, а пересечение top-10 скачет с 82% до 37%; переключение через пять дней. Как восстановиться?
nlpembeddingsmigrations
77
Мультиязычный reranker повышает английский nDCG@10 на 4 пункта, но снижает японский с 0,76 до 0,58 на 12 000 запросов, а релиз через 36 часов. Что вы решите?
rerankingqueries
78
Кандидат машинного перевода повышает BLEU с 31,2 до 34,8, но носители предпочитают старый результат в 64% из 500 юридических предложений; смена подрядчика назначена на пятницу. Чему вы доверитесь?
bleuprocurement
79
ROUGE финансового суммаризатора остается стабильным, но 12% из 2 000 сводок привязывают правильные числа к неверному кварталу, компании, валюте или единице измерения; автоматизация начнется через 72 часа. Что вы сделаете?
rouge
80
Релиз перевода передаёт Chargeback как Refund в 17% из 90 000 немецких сообщений поддержки, а уведомления клиентам отправятся через восемь часов. Как локализовать терминологический инцидент?
incidents
81
Клинический суммаризатор копирует идентификаторы пациентов в 6,1% выписок несмотря на этап обезличивания, а деплой назначен через 24 часа. Что вы сделаете?
deployment
82
Суммаризатор встреч пропускает 23% назначенных действий, когда транскрипт длиннее 45 минут, а руководителям нужен фикс до завтрашних 300 встреч. Что вы измените?
tracking
83
После добавления языковой токенизации 7% исполнителей Spark-задачи на 12 ТБ падают с OOM, а корпус нужен через десять часов. Как стабилизировать задачу?
tokensconcurrencyspark
84
Lag Kafka достигает 38 миллионов сообщений, а дубли текстовых классификаций растут до 4,5% после ребалансировки consumers; SLA нужно восстановить за два часа. Что вы сделаете?
classificationkafka
85
DAG Airflow отмечен успешным, хотя 14 из 320 разделов корпуса не попали в обучение, а запуск на 48 GPU начинается через шесть часов. Как вы ответите?
partitioningairflowhardware
86
После выравнивания подслов некоторые пакеты NER содержат документы, у которых все метки равны игнорируемому индексу -100; запуск на 8 GPU получает NaN на шаге 72 400 после 19 часов. Как восстановиться?
indexesbatchhardware
87
После возобновления мультиязычного распределенного обучения с другим world size общий loss совпадает, но F1 суахили падает на 11 пунктов, потому что sampler epoch и шардирование RNG лишают язык данных; до конца аренды остается восемь часов. Что вы сделаете?
shardingdistributed
88
Релиз из реестра моделей использует правильные чекпоинт и токенизатор, но неверная карта id-to-label меняет местами Refund и Chargeback на 1,2 миллиона тикетов; откат нужен за 45 минут. Что вы сделаете?
rollbackregistriestokens
89
Экспорт ONNX совпадает с PyTorch по общей accuracy, но меняет 5,2% спанов NER на 20 000 длинных предложениях, а мобильный релиз через три дня. Как вы расследуете проблему?
serving-runtimespytorch
90
Конвертация TensorRT снижает p95 latency с 92 до 41 мс, но уменьшает recall классификации документов с 88% до 79% для текстов длиннее 2 000 токенов; запуск через 48 часов. Что вы сделаете?
classificationtokenslatency
91
Квантизация INT8 вдвое снижает стоимость encoder, но уменьшает F1 интентов суахили с 76% до 61%, тогда как английский не меняется; ёмкость закончится через 72 часа. Вы разворачиваете её?
capacitydeploymentmodel-compression
92
В Kubernetes p99 растёт со 180 до 740 мс при 6 000 запросов в секунду, GPU остаются на 43%, а CPU токенизации достигает 96%; на стабилизацию есть час. Что вы сделаете?
tokenskuberneteslatency
93
Ночной backlog классификации растёт до 84 миллионов документов после падения throughput на 29%, а результаты нужны через 11 часов. Как восстановиться?
throughputbacklog
94
Dynamic batching повышает throughput на 35%, но увеличивает p99 latency коротких текстов с 240 до 910 мс при 4 500 запросах в секунду; launch review через два часа. Оставите изменение?
latencythroughputbatch
95
Сервис encoder падает по OOM, когда 40 пользователей загружают юридические документы на 12 000 токенов, хотя поддерживаемый лимит равен 16 000; приём документов закрывается через три часа. Как стабилизировать сервис?
tokens
96
Детектор drift пропустил падение recall на 19 пунктов на шесть дней, а заменившее его правило выдаёт 430 алертов в час на безобидный новый сленг; operations нужно решение сегодня. Что вы построите?
alertingiac
97
A/B-тест повышает общую автоматизацию тикетов на 6%, но ложные автозакрытия для арабских пользователей растут с 2% до 9% за 48 часов; продукт хочет завтра выкатить 100%. Что вы решите?
ab-testingclosures
98
Клиент требует удалить 240 000 сообщений поддержки из ЕС, использованных в обучении, но реплики и model registry распределены между регионами США и ЕС; доказательства нужны через 14 дней. Как выполнить запрос?
replicationregistries
99
На code review middle-инженер предлагает приводить текст к lowercase, делать ASCII folding и усекать каждый документ до 512 токенов, потому что сервис превышает цель задержки на 20% перед пятницей. Как вы проведете review и менторство после того, как изменение уже снизило F1 турецких интентов на 13 пунктов?
mentoringcode-reviewlatency
100
Продукт просит выпустить к пятнице медицинский triage-классификатор для 2 миллионов пользователей, но recall тяжёлых состояний равен 81% при пороге 95%, а откат занимает 40 минут. Что вы рекомендуете на финальном review?
rollback

Вопросы

1Спроектируйте мультиязычную NLP-платформу для 12 продуктовых команд, 20 языков и 50 миллионов документов в день с доступностью 99,9% и месячным бюджетом $180 000.

3Спроектируйте классификацию 80 миллионов документов в день по 120 меткам и 6 языкам с пакетным SLA 30 минут и бюджетом $0,20 на 1 000 документов.

11Спроектируйте экстрактивный QA по 20 миллионам фрагментов политик на 6 языках, без генерации ответов, с p99 ниже 350 мс, exact match выше 75% и 2 000 запросов в секунду.

14Спроектируйте дедупликацию 2 миллиардов предложений на 14 языках с recall дублей 95%, долей ложных слияний меньше 0,5% и окном Spark 12 часов.

16Спроектируйте машинный перевод для 8 языковых пар, 100 миллионов символов в день, p95 ниже 900 мс для интерактивного текста, COMET выше 0,82 и месячного бюджета GPU $90 000.

17Спроектируйте абстрактивную суммаризацию 5 миллионов финансовых отчетов в месяц длиной до 20 000 слов, с итогом до 300 слов, точностью чисел 98% и ночным SLA 6 часов.

19Спроектируйте платформу аннотирования для 300 аннотаторов, 6 языков, 4 NLP-команд, 2 миллионов объектов в квартал и доступности 99,95% в рабочее время.

Закрытые вопросы