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

Что происходит, когда продукт строится не из метрик, а из идеи. История «Сфер» (Рубрика #ProductManagement)

Этот доклад рассказал мой коллега, Иван Турлаев, который уже больше 8 лет развивает мобильные приложения в Т-Банке. Доклад был посвящен созданию и внедрению новой концепции банковского приложения – «Сферы». Предпосылка проста: современные банковские приложения устроены одинаково. Счета, карты, платежи, кредиты – все разложено по привычным категориям. Банки, ориентируясь на метрики и копируя друг друга, выпускают однотипные решения. Но мы решили взглянуть на приложение не со стороны компании, а со стороны клиента и подумать, а что если сгруппировать сервисы не по банковским продуктам, а по жизненным потребностям человека? Так возникла идея «Сфер». Эта концепция родилась не на основе цифр или бизнес-планов - она появилась из стремления сделать сервис понятным и полезным для человека.

Придумать смелую идею мало, ее нужно реализовать. Разработка «Сфер» потребовала объединить усилия множества разрозненных команд. В T‑Банке разные направления (карты, кредиты, платежи, страховки, путешествия и др.) имели свои цели и метрики. Объединить их вокруг новой концепции оказалось непросто. Нужно было убедить менеджеров и разработчиков принять общую идею и найти с ними общий язык. При этом бросить текущие проекты было нельзя.

Проекту помог единый vision, который был подготовлен командой в качестве наглядного концепта нового интерфейса. Увидев цельный образ будущего продукта, разработчики и менеджеры смогли эффективнее взаимодействовать. Обсуждения сместились с узких показателей на пользовательский опыт: фокус на том, как сделать удобнее человеку. Единый дизайн-концепт выступил «клеем», объединяющим команды. Важно было регулярно сверяться с изначальным замыслом и быть настойчивым.

Основой был дизайн-концепт. Команда сознательно отошла от банковских шаблонов интерфейса. Цель - сделать так, чтобы интерфейс говорил на языке жизненных ситуаций, а не банковских продуктов. Дизайнеры экспериментировали с навигацией и визуальным стилем, уходя от перегруженных списков и меню. На главном экране пользователь сразу видит ключевые сферы своей жизни вместо длинного перечня услуг. В итоге, на первом этапе в приложении T‑Банка появились четыре первые «Сферы»: «Шопинг», «Дом», «Авто» и «Путешествия». Каждая стала единым центром для своей темы, объединяя все связанные сервисы банка и партнеров. Например, «Дом» собрал в одном месте оплату коммунальных услуг, страховку жилья и покупки для дома. А «Авто» объединил все для автовладельцев: от штрафов и заправки до страховок и ТО. Такой подход резко отличался от традиционного: прежде эти операции были разбросаны по разным разделам, а теперь клиент решает задачу целиком, не переключаясь между вкладками.

Для инженеров проект «Сферы» тоже стал испытанием. Нужно было интегрировать множество разных систем – внутренних и внешних – в единое целое. Фактически команда создала платформу по принципу супераппа, где разнородные модули работают согласованно ради общего сценария. Архитектуре потребовалась гибкость: унифицированные API, общая навигация, единая система уведомлений - всё для цельного UX. Решения по backend и frontend принимались с оглядкой на задуманный пользовательский опыт, чтобы техническая реализация не испортила UX.

Если говорить про извлеченные уроки, то я бы отметил для себя следующие
- Большие изменения рождаются из смелых гипотез и тут не всегда решают метрики, а вот дальше оптимизировать идею без них не получится
- Сценарии работы пользователей важнее структуры компании. Приложения части компаний отражают их внутреннюю структуру (у каждого отдела свой раздел). В сферах мы пошли от сценариев пользователя, а потом уже пришли и к реорганизации структуры подразделений внутри компании (я про это уже как-то писал)
- Для больших изменений важен единый vision и коммуникации вокруг него. Без единой цели не получится объединить работу многих команд

#Management #Design #Engineering #Leadership #Project #Metrics #Philosophy

Программирование смыслов (Рубрика #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

Вот пример того, как роботы помогают в quality assurance. Пока я рассказывал про генерацию тест-кейсов агентами, повышение test coverage через генерацию юнит тестов, коллеги рассказали про настоящую робо-руку, что занимается настоящим ручным тестированием банкоматов:)

[1/2] The 7 Most Powerful Moats For AI Startups (Рубрика #Startup)

Интересный выпуск ребят из Y Combinator, в котором они разбирают книгу «Seven Powers: The Foundations of Business Strategy» (2016) авторства экономиста Хамильтона Хелмера. В этой книге описана концепция «moat» (конкурентного «рва») – устойчивого преимущества, защищающего бизнес от конкурентов, по аналогии с рвом вокруг замка. Несмотря на то, что книга вышла в 2016 году на примерах компаний вроде Oracle, Facebook и Netflix, ее идеи о типах moat остаются актуальными и для современных стартапов (в частности, AI-стартапов).

Хелмер выделяет семь видов устойчивых источников преимущества, которые позволяют компаниям долго удерживать высокую эффективность и защищаться от конкуренции
1. Scale Economies (эффект масштаба) – снижение издержек на единицу продукции по мере роста объёмов. Пример: компания с огромной инфраструктурой, как Amazon или UPS, может доставлять товары дешевле за счет массовости операций
2.Network Effects (сетевые эффекты) – ценность продукта растёт с увеличением числа пользователей. Классический пример – соцсети: они становятся ценнее, когда в них больше друзей. Аналогично платёжные системы (например, Visa) выигрывают, если их принимают больше магазинов
3. Counter-Positioning (контр-позиционирование) – стратегия, при которой новая компания предлагает такую модель или продукт, что лидеру рынка трудно скопировать из-за конфликта с его текущим бизнесом. Например, AI-стартапы могут брать плату за выполненную работу вместо лицензий на пользователя, подрывая модель SaaS-компаний
4. Switching Costs (издержки переключения) – пользователю дорого или сложно перейти к конкуренту, что удерживает его. Например, когда все данные и логика компании завязаны на Oracle, то миграция на другую СУБД крайне сложна и затратна. В эпоху SaaS таким же «липким» оказался, например, корпоративный CRM Salesforce
5. Branding (сила бренда) – клиенты выбирают продукт благодаря бренду, даже если есть аналог. Бренд формирует доверие и узнаваемость, что конкуренты не могут быстро воспроизвести. Интересно, что OpenAI показал Google силу бренда: у Google огромная аудитория и технологии (модели Gemini), но OpenAI с нуля сумела построить доминирующий бренд в AI благодаря ChatGPT, обогнав по популярности продукты Google.
6. Cornered Resource (эксклюзивный ресурс) – компания получает эксклюзивный доступ к ценному ресурсу, который трудно или невозможно заполучить другим. Примеры: патенты, уникальные алгоритмы, договоры. Например, Nintendo защищается эксклюзивными персонажами/играми, а в современном AI-пространстве примером служат компании с доступом к уникальным данным или контрактам: Palantir за годы работы получила особые контракты с правительством и доступ к секретным данным – такой ресурс недоступен новичкам (кстати, я уже рассказывал про книгу CEO Palantir).
7. Process Power (процессное преимущество) – долгосрочное преимущество от уникального бизнес-процесса или организационной практики, крайне сложно копируемой. Обычно формируется со временем и редко встречается.. Классический пример – Toyota со своей системой бережливого производства: ее производственные процессы десятилетиями давали фору конкурентам.

Отдельно ребята из Y Combinator добавляют еще speed (скорость). Они считают, что для стартапа на ранней стадии важнейшим «moat» является скорость исполнения. Этого фактора нет в списке Хелмера, но он «должен был бы там быть». В начале пути скорость разработки и доставки продукта – фактически единственное защитное преимущество стартапа. Пока большая компания раскачивается, стартап, работая в авральном темпе, успевает завоевать рынок.В крупной корпорации множество согласований, уровней менеджмента и бюрократии, из-за чего выпуск новой фичи занимает месяцы. Стартап же способен релизить улучшения за дни или часы. Пример – AI-стартап Cursor (интеллектуальный редактор кода): его команда практиковала «one-day sprints» – полный цикл разработки за один день!

Практические выводы из подкаста в продолжении.

#AI #Engineering #Software #Management #Leadership

[2/2] The 7 Most Powerful Moats For AI Startups (Рубрика #Startup)

Продолжая рассказ про этот подкаст поделюсь ключевыми идеями, что можно вытянуть из обзора книги, которую обсуждали подкастеры из Y Combinator

1. Не начинать со «рва», начните с продукта. Сначала решите реальную проблему клиента и найдите product-market fit (соответствие продукта рынку). Не стоит отбрасывать идею стартапа только потому, что вы не видите сразу долгосрочного конкурентного преимущества - оно может сформироваться по мере роста через технологии, данные, бренд и т.д. Иначе говоря, «moat» – вещь защитная, сперва нужно что защищать. Эту мысль подчеркивают и цитатой Питера Тиля:
Competition is for loser
в смысле, надо стремиться найти уникальность, но не парализоваться страхом конкуренции на старте

2. Скорость и фокус – оружие стартапа. Главный козырь малой команды – быстрота решений и отсутствие бюрократии. Делайте упор на скорость разработки, частые итерации, тесную связь с пользователями. Это язык, понятный каждому инженеру: меньше совещаний – больше кода в продакшн. Применяя agile в экстремум (ежедневные релизы, как у Cursor), стартап может наработать большое отрывное преимущество, пока гиганты раскачиваются. Идея «Speed as a Moat» особенно резонирует для технических команд, где культура быстрых экспериментов и деплоя может решить судьбу продукта.

3. Классические “силы” никуда не делись – учитесь их распознавать. Инженерам и менеджерам важно понимать, какое преимущество формируется у их продукта: сеть, масштаб, lock-in, бренд или др. Например, создавая API или платформу, вы можете строить network effect – с каждым новым интегрированным клиентом ценность вашей платформы для всех растет. Разрабатывая сложную инфраструктуру, можно заложить process power, как это сделал Plaid или Palantir, где ценность в отлаженном процессе интеграции данных. Добавляя функционал, повышающий издержки переключения, вы удержите клиентов (пример – персонализация и память в AI-сервисах создают привязку пользователей). Руководителям продуктов стоит мыслить в этих категориях при развитии стратегии.

4. Новые времена – новые проявления moat. Менеджерам полезно осознать, что с появлением ИИ появились и новые источники данных и эффектов, усиливающих классические moats. Например, данные пользователей стали топливом для алгоритмов, и те компании, кто собирает больше данных (не жертвуя качеством), получают экспоненциальный рост преимущества (их модели умнеют быстрее). Это своего рода data network effect. Также, AI позволяет стартапам сразу выходить на глобальный рынок (меньше барьеров локализации), что ускоряет брендовый эффект – вспомним взрывную известность ChatGPT. Таким образом, техдиректорам и CTO стоит держать руку на пульсе этих трендов, чтобы понимать, куда вкладываться: в сбор данных, в улучшение алгоритмов, в создание экосистемы вокруг продукта и т.п.

В итоге, знание этих терминов про конкурентные преимущества дает общий язык инженерам и бизнесу. Термины вроде network effect, switching cost, moat перестают быть непонятными абстракциями. Для инженерных команд это шанс лучше понять стратегию компании, а для руководителей – донести её «на языке шаблонов». Такой взаимопонимание повышает шансы, что стартап не только быстро выстрелит, но и сумеет закрепиться, выстроив надежный ров вокруг своего «замка»

#AI #Engineering #Software #Management #Leadership

Meet For Charity & Нить Добра (Рубрика #Charity)

Уже традиционно я решли поучаствовать в аукционе Meet For Charity, где предметом аукциона является встреча со мной. За обедом/ужином я готов буду поговорить на разные темы, включая +/- любые из тех, что я поднимаю в этом канале. Сама встреча будет в Москве и я постарюсь, чтобы это было в первую рабочую неделю ноября:) Собранные по итогам аукциона средства будут направлены в фонд "Нить добра".

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

#Charity