Среднее четырех чисел из среднего пяти
Дано среднее пяти чисел avg_5 и известно одно из этих чисел x.
Верните среднее оставшихся четырех чисел.
Сигнатура
def avg_4(avg_5: float, x: float) -> float:Пример
avg_4(10, 6) -> 11Решение прямо на странице
Напишите код, запустите проверки и только потом открывайте разбор.
Нажмите «Запустить проверки» или Ctrl+Enter.
Показать разбор
Идея решения
Среднее пяти чисел — это сумма пяти чисел, деленная на 5.
Значит, сумма пяти чисел равна 5 * avg_5. Вычитаем известное число x и делим остаток на 4.
Эталонный код
def avg_4(avg_5: float, x: float) -> float:
return (5 * avg_5 - x) / 4Аномальные дни по выручке publisher
Есть таблица RevenueDaily с дневной выручкой publisher.
День считается аномальным для конкретного publisher, если revenue в этот день строго больше, чем 3 * revenue предыдущего дня этого же publisher.
Первый день в доступном наборе не считается аномальным, потому что у него нет предыдущего дня.
Схема
CREATE TABLE RevenueDaily (
day TEXT NOT NULL,
publisher_id INTEGER NOT NULL,
revenue REAL NOT NULL,
PRIMARY KEY (day, publisher_id)
);Верните publisher_id, day, revenue, prev_revenue. Отсортируйте результат по publisher_id ASC, затем day ASC.
Решение прямо на странице
Напишите код, запустите проверки и только потом открывайте разбор.
Нажмите «Запустить проверки» или Ctrl+Enter.
Показать разбор
Подсказки
- Предыдущая строка
Нужна оконная функция LAG(revenue).
- Разные publishers
Не забудьте PARTITION BY publisher_id, иначе сравните дни разных publisher.
Идея решения
Используем LAG(revenue) с PARTITION BY publisher_id ORDER BY day, чтобы получить revenue предыдущего дня внутри того же publisher.
После этого фильтруем строки, где предыдущий день существует и текущая выручка строго больше 3 * prev_revenue.
Эталонный код
WITH daily_with_prev AS (
SELECT
publisher_id,
day,
revenue,
LAG(revenue) OVER (
PARTITION BY publisher_id
ORDER BY day
) AS prev_revenue
FROM RevenueDaily
)
SELECT
publisher_id,
day,
revenue,
prev_revenue
FROM daily_with_prev
WHERE prev_revenue IS NOT NULL
AND revenue > 3 * prev_revenue
ORDER BY publisher_id ASC, day ASC;Revenue spike через centered moving average
Есть таблица дневной выручки publisher:
CREATE TABLE RevenueDaily (
day TEXT NOT NULL,
publisher_id INTEGER NOT NULL,
revenue REAL NOT NULL,
PRIMARY KEY (day, publisher_id)
);Найдите дни, где revenue строго больше, чем 3 * centered 5-day moving average для того же publisher.
Centered window состоит из двух предыдущих строк, текущей строки и двух следующих строк внутри publisher при сортировке по day.
Учитывайте только строки, для которых окно полное, то есть в нем ровно 5 строк.
Верните publisher_id, day, revenue, avg_window_revenue. Отсортируйте результат по publisher_id ASC, day ASC.
Решение прямо на странице
Напишите код, запустите проверки и только потом открывайте разбор.
Нажмите «Запустить проверки» или Ctrl+Enter.
Показать разбор
Подсказки
- Centered window
Используйте ROWS BETWEEN 2 PRECEDING AND 2 FOLLOWING.
- Полное окно
COUNT(*) по тому же окну должен быть равен 5.
Идея решения
Считаем два оконных агрегата по каждому publisher: AVG(revenue) и COUNT(*) в окне ROWS BETWEEN 2 PRECEDING AND 2 FOLLOWING.
После этого оставляем только строки с полным окном из 5 строк и строгим условием revenue > 3 * avg_window_revenue.
Эталонный код
WITH windowed AS (
SELECT
publisher_id,
day,
revenue,
AVG(revenue) OVER (
PARTITION BY publisher_id
ORDER BY day
ROWS BETWEEN 2 PRECEDING AND 2 FOLLOWING
) AS avg_window_revenue,
COUNT(*) OVER (
PARTITION BY publisher_id
ORDER BY day
ROWS BETWEEN 2 PRECEDING AND 2 FOLLOWING
) AS window_count
FROM RevenueDaily
)
SELECT
publisher_id,
day,
revenue,
avg_window_revenue
FROM windowed
WHERE window_count = 5
AND revenue > 3 * avg_window_revenue
ORDER BY publisher_id ASC, day ASC;Как встроить LLM-агента в продуктовый pipeline
Нужно добавить LLM-агента в существующий продуктовый pipeline. Как спроектировать границы агента, tools, контекст, проверки и мониторинг?
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Показать разбор
Короткий ответ
LLM должна быть reasoning/tool-selection слоем, а не единственным backend: нужны явные tools, контекст, state, validation, retries, fallback и observability.
Подробный разбор
Систему лучше разделить на trigger, context builder, LLM planner, tool executor, validator и response/action layer. Для каждого tool нужен контракт входа/выхода, timeout, retry policy, permission check и логирование.
Контекст должен собираться из разрешенных источников через retrieval и metadata filters, а не безлимитно передаваться в prompt. Для рискованных действий нужны schema validation, deterministic checks, confidence threshold, human approval или fallback. В production отдельно мониторятся task success, tool error rate, hallucination/fallback rate, latency, cost и traces по шагам агента.
Отчетность и метрики для LLM-агента
Как построить отчетность вокруг LLM-агента, чтобы понимать качество, пользу, ошибки и стоимость?
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Показать разбор
Короткий ответ
Нужны product, quality, safety и system metrics: task success, correction/escalation rate, groundedness, tool failures, latency, cost.
Подробный разбор
Отчетность лучше строить по воронке: запрос принят, контекст найден, tools вызваны корректно, ответ/action прошел validation, пользователь получил результат. Quality: task success, экспертная оценка, groundedness, citation correctness и доля исправлений.
Safety: hallucination rate, forbidden tool calls, доступ к данным, fallback rate. System: latency p50/p95, retries, tool errors, cost per successful task. Для анализа нужны traces: prompt version, retrieved sources, tool calls, validator verdict и финальный outcome.
Bias-variance trade-off у Random Forest
Почему Random Forest обычно снижает variance по сравнению с одним деревом и какие trade-offs остаются?
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Показать разбор
Короткий ответ
Random Forest усредняет много decorrelated деревьев: variance падает, bias обычно остается низким, но растут стоимость, latency и хуже интерпретируемость.
Подробный разбор
Одно глубокое дерево имеет низкий bias, но высокий variance: сильно реагирует на изменения train data. Random Forest обучает деревья на bootstrap samples и случайных подмножествах признаков, поэтому ошибки деревьев частично независимы.
Усреднение снижает variance. Trade-offs: больше compute и memory, сложнее интерпретация, хуже extrapolation, а при слишком коррелированных деревьях эффект усреднения слабее. Параметры max_depth, min_samples_leaf, max_features и n_estimators управляют bias/variance.
Как работать с пропусками и шумом в данных
В датасете есть missing values и шумные признаки. Как системно обработать их до обучения и в production?
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Показать разбор
Короткий ответ
Сначала понять механизм пропусков и шума, затем выбрать imputation/filtering, добавить missing indicators, валидировать без leakage и мониторить drift.
Подробный разбор
Пропуски бывают MCAR/MAR/MNAR: случайные, зависящие от наблюдаемых факторов или несущие отдельный сигнал. Базовые варианты: constant/median/category imputation, отдельная категория unknown, model-based imputation, missing indicator.
Шум обрабатывается правилами валидности, winsorization/clipping, robust losses, outlier flags или удалением только при понятной причине. Важно считать imputation statistics только на train и фиксировать тот же preprocessing в serving. В production нужны алерты на долю пропусков, новые категории, распределения признаков и schema violations.
Что значит await в асинхронном Python
Объясните, что делает await в asyncio и почему он важен для неблокирующего сервиса.
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Показать разбор
Короткий ответ
await приостанавливает coroutine до завершения awaitable и возвращает управление event loop, чтобы другие задачи могли выполняться.
Подробный разбор
asyncio использует cooperative multitasking. Когда coroutine доходит до await на сетевом запросе, sleep, stream read или другой awaitable операции, она не держит поток занятым ожиданием.
Управление возвращается event loop, который может выполнить другие coroutines. Это полезно для I/O-bound сервисов: много запросов ждут сеть, БД или API. await не делает CPU-bound код параллельным; тяжелые вычисления нужно выносить в process pool, native code или отдельный worker.
Периоды падения endpoint по watchdog событиям
Есть таблица проверок endpoint-ов:
endpoint_checks(endpoint_id, checked_at, status)status принимает значения ok или failed. Нужно найти непрерывные периоды падения для каждого endpoint: подряд идущие строки со статусом failed, разделенные строками ok.
Верните:
endpoint_id;start_at— первый failed check периода;end_at— последний failed check периода;failed_checks— число failed checks в периоде.
Отсортируйте результат по endpoint_id, start_at.
Решение прямо на странице
Напишите код, запустите проверки и только потом открывайте разбор.
Нажмите «Запустить проверки» или Ctrl+Enter.
Показать разбор
Подсказки
- Найдите старты периодов
Используйте LAG(status), чтобы понять, является ли failed строка началом нового периода.
- Номер группы
Накопительная SUM по флагу начала периода дает стабильный group_id для каждого island.
Идея решения
Это классическая задача gaps and islands. Сначала находим начало каждого failed-периода: текущий статус failed, а предыдущий статус внутри endpoint либо отсутствует, либо не failed. Затем накопительной суммой таких стартов строим номер группы и агрегируем только failed строки.
Эталонный код
WITH ordered AS (
SELECT
endpoint_id,
checked_at,
status,
CASE
WHEN status = 'failed'
AND COALESCE(LAG(status) OVER (PARTITION BY endpoint_id ORDER BY checked_at), 'ok') <> 'failed'
THEN 1
ELSE 0
END AS new_group
FROM endpoint_checks
),
grouped AS (
SELECT
endpoint_id,
checked_at,
status,
SUM(new_group) OVER (
PARTITION BY endpoint_id
ORDER BY checked_at
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
) AS group_id
FROM ordered
)
SELECT
endpoint_id,
MIN(checked_at) AS start_at,
MAX(checked_at) AS end_at,
COUNT(*) AS failed_checks
FROM grouped
WHERE status = 'failed'
GROUP BY endpoint_id, group_id
ORDER BY endpoint_id, start_at;Endpoint с watchdog и устойчивым поведением
Как спроектировать endpoint, который вызывает нестабильный downstream или долгий pipeline и должен корректно переживать сбои?
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Показать разбор
Короткий ответ
Нужны timeouts, cancellation, retries с backoff, circuit breaker, idempotency, fallback, health metrics и понятный status model.
Подробный разбор
Endpoint не должен бесконечно ждать downstream. Задайте timeout budget, cancel propagation и bounded retries с backoff/jitter. Для повторяемых запросов нужна idempotency key.
Если dependency деградирует, circuit breaker переводит часть запросов в fallback: cached response, partial result, degraded mode или async job with polling. Watchdog должен различать timeout, crash, stale heartbeat и бизнес-ошибку. Метрики: success/error rate, timeout rate, retry count, queue age, p95/p99 latency, breaker state и доля fallback.