🤖 Что такое MCP сервер — как научить нейросеть писать SQL под ваши данные (часть 2):

В первой части разобрали что такое MCP и написали первый инструмент. Сегодня идем дальше — что делать, если запросы сложнее и нейросеть не знает как у вас организованы таблицы (их описание и как они могут соединяться между собой).

Проблема: модель не знает ваши таблицы 🎚

Фиксированный тул — например get_sales_by_region — работает хорошо для простых запросов. Но что если пользователь спросит: «Сравни выручку по регионам с прошлым кварталом с разбивкой по сегментам клиентов»?

Тут нужно несколько таблиц, JOIN и оконные функции. Заранее написать тул под каждый такой запрос — нереально (реально, конечно, но не логично мягко говоря).

Решение: дать модели два инструмента — получить схему и возможность выполнить любой запрос.

Как это устроено: 🎚

@mcp.tool()
def get_database_schema(domain: str = "all") -> str:
    """
    Возвращает схему БД: таблицы, поля, типы данных и связи.
    Вызывай ПЕРЕД тем как писать SQL-запрос.
    domain: 'sales', 'customers', 'products' или 'all'
    """
    if domain == "all":
        files = ["sales.md", "customers.md", "products.md"]
    else:
        files = [f"{domain}.md"]
    
    result = ""
    for f in files:
        with open(f"docs/{f}", "r") as file:
            result += file.read() + "\n\n"
    return result

@mcp.tool()
def execute_sql(query: str) -> list:
    """
    Выполняет SELECT-запрос к базе данных.
    Используй только после get_database_schema.
    Только SELECT — никаких изменений данных.
    """
    conn = sqlite3.connect("metrics.db")
    cursor = conn.cursor()
    cursor.execute(query)
    result = cursor.fetchall()
    conn.close()
    return result

Модель сначала вызывает get_database_schema, читает описание таблиц и связей — потом сама пишет SQL и передает в execute_sql.

Как организовать файлы схемы: 🎚

Файлы лежат рядом с сервером в папке /docs. Внутри — описание таблиц, типы данных и как они связаны:

## Таблица orders
- order_id INT — первичный ключ
- customer_id INT — FK → customers.customer_id  
- region VARCHAR — регион продажи
- revenue FLOAT — выручка
- created_at DATE — дата заказа

## Связи
orders.customer_id → customers.customer_id

Прочитав это, модель сама поймет как делать JOIN между таблицами — объяснять ничего не нужно.

Один MCP или несколько? 🎚

Один MCP-сервер = один проект. Не нужно плодить отдельный сервер под каждую таблицу. Все связанные таблицы и тулы живут в одном сервере. Если у вас две независимые системы — например аналитическая база и CRM — вот тогда имеет смысл делать два разных сервера. Здесь нет явного ответа, нужно подходить индивидуально к каждому проекту.

А если схема хранится в Confluence? 🎚

Рабочий вариант — тул делает запрос к Confluence API и достает описание нужной таблицы прямо оттуда:

@mcp.tool()
def get_table_docs(table_name: str) -> str:
    """
    Достает описание таблицы из корпоративной документации.
    Используй перед написанием SQL если нужны детали схемы.
    """
    # запрос к Confluence API
    response = requests.get(
        f"{CONFLUENCE_URL}/rest/api/content",
        params={"title": table_name, "expand": "body.storage"},
        auth=(USER, TOKEN)
    )
    return response.json()["results"][0]["body"]["storage"]["value"]

🟢 Хотите еще про нейронки ?
🔥 Набираем 80 реакций на этот пост, чтобы подобные посты выходили чаще

Итог: 🤩

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓ Какие идеи для использования MCP есть у вас? Делись в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации: Написать в ЛС | mentor.dima-sqlit.ru


@dima_sqlit

🗂 Порядок выполнения sql запроса — и почему алиас в WHERE не работает:

Часто вижу одну и ту же ошибку — человек пишет запрос, придумывает алиас в SELECT, а потом пытается использовать его в WHERE или HAVING. И получает ошибку. Почему?

Всё дело в порядке выполнения SQL.
На самом деле SQL выполняется совсем не в том порядке, в котором мы его пишем. Вот реальная последовательность:

1️⃣ FROM — сначала движок идёт к таблицам
2️⃣ JOIN — потом движок соединяет таблицы
2️⃣ WHERE — фильтрует строки до группировки
3️⃣ GROUP BY — группирует данные
4️⃣ HAVING — фильтрует уже сгруппированные данные
5️⃣ SELECT — только сейчас вычисляются выражения и алиасы
6️⃣ ORDER BY — сортировка результата
7️⃣ LIMIT — обрезание до нужного числа строк

Пример 1 — классическая ошибка с алиасом:

-- ❌ Не работает — алиас revenue ещё не существует на шаге WHERE
SELECT
    order_id,
    amount * 0.9 AS revenue
FROM orders
WHERE revenue > 1000;

-- ✅ Правильно — повторяем выражение напрямую
SELECT
    order_id,
    amount * 0.9 AS revenue
FROM orders
WHERE amount * 0.9 > 1000;

Пример 2 — почему HAVING, а не WHERE:

-- ❌ Нельзя — WHERE выполняется ДО GROUP BY
SELECT
    user_id,
    COUNT(*) AS order_count
FROM orders
GROUP BY user_id
WHERE order_count > 5;

-- ✅ Правильно — HAVING фильтрует после группировки
SELECT
    user_id,
    COUNT(*) AS order_count
FROM orders
GROUP BY user_id
HAVING COUNT(*) > 5;

Пример 3 — вот почему все пишут CTE:
Иногда хочется сначала что-то посчитать, а потом фильтровать по результату. Именно для этого и придумали CTE — они позволяют «сохранить» промежуточный результат и работать с ним как с таблицей.

-- ✅ CTE решает проблему: сначала считаем, потом фильтруем
WITH revenue_calc AS (
    SELECT
        order_id,
        amount * 0.9 AS revenue
    FROM orders
)
SELECT *
FROM revenue_calc
WHERE revenue > 1000;

Видите? В CTE SELECT уже выполнился — алиас revenue существует — и теперь во внешнем запросе WHERE отрабатывает по нему без проблем.

Итог: 🤩

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓ Сталкивались с этой ошибкой? Или, может, объясняете это джунам — как объясняете? Пишите в комментах!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации: Написать в ЛС | mentor.dima-sqlit.ru


@dima_sqlit

🏦 Разбор задачи с собеседования в Тинькофф (Т-банк). Задача про светофор сколько минут ты теряешь на красном?

Условие: Каждый день едете на работу. На пути один светофор: 2 минуты горит зелёный, 1 минуту — красный. Сколько времени вы ожидаемо простоите за 100 поездок?

Задачи на матожидание — любимый инструмент интервьюеров у аналитиков и DS. Выглядят как «логика про жизнь», а проверяют умение считать вероятности. Разберём на пальцах.

1️⃣ Находим цикл светофора
Полный цикл = 2 + 1 = 3 минуты. Вы приезжаете к светофору в случайный момент — считаем, что равномерно распределённый по этим 3 минутам.

2️⃣ Считаем вероятности

P(зелёный) = 2/3  →  ждать 0 минут
P(красный) = 1/3  →  придётся постоять

3️⃣ Сколько ждать, если попали на красный?
Вот тут сыплются многие. Вы ждёте не всю минуту. Вы приезжаете в случайный момент красной фазы: иногда в самом начале (придется ждать 1 минуту), иногда в конце (придется ждать 0 минут). В среднем — получим:

Среднее ожидание на красном = (1+0)/2 = 0.5 минуты

4️⃣ Собираем матожидание за одну поездку

E = P(зелёный) × 0  +  P(красный) × 0.5
E = (2/3) × 0  +  (1/3) × 0.5
E = 1/6 минуты ≈ 10 секунд

5️⃣ Умножаем на 100 поездок

100 × 1/6 ≈ 16.7 минуты = 16 минут 40 секунд

Итог: 🤩  

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓  Сколько у вас получилось до того, как дочитали до ответа? Делись в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации:  Написать в ЛС | mentor.dima-sqlit.ru 


@dima_sqlit

🛒  Разбор задачи с собеседования Магнит OMNI (MAGNIT TECH).
Сколько покупок нужно, чтобы собрать все 10 стикеров?

Условие: В наборе 10 наклеек. На кассе дают одну случайную за любую покупку. сколько покупок нужно, чтобы собрать все 10?

Задача на пониманием и умение считать математическое ожидание. Разберём на пальцах:

1️⃣ Главное правило: переворачиваем дробь
Если вероятность равна p, то среднее количество попыток до первого успеха равно 1/p. Например:

Вероятность 1/10 → 10/1 = 10 попыток
Вероятность 5/10 → 10/5 = 2 попыток

2️⃣ Шанс поймать новую наклейку
Собираем по этапам. Чем больше наклеек в альбоме, тем реже попадается новая:

этап 1:  собрано 0  →  шанс новой 10/10
этап 2:  собрано 1  →  шанс новой 9/10
...
этап 10: собрано 9  →  шанс новой 1/10

3️⃣ Собираем матожидание и считаем ответ
Переворачиваем шанс каждого этапа в число покупок и складываем всё:

этап 1 (запишем общую формулу):
E = 10/10 + 10/9 + 10/8 + ... + 10/2 + 10/1

этап 2 (вынесем общий множитель за скобки):
E = 10 × (1 + 1/2 + 1/3 + ... + 1/10

этап 3 (считаем ответ):
E = 10 × 2.93 ≈ 29 покупок

Почти половина из этих них уходит на последние 2-3 наклейки.

Итог: 🤩  

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓  Сколько у вас получилось до того, как дочитали до ответа? Делись в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации:  Написать в ЛС | mentor.dima-sqlit.ru 


@dima_sqlit

📊 DAU, WAU, MAU и sticky factor — метрики активности:

Пришло время разбираться с метриками, начнем с DAU, WAU, MAU и sticky factor 😘

1️⃣ Что это

DAU — уникальные пользователи за день
WAU — за 7 дней
MAU — за 30 дней
Ключевое слово — уникальные: один user_id считаем один раз, сколько бы раз он ни заходил.

2️⃣ Считаем все три одним запросом

SELECT
    COUNT(DISTINCT CASE WHEN dt =  CURRENT_DATE      THEN user_id END) AS dau,
    COUNT(DISTINCT CASE WHEN dt >= CURRENT_DATE - 6  THEN user_id END) AS wau,
    COUNT(DISTINCT CASE WHEN dt >= CURRENT_DATE - 29 THEN user_id END) AS mau
FROM events;

COUNT(DISTINCT …) убирает повторы, CASE WHEN задаёт окно по дате.

3️⃣ Частая ошибка

WAU — это не сумма семи DAU. Кто заходил все 7 дней, в сумме DAU посчитан 7 раз, а в WAU — один.
Отсюда правило: DAU ≤ WAU ≤ MAU.

4️⃣ Sticky factor

sticky factor = DAU / MAU — показывает, как часто пользователи возвращаются.
0.1 → заходят ~3 дня в месяц (слабо)
0.2 → ~6 дней
0.5 → ~15 дней (уровень соцсетей)
Чем выше — тем «липче» продукт.

Итог: 🤩  

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓  Как вам такие разборы в формате видео? Делись в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации:  Написать в ЛС | mentor.dima-sqlit.ru 


@dima_sqlit

🎲 Формула Байеса и условная вероятность — разбор на кубике:

Условие: кинули кубик и говорят — выпало чётное. Какова вероятность, что это шестёрка?

Ответ: не 1/6, а 1/3. Покажу через формулу Байеса и расшифрую в ней каждое слагаемое — это и есть самое главное.

1️⃣ Обозначим события:

A — «выпала шестёрка» (это мы ищем)
B — «выпало чётное» (это уже известно — условие)
Нужна вероятность A, если известно B.

2️⃣ Сама формула Байеса:

P(A|B) = P(B|A) × P(A) / P(B)
Читается: вероятность A при условии, что произошло B.

3️⃣ Разбираем каждый кусок формулы:

• P(A|B) — что ищем: шанс шестёрки, раз выпало чётное. Это и есть ответ.
• P(A) — базовый шанс шестёрки, без подсказок = 1/6.
• P(B) — шанс чётного вообще: чётные это 2, 4, 6, то есть 3 из 6 = 1/2.
• P(B|A) — шанс, что чётное, ЕСЛИ выпала шестёрка = 1. Шестёрка всегда чётная.

4️⃣ Подставляем числа:

P(A|B) = P(B|A) × P(A) / P(B) = 1 × (1/6) / (1/2) = (1/6) / (1/2) = 1/3

5️⃣ Почему получилось именно так:
Подсказка «чётное» выкинула варианты 1, 3, 5. Осталось 2, 4, 6 — и шестёрка одна из трёх. Формула дала ровно это: 1/3. Информация подняла шанс шестёрки с 1/6 до 1/3 — в этом вся суть Байеса.

Итог: 🤩  

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓  А вы сразу сказали 1/3 или попались на 1/6? Делитесь в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие разборы.


🚬 Вопросы, обучение, консультации:  Написать в ЛС | mentor.dima-sqlit.ru 


@dima_sqlit

💰 ARPU vs ARPPU — разберемся в чем разница:

ARPU и ARPPU постоянно путают. Обе про доход с пользователя, но делят на разное. Разберём и выведем главную формулу.

1️⃣ ARPU — доход на ВСЕХ
Всю выручку делим на всех активных, даже на тех, кто ничего не заплатил.
ARPU = выручка / все юзеры

SELECT
    SUM(revenue) / COUNT(DISTINCT user_id) AS arpu
FROM payments;

2️⃣ ARPPU — доход на ПЛАТЯЩИХ
Та же выручка, но делим только на тех, у кого платёж больше нуля.
ARPPU = выручка / платящие

SELECT
    SUM(revenue) / COUNT(DISTINCT CASE WHEN revenue > 0 THEN user_id END) AS arppu
FROM payments;

3️⃣ Связь — доля платящих
доля платящих = платящие / все юзеры = CR to pay (часто 1–5%)
Отсюда главное тождество:
ARPU = ARPPU × доля платящих
И всегда ARPPU >= ARPU.

4️⃣ Куда расти
Тождество показывает два рычага роста:
• поднять долю платящих — онбординг, триггеры оплаты
• поднять ARPPU — апселл, тарифы, допродажи

Итог: 🤩  

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓  Что еще разобрать? Пишите в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации:  Написать в ЛС | mentor.dima-sqlit.ru 


@dima_sqlit

🏦  Разбор задачи с собеседования в Т-Банке (Тинькофф). Тест точен на 99%, он положительный — но вы, скорее всего, здоровы:

Ранее мы разобрали, как работает условная вероятность и формула Байеса.
Если пропустили, то вот сам пост.

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

Условие: болезнь встречается у 1% людей. Тест находит болезнь у больного в 99% случаев, а у здорового ошибочно кричит «+» в 5% случаев. Вам пришёл положительный результат. Какова вероятность, что вы действительно больны?

Почти все на автомате отвечают «99%». Правильный ответ — 16.7%. Разберём, почему.

1️⃣ Вопрос не тот, на который вы ответили:

В условии дано P(+ | болен) = 99% — «тест сработает, если человек болен».
А спрашивают P(болен | +) — «человек болен, если тест сработал».

Это разные вопросы, и цифры у них разные. Формула Байеса как раз переворачивает условную вероятность с одной стороны на другую.


2️⃣ Считаем по головам — 10 000 человек:

Забудем про проценты и посчитаем живых людей:
• больных: 1% от 10 000 = 100 человек
• здоровых: 9 900 человек

Прогоняем всех через тест:
• из 100 больных тест поймает 99% = 99 человек
• из 9 900 здоровых тест ошибочно испугает 5% = 495 человек

тест + тест − всего
болен 99 1 100
здоров 495 9405 9900
всего 594 9406 10000

Смотрим столбец «тест +»: плюс получили 594 человека, а больны из них только 99.

P(болен | +) = 99 / 594 = 1/6 ≈ 16.7%

3️⃣ Тот же ответ формулой Байеса:

Сначала выпишем всё, что даёт условие — новых чисел дальше не появится:

P(болен) = 0.01 — болезнь у 1% людей
P(здоров) = 0.99 — остальные 99%
P(+ | болен) = 0.99 — тест ловит больного
P(+ | здоров) = 0.05 — ошибка на здоровом

⚠️ Два разных числа выглядят одинаково: 0.99 — это и точность теста, и доля здоровых. Не перепутайте, кто где стоит.

Числитель — только больные с плюсом:
P(болен) × P(+|болен) = 0.01 × 0.99 = 0.0099 → это наши 99 человек

Знаменатель — почему он именно такой
Мы ищем долю: из всех, у кого плюс, сколько по-настоящему больны. Значит внизу должны стоять ВСЕ плюсы, а не только больные — иначе это будет не доля.

А плюс может прийти ровно из двух мест:
• тест поймал больного → 0.01 × 0.99 = 0.0099 → 99 человек
• тест ошибся на здоровом → 0.99 × 0.05 = 0.0495 → 495 человек

Третьего источника нет: человек либо болен, либо здоров, других вариантов не бывает. Поэтому знаменатель — сумма этих двух групп (это и есть формула полной вероятности):

P(+) = 0.0099 + 0.0495 = 0.0594 → 594 человека

Внутри каждой группы мы умножаем по одному правилу: «какая группа по размеру» × «какая доля в ней даёт плюс». Для здоровых это 0.99 × 0.05 — 99% людей здоровы, и 5% из них тест пугает зря.

Делим: 0.0099 / 0.0594 ≈ 0.167 = 16.7%

Ровно те же 99 и 594, что мы посчитали по головам. Формула ничего не выдумывает — она просто записывает подсчёт людей на языке вероятностей.

Итог: 🤩  

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓  Встречали эту задачку на собеседованиях? Пишите в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации:  Написать в ЛС | mentor.dima-sqlit.ru 


@dima_sqlit

🛒 Разбор задачи с собеседования в Авито:

Условие: в мешке три кубика — на 6, 12 и 20 граней. Взяли один наугад, бросили — выпало 12. Бросаем этот же кубик ещё раз. Какова вероятность, что выпадет число меньше 12?

1️⃣ Что понятно сразу
6-гранный отпадает: числа 12 на нём просто нет. Значит в руке либо 12-гранный, либо 20-гранный.

2️⃣ Почему не 50 на 50
12 выпадает на этих кубиках по-разному: на 12-гранном — 1 раз из 12, на 20-гранном — 1 раз из 20. Раз у вас она выпала, вероятнее, что в руке именно 12-гранный.

3️⃣ Насколько именно чаще
Чтобы сравнить кубики честно, дадим каждому одинаковое число бросков. Возьмём 60 — оно делится и на 12, и на 20, поэтому получатся целые числа:

12-гранный: двенадцатка выпадет 60 : 12 = 5 раз
20-гранный: двенадцатка выпадет 60 : 20 = 3 раза

Итого 12-ть выпало 8 раз: пять раз с 12-гранного и три — с 20-гранного.

А если взять не 60 бросков, а другое число?
Ничего не изменится — важна только пропорция, а не сама цифра:

по 120 бросков → 10 и 6
по 600 бросков → 50 и 30
по 60 бросков → 5 и 3

Везде одно и то же: 12-гранный даёт 12-ать в 5 случаях из 8. Число 60 удобно только тем, что делится нацело: возьми 50 — вышло бы 4.17 и 2.5, та же пропорция.

При чём тут эти 8 случаев
По условию 12-ать уже выпало. Значит все броски, где выпало что-то другое, к вам не относятся — вы находитесь внутри тех самых 8 случаев. И в пяти из них у вас в руках 12-гранный кубик. Вот и всё, никакого 50 на 50.

4️⃣ Второй бросок
Считаем, как часто на каждом кубике выпадает меньше 12. Подходят числа от 1 до 11 — это 11 нужных граней:

на 12-гранном: 11 граней из 12 = 92%
на 20-гранном: 11 граней из 20 = 55%

Осталось соединить это с восемью случаями. В пяти из них у вас в руках 12-гранный и шанс 92%, в трёх — 20-гранный и шанс 55%. Считаем среднее по всем восьми, как среднюю оценку в классе:

(5 × 92% + 3 × 55%) / 8 ≈ 78%

5️⃣ Второй случай из тестового: выпало 4
Логика ровно та же, только теперь подходят все три кубика. Снова по 60 бросков каждым:

6-гранный: 60 : 6 = 10 четвёрок
12-гранный: 60 : 12 = 5
20-гранный: 60 : 20 = 3
всего 18 случаев

Меньше 4 — это 1, 2 и 3, то есть 3 нужные грани:
на 6-гранном: 3 из 6 = 50%
на 12-гранном: 3 из 12 = 25%
на 20-гранном: 3 из 20 = 15%

Среднее по восемнадцати случаям:
(10 × 50% + 5 × 25% + 3 × 15%) / 18 ≈ 37%

Итог: 🤩  

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓  Встречали эту задачку на собеседованиях? Пишите в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации:  Написать в ЛС | mentor.dima-sqlit.ru 


@dima_sqlit

🌐 Разбор задачи с собеседования в Яндекс. Парадокс Монти Холла:

Условие: Три двери, за одной приз, за двумя пусто. Вы выбрали дверь 1. Ведущий открыл дверь 3 — там пусто — и предлагает поменять выбор на дверь 2. Стоит ли изменить выбор?

1️⃣ Ловушка
Дверей осталось две, приз за одной. Кажется, шансы равны — 50 на 50.

Это самый частый ответ и он неверный. Ошибка в том, что мы считаем оставшиеся двери одинаковыми. А они не одинаковые: одну выбрали вы наугад, вторую оставил ведущий, который знает расклад.

2️⃣ Деталь, на которой держится вся задача
Ведущий знает, где приз. И у него связаны руки:

— вашу дверь он не трогает
— дверь с призом он не открывает

Значит его ход не случаен. Он не «просто открыл пустую дверь» — он был обязан открыть именно пустую. И этим он сливает вам информацию


3️⃣ Перебор: три расклада, больше их не бывает
Ваш выбор — дверь 1. Приз может быть за любой из трёх дверей, и все три случая равновероятны. Просто пройдём их по очереди и посмотрим, что даёт СМЕНА выбора.

• Приз за дверью 1 (вы угадали сразу)
Ведущий открывает 2 или 3 — обе пустые. Меняете → попадаете на пустую. ✗ мимо

• Приз за дверью 2
Ваша дверь 1 пустая, дверь 3 пустая. Открыть 1 он не может (ваша), открыть 2 не может (там приз) — остаётся дверь 3. Меняете → берёте дверь 2 с призом. ✓ приз

• Приз за дверью 3
Зеркально: он обязан открыть 2. Меняете → берёте дверь 3 с призом. ✓ приз

Итого смена выигрывает в 2 случаях из 3.

4️⃣ Почему так получается
Посмотрите, когда смена проигрывает. Ровно в одном случае — если вы угадали приз с первого раза. А это 1 шанс из 3.

Дальше просто:

вы угадали сразу → 1/3 → смена проигрывает
вы не угадали → 2/3 → смена ВСЕГДА выигрывает

Во втором случае смена выигрывает не «иногда», а всегда: если ваша дверь пустая, то из двух оставшихся одна с призом, и пустую ведущий уже открыл за вас. Он своими руками сложил все ваши 2/3 в одну-единственную дверь.

Остаться: 1/3 (33%)
Поменять: 2/3 (67%)

Ваш первый выбор как был 1/3, так им и остался — ведущий про вашу дверь ничего не сообщил, он и не мог её открыть. Зато про две другие сообщил всё.

Итог: 🤩  

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓  Какой ответ вы дали первым — 50 на 50 или сразу «менять»? И смогли бы объяснить почему? Пишите в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации:  Написать в ЛС | mentor.dima-sqlit.ru 


@dima_sqlit