Review of Book "AI Engineering" #3 - Chapter 3 & 4: Evaluation Methodology и Evaluate AI Systems(Рубрика #AI)

Вышла третья серия подкаста с разбором крутой книги "AI Engineering", которая дает представление об оценке как самих foundation models, так и приложений на их основе. Книгу разбирает Александр Поломодов, технический директор Т-Банка, а также Евгений Сергеев, engineering director в Flo. Собственно, в этой серии мы обсудили две главы: "Chapter 3: Evaluation Methodology" и "Chapter 4: Evaluate AI Systems". Ну а если раскладывать по темам, то они представлены ниже

- Введение и тема выпуска
- Почему оценка ИИ‑приложений сложна; рост важности валидации
- Валидация в пайплайнах и сложности доменов
- Ограничения бенчмарков и переход к продуктовой валидации
- Риски неконтролируемой генерации
- Теория информации: энтропия как база метрик
- Кросс‑энтропия и KL‑дивергенция для оценки моделей
- Перплексия и влияние контекста на уверенность модели
- Функциональная корректность vs нефункциональные требования
- От лексической к семантической близости; эмбеддинги
- Паттерны валидации и AI as a judge
- Попарные сравнения и ранжирование моделей; транзитивность и голосования
- Каркас системы: критерии → выбор моделей → сборка пайплайнов
- Факт‑чек и референс‑чек; доверенные источники; человеческий бейзлайн
- Дизайн пайплайна: независимые тесты, гайдлайны, разметка; финальные выводы

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

[1/2] Monarch: Google's Planet-Scale In-Memory Time Series Database (Рубрика #Architecture)

Наконец-то я дочитал оригинальный whitepaper про эту интересную систему для работы с time-series данными от Google. Идея появилась после моего погружения в архитектурный whitepaper, где эту систему перепроектировали с использованием quality-based подхода и UML диаграмм. Если кратко, то суть примерно такая, что в 2020 году вышла статья на VLDB Endowment про эту самую масштабную в мире базу для временных рядов
1) Monarch - это глобально распределённая, мультитенантная in‑memory БД временных рядов для мониторинга почти всех пользовательских и инфраструктурных сервисов Google. Ежесекундно принимает терабайты метрик и обрабатывает миллионы запросов. Архитектура - разделенная по регионам с глобальным plane запросов и конфигурации.
2) Ключ к масштабу: лексикографическое шардирование по “target”, агрегация на этапе сбора, компактные индексы подсказок (Field Hints Index), двухуровневые исполнители запросов (Root/Zone Mixers).
3) На июль 2019: почти 950 млрд рядов в оперативной памяти (~петабайт сжатых данных); средняя агрегация при сборе 36:1 (до 1 000 000:1); индексы позволяют срезать fan-out до десятков тысяч лишних leaf‑узлов.

Как это примерно работало
- Система мультитенантная и глобальная. Региональные зоны автономно принимают и хранят данные в памяти, а глобальные плоскости обеспечивают единый запрос и конфигурацию. Это снижает зависимость от внешней персистентности и повышает доступность мониторинга во время инцидентов.
- Модель данных и запросов отличается от предшественника Borgman (кстати, именно Borgman стал прототипом Prometheus - об этом можно глянуть в документалке, о которой я рассказывал). В отличие от “строчных ключей” прежних систем, Monarch использует типо‑насыщенную реляционную модель метрик (включая распределения/гистограммы) и выразительный язык запросов, что упрощает статический анализ и оптимизации.
- Архитектура обработки выглядела примерно так
-- Ингест: клиенты → ingestion routers → зона → leaf router → Leaves (in‑memory). Уже здесь может работать collection aggregation.
-- Запросы: Root Mixer распределяет по зонам (Zone Mixers); Index Servers (в т.ч. Field Hints Index) заранее исключают нерелевантные узлы, резко уменьшая фан‑аут.
- Отдельно были сделаны оптимизации
-- Collection aggregation: в среднем 36 входных рядов → 1; в экстремуме до 10⁶:1. Экономит память/CPU и трафик.
-- Field Hints Index (FHI): зоны с >10 000 leaves и триллионами ключей; FHI позволяет отсечь ~73 000 нерелевантных leaves для сложных выборок.
-- Лексикографическое шардирование по target: все метрики одного объекта попадают на один leaf → локальные агрегации/джойны, меньше fanout.

В продолжении рассказ, а что было с этой системой дальше.

#Software #Architecture #DistributedSystems #SRE #Engineering #Databases #Data

[2/2] Monarch: Google's Planet-Scale In-Memory Time Series Database (Рубрика #Architecture)

Но на этом история монарха не закончилась. Уже в 2023 году на конфе ICSE‑SEIP’23 ребята из Google опубликовали whitepaper-продолжение (что я уже разбирал).
Тезисно этот paper можно сократить до следующих пунктов
1) Причина: двукратный рост год‑к‑году QPS и числа рядов, проблемы с поддержкой и дальнейшим попаданием в SLO
2) Команда решила провести редизайн с опорой на quality‑attribute сценарии + лёгкие UML‑модели
3) Фактически, декомпозицировали Leaf на Leaf (KV‑хранилище), Leaf Index Server и Leaf Mixer.
4) Это повлияло в плюс на доступность и сопровождаемость, а latency выросла умеренно, хотя хопов стало больше на 2  (рост с ~12–14 до 16–18 RPC)

Но и это было не все - принципы Monarch легли в основу облачного Managed Service for Prometheus: это сервис на том же бэкенде Monarch, которым Google мониторит свои сервисы. Запросы PromQL частично вычисляются на стороне Monarch. Для инженерных команд это даёт из коробки «глобальный» Prometheus‑опыт. Кстати, вопрос масштабирования отдельных Prometheus возникает у крупных компаний часто и для решения этого вопроса появился проект Thanos. Еще можно глянуть на VIctoriaMetrics, этот проект тоже борется с ограничениями Prometheus, но по другому (можно глянуть мой разбор подкаста где автор проекта про это рассказывал)

Если подбивать уроки из истории Monarch, то стоит
- Собирать метрики ближе к источнику, аггрегировать рано (уменьшение кардинальности и стоимости)
- Дешёвый предикатный индекс → дешевле распределённые запросы (урезать fanout до выполнения)
- Строго разделять stateful и stateless части (проще сопровождать, легче выдерживать SLO при росте) - фокус на этом во втором whitepaper про редизайн
- Шардирование по бизнес‑ключу (target) - локальные агрегации/джойны дешевле.

#Software #Architecture #DistributedSystems #SRE #Engineering #Databases #Data

Программирование смыслов (Рубрика #AI)

Посмотрел вчера интересное выступление Алексея Гусакова, CTO бизнес‑группы «Поиск и рекламные технологии» в Яндексе. Алексей рассказывал об изменениях в подходах к созданию продуктов - они активно развивают ML и LLM‑стек и внедряет нейросети в ключевые сервисы (Поиск, Алиса, Браузер и др.). Если кратко, то фокус разработки смещается от детального кодирования алгоритмов к проектированию намерений и смыслов: вы формулируете задачу, ограничения, источники знаний и метрики качества, а поведение системы «программируете» комбинацией промптов, данных, инструментов и вознаграждения (reward). В такой модели ценность создаётся не одиночным микросервисом, а циклом: гипотеза → прототип → измерение → дообучение/тонкая настройка → интеграция. Внутренний стек и процессы должны это поддерживать.

Собственно, доклад Алексея отлично рассказывает переход к программированию смыслов по шагам
1) Как всё началось
В 2022 Яндекс запустил диалоговый эксперимент «Гуру по товарам» - это была попытка превратить поиск в помощника по выбору: задаёшь вопросы (“какой телек взять?”), система уточняет параметры и ведёт к покупке. Но пользователям не зашло - общение с гуру ощущалось как заполнение скучной анкеты. Команда потратила много ресурсов, наделала ошибок, но получила важные сигналы о том, какой диалог “продаёт”, а какой — раздражает.
2) Поворотный момент
В конце 2022 года вышел ChatGPT и появились генеративные ответы в Bing. Перед командой Yandex появилась дилемма: пилить “большую сложную штуку” (аля как у Bing) или идти инкрементально. Выбрали второе - быстрые, приземлённые улучшения вокруг текущей выдачи.
3) Что именно сделали (и где)
- Начали собирать ответы на основе сниппетов и инфоконтекста; обучили собственную LLM для абзацев‑ответов.
- Перешли к структурированным ответам из нескольких источников: модель планирует, какие документы использовать и как сшивать факты. Балансировали стабильность vs. риск: не выпускать “магический” ответ любой ценой, а двигаться ступеньками, проверяя качество. Сместили фокус с “идеальной рекомендации” к системе ограничений: не повторяться, сохранять разнообразие, поддерживать новичков и т. п. Оптимизация таргета происходила внутри набора правил, а не поверх “чёрной коробки”, - так проще контролировать поведение.
- Пошли в ассистенты, но абстрактные описания вроде “будь умным и полезным” не собирают дают продукт. Выработали принципы, которые действительно работают: ответы не слишком длинные/короткие, правдивые, персонализированные, без вымышленных товаров/свойств; форму ответа модель выбирает, глядя на онлайн‑сигналы.
4) Машинное обучение как конвейер
Запустили повторяемый цикл: AI-тренеры размечают и оценивают ответы → обучаются генеративная модель и модель вознаграждения (RM) → катим улучшения → снова собираем обратную связь. Стали на встречах “мудрецов” обсуждать работу моделей
- Использовали пайплайны с несколькими моделями на один запрос: даже с “замороженными” параметрами можно сильно вырасти за счёт правильной оркестрации и большего вычисления.
5) Какие проблемы были и как их лечили
- Reward‑хаккинг: после первого цикла RM модель “учится” радовать оценщик - внезапно удлиняет ответы, начинает копировать куски источников, вставляет лишние дисклеймеры.
- Фиксы: в модель rewards добавили регуляризацию на длину, штрафы за копипасту/канцелярит; отдрессировали стилистику. Был прикольный пример про дисклеймеры, которые оставили только там, где они реально помогают.
- В итоге, продуктовая и ML‑разработка смешались - промпты, RM, правила и метрики стали такими же артефактами продукта, как код.
6) Принципы ранжирования и ответов
Ссылки в выдаче — это смесь офлайн‑оценки релевантности и онлайн‑вероятности успеха.
Ассистенты строят ответы поверх этих ссылок, а не “из воздуха”, чтобы сохранять верифицируемость.

#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

Техношоу «Дропнуто»: выпуск 1 (Рубрика #SRE)

Посмотрел вчера интересный выпуск нового шоу "Дропнуто" от моих коллег из Т-Банка. В этом шоу ребята говорят об инцидентах на дата‑платформах, с честным разбором причин и выводов. Интересно, что шоу идет в прямом эфире, что должно вселять надежду в минимум редактуры и зап...ния. Формат выдержан в духе blameless postmortems, где мы подходим к постмортемам без обвиненений и даже с прицелом на обучение - чель поговорить про то, а почему отказы случаются, как их предотвратить и что изменить в процессах/архитектуре для повышения надежности (кстати, про надежность в Т-Банке хорошо рассказывал Леша Мерсон в статье, о которой я писал раньше).

В первом выпуске подкаста гостем был Александр Крашенинников из Т‑Банка, практик в области платформ данных/ETL/DWH, а также просто человек с хорошим чувством юмора и навыками импровизации, что можно увидеть из его рассказа о двухнедельном инциденте в датаплатформе, о котором он рассказывает в этом эпизоде. Цепочка инцидента выглядит кратко примерно так: удаление/потеря метаданных → падение чтения в Trino → нет бэкапа/медленное CDC‑восстановление → критичный инцидент → разворот на новую Kafka‑архитектуру + контракты → унификация схем, параллельные загрузки → валидация и исправление расхождений → восстановление сервиса с возможной частичной потерей → восстановление сервиса из бекапов и дозагрузка исторических данных.

Инженерам может понравитсья этот «боевой» разбор инцидента
- Эксплуатация CDC (change data capture): где Debezium удобен, его архитектурные варианты, типовые грабли
- Паттерны целостности: outbox‑подход для надёжного обмена событиями между сервисами и границы применимости.
- Наблюдаемость пайплайнов: какие SLI поднимать для «скорости данных» (freshness/latency), целостности (дупликаты/пропуски), устойчивости коннекторов.

Руководителям эпизод полезен для управленческой оптики:
- Единый язык риска: связать цвет/серьёзность инцидента с бюджетам ошибок и фризом релизов
- Культура обучения на сбоях: blameless‑постмортемы как системный инструмент качества и коммуникации между командами данных/продукта/SRE.
- Управление SLO: перевод пользовательских метрик (например, «данные в витрине свежи ≤ X минут 99,9% времени») в алерты и план/факт по риску.

#SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering #Databases #Data

[2/3] How States Think: The Rationality of Foreign Policy (Как мыслят государства: рациональность внешней политики) (Рубрика #Politics)

Продолжая рассказ о книге, надо отметить, что модель рациональности авторов содержат два слоя
1. Рациональность целей (goal rationality). Почти всегда на первом месте - выживание государства; остальные цели подчинены этому.
2. Рациональность стратегий (strategic rationality). В итоге, стратегические решений
- Опирается на достоверную теорию (реалистичные допущения, непротиворечивая каузальная логика, поддержка в данных/истории), и
- Появилось из открытой и «неподавляющей» процедуры обсуждения (без умолчаний, давления, искажения информации). Оценивать нужно процесс, а не только результат.

Ключом к их школе мыслей является разница между риском и неопределенностью. В международной политике чаще нет надёжных частот/базовых вероятностей, поэтому чистые расчёты EV/Expected Utility неприменимы - здесь имеет смысл построения надежных теорий + сценарный анализ и «проверка на худший случай».

Вот как выглядит критика стандартных подходов от авторов книги
1. Против expected utility. Модели, где рациональность = расчёт ожидаемой полезности, предполагают измеримые вероятности и стабильные предпочтения, а во внешней политике это редкость. Поэтому требовать от государств «считать EU в голове» - неправильно; разумнее оценивать качество применённой теории и качество процесса.
2. Против «все вокруг в bias’ах». Политпсихология/поведенческая экономика часто объявляет отклонения от expected utility «нерациональностью» (bias), упирая в аналогии, эвристики, «групповое мышление». Авторы отвечают:
- Эвристики ≠ нерациональность, если они встроены в внятную теорию и
- Групповые процедуры в госаппарате нередко сглаживают индивидуальные искажения. И главное - эти подходы почти не объясняют, как индивидуальные мнения агрегируются в государственные решения.

Если говорить про инженерную интерпретацию, то авторы предлагают сменить метрику оценки рациональности с «считал ли агент правильный expected value» на «была ли у агента валидная модель мира + нормальный review‑процесс принятия решения».

Свою модель авторы подтверждают разбором ситуаций, которые по мнению авторов были несправедливо названы нерациональными
- Начинается все с СВО в 2022 году - в предисловии книги разбирается как кейс, где на Западе быстро повесили ярлык «безумия», но авторы считают решение теоретически мотивированным (баланс сил, НАТО) и обсуждённым на уровне элиты.
- Германия, вступление в Первую мировую (1914) - превентивная логика против растущей мощи соперников и окна уязвимости.
- Япония, удар по Пёрл‑Харбору (1941) - попытка вывести из игры Тихоокеанский флот США и обеспечить ресурсы; рискованная стратегия, но не «иррациональный порыв».
- Германия, «Барбаросса» (1941) - авторы показывают, что ключевые лица рассуждали в терминах жёсткого силового реализма (разделение ресурсов СССР/Великобритании и т. п.). Спорно, но в их метрике это рациональная теория + процесс.
- Расширение НАТО после Холодной войны - при том что сам Миршаймер критиковал расширение, в книге это - рациональное решение, опирающееся на легитимные либеральные теории (демократический мир, институционализм, интердепенденция).
- и так далее

Также есть примеры действительно нерациональных решений (где связка «теория + процесс» нарушены)
- «Стратегия риска» Германии до Первой мировой - организационные и когнитивные искажения, пробелы/закрытие ключевой информации, не обеспечена качественная проверка теории.
- Вторжение на Кубу ака Залив Свиней, США (1961) - малый «клуб» перехватил процесс, критические сигналы игнорировались → нет нормального обсуждения.
- Ирак, вторжение США (2003) - подавление альтернатив, слабая эмпирическая база теории (WMD/демократизация через силу), искажения в процессе.

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

#Economics #Leadership #Management #Data

[3/3] How States Think: The Rationality of Foreign Policy (Как мыслят государства: рациональность внешней политики) (Рубрика #Politics)

В последней части обзора книги (1 и 2) мы поговорим про применимость подходов авторов на земле, а точнее в работе обычного технического директора

1. Требуйте «достоверную теорию» перед крупным решением. В терминах архитектуры: чёткие допущения, причинно-следственная логика, ссылки на эмпирические данные/историю эксплуатации. Это не «максимизация KPI» по красивой формуле, а валидность модели.
2. Не путайте риск и неопределённость. Если у вас нет качественных базовых частот (например, для редких инцидентов SRE или влияния геополитики на поставки), ожидаемая ценность - ловушка уверенности. Лучше сценарии, стресс‑тесты, pre‑mortem, «что если всё пойдёт по худшему пути».
3. Открытое обсуждение как стандарт. Обязательные дизайн‑ревью, red team, «критик без санкций», протокол, где запрещено скрывать плохие новости. Формально фиксируйте, какая теория «под капотом» у решения.
4. Оценивайте процесс, а не только результат. Провал ≠ глупость, если теория была качественной, а обсуждение - честным. И наоборот: успех ≠ оправдание, если процесс был испорчен.

Если суммировать все, то рациональность государств - это не «всегда выигрывать» и не «всегда считать EV». Это про то, чтобы опираться на валидную модель мира и не ломать процесс обсуждения. В ИТ‑командах это означает: модель‑прежде‑чем‑метрика и ревью‑прежде‑чем‑решение

P.S.
Отдельно надо отметить, что это все про дорогие one-way door decision, когда фарш обратно не провернуть:) А вот two-way door decision хорошо бы научиться принимать без долгих размышлений и эскалаций. По этому поводу можно почитать письмо Джеффа Безоса акционерам, где он еще в 1997 году описывал этот фреймворк для принятия решений.

#Economics #Leadership #Management #Data

Why Growth Playbooks Are Crumbling - and What’s Next (Рубрика #ProductManagement)

С интересом посмотрел выступление с ProductCon SF 2025 от Elena Verna, Head of Growth в Lovable. Ранее Елена руководила/консультировала ростом в SurveyMonkey, Miro, Amplitude, Dropbox. Тезисно она рассказывала о следующих темах
1. Классический рост ломается. SEO, перформанс‑реклама и линейные воронки теряют эффективность. Новая точка входа - answer engines (LLM‑поисковики, ассистенты), где пользователи получают ответ сразу, без клика.
2. AEO вместо только SEO. Нужны стратегии Answer Engine Optimization: как подготовить данные и контент, чтобы ассистенты “знали” о вас и цитировали. Подробнее про это можно посмотреть в серии подкаста Лении "Why ChatGPT will be the next big growth channel" (см. мой разбор)
3. Защита через growth‑петли, а не воронки. Нам надо связать продукт, контент и сигналы пользователей, чтобы запускать самоподдерживающийся рост.
4. Партнёрства с AI‑платформами. Надо работать с провайдерами моделей и экосистемами, чтобы закрепить присутствие бренда/продукта в выдаче ответ‑движков.

Важно, что это не просто про маркетинг, а про инженерную дистрибуцию продукта, которую можно улучшить через следующие шаги
- Структурирование знаний: схемы, разметка, machine‑readable справка/доки, вики/репозитории знаний - чтобы модели могли извлекать и цитировать.
- Интеграции с LLM/поиском: фиды, API, RAG‑коннекторы и разрешения на повторное использование контента.
- Наблюдаемость и метрики AEO: отслеживание доли упоминаний/цитаций в ответах ассистентов, качество извлечения и “замыкание петли” в продукте.
- Эксперименты поверх контента/схем: быстрые итерации как по продукту, так и по документации и семантике.

#AI #Data #Software #Marketing #Economics

Охота на электроовец: большая книга искусственного интеллекта (Рубрика #AI)

За квартал я справился с первым томом этой книги Сергея Маркова, в которой он решил описать откуда взялись нейросети, как они устроены и куда всё идёт:) Отмечу, что многие истории из книги я уже знал, но в более сокращенном варианте (из-за чего часто история воспринималась более плоско и в черно-белом стиле). Интересно, что за время моего чтения по вечерам этой книги ей присудили Беляевскую премию 2025 года в номинации «за лучшую оригинальную научно‑популярную/научно‑художественную книгу на русском языке». Если попробовать фрагментарно описать за что ее стоит прочитать, то за
- За глубокое погружение в анналы истории: от античных механизмов и первых вычислительных устройств до компьютерных шахмат, AlexNet и «революции глубокого обучения».
- За рассказ о людях, что стояли за нейросетями: от Мак‑Каллока и Питтса и перцептрона Розенблатта до бэкпропа, Хинтона и современного DL
- За отличные иллюстрации и дизайн книги - в цветном издании это все смотрится превосходно
- За изложение математических основ понятно и без зубодробительных формул
- За историю «думающих машин», где игры выступали как двигатель ИИ (шахматы/го)

Книга есть в электронном виде бесплатно на сайте автора, а также можно купить бумажное издание от ДМК Пресс.

#PopularScience #AI #DS #Data #Math #History #Economics