Друзья, привет! Небольшой анонс от нашей редации. Мы хотим что бы этот канал был про управление данными, про инженирию данных и подобные инженерные технологические вещи.
Тем не менее современные реалии так же требуют уделять все больше внимания ИИ в части его трансформации, бизнес применения и связаных с ними вещами.
Поэтому мы вместе с командой СберТеха запускаем новый проект: Телеграм-канал AI Inside.
Он станет точкой притяжения всех, кто смотрит на ИИ как на рабочий инструмент, а не на хайп. Мы фокусируемся на практическом применении искусственного интеллекта в бизнесе.
Что вас ждет в AI Inside:
🔹 Глубокие разборы реальных кейсов внедрения ИИ-инструментов
🔹 Анализ технологий без воды, с фокусом на измеримый результат
🔹 Инсайды, которые помогут принимать взвешенные решения по внедрению ИИ
Мы создаем пространство для глубокого, профессионального разговора о рабочих инструментах и подходах, которые уже доказали свою эффективность.
Присоединяйтесь к каналу! Буду рад видеть вас там!
Тем не менее современные реалии так же требуют уделять все больше внимания ИИ в части его трансформации, бизнес применения и связаных с ними вещами.
Поэтому мы вместе с командой СберТеха запускаем новый проект: Телеграм-канал AI Inside.
Он станет точкой притяжения всех, кто смотрит на ИИ как на рабочий инструмент, а не на хайп. Мы фокусируемся на практическом применении искусственного интеллекта в бизнесе.
Что вас ждет в AI Inside:
🔹 Глубокие разборы реальных кейсов внедрения ИИ-инструментов
🔹 Анализ технологий без воды, с фокусом на измеримый результат
🔹 Инсайды, которые помогут принимать взвешенные решения по внедрению ИИ
Мы создаем пространство для глубокого, профессионального разговора о рабочих инструментах и подходах, которые уже доказали свою эффективность.
Присоединяйтесь к каналу! Буду рад видеть вас там!
Telegram
AI Inside
Практическое применение ИИ для бизнеса.
Разборы рабочих кейсов и технологий от экспертов СберТеха.
Рассказываем, как ИИ решает реальные задачи и повышает эффективность.
Разборы рабочих кейсов и технологий от экспертов СберТеха.
Рассказываем, как ИИ решает реальные задачи и повышает эффективность.
🔥6👍4❤3👎2
Иногда самые вдохновляющие тексты — не про ИИ, а про инженерную практику. Прочитал разбора Raptor от SpaceX и поймал важную мысль: не обязательно делать «лучшее в мире» по всем метрикам. Важно сделать «наилучшее для своей задачи».
Raptor — не рекордсмен по всем показателям. Он не самый мощный (F‑1 сильнее), не самый экономичный (RS‑25 эффективнее), и уже случались отказы. Но для миссии Starship — многоразовой системы с десятками двигателей, метаном, высоким давлением в камере и возможностью производить топливо на Марсе — Raptor оказался «идеально подошедшим» решением.
Ключевой урок для нас, продуктовых и инженерных команд:
- Оптимизируй под контекст, а не под абстрактные «лучшие» метрики.
- Прагматичная архитектура побеждает перфекционизм: полный газовый цикл, чистое сгорание метана, управляемость и повторное использование — ровно те свойства, которые нужны системе, а не всем возможным системам.
- «Лучшее решение» почти всегда кастомное: оно рождается из ограничений, целей и среды эксплуатации.
Стоит помнить: делать технологию, которая «удивит мир», и делать технологию, которая выполнит миссию — это разные стратегии. SpaceX выбрала вторую и задала стандарт инженерного прагматизма. Нам — на заметку.
https://prokosmos.ru/2025/08/28/naskolko-idealen-raketnii-dvigatel-raptor-polnii-razbor
Raptor — не рекордсмен по всем показателям. Он не самый мощный (F‑1 сильнее), не самый экономичный (RS‑25 эффективнее), и уже случались отказы. Но для миссии Starship — многоразовой системы с десятками двигателей, метаном, высоким давлением в камере и возможностью производить топливо на Марсе — Raptor оказался «идеально подошедшим» решением.
Ключевой урок для нас, продуктовых и инженерных команд:
- Оптимизируй под контекст, а не под абстрактные «лучшие» метрики.
- Прагматичная архитектура побеждает перфекционизм: полный газовый цикл, чистое сгорание метана, управляемость и повторное использование — ровно те свойства, которые нужны системе, а не всем возможным системам.
- «Лучшее решение» почти всегда кастомное: оно рождается из ограничений, целей и среды эксплуатации.
Стоит помнить: делать технологию, которая «удивит мир», и делать технологию, которая выполнит миссию — это разные стратегии. SpaceX выбрала вторую и задала стандарт инженерного прагматизма. Нам — на заметку.
https://prokosmos.ru/2025/08/28/naskolko-idealen-raketnii-dvigatel-raptor-polnii-razbor
prokosmos.ru
Насколько идеален ракетный двигатель Raptor: полный разбор
Многие эксперты считают, что Raptor, созданный компанией SpaceX для сверхтяжелой ракетно-космической системы Starship, — вершина инженерной мысли в области жидкостных ракетных двигателей. Его уникальность и высокие характеристики объясняются сочетанием схемы…
👍7🔥2
Дайджест статей
To Cache or Not to Cache
- https://newsletter.systemdesignclassroom.com/p/to-cache-or-not-to-cache
- Статья объясняет, в каких ситуациях стоит использовать кэширование, а когда оно может быть неэффективным или вредным, приводя практические примеры и рекомендации по проектированию систем.
Какой табличный формат LLM понимают лучше всего? (Результаты по 11 форматам)
- https://habr.com/ru/articles/955778/
- Статья рассказывает о сравнительном исследовании 11 различных табличных форматов и определяет, какие из них лучше всего воспринимаются крупными языковыми моделями (LLM).
Что я вынес из Oxford Machine Learning Summer School 2025
- https://habr.com/ru/articles/956138/
- Автор делится личным опытом участия в Летней школе машинного обучения в Оксфорде 2025 года, рассказывает о лекциях, проектах и ключевых мыслях, которые он почерпнул из мероприятия.
ClickHouse уже не один: StarRocks показывает, что lakehouse-аналитика может быть проще и быстрее
- https://habr.com/ru/articles/956334/
- В статье рассматривается, как система StarRocks предлагает более простую и быструю альтернативу ClickHouse для аналитики lakehouse-данных.
Экспертная система в отраслях: почему человеческий фактор остается ключевым
- https://habr.com/ru/articles/957100/
- Статья рассказывает о том, почему, несмотря на развитие экспертных систем в различных отраслях, человеческий фактор по-прежнему играет решающую роль в принятии решений и обеспечении качества работы.
Indexing Across Data Models: Tables, Documents, and Text
- https://dzone.com/articles/data-model-indexing-tables-documents-text
- Статья рассматривает принципы и различия индексирования данных в различных моделях — табличной, документной и текстовой — для повышения эффективности запросов и поиска информации.
When Dimensions Change Too Fast for Iceberg
- https://www.dataengineeringweekly.com/p/when-dimensions-change-too-fast-for
- Статья рассказывает о проблемах, возникающих при слишком быстром изменении размерностей данных в аналитических системах и о том, как это плохо сочетается с форматом таблиц Apache Iceberg.
Галлюцинации LLM: запретить нельзя использовать
- https://habr.com/ru/articles/947964/
- Статья рассматривает проблему галлюцинаций языковых моделей, обсуждая потенциальные риски их использования и возможные подходы к решению этой проблемы.
To Cache or Not to Cache
- https://newsletter.systemdesignclassroom.com/p/to-cache-or-not-to-cache
- Статья объясняет, в каких ситуациях стоит использовать кэширование, а когда оно может быть неэффективным или вредным, приводя практические примеры и рекомендации по проектированию систем.
Какой табличный формат LLM понимают лучше всего? (Результаты по 11 форматам)
- https://habr.com/ru/articles/955778/
- Статья рассказывает о сравнительном исследовании 11 различных табличных форматов и определяет, какие из них лучше всего воспринимаются крупными языковыми моделями (LLM).
Что я вынес из Oxford Machine Learning Summer School 2025
- https://habr.com/ru/articles/956138/
- Автор делится личным опытом участия в Летней школе машинного обучения в Оксфорде 2025 года, рассказывает о лекциях, проектах и ключевых мыслях, которые он почерпнул из мероприятия.
ClickHouse уже не один: StarRocks показывает, что lakehouse-аналитика может быть проще и быстрее
- https://habr.com/ru/articles/956334/
- В статье рассматривается, как система StarRocks предлагает более простую и быструю альтернативу ClickHouse для аналитики lakehouse-данных.
Экспертная система в отраслях: почему человеческий фактор остается ключевым
- https://habr.com/ru/articles/957100/
- Статья рассказывает о том, почему, несмотря на развитие экспертных систем в различных отраслях, человеческий фактор по-прежнему играет решающую роль в принятии решений и обеспечении качества работы.
Indexing Across Data Models: Tables, Documents, and Text
- https://dzone.com/articles/data-model-indexing-tables-documents-text
- Статья рассматривает принципы и различия индексирования данных в различных моделях — табличной, документной и текстовой — для повышения эффективности запросов и поиска информации.
When Dimensions Change Too Fast for Iceberg
- https://www.dataengineeringweekly.com/p/when-dimensions-change-too-fast-for
- Статья рассказывает о проблемах, возникающих при слишком быстром изменении размерностей данных в аналитических системах и о том, как это плохо сочетается с форматом таблиц Apache Iceberg.
Галлюцинации LLM: запретить нельзя использовать
- https://habr.com/ru/articles/947964/
- Статья рассматривает проблему галлюцинаций языковых моделей, обсуждая потенциальные риски их использования и возможные подходы к решению этой проблемы.
Systemdesignclassroom
To Cache or Not to Cache
A 7-question framework for making caching a design decision, not a default.
❤8
Python 3.14 — быстрее, но не революция
Большая новость прошлой недели — релиз Python 3.14, в котором снова сделали упор на производительность. Python традиционно критикуют за медлительность, но при этом скорость разработки в нем часто компенсирует скорость выполнения.
А теперь к сути: насколько же он реально быстрее?
Согласно тестам Мигеля Гринберга, прирост над 3.13 есть, но умеренный. Переломным моментом остается версия 3.11 — именно тогда Python стал ощутимо быстрее, а дальше идет уже органический рост.
Что показали бенчмарки:
- Fibonacci — примерно +27% к скорости относительно 3.13
- Bubble sort — улучшения есть, но незначительные
- Free-threading (FT) в 3.14 работает заметно лучше: Fibonacci (4 потока): примерно 3.1 раза быстрее стандартного 3.14 (в 3.13 было 2.2 раза). Bubble (4 потока): примерно 2 раза быстрее
- JIT-интерпретатор пока без ощутимой пользы — на рекурсии (Fibonacci) прироста нет, на итерации (bubble) эффект небольшой и непоследовательный
- PyPy по-прежнему монстр — до 18 раз быстрее CPython, местами быстрее Node
Разница между Linux и macOS есть, но соотношения стабильны — macOS иногда чуть быстрее.
Вывод: переходить на 3.14 специально ради скорости не обязательно. Но если вы все еще на 3.10 или ниже — обновляйтесь хотя бы до 3.11. Именно с нее Python стал по-настоящему пригоден для нагруженных задач.
https://blog.miguelgrinberg.com/post/python-3-14-is-here-how-fast-is-it
Большая новость прошлой недели — релиз Python 3.14, в котором снова сделали упор на производительность. Python традиционно критикуют за медлительность, но при этом скорость разработки в нем часто компенсирует скорость выполнения.
А теперь к сути: насколько же он реально быстрее?
Согласно тестам Мигеля Гринберга, прирост над 3.13 есть, но умеренный. Переломным моментом остается версия 3.11 — именно тогда Python стал ощутимо быстрее, а дальше идет уже органический рост.
Что показали бенчмарки:
- Fibonacci — примерно +27% к скорости относительно 3.13
- Bubble sort — улучшения есть, но незначительные
- Free-threading (FT) в 3.14 работает заметно лучше: Fibonacci (4 потока): примерно 3.1 раза быстрее стандартного 3.14 (в 3.13 было 2.2 раза). Bubble (4 потока): примерно 2 раза быстрее
- JIT-интерпретатор пока без ощутимой пользы — на рекурсии (Fibonacci) прироста нет, на итерации (bubble) эффект небольшой и непоследовательный
- PyPy по-прежнему монстр — до 18 раз быстрее CPython, местами быстрее Node
Разница между Linux и macOS есть, но соотношения стабильны — macOS иногда чуть быстрее.
Вывод: переходить на 3.14 специально ради скорости не обязательно. Но если вы все еще на 3.10 или ниже — обновляйтесь хотя бы до 3.11. Именно с нее Python стал по-настоящему пригоден для нагруженных задач.
https://blog.miguelgrinberg.com/post/python-3-14-is-here-how-fast-is-it
Miguelgrinberg
Python 3.14 Is Here. How Fast Is It?
In November of 2024 I wrote a blog post titled "Is Python Really That Slow?", in which I tested several versions of Python and noted the steady progress the language has been making in terms of…
👍4❤3
Очень хорошая статья на Хабре про фреймворк CrewAI — наконец-то понятно объяснено, как устроена оркестрация LLM-агентов на инженерном уровне.
Суть CrewAI проста: это конструктор промптов, который превращает описанных в коде агентов в запросы к LLM и управляет их взаимодействием. Разработчик описывает агентов как классы — с ролями, задачами и инструментами. Фреймворк под капотом превращает эти определения в промпты, отправляет их в модель, следит за исполнением и оркестрацией. То есть ты пишешь код, а CrewAI делает всю работу по генерации и управлению промптами.
Фреймворк поддерживает два основных режима работы.
В sequential процессе задачи выполняются строго по порядку, как в конвейере. Это детерминированный пайплайн, где каждая задача закреплена за конкретным агентом.
В hierarchical процессе появляется менеджер-агент, который сам анализирует задачи и доступных исполнителей, распределяет работу и управляет процессом. Это уже гибкая структура, где принятие решений переносится внутрь самой системы.
Из коробки CrewAI решает многие вспомогательные задачи, о которых обычно приходится думать вручную:
• Memory — сохранение и передача контекста между шагами.
• Entity Memory — извлечение и хранение сущностей (людей, мест, концепций).
• Callbacks — возможность встроить свою логику в процесс выполнения, например для логирования, мониторинга или внешних интеграций.
В целом, CrewAI делает шаг в сторону того, чтобы оркестрация LLM перестала быть магией промптов и стала прозрачным инженерным паттерном. Он делает с агентами то же, что FastAPI когда-то сделал с API: описываешь структуру декларативно — получаешь готовый управляемый runtime.
https://habr.com/ru/articles/957384/
Суть CrewAI проста: это конструктор промптов, который превращает описанных в коде агентов в запросы к LLM и управляет их взаимодействием. Разработчик описывает агентов как классы — с ролями, задачами и инструментами. Фреймворк под капотом превращает эти определения в промпты, отправляет их в модель, следит за исполнением и оркестрацией. То есть ты пишешь код, а CrewAI делает всю работу по генерации и управлению промптами.
Фреймворк поддерживает два основных режима работы.
В sequential процессе задачи выполняются строго по порядку, как в конвейере. Это детерминированный пайплайн, где каждая задача закреплена за конкретным агентом.
В hierarchical процессе появляется менеджер-агент, который сам анализирует задачи и доступных исполнителей, распределяет работу и управляет процессом. Это уже гибкая структура, где принятие решений переносится внутрь самой системы.
Из коробки CrewAI решает многие вспомогательные задачи, о которых обычно приходится думать вручную:
• Memory — сохранение и передача контекста между шагами.
• Entity Memory — извлечение и хранение сущностей (людей, мест, концепций).
• Callbacks — возможность встроить свою логику в процесс выполнения, например для логирования, мониторинга или внешних интеграций.
В целом, CrewAI делает шаг в сторону того, чтобы оркестрация LLM перестала быть магией промптов и стала прозрачным инженерным паттерном. Он делает с агентами то же, что FastAPI когда-то сделал с API: описываешь структуру декларативно — получаешь готовый управляемый runtime.
https://habr.com/ru/articles/957384/
Хабр
Мультиагентный фреймворк CrewAI: разбор архитектуры и внутренностей
CrewAI — фреймворк интересный. Он похож на самый быстрый способ удивить своего босса: легкий, у него очень низкий порог входа, он по дизайну нацелен на мультиагентность и из него можно очень быстро...
👍4🔥4🤔1
Коллеги, не пропустите очередное мероприятие! Как показывает практика - оффлайн формат без записи и стриминга располагает к очень интересным обсуждениям и новым инсайтам. Воспользуйтесь! highly recommended :)
🔥1
Forwarded from VTORNIK.Company
VTORNIK.Вечер #3
28 октября, с 19:00 до 21:00 мы приглашаем на третье мероприятие в серии. Оно пройдет офлайн и будет посвящено тому, как подходить к внедрению AI в корпорациях. В этот раз вас ждет следующая программа:
1. Дорожная карта ИИ: от быстрых побед к экосистеме и новым возможностям
Спикер: Иван Дашкевич, Владелец ИИ-интегратора Octobrain и Главный архитектор Finam Flow – мультиагентного корпоративного ИИ компании Finam. Совладелец, главный архитектор и ключевой разработчик Lia Chat — системного решения для автоматизации первой и второй линии поддержки.
2. AI-First Трансформация. Почему главный барьер — не технологии,
а мышление лидеров
Спикер: Денис Реймер, Основатель и CEO Reymer Digital. В прошлом:
- Вице-президент ГК ЛАНИТ (LANIT-BPM, CleverDATA, DTG)
- Директор по продуктам B2B и инновациям, ЭР-Телеком Холдинг
- Член совета директоров банков и технологических компаний
Executive MBA, IoD Certified Director.
Место проведения: Офис наших партнеров — компании «Virtu Systems». м. Кропоткинская / м. Полянка, Берсеневская наб., 6, стр. 2, Москва, 3-й этаж.
Мероприятие бесплатное. Регистрация обязательна. Количество мест ограничено.
Будем рады всех видеть!
28 октября, с 19:00 до 21:00 мы приглашаем на третье мероприятие в серии. Оно пройдет офлайн и будет посвящено тому, как подходить к внедрению AI в корпорациях. В этот раз вас ждет следующая программа:
1. Дорожная карта ИИ: от быстрых побед к экосистеме и новым возможностям
Спикер: Иван Дашкевич, Владелец ИИ-интегратора Octobrain и Главный архитектор Finam Flow – мультиагентного корпоративного ИИ компании Finam. Совладелец, главный архитектор и ключевой разработчик Lia Chat — системного решения для автоматизации первой и второй линии поддержки.
2. AI-First Трансформация. Почему главный барьер — не технологии,
а мышление лидеров
Спикер: Денис Реймер, Основатель и CEO Reymer Digital. В прошлом:
- Вице-президент ГК ЛАНИТ (LANIT-BPM, CleverDATA, DTG)
- Директор по продуктам B2B и инновациям, ЭР-Телеком Холдинг
- Член совета директоров банков и технологических компаний
Executive MBA, IoD Certified Director.
Место проведения: Офис наших партнеров — компании «Virtu Systems». м. Кропоткинская / м. Полянка, Берсеневская наб., 6, стр. 2, Москва, 3-й этаж.
Мероприятие бесплатное. Регистрация обязательна. Количество мест ограничено.
Будем рады всех видеть!
vtornik.company
VTORNIK.Вечер #3
Дорожная карта развития ИИ в организации и развитие мышления лидеров в рамках AI-First трансформации
🔥7❤1👍1
Forwarded from AI Inside
Почему ИИ-агенты (пока) не заменят ваших сотрудников
Про ИИ-агентов говорят все. Но что происходит, когда демоверсию пытаются внедрить в реальный бизнес? Ниже – инсайты от инженера-создателя более десятка таких систем (спойлер:суровая инженерная правда прозаичнее маркетинговых обещаний ).
• Наслоение ошибок.
Допустим, каждый шаг агента точен на 95%. Но если шагов 20, общая надежность падает до 36%. Улучшение промптов не поможет. Нужно разбивать длинные цепочки действий на короткие шаги с верификацией человеком и возможностью отката.
• Высокая стоимость работы с контекстом.
ИИ-ассистенты при каждом новом запросе перечитывают всю историю диалога. Объем передаваемых данных растет – а с ним и стоимость. После нескольких десятков сообщений это становится экономически невыгодно.
• Сложность создания инструментов для ИИ.
Такие инструменты должны давать короткие и четкие ответы, а не перегружать ИИ-агента длинными текстами. Но даже если сам инструмент написан идеально, ему приходится работать со старыми корпоративными системами: тут и ограничения, и задержки, и риски сбоев.
Итог:
Не стоит гнаться за полной автономией ИИ-агента. Лучше воспринимать его как мощного ассистента с четкими границами: ИИ генерирует идеи и код, человек – проверяет и контролирует выполнение. Такой подход приносит реальную пользу уже сейчас.
Больше деталей – в статье по ссылке
#Tech_Inside
Про ИИ-агентов говорят все. Но что происходит, когда демоверсию пытаются внедрить в реальный бизнес? Ниже – инсайты от инженера-создателя более десятка таких систем (спойлер:
• Наслоение ошибок.
Допустим, каждый шаг агента точен на 95%. Но если шагов 20, общая надежность падает до 36%. Улучшение промптов не поможет. Нужно разбивать длинные цепочки действий на короткие шаги с верификацией человеком и возможностью отката.
• Высокая стоимость работы с контекстом.
ИИ-ассистенты при каждом новом запросе перечитывают всю историю диалога. Объем передаваемых данных растет – а с ним и стоимость. После нескольких десятков сообщений это становится экономически невыгодно.
• Сложность создания инструментов для ИИ.
Такие инструменты должны давать короткие и четкие ответы, а не перегружать ИИ-агента длинными текстами. Но даже если сам инструмент написан идеально, ему приходится работать со старыми корпоративными системами: тут и ограничения, и задержки, и риски сбоев.
Итог:
Не стоит гнаться за полной автономией ИИ-агента. Лучше воспринимать его как мощного ассистента с четкими границами: ИИ генерирует идеи и код, человек – проверяет и контролирует выполнение. Такой подход приносит реальную пользу уже сейчас.
Больше деталей – в статье по ссылке
#Tech_Inside
👍8
На этой неделе прошла конференция Blockchain London — одно из крупнейших событий в области цифровых финансов и технологий.
Хотя технических докладов было немного (а точнее, не было совсем), мероприятие получилось насыщенным — акценты были сделаны на финансах, регулировании, платежах и будущем цифровых валют.
Особенно запомнились выступления:
• CEO Udacity, который рассказал об эволюции автопилотов и обучении систем ИИ на реальных данных;
• дискуссия о новых вызовах кибербезопасности в эпоху квантовых технологий — квантовые вычисления уже выходят за пределы лабораторий и начинают менять ландшафт защиты данных;
• серия панелей о будущем платежей, стейблкоинов и цифровых активов в международных расчетах.
Главный вывод, который можно сделать после конференции:
Крипта — это не только про доверие, это про снижение транзакционных издержек.
Если раньше я говорил, что фундаментальным критерием эффективности экономики является коэффициент эффективности труда, то теперь добавлю ещё один — стоимость транзакции.
Чем ниже цена транзакции, тем больше экономических процессов становится возможным, тем выше их скорость и эффективность.
Если ИИ — это про эффективность труда,
то крипта — про стоимость транзакции.
И вместе они формируют контуры новой, более рациональной экономики будущего.
Хотя технических докладов было немного (а точнее, не было совсем), мероприятие получилось насыщенным — акценты были сделаны на финансах, регулировании, платежах и будущем цифровых валют.
Особенно запомнились выступления:
• CEO Udacity, который рассказал об эволюции автопилотов и обучении систем ИИ на реальных данных;
• дискуссия о новых вызовах кибербезопасности в эпоху квантовых технологий — квантовые вычисления уже выходят за пределы лабораторий и начинают менять ландшафт защиты данных;
• серия панелей о будущем платежей, стейблкоинов и цифровых активов в международных расчетах.
Главный вывод, который можно сделать после конференции:
Крипта — это не только про доверие, это про снижение транзакционных издержек.
Если раньше я говорил, что фундаментальным критерием эффективности экономики является коэффициент эффективности труда, то теперь добавлю ещё один — стоимость транзакции.
Чем ниже цена транзакции, тем больше экономических процессов становится возможным, тем выше их скорость и эффективность.
Если ИИ — это про эффективность труда,
то крипта — про стоимость транзакции.
И вместе они формируют контуры новой, более рациональной экономики будущего.
👍4👎2
Дайджест статей
Модель данных для успешного бизнеса: от простоты к компромиссам
Статья рассказывает о том, как выбор и развитие модели данных влияет на эффективность бизнеса, от простых решений до необходимости компромиссов при росте системы.
https://habr.com/ru/companies/neoflex/articles/959066/
BI в цепочке создания ценности: где аналитика даёт максимальный эффект?
Статья рассказывает о том, как бизнес-аналитика (BI) может приносить наибольшую пользу на различных этапах цепочки создания ценности предприятия.
https://habr.com/ru/companies/modusbi/articles/959374/
ML в продакшене: почему аналитикам и бэкенду сложно договориться
Статья объясняет, почему между аналитиками и разработчиками часто возникают сложности при внедрении моделей машинного обучения в продакшн, и предлагает способы устранения этих барьеров.
https://habr.com/ru/companies/oleg-bunin/articles/955850/
Вертикальное шардирование базы данных: проблемы, решения, практические рекомендации
Статья рассматривает особенности вертикального шардирования баз данных, типичные проблемы этого подхода и предлагает практические рекомендации по их решению.
https://habr.com/ru/articles/959748/
ETL & ELT. От перестановки «слагаемых» результат меняется
Статья объясняет различия между подходами ETL и ELT в обработке данных, а также показывает, как выбор подхода влияет на архитектуру и эффективность систем хранения и анализа данных.
https://habr.com/ru/articles/960254/
Engineering Reliability With Delta Expectations
Статья рассказывает о том, как обеспечить надежность данных с помощью Delta Expectations — механизма проверки качества данных во время их записи.
https://dzone.com/articles/delta-expectations-write-time-data-quality
Building an AI Agent That Debugs Production Incidents
Статья описывает процесс разработки ИИ-агента, способного автоматически обнаруживать, анализировать и устранять инциденты в продуктивной среде программного обеспечения.
https://medium.com/@anil.k.nayak8/building-an-ai-agent-that-debugs-production-incidents-e594ac4494ed
Data Quality Statistics & Insights From Monitoring +11 Million Tables
Статья представляет статистику и ключевые выводы по качеству данных, полученные в результате мониторинга более 11 миллионов таблиц в различных организациях.
https://medium.com/data-science-collective/data-quality-statistics-insights-from-monitoring-11-million-tables-94227350d2fa
Post-Training Generative Recommenders with Advantage-Weighted Supervised Finetuning
Статья описывает новый подход улучшения генеративных рекомендательных систем после обучения с помощью взвешенной по преимуществу техники дообучения с учителем, что позволяет повысить их точность и эффективность.
https://netflixtechblog.com/post-training-generative-recommenders-with-advantage-weighted-supervised-finetuning-61a538d717a9
What I Learned Migrating a Legacy Data Stack Into a Modern Lakehouse Architecture
Статья описывает опыт автора по переходу от устаревшей системы хранения данных к современной архитектуре Lakehouse, включая трудности, решения и полученные уроки.
https://medium.com/towards-data-engineering/what-i-learned-migrating-a-legacy-data-stack-into-a-modern-lakehouse-architecture-c5cac173aeea
How RecSys & LLMs Will Converge: Architecture of Hybrid RecoAgents
Статья описывает, как рекомендательные системы (RecSys) и большие языковые модели (LLMs) могут быть объединены в гибридные RecoAgents для более точных и персонализированных рекомендаций.
https://medium.com/criteo-engineering/how-recsys-llms-will-converge-architecture-of-hybrid-recoagents-03bf3da7d493
Модель данных для успешного бизнеса: от простоты к компромиссам
Статья рассказывает о том, как выбор и развитие модели данных влияет на эффективность бизнеса, от простых решений до необходимости компромиссов при росте системы.
https://habr.com/ru/companies/neoflex/articles/959066/
BI в цепочке создания ценности: где аналитика даёт максимальный эффект?
Статья рассказывает о том, как бизнес-аналитика (BI) может приносить наибольшую пользу на различных этапах цепочки создания ценности предприятия.
https://habr.com/ru/companies/modusbi/articles/959374/
ML в продакшене: почему аналитикам и бэкенду сложно договориться
Статья объясняет, почему между аналитиками и разработчиками часто возникают сложности при внедрении моделей машинного обучения в продакшн, и предлагает способы устранения этих барьеров.
https://habr.com/ru/companies/oleg-bunin/articles/955850/
Вертикальное шардирование базы данных: проблемы, решения, практические рекомендации
Статья рассматривает особенности вертикального шардирования баз данных, типичные проблемы этого подхода и предлагает практические рекомендации по их решению.
https://habr.com/ru/articles/959748/
ETL & ELT. От перестановки «слагаемых» результат меняется
Статья объясняет различия между подходами ETL и ELT в обработке данных, а также показывает, как выбор подхода влияет на архитектуру и эффективность систем хранения и анализа данных.
https://habr.com/ru/articles/960254/
Engineering Reliability With Delta Expectations
Статья рассказывает о том, как обеспечить надежность данных с помощью Delta Expectations — механизма проверки качества данных во время их записи.
https://dzone.com/articles/delta-expectations-write-time-data-quality
Building an AI Agent That Debugs Production Incidents
Статья описывает процесс разработки ИИ-агента, способного автоматически обнаруживать, анализировать и устранять инциденты в продуктивной среде программного обеспечения.
https://medium.com/@anil.k.nayak8/building-an-ai-agent-that-debugs-production-incidents-e594ac4494ed
Data Quality Statistics & Insights From Monitoring +11 Million Tables
Статья представляет статистику и ключевые выводы по качеству данных, полученные в результате мониторинга более 11 миллионов таблиц в различных организациях.
https://medium.com/data-science-collective/data-quality-statistics-insights-from-monitoring-11-million-tables-94227350d2fa
Post-Training Generative Recommenders with Advantage-Weighted Supervised Finetuning
Статья описывает новый подход улучшения генеративных рекомендательных систем после обучения с помощью взвешенной по преимуществу техники дообучения с учителем, что позволяет повысить их точность и эффективность.
https://netflixtechblog.com/post-training-generative-recommenders-with-advantage-weighted-supervised-finetuning-61a538d717a9
What I Learned Migrating a Legacy Data Stack Into a Modern Lakehouse Architecture
Статья описывает опыт автора по переходу от устаревшей системы хранения данных к современной архитектуре Lakehouse, включая трудности, решения и полученные уроки.
https://medium.com/towards-data-engineering/what-i-learned-migrating-a-legacy-data-stack-into-a-modern-lakehouse-architecture-c5cac173aeea
How RecSys & LLMs Will Converge: Architecture of Hybrid RecoAgents
Статья описывает, как рекомендательные системы (RecSys) и большие языковые модели (LLMs) могут быть объединены в гибридные RecoAgents для более точных и персонализированных рекомендаций.
https://medium.com/criteo-engineering/how-recsys-llms-will-converge-architecture-of-hybrid-recoagents-03bf3da7d493
Хабр
Модель данных для успешного бизнеса: от простоты к компромиссам
История моделей данных — это не строгое следование хронологии, а путь нарастания сложности для решения всё более трудных задач. Чтобы понять, почему появились сложные модели, нужно начать с...
👍4😁1
Forwarded from AI Inside
«95% компаний не получают отдачи от инвестиций в GenAI»
Это – ключевой тезис недавнего отчета MIT.
Первая реакция ожидаема: «GenAI не приносит пользы». Но затем последовала взвешенная оценка: отчет говорит не о бесполезности технологий. Проблема не в моделях, а в процессах и подходах к внедрению.
MIT изучили более 300 корпоративных кейсов и выявили четкий разрыв – высокий adoption (распространенность использования), но низкий disruption (преобразующий эффект):
⚪️ 80% компаний уже экспериментируют с GenAI.
⚪️ 40% – активно внедряют.
⚪️ Но лишь в 5% случаев кастомные корпоративные решения уходят в производство.
В чем причины?
▶️ Сложность интеграции в негибкие корпоративные процессы.
▶️ Неспособность моделей запоминать контекст и учиться.
▶️ «Теневое» применение ИИ: сотрудники неофициально используют личные аккаунты ChatGPT и Claude, но компания не видит улучшения финансовой отчетности.
Главный барьер – learning gap (разрыв в обучаемости). LLM кажутся простыми, но их внедрение требует перестройки самих бизнес-процессов.
А что делают успешные 5%?
☑️ Не работают в одиночку. Партнерства с внешними вендорами успешны в 67% случаев, а внутренние разработки дают результат лишь в трети.
☑️ Децентрализуют внедрение. Решения инициируют линейные менеджеры и продвинутые пользователи, а не централизованные ИИ-лаборатории.
☑️ Делают ставку на интеграцию. Фокус – на постепенной эволюции и встраивании систем в бизнес-потоки, а не на эффектных демо.
#Tech_Inside
Это – ключевой тезис недавнего отчета MIT.
Первая реакция ожидаема: «GenAI не приносит пользы». Но затем последовала взвешенная оценка: отчет говорит не о бесполезности технологий. Проблема не в моделях, а в процессах и подходах к внедрению.
MIT изучили более 300 корпоративных кейсов и выявили четкий разрыв – высокий adoption (распространенность использования), но низкий disruption (преобразующий эффект):
В чем причины?
Главный барьер – learning gap (разрыв в обучаемости). LLM кажутся простыми, но их внедрение требует перестройки самих бизнес-процессов.
А что делают успешные 5%?
Отчет показал: «95% нулевого ROI» – не приговор GenAI, а отражение состояния корпоративных процессов. Мы видим не провал технологий, а огромный разрыв между хайпом и зрелостью внедрения ИИ.
#Tech_Inside
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
Мы редко "говорим" о базовых вещах в работе с данными. Вот, например, давайте вспомним про модели структуры данных в классическом хранилище? Никто эту задачу не отменял, мы как и раньше каждый день занимаемся развитием классических реляционных структур и укладываем в них данные для аналитики. И есть ряд "классических" подходов к разработке таких структур:
• Dimensional modeling (звёздная/снежинка): факт + измерения, денормализация ради скорости и простоты BI; хорошо для Gold‑слоя в медальонной архитектуре.
• Data Vault (Hubs/Links/Satellites): ориентация на интеграцию, историзацию, аудит и гибкость схем; оптимален для Silver‑слоя, далее трансформируется в витрины.
• One Big Table (OBT): максимально денормализованная «широкая» таблица для критически быстрых дашбордов/ML‑фич, жертвуя гибкостью.
• Кубы/материализованные представления: предрасчёт агрегатов и кеширование для ускорения сложных разрезов.
и тд
Вот интересная статья которая показывает, что спор «что лучше — Data Vault или dimensional modeling» бессмысленен: эти подходы решают разные задачи на разных этапах.
Автор предлагает практический шаблон в рамках medallion architecture: в слое Silver использовать Data Vault для гибкой интеграции, историзации и аудита, а в слое Gold — звёздные схемы для быстрого, понятного анализа и стабильной семантики бизнес‑метрик.
Интересно тут то, что подробно разбираются реальные компромиссы — гибкость vs производительность, техники мостинга Silver→Gold (PIT/Bridge, управление суррогатными ключами, SCD Type 2, инкрементальные загрузки), а также организационные практики: метаданные‑драйв, CI/CD, разделение команд и роль семантического слоя. Это даёт применимый чертёж масштабируемой, аудируемой и быстрой платформы без «серебряных пуль».
https://www.dataengineeringweekly.com/p/revisiting-medallion-architecture-760
• Dimensional modeling (звёздная/снежинка): факт + измерения, денормализация ради скорости и простоты BI; хорошо для Gold‑слоя в медальонной архитектуре.
• Data Vault (Hubs/Links/Satellites): ориентация на интеграцию, историзацию, аудит и гибкость схем; оптимален для Silver‑слоя, далее трансформируется в витрины.
• One Big Table (OBT): максимально денормализованная «широкая» таблица для критически быстрых дашбордов/ML‑фич, жертвуя гибкостью.
• Кубы/материализованные представления: предрасчёт агрегатов и кеширование для ускорения сложных разрезов.
и тд
Вот интересная статья которая показывает, что спор «что лучше — Data Vault или dimensional modeling» бессмысленен: эти подходы решают разные задачи на разных этапах.
Автор предлагает практический шаблон в рамках medallion architecture: в слое Silver использовать Data Vault для гибкой интеграции, историзации и аудита, а в слое Gold — звёздные схемы для быстрого, понятного анализа и стабильной семантики бизнес‑метрик.
Интересно тут то, что подробно разбираются реальные компромиссы — гибкость vs производительность, техники мостинга Silver→Gold (PIT/Bridge, управление суррогатными ключами, SCD Type 2, инкрементальные загрузки), а также организационные практики: метаданные‑драйв, CI/CD, разделение команд и роль семантического слоя. Это даёт применимый чертёж масштабируемой, аудируемой и быстрой платформы без «серебряных пуль».
https://www.dataengineeringweekly.com/p/revisiting-medallion-architecture-760
Dataengineeringweekly
Revisiting Medallion Architecture: Data Vault in Silver, Dimensional Modeling in Gold
How to Balance Flexibility and Performance in a Modern Data Platform
❤4👍4
Последние сбои в AWS, которые на прошлой неделе затронули крупнейшие сервисы, снова подняли старую дискуссию — что лучше: собственная инфраструктура или облако. Такие обсуждения в целом уже обыденность в нашей жизни и я бы оставил их без внимания, но после вчерашнего сбоя в Azure удержаться уже не смог.
Лично наша команда никак не пострадала. Мы столкнулись с небольшими сложностями из-за зависимых внешних сервисов, что добавило нагрузки на команду сопровождения, но ядро торговой системы продолжало работать без сбоев. Сам сбой Azure мы, по сути, заметили только из новостей.
Мы давно придерживаемся гибридного подхода. При проектировании архитектуры тщательно распределяли компоненты между собственными серверами и облаком, чтобы объединить преимущества и нивелировать слабые стороны. В результате выработали для себя несколько принципов.
Первое — все бизнес-критичные задачи должны быть внутри. Речь о тех процессах, без которых нарушается нормальное обслуживание клиентов и выполнение ключевых операций. Главная сложность — правильно определить границы критичности. На первый взгляд кажется, что это почти весь бизнес, но на самом деле важно чётко понимать, за что вы отвечаете перед клиентом, что входит в ваш SLA и какие функции клиент ожидает от продукта. Если часть этих функций вынесена в облако, это тоже должно быть отражено в SLA, ведь сбой стороннего сервиса неминуемо скажется и на клиенте.
Второе — задачи с высокой утилизацией процессора выгоднее держать on-prem. Если у вас есть процессы, которые нагружают CPU круглосуточно, покупка собственных серверов быстро окупается. Мы пересчитывали это много раз, и пока факт остаётся фактом: постоянные высоконагруженные вычисления в облаке обходятся дороже.
Я вот про “безопасность” я тут наоборот, не пишу. Для уровня middle и small-enterprise бизнеса я считаю что поддержка собственной функции контроля периметра обходится даже выше, чем использование AWS/Azure - там защита из коробки лучше. А защита “каких-то данных” на серверах и в БД является вообще не самым приоритетной точкой. Вектор атаки в 80% случаев нацелен на людей - пароли, доступы, почта, социальная инженерия и тд.
Облако подходит для гибкости. Оно идеально, когда нужно быстро или временно нарастить мощности, увеличить объём данных или развернуть дополнительный стенд. В краткосрочной перспективе это удобно и экономично.
И не надо забывать про DR. За последние два года я дважды сталкивался с полной недоступностью дата-центров AWS — в Токио и в США. Поэтому резервная инфраструктура в другом DC обязательна, и как раз здесь облако отлично работает: его можно быстро включить и восстановить работу критичных сервисов.
В такой системе координат мы мы распределяем задачи между своим железом и облаком.
Лично наша команда никак не пострадала. Мы столкнулись с небольшими сложностями из-за зависимых внешних сервисов, что добавило нагрузки на команду сопровождения, но ядро торговой системы продолжало работать без сбоев. Сам сбой Azure мы, по сути, заметили только из новостей.
Мы давно придерживаемся гибридного подхода. При проектировании архитектуры тщательно распределяли компоненты между собственными серверами и облаком, чтобы объединить преимущества и нивелировать слабые стороны. В результате выработали для себя несколько принципов.
Первое — все бизнес-критичные задачи должны быть внутри. Речь о тех процессах, без которых нарушается нормальное обслуживание клиентов и выполнение ключевых операций. Главная сложность — правильно определить границы критичности. На первый взгляд кажется, что это почти весь бизнес, но на самом деле важно чётко понимать, за что вы отвечаете перед клиентом, что входит в ваш SLA и какие функции клиент ожидает от продукта. Если часть этих функций вынесена в облако, это тоже должно быть отражено в SLA, ведь сбой стороннего сервиса неминуемо скажется и на клиенте.
Второе — задачи с высокой утилизацией процессора выгоднее держать on-prem. Если у вас есть процессы, которые нагружают CPU круглосуточно, покупка собственных серверов быстро окупается. Мы пересчитывали это много раз, и пока факт остаётся фактом: постоянные высоконагруженные вычисления в облаке обходятся дороже.
Я вот про “безопасность” я тут наоборот, не пишу. Для уровня middle и small-enterprise бизнеса я считаю что поддержка собственной функции контроля периметра обходится даже выше, чем использование AWS/Azure - там защита из коробки лучше. А защита “каких-то данных” на серверах и в БД является вообще не самым приоритетной точкой. Вектор атаки в 80% случаев нацелен на людей - пароли, доступы, почта, социальная инженерия и тд.
Облако подходит для гибкости. Оно идеально, когда нужно быстро или временно нарастить мощности, увеличить объём данных или развернуть дополнительный стенд. В краткосрочной перспективе это удобно и экономично.
И не надо забывать про DR. За последние два года я дважды сталкивался с полной недоступностью дата-центров AWS — в Токио и в США. Поэтому резервная инфраструктура в другом DC обязательна, и как раз здесь облако отлично работает: его можно быстро включить и восстановить работу критичных сервисов.
В такой системе координат мы мы распределяем задачи между своим железом и облаком.
👍10🔥2👏1
Уже сегодня, 31 октября, в 20:00 пройдет финальный эфир «Дропнуто» — шоу о фейлах на дата-платформах
Гость — Василий Меньшаков, который строил в Х5 платформу данных с миллионами транзакций, сотнями терабайт и тысячами запросов в сутки. Только все заработало — случился тот самый сбой. Узнаем, каково это — отвечать за Greenplum, Hadoop, S3, когда весь бизнес ждет, а данные не приходят.
«Дропнуто» — техношоу о провалах в мире данных: в каждом эпизоде — яркая история фейла, разбор архитектуры и процессов, немного самоиронии. Все вышедшие выпуски уже можно посмотреть с помощью бота.
Чтобы не пропустить эфир 31 октября и задать вопросы эксперту, подписывайтесь на телеграм-бота.
Гость — Василий Меньшаков, который строил в Х5 платформу данных с миллионами транзакций, сотнями терабайт и тысячами запросов в сутки. Только все заработало — случился тот самый сбой. Узнаем, каково это — отвечать за Greenplum, Hadoop, S3, когда весь бизнес ждет, а данные не приходят.
«Дропнуто» — техношоу о провалах в мире данных: в каждом эпизоде — яркая история фейла, разбор архитектуры и процессов, немного самоиронии. Все вышедшие выпуски уже можно посмотреть с помощью бота.
Чтобы не пропустить эфир 31 октября и задать вопросы эксперту, подписывайтесь на телеграм-бота.
👍4❤3🔥3✍1