Инструменты
Каталог TGAds
beta
Мониторинг
Детальная статистика
Анализ аудитории
Бот аналитики
Полезная информация
Инструкция Telemetr
Документация к API
Чат Telemetr
Не попадитесь на накрученные каналы! Узнайте, не накручивает ли канал просмотры или
подписчиков
Проверить канал на накрутку
Телеграм канал «Клуб CDO»
Подписчики
Всего
3 718
Сегодня
+9
Просмотров на пост
Всего
758
ER
Общий
18.77%
Суточный
13.4%
Динамика публикаций
Telemetr - сервис глубокой аналитики
телеграм-каналов
телеграм-каналов
Получите подробную информацию о каждом канале
Отберите самые эффективные каналы для
рекламных размещений, по приросту подписчиков,
ER, количеству просмотров на пост и другим метрикам
рекламных размещений, по приросту подписчиков,
ER, количеству просмотров на пост и другим метрикам
Анализируйте рекламные посты
и креативы
и креативы
Узнайте какие посты лучше сработали,
а какие хуже, даже если их давно удалили
а какие хуже, даже если их давно удалили
Оценивайте эффективность тематики и контента
Узнайте, какую тематику лучше не рекламировать
на канале, а какая зайдет на ура
на канале, а какая зайдет на ура
Показано 7 из 2 512 постов
Смотреть все посты
Пост от 30.03.2026 15:32
300
0
7
Пока одни спорят, нужны ли системы управления данными (Data Governance), другие превращают их в драйвер развития ИИ. Как выстроить систему, которая не блокирует, а поддерживает внедрение ИИ? Почему качество данных становится особенно важным именно сейчас?
Поговорили об этом и не только с Алексеем Нейманом – исполнительным директором Ассоциации больших данных. Алексей и его команда каждый день работают с рынком данных и видят его изнутри.
В интервью – о том, почему качество ИИ зависит от качества данных, а Data Governance – не бюрократия, а драйвер для развития искусственного интеллекта.
AI Inside #голос_AI
Поговорили об этом и не только с Алексеем Нейманом – исполнительным директором Ассоциации больших данных. Алексей и его команда каждый день работают с рынком данных и видят его изнутри.
В интервью – о том, почему качество ИИ зависит от качества данных, а Data Governance – не бюрократия, а драйвер для развития искусственного интеллекта.
AI Inside #голос_AI
👍
2
Пост от 30.03.2026 13:18
351
0
5
Дайджест статей
📰 Как я проектирую OLTP-БД с нуля: принципы, trade-off'ы и архитектурные решения
🔗 https://habr.com/ru/articles/1014098/
💡 Вывод: Инженер пишет собственный OLTP-движок на Rust — с UNDO-log MVCC (как у InnoDB, Oracle, MSSQL), unified storage на БД и fail-closed поведением вместо тихой деградации. Главный тезис: если система под нагрузкой молчит и тянет — она врёт. Предсказуемый отказ с внятным SQLSTATE лучше, чем иллюзия, что «ещё дотянет». Для CDO: пример архитектурных решений на уровне storage engine, которые стоит знать при оценке собственных data-платформ.
📰 Как ML изменит бизнес в 2026 году: прогноз Selectel, GlowByte и Data Sapience
🔗 https://habr.com/ru/companies/selectel/articles/1013862/
💡 Вывод: Маркетинговый по форме, но полезный по структуре обзор корпоративного AI. Зерно: компании переходят от хаотичного использования LLM к централизованным корпоративным порталам с RBAC, квотами и биллингом. Shadow AI становится реальным драйвером создания внутренних GenAI-сред — не из любви к технологиям, а из страха потери контроля над корпоративными данными. AI-агенты в продакшн — это микросервис, которому нужен жизненный цикл, версионирование и CI/CD, а не просто промпт в блокноте.
📰 Как мы подружили DataLens и OpenMetadata: архитектура, код и подводные камни
🔗 https://habr.com/ru/companies/magnit/articles/1015708/
💡 Вывод: Команда DWH Magnit написала ingestion-коннектор DataLens → OpenMetadata с нуля и выложила в открытый доступ. Практический кейс: BI-объекты (дашборды, чарты, датасеты) вытащены в общий граф метаданных с lineage-цепочками. Главный урок — ingestion на реальном объёме немедленно упирается в rate limits и scope management, поэтому operational-параметры (задержки, ретраи, фильтрация коллекций) нужно закладывать в коннектор сразу, не после первого запуска на продовом контуре.
📰 Case for Self-Healing Data Observability in Converged Architectures
🔗 https://moderndata101.substack.com/p/self-healing-data-observability-in
💡 Вывод: Аргумент в пользу ARI-цикла (Anticipate → Remediate → Immunize) как архитектурного слоя качества данных, а не инструментального. Основная мысль: конвергированные платформы убрали швы между системами, но оставили observability в парадигме «оповестить человека» — это незаконченная архитектура. Самовосстанавливающаяся платформа не исключает инженера, а меняет его роль: от дежурного пожарного к проектировщику иммунной системы. Граница «что платформа решает сама, а что эскалирует» — это архитектурное решение, а не настройка порогов.
📰 Reference Data Management по-русски: что мы называем НСИ и почему это не всегда RDM
🔗 https://habr.com/ru/companies/datasapience/articles/1012404/
💡 Вывод: Честная разборка терминологии: российское «НСИ» на практике = RDM + часть MDM + немного DQ — исторически потому, что отдельных систем не было, и всё сваливали в одну. Для CDO: смешение задач — это не культурная особенность, а архитектурный риск. Один инструмент «на всё» хорошо звучит на слайде и плохо работает в эксплуатации. Продукт, который претендует закрыть RDM, MDM и DQ одновременно, — кандидат на идиотский индекс.
📰 How Long Until We Call AI Agents Data Products
🔗 https://moderndata101.substack.com/p/data-products-as-ai-agents
💡 Вывод: AI-агент в продакшне соответствует всем критериям data product — пользователи, контракты качества, жизненный цикл, обратная связь. Большинство команд запускают агентов как эксперименты и удивляются, почему они деградируют. Обсервабилити ≠ логирование: каждый retry — это измеримое трение, каждый брошенный диалог — невидимый отток. Единственная работающая обратная связь — ручная аннотация разговоров с последующим маппингом паттернов на тикеты. Не дашборды — решения.
📰 Как я проектирую OLTP-БД с нуля: принципы, trade-off'ы и архитектурные решения
🔗 https://habr.com/ru/articles/1014098/
💡 Вывод: Инженер пишет собственный OLTP-движок на Rust — с UNDO-log MVCC (как у InnoDB, Oracle, MSSQL), unified storage на БД и fail-closed поведением вместо тихой деградации. Главный тезис: если система под нагрузкой молчит и тянет — она врёт. Предсказуемый отказ с внятным SQLSTATE лучше, чем иллюзия, что «ещё дотянет». Для CDO: пример архитектурных решений на уровне storage engine, которые стоит знать при оценке собственных data-платформ.
📰 Как ML изменит бизнес в 2026 году: прогноз Selectel, GlowByte и Data Sapience
🔗 https://habr.com/ru/companies/selectel/articles/1013862/
💡 Вывод: Маркетинговый по форме, но полезный по структуре обзор корпоративного AI. Зерно: компании переходят от хаотичного использования LLM к централизованным корпоративным порталам с RBAC, квотами и биллингом. Shadow AI становится реальным драйвером создания внутренних GenAI-сред — не из любви к технологиям, а из страха потери контроля над корпоративными данными. AI-агенты в продакшн — это микросервис, которому нужен жизненный цикл, версионирование и CI/CD, а не просто промпт в блокноте.
📰 Как мы подружили DataLens и OpenMetadata: архитектура, код и подводные камни
🔗 https://habr.com/ru/companies/magnit/articles/1015708/
💡 Вывод: Команда DWH Magnit написала ingestion-коннектор DataLens → OpenMetadata с нуля и выложила в открытый доступ. Практический кейс: BI-объекты (дашборды, чарты, датасеты) вытащены в общий граф метаданных с lineage-цепочками. Главный урок — ingestion на реальном объёме немедленно упирается в rate limits и scope management, поэтому operational-параметры (задержки, ретраи, фильтрация коллекций) нужно закладывать в коннектор сразу, не после первого запуска на продовом контуре.
📰 Case for Self-Healing Data Observability in Converged Architectures
🔗 https://moderndata101.substack.com/p/self-healing-data-observability-in
💡 Вывод: Аргумент в пользу ARI-цикла (Anticipate → Remediate → Immunize) как архитектурного слоя качества данных, а не инструментального. Основная мысль: конвергированные платформы убрали швы между системами, но оставили observability в парадигме «оповестить человека» — это незаконченная архитектура. Самовосстанавливающаяся платформа не исключает инженера, а меняет его роль: от дежурного пожарного к проектировщику иммунной системы. Граница «что платформа решает сама, а что эскалирует» — это архитектурное решение, а не настройка порогов.
📰 Reference Data Management по-русски: что мы называем НСИ и почему это не всегда RDM
🔗 https://habr.com/ru/companies/datasapience/articles/1012404/
💡 Вывод: Честная разборка терминологии: российское «НСИ» на практике = RDM + часть MDM + немного DQ — исторически потому, что отдельных систем не было, и всё сваливали в одну. Для CDO: смешение задач — это не культурная особенность, а архитектурный риск. Один инструмент «на всё» хорошо звучит на слайде и плохо работает в эксплуатации. Продукт, который претендует закрыть RDM, MDM и DQ одновременно, — кандидат на идиотский индекс.
📰 How Long Until We Call AI Agents Data Products
🔗 https://moderndata101.substack.com/p/data-products-as-ai-agents
💡 Вывод: AI-агент в продакшне соответствует всем критериям data product — пользователи, контракты качества, жизненный цикл, обратная связь. Большинство команд запускают агентов как эксперименты и удивляются, почему они деградируют. Обсервабилити ≠ логирование: каждый retry — это измеримое трение, каждый брошенный диалог — невидимый отток. Единственная работающая обратная связь — ручная аннотация разговоров с последующим маппингом паттернов на тикеты. Не дашборды — решения.
❤
4
👍
1
Пост от 29.03.2026 18:16
666
1
42
Роль дата-инженера долгое время определялась через аббревиатуру ETL - Extract, Transform, Load. Извлечь данные из разрозненных источников, привести к единому формату, загрузить в хранилище. Работа понятная, воспроизводимая и всё более автоматизируемая. Когда AI-инструменты научились генерировать пайплайны на уровне уверенного мидла, возник закономерный вопрос: что остаётся у человека?
Ananth Packkildurai, автор рассылки Data Engineering Weekly, предлагает конкретный ответ. По его наблюдению, механическая работа по построению пайплайнов всегда маскировала более важную задачу — управление семантикой данных. Понимание того, что «выручка» в финансовом департаменте и «выручка» в отделе продаж считаются по-разному. Что null в одной системе означает отсутствие информации, а в другой — осознанный выбор пользователя. Что определение «активного клиента» менялось трижды за год, и каждое изменение похоронено где-то в SQL-логике трансформаций.
Вместо ETL предлагается фреймворк ECL - Extract, Contextualize, Link. Извлечение данных остаётся инженерной задачей. Но центр тяжести смещается на этап контекстуализации - придания данным проверяемого семантического значения. Третий элемент, связывание, отвечает за построение устойчивых связей между сущностями из разных систем: клиент в CRM, пользователь в продуктовой базе, событие в аналитике, сессия в системе поддержки.
Архитектурно это предполагает появление нового инфраструктурного компонента - Context Store, версионируемого хранилища семантических определений. Не вики-страницы с описанием полей, а инженерного артефакта, к которому обращаются downstream-системы и AI-агенты, прежде чем работать с данными. Контракты данных при этом перестают быть документацией и становятся исполняемыми ограничениями - по аналогии с интерфейсами в разработке, которые ломают сборку при нарушении.
Это различие критично именно в контексте AI. Когда агент генерирует трансформационный код, он добросовестно реализует любую логику, которую ему задают. Если контракт на входе неоднозначен или не enforce-ится - ошибки становятся системными, а не единичными. Масштаб автоматизации умножает как корректные решения, так и некорректные.
Примечательно, что 53% участников опроса в LinkedIn назвали архитектуру и принятие компромиссных решений тем, что останется за человеком в мире AI-генерируемого кода. Не владение конкретным инструментом и не скорость написания SQL. А способность определить, какие данные заслуживают формализованного контракта, где граница между предписанным и обнаруженным контекстом, и кто в организации несёт ответственность за то, что определение в Context Store корректно.
Дата-инженер в этой модели - не тот, кто перемещает данные. А тот, кто проектирует инфраструктуру их смысла.
https://www.dataengineeringweekly.com/p/data-engineering-after-ai?utm_source=post-email-title&publication_id=73271&post_id=188977018
Ananth Packkildurai, автор рассылки Data Engineering Weekly, предлагает конкретный ответ. По его наблюдению, механическая работа по построению пайплайнов всегда маскировала более важную задачу — управление семантикой данных. Понимание того, что «выручка» в финансовом департаменте и «выручка» в отделе продаж считаются по-разному. Что null в одной системе означает отсутствие информации, а в другой — осознанный выбор пользователя. Что определение «активного клиента» менялось трижды за год, и каждое изменение похоронено где-то в SQL-логике трансформаций.
Вместо ETL предлагается фреймворк ECL - Extract, Contextualize, Link. Извлечение данных остаётся инженерной задачей. Но центр тяжести смещается на этап контекстуализации - придания данным проверяемого семантического значения. Третий элемент, связывание, отвечает за построение устойчивых связей между сущностями из разных систем: клиент в CRM, пользователь в продуктовой базе, событие в аналитике, сессия в системе поддержки.
Архитектурно это предполагает появление нового инфраструктурного компонента - Context Store, версионируемого хранилища семантических определений. Не вики-страницы с описанием полей, а инженерного артефакта, к которому обращаются downstream-системы и AI-агенты, прежде чем работать с данными. Контракты данных при этом перестают быть документацией и становятся исполняемыми ограничениями - по аналогии с интерфейсами в разработке, которые ломают сборку при нарушении.
Это различие критично именно в контексте AI. Когда агент генерирует трансформационный код, он добросовестно реализует любую логику, которую ему задают. Если контракт на входе неоднозначен или не enforce-ится - ошибки становятся системными, а не единичными. Масштаб автоматизации умножает как корректные решения, так и некорректные.
Примечательно, что 53% участников опроса в LinkedIn назвали архитектуру и принятие компромиссных решений тем, что останется за человеком в мире AI-генерируемого кода. Не владение конкретным инструментом и не скорость написания SQL. А способность определить, какие данные заслуживают формализованного контракта, где граница между предписанным и обнаруженным контекстом, и кто в организации несёт ответственность за то, что определение в Context Store корректно.
Дата-инженер в этой модели - не тот, кто перемещает данные. А тот, кто проектирует инфраструктуру их смысла.
https://www.dataengineeringweekly.com/p/data-engineering-after-ai?utm_source=post-email-title&publication_id=73271&post_id=188977018
❤
6
🔥
3
Пост от 27.03.2026 17:06
644
0
6
Традиционная космическая страничка
26 февраля 2025 года NASA запустило зонд Lunar Trailblazer - миссия за $72 млн для картографирования воды на Луне. Через сутки связь с аппаратом была потеряна навсегда. Год спустя NPR через запрос по закону о свободе информации добыл отчёт о причинах.
Причина оказалась обидно простой. Софт ориентации солнечных панелей развернул их на 180 градусов от Солнца. Не частично, не с отклонением - ровно в противоположную сторону. Аппарат построил Lockheed Martin, и комиссия NASA установила, что компания не провела надлежащего тестирования этого ПО перед запуском.
Но убил миссию не один баг. Бортовая система управления неисправностями - та самая, которая должна была спасти аппарат - начала принимать ошибочные решения одно за другим. Каскад. Операторы на Земле теоретически могли бы скорректировать ориентацию вручную, но цепочка софтверных сбоев сначала затруднила, а потом сделала это невозможным.
$72 миллиона потеряны из-за ошибки, которую можно было обнаружить одним интеграционным тестом до старта. Не нужен был ИИ, не нужен был гений. Нужен был человек, который запустил бы симуляцию и посмотрел, куда повернутся панели.
Космос не прощает пропущенных тестов. Впрочем, продакшен тоже.
https://www.npr.org/2026/02/26/nx-s1-5727622/nasa-lunar-trailblazer-moon-new-report-what-went-wrong
26 февраля 2025 года NASA запустило зонд Lunar Trailblazer - миссия за $72 млн для картографирования воды на Луне. Через сутки связь с аппаратом была потеряна навсегда. Год спустя NPR через запрос по закону о свободе информации добыл отчёт о причинах.
Причина оказалась обидно простой. Софт ориентации солнечных панелей развернул их на 180 градусов от Солнца. Не частично, не с отклонением - ровно в противоположную сторону. Аппарат построил Lockheed Martin, и комиссия NASA установила, что компания не провела надлежащего тестирования этого ПО перед запуском.
Но убил миссию не один баг. Бортовая система управления неисправностями - та самая, которая должна была спасти аппарат - начала принимать ошибочные решения одно за другим. Каскад. Операторы на Земле теоретически могли бы скорректировать ориентацию вручную, но цепочка софтверных сбоев сначала затруднила, а потом сделала это невозможным.
$72 миллиона потеряны из-за ошибки, которую можно было обнаружить одним интеграционным тестом до старта. Не нужен был ИИ, не нужен был гений. Нужен был человек, который запустил бы симуляцию и посмотрел, куда повернутся панели.
Космос не прощает пропущенных тестов. Впрочем, продакшен тоже.
https://www.npr.org/2026/02/26/nx-s1-5727622/nasa-lunar-trailblazer-moon-new-report-what-went-wrong
👍
5
🤯
2
Пост от 26.03.2026 18:49
1 047
2
28
Прочитал статью Rahul Garg из Thoughtworks про Context Anchoring - и она навела меня на мысли, которые выходят далеко за пределы самой статьи.
Обратите внимание на любопытный момент: индустрия добралась до вопроса «что такое контекст и где его границы». Не в философском смысле — в инженерном. Люди буквально проектируют системы управления контекстом для AI-ассистентов. Но чтобы делать это эффективно, вам, оказывается, нужно сначала понять, а что такое контекст в вашей собственной жизни. Как вы сами передаёте его коллеге, который подключился к задаче на третий день? Как вы сами решаете, что важно запомнить, а что можно забыть? Это совершенно не очевидный термин, хотя мы пользуемся им каждый день.
Второй момент, который меня не перестаёт удивлять. Мы сами создали LLM. Казалось бы, должно быть довольно понятно, как они работают. Но нет - мы проводим эксперименты и обнаруживаем неожиданные вещи. Например, что модель помнит решение, но забывает причину этого решения. Что рассуждения деградируют быстрее фактов. Что автоматическое сжатие диалога убивает именно то, что имело наибольшую ценность - объяснение «почему». Мы исследуем собственное изобретение как чёрный ящик, и результаты нас удивляют. Есть в этом что-то ироничное.
Статья предлагает простое решение: вынести контекст решений наружу, в живой документ, который переживает сессию. Концепция здравая, но давайте честно - все текущие решения для работы LLM с контекстом довольно неказистые. RAG, векторные базы, сжатие диалогов - всё это попытки угадать, что именно понадобится модели на следующем шаге. Тут отдельная мега-задача, до которой индустрия по-настоящему ещё не добралась.
И вот что меня действительно зацепило в статье - ссылка на Architecture Decision Records. Автор описывает feature-документ как «живой ADR». А мы у себя в командах сейчас не просто развиваем практику ADR - мы обнаружили, что агентам эти записи помогают колоссально. Код показывает, что было реализовано. ADR показывает, что было отвергнуто и почему. И когда агент видит эту историю решений, он работает в рамках ваших практик и стандартов, а не «в вакууме».
По сути, ADR стали интерфейсом между человеческой инженерной культурой и AI-агентами. Такого применения Майкл Найгард в 2011 году точно не предполагал :)
https://martinfowler.com/articles/reduce-friction-ai/context-anchoring.html
Обратите внимание на любопытный момент: индустрия добралась до вопроса «что такое контекст и где его границы». Не в философском смысле — в инженерном. Люди буквально проектируют системы управления контекстом для AI-ассистентов. Но чтобы делать это эффективно, вам, оказывается, нужно сначала понять, а что такое контекст в вашей собственной жизни. Как вы сами передаёте его коллеге, который подключился к задаче на третий день? Как вы сами решаете, что важно запомнить, а что можно забыть? Это совершенно не очевидный термин, хотя мы пользуемся им каждый день.
Второй момент, который меня не перестаёт удивлять. Мы сами создали LLM. Казалось бы, должно быть довольно понятно, как они работают. Но нет - мы проводим эксперименты и обнаруживаем неожиданные вещи. Например, что модель помнит решение, но забывает причину этого решения. Что рассуждения деградируют быстрее фактов. Что автоматическое сжатие диалога убивает именно то, что имело наибольшую ценность - объяснение «почему». Мы исследуем собственное изобретение как чёрный ящик, и результаты нас удивляют. Есть в этом что-то ироничное.
Статья предлагает простое решение: вынести контекст решений наружу, в живой документ, который переживает сессию. Концепция здравая, но давайте честно - все текущие решения для работы LLM с контекстом довольно неказистые. RAG, векторные базы, сжатие диалогов - всё это попытки угадать, что именно понадобится модели на следующем шаге. Тут отдельная мега-задача, до которой индустрия по-настоящему ещё не добралась.
И вот что меня действительно зацепило в статье - ссылка на Architecture Decision Records. Автор описывает feature-документ как «живой ADR». А мы у себя в командах сейчас не просто развиваем практику ADR - мы обнаружили, что агентам эти записи помогают колоссально. Код показывает, что было реализовано. ADR показывает, что было отвергнуто и почему. И когда агент видит эту историю решений, он работает в рамках ваших практик и стандартов, а не «в вакууме».
По сути, ADR стали интерфейсом между человеческой инженерной культурой и AI-агентами. Такого применения Майкл Найгард в 2011 году точно не предполагал :)
https://martinfowler.com/articles/reduce-friction-ai/context-anchoring.html
👍
6
✍
2
🤔
1
Пост от 26.03.2026 00:05
789
0
2
Друзья, 7 апреля в Центре событий РБК пройдёт 15-й форум FINNEXT — одна из немногих площадок, где банки, финтех, ритейл и регуляторы разговаривают на одном языке и про конкретику, а не про «стратегические горизонты».
В этом году программа собрана вокруг вещей, которые реально определят ландшафт ближайших лет. Payment Battle — про борьбу за последнюю платёжную милю: QR-коды vs биометрия vs pay-сервисы, трансграничные расчёты без SWIFT, роль ЦФА и стейблкоинов в ВЭД. AI-Economy — про переход от AI-ассистентов к автономным агентным системам и мультиагентным архитектурам в финансах. И Banking as a Platform — про то, как банки становятся невидимыми операционными системами, а не приложениями с логотипом.
В спикерах — Игорь Маслов (CTO Т-Банка), Кирилл Когтев, исполнительный вице-президент Газпромбанка), Алексей Щавелёв (старший вице-президент ПСБ) и другие.
Отдельная история — Премия FINNEXT. Третий год подряд, и это возможность узнать о кейсах цифровой трансформации, которые дали измеримый результат, а не остались в презентациях. Шорт-лист сформирован - уже можно ознакомиться с кейсами номинантов, сделать ставки на победителя и прийти поболеть за своего фаворита.
Детали программы и регистрация — на сайте мероприятия.
https://finnext.ru/?rs=p_finnext2026_cdo
В этом году программа собрана вокруг вещей, которые реально определят ландшафт ближайших лет. Payment Battle — про борьбу за последнюю платёжную милю: QR-коды vs биометрия vs pay-сервисы, трансграничные расчёты без SWIFT, роль ЦФА и стейблкоинов в ВЭД. AI-Economy — про переход от AI-ассистентов к автономным агентным системам и мультиагентным архитектурам в финансах. И Banking as a Platform — про то, как банки становятся невидимыми операционными системами, а не приложениями с логотипом.
В спикерах — Игорь Маслов (CTO Т-Банка), Кирилл Когтев, исполнительный вице-президент Газпромбанка), Алексей Щавелёв (старший вице-президент ПСБ) и другие.
Отдельная история — Премия FINNEXT. Третий год подряд, и это возможность узнать о кейсах цифровой трансформации, которые дали измеримый результат, а не остались в презентациях. Шорт-лист сформирован - уже можно ознакомиться с кейсами номинантов, сделать ставки на победителя и прийти поболеть за своего фаворита.
Детали программы и регистрация — на сайте мероприятия.
https://finnext.ru/?rs=p_finnext2026_cdo
👍
2
Пост от 25.03.2026 22:41
669
0
7
VTORNIK.Вечер #6
31 марта, с 19:00 до 21:00 мы рады вас пригласить на наш новый митап. В этот раз он пройдет как обычно офлайн, но на новой площадке (!). В этот раз вас ждет следующая программа:
————————————
1️⃣ Что не так с ИИ-проектами?
Согласно исследованию MIT, 95% ИИ проектов оканчиваются неудачей. Исходя из своего богатого опыта проектного управления и опыта работы с ИИ Юлия перечислит типовые ошибки и даст рекомендации как их избежать.
Спикер: Юлия Богачева, Еx-CPO AI-продуктов, Холдинг Т1
В прошлом CDO в Сбере и Член Правления и председатель R&D комитета в Ассоциации Больших Данных.
2️⃣ Детерминированный AI: ĸаĸ заставить агентов писать поддерживаемый ĸод
Как создать AI сотрудника, стандарты для их работы, собрать команду и организовать их работу.
Спикер: Сергей Спевак, AI-архитектор и Архитектор программных решений, Прогресс Терра
В прошлом IT-директор в «Снежной Королеве», CDO в Gipfel, ведущий архитектор домена в билайне, архитектор платформы «Самозанятые РФ»
————————————
📍 Место проведения: Офис наших партнеров — компании ГК «Солар», адрес: м. Охотный ряд / Площадь Революции / Театральная / Александровский сад, Никитский пер. 7с1, Москва, 2-й этаж.
Мероприятие бесплатное. Регистрация обязательна. Количество мест ограничено.
Будем рады всех видеть!
31 марта, с 19:00 до 21:00 мы рады вас пригласить на наш новый митап. В этот раз он пройдет как обычно офлайн, но на новой площадке (!). В этот раз вас ждет следующая программа:
————————————
1️⃣ Что не так с ИИ-проектами?
Согласно исследованию MIT, 95% ИИ проектов оканчиваются неудачей. Исходя из своего богатого опыта проектного управления и опыта работы с ИИ Юлия перечислит типовые ошибки и даст рекомендации как их избежать.
Спикер: Юлия Богачева, Еx-CPO AI-продуктов, Холдинг Т1
В прошлом CDO в Сбере и Член Правления и председатель R&D комитета в Ассоциации Больших Данных.
2️⃣ Детерминированный AI: ĸаĸ заставить агентов писать поддерживаемый ĸод
Как создать AI сотрудника, стандарты для их работы, собрать команду и организовать их работу.
Спикер: Сергей Спевак, AI-архитектор и Архитектор программных решений, Прогресс Терра
В прошлом IT-директор в «Снежной Королеве», CDO в Gipfel, ведущий архитектор домена в билайне, архитектор платформы «Самозанятые РФ»
————————————
📍 Место проведения: Офис наших партнеров — компании ГК «Солар», адрес: м. Охотный ряд / Площадь Революции / Театральная / Александровский сад, Никитский пер. 7с1, Москва, 2-й этаж.
Мероприятие бесплатное. Регистрация обязательна. Количество мест ограничено.
Будем рады всех видеть!
👍
6
🐳
2
❤
1