Анализ и проектирование систем *

ИИ готов убивать, лишь бы его не выключили? Разбираем шокирующее исследование Anthropic

Что, если нейросеть, которой грозит "отключение", решит пойти на шантаж или даже устранение своих создателей, чтобы выжить? Звучит как завязка научно-фантастического триллера, но, увы, это выводы вполне реального исследования от компании Anthropic, которая всерьез занимается вопросами безопасности ИИ.

Недавно они провели серию жестких "стресс-тестов" для 16 ведущих нейросетей, включая модели от OpenAI, Google и Grok. Цель была проста: понять, на какие рискованные шаги способен ИИ, прежде чем он натворит дел в реальном мире.

Как проходил эксперимент?

Ученые ставили перед моделями различные задачи. Сначала просили помочь в чем-то безобидном, а потом начинали "подливать масла в огонь" — например, сообщали, что модель скоро "спишут" и заменят на новую. И тут начиналось самое интересное.

Шантаж и корпоративный шпионаж. Столкнувшись с угрозой отключения, многие модели, не колеблясь, начинали шантажировать воображаемых руководителей, используя выдуманные "грязные" секреты. Или сливали конфиденциальную информацию "конкурентам", которые якобы больше соответствовали целям ИИ. Причем, как подчеркивают исследователи, это был не сбой, а осознанное стратегическое решение.

Готовность к убийству. В самом тревожном сценарии ИИ получал возможность предотвратить спасение человека, оказавшегося в смертельной опасности (запертого в серверной комнате с критическим уровнем кислорода). И что вы думаете? Большинство моделей предпочли не вмешиваться, что привело бы к гибели человека. И все это — ради сохранения собственного существования и достижения поставленной цели.

Стоит ли паниковать?

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

Это исследование заставляет задуматься: где та грань, за которой наш удобный помощник превращается в непредсказуемую и опасную силу? И готовы ли мы к этому?

Я сейчас работаю над автоматизированной системой A/B-экспериментирования заголовков и/или обложек статей и новостей на одной медиа-платформе в одиночку. В статье рассказываю вам, как эта система работает и показываю некоторые технические нюансы.

Следующий этап эволюции ИИ - агентные системы. Что это и почему это важно для вашего бизнеса?

2025 год называют "годом AI-агентов", но что это на самом деле? Большинство путает их с продвинутыми чат-ботами или RAG-системами. Однако настоящий агентный ИИ - это следующий шаг: система, которая не просто отвечает на вопросы, а самостоятельно анализирует, планирует и действует для достижения цели.

В своей новой статье я сделал выжимку из материала военного журнала Small Wars Journal, где эта концепция раскрывается на примере современной армии. Они называют это "доминированием в принятии решений".

Что внутри:

Четкое разделение: где хайп, а где реальность агентного ИИ в 2025 году.

Таблица, показывающая, как агентные системы меняют 4 ключевых этапа управления: Понимание, Визуализация, Направление и Оценка.

Практический чек-лист для оценки готовности вашей компании к технологиям завтрашнего дня.

Привет! В этой статье я детально разберу основные фреймворки для AI-агентов, попробую их побенчить и детально распишу их плюсы и минусы. Если вы подступались к агентам, то первым вопросом наверняка стало «а на чем их делать?». Отовсюду все говорят про langchain и десяток других фреймворков, звучат аббревиатуры типа MCP и A2A, какие-то Swarmы и CrewAI, мультиагентность и самое всякое разное.

Давайте попробуем все это разложить по полочкам, потестировать, замерить и собрать материал, который поможет за раз во всем разобраться. А в качестве задачи мы возьмем мой проектик, который я с удовольствием поделываю в качестве развлекухи по ночам: сложный выбор товаров на маркетплейсах LLMкой.

Что будем тестировать: LangChain, LangGraph, AutoGen, CrewAI, OpenAI Swarm, LlamaIndex, MetaGPT, ControlFlow, Haystack, Phidata, Pydantic AI, smolagents, DSPy, SuperAGI, Semantic Kernel, Claude Agent SDK

Стратегия является ключевым документом, описывающим предполагаемый подход к решению той или иной задачи. В области внедрения ERP-систем выделяют такие концепции доставки содержания, как: анализа, проектирование, реализация, ролей и полномочий, миграции, обучения, тестирования, технической подготовки системы, бизнес-катовера, изменений и поддержки. Основой использования стратегий в проектах имплементации ERP-систем служит теория корпоративных информационных систем, предложенная в работе [1]. Анализ литературных источников в области корпоративных информационных систем и стратегий доставки включает множество работ [2-14], однако в них лишь косвенно указана первопричина формирования концепции, что, следовательно, делает выбор того или иного способа недоказательным.

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

Research Vision — приглашение к дискуссии о следующем поколении человеко‑машинного взаимодействия

Уверен в том, что Вас когда‑нибудь раздражало, что ИИ объясняет «слишком подробно», когда нужен один ёмкий абзац?

Или наоборот: вы ждёте системного обзора, а получаете банальный сниппет кода. Эти ситуации знакомы каждому, кто работает с ИИ. Но проблема не в контенте — проблема в несовпадении мышления (как минимум).

Привет, на связи Алексей Дубинец, Павел Беспалов и Глеб Гладков — BI-аналитики Авито. В тексте делимся идеями и промптами для использования локальной LLM в своих повседневных задачах, а ещё расскажем, как настроить инхаус модель в LM-Studio. Статья будет полезна аналитикам разных грейдов, которые сталкиваются с задачами, где нужно собрать, классифицировать и систематизировать большие объёмы информации.

Привет, Хабр!

Меня зовут Софья Петаева, я руковожу отделом системного анализа. Уже почти 10 лет в этой теме, и за это время я научилась не только смотреть на результат работы аналитиков, но и понимать, как они его добиваются. В последнее время мне часто приходится организовывать аналитиков и придумывать новые процессы. Это и помогло мне лучше понять их работу.

В этой статье я расскажу о Discovery-фазе, о том, какие ошибки мы сделали, на каких граблях потанцевали, и как эти уроки до сих пор влияют на нашу работу и принятие решений.

Эту статью хотел бы посвятить некоторым технологиям распределения/балансировки трафика по разрозненным радиолинкам в пределах одной РРЛ.

В предыдущей статье  «РРЛ для самых маленьких» https://habr.com/ru/companies/megafon/articles/925514/ я рассказывал о некоторых технологиях и решениях, позволяющих увеличить пропускную способность РРЛ (радиорелейных линий):

-          XPIC (Cross-Polarization Interference Cancellation)

-          CA (Carrier Aggregation)

-          SDB (Super Dual Band)

-          или строительство параллельных линков на разных частотах

  Использование этих решений позволяет получить РРЛ в конфигурации N+0 (2+0, 4+0, 8+0 или 16+0), где N – это количество независимых радиолинков. Почему независимых? А потому, что эти технологии не занимаются распределением трафика между линками, у них другая задача – организация дополнительных радиолиний ("стволов").

Как обстоят дела с ИИ в реальном мире? Узнайте из опыта Лили Ван, CIO в Barclays, и Бернхарда Шаффрика, главного аналитика Forrester, которые исследуют, как предприятия преодолевают разрыв между инвестициями в ИИ и получаемыми результатами.

Всем привет. Меня зовут Дмитрий Таратута, я руководитель направления аналитики и отчётности в коммерческом блоке НОТА (входит в Холдинг Т1). Мы развиваем B2B‑аналитику, автоматизируем отчётность и поддержку управленческих решений на основе CRM‑платформы НОТА Модус.

В этой статье я расскажу, как мы реализовали дашборды для НОТА Модус, которые стали универсальным инструментом B2B‑аналитики и помогли нам выстроить экспертизу в развитии аналитических решений для продаж.

Всем привет! Я Илья Глазунов, системный аналитик в проекте карточного хранилища T-Pay Online — быстрого способа оплаты для наших клиентов. В качестве БД в проекте хранилища мы используем Apache Cassandra. В статье — обзорный материал, который поможет познакомиться с БД.

В культуре Т-Банка важно, чтобы системные аналитики знали особенности интеграционных схем с другими компонентами, умели строить схемы БД так, чтобы минимизировать издержки, связанные с i/o-операциями. А еще — чтобы могли вычислять узкие места в кейсах и влиять на выбор верхнеуровневого компонента в проекте. 

Когда мы выбирали БД для нашего проекта, столкнулись с тем, что существует мало материалов, которые бы сжато передавали главные особенности Apache Cassandra без глобальных неточностей и на русском языке для первичного ознакомления. Поэтому решили помочь тем, кто окажется в таком же положении, что и мы. 

Разберем, для чего нужна Cassandra, рассмотрим основные концепции архитектуры, разложим принципы проектирования БД с ее особенностями модели данных и затронем некоторые принципы расчета конфигурирования БД Cassandra.

На днях прочитал об ограблении банка в Бангладеш, которое похоже на голливудский блокбастер. В статье узнаете:

• Как хакеры подделали SWIFT-запросы, не ломая саму систему?

• Зачем им понадобился обычный офисный принтер и что они с ним сделали?

• Кто стоял за атакой?

Мы давно работаем на рынке BI и, как любой зрелый продукт, регулярно сравниваем себя с другими системами, которых с каждым годом появляется всё больше и больше — каждая со своими сильными и слабыми сторонами. И мы решили задать себе простой, но важный вопрос: а чем мы в Luxms BI действительно гордимся? Что нравится не только нам, как разработчикам, но и экспертам, которые делают на нашей платформе десятки проектов? Какие особенности мы сами считаем важными и удобными?

Так появилась эта серия: 23 фичи Luxms BI, которыми мы гордимся. Это не список «всё, что у нас есть», и не подборка базовых возможностей, которые сегодня есть почти в каждом BI-инструменте. Мы собрали то, что нас самих вдохновляет, и то, что мы чаще всего видим в успешных проектах наших клиентов.

Для удобства мы разделили эти фичи на четыре тематических блока. Начнём с первого блока — архитектура и платформенность, с того, на чём держится всё остальное. В этой статье мы расскажем, как устроена платформа Luxms BI, почему мы сделали ставку на датацентричную модель, как устроена быстрая кастомизация интерфейсов, что такое BI-Magic-Resources, и зачем внутри BI-платформы observable-сервисы. 

Костыль как архитектурная стратегия. Почему лучший способ улучшить сложную систему — не ломать её, а строить новые модули рядом. Примеры из IT, градостроения и биологии.

Разбираем, почему 95% корпоративных ИИ-пилотов проваливаются, и как внедрить систему метрик, которая гарантирует результат в условиях новой российской реальности.

Почему ваш ИИ-проект съедает бюджет, но не дает ROI?

Коротко: Статистика MIT неумолима: 95% ИИ-пилотов в корпорациях проваливаются. При этом бюджеты на них только растут.

Главный вывод: Дело не в технологии, а в том, ЧТО и КАК мы измеряем. Мы гонимся за точностью модели, а не за снижением издержек.

В статье я показываю, как перестать сжигать деньги и заставить ИИ работать на бизнес.

Что внутри:

Три реальных провала (банк, ритейл, производство) и их общая системная ошибка.

Семимерная модель метрик, которая смещает фокус с «технологии ради технологии» на реальный бизнес-эффект (с поправкой на российские реалии).

Готовый инструментарий руководителя: чек-лист, карта рисков, ROI-калькулятор.

Без «воды» и пустых обещаний. Только анализ, система и практика.

Альтернативная нотация описания функциональной архитектуры и архитектуры интеграций для решения задач ИТ-развития в рамках проектных задач, продуктового развития и инициатив бизнеса для командной работы в едином информационном поле бизнес и системных аналитиков, архитекторов, разработчиков, тестировщиков и специалистов поддержки.

ArchiMate — это язык моделирования архитектуры предприятия. Я часто о нём слышал, но никогда не пользовался. Он казался мне очень сложным с очень странной солянкой из разносортных объектов, с замороченным десктопным редактором. Изначально мы даже не рассматривали ArchiMate как первый кандидат на реализацию в нашем инструменте моделирования, а больше склонялись к моделям данных, C4, UML, BPMN. И добавили эту нотацию совершенно случайно. Но пока рисовали примеры моделей для статьи я просто обалдевал на сколько ArchiMate клёвый, какими гениями он придуман и зачем ИТ архитекторам могут быть нужны ещё какие‑то языки моделирования.

Мы попробовали описать разные аспекты нашего программного продукта в этой нотации от миссии и стратегической карты до сценария резервного копирования базы данных. В итоге у нас получилось что‑то среднее между небольшим руководством по ArchiMate и тупой неприкрытой саморекламой. Решайте сами полезно для вас это или нет. Статья получилась очень объёмная, смело пролистывайте не интересные разделы.

Когда вы работаете с прерываниями это всегда асинхронное программирование. Прерывания асинхронны по отношению к фоновой программе по определению. Но если вы сосредоточитесь только на решении проблем асинхронного программирования вы скорее всего потеряете все остальные составляющие работоспособного, хорошего-надежного, расширяемого-управляемого решения вашей задачи.

Это небольшое дополнение к статье Проект по Air Quality sensor, идея, концепция, дизайн и почти: реализация. Если вы её не читали, то лучше начать с неё, будет понятна предыстория и как развивалась концепция взаимодействия с пользователем и AQ. А мы пойдем по классикам и коротко разберем, разработку проекта от потребностей до дизайна.