Инструменты
Каталог TGAds
Мониторинг
Детальная статистика
Анализ аудитории
Бот аналитики
Полезная информация
Инструкция Telemetr
Документация к API
Чат Telemetr
Не попадитесь на накрученные каналы! Узнайте, не накручивает ли канал просмотры или
подписчиков
Проверить канал на накрутку
Телеграм канал «Клуб CDO»
Подписчики
Всего
3 729
Сегодня
-1
Просмотров на пост
Всего
608
ER
Общий
14.92%
Суточный
13.1%
Динамика публикаций
Telemetr - сервис глубокой аналитики
телеграм-каналов
телеграм-каналов
Получите подробную информацию о каждом канале
Отберите самые эффективные каналы для
рекламных размещений, по приросту подписчиков,
ER, количеству просмотров на пост и другим метрикам
рекламных размещений, по приросту подписчиков,
ER, количеству просмотров на пост и другим метрикам
Анализируйте рекламные посты
и креативы
и креативы
Узнайте какие посты лучше сработали,
а какие хуже, даже если их давно удалили
а какие хуже, даже если их давно удалили
Оценивайте эффективность тематики и контента
Узнайте, какую тематику лучше не рекламировать
на канале, а какая зайдет на ура
на канале, а какая зайдет на ура
Показано 7 из 2 535 постов
Смотреть все посты
Пост от 04.04.2026 12:15
43
0
1
Дайджест статей
📰 The Missing Context Layer for AI Agents Over Business Data
🔗 https://medium.com/wrenai/the-missing-context-layer-for-ai-agents-over-business-data-03849b72f73d
💡 Вывод: Авторы Wren Engine переосмыслили семантический слой как «контекстный движок» для AI-агентов над бизнес-данными — аргумент в пользу того, что проблема NL→SQL не в модели, а в отсутствии правильного контекстного слоя между агентом и данными. (по метаданным — paywall)
📰 SQL Is Quietly Taking Over Data Engineering — Again
🔗 https://medium.com/towards-data-engineering/sql-is-quietly-taking-over-data-engineering-again-1dec44ca2c7d
💡 Вывод: SQL возвращается как де-факто стандарт современной data engineering через dbt, DuckDB, MotherDuck и SQL-first платформы — Python-пайплайны уступают место SQL там, где раньше его считали недостаточным. (по метаданным — paywall)
📰 Data Gravity и отравление выборки
🔗 https://habr.com/ru/companies/otus/articles/1012868/
💡 Вывод: Три системные угрозы ML-проектов — инерция данных (Data Gravity), намеренное и случайное отравление выборки (Data Poisoning по OWASP ML02:2023) и эффект матроса (ложные корреляции) — не решаются ростом объёма данных; решаются они версионированием, статистическим мониторингом и отношением к данным как к инженерному артефакту, а не бесплатному ресурсу.
📰 Лучшие YouTube-каналы по Data и Product Analytics
🔗 https://habr.com/ru/articles/1018610/
💡 Вывод: Подборка каналов (Alex The Analyst, Luke Barousse, Amplitude, Reforge и др.) — материал уровня «начинающий аналитик ищет что посмотреть», для CDO-аудитории ценности почти нет.
📰 Data as Code на практике: ArchDB
🔗 https://habr.com/ru/articles/1018586/
💡 Вывод: ArchDB — open-source DSL для декларативного описания схем БД с модульностью, множественным наследованием шаблонов и контролем версий; практически применим для команд, у которых схема базы живёт в Confluence и устаревает быстрее, чем обновляется — переход с DBML потребует минимальных правок.
📰 BI-аналитика или Excel: где вести аналитику компаниям?
🔗 https://habr.com/ru/articles/1018058/
💡 Вывод: По данным «КОРУС Консалтинг», 43% компаний до сих пор строят аналитику в Excel — статья описывает типичный путь к BI через боль с актуальностью данных, ошибками формул и временны́м долгом на сбор отчётности; реальный кейс — сокращение времени на аналитику с 15–20 до 2–3 часов в неделю через Yandex DataLens с окупаемостью за 4 месяца.
📰 OLAP-кубы в финансах: превращаем бюджетирование в управляемую систему
🔗 https://habr.com/ru/articles/1017470/
💡 Вывод: Статья чётко артикулирует разницу между «личной автоматизацией» (Power Pivot) и корпоративной аналитической инфраструктурой (OLAP): четыре сценария — многоверсионное планирование, консолидация ЦФО, двунаправленное планирование и скользящие прогнозы — реализуемы только на OLAP-платформе, а не в Excel, и именно это меняет роль финансиста с «составителя отчётов» на аналитика.
📰 Как стать аналитиком данных и сколько можно зарабатывать
🔗 https://habr.com/ru/companies/habr_career/articles/1017412/
💡 Вывод: Медианная зарплата дата-аналитика в России — 171 тыс. руб., сеньор получает 283 тыс., лид — 380 тыс.; рынок перегрет кандидатами с сертификатами без практики — по словам руководителя аналитиков Яндекса, рабочий путь в профессию: применять анализ данных там, где уже работаешь, не ждать «правильного» первого места.
📰 ML/AI в системе мониторинга: прогнозирование и предотвращение инцидентов
🔗 https://habr.com/ru/companies/sberbank/articles/1015336/
💡 Вывод: Сбер описывает production-реализацию ML predict-модели с горизонтом 15 минут на инфраструктурных, прикладных и бизнес-метриках — 80% точности достаточно для практического применения, модель обучается на ноутбуке при наличии 5 недель исторических данных, но требует переобучения минимум раз в квартал при изменении инфраструктуры или бизнес-паттернов.
📰 Reference Data Management по-русски: НСИ и почему это не всегда RDM
🔗 https://habr.com/ru/companies/datasapience/articles/1012404/
📰 The Missing Context Layer for AI Agents Over Business Data
🔗 https://medium.com/wrenai/the-missing-context-layer-for-ai-agents-over-business-data-03849b72f73d
💡 Вывод: Авторы Wren Engine переосмыслили семантический слой как «контекстный движок» для AI-агентов над бизнес-данными — аргумент в пользу того, что проблема NL→SQL не в модели, а в отсутствии правильного контекстного слоя между агентом и данными. (по метаданным — paywall)
📰 SQL Is Quietly Taking Over Data Engineering — Again
🔗 https://medium.com/towards-data-engineering/sql-is-quietly-taking-over-data-engineering-again-1dec44ca2c7d
💡 Вывод: SQL возвращается как де-факто стандарт современной data engineering через dbt, DuckDB, MotherDuck и SQL-first платформы — Python-пайплайны уступают место SQL там, где раньше его считали недостаточным. (по метаданным — paywall)
📰 Data Gravity и отравление выборки
🔗 https://habr.com/ru/companies/otus/articles/1012868/
💡 Вывод: Три системные угрозы ML-проектов — инерция данных (Data Gravity), намеренное и случайное отравление выборки (Data Poisoning по OWASP ML02:2023) и эффект матроса (ложные корреляции) — не решаются ростом объёма данных; решаются они версионированием, статистическим мониторингом и отношением к данным как к инженерному артефакту, а не бесплатному ресурсу.
📰 Лучшие YouTube-каналы по Data и Product Analytics
🔗 https://habr.com/ru/articles/1018610/
💡 Вывод: Подборка каналов (Alex The Analyst, Luke Barousse, Amplitude, Reforge и др.) — материал уровня «начинающий аналитик ищет что посмотреть», для CDO-аудитории ценности почти нет.
📰 Data as Code на практике: ArchDB
🔗 https://habr.com/ru/articles/1018586/
💡 Вывод: ArchDB — open-source DSL для декларативного описания схем БД с модульностью, множественным наследованием шаблонов и контролем версий; практически применим для команд, у которых схема базы живёт в Confluence и устаревает быстрее, чем обновляется — переход с DBML потребует минимальных правок.
📰 BI-аналитика или Excel: где вести аналитику компаниям?
🔗 https://habr.com/ru/articles/1018058/
💡 Вывод: По данным «КОРУС Консалтинг», 43% компаний до сих пор строят аналитику в Excel — статья описывает типичный путь к BI через боль с актуальностью данных, ошибками формул и временны́м долгом на сбор отчётности; реальный кейс — сокращение времени на аналитику с 15–20 до 2–3 часов в неделю через Yandex DataLens с окупаемостью за 4 месяца.
📰 OLAP-кубы в финансах: превращаем бюджетирование в управляемую систему
🔗 https://habr.com/ru/articles/1017470/
💡 Вывод: Статья чётко артикулирует разницу между «личной автоматизацией» (Power Pivot) и корпоративной аналитической инфраструктурой (OLAP): четыре сценария — многоверсионное планирование, консолидация ЦФО, двунаправленное планирование и скользящие прогнозы — реализуемы только на OLAP-платформе, а не в Excel, и именно это меняет роль финансиста с «составителя отчётов» на аналитика.
📰 Как стать аналитиком данных и сколько можно зарабатывать
🔗 https://habr.com/ru/companies/habr_career/articles/1017412/
💡 Вывод: Медианная зарплата дата-аналитика в России — 171 тыс. руб., сеньор получает 283 тыс., лид — 380 тыс.; рынок перегрет кандидатами с сертификатами без практики — по словам руководителя аналитиков Яндекса, рабочий путь в профессию: применять анализ данных там, где уже работаешь, не ждать «правильного» первого места.
📰 ML/AI в системе мониторинга: прогнозирование и предотвращение инцидентов
🔗 https://habr.com/ru/companies/sberbank/articles/1015336/
💡 Вывод: Сбер описывает production-реализацию ML predict-модели с горизонтом 15 минут на инфраструктурных, прикладных и бизнес-метриках — 80% точности достаточно для практического применения, модель обучается на ноутбуке при наличии 5 недель исторических данных, но требует переобучения минимум раз в квартал при изменении инфраструктуры или бизнес-паттернов.
📰 Reference Data Management по-русски: НСИ и почему это не всегда RDM
🔗 https://habr.com/ru/companies/datasapience/articles/1012404/
Пост от 04.04.2026 12:15
42
0
1
💡 Вывод: В российской практике НСИ исторически стало означать RDM + часть MDM + элементы DQ в одном флаконе — это создаёт ошибочные ожидания от систем и приводит к выбору «универсального» решения, которое делает всё, но плохо; правильный подход — разделить задачи и подбирать инструмент под каждую.
Пост от 03.04.2026 09:15
424
0
16
На прошлой неделе послушал доклад Анны Байдиной из Revolut - технического лидера их voice team. Тема: dialogue management в голосовых агентах. Казалось бы, нишевая история. На практике - хороший срез того, где реально ломается большинство голосовых продуктов.
Первый инсайт, который стоит зафиксировать: голос и текст - разные домены не по UX, а по физике. В текстовом чате лишние 3–4 секунды на ответ - нормально. В голосе те же 3–4 секунды - руинированная сессия и желание попросить живого оператора. Revolut ориентируется на P50 latency < 2 секунд. Это не KPI, это порог между "работает" и "не работает".
Второй момент: большинство команд, которые строят голосовых агентов, думают что задача - это STT + LLM + TTS. Сложили три модели — готово. Но есть четвёртый слой, без которого первые три не имеют смысла. Это dialogue management.
Что это такое? Это слой управления разговором, который решает один вопрос: сейчас говорить или слушать? Если STT — это уши, LLM — мозг, TTS — рот, то dialogue manager — это личность агента. Он определяет, перебивает ли агент пользователя, отвечает ли на правильный вопрос, или зависает в паузе и теряет нить.
Конкретный пример из доклада: пользователь говорит "я хочу купить... [пауза] ...пиво на 150 человек". Без dialogue management агент слышит паузу после "купить", решает что фраза закончена, отвечает на неполный запрос. С dialogue management - понимает, что пауза внутри фразы, ждёт конца, отвечает по существу.
Технически это решается через turn-taking - механизм определения конца реплики пользователя. Простое решение: VAD (Voice Activity Detector) + таймер. Молчание 700 мс — конец хода. Проблема: 700 мс из бюджета в 2 секунды — это огромная цена. Плюс ложные срабатывания на паузы внутри фраз.
Более сильное решение — аудионативные модели типа SmartTurn. Они используют те же сигналы, которые использует человек в живом разговоре: падение питча, снижение энергии, замедление ритма речи. Transformer-архитектура (encoder от Whisper) + классификатор. Быстрее и точнее VAD-based подхода. Revolut использует его в продакшене как основной механизм, с VAD-based fallback на 2 секунды.
Ещё одна деталь, которую легко пропустить: Revolut не смог просто переиспользовать свой существующий чатбот LLM внутри голосового агента. Архитектурно они сделали отдельный LLM + два вызова к chatbot API для получения ответов — именно чтобы вписаться в латентный бюджет. То есть задача оказалась не "взять готовый AI и добавить голос", а переосмыслить всю цепочку под жёсткое latency constraint.
Это честная инженерная история: не про то какая модель умнее, а про то как архитектура определяет что вообще возможно.
https://www.youtube.com/watch?v=onIFwG-5tuE
Первый инсайт, который стоит зафиксировать: голос и текст - разные домены не по UX, а по физике. В текстовом чате лишние 3–4 секунды на ответ - нормально. В голосе те же 3–4 секунды - руинированная сессия и желание попросить живого оператора. Revolut ориентируется на P50 latency < 2 секунд. Это не KPI, это порог между "работает" и "не работает".
Второй момент: большинство команд, которые строят голосовых агентов, думают что задача - это STT + LLM + TTS. Сложили три модели — готово. Но есть четвёртый слой, без которого первые три не имеют смысла. Это dialogue management.
Что это такое? Это слой управления разговором, который решает один вопрос: сейчас говорить или слушать? Если STT — это уши, LLM — мозг, TTS — рот, то dialogue manager — это личность агента. Он определяет, перебивает ли агент пользователя, отвечает ли на правильный вопрос, или зависает в паузе и теряет нить.
Конкретный пример из доклада: пользователь говорит "я хочу купить... [пауза] ...пиво на 150 человек". Без dialogue management агент слышит паузу после "купить", решает что фраза закончена, отвечает на неполный запрос. С dialogue management - понимает, что пауза внутри фразы, ждёт конца, отвечает по существу.
Технически это решается через turn-taking - механизм определения конца реплики пользователя. Простое решение: VAD (Voice Activity Detector) + таймер. Молчание 700 мс — конец хода. Проблема: 700 мс из бюджета в 2 секунды — это огромная цена. Плюс ложные срабатывания на паузы внутри фраз.
Более сильное решение — аудионативные модели типа SmartTurn. Они используют те же сигналы, которые использует человек в живом разговоре: падение питча, снижение энергии, замедление ритма речи. Transformer-архитектура (encoder от Whisper) + классификатор. Быстрее и точнее VAD-based подхода. Revolut использует его в продакшене как основной механизм, с VAD-based fallback на 2 секунды.
Ещё одна деталь, которую легко пропустить: Revolut не смог просто переиспользовать свой существующий чатбот LLM внутри голосового агента. Архитектурно они сделали отдельный LLM + два вызова к chatbot API для получения ответов — именно чтобы вписаться в латентный бюджет. То есть задача оказалась не "взять готовый AI и добавить голос", а переосмыслить всю цепочку под жёсткое latency constraint.
Это честная инженерная история: не про то какая модель умнее, а про то как архитектура определяет что вообще возможно.
https://www.youtube.com/watch?v=onIFwG-5tuE
👍
7
🔥
2
Пост от 02.04.2026 18:57
451
1
26
Мы видим AI везде, кроме статистики
Сегодня обсуждали парадокс, который, имхо, объясняет 90% разочарований от AI.
Солоу, нобелевский лауерат по экономике, как-то заметил:
Мы видим компьютеры повсюду, только не в показателях производительности
Компании массово покупали компьютеры, но производительность не росла. Звучит знакомо?
Собственно, тот же парадокс сейчас: Goldman Sachs пишет, что на макроуровне пока нет значимой связи между внедрением AI и производительностью. До 95% AI пилотов не проходят cost-benefit. CEO покупают подписки, но ROI не видно.
J-Curve theory объясняет почему. Когда приходит новая GPT (general-purpose technology) - электричество, компьютеры, AI - мы входим в фазу инвестиций, в которой производительность ПАДАЕТ. Не потому что технология не работает, а потому что:
1) Нужно переучиваться, нужно менять процессы, это вызывает трение. Мы начинаем покупать всем Claude — затраты растут. Тратим время на обучение — output временно падает. В отчётности это выглядит как убыток, потому что реорганизация, переобучение — это всё учитывается как операционные затраты, а не как инвестиции. Причем это не только про бухучет, лучшие умы и значительные ресурсы перенаправляются на создание новой инфраструктуры и процессов.
2) Лаг между adoption и результатом. С электричеством было ~40 лет. С компьютерами ~25. Фабрики сначала просто воткнули электромоторы вместо паровых — ноль эффекта. Просто замена инструмента без перестройки процессов не дает почти ничего - и это имхо именно то, что происходит со многими сейчас. Рост тогда пришёл когда полностью перепроектировали фабрику, поняли что можно подвести электричество к каждому рабочему месту и тп.
3) Может быть, производительность и растёт — но измеряемая производительность падает. Ты лично пишешь код в 3 раза быстрее, но на уровне компании это пока не видно. Цепочка от кода до клиента длинная, и AI пока ускорил только один кусок. Как сказал недавно один участник курса: "Мы построили фабрику софтверную, но теперь нам нужны заказы". Очень напоминает Цель-2 Голдратта
Вот что меня зацепило: из-за этого разрыва могут быть поспешные выводы о том, что технология не работает. И это бьёт сильнее по большим компаниям — чем больше людей и процессов, тем меньше рост индивидуальной производительности влияет на общий результат. Устранение узкого места в одном месте не решает проблему в другом. Прям теория ограничений.
А у маленьких команд — наоборот. Один человек с Claude Code может заменить целый отдел — и это сразу видно в выручке, а не через 20 лет. У нас 5 человек делают то, на что обычно нужно 12-15. Не потому что мы гении — потому что нам меньше перестраивать.
Имхо, хороший майндсет, который стоит держать в голове:
- Если ваш CEO говорит «попробовали AI, не работает» — покажите ему J-Curve. Скорее всего, вы в investment phase и выводы преждевременные
- Если вы маленькая команда — у вас преимущество. Пока корпорации пытаются «масштабировать AI adoption», вы просто работаете быстрее
На эту тему очень понравился, кстати, ресурс jobsdata.ai (скриншот в аттаче) — чувак собирает все релевантные статьи и исследования на тему влияния AI на рынок труда, плюс есть чатбот, которому можно задать вопросы по своей индустрии.
Сегодня обсуждали парадокс, который, имхо, объясняет 90% разочарований от AI.
Солоу, нобелевский лауерат по экономике, как-то заметил:
Мы видим компьютеры повсюду, только не в показателях производительности
Компании массово покупали компьютеры, но производительность не росла. Звучит знакомо?
Собственно, тот же парадокс сейчас: Goldman Sachs пишет, что на макроуровне пока нет значимой связи между внедрением AI и производительностью. До 95% AI пилотов не проходят cost-benefit. CEO покупают подписки, но ROI не видно.
J-Curve theory объясняет почему. Когда приходит новая GPT (general-purpose technology) - электричество, компьютеры, AI - мы входим в фазу инвестиций, в которой производительность ПАДАЕТ. Не потому что технология не работает, а потому что:
1) Нужно переучиваться, нужно менять процессы, это вызывает трение. Мы начинаем покупать всем Claude — затраты растут. Тратим время на обучение — output временно падает. В отчётности это выглядит как убыток, потому что реорганизация, переобучение — это всё учитывается как операционные затраты, а не как инвестиции. Причем это не только про бухучет, лучшие умы и значительные ресурсы перенаправляются на создание новой инфраструктуры и процессов.
2) Лаг между adoption и результатом. С электричеством было ~40 лет. С компьютерами ~25. Фабрики сначала просто воткнули электромоторы вместо паровых — ноль эффекта. Просто замена инструмента без перестройки процессов не дает почти ничего - и это имхо именно то, что происходит со многими сейчас. Рост тогда пришёл когда полностью перепроектировали фабрику, поняли что можно подвести электричество к каждому рабочему месту и тп.
3) Может быть, производительность и растёт — но измеряемая производительность падает. Ты лично пишешь код в 3 раза быстрее, но на уровне компании это пока не видно. Цепочка от кода до клиента длинная, и AI пока ускорил только один кусок. Как сказал недавно один участник курса: "Мы построили фабрику софтверную, но теперь нам нужны заказы". Очень напоминает Цель-2 Голдратта
Вот что меня зацепило: из-за этого разрыва могут быть поспешные выводы о том, что технология не работает. И это бьёт сильнее по большим компаниям — чем больше людей и процессов, тем меньше рост индивидуальной производительности влияет на общий результат. Устранение узкого места в одном месте не решает проблему в другом. Прям теория ограничений.
А у маленьких команд — наоборот. Один человек с Claude Code может заменить целый отдел — и это сразу видно в выручке, а не через 20 лет. У нас 5 человек делают то, на что обычно нужно 12-15. Не потому что мы гении — потому что нам меньше перестраивать.
Имхо, хороший майндсет, который стоит держать в голове:
- Если ваш CEO говорит «попробовали AI, не работает» — покажите ему J-Curve. Скорее всего, вы в investment phase и выводы преждевременные
- Если вы маленькая команда — у вас преимущество. Пока корпорации пытаются «масштабировать AI adoption», вы просто работаете быстрее
На эту тему очень понравился, кстати, ресурс jobsdata.ai (скриншот в аттаче) — чувак собирает все релевантные статьи и исследования на тему влияния AI на рынок труда, плюс есть чатбот, которому можно задать вопросы по своей индустрии.
Изображение
👍
7
❤
1
Пост от 02.04.2026 11:04
544
1
18
Коллеги, обратите внимание на мероприятие
Как использовать AI для анализа метаданных в СУБД и BI: практика применения LLM и RAG 🤖
Во многих компаниях data catalog уже внедрен, но не работает как инструмент. Метаданные устаревают, доверие к данным падает, аналитики продолжают искать информацию вручную, а команда DWH остается перегруженной.
📆 9 апреля в 11:00 (МСК) пройдёт бесплатный онлайн-вебинар «Как использовать AI для анализа метаданных в СУБД и BI: практика применения LLM и RAG», где вы узнаете, как изменить этот подход с помощью AI.
👨💻 Спикер: Павел Хамрин — руководитель AI-направления Lasmart. Более 10 лет в аналитике и DWH.
В программе вебинара:
— почему data catalog не работает на практике: неактуальные метаданные, отсутствие доверия, перегрузка команды;
— как LLM автоматизирует описание таблиц, дашбордов и бизнес-логики без ручной поддержки;
— как работает RAG для поиска данных, контекста и анализа связей (data lineage);
— архитектура решения и roadmap внедрения без перестройки текущих систем.
Кому будет полезно:
Data-инженерам, CTO, CDO, Head of BI и DWH, Data-аналитикам и Data Scientist
🔗 Регистрация по ссылке
Как использовать AI для анализа метаданных в СУБД и BI: практика применения LLM и RAG 🤖
Во многих компаниях data catalog уже внедрен, но не работает как инструмент. Метаданные устаревают, доверие к данным падает, аналитики продолжают искать информацию вручную, а команда DWH остается перегруженной.
📆 9 апреля в 11:00 (МСК) пройдёт бесплатный онлайн-вебинар «Как использовать AI для анализа метаданных в СУБД и BI: практика применения LLM и RAG», где вы узнаете, как изменить этот подход с помощью AI.
👨💻 Спикер: Павел Хамрин — руководитель AI-направления Lasmart. Более 10 лет в аналитике и DWH.
В программе вебинара:
— почему data catalog не работает на практике: неактуальные метаданные, отсутствие доверия, перегрузка команды;
— как LLM автоматизирует описание таблиц, дашбордов и бизнес-логики без ручной поддержки;
— как работает RAG для поиска данных, контекста и анализа связей (data lineage);
— архитектура решения и roadmap внедрения без перестройки текущих систем.
Кому будет полезно:
Data-инженерам, CTO, CDO, Head of BI и DWH, Data-аналитикам и Data Scientist
🔗 Регистрация по ссылке
👍
3
Пост от 02.04.2026 09:54
165
1
2
Коллеги, обратите внимание на мероприятие
Большинство компаний сейчас проходят одну и ту же стадию: бюджет на ИИ выделен, пилот запущен, через полгода — тишина. Не провал, не успех, просто "не взлетело". И никто особо не понимает почему.
Команда Loginom собрала вебинар с говорящим названием — "Как потратить бюджет на ИИ и не добиться ничего". Не мотивационный контент про то, как ИИ изменит ваш бизнес, а разбор по существу: почему LLM-проекты умирают не от плохой технологии, а от неправильной архитектуры аналитических процессов и отсутствия данных, которым можно доверять.
Разберут три вещи, которые реально стоит знать перед тем как подписывать бюджет на ИИ-инициативы:
— где LLM работают, а где создают иллюзию работы
— как выстроить архитектуру, при которой инвестиции не превращаются в дорогой эксперимент
— как получать от ИИ воспроизводимые результаты, а не красивые демо
Спикеры — директор Loginom Алексей Арустамов и архитектор аналитических систем Евгений Стучалкин.
Для тех, кто уже внедряет или планирует внедрять ИИ в аналитику — и хочет понять, что реально работает, а что хорошо выглядит в презентациях.
Регистрация: https://loginom.ru/announce/webinar-ai-without-illusions?utm_source=tg-lg&utm_medium=post&utm_campaign=webinar-ai
Большинство компаний сейчас проходят одну и ту же стадию: бюджет на ИИ выделен, пилот запущен, через полгода — тишина. Не провал, не успех, просто "не взлетело". И никто особо не понимает почему.
Команда Loginom собрала вебинар с говорящим названием — "Как потратить бюджет на ИИ и не добиться ничего". Не мотивационный контент про то, как ИИ изменит ваш бизнес, а разбор по существу: почему LLM-проекты умирают не от плохой технологии, а от неправильной архитектуры аналитических процессов и отсутствия данных, которым можно доверять.
Разберут три вещи, которые реально стоит знать перед тем как подписывать бюджет на ИИ-инициативы:
— где LLM работают, а где создают иллюзию работы
— как выстроить архитектуру, при которой инвестиции не превращаются в дорогой эксперимент
— как получать от ИИ воспроизводимые результаты, а не красивые демо
Спикеры — директор Loginom Алексей Арустамов и архитектор аналитических систем Евгений Стучалкин.
Для тех, кто уже внедряет или планирует внедрять ИИ в аналитику — и хочет понять, что реально работает, а что хорошо выглядит в презентациях.
Регистрация: https://loginom.ru/announce/webinar-ai-without-illusions?utm_source=tg-lg&utm_medium=post&utm_campaign=webinar-ai
Изображение
👍
1
Пост от 02.04.2026 07:19
487
1
6
А пока космический корабль Orion продолжает свой полет, давайте посмотрим на фотографии запуска ракеты SLS в рамках миссии Artemis II от фотографов из Космического центра имени Кеннеди📸
Взлет🚀
#nasa #orion #sls #artemis #artemis2
Взлет🚀
#nasa #orion #sls #artemis #artemis2
👍
4
❤
1