Техкомьюнити №1: выпуск про космос (#Engineering)
Посмотрел пилот нового подкаста Сбера «Техкомьюнити №1» - его делают инженеры для инженеров. Ведёт Кирилл Меньшов (SVP Сбера, блок «Технологии»), а в гостях - Алексей Шелобков, CEO «ИКС Холдинг» (там «Ядро» - российское ИКТ/железо, и «Бюро 1440» - частная космическая история). В первом выпуске разговор шел про "новый космос", что больше похож на IT: ребята обсуждали: distributed systems, связь, надёжность, апгрейды. Ниже ключевые тезисы
1️⃣ Почему «Бюро 1440» и откуда коммерческий «бум»
1440 - символическое число: столько оборотов вокруг Земли сделал первый спутник Королёва (запуск 4 октября 1957).
Сейчас космос уходит от чисто гос/научных программ к коммерческому low‑orbit. Драйверы понятные:
- AI и вечный голод по данным
- "Always online" для людей и бизнеса
- Цифровые гос/банк/логистика, которым нужен интернет «везде»
- Автономный транспорт/логистика, где связь вне городов - не “nice to have”, а must.
2️⃣ «Старый» vs «новый» космос - как мэйнфрейм vs облачный дата-центр
Старый подход (геостационар):
- Один супернадёжный аппарат на 10–15 лет;
- Спец. радиационно-стойкая схемотехника;
- Долгие циклы и цена уровня «мэйнфрейма».
Новый подход (низкие орбиты):
- Спутник = нода в кластере (умер - неприятно, но не конец света);
- Надёжность даёт избыточность группировки + быстрые замены;
- Серийное производство и регулярные обновления (почти rolling upgrade).
3️⃣ Спутник сегодня - это базовая станция + роутер + автономный робот
Низкоорбитальный аппарат - "летающая базовая станция" и умный коммутатор одновременно:
- Uplink/downlink к абоненту + межспутниковые каналы (лазеры);
- На борту непрерывно считаются положение/ориентация (звёздные датчики + данные с Земли), крутятся контуры управления, коррекция орбиты, наведение лазерных линий
- Тестовые запуски 2023–2024 - чтобы вживую проверить модели и стандарты связи, в т.ч. 5G‑NTN.
4️⃣ Боли: энергия/тепло, latency, безопасность
- Edge computing “прямо на спутнике” пока сомнительно: мощность дорогая, а тепло в вакууме отводить - отдельный вид спорта.
- "Орбитальные дата-центры" звучат красиво, но упираются в КПД солнечных панелей и деградацию аккумуляторов.
- Latency: LEO даёт десятки миллисекунд - уже ок для realtime. А вот >300 мс - и живое общение становится мучением.
- Кибербезопасность: 100% защиты не бывает, поэтому важнее архитектура под резервирование и быстрое восстановление после сбоев/атак (resilience > "неуязвимость").
5️⃣ Практика и планы
Про РФ: чтобы покрыть страну, звучала оценка ~250 аппаратов, целевой горизонт - 2027. Идея - закрыть «белые пятна» даже в освоенных регионах и на длинных магистралях
Про глобальный рынок к 2029:
- «Околоземная экономика» может вырасти примерно с ~$600B до $1.8T за 7–8 лет;
- Сети будут срастаться: 5G‑NTN → 6G‑NTN, где связь станет реально «бесшовной»;
- Терминалы станут меньше, и в устройствах будет больше интеграции: связь + точное позиционирование.
6️⃣ Про инженеров: без гибрида "классика + IT" не поедет
Нужен микс: фундаментальная инженерия (системность, высокая цена ошибки) + IT‑культура (скорость, итерации, нормальное отношение к ошибкам).
Из цифр: у ИКС/«Ядра» - ~25 магистерских программ с вузами
Советы молодым инженерам:
- Найти трек, который реально драйвит
- Пробовать разные области и собирать T-Shape
- Качать soft skills наравне с hard
- Метанавык №1 - быстро учиться и адаптироваться
«Тёмная лошадка» по технике - гибридные штуки вроде нейроинтерфейсов + (возможно) новые открытия в физике, которые потом внезапно сделают “sci‑fi” рабочей реальностью.
7️⃣ Партнёрства
В конце обсудили, что стратегическим партнёрам пора уходить от модели «заказчик‑поставщик» к совместному R&D: общие команды, гипотезы, эксперименты и «мечты о будущем», где каждая сторона приносит свои суперсилы.
Если вы любите распределённые системы, связь и железо, которое реально летает, то рекомендую посмотреть выпуск - он реально стоит часа просмотра.
#Engineering #Leadership #AI #Space #Software #RnD
Посмотрел пилот нового подкаста Сбера «Техкомьюнити №1» - его делают инженеры для инженеров. Ведёт Кирилл Меньшов (SVP Сбера, блок «Технологии»), а в гостях - Алексей Шелобков, CEO «ИКС Холдинг» (там «Ядро» - российское ИКТ/железо, и «Бюро 1440» - частная космическая история). В первом выпуске разговор шел про "новый космос", что больше похож на IT: ребята обсуждали: distributed systems, связь, надёжность, апгрейды. Ниже ключевые тезисы
1️⃣ Почему «Бюро 1440» и откуда коммерческий «бум»
1440 - символическое число: столько оборотов вокруг Земли сделал первый спутник Королёва (запуск 4 октября 1957).
Сейчас космос уходит от чисто гос/научных программ к коммерческому low‑orbit. Драйверы понятные:
- AI и вечный голод по данным
- "Always online" для людей и бизнеса
- Цифровые гос/банк/логистика, которым нужен интернет «везде»
- Автономный транспорт/логистика, где связь вне городов - не “nice to have”, а must.
2️⃣ «Старый» vs «новый» космос - как мэйнфрейм vs облачный дата-центр
Старый подход (геостационар):
- Один супернадёжный аппарат на 10–15 лет;
- Спец. радиационно-стойкая схемотехника;
- Долгие циклы и цена уровня «мэйнфрейма».
Новый подход (низкие орбиты):
- Спутник = нода в кластере (умер - неприятно, но не конец света);
- Надёжность даёт избыточность группировки + быстрые замены;
- Серийное производство и регулярные обновления (почти rolling upgrade).
3️⃣ Спутник сегодня - это базовая станция + роутер + автономный робот
Низкоорбитальный аппарат - "летающая базовая станция" и умный коммутатор одновременно:
- Uplink/downlink к абоненту + межспутниковые каналы (лазеры);
- На борту непрерывно считаются положение/ориентация (звёздные датчики + данные с Земли), крутятся контуры управления, коррекция орбиты, наведение лазерных линий
- Тестовые запуски 2023–2024 - чтобы вживую проверить модели и стандарты связи, в т.ч. 5G‑NTN.
4️⃣ Боли: энергия/тепло, latency, безопасность
- Edge computing “прямо на спутнике” пока сомнительно: мощность дорогая, а тепло в вакууме отводить - отдельный вид спорта.
- "Орбитальные дата-центры" звучат красиво, но упираются в КПД солнечных панелей и деградацию аккумуляторов.
- Latency: LEO даёт десятки миллисекунд - уже ок для realtime. А вот >300 мс - и живое общение становится мучением.
- Кибербезопасность: 100% защиты не бывает, поэтому важнее архитектура под резервирование и быстрое восстановление после сбоев/атак (resilience > "неуязвимость").
5️⃣ Практика и планы
Про РФ: чтобы покрыть страну, звучала оценка ~250 аппаратов, целевой горизонт - 2027. Идея - закрыть «белые пятна» даже в освоенных регионах и на длинных магистралях
Про глобальный рынок к 2029:
- «Околоземная экономика» может вырасти примерно с ~$600B до $1.8T за 7–8 лет;
- Сети будут срастаться: 5G‑NTN → 6G‑NTN, где связь станет реально «бесшовной»;
- Терминалы станут меньше, и в устройствах будет больше интеграции: связь + точное позиционирование.
6️⃣ Про инженеров: без гибрида "классика + IT" не поедет
Нужен микс: фундаментальная инженерия (системность, высокая цена ошибки) + IT‑культура (скорость, итерации, нормальное отношение к ошибкам).
Из цифр: у ИКС/«Ядра» - ~25 магистерских программ с вузами
Советы молодым инженерам:
- Найти трек, который реально драйвит
- Пробовать разные области и собирать T-Shape
- Качать soft skills наравне с hard
- Метанавык №1 - быстро учиться и адаптироваться
«Тёмная лошадка» по технике - гибридные штуки вроде нейроинтерфейсов + (возможно) новые открытия в физике, которые потом внезапно сделают “sci‑fi” рабочей реальностью.
7️⃣ Партнёрства
В конце обсудили, что стратегическим партнёрам пора уходить от модели «заказчик‑поставщик» к совместному R&D: общие команды, гипотезы, эксперименты и «мечты о будущем», где каждая сторона приносит свои суперсилы.
Если вы любите распределённые системы, связь и железо, которое реально летает, то рекомендую посмотреть выпуск - он реально стоит часа просмотра.
#Engineering #Leadership #AI #Space #Software #RnD
VK Видео
Техкомьюнити: как работает ИТ в космосе? Пилотный выпуск с Кириллом Меньшовым и Алексеем Шелобковым
Запускаем новый подкаст «Техкомьюнити». Это пространство для честного разговора с лидерами технологической индустрии. Обсуждаем решения, которые уже сегодня трансформируют нашу жизнь. Смотрите первый выпуск! Вы узнаете, как работает частный космос в России…
❤6👍4🔥3
Сайт по system design (Рубрика #Architecture)
Многие мои подписчики знают, что я планировал написать книгу ... но я не уточнял какую. Суть была в том, что я параллельно занимался работой над несколькими книгами. Ближе всего к готовности была книга по System Design (с фокусом на подготовке к интервью) - мне просто было проще всего ее собрать из своих материалов. Я работал по стартинке - сделал желаемое оглавление, собрал часть глав из своих материалов и получил большой Google Doc. Но на каникулах меня осенило, что цель-то не в книге, а в удобной компиляции моих мыслей. Поэтому я поменял подход - скормил google doc сервису Lovable для создания интерактивного сайта, а дальше инкрементально начал его дорабатывать. Я этим занимался больше месяца и получился такой вот сайт system-design.space. Конечно, нет предела совершенству и я собираюсь продолжить его наполнение, но думаю, что он уже может принести пользу тем, кто хочет прокачаться в проектировании.
Если найдете какие-то ошибки или опечатки, то пишите - я буду править их по мере своих сил. В ближайшие месяцы я планирую добавить еще рекомендованных книг, поработать над пулом задачек, чтобы тут были не только классические из других книг + сделаю побольше красивых визуализаций. На более далеком горизонте я планирую пойти в стороне не только классическо system design, но и других типов, что описаны в главе про специфику интервью.
#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software
Многие мои подписчики знают, что я планировал написать книгу ... но я не уточнял какую. Суть была в том, что я параллельно занимался работой над несколькими книгами. Ближе всего к готовности была книга по System Design (с фокусом на подготовке к интервью) - мне просто было проще всего ее собрать из своих материалов. Я работал по стартинке - сделал желаемое оглавление, собрал часть глав из своих материалов и получил большой Google Doc. Но на каникулах меня осенило, что цель-то не в книге, а в удобной компиляции моих мыслей. Поэтому я поменял подход - скормил google doc сервису Lovable для создания интерактивного сайта, а дальше инкрементально начал его дорабатывать. Я этим занимался больше месяца и получился такой вот сайт system-design.space. Конечно, нет предела совершенству и я собираюсь продолжить его наполнение, но думаю, что он уже может принести пользу тем, кто хочет прокачаться в проектировании.
Если найдете какие-то ошибки или опечатки, то пишите - я буду править их по мере своих сил. В ближайшие месяцы я планирую добавить еще рекомендованных книг, поработать над пулом задачек, чтобы тут были не только классические из других книг + сделаю побольше красивых визуализаций. На более далеком горизонте я планирую пойти в стороне не только классическо system design, но и других типов, что описаны в главе про специфику интервью.
#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software
system-design.space
System Design Space — Проектируй лучшие системы
Изучай System Design для создания надёжных масштабируемых систем и успешного прохождения интервью.
2🔥154👍33❤26🏆1
Оливер Хьюз - про уход из Tinkoff Bank, Узбекистан и бизнес (Рубрика #Management)
Интересно было посмотреть интервью Оливера Хьза в подкасте Alter Ego, что вышел 14 января 2026. Оливер долго работал в Т, а потом ушел в TBC отвечать за рост и международный бизнес, включая тот, что в Узбекистане (собственно, подкаст Alter Ego как раз отсюда). Оливера всегда интересно слушать, но в этот раз интересно было интересно послушать рефлексию про его опыт, отъезд из России и новые вызовы в Узбекистане. Тезисно можно забрать из этого рассказа следующее
1️⃣ Лидерство = дисциплина + открытость
Лидер обязан держать темп и форму - не ради статуса, а чтобы команда видела: “мы в одном окопе”. И второе - реально слушать идеи снизу. Не «я самый умный», а «давайте найдём лучший ход».
2️⃣ Любовь важнее уважения
Провокационно, но точно: уважение легко превращается в дистанцию, а “любовь” - это когда люди с тобой, потому что “мы вместе в этом”. Его стиль - маленькая “d”-демократия: минимум рангов, максимум совместной ответственности.
3️⃣ Культура важнее стратегии
Стратегия - это roadmap, который устаревает быстрее, чем вы закрываете Q1. Культура - ваш runtime: как вы принимаете решения, спорите, меряете, учитесь и адаптируетесь. Фаундеры задают стартовую конфигурацию, дальше появляются подкультуры - и культурой нужно управлять осознанно, как системой.
4️⃣ Люди vs система - ложная дихотомия
Сильные люди без процессов не вывозят масштаб. Процессы без сильных людей не едут вообще. Модель TBC у него звучит просто: «сильные люди внутри понятной системы» (данные, процессы, IT-фундамент). Самое честное: собрать консистентную систему на масштабе адски сложно - всегда будут разрывы, где одна часть бизнеса убежала, а другая догоняет.
5️⃣ Скорость важна, но выигрывает качество
Оливер выбирает “быть лучшим”, а не “быть первым”. Early adopters (5–10%) дадут шум и фидбек, но бизнес - это следующие ~70%, которые покупают стабильность и качество. И да, он сам “поздний адоптер” - успех не требует быть техно-евангелистом первой волны.
6️⃣ Скепсис к MVP (особенно в финсфере
MVP показывает только, что идея “не мертвая”. Реальное понимание приходит по когортам и часто через 12–18 месяцев. Месседж: не паниковать от первых метрик, а “допушивать и дотягивать” продукт.
7️⃣ Скейлинг - «ад каждый день» + две смертельные ошибки
Ошибки такие
- Растянуться быстрее возможностей (часто через долг)
- “Порваться изнутри”, когда компания расплывается и метрики поплыли, а вы поздно заметили.
Слишком быстрый рост, по его мнению, опаснее стагнации.
Отдельно были интересные факты про Узбекистан/TBC:21 млн уникальных пользователей и 5,7 млн MAU; кредитный портфель порядка $905 млн. И сильный AI-фокус: узбекоязычные LLM, on‑prem развёртывание, voice agents закрывают >40% ранней просрочки.
Если попробовать сократить тезисы до чеклиста самопроверки, то получим примерно следующее
- Опишите “runtime” команды: какие решения принимаем только через данные, какие через принципы.
- Проверьте, не держится ли скорость на героизме. Если да - вам нужна система.
- Меряйте продукт когортами, а не эмоциями первой недели релиза.
- Инвестируйте в качество как в долгосрочный moat.
#Leadership #Management #Economics
Интересно было посмотреть интервью Оливера Хьза в подкасте Alter Ego, что вышел 14 января 2026. Оливер долго работал в Т, а потом ушел в TBC отвечать за рост и международный бизнес, включая тот, что в Узбекистане (собственно, подкаст Alter Ego как раз отсюда). Оливера всегда интересно слушать, но в этот раз интересно было интересно послушать рефлексию про его опыт, отъезд из России и новые вызовы в Узбекистане. Тезисно можно забрать из этого рассказа следующее
1️⃣ Лидерство = дисциплина + открытость
Лидер обязан держать темп и форму - не ради статуса, а чтобы команда видела: “мы в одном окопе”. И второе - реально слушать идеи снизу. Не «я самый умный», а «давайте найдём лучший ход».
2️⃣ Любовь важнее уважения
Провокационно, но точно: уважение легко превращается в дистанцию, а “любовь” - это когда люди с тобой, потому что “мы вместе в этом”. Его стиль - маленькая “d”-демократия: минимум рангов, максимум совместной ответственности.
3️⃣ Культура важнее стратегии
Стратегия - это roadmap, который устаревает быстрее, чем вы закрываете Q1. Культура - ваш runtime: как вы принимаете решения, спорите, меряете, учитесь и адаптируетесь. Фаундеры задают стартовую конфигурацию, дальше появляются подкультуры - и культурой нужно управлять осознанно, как системой.
4️⃣ Люди vs система - ложная дихотомия
Сильные люди без процессов не вывозят масштаб. Процессы без сильных людей не едут вообще. Модель TBC у него звучит просто: «сильные люди внутри понятной системы» (данные, процессы, IT-фундамент). Самое честное: собрать консистентную систему на масштабе адски сложно - всегда будут разрывы, где одна часть бизнеса убежала, а другая догоняет.
5️⃣ Скорость важна, но выигрывает качество
Оливер выбирает “быть лучшим”, а не “быть первым”. Early adopters (5–10%) дадут шум и фидбек, но бизнес - это следующие ~70%, которые покупают стабильность и качество. И да, он сам “поздний адоптер” - успех не требует быть техно-евангелистом первой волны.
6️⃣ Скепсис к MVP (особенно в финсфере
MVP показывает только, что идея “не мертвая”. Реальное понимание приходит по когортам и часто через 12–18 месяцев. Месседж: не паниковать от первых метрик, а “допушивать и дотягивать” продукт.
7️⃣ Скейлинг - «ад каждый день» + две смертельные ошибки
Ошибки такие
- Растянуться быстрее возможностей (часто через долг)
- “Порваться изнутри”, когда компания расплывается и метрики поплыли, а вы поздно заметили.
Слишком быстрый рост, по его мнению, опаснее стагнации.
Отдельно были интересные факты про Узбекистан/TBC:21 млн уникальных пользователей и 5,7 млн MAU; кредитный портфель порядка $905 млн. И сильный AI-фокус: узбекоязычные LLM, on‑prem развёртывание, voice agents закрывают >40% ранней просрочки.
Если попробовать сократить тезисы до чеклиста самопроверки, то получим примерно следующее
- Опишите “runtime” команды: какие решения принимаем только через данные, какие через принципы.
- Проверьте, не держится ли скорость на героизме. Если да - вам нужна система.
- Меряйте продукт когортами, а не эмоциями первой недели релиза.
- Инвестируйте в качество как в долгосрочный moat.
#Leadership #Management #Economics
YouTube
Оливер Хьюз - про уход из Tinkoff Bank, Узбекистан и бизнес
В этом выпуске — Оливер Хьюз, один из самых опытных и известных топ-менеджеров региона. Гуманитарий, который пришёл в банковский бизнес в общем-то случайно, но сделал потрясающую карьеру. Работа в России, запуск цифрового банка, опыт работы внутри систем…
👍37❤16🔥12💘3
🇨🇳 Китай строит «ИИ‑вертикаль» в образовании: от детсада до университета (Рубрика #AI)
В Forbes (12.01.2026) сделали разбор, как КНР делает ИИ массовым образовательным инструментом. По ощущениям инженера/CTO: это программа уровня платформы с регуляторикой и KPI. Собственно тезисы статьи примерно такие
🧭 Какие меры принимаются
1. Стратегия и дорожная карта
- «План развития ИИ нового поколения» (2017) с вехами 2020 → 2025 → 2030.
- Образование - ключевой полигон: после «Education Informatization 2.0» (2019) - десятки документов по AI‑in‑education; цель - к 2030 ИИ как повседневный инструмент во всех школах.
2. Масштабирование через пилоты
- В феврале 2024 Минобр КНР выбрал 184 пилотные школы/площадки для ИИ‑образования (эталонные практики для тиражирования).
3. «ИИ с пелёнок»: контент + инструменты
- Детсад: разовые занятия/игры с роботами‑ассистентами учителя.
- Начальная школа: учебники, где ИИ - «чудесный друг», далее - простые эксперименты/кейсы + этика.
- Средняя/старшая: виртуальные собеседники (пример - «Анна» для английского), персонализированное ДЗ, автопроверка части работ.
- Отдельно: ИИ‑поддержка обучения детей с РАС (адаптация темпа по эмоциям/состоянию).
4. Высшая школа: расширение кадров + участие BigTech
- В списке бакалаврских направлений (04.2025) - 845 AI‑связанных треков (29 новых); около 620 вузов предлагают бакалавриат «Искусственный интеллект».
- BigTech открывают лаборатории/институты и свои академии (Alibaba, ByteDance, Tencent, Huawei и др.).
5. Регулирование и академическая честность
- Китайская академия наук (09.2024): где ИИ допустим (поиск/структурирование, правка, перевод, графики) - и что запрещено; нужна маркировка/декларация и выбор «зарегистрированных» сервисов.
- Вузы вводят локальные правила (пример: Фудань - только «некреативные» задачи, с согласованием у научрука).
📈 Что видно по результатам (цифры из статьи)
- 1‑я половина 2025: 515 млн пользователей ген‑ИИ (36,5% населения).
- 83% в Китае считают, что у AI‑продуктов/сервисов больше плюсов, чем минусов.
- Зарегистрированные ИИ‑разработки: 117 (04.2024) → 801 (08.2025), +585%.
- Внедрение по регионам неравномерно: местами остаётся «просто цифровизация».
- Автопроверка не идеальна: в 2024 Zuoyebang на задачах уровня гаокао набирала <4/5.
⚠️ Обратная сторона
- AI‑плагиат и разрыв «домашки vs знания» (высокие баллы за письменное, слабое устное).
- Риск непроверенной/сгенерированной информации в науке и падение критического мышления - отсюда рост правил и контроля.
🧩 Насколько реально повторить вне Китая
Повторяемо
- Пилоты + измеримые метрики эффекта (успеваемость, нагрузка учителя, вовлечённость).
- Возрастной AI‑curriculum + этика/верификация.
- ИИ в рутину, но human‑in‑the‑loop на критичных точках.
- Политики «что можно/нельзя» + изменение формата оценивания (устное/практика/проекты).
Труднее
- Супер‑масштаб и скорость централизованной модели + единая инфраструктура/регуляторика.
- «Навязывание стандарта» (например, обязательность локальных/зарегистрированных сервисов).
#AI #ML #Education #Kids #Software #ML #Economics
В Forbes (12.01.2026) сделали разбор, как КНР делает ИИ массовым образовательным инструментом. По ощущениям инженера/CTO: это программа уровня платформы с регуляторикой и KPI. Собственно тезисы статьи примерно такие
🧭 Какие меры принимаются
1. Стратегия и дорожная карта
- «План развития ИИ нового поколения» (2017) с вехами 2020 → 2025 → 2030.
- Образование - ключевой полигон: после «Education Informatization 2.0» (2019) - десятки документов по AI‑in‑education; цель - к 2030 ИИ как повседневный инструмент во всех школах.
2. Масштабирование через пилоты
- В феврале 2024 Минобр КНР выбрал 184 пилотные школы/площадки для ИИ‑образования (эталонные практики для тиражирования).
3. «ИИ с пелёнок»: контент + инструменты
- Детсад: разовые занятия/игры с роботами‑ассистентами учителя.
- Начальная школа: учебники, где ИИ - «чудесный друг», далее - простые эксперименты/кейсы + этика.
- Средняя/старшая: виртуальные собеседники (пример - «Анна» для английского), персонализированное ДЗ, автопроверка части работ.
- Отдельно: ИИ‑поддержка обучения детей с РАС (адаптация темпа по эмоциям/состоянию).
4. Высшая школа: расширение кадров + участие BigTech
- В списке бакалаврских направлений (04.2025) - 845 AI‑связанных треков (29 новых); около 620 вузов предлагают бакалавриат «Искусственный интеллект».
- BigTech открывают лаборатории/институты и свои академии (Alibaba, ByteDance, Tencent, Huawei и др.).
5. Регулирование и академическая честность
- Китайская академия наук (09.2024): где ИИ допустим (поиск/структурирование, правка, перевод, графики) - и что запрещено; нужна маркировка/декларация и выбор «зарегистрированных» сервисов.
- Вузы вводят локальные правила (пример: Фудань - только «некреативные» задачи, с согласованием у научрука).
📈 Что видно по результатам (цифры из статьи)
- 1‑я половина 2025: 515 млн пользователей ген‑ИИ (36,5% населения).
- 83% в Китае считают, что у AI‑продуктов/сервисов больше плюсов, чем минусов.
- Зарегистрированные ИИ‑разработки: 117 (04.2024) → 801 (08.2025), +585%.
- Внедрение по регионам неравномерно: местами остаётся «просто цифровизация».
- Автопроверка не идеальна: в 2024 Zuoyebang на задачах уровня гаокао набирала <4/5.
⚠️ Обратная сторона
- AI‑плагиат и разрыв «домашки vs знания» (высокие баллы за письменное, слабое устное).
- Риск непроверенной/сгенерированной информации в науке и падение критического мышления - отсюда рост правил и контроля.
🧩 Насколько реально повторить вне Китая
Повторяемо
- Пилоты + измеримые метрики эффекта (успеваемость, нагрузка учителя, вовлечённость).
- Возрастной AI‑curriculum + этика/верификация.
- ИИ в рутину, но human‑in‑the‑loop на критичных точках.
- Политики «что можно/нельзя» + изменение формата оценивания (устное/практика/проекты).
Труднее
- Супер‑масштаб и скорость централизованной модели + единая инфраструктура/регуляторика.
- «Навязывание стандарта» (например, обязательность локальных/зарегистрированных сервисов).
#AI #ML #Education #Kids #Software #ML #Economics
Forbes.ru
От чудесного друга к виртуальному лектору: как китайцев учат тонкостям ИИ с пеленок
Китай стремится к мировому лидерству во всех сферах, включая искусственный интеллект. Для этого он задействует все инструменты, начиная от жесткого госконтроля и заканчивая массовым внедрением ИИ в сферу образования. Роботы-собеседники и виртуальные
❤6🔥5⚡1🤬1
Современные методы описания функциональных требований к системам (Writing Effective Use Cases) (Рубрика #Software)
Во время подготовки материалов для своего сайта по System Design (https://system-design.space/) наткнулся в своей библиотеке на книгу Алистера Кокберна про написание функциональных требования. Сам Алистер - один из соавторов Agile-манифеста 2001 года, а также один из главных популяризаторов метода вариантов использования (Use Cases) для описания требований. Самой книге в этом году исполнилось 25 лет, поэтому я решил вспомнить про нее, а заодно про эволюцию подходов к описанию требований.
К концу 1990-х варианты использования стали одним из основных способов описания требований к поведению системы. Однако писать действительно хорошие use case было нелегко - требовались чёткие формулировки и логичная структура, как при написании хорошего эссе. Коберн решил эту проблему на практике, выпустив своё руководство по написанию вариантов использования в 2001 году. Книга подробно разъяснила как документировать сценарии: как определить границы системы (scope), описать актёров, их цели и пошаговый ход взаимодействия. Автор включил реальные примеры и сформулировал ряд правил, помогающих создавать понятные и полезные описания. Такой прикладной подход сделал книгу популярной среди инженеров.
На текущий момент индустрия разработки существенно изменилась. С появлением Agile-команд громоздкие спецификации требований уступили место более лёгким артефактам - таким как user stories (пользовательские истории). Формальные же use case многими стали считаться устаревшими. Однако на практике варианты использования до сих пор применяются, особенно в крупных сложных проектах. Их структурированный формат с проработкой логики и исключений даёт разработчикам понятное техническое задание. Подготовка use case более трудоёмка, но впоследствии экономится время на реализации и отладке требований.
Если же говорить про эволюцию подходов, то с момента выхода книги Алистера появились другие, более гибкие методы, ориентированные на работу с требованиями пользователей
1️⃣ User Story
Этот формат зародился в Agile-разработке: требования формулируются кратко от лица пользователя (по шаблону “As a ..., I want ..., so that ...”). User stories акцентируют ценность для пользователя и благодаря простоте быстро завоевали популярность в Agile-разработке.
2️⃣ Jobs to be Done (JTBD)
JTBD - концепция, рассматривающая, какую «работу» пользователь «нанимает» продукт выполнить для решения своей проблемы.
3️⃣ Job Story
Формат job story появился как развитие подхода Jobs to be Done. В job story акцент смещён с образа пользователя на саму задачу и контекст её выполнения. Используется шаблон: “When [ситуация], I want to [действие], so I can [результат].” Такой подход чётко обозначает ситуацию и мотивацию, позволяя сконцентрироваться на решении реальной задачи.
4️⃣ Design Thinking
Design thinking (дизайн-мышление) – человеко-ориентированный творческий процесс решения проблем: через эмпатию и эксперименты команда ищет нестандартные решения, отвечающие потребностям пользователей.
В общем, книга Алистера сейчас уже устарела, но сам подход к написанию use cases полезно знать, особенно как предшественников очередных модных подходов, которые обыгрывают похожие идеи косметически изменяя формулировки:)
#Software #Architect #SystemDesign #SoftwareArchitecture #Processes
Во время подготовки материалов для своего сайта по System Design (https://system-design.space/) наткнулся в своей библиотеке на книгу Алистера Кокберна про написание функциональных требования. Сам Алистер - один из соавторов Agile-манифеста 2001 года, а также один из главных популяризаторов метода вариантов использования (Use Cases) для описания требований. Самой книге в этом году исполнилось 25 лет, поэтому я решил вспомнить про нее, а заодно про эволюцию подходов к описанию требований.
К концу 1990-х варианты использования стали одним из основных способов описания требований к поведению системы. Однако писать действительно хорошие use case было нелегко - требовались чёткие формулировки и логичная структура, как при написании хорошего эссе. Коберн решил эту проблему на практике, выпустив своё руководство по написанию вариантов использования в 2001 году. Книга подробно разъяснила как документировать сценарии: как определить границы системы (scope), описать актёров, их цели и пошаговый ход взаимодействия. Автор включил реальные примеры и сформулировал ряд правил, помогающих создавать понятные и полезные описания. Такой прикладной подход сделал книгу популярной среди инженеров.
На текущий момент индустрия разработки существенно изменилась. С появлением Agile-команд громоздкие спецификации требований уступили место более лёгким артефактам - таким как user stories (пользовательские истории). Формальные же use case многими стали считаться устаревшими. Однако на практике варианты использования до сих пор применяются, особенно в крупных сложных проектах. Их структурированный формат с проработкой логики и исключений даёт разработчикам понятное техническое задание. Подготовка use case более трудоёмка, но впоследствии экономится время на реализации и отладке требований.
Если же говорить про эволюцию подходов, то с момента выхода книги Алистера появились другие, более гибкие методы, ориентированные на работу с требованиями пользователей
1️⃣ User Story
A user story is a short, informal explanation of a software feature, written from the perspective of the end user.
Этот формат зародился в Agile-разработке: требования формулируются кратко от лица пользователя (по шаблону “As a ..., I want ..., so that ...”). User stories акцентируют ценность для пользователя и благодаря простоте быстро завоевали популярность в Agile-разработке.
2️⃣ Jobs to be Done (JTBD)
Jobs to be Done is a framework that helps product teams understand what job a customer is hiring a product to do — what problem, challenge, or opportunity is so important to them that they're willing to hire your product to address it.
JTBD - концепция, рассматривающая, какую «работу» пользователь «нанимает» продукт выполнить для решения своей проблемы.
3️⃣ Job Story
An exciting alternative for some teams is the job story. A job story is focused less on the user performing some function than on the job to be done by that story.
Формат job story появился как развитие подхода Jobs to be Done. В job story акцент смещён с образа пользователя на саму задачу и контекст её выполнения. Используется шаблон: “When [ситуация], I want to [действие], so I can [результат].” Такой подход чётко обозначает ситуацию и мотивацию, позволяя сконцентрироваться на решении реальной задачи.
4️⃣ Design Thinking
Design thinking is a problem-solving approach that focuses on understanding users’ needs and creating innovative solutions.
Design thinking (дизайн-мышление) – человеко-ориентированный творческий процесс решения проблем: через эмпатию и эксперименты команда ищет нестандартные решения, отвечающие потребностям пользователей.
В общем, книга Алистера сейчас уже устарела, но сам подход к написанию use cases полезно знать, особенно как предшественников очередных модных подходов, которые обыгрывают похожие идеи косметически изменяя формулировки:)
#Software #Architect #SystemDesign #SoftwareArchitecture #Processes
❤12🔥6👍5
Дискуссия на T-Sync Conf на тему "AI меняет инженерную культуру — быстрее, чем мы это осознали" (Рубрика #AI)
Конференция T-Sync состоится уже 7 февраля, я там буду на стенде презентовать результаты нашего исследования про влияние AI на SDLC, а также поучаствую в крутой дискуссии на тему инженерной культуры и о том, как AI влияет не только на скорость разработки,но и на мышление, ответственность и подходы инженерных команд. Планируем обсудить следующие темы
- Как меняется роль инженера в эпоху AI,
- Что происходит с качеством решений и инженерной экспертизой,
- Усиливает ли AI культуру или размывает её,
- Какие эффекты мы уже видим в реальных командах — и какие пока игнорируем.
Это разговор не про инструменты, а про людей, практики и инженерную идентичность.
P.S.
Если еще не зарегестрировались на конфу, то самое время
#AI #DevOps #Software #Engineering #Culture #Management #Leadership
Конференция T-Sync состоится уже 7 февраля, я там буду на стенде презентовать результаты нашего исследования про влияние AI на SDLC, а также поучаствую в крутой дискуссии на тему инженерной культуры и о том, как AI влияет не только на скорость разработки,но и на мышление, ответственность и подходы инженерных команд. Планируем обсудить следующие темы
- Как меняется роль инженера в эпоху AI,
- Что происходит с качеством решений и инженерной экспертизой,
- Усиливает ли AI культуру или размывает её,
- Какие эффекты мы уже видим в реальных командах — и какие пока игнорируем.
Это разговор не про инструменты, а про людей, практики и инженерную идентичность.
P.S.
Если еще не зарегестрировались на конфу, то самое время
#AI #DevOps #Software #Engineering #Culture #Management #Leadership
❤6🔥5👏3🏆2
Книжный куб pinned «Сайт по system design (Рубрика #Architecture) Многие мои подписчики знают, что я планировал написать книгу ... но я не уточнял какую. Суть была в том, что я параллельно занимался работой над несколькими книгами. Ближе всего к готовности была книга по System…»
[1/2] Prompt Engineering for LLMs (Рубрика #AI)
Прочитал по большей части на новогодних каникулах популярную книгу про prompt engineering , которая вышла ~2 года назад. В ней Джон Берриман и Альберт Циглер рассказывали о том, как правильно «разговаривать» с большими языковыми моделями (LLMs). Авторов интересно читать, так как они – создатели одного из самых успешных AI-продуктов (GitHub Copilot) и шарят в теме.
В 2024 году тема prompt engineering была горячей, ее много обсуждали и эта книга стала одним из первых гидов - от основ до продвинутых тем, также в ней были готовые шаблоны с примерами кода. Все это сделало книгу ценным пособием для разработчиков. Если говорить подробнее про содержание книги, то она состоит из трех частей
1️⃣ Основы LLM: устройство и эволюция моделей, их обучение и переход к диалогам.
В первой части было 4 главы
1. Introduction to Prompt Engineering - почему LLM выглядят как «магия», краткая эволюция языковых моделей и где в этой картине prompt engineering как инженерная дисциплина.
2. Understanding LLMs - LLM как completion engine: токены/токенизация, автрорегрессия, галлюцинации, temperature/probabilities, основы трансформера; почему порядок текста и «нагрузка» на модель реально влияют на качество.
3. Moving to Chat - переход от completion к chat: RLHF (как он собирается), instruct vs chat, «alignment tax», эволюция API и почему следующая остановка — tools. Идея промптинга как «постановки пьесы» (сцены/роли/реплики).
4. Designing LLM Applications - ключевой фрейм: LLM loop (перевод проблемы пользователя в домен модели → completion → пост‑обработка обратно). Внутри: retrieval → snippetizing → scoring → prompt assembly; где добавляются state, внешний контекст, глубина рассуждений, tools и eval.
2️⃣ Ключевые техники: few-shot примеры, добавление внешних данных (подход Retrieval-Augmented Generation) для снижения галлюцинаций, форматирование длинных запросов
Во второй части было 3 главы
5. Prompt Content - из чего «собирать» промпт: static (инструкции, few-shot + типовые риски) vs dynamic (контекст на лету); RAG (lexical vs neural), эмбеддинги/векторное хранилище; суммаризация (в т.ч. иерархическая) и выбор «общей» vs «под задачу».
6. Assembling the Prompt - как упаковать всё в лимит контекста: «анатомия» промпта, выбор формата документа (advice conversation / analytic report / structured doc), форматирование сниппетов и few-shot, elastic snippets, зависимости между кусками (position/importance/dependency). Плюс важная практика: середина промпта часто “проседает” (условная valley of meh), важное лучше держать ближе к концу.
7. Taming the Model - «анатомия completion»: preamble, узнаваемые start/end, postscript; stop‑sequence/стриминг; logprobs для уверенности/классификации; как выбирать модель (качество/цена/латентность/фичи).
В продолжении я расскажу про продвинутые темы, а также поделюсь своими мыслями насчет актуальности книги в 2026 году.
#AI #DevOps #Software #Engineering #Architecture
Прочитал по большей части на новогодних каникулах популярную книгу про prompt engineering , которая вышла ~2 года назад. В ней Джон Берриман и Альберт Циглер рассказывали о том, как правильно «разговаривать» с большими языковыми моделями (LLMs). Авторов интересно читать, так как они – создатели одного из самых успешных AI-продуктов (GitHub Copilot) и шарят в теме.
В 2024 году тема prompt engineering была горячей, ее много обсуждали и эта книга стала одним из первых гидов - от основ до продвинутых тем, также в ней были готовые шаблоны с примерами кода. Все это сделало книгу ценным пособием для разработчиков. Если говорить подробнее про содержание книги, то она состоит из трех частей
1️⃣ Основы LLM: устройство и эволюция моделей, их обучение и переход к диалогам.
В первой части было 4 главы
1. Introduction to Prompt Engineering - почему LLM выглядят как «магия», краткая эволюция языковых моделей и где в этой картине prompt engineering как инженерная дисциплина.
2. Understanding LLMs - LLM как completion engine: токены/токенизация, автрорегрессия, галлюцинации, temperature/probabilities, основы трансформера; почему порядок текста и «нагрузка» на модель реально влияют на качество.
3. Moving to Chat - переход от completion к chat: RLHF (как он собирается), instruct vs chat, «alignment tax», эволюция API и почему следующая остановка — tools. Идея промптинга как «постановки пьесы» (сцены/роли/реплики).
4. Designing LLM Applications - ключевой фрейм: LLM loop (перевод проблемы пользователя в домен модели → completion → пост‑обработка обратно). Внутри: retrieval → snippetizing → scoring → prompt assembly; где добавляются state, внешний контекст, глубина рассуждений, tools и eval.
2️⃣ Ключевые техники: few-shot примеры, добавление внешних данных (подход Retrieval-Augmented Generation) для снижения галлюцинаций, форматирование длинных запросов
Во второй части было 3 главы
5. Prompt Content - из чего «собирать» промпт: static (инструкции, few-shot + типовые риски) vs dynamic (контекст на лету); RAG (lexical vs neural), эмбеддинги/векторное хранилище; суммаризация (в т.ч. иерархическая) и выбор «общей» vs «под задачу».
6. Assembling the Prompt - как упаковать всё в лимит контекста: «анатомия» промпта, выбор формата документа (advice conversation / analytic report / structured doc), форматирование сниппетов и few-shot, elastic snippets, зависимости между кусками (position/importance/dependency). Плюс важная практика: середина промпта часто “проседает” (условная valley of meh), важное лучше держать ближе к концу.
7. Taming the Model - «анатомия completion»: preamble, узнаваемые start/end, postscript; stop‑sequence/стриминг; logprobs для уверенности/классификации; как выбирать модель (качество/цена/латентность/фичи).
В продолжении я расскажу про продвинутые темы, а также поделюсь своими мыслями насчет актуальности книги в 2026 году.
#AI #DevOps #Software #Engineering #Architecture
❤14🔥7👍5👎2🥱1🥴1
[2/2] Prompt Engineering for LLMs (Рубрика #AI)
Заканчивая рассказ про книгу о промпт инжиниринге надо рассказать про продвинутые темы, а также поделюсь своими мыслями насчет актуальности книги в 2026 году.
3️⃣ Продвинутые темы: разработка чат-агентов с памятью и инструментами (метод ReAct), разбиение сложных задач на шаги (workflows), оценка качества решений моделью.
8. Conversational Agency - tool use в деталях: как проектировать инструменты (имена/аргументы), разруливать ошибки и опасные действия; reasoning‑паттерны (CoT, ReAct и дальше); контекст для task‑диалогов; сборка агента, управление диалогом и UX.
9. LLM Workflows - когда «чат‑агент» не нужен, а нужен workflow: задачи как кирпичики; реализация через шаблонные промпты или tools; усложнение/вариативность; идея «eval начинается на уровне task»; пример end‑to‑end workflow; продвинутые схемы: agent‑driven workflow, stateful task agents, роли/делегирование.
10. Evaluating LLM Applications - что вообще тестируем; offline: example suites, gold standard / functional testing / LLM‑as‑judge, SOMA; online: A/B и метрики.
11. Looking Ahead - куда всё едет: multimodality, UI/UX как часть качества, рост «интеллекта»/скорости/доступности моделей.
В общем, контента в книге много, но возникает вопрос, а насколько он полезен сейчас (в 2026 году). И действительно с момента выхода книги LLM-технологии шагнули вперёд, и некоторые в 2025-м провозгласили «prompt engineering мёртв». Качество моделей выросло – они всё лучше понимают пользователя даже без хитрых подсказок; кроме того, лучшие техники уже встроены в инструменты (готовые шаблоны промптов). В реальных продуктах поведение модели всё чаще определяется системными настройками или fine-tuning’ом, а не текстом пользовательского запроса. В итоге роль "prompt engineer" вскоре слилась с более широкими ролями AI/LLM-разработчиков.
Однако книга не потеряла ценности – её фундаментальные принципы по-прежнему полезны каждому инженеру. Авторы честно предупреждали, что конкретные API могут устареть, но базовые идеи останутся актуальными. Так и вышло: например, подход RAG теперь повсеместно применяют для подключения знаний модели, а техника chain-of-thought стала стандартным приёмом в современных AI-агентах. А в 2025 году Андрей Карпати ввёл термин «контекст-инжиниринг» – фокус на предоставлении модели полного окружения (данные, история, инструменты) вместо подбора идеальной формулировки запроса. Такой подход требует уметь динамически находить и подставлять нужные сведения, ужимать их под контекстное окно, чётко задавать роли (system/user) и подключать внешние инструменты по мере необходимости. Кроме того, появились практики вроде PromptOps – управление промптами (версионирование, мониторинг качества запросов). А некоторые команды уже пытаются полностью автоматизировать подготовку контекста и инструкций (т.н. workflow-подход).
#AI #DevOps #Software #Engineering #Architecture
Заканчивая рассказ про книгу о промпт инжиниринге надо рассказать про продвинутые темы, а также поделюсь своими мыслями насчет актуальности книги в 2026 году.
3️⃣ Продвинутые темы: разработка чат-агентов с памятью и инструментами (метод ReAct), разбиение сложных задач на шаги (workflows), оценка качества решений моделью.
8. Conversational Agency - tool use в деталях: как проектировать инструменты (имена/аргументы), разруливать ошибки и опасные действия; reasoning‑паттерны (CoT, ReAct и дальше); контекст для task‑диалогов; сборка агента, управление диалогом и UX.
9. LLM Workflows - когда «чат‑агент» не нужен, а нужен workflow: задачи как кирпичики; реализация через шаблонные промпты или tools; усложнение/вариативность; идея «eval начинается на уровне task»; пример end‑to‑end workflow; продвинутые схемы: agent‑driven workflow, stateful task agents, роли/делегирование.
10. Evaluating LLM Applications - что вообще тестируем; offline: example suites, gold standard / functional testing / LLM‑as‑judge, SOMA; online: A/B и метрики.
11. Looking Ahead - куда всё едет: multimodality, UI/UX как часть качества, рост «интеллекта»/скорости/доступности моделей.
В общем, контента в книге много, но возникает вопрос, а насколько он полезен сейчас (в 2026 году). И действительно с момента выхода книги LLM-технологии шагнули вперёд, и некоторые в 2025-м провозгласили «prompt engineering мёртв». Качество моделей выросло – они всё лучше понимают пользователя даже без хитрых подсказок; кроме того, лучшие техники уже встроены в инструменты (готовые шаблоны промптов). В реальных продуктах поведение модели всё чаще определяется системными настройками или fine-tuning’ом, а не текстом пользовательского запроса. В итоге роль "prompt engineer" вскоре слилась с более широкими ролями AI/LLM-разработчиков.
Однако книга не потеряла ценности – её фундаментальные принципы по-прежнему полезны каждому инженеру. Авторы честно предупреждали, что конкретные API могут устареть, но базовые идеи останутся актуальными. Так и вышло: например, подход RAG теперь повсеместно применяют для подключения знаний модели, а техника chain-of-thought стала стандартным приёмом в современных AI-агентах. А в 2025 году Андрей Карпати ввёл термин «контекст-инжиниринг» – фокус на предоставлении модели полного окружения (данные, история, инструменты) вместо подбора идеальной формулировки запроса. Такой подход требует уметь динамически находить и подставлять нужные сведения, ужимать их под контекстное окно, чётко задавать роли (system/user) и подключать внешние инструменты по мере необходимости. Кроме того, появились практики вроде PromptOps – управление промптами (версионирование, мониторинг качества запросов). А некоторые команды уже пытаются полностью автоматизировать подготовку контекста и инструкций (т.н. workflow-подход).
#AI #DevOps #Software #Engineering #Architecture
Telegram
Книжный куб
[1/2] Prompt Engineering for LLMs (Рубрика #AI)
Прочитал по большей части на новогодних каникулах популярную книгу про prompt engineering , которая вышла ~2 года назад. В ней Джон Берриман и Альберт Циглер рассказывали о том, как правильно «разговаривать»…
Прочитал по большей части на новогодних каникулах популярную книгу про prompt engineering , которая вышла ~2 года назад. В ней Джон Берриман и Альберт Циглер рассказывали о том, как правильно «разговаривать»…
❤15👍7✍3
CS230 Lecture 2 @ Stanford (Рубрика #AI)
Раньше я уже рассказывал про то, что начал изучать этот курс и посмотрел первую лекцию Andrew Ng. Дальше пришло время второй лекции, которую вел Kian Katanforoosh, со-автор этого курса, CEO и основатель Workera (платформа для оценки AI-навыков), сооснователь deeplearning.ai. Лекция выглядела как "recap про supervised" после изучения лекций с Coursera, но на деле это разбор инженерных рычагов в AI‑проектах: постановка задачи → данные/разметка → архитектура → loss → эксплуатация embeddings. Основные тезисы примерно следующие
1️⃣ Supervised ML решение - это обычный прод‑сервис
- В проде «модель» = архитектура + веса (два артефакта), вокруг которых крутятся пайплайны, метрики и деплой.
- Меняете задачу (binary → multi‑label) - меняется контракт лейблов, loss и метрики. Это не «добавили классы в датасет».
- Capacity: размер модели должен соответствовать сложности + разнообразию данных + compute/latency. Иначе получите красивый dev и боль в реальном трафике.
- Embeddings - когда расстояния в пространстве имеют смысл. Это фундамент поиска, рекомендаций, retrieval/RAG и «переиспользуемых представлений».
2️⃣ Три кейса, где всё решают данные и постановка
1) Определение day/night по картинке: сначала scope (одна камера или «весь мир»? indoor/outdoor? рассвет/закат/полярный день?) → потом сбор данных. Разрешение подбирают через human‑эксперимент: печатаем/показываем людям разное качество и ищем нижнюю границу информативности. Типичный компромисс: ~64×64×3 + небольшая CNN.
2) Работа с триггер словом типа "Алекса"/"Алиса"/"Siri", тут предлагается “activate”: классический паттерн каскада (дешёвое → дорогое): VAD/activity → trigger → ASR/intent. Чтобы не разметить руками бесконечные аудио, делают synthetic data + programmatic labeling: позитивы (“activate”), hard negatives (“deactivate” и похожие), фоновые шумы; скрипт миксует всё в 10‑сек клипы и генерит временные метки. Часто выигрыш даёт не «ещё данных», а правильная схема разметки по времени.
3) Face verification: «сравниваем пиксели» и «классифицируем каждого человека» не масштабируются. Решение - face embeddings + triplet loss (A,P ближе, чем A,N + margin). Дальше один embedding‑слой закрывает сразу три продукта:
- verification: distance < threshold
- identification: nearest neighbor по базе
- clustering: k‑means/agglo
3️⃣ Как масштабироваться без дорогих меток
- Self‑supervised: contrastive (SimCLR‑стиль) - две аугментации одного объекта должны быть ближе, остальные дальше; и next‑token prediction (GPT) - данные «размечают себя».
- Weak supervision: используем естественные пары модальностей (image↔️text, video↔️audio, subtitles↔️video). Отсюда CLIP/ImageBind‑подходы и единые multimodal embedding‑spaces.
Что можно почерпнуть для техлида DL/ML проекта
- Начинайте проект с постановки + распределения + edge‑кейсов, не с выбора модели.
- Ревьюйте свои ML модели как код: labels contract + loss + метрики (и их связь с бизнес‑ценой ошибок).
- Делайте быстрые human‑тесты до траты GPU‑недель.
- Оптимизируйте iteration speed: чуть меньшая модель/разрешение часто быстрее приводит к правильной системе.
- Стройте архитектуру вокруг embedding‑API: «выучили представление один раз → решаем N задач».
- Ищите в домене неразмеченные потоки и слабые связи (логи↔️действия, текст↔️телеметрия) - это топливо для self/weak supervision.
#Software #ML #AI #Engineering #Architecture
Раньше я уже рассказывал про то, что начал изучать этот курс и посмотрел первую лекцию Andrew Ng. Дальше пришло время второй лекции, которую вел Kian Katanforoosh, со-автор этого курса, CEO и основатель Workera (платформа для оценки AI-навыков), сооснователь deeplearning.ai. Лекция выглядела как "recap про supervised" после изучения лекций с Coursera, но на деле это разбор инженерных рычагов в AI‑проектах: постановка задачи → данные/разметка → архитектура → loss → эксплуатация embeddings. Основные тезисы примерно следующие
1️⃣ Supervised ML решение - это обычный прод‑сервис
- В проде «модель» = архитектура + веса (два артефакта), вокруг которых крутятся пайплайны, метрики и деплой.
- Меняете задачу (binary → multi‑label) - меняется контракт лейблов, loss и метрики. Это не «добавили классы в датасет».
- Capacity: размер модели должен соответствовать сложности + разнообразию данных + compute/latency. Иначе получите красивый dev и боль в реальном трафике.
- Embeddings - когда расстояния в пространстве имеют смысл. Это фундамент поиска, рекомендаций, retrieval/RAG и «переиспользуемых представлений».
2️⃣ Три кейса, где всё решают данные и постановка
1) Определение day/night по картинке: сначала scope (одна камера или «весь мир»? indoor/outdoor? рассвет/закат/полярный день?) → потом сбор данных. Разрешение подбирают через human‑эксперимент: печатаем/показываем людям разное качество и ищем нижнюю границу информативности. Типичный компромисс: ~64×64×3 + небольшая CNN.
2) Работа с триггер словом типа "Алекса"/"Алиса"/"Siri", тут предлагается “activate”: классический паттерн каскада (дешёвое → дорогое): VAD/activity → trigger → ASR/intent. Чтобы не разметить руками бесконечные аудио, делают synthetic data + programmatic labeling: позитивы (“activate”), hard negatives (“deactivate” и похожие), фоновые шумы; скрипт миксует всё в 10‑сек клипы и генерит временные метки. Часто выигрыш даёт не «ещё данных», а правильная схема разметки по времени.
3) Face verification: «сравниваем пиксели» и «классифицируем каждого человека» не масштабируются. Решение - face embeddings + triplet loss (A,P ближе, чем A,N + margin). Дальше один embedding‑слой закрывает сразу три продукта:
- verification: distance < threshold
- identification: nearest neighbor по базе
- clustering: k‑means/agglo
3️⃣ Как масштабироваться без дорогих меток
- Self‑supervised: contrastive (SimCLR‑стиль) - две аугментации одного объекта должны быть ближе, остальные дальше; и next‑token prediction (GPT) - данные «размечают себя».
- Weak supervision: используем естественные пары модальностей (image↔️text, video↔️audio, subtitles↔️video). Отсюда CLIP/ImageBind‑подходы и единые multimodal embedding‑spaces.
Что можно почерпнуть для техлида DL/ML проекта
- Начинайте проект с постановки + распределения + edge‑кейсов, не с выбора модели.
- Ревьюйте свои ML модели как код: labels contract + loss + метрики (и их связь с бизнес‑ценой ошибок).
- Делайте быстрые human‑тесты до траты GPU‑недель.
- Оптимизируйте iteration speed: чуть меньшая модель/разрешение часто быстрее приводит к правильной системе.
- Стройте архитектуру вокруг embedding‑API: «выучили представление один раз → решаем N задач».
- Ищите в домене неразмеченные потоки и слабые связи (логи↔️действия, текст↔️телеметрия) - это топливо для self/weak supervision.
#Software #ML #AI #Engineering #Architecture
YouTube
Stanford CS230 | Autumn 2025 | Lecture 2: Supervised, Self-Supervised, & Weakly Supervised Learning
For more information about Stanford’s Artificial Intelligence professional and graduate programs, visit: https://stanford.io/ai
September 30, 2025
This lecture covers key AI concepts through case studies.
To learn more about enrolling in this course, visit:…
September 30, 2025
This lecture covers key AI concepts through case studies.
To learn more about enrolling in this course, visit:…
👍7❤4🔥2
AI Periodic Table Explained: Mapping LLMs, RAG & AI Agent Frameworks (Рубрика #AI)
Посмотрел очередное интересное обучающее видео от Martin Keen из IBM, где он пытается свести AI терминологию в понятную систему. Все из-за того, что у нас куча терминов навроде таких: "агенты", "RAG", "эмбеддинги", "гардрейлы", все эти термины летают вокруг, и от разработчиков ожидается, что они просто знают, как это всё связано, но это далеко не так просто уложить в голове. Для этого Мартин предложил свою структуру для систематизации в виде периодическиой системыМенделеева "AI Periodic Table". У этой таблицы, как ни странно, два измеренияя
Строки (периоды) - этпы
1. Primitives - атомарные блоки (Prompts, Embeddings, LLMs)
2. Compositions - комбинации примитивов (RAG, Vector DBs, Guardrails)
3. Deployment - продакшн-паттерны (Agents, Frameworks, Fine-tuning)
4. Emerging - передний край (Multi-Agent, Thinking Models, Interpretability)
Колонки (семейства)
1. Reactive (реактивные) - изменение входа → радикальное изменение выхода
2. Retrieval (поиск) - хранение и извлечение информации
3. Orchestration (оркестрация) - связывание множества компонентов
4. Validation (валидация) - безопасность и тестирование
5. Models (модели) - стабильные фундаментальные возможности
Если разбирать содержимое таблицы по колонкам, то получится интересно
Reactive Family
- Pr (Prompt) - инструкции для AI
- Fc (Function Calling) - вызов внешних API/инструментов
- Ag (Agent) - цикл думай-действуй-наблюдай
- Ma (Multi-Agent) - коллаборация нескольких AI агентов
Retrieval Family
- Em (Embeddings) - численные представления смысла
- Vx (Vector Database) - хранилище для семантического поиска
- Ft (Fine-tuning) - адаптация к доменным данным
- Sy (Synthetic data) - синтетические данные, на которых сейчас зачастую учатся новые модели
Orchestration Family
- Rg (RAG) - блок про Retrieval Augmented Generation
- Fw (Framework) - платформы вроде LangChain
Validation Family
- Gr (Guardrails) - runtime-фильтры безопасности
- Rt (Red Teaming) - adversarial-тестирование при помощи атакующих red teams
- In (Interpretability) - понимание "почему" модель именно так отрабатывает во время inference
Models Family
- Lg (LLM) - большие языковые модели от OpenAI, Antrhopic, Google, Alibaba, DeepSeek и других
- Mm (Multi-modal) - мультмодальные модели, что позволяют обрабатывать помимо текста изображения, аудио и так далее
- Sm (Small Models) - дистиллированные модели для edge и не только
- Th (Thinking Models) - chain-of-thought встроен в архитектуру новых моделей
Дальше в видео Мартин рассказывает как такая картинка в голове помогает лучше укладывать информацию, а также размышлять про решение задач, связанных с AI в реальном мире. Мне концепция нравится - я сам часто размышляю визуально схемами и эта схема выглядит неплохо и хорошо укладывается в мою голову:))
Плюс мне кажется, что эту схему можно использовать при проектировании и прогонять идеи через призму таблицы. Например, когда кто-то питчит "AI-решение", можно мгновенно декомпозировать его на элементы таблицы:
- Какие элементы используются?
- Какие реакции они запускают?
- Отсутствует ли элемент безопасности (Gr)?
- Нет ли over-engineering в оркестрации?
- Подходит ли Thinking Model там, где хватило бы Small Model?
#AI #DevOps #Software #Engineering #Architecture #SystemDesign
Посмотрел очередное интересное обучающее видео от Martin Keen из IBM, где он пытается свести AI терминологию в понятную систему. Все из-за того, что у нас куча терминов навроде таких: "агенты", "RAG", "эмбеддинги", "гардрейлы", все эти термины летают вокруг, и от разработчиков ожидается, что они просто знают, как это всё связано, но это далеко не так просто уложить в голове. Для этого Мартин предложил свою структуру для систематизации в виде периодическиой системы
Строки (периоды) - этпы
1. Primitives - атомарные блоки (Prompts, Embeddings, LLMs)
2. Compositions - комбинации примитивов (RAG, Vector DBs, Guardrails)
3. Deployment - продакшн-паттерны (Agents, Frameworks, Fine-tuning)
4. Emerging - передний край (Multi-Agent, Thinking Models, Interpretability)
Колонки (семейства)
1. Reactive (реактивные) - изменение входа → радикальное изменение выхода
2. Retrieval (поиск) - хранение и извлечение информации
3. Orchestration (оркестрация) - связывание множества компонентов
4. Validation (валидация) - безопасность и тестирование
5. Models (модели) - стабильные фундаментальные возможности
Если разбирать содержимое таблицы по колонкам, то получится интересно
Reactive Family
- Pr (Prompt) - инструкции для AI
- Fc (Function Calling) - вызов внешних API/инструментов
- Ag (Agent) - цикл думай-действуй-наблюдай
- Ma (Multi-Agent) - коллаборация нескольких AI агентов
Retrieval Family
- Em (Embeddings) - численные представления смысла
- Vx (Vector Database) - хранилище для семантического поиска
- Ft (Fine-tuning) - адаптация к доменным данным
- Sy (Synthetic data) - синтетические данные, на которых сейчас зачастую учатся новые модели
Orchestration Family
- Rg (RAG) - блок про Retrieval Augmented Generation
- Fw (Framework) - платформы вроде LangChain
Validation Family
- Gr (Guardrails) - runtime-фильтры безопасности
- Rt (Red Teaming) - adversarial-тестирование при помощи атакующих red teams
- In (Interpretability) - понимание "почему" модель именно так отрабатывает во время inference
Models Family
- Lg (LLM) - большие языковые модели от OpenAI, Antrhopic, Google, Alibaba, DeepSeek и других
- Mm (Multi-modal) - мультмодальные модели, что позволяют обрабатывать помимо текста изображения, аудио и так далее
- Sm (Small Models) - дистиллированные модели для edge и не только
- Th (Thinking Models) - chain-of-thought встроен в архитектуру новых моделей
Дальше в видео Мартин рассказывает как такая картинка в голове помогает лучше укладывать информацию, а также размышлять про решение задач, связанных с AI в реальном мире. Мне концепция нравится - я сам часто размышляю визуально схемами и эта схема выглядит неплохо и хорошо укладывается в мою голову:))
Плюс мне кажется, что эту схему можно использовать при проектировании и прогонять идеи через призму таблицы. Например, когда кто-то питчит "AI-решение", можно мгновенно декомпозировать его на элементы таблицы:
- Какие элементы используются?
- Какие реакции они запускают?
- Отсутствует ли элемент безопасности (Gr)?
- Нет ли over-engineering в оркестрации?
- Подходит ли Thinking Model там, где хватило бы Small Model?
#AI #DevOps #Software #Engineering #Architecture #SystemDesign
👍15❤5🔥4
ASML Statement on Strengthening Focus on Engineering and Innovation (Рубрика #Engineering)
Вышла интересная новость от ASML, чьи литографы хотят все производители чипов. Так вот ASML внезапно обнаружила, что стала… less agile, процессы усложнились, скорость упала, матричная оргструктура начала мешать инженерии и пора принимать меры.
Если переводить с корпоративного, то можно прочитать это письмо так
- Matrix-структура больше не вывозит - слишком много пересечений, согласований и «непонятно кто владелец результата»
- Хотим product-ориентированную модель - чёткие продуктовые направления, end-to-end ownership, меньше размазанной ответственности
- Processes became “less agile” - для компании, которая живёт на скорости R&D, это почти диагноз.
В итоге, ребята решили сократить лишние уровни менеджмента и уволить 1.7к сотрудников, что я прочитал примерно так "кажется, у нас слишком много людей, которые управляют людьми, которые управляют процессами". Интересно будет дальше посмотреть как пройдет эта трансформация.
#Engineering #Management #Leadership #Software #Processes
Вышла интересная новость от ASML, чьи литографы хотят все производители чипов. Так вот ASML внезапно обнаружила, что стала… less agile, процессы усложнились, скорость упала, матричная оргструктура начала мешать инженерии и пора принимать меры.
Если переводить с корпоративного, то можно прочитать это письмо так
- Matrix-структура больше не вывозит - слишком много пересечений, согласований и «непонятно кто владелец результата»
- Хотим product-ориентированную модель - чёткие продуктовые направления, end-to-end ownership, меньше размазанной ответственности
- Processes became “less agile” - для компании, которая живёт на скорости R&D, это почти диагноз.
В итоге, ребята решили сократить лишние уровни менеджмента и уволить 1.7к сотрудников, что я прочитал примерно так "кажется, у нас слишком много людей, которые управляют людьми, которые управляют процессами". Интересно будет дальше посмотреть как пройдет эта трансформация.
#Engineering #Management #Leadership #Software #Processes
🔥9👍6❤3
Командировка в Питер (Рубрика #Travel)
Сегодня тревел-пост про комадировку в Питер, куда мне нравилось приезжать и раньше. Но в прошлом году у нас открылся новый офис, который подальше от метро, но супер уютный и удобный. Кроме того, в этот приезд нам как часть стратсессии коллеги устроили посещение Эрмитажа, но в закрытом режиме с отдельным гидом и почти пустыми залами и это было бомбически. Я люблю искусство, но я очень не люблю толпы людей, поэтому я редко хожу на большие мероприятия (концерты, популярные музеи и так далее). А тут получилось очень здорово - крутой музей и почти весь наш ... Теперь я и в другие музеи хочу ходить в таком режиме:))
#Travel
Сегодня тревел-пост про комадировку в Питер, куда мне нравилось приезжать и раньше. Но в прошлом году у нас открылся новый офис, который подальше от метро, но супер уютный и удобный. Кроме того, в этот приезд нам как часть стратсессии коллеги устроили посещение Эрмитажа, но в закрытом режиме с отдельным гидом и почти пустыми залами и это было бомбически. Я люблю искусство, но я очень не люблю толпы людей, поэтому я редко хожу на большие мероприятия (концерты, популярные музеи и так далее). А тут получилось очень здорово - крутой музей и почти весь наш ... Теперь я и в другие музеи хочу ходить в таком режиме:))
#Travel
🔥41👍13❤12