Линейная регрессия: аналитическое решение и регуляризация
Как связаны матричная запись линейной регрессии, метод наименьших квадратов, градиентный спуск и регуляризация L1/L2?
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Короткий ответ
Least squares минимизирует ||Xw-y||^2. Closed form использует normal equation, но на практике часто нужны regularization, SVD/PCA или iterative optimization.
Подробный разбор
Линейная регрессия в matrix form решает задачу минимизации squared error. Если X full rank, closed-form решение можно записать через normal equation. Но обращение матрицы может быть нестабильным или дорогим, особенно при collinearity и большом числе признаков.
Ridge добавляет L2 penalty и стабилизирует решение, Lasso добавляет L1 и может занулять признаки, Elastic Net комбинирует оба эффекта. Gradient descent/SGD полезны на больших данных, а SVD/PCA помогают диагностировать rank deficiency и redundant features.
async, threading и multiprocessing в Python
Когда использовать async, threading и multiprocessing в Python, и как GIL влияет на этот выбор?
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Короткий ответ
async/threading подходят для I/O-bound задач, multiprocessing - для CPU-bound Python кода; GIL мешает параллельному исполнению Python bytecode в threads.
Подробный разбор
asyncio хорош, когда много сетевых или файловых ожиданий и код можно писать в cooperative style. Threads тоже удобны для I/O-bound задач, особенно когда библиотека блокирующая, но GIL не дает двум Python threads одновременно исполнять CPU-bound bytecode.
Для CPU-bound задач на чистом Python используют multiprocessing или выносят вычисления в native code, который освобождает GIL. В ML/NumPy/PyTorch часть операций выполняется в C/CUDA и может эффективно параллелиться вне GIL.
В production выбор зависит от нагрузки: web API с внешними calls - async/thread pool; тяжелый feature extraction на CPU - processes/queue; GPU inference - batching и отдельный worker pool.
Типичные ошибки
- Говорить, что threads всегда бесполезны из-за GIL.
- Использовать multiprocessing для легкого I/O.
- Не учитывать serialization overhead между processes.
Как сказать на собеседовании
- Раздели I/O-bound и CPU-bound.
- Упомяни, что native ML libraries часто обходят GIL.
Как собрать данные и классы для модели модерации
Для moderation-модели нужны классы и данные. Как собрать labels, обработать дисбаланс и не смешать разные политики в один шумный датасет?
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Короткий ответ
Данные приходят из ручной модерации, жалоб, исторических решений, open datasets и augmentation. Label taxonomy фиксирует классы, инструкции, ambiguous cases и disagreement handling.
Подробный разбор
Сначала команда фиксирует policy taxonomy: какие классы действительно нужны продукту и какие действия они запускают. Например, clean, toxic, hate, insult, spam, self-harm или доменные нарушения. Для каждого класса нужны инструкции и примеры, иначе модераторы будут размечать разные вещи под одним названием.
Источники данных: историческая ручная модерация, жалобы пользователей, выборка обычного контента, open datasets, перевод/augmentation и специально собранные hard cases. Исторические решения нельзя брать без проверки, потому что политика могла меняться, а очередь модерации уже смещена в сторону подозрительного контента.
Дисбаланс решается не только oversampling. Нужны stratified batches, class weights или focal loss, отдельный validation set по редким классам, adjudication спорных примеров и регулярное обновление данных после изменения политики.