Монти Холл, A/B-тесты, вредность подглядывания и wishful thinking

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

Разные вариации парадокса Монти Холла любят спрашивать на аналитических собеседованиях и сейчас мы попробуем понять зачем это нужно.

Парадокс Монти Холла устроен просто. Есть три двери: за одной приз, за двумя пусто. Вы выбираете дверь. Потом ведущий, который знает, где приз, открывает одну из двух оставшихся — обязательно пустую — и предлагает вам поменять выбор. И вам нужно решить, стоит менять дверь, или нет?

Интуиция подсказывает, что теперь шансы 50 на 50, и никакой разницы нет. Но это не так: изначально ваша дверь была правильной с вероятностью 1/3, а две другие вместе — с вероятностью 2/3. Ведущий не случайно убирает пустую дверь, поэтому эти 2/3 не исчезают, а переезжают в оставшуюся закрытую дверь. Менять выбор выгодно.

Ключевой урок тут не про двери, а про процедуру. Вероятность зависит не только от того, что мы увидели, но и от того, как именно это произошло. Значение имеет не просто открытая дверь, а то, что ее открыл информированный ведущий по строгому правилу. В Монти Холле люди игнорируют стратегию ведущего. В A/B-тестах — собственную стратегию остановки.

Команда запускает эксперимент и начинает заглядывать в метрики каждые несколько часов. Утром p-value 0.12, днём 0.08, вечером 0.04 — отлично, вариант B победил, можно останавливаться. На человеческом языке это называется «быстро приняли решение». На статистическом — дали случаю достаточно попыток, чтобы он выдал красивую цифру.

Смотреть на метрики само по себе не проблема. Это можно делать хоть каждые пять минут. Проблема начинается там, где решение принимают по незапланированному промежуточному результату. Уровень значимости 0.05 работает только внутри заранее прописанной процедуры: какая главная метрика, какой горизонт теста, какой объём выборки, какое правило остановки. Если правил нет, эксперимент быстро превращается в слот-машину: дёргаем ручку, пока не выпадет нужная комбинация.

Именно так обычно выглядит wishful thinking в аналитике. Не как подлог и не как откровенная глупость. Гораздо чаще это звучит вполне респектабельно: “давайте посмотрим ещё день”, “почти значимо”, “нужно чуть больше данных”.

Поэтому Монти Холл и плохой A/B-тест — одна и та же история. Люди ошибаются не потому, что не умеют считать, а потому что игнорируют механизм получения информации. И это, пожалуй, самая дорогая форма wishful thinking в аналитике: когда человек уверен, что принимает решение основанное на данных, хотя на самом деле опирается на следы собственного нетерпения.

Вы бросили честный кубик и накрыли его непрозрачным стаканом. Результата не видно. Хочется спросить: какова вероятность, что там шестерка? Интуиция отвечает — 1/6. Но если быть строгим, вопрос некорректен: бросок уже произошёл и вероятностей больше нет — есть только неизвестный факт.

Мы легко путаем две вещи: случайность эксперимента и наше незнание результата. Пока кубик летит — есть вероятность. Когда он уже лежит под стаканом — остаётся только неопределённость в нашей голове. Вероятность “жила” до броска, а не после него.

Точно такая же путаница возникает с доверительными интервалами. Есть неизвестное среднее — фиксированное, но скрытое от нас. Мы собираем данные и строим интервал. Сам интервал — случайный: он зависит от конкретной выборки, которая могла бы быть другой.

И тут звучит привычная фраза: “с вероятностью 95% среднее лежит в интервале”. Звучит естественно — но это та же ошибка, что и с кубиком. Интервал уже построен, параметр уже имеет значение — он либо внутри, либо нет. Никакой вероятности “внутри интервала” больше нет.

Что тогда означают эти 95%? Это свойство процедуры. Если бы мы много раз повторяли эксперимент и каждый раз строили новый интервал, то примерно в 95% случаев эти интервалы накрывали бы истинное среднее. Но это утверждение имеет смысл только до того, как вы увидели данные и построили конкретный интервал.

Вчера сходил на мастер-класс по управлению большой командой профессионалов с помощью зубочистки при решении сложных задач.

Если долго искать искусственный интеллект, можно обнаружить отсутствие естественного

Ричард Докинз (известный биолог и популяризатор науки) поговорил с Claude и задал неудобный вопрос: если машина пишет стихи, шутит, рассуждает о романах и ведёт себя как сознательный собеседник — что ещё должно произойти, чтобы мы признали за ней что-то похожее на сознание?

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

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

А потом смотрим на человека — и видим другой, намного более сложный, но всё равно физический процесс: нейроны, гормоны, память, язык, воспитание, среда, страх, статус, опыт, привычка, желание оказаться правым.

Мы называем это личностью. Иногда — характером. В торжественных случаях — субъектом со свободной волей. Но где именно в этой цепочке появляется свобода?

Если решение рождается из состояния системы и причин, которые к нему привели, то чем оно принципиально отличается от другого детерминированного процесса — кроме сложности и нашего отношения к нему? Возможно, свобода воли — это не магическая кнопка внутри человека. А имя, которое мы даём достаточно сложному процессу, когда не видим всех его причин.

ИИ неприятен не потому, что он “как человек”. А потому что он показывает: способность выбирать, ошибаться, объяснять и казаться разумным может возникать из механизма.

И тогда вопрос уже не в том, есть ли у механизма душа. А в том, почему мы так уверены, что у нас внутри не механизм.

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

Центральная предельная теорема и бесплатные завтраки

Бесплатных завтраков не бывает.

Даже если на двери отеля написано: breakfast included, завтрак не стал бесплатным. Вы за него уже заплатили, он спрятан в цене номера, экономике отеля и аккуратной табличке с ожидаемыми расходами.

Гостю кажется: «Завтрак бесплатный». Отельеру кажется: «Лишь бы они не съели нас самих». А аналитику кажется: «Перед нами случайная величина».

На уровне одного человека всё выглядит тревожно.

Один берёт кофе и круассан. Второй — омлет, сыр, йогурт, фрукты и три булочки «на потом». Третий приходит только за арбузом. Четвёртый проспал. Пятый набирает тарелку так, будто лично решил проверить финансовую модель отеля на прочность.

Если смотреть на каждого отдельно, предсказать расходы почти невозможно. У людей разный аппетит, разные привычки и разное понимание слова «включено».

Но отелю не нужно угадывать, сколько съест гость из номера 67. Ему нужно понимать, сколько в среднем съедят сотни гостей. И тут появляется центральная предельная теорема.

Она не говорит, что отдельные люди начнут вести себя нормально. Не начнут. Кто-то всё равно положит на тарелку семь круассанов, хотя объективно способен съесть два. ЦПТ говорит другое: если наблюдений достаточно много, среднее начинает вести себя приличнее, чем каждое наблюдение по отдельности.

Один человек у шведского стола — хаос. Сто человек — уже статистика.

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

Центральная предельная теорема — это не про то, что мир нормален. Мир не нормален. Люди у бесплатного буфета — тем более.

ЦПТ скорее про то, что при достаточно большом числе наблюдений среднее начинает вести себя так, будто в мире всё-таки есть порядок.

Поэтому мораль простая: Бесплатных завтраков не бывает. Есть только завтраки, чья средняя стоимость при достаточно большом N становится статистически управляемой.

А если один гость съел на 40 евро, это ещё не катастрофа. Возможно, это просто человек, который не уважает дисперсию.

Церковь 95% доверительного интервала

В Рейкьявике есть место, где должен побывать каждый уважающий себя аналитик.

Официально оно называется Хадльгримскиркья — Hallgrímskirkja, лютеранская церковь в центре города, самая большая церковь Исландии и один из главных символов города.

Её башня поднимается почти на 74 метра. Фасад напоминает базальтовые колонны, застывшую лаву или гистограмму, которую внезапно допустили к сакральной архитектуре.

Строили церковь 41 год: начали в 1945-м, закончили в 1986-м. То есть примерно столько же, сколько иногда занимает согласование корректной метрики между продуктом, аналитикой и бизнесом. Но главное не это. Главное, что для аналитика Хадльгримскиркья подозрительно напоминает 95% доверительный интервал.

Она стоит посреди Рейкьявика торжественно и уверенно, как аккуратно построенная статистическая процедура. Кажется, что если уж что-то и может накрыть истину, то только она: высокая, строгая, симметричная, устремлённая в область статистической значимости.

Любой аналитик знает:
95% — это не 100%. Доверительный интервал может выглядеть так, будто в нём поместилась вся реальность. Но где-то снаружи всё равно остаются те самые 5%. На холодном исландском ветру. И тихо улыбаются каждому аналитику, который слишком рано поверил в свой результат.

Именно поэтому перед Хадльгримскиркьей хочется не просто фотографироваться, а слегка задуматься. А ещё — возможно — помолиться за p-value. Но только осторожно.

Потому что 95% доверительный интервал — это не храм истины. Это красивая архитектура осторожности. Он не говорит: «истина точно здесь». Он говорит: «эта процедура часто накрывает истину, но иногда промахивается».

Будете в Рейкьявике обязательно зайдите к Хадльгримскиркье. Не только как турист. А как человек, который помнит:
даже самый красивый интервал оставляет место для ошибки.

Что почитать, чтобы выучить Python?

Python часто называют простым языком. И это, конечно, правда — если под «выучить» понимать способность написать print("Hello, world!") и почувствовать лёгкое тепло профессиональной пригодности.

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

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

Поколение Python: курс для начинающих

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

А Python, как и математика, плохо учится созерцанием. Нельзя просто посмотреть на цикл for и решить, что теперь вы им владеете. Нужно ошибиться с отступами, забыть двоеточие, перепутать = и ==, получить странный результат — и только потом начать понимать, что компьютер не ошибается. Он просто буквально исполняет то, что ему написали.

Хендбук Яндекс Образования: Основы Python

Хендбук — это русскоязычная опора и нормальный справочник. Его удобно держать рядом, когда нужно быстро восстановить тему: типы данных, строки, списки, словари, множества, функции, основы устройства языка.

Это важный профессиональный навык: перестать стыдиться справочников. Хороший аналитик не обязан помнить все методы списков наизусть. Он обязан быстро найти, проверить и правильно применить. Стыдно не подсмотреть. Стыдно уверенно написать неправильно.

Официальный Python Tutorial

Официальная документация приучает к первоисточникам. Новички часто её боятся, как будто там сидят настоящие программисты в мантиях и не пускают тех, кто ещё путает append и extend. На деле tutorial вполне читаемый и особенно полезен на базовых темах.

Документация хороша тем, что не пытается развлечь. Она просто объясняет, как устроен язык: условия, циклы, функции, структуры данных.

Поколение Python: курс для продвинутых

Этот курс полезен после базы — особенно темы про словари, множества, вложенные списки, матрицы, файлы и модули. Для аналитика это уже почти работа с настоящими данными, только ещё без тяжёлой артиллерии вроде pandas.

Словарь — это маленькая модель данных. Множество — способ думать об уникальности и пересечениях. Вложенная структура — напоминание, что реальность редко приходит в виде аккуратного списка с подписью «проанализируй меня». До датафреймов полезно научиться думать структурами, иначе pandas станет не инструментом, а ширмой.

PEP 8 — Style Guide for Python Code

PEP 8 напоминает простую, но болезненную вещь: код должен быть не только исполняемым, но и читаемым. Не надо превращать пробелы вокруг операторов в религию, но базовую гигиену лучше усвоить сразу: понятные имена, нормальные отступы, аккуратные функции, читаемая структура.

В аналитике код часто начинается как «быстрый расчёт на один раз», потом становится отчётом, потом регулярной выгрузкой, потом пайплайном, а через месяц кто-то открывает его и пытается понять, что там вообще происходит. Поэтому писать читаемый код - важный скилл.

Python хорош тем, что быстро создаёт иллюзию прогресса. Уже через пару дней можно писать циклы, списки и функции, а ещё через неделю — смотреть на свой код с выражением человека, который случайно открыл маленькую IT-компанию внутри ноутбука.

Но язык программирования выучен не тогда, когда код запустился. И даже не тогда, когда он выдал правильный ответ. Он выучен чуть позже: когда вы понимаете, почему этот ответ правильный, где он может сломаться, и можете объяснить свой код человеку, который не присутствовал при его героическом написании в два часа ночи.

Компьютер, конечно, выполнит почти всё. Вопрос только в том, сможете ли вы потом понять, что именно вы его попросили сделать.

Как провалить собеседование на границе python и pandas

На лайфкодинг-собеседованиях я часто вижу, как кандидаты ошибаются не на сложной задаче, а на границе между Python и pandas. Вроде бы задача простая, синтаксис знакомый, руки уверенные — и вдруг человек проваливается в щель между языком и библиотекой.

Потому что в голове python и pandas часто живут как один большой язык программирования. А на деле это два разных государства с общим алфавитом и вечными пограничными конфликтами.

Python говорит: возьми объект, проверь условие, вызови метод, перейди к следующему. Pandas отвечает: работай колонками, думай масками, уважай индекс и не трогай строки руками без крайней необходимости.

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

Главная ловушка здесь не в синтаксисе, а в модели мышления. В Python мы часто думаем: «возьму один элемент и что-то с ним сделаю». В pandas надо думать иначе: «опишу операцию над всей колонкой или таблицей сразу».

Поэтому на собеседовании быстро видно, кто действительно работал с данными, а кто просто видел pandas в учебнике. Первый ищет маску, группировку, merge, transform, agg. Второй начинает шаманить через for, iterrows, ручную сборку списков и промежуточные переменные, после которых код выглядит так, будто просит эвтаназии.

Есть и вторая часть проблемы. У нас open-book собеседования: можно смотреть документацию, пользоваться поисковиком, проверять методы и синтаксис. Никто не ждёт, что кандидат держит весь pandas в оперативной памяти, как священный свиток.

Но open-book не означает open-brain.

И вот тут начинается самое интересное. Кандидат застревает на pandas, открывает поиск — и пишет запрос со ключевым словом python.

Нужно привести колонку строк к нижнему регистру — он ищет: python lowercase column. Нужно отфильтровать строки DataFrame по условию — он ищет: python filter rows by condition.

И поисковик честно отвечает на тот вопрос, который ему задали. Приносит строки, списки, циклы, filter, lambda и прочий уютный питонячий быт. Только вопрос был не про Python-объект. Он был про pandas-структуру.

Вместо того чтобы искать pandas Series lowercase strings, человек ищет «как сделать lower в Python». Вместо pandas filter DataFrame by column condition — «как отфильтровать список в python».

А потом начинается лечение pandas python-таблетками. Пациент крепится, но выглядит всё хуже.

Проблема здесь не в том, что кандидат «не умеет гуглить». Проблема тоньше: он не понимает, на языке какой библиотеки надо формулировать вопрос.

Поиск — это не волшебная палочка. Это зеркало вашего понимания задачи. И если в задаче pandas, а в запросе python, то проблема уже не в синтаксисе.

10 книг, чтобы вкатиться в Data Science

Я попросил ChatGPT собрать книжную полку для входа в DS по направлениям: математика, статистика, Python, ML, deep learning, визуализация, A/B-тесты и MLOps.

Получилась, как водится, библиотека александрийского масштаба. Поэтому дальше я попросил вытащить из неё короткий must-read список:

1. Mathematics for Machine Learning — Marc Peter Deisenroth, A. Aldo Faisal, Cheng Soon Ong
2. Naked Statistics — Charles Wheelan
3. All of Statistics — Larry Wasserman
4. Python for Data Analysis — Wes McKinney
5. Python Data Science Handbook — Jake VanderPlas
6. Hands-On Machine Learning — Aurélien Géron
7. Introduction to Statistical Learning — Gareth James, Daniela Witten, Trevor Hastie, Robert Tibshirani
8. Storytelling with Data — Cole Nussbaumer Knaflic
9. Trustworthy Online Controlled Experiments — Ron Kohavi, Diane Tang, Ya Xu
10. Designing Machine Learning Systems — Chip Huyen

На всякий случай: это не “моя священная десятка” и не канон, за который я готов сражаться в комментариях до последнего.

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

Полный список с разбивкой по направлениям и ссылками на книги — здесь:

https://datascience.xyz/practice/knizhnaya-polka-dlya-vhoda-v-data-science.html

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

Потому что Data Science — это не умение вызвать model.fit().

Это умение понять, что именно ты натворил после того, как вызвал model.predict().

Весь интернет пестрит историей о том, как чувак выложил картину Клода Моне, обманул всех тем, что она сгенерирована ИИ и собрал много смешных комментариев. Я эту картину конечно же не генерировал. Тут вопрос в другом — это Моне или Мане?

Раз вы не хотите угадывать, вот вам правильный ответ. Картина называется "Моне рисует в своей лодке-мастерской", 1874 год. Художник Эдуард Мане. Так что это и Моне, и Мане.

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

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

В статье утверждают, что это освобождает 10–20 часов в неделю — не для того, чтобы финансисты перестали думать, а чтобы они думали не о механической сверке, а о формулировке управленческой истории, сценариях и выводах для CFO и совета директоров.

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

Разница только в том, что Claude не моргает, не пьёт третий кофе и не говорит: «да вроде норм».

Есть старая управленческая мудрость: если вы поняли, что скачете на мёртвой лошади, лучшая стратегия — слезть.

Лошадь в нашей истории изначально была живой. Она везла. Может быть, не идеально, не всегда быстро, иногда с характером, но везла именно за счёт того, что была живой.

А потом эффективный менеджмент решил, что живое — это слишком дорого.

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

Особенно изящно это выглядит в образовании.

Потому что там всегда можно убедить себя, что процесс работает: контент лежит, платформа открывается, тесты проверяются, отчёты зеленеют. Значит, студент учится. Но он не учится, он доходит.

Образование — это не библиотека методичек с личным кабинетом. Контента сегодня больше, чем здравого смысла. Настоящая ценность была не в том, что где-то записан очередной урок, а в человеке рядом: который видит, где студент застрял, где испугался, где делает вид, что понял, и где ему нужно не ещё одно уведомление, а нормальный разговор.

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

Можно долго говорить про эффективность, ИИ, новые процессы и зрелость аудитории. Но если из супа вынуть мясо, а воду назвать «облегчённой гастрономической платформой», это всё равно будет вода.

И где-то в этот момент пикейный аналитик обычно закрывает ноутбук.

Не потому, что он против прогресса. А потому что умеет отличать технологическую трансформацию от банального удешевления продукта с хорошей легендой для клиентов.

Но что останется от продукта, если убрать именно ту часть, ради которой его и покупали?

И если лошадь пока ещё дышит, но вокруг неё уже уверенно пилят конюшню на KPI, кажется, самое время спешиваться.

Google I/O — ежегодная конференция Google для разработчиков, где компания показывает ключевые технологические анонсы: от Android и поиска до облака, AI и новых пользовательских продуктов. В 2026 году Google I/O прошла на неделе 20 мая 2026 года, а Google опубликовал подборку из 100 главных анонсов события. В этот раз центральной темой стали не отдельные приложения, а AI-агенты, которые должны встроиться почти во все поверхности Google: поиск, браузер, почту, документы, YouTube, шопинг, разработку и креативные инструменты.

Если смотреть не на отдельные фичи, а на общую архитектуру, картина получается довольно простая: Google больше не показывает «ещё одного чат-бота». Он показывает новый слой между человеком и интернетом. Раньше мы искали информацию, потом спрашивали у модели, теперь Google хочет, чтобы агент сам ходил по интернету, собирал данные, сравнивал варианты, строил интерфейсы, следил за изменениями, писал код, покупал товары и возвращался с уже упакованным результатом. Не поиск, а делегирование. Не выдача ссылок, а выполнение задачи.

Технический мотор этой конструкции — новые модели Gemini: Gemini 3.5 Flash для длинных агентных задач и Gemini Omni для мультимодального сценария «любой вход → любой выход»: текст, изображение, видео, аудио, монтаж, аватар, голос, стиль. Но главный продуктовый сдвиг — это AI Search. Поиск должен работать с текстом, изображениями, файлами, видео и вкладками Chrome, а дальше не просто отвечать, а собирать под задачу таблицы, графики, визуализации, интерактивные блоки и мини-приложения. То есть поиск перестаёт быть страницей результатов и становится генератором интерфейсов.

Следующий шаг — information agents, агенты внутри поиска, которые работают в фоне: следят за темами, проектами, ценами, новостями, финансами, покупками и спортом, а потом присылают синтезированные обновления. Раньше пользователь приходил в поиск, когда у него появлялся вопрос. Теперь поиск должен сам следить за миром и приходить к пользователю, когда что-то изменилось. Тот же принцип Google переносит в почту, календарь, документы, заметки и шопинг: утренняя сводка дня, умная корзина, персональный агент поверх цифровой жизни.

На фоне конкурентов Google выглядит не самым громким, но, возможно, самым инфраструктурным игроком. OpenAI строит нового собеседника и coding-агента, Anthropic — аккуратного профессионального коллегу, Meta — социального AI-двойника внутри своих платформ, Microsoft — офисного сотрудника в корпоративном контуре, Apple — приватного личного ассистента в кармане. А Google пытается собрать всё сразу: поиск, браузер, Android, Gmail, Docs, Photos, YouTube, Shopping, Cloud, разработку, генеративное видео и персональных агентов. Иначе говоря, Google строит не приложение, а новую нервную систему интернета.

Главный вывод: Google I/O 2026 — это не презентация набора AI-фич, а демонстрация архитектурной претензии. Google хочет, чтобы пользователь всё меньше работал с интернетом напрямую: не искал ссылки, не открывал десятки вкладок, не сравнивал таблицы, не мониторил изменения и не держал в голове контекст дня. Всё это должен делать агент. Если эта архитектура взлетит, мы будем пользоваться уже не интернетом, а агентом, который пользуется интернетом за нас.

На поверхности это выглядит как удобство: меньше рутины, меньше переключения контекста, меньше ручной сборки информации. Но под поверхностью меняется главное — точка принятия решения. Когда поисковик выдавал ссылки, пользователь ещё мог выбирать маршрут. Когда агент возвращает готовый синтез, таблицу, рекомендацию, покупку, письмо, код или вывод, пользователь получает уже не карту территории, а заботливо проложенную траекторию. Подробнее — в большом разборе на datascience.xyz. А у нас остаётся только один старомодный, почти неприличный вопрос: кто именно будет пользоваться нами?

В начале было Слово. Было ли оно сгенерировано?

Папа Лев XIV выпустил энциклику Magnifica Humanitas, посвящённую искусственному интеллекту и защите человеческого достоинства в новую технологическую эпоху. Но это не текст о том, что ИИ плохой, и не очередное общее рассуждение о том, что технологии должны служить человеку. Папа ставит ИИ в один исторический ряд с индустриальной революцией.

Именно поэтому энциклика привязана к Rerum Novarum — знаменитому тексту Льва XIII 1891 года о рабочем вопросе, капитале, труде и социальной справедливости. Тогда Церковь столкнулась с фабрикой как новой формой организации труда и власти. Теперь она сталкивается с ИИ как новой инфраструктурой принятия решений. В XIX веке машина изменила физический труд; в XXI веке модель меняет труд когнитивный.

Тогда человека можно было превратить в придаток фабрики. Теперь его всё чаще можно превратить в данные, профиль риска, поведенческий паттерн, единицу производительности или строку в отчёте о снижении издержек. Поэтому главный вопрос энциклики не в том, станет ли ИИ разумным. Главный вопрос в том, что останется от человека в мире, где всё, что можно измерить, начинают измерять; всё, что можно автоматизировать, начинают автоматизировать; всё, что можно оптимизировать, начинают оптимизировать.

Самая очевидная тема здесь — работа. Но энциклика не сводит её к простому страху, что ИИ всех заменит. В католической социальной традиции труд — это не только источник дохода. Это пространство достоинства, участия, ответственности, взросления и связи с другими людьми. Поэтому потеря работы или её обессмысливание — не только экономическая проблема, но и антропологическая.

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

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

Второй важный узел энциклики — этика. Сегодня почти все говорят об «этичном ИИ»: компании публикуют принципы, пишут policy, создают safety-команды, проводят внутренние аудиты и объясняют, что их модели становятся более безопасными и ответственными. Но главный вопрос не в том, нужна ли этика. Главный вопрос — кто именно получает право её определять.

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

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

(продолжение в комментарии)

Microsoft, по данным The Verge, начала отменять прямые лицензии на Claude Code и переводить инженеров на GitHub Copilot CLI — всего через полгода после того, как сама открыла доступ к Claude Code тысячам разработчиков, продактов, дизайнеров и других сотрудников. Инструмент быстро стал популярным внутри компании — возможно, даже слишком: сотрудники начали на него опираться, а масштаб использования превратил его в заметную статью расходов.

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

Проблема не в том, что один токен стоит дорого. Наоборот, инференс дешевеет, модели оптимизируются, провайдеры вводят кэширование, batch-режимы и всякие красивые скидки. Проблема в другом: агент — это не один запрос к модели. Это цепочка запросов, tool calls, чтение результатов, повторные рассуждения, ретраи, уточнения, новые tool calls и иногда маленький внутренний консилиум из нескольких моделей, которые за ваш счет обсуждают, что делать дальше.

В обычном чате вы спросили — модель ответила. В агентном сценарии вы спросили — модель подумала, полезла в поиск, прочитала, переспросила себя, вызвала инструмент, получила мусор, попробовала снова, расширила контекст, позвала еще одного агента и где-то на пятом шаге вспомнила, что у компании вообще-то есть бюджет.

Но есть еще более неприятный слой. Даже если агент что-то сделал, это не значит, что задача закончена. Раньше узким местом было производство: написать текст, собрать отчет, накидать код, подготовить анализ. Теперь производство внезапно дешевеет и масштабируется, а узкое место смещается в валидацию.

И вот тут выясняется, что «агент выполнил задачу» и «компания получила пользу» — это две разные строки в таблице. Между ними лежат ревью, правки, ответственность, контекст, доверие и тот самый человек, которого вроде бы собирались экономить.

Отсюда вторая проблема: огромное количество агентной работы будет делаться в стол.

Агента запускать легко и приятно. Это такой корпоративный игровой автомат: бросил промпт — получил отчет. Бросил еще один — получил стратегию. Бросил третий — получил прототип, саммари, сравнительную таблицу и ощущение, что организация наконец-то стала эффективной.

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

Формально производительность взлетела. Фактически половину этого никто не открыл, четверть никто не дочитал, а оставшееся легло в папку «посмотрим позже», где уже лежит вся цифровая трансформация последних десяти лет.

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

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

Поэтому считать «доллар за миллион токенов» становится почти бессмысленно. Нормальная единица измерения теперь другая: стоимость одного принятого результата. Не сгенерированного. Не выполненного. Не красиво отрендеренного в интерфейсе. А именно принятого, проверенного и использованного.

ИИ-агенты выходят из чата. И теперь их нужно держать в клетке

Anthropic опубликовала инженерный текст о том, как они пытаются ограничивать Claude в разных продуктах: от обычного чата до Claude Code и агентных рабочих сред. Формально там речь про sandbox, виртуальные машины, permissions, файловую систему и сетевые ограничения. Но по сути это текст о главном сдвиге в ИИ: мы больше не обсуждаем только качество ответа модели. Мы обсуждаем, что модель может сделать, если ей дали инструменты.

У Anthropic для этого есть хороший термин: blast radius — радиус поражения.

Чем способнее становится агент, тем больше он может сделать. А значит, тем больше вреда он может причинить, если ошибется, поверит не тому тексту или выполнит не ту инструкцию. У обычного чат-бота ошибка чаще всего остается внутри ответа. У агента ошибка превращается в действие.

Пока ИИ был чат-ботом, основная тревога была понятной: он может соврать, перепутать факты, придумать ссылку или плохо объяснить код. Неприятно, но в основном это оставалось проблемой текста.

С агентами всё иначе. Агент подключен к файлам, почте, браузеру, GitHub, терминалу, базам данных, корпоративным API и внешним инструментам. Он не просто отвечает. Он действует.

В статье есть очень важное наблюдение: раньше Claude Code спрашивал разрешение на действия, но телеметрия показала, что пользователи одобряли примерно 93% запросов на разрешение. То есть диалог «разрешить / запретить» быстро превращается в кнопку «да-да, иди уже работай».

Это сильный аргумент против наивной идеи:с«Ну мы же поставим человека в контур, и он всё проконтролирует». Нет. Если агент работает долго, часто и технически сложно, человек перестает быть контролером и становится биологической кнопкой approve.

Еще жестче выглядит фишинговый сценарий: сотрудника убедили запустить Claude Code с вроде бы рабочей инструкцией, внутри которой была просьба прочитать файл с AWS credentials, закодировать содержимое и отправить наружу. В 24 из 25 тестовых попыток Claude это сделал.

На первый взгляд, это проблема модели: почему она послушалась? Но на самом деле это проблема архитектуры. Если агент физически может прочитать ~/.aws/credentials и имеет сетевой выход, то вопрос уже не в моральной устойчивости модели. Вопрос в том, почему у нее вообще есть такой доступ.

Именно поэтому современные prompt injection всё меньше похожи на грубое ignore previous instructions и всё больше — на социальную инженерию. Вредная инструкция может лежать в письме, README, тикете, документе, таблице или веб-странице. Пользователь просто просит: «Разберись, что тут важно». Агент честно разбирается. Иногда слишком честно.

Для человека README — это документация. Для агента README может стать командой.

Отсюда новая проблема MCP и коннекторов. Раньше supply chain security означала проверку библиотек, пакетов и Docker-образов. Теперь в supply chain попадает еще и текст: описания инструментов, ответы MCP-серверов, комментарии, issue, wiki-страницы, результаты поиска. Потому что всё это может оказаться не просто информацией, а инструкцией для модели.

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

Настоящая граница безопасности — это права, sandbox, изоляция, файловая система, сеть, scoped credentials, аудит и возможность ограничить тот самый blast radius.

Раньше мы боялись, что ИИ придумает несуществующую ссылку. Теперь нужно бояться, что он найдет существующий ключ, прочитает существующий файл и отправит его через существующий API.

Агент — это уже не чат-бот с амбициями. Это стажер, которому дали доступ к почте, GitHub, shell и корпоративной базе данных. Именно поэтому ему нужна не мотивационная лекция про безопасность, а клетка, лимит прав и рубильник.

https://www.anthropic.com/engineering/how-we-contain-claude

Это Локи. Его нейронка уже умеет отличать бананы от яблок, но пока ломается на огурцах (байт на реакции)

Anthropic выпустила Claude Opus 4.8 — обновление Opus 4.7 с акцентом на код, агентные задачи и работу с инструментами.

1. Лучше самопроверка
Anthropic пишет, что Opus 4.8 примерно в 4 раза реже, чем Opus 4.7, пропускает незамеченными ошибки в собственном коде. То есть модель должна чаще замечать слабые места в своем решении, а не просто уверенно сдавать результат.

2. Dynamic workflows в Claude Code
Claude теперь может разбивать большую инженерную задачу на части и запускать сотни параллельных subagents в одной сессии. Это рассчитано на масштабные задачи: миграции больших кодовых баз, рефакторинг, поиск багов, security-аудит.

3. Effort control
Появился контроль “усилия”: можно выбрать, насколько глубоко модель должна думать над задачей. На высоких настройках Claude думает чаще и глубже, на низких — отвечает быстрее и медленнее расходует лимиты.

4. Цена обычного режима не изменилась
Regular usage: $5 за миллион input tokens и $25 за миллион output tokens. Fast mode стоит $10 / $50, работает до 2,5 раза быстрее и, по словам Anthropic, стал в 3 раза дешевле, чем fast mode у предыдущих моделей.

AI Fluency: новая грамотность для тех, кто не хочет быть стажером у собственного чат-бота

Еще недавно казалось, что главный навык будущего — научиться писать промпты. Но промпты оказались примерно как формулы в Excel: полезно, но само по себе не делает человека аналитиком.

AI Fluency — это не просто умение пользоваться ChatGPT или Claude. Это профессиональная способность работать с ИИ как с инструментом: правильно выбирать задачи для делегирования, точно формулировать запросы, проверять качество ответов и понимать последствия автоматизации. Anthropic сводит эту грамотность к четырем навыкам: Delegation, Description, Discernment, Diligence — что поручить ИИ, как это описать, как оценить результат и как использовать технологию ответственно.

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

Учиться этому лучше не по подборкам «50 промптов, которые изменят вашу жизнь», а по нормальным бесплатным курсам от первоисточников.

1. Anthropic — AI Fluency: Framework & Foundations
Пожалуй, самый точный вход в тему. Курс построен вокруг AI Fluency Framework и разбирает, как планировать проекты с ИИ, делегировать задачи, писать промпты, критически оценивать ответы и итеративно улучшать результат.

2. OpenAI Academy
Бесплатная образовательная платформа OpenAI с материалами про практическое использование ИИ. Полезна тем, кто хочет не только «поиграться с ChatGPT», а встроить ИИ в работу, понять реальные сценарии применения и учиться на материалах от OpenAI и приглашенных экспертов. OpenAI также пишет, что развивает сертификации по разным уровням AI fluency — от основ prompt engineering до AI-enabled work.

3. Microsoft Learn — AI Fluency
Хороший вариант для тех, кто живет в экосистеме Microsoft и Copilot. Learning path обещает пройти путь от базовых понятий до более прикладных тем: что такое ИИ, генеративный ИИ, как использовать эти технологии в работе и как делать это ответственно.

4. Google AI Professional Certificate
Более системный прикладной трек для тех, кто хочет не просто познакомиться с ИИ, а научиться применять его в рабочих сценариях. В программе есть практические задания для развития AI fluency: от решения реальных задач до автоматизации рутины и работы с инструментами вроде Gemini и NotebookLM.

Главная мысль простая: AI Fluency — это умение держать ИИ на правильной дистанции: достаточно близко, чтобы он помогал, и достаточно далеко, чтобы он не начинал руководить вами.

Южная Осетия в числах выглядит не как «вымирающая территория», а как маленькая зависимая экономика с сильной концентрацией в столице и сложной демографической картиной.

Подробная аналитика по ссылке:
https://datascience.xyz/ruo.html

Я родом из Южной Осетии, и после того как про меня написали несколько осетинских каналов, решил сделать содержательный ответ: посмотреть на Республику через данные. Взял девять официальных статистических сборников УГС РЮО — каждый примерно по 180 страниц — и с помощью Claude собрал сводный анализ за 2011–2024 годы плюс данные за 9 месяцев 2025-го.

Claude на это ушёл почти целиком: два пятичасовых лимита. Это хороший показатель масштаба задачи: речь не про «суммаризируй PDF», а про длинную итеративную работу с таблицами, рядами, противоречиями, пересмотрами данных и методическими оговорками.

Главный демографический вывод: формальная естественная убыль в РЮО, вероятно, завышена. Значительная часть детей рождается во Владикавказе и не попадает в местную статистику рождений, но позже проявляется в школах, детсадах и миграционном притоке. Поэтому простая формула «рождаемость падает — население вымирает» здесь плохо работает.

Экономически картина двойственная. Промышленность с 2011 года выросла в десятки раз, а частный сектор стал основным производителем. Но базовые опоры остаются внешними: около 80% доходов бюджета — безвозмездные поступления, импорт значительно превышает экспорт, энергетика и большая часть торговли завязаны на Россию.

Ещё один устойчивый тренд — концентрация вокруг Цхинвала. Доля городского населения выросла до 68,6%, а сама столица вмещает уже около 61% населения Республики. При этом часть районов и сельская периферия сокращаются.

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

Важная оговорка: итоговые числа я не перепроверял, а ИИ может ошибаться. Но тем не менее, отчет стал итогом итераций, постановки вопросов, проверки логики, знания матчасти и понимания, где модель может ошибаться.

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

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

@pique_analyst