MLOps в теории и на практике

Недавно вышел первый эпизод совместного подкаста Тинькофф Образования и Высшей Школы Экономики. Он был посвящен теме MLOps. Сейчас темы AI/ML у всех на слуху: все пытаются использовать LLM для оптимизации существующих процессов, кто-то старается придумать прорывные идеи, а кто-то боится этих изменений. В университетах сейчас есть большое количество курсов по обучению data science и machine learning, но в реальных компаниях зачастую надо не просто создать хорошую модель, но и сделать кучу других приседаний, которые можно назвать MLOps. Если описывать суть, то нужна четкая связь между Data engineering, App engineering и, собственно, ML engineering. Причем выстроенные процессы работы с данными нам нужны как пререквизиты для эффективной работы над ML-моделями, а App engineering нужен, чтобы обученные модели хорошо работали в продакшене и обслуживали запросы.

В обсуждении участвовали
- Дмитрий Ушанов, технический директор ML платформы
- Евгений Соколов — академический руководитель ПМИ ФКН ВШЭ
- и я

Кстати, узнавать про новые выпуски эпизодов этого подкаста и о других образовательных новостях Tinkoff можно в telegram канале "Тинькофф Образование" (@tinkoff_fintech).

P.S.
Я уже разбирал в двух постах в этом канале (1 и 2) тот простенький whitepaper об MLOps от Google, который мы использовали в качестве каркаса обсуждения на подкасте.

#ML #Devops #Data #AI #Software #Architecture #Processes

Sunk cost fallacy (Невозвратные затраты)

Sunk cost fallacy - это интересное явление, при котором человек не хочет отказываться от стратегии или курса действий, потому что он вложил в них значительные средства, даже если очевидно, что отказ будет более выгодным. Забавно, что есть и смежные эффекты вида:
- Эффект Икеи - когнитивное искажение, проявляющееся когда покупатели непропорционально высоко оценивают значимость (ценность) товаров, которые они создают отчасти сами (например, собирают из деталей)
- Синдром NIH (not invented here) - позиция в социальной, корпоративной или организационной культурах, при которой избегается использование или покупка уже существующих разработок, исследований, стандартов или знаний из-за их внешнего происхождения и затрат.

Эти ошибки мышления проникают во многие важные решения, даже если мы знаем про них:) Для того, чтобы с ней бороться, можно задавать себя явные вопросы вида:
- Если бы я не вложил столько сил в проект, то я бы настаивал на его продолжении?
- Если бы уже не было сделано X, то мы бы сделали его заново?
- Какие у нас есть альтеративы ? Причем туда входит как активные опции по изменению текущего состояния, так и сохранение статуса кво.

В общем, полезно знать про собственные предубеждения и пытаться принимать решения, избегая их:) А для того, чтобы знать про них можно посмотреть выступление "Keynote: Debug your thinking - Laila Bougria - NDC London 2024", про которое я писал раньше, а также почитать книги из подборок
1) На тему системного и критического мышления
2) На тему работы мозга

Плюс можно глянуть седьмой выпуск Code of Leadership про работу мозга "Your brain at Work", который был с Эрнесто Инаркиевым, чемпионом Европы по шахматам, гроссмейстером, который входит в ТОП-100 лучших шахматистов мира и в ТОП-30 по быстрым шахматам.

#Thinking #CriticalThinking #Reasoning #SelfDevelopment #Brain #Management #Leadership

How Cognitive Biases Affect our Software Architectures • Birgitta Böckeler • YOW! 2022

Это интересный доклад для архитекторов, в котором рассматривались следующие предубеждения, которые важны нам при проектировании софта:
- Confirmation biases характеризуется тем, что люди подсознательно работают с информацией так, чтобы подтвердить свою точку зрения. Это приводит к тому, что люди с трудом принимают изменения и склонны к повторению своих предыдущих решений и действий. Именно поэтому часто нам так сложно менять устоявшиеся процессы разработки или архитектуру решения - обычно это требует от руководителей мастерского управления изменениями. Я часто сталкивался с этим bias у других, да и ловил его у себя самого.
- Zero risk bias — этот bias влияет на то, как люди управляют рисками. Зачастую есть желание полностью исключить небольшой риск, а не смягчить общий риск даже на большую величину. Это относится к security рискам, избеганию vendor lock in или наличию преждевременных оптимизаций, которые могут защитить нас от рисков масштабирования, но часто не пригождается в итоге, а стоят дорого. Этот bias можно обойти, если иметь фреймворк для работы с рисками и использовать его в своих проектах.
- Availability heuristics - этот bias про принятие быстрых, но иногда не самых правильных решений. И мы строем свои выводы на доступной информации. В разработке софта это например проявляется в том, что часто про техдолг забывают, так как он бывает явно не зафиксирован и его как бы нет:) Поэтому стоит идти от обратного - делать так, чтобы информация о важных вещах была легко доступна. В разработке софта это относительно легко сделать используя логи, метрики, трейсинг как для технических систем, так и для самих процессов разработки.
- Base rate fallacy - этот bias влияет на то, как мы оцениваем вероятность разных сценариев, а дальше как мы распределяем силы своих команд. Часто мы уделяем больше внимания edge cases, про которые мы знаем много, в ущерб каким-то более общим сценариям. Этот bias влияет на приоритизацию усилий, поэтому классно, если у вас есть +/- стандартные метрики для оценки и сравнения важности задач между собой.
- Outcome bias - этот bias про то, что люди оценивают принятые решения на основании результатов. У нас есть поговорка “победителей не судят” и она как раз про это. Но гораздо продуктивнее поменять подход к оценке решения, ориентируясь на ту информацию, которая была доступна в момент принятия решения. В разработке этот подход применяют, когда используют процессы с написанием RFC (request for comments) и ADR (architecture decision records). Это позволяет постфактум оценивать качество решений, а не просто отталкиваться от результатов.
- Self-serving bias - этот bias о том, что люди склонны приписывать успех своим способностям и усилиям, а неудачи - внешним факторам. Это тоже влияет на то, как мы оцениваем свои решения. И этот bias мешает нам расти над собой, потому что мы свои точки роста выводим из своей зоны контроля апеллируя к слепому случая. Гораздо конструктивнее следовать пословице “на ошибках учатся”.

P.S.
Доклад хорошо продолжает вчерашний пост про Sunk cost fallacy (Невозвратные затраты)

#Thinking #CriticalThinking #Reasoning #Philosophy #SelfDevelopment #Brain #Management #Leadership

Искусство системного мышления (The Art of Systems Thinking)

Эта книга Джозефа О'Коннора и Иана Макдермота является одной из самых простых и понятных книг по системному мышлению, что я читал. Вместо заумной теории и сложных объяснений авторы предлагают кучу практических примеров, которые они вплетают в повествование так, что концепции системного мышления вы узнаете в бытовых ситуациях, навроде, ссоры со своей второй половинкой, потребления алкоголя или обучения новому. Книга читается буквально влет, благо она компактная и состоит из следующих частей

Часть 1 - Мышление за пределами очевидного
1. Что такое система? - авторы дают простое определение "Система есть сущность, которая в результате взаимодействия ее частей может поддерживать свое существование и функицонировать как единое целое", а дальше используют его для сравнения систем и просто групп объектов, чтобы показать разницу. Дальше идет речь про системные или эмерджентные свойства, когда целое больше суммы частей. Обсуждаются простые и сложные системы, система как паутина взаимосвей, стабильность и принцип рычага.
2. Контурное мышление - авторы рассказывают про feedback loops, которые позволяют системе обрести интересные свойства, но одновременно усложняющие предсказание происходящего в системе. Эти петли бывают усиливающими (положительная обратная связь) и уравновешивающими (отрицательная обратная связь). Авторы показывают кучу примеров и объясняют почему терминология усиливающие/ослабляющие лучше:) Плюс они показывают какой интересный эффект возникает, когда обратная связь запаздывают и возникают колебания в системе.
Часть 2 - Построение ментальных моделей
3. Ментальные модели - при мышлении мы опираемся на встроенные ментальные модели (идеи, верования и убеждения), которые определяют нашу интерпретацию событий, выбор варианта действия и его реализацию. Нам надо знать про свои ментальные модели, т.к. мы используем их для придания смысла другим системам. В создании и поддержании этих моделей участвуют 4 механизма: вычеркивание, конструирование, искажение и обобщение. Ну и есть другие факторы, что приводят к искаженному восприятию опыта: регрессия, временные рамки, избирательная трактовка опыта
4. Причина и следствие - причинно-следственная связь в системах сложнее линейной - из-за циклов причина может порождать следствие и наоборот. Есть три стандартных заблуждения из линейного мира: разделимость причины и следствия, отсутствие учета времени (следствие сразу идет за причиной), пропорциональность следствия причине. Дальше авторы говорят, что работая со сложными системами, надо определять границы системы, а также искать аттракторы (стабильные состояния, к которым тяготеет система)
5. За пределами логики - формальной логики не достаточно, когда мы имеем дело с системами. Нужен системный подход и метапозиция, что позволяет выйти за пределы стандартной системы отсчета. Для изменения состояния систем часто лучшими точками приложения усилий являются наши ментальные модели
Часть 3 - Мыслить по новому
6. Обучение - рассказ про 2 типа обучения: простое и порождающее. В простом обучении мы используем обратную связь для корректировки своих действий для лучшего достижения нашей цели. В порождающем обучении у нас 2 контура обратной связи и мы не просто корректируем свои действия, но корректируем и свои ментальные модели.
7. Ракурс, перспектива - рассказ про важность точки зрения и расширение наших ментальных моделей. В системном мышлении используется как объективный подход (взгялд на систему снаружи), так и субъективный подход (взгляд на систему изнутри). Причем выбор подхода зависит и от того, а как мы определяем границы системы.
Часть 4 - Рисуем выводы - рассказ как можно визуализировать структуру системы и взаимосвязи, используя контуры обратной связи (куча примеров)
Часть 5 - Замыкаем круг - авторы показывают как использовать весь приведенный до этого инструментарий системного мышления, например, если результаты не соответсвуют усилиям.
Часть 6 - Источники - история того, как системное мышление появилось и развивалось в 20 веке.

#Brain #SelfDevelopment

How We Write Better Software with Low-Code • Michiel Overeem • GOTO 2023

Интересное выступление про low-code платформу от Michiel Overeem, который рассказал как голландская компания AFAS пришла в своем SaaS продукте (смесь ERP, CRM, CMS, и других трехбуквенных слов) к подходу с low-code. По-факту, продукту уже почти 3 десятка лет и за это время он прошел путь от MS DOS программы до того, что разворачивается где-то на серверах и превратился в legacy:) Дальше появилась задача разделить доменную логику и технологическую часть. Знания о бизнесе должны были остаться в моделях, чтобы можно было спокойно развивать технологии. В компании решили это сделать через создание low-code движка, которым будут пользоваться внутренние сотрудники, доменные эксперты, для создания/редактирования бизнес-процессов и пользовательских сценариев работы с системой. Модели из домена по этой логике должны быть свободной от технологий, описывать процессы и роли в реальном мире. В low-code платформу пришлось нехило вложиться и поработать над архитектурой, получился в итоге фреймворк для создания интерфейсов и бекенд фреймворк. 95% функциональности генерируется на основе модели, что создаются citizen developers (это люди, что используют low-code платформу и о самом термине я рассказывал подробнее раньше), а 5% пишутся вручную силами инженеров. Дальше автор выступления рассказывает про преимущества такого подхода:
- Создание модели предметной области позволяет разработчикам писать код, тестировать его и помещать в генератор, что упрощает процесс разработки.
- Модель предметной области позволяет заменять технологии и интерфейсы, сохраняя знания в модели.
- Citizen developers могут вносить изменения в модель без вмешательства инженеров, что повышает продуктивность и позволяет им создавать прототипы и экспериментировать.
- Citizen developers могут создавать программное обеспечение, используя свои знания в области бизнеса, что позволяет им создавать прибыльные подпродукты
Но есть и проблемы
- Citizen developers могут вносить вносят ошибки в модель, что усложняет процесс отладки и требует привлечения программистов для консультации.
- Citizen developers должны понимать как их изменения в модели влияют на runtime свойства софта, что требует дополнительных инструментов и обучения
Ну и дальше идут выводы
- Low-code не является универсальным решением для всех частей приложения
- Стоит использовать low-code только в определенных частях, где можно найти повторяющиеся фрагменты, так как это позволяет работать над этими частями не инженерам, а citizen developers
- Low-code стоит рассматривать как дополнительный инструмент для повышения производительности и создания лучшего программного обеспечения.

В общем, достаточно простой и понятный доклад про то, как компании приходят к low-code решениям как части своего продукта. У нас по такому принципу сделана, например, low-code платформа для маркетинга, в которой сами аналитики могут выстроить процесс маркетинговых коммуникаций с определенными сегментами наших клиентов.

#Software #Engineering #Architecture #PlatformEngineering

Как лгать при помощи статистики (How to Lie with Statistics) - Part I

Этой книге Дарелла Хаффа уже 70 лет, но она до сих пор не потеряла актуальность. Я решил ее прочитать в продолжение книги "Understanding Statistics and Experimental Design. How to Not Lie With Statistics", про которую я рассказывал раньше. И книга не подвела моих ожиданий - она написана простым языком, не содержит воды и рассказывает о различных способах злоупотребления статистикой в целях обмана аудитории и манипулирования ее мнением. Книга состоит из 10 глав:
1. Выборка изначально необъективна - эта манипуляция связана с тем, как мы формируем выборку. Если выборка не соответствует генеральной совокупности (не является репрезентативной), то статистика, которую мы вычислим по этой выборке может показывать те числа, которые мы хотим. Но даже если мы хотим сделать максимально честную выборку, то это достаточно сложно сделать. Например, автор рассказывает про это на примере опросов. А вот пример от меня, whitepaper "DevEx in Action" про developer productivity был описан на основе опросов тех разработчиков, которые работали в компаниях, что пользовались платформой https://getdx.com/ , которая предоставляет инструменты для измерения developer productivity. В итоге, опрос показал, что эти инструменты полезны:)
2. Грамотно выбранное среднее - здесь речь идет про выбор среднего удобного для вашего конкретного случая использования, например, это может быть среднее (mean), медиана (median) и мода. В общем, в зависимости от вида распределения вашей величины эти варианты среднего могут сильно отличаться:)
3. Нюансы, о которых скромно умалчивают - здесь начинается все с размера выборки, который могут не упоминать (а при маленьком размере получить интересные результаты гораздо проще), также про неуспешные результаты экспериментов можно не рассказывать (зачем говорить про неинтересные вещи), плюс можно играть с формулировкой так, чтобы было не ясно как рассчитывается сам показатель:)
4. Много шума практически из ничего - здесь автор рассказывает про статзначимость и доверительные интервалы:) И что при указании конкретных чисел нам сложно сравнить их между собой не зная доверительных интервалов.
5. График - лучше не бывает - тут идет речь про манипуляции с графиками: отсчет не от начальной точки по вертикали, разные масштабы осей, выбор нужного интервала времени для демонстрации графика величины на котрасте между началом и концом интервала
6. Схематичная картинка - здесь автор рассказывает как можно при помощи инфографики обманывать людей. Например, при двухкратном росте денежного показателя показывать в два раза больший мешочек денег - но предметы мы воспринимает как трехмерные и там ощущение от этого приема, что рост был в 8 (2ˆ3) раз
7. Псевдообоснованная цифра - тут автор показывает как взятое из статистики рандомное число можно трактовать по своему усмотрению. Главное сделать отсылку к авторитету и указать откуда взято число, а интерпретацию уже вкрутить свою:) Кстати, это частая манипулятивная техника
8. И снова это "после - значит вследствие" - здесь автор рассказывает, что корреляция совсем не равна причинно-следственной связи. Возможно причина и следствие связаны циклом (как обсуждалось в книге "Искусство системного мышления", про которую я рассказывал раньше) или обе переменных зависят от какой-то другой третьей, а может быть это просто совпадение:)
9. Как производить статикуляции (статистические манипуляции) - тут автор показывает примеры из предыдущих глав и добавляет игры с процентами, повторный учет одних и тех же элементов в расчетах, складывает вместе разные типы объектов и выводит среднее. В общем, поступает очень креативно:)

Продолжение в следующем посте.

#Math #Statistics #PopularScience #Science #Data

ЦЕХ 4 - Урок #6 "Жду музу, а она все не приходит. Эксперт: Лариса Парфентьева"

Продолжая серию постов про свое обучение книгописательству (смотри предыдущие посты: 1, 2, 3, 4 и 5), я расскажу про шестой урок. Он был посвящен поиску вдохновления. Это практическое занятие вела Лариса Парфентьева — автор бестселлеров МИФа с большим количеством регалий.

Занятие было довольно интересным и мне запомнились следующие момены
- Большинство авторов страдают от синжрома самозванца и важно с ним работать
- Сам синдром блокирует нас используя две стратегии: перфекционизм и прокрастинацию
- Насчет перфекционизма важно понимать, что сделать на 100% идеально не получится, поэтому надо быть готовым заделиверить книгу, который ты доволен не на все 100%:)
- А прокрастинацию можно победить используя тайм-менеджмент - надо защищать свое время и пространство, чтобы иметь время сконцентрироваться на творческом процессе и впасть в состояние потока
- Для стимулирования написания свои ощущения можно стимулировать через вкус (пить кофе, есть шоколад и т.д.) во время творческого процесса. Можно ходить на прогулки, чтобы покрутить в голове идеи.
- В общем, надо запланировать время на написание книги и как оно будет распределено в течение дня/недели. Плюс для того, чтобы написать книгу, надо от чего-то отказаться и разгрузить свое расписание:)

#Writing #SelfDevelopment #Management

Успешно ребята съездили в Египет на финал ICPC. Поздравляю победителей и призеров!

Финал ICPC — победа команд ВШЭ и МФТИ

Сотрудники, студенты, преподаватели и стипендиаты Тинькофф в разные годы принимали участие в ICPC. В этом году команды ВШЭ и МФТИ забрали абсолютное чемпионство, золото и серебро, сразу в двух финалах.

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

ВШЭ:
— Александр Бабин, преподаватель Тинькофф Поколения — абсолютный победитель;
— Федор Ромашов, стипендиат Тинькофф — абсолютный победитель;
— Кирилл Кудряшов, стипендиат Тинькофф — абсолютный победитель.

МФТИ:
— Шеховцов Александр, стипендиат Тинькофф — серебро;
— Всеволод Нагибин, стипендиат Тинькофф — золото;
— Тихон Евтеев, стипендиат Тинькофф — золото.

Мы очень болели за ребят и надеемся, что стипендиальная программа помогла ребятам сосредоточиться на подготовке! Отдельно поздравляем тренеров команд: Филиппа Руховича, преподавателя Тинькофф Поколения, Демида Кучеренко, автора курса Тинькофф Образования «Информатика решает», и Михаила Густокашина, члена жюри конкурса для школьных учителей «Вклад в поколение»!