🧩 AI Design Patterns: GoF для эры ИИ

Ух, давно не писал – был в режиме deep work 🔥
Сейчас погрузился в Patterns for Modern AI Systems – есть чем поделиться. Поэтому сегодня пост про то, как в AI складывается свой "дизайн-паттернс".

Помните GoF (Gang of Four) и их легендарные Design Patterns 1994 года? 23 шаблона дали разработчикам общий язык и избавили от изобретения велосипеда. Сейчас похожий словарь складывается в AI-разработке.

TL;DR:

➡️

В AI уже сформировались

повторяемые паттерны

– готовые решения для типовых задач

➡️

Пять слоев

: Prompting & Context, Responsible AI, UX-паттерны, AI-Ops, Optimization

➡️

Как GoF для ИИ

: общий словарь, меньше ошибок, быстрее в продакшн

➡️

Думайте об этом как о

"микросервисах для искусственного интеллекта"

О чем этот пост (и о чем не говорим)

Фокус на пользовательских приложениях поверх готовых моделей через API.
Не затрагиваем: тренинг моделей, хостинг, квантование, (мульти)агентные системы – это отдельные большие темы.

Зачем вообще паттерны в AI?

Как когда-то GoF и облачные паттерны (pub/sub, event-driven, serverless) ускорили разработку, так и в ИИ появляются стандартные приёмы.

Разница в том, что AI решает задачи, которых раньше просто не было: как направлять модель на нужный результат, как объяснять её ответы пользователю, как удерживать стоимость в разумных пределах.

Пять слоев AI-паттернов

➡️Слой 1 – Prompting & Context
"Направь модель и дай ей знать больше"

– Шаблоны промптов с явной ролью, задачей и критериями качества
– Контекст-инжиниринг: RAG, knowledge snippets прямо в запрос
– Ограничения: формат ответа, шаги верификации, примеры

➡️Слой 2 – Responsible AI
"Меньше галлюцинаций, больше доверия"

– Фильтры до/после, факт-чекинг, цитирование источников
– Политики контента и детект запрещённого контента
– Снижение bias и прозрачность: логи решений, объяснимость

➡️Слой 3 – UX-паттерны
"Новые интерфейсы для новых диалогов"

– AI предлагает → человек правит: история изменений, версионность
– Метки неопределённости: источники, уровень уверенности
– Умные кнопки: "уточнить", "расширить", "сжать", "проверить факты"

➡️Слой 4 – AI-Ops
"Как управлять ИИ на масштабе"

– Версионирование промптов и конфигов, A/B тесты, канареечные релизы
– Наблюдаемость: метрики качества, латентности, отказов; алерты
– Отказоустойчивость: фолбэки, ретраи, квоты, умный роутинг

➡️Слой 5 – Optimization
"Баланс качества и цены"

– Умный роутинг на подходящую модель (не все через "самую большую" – GPT5 привет)
– Производительность: кэш, батчинг, стриминг
– Специализированные (под домен) модели там, где это окупается

Почему это важно прямо сейчас

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

🟢

Индустрия AI переживает тот же процесс стандартизации, что и веб-разработка 20 лет назад

. Кто освоит паттерны раньше и будет их правильно использовать – получит конкурентное преимущество.

😀😃😄😁😅😂🤣😊
😇🙂🙃😉😌😍🥰😘
😗😙😚😋😛😝😜🤪
🤨🧐🤓😎🤩🥳😏😒

🔗Полезное чтиво на тему: Beyond the Gang of Four: Practical Design Patterns for Modern AI Systems

#AI #DesignPatterns #TechStrategy #Development

🧠 Почему ИИ уверенно фантазирует и что с этим делать

Меня часто спрашивают: «Зачем нам эти LLM, если они периодически несут чушь и все придумывают?».
Вопрос справедливый! Да, модели иногда уверенно фантазируют – и на это есть нормальные причины в данных и в том, как мы их оцениваем

В этом посте разберем, откуда берутся «уверенные промахи» и как простыми инженерными приемами (пороги уверенности, RAG-правила, калибровка, UX/Ops) сделать так, чтобы ошибочных ответов стало заметно меньше, а пользы – больше 🙃

TL;DR

➡️

Модели часто угадывают, когда не уверены — как студент на экзамене с оценкой «правильно/неправильно». А бенчмарки это поощряют...

➡️

Есть класс вопросов, где нет закономерности (типа «дата рождения X»). Если факт встречался в данных 1 раз, ниже которого модель падает трудно – это singleton rate

➡️

Формально: ошибки генерации связаны с ошибками бинарной классификации (Is-It-Valid). Если путаем «валидно/невалидно», галлюцинации неизбежны

➡️

Решение – менять стимулы: не штрафовать “не знаю”, вшивать пороги уверенности и проверять поведенческую калибровку

Где ломается логика

Представим экзамен: за правильный ответ – 1, за пустой – 0. Угадывать выгоднее, чем промолчать. Так же и с LLM: большинство оценок – бинарные, то есть модель отвечает либо «правильно», либо «неправильно». А вариант IDK (I don't know / «я не знаю») не учитывается. Результат: модель учится всегда что-то говорить.

Техническая сторона

- Редукция к классификации. Генерацию можно представить как простую проверку «валидно/невалидно» (Is-It-Valid). И чем чаще система ошибается в такой проверке, тем выше шанс, что в тексте появятся галлюцинации
- Singleton rate (Good–Turing-интуиция). Если заметная доля фактов в корпусе встретилась один раз, то по таким запросам ожидаем сопоставимую долю промахов – база просто не успела «выучить» закономерность
- Пост-тренинг не спасает, если метрика против «IDK». Пока лидерборды награждают «смелые догадки», система будет учиться блефовать.
- RAG ≠ серебряная пуля. Поиск снижает часть ошибок, но как только поиск не дал уверенного сигнала, бинарная оценка снова толкает к «уверенной догадке»

Что с этим делать?

1️⃣ Разрешить «не знаю»
В проде и на внутренних тестах вводим порог уверенности: «Отвечай только если ≥t, иначе — краткое “не знаю/нужен поиск”». И перестаем штрафовать за воздержание. Это резко снижает соблазн «уверенно фантазировать»
2️⃣ Показывать основания
По умолчанию – ссылки/цитаты из RAG. Нет надежных источников, то следуем по правилу – «не знаю». Поиск и рассуждение помогают, но не отменяют стимул угадывать, если оценка настроена неправильно
3️⃣ Мерить правильные метрики
Имеет смысл добавлять поведенческую калибровку: для набора порогов t сравнивать точность среди ответов и долю воздержаний – модель должна последовательно «молчать» ниже порога.
4️⃣ UX-паттерны для честности
Кнопки «проверить факты», «уточнить», бейджи уверенности и явные «источники». Если уверенность низкая – просим подтверждение пользователя (human-in-the-loop)
5️⃣ Ops-практики
Фолбэки на более «надежную» модель/человека при низкой уверенности, ретраи, алерты. Это про процессы, а не только про модель

Немного тонкостей

- Плохая модель vs плохие данные. Ошибки бывают из-за «формы» модели (например, токенизация мешает посчитать буквы) и из-за GIGO (мусор в корпусе)
- Комплексность задач. Есть классы запросов, где «лучше не отвечать» – вычислительно тяжелые/инвертирование шифрования и т. д. и т. п. Это теоретически обосновывается там, что там тоже будет тянуть на ложные догадки
- Калибровка: база vs после RL. Базовые модели обычно честнее в своей уверенности, а пост-тренинг под бинарные метрики уводит в «гиперуверенность» — то самое ощущение «говорит уверенно, но мимо»

Короткая мысль напоследок:

🟢

Галлюцинации – не «прихоть модели», а следствие статистики и наших же метрик.

Перестанем наказывать «не знаю» – модели станут реже «уверенно врать» и чаще вести себя как полезные ассистенты.

🔗Рекомендую почитать: исследование OpenAI –Why language models hallucinate, меня оч вдохновило :)

#AI #LLM #AITrust #TechStrategy

Интернет шутит мемами про «вечный генератор денег», но история куда глубже

Пара мыслей:

1️⃣ Compute становится новой энергией XXI века. 10 гигаватт – это масштаб национальных энергосистем, теперь перенесённый в ИИ-датасентры.

2️⃣ $100B от NVIDIA в OpenAI — не про деньги сами по себе, а про закрепление вертикальной интеграции: от GPU → до облаков → до AGI.

3️⃣ 2026 год, запуск Vera Rubin – точка отсчета следующего уровня конкуренции: кто контролирует вычислительные фабрики, тот контролирует темпы прогресса.

А мемы все равно хороши 😁

🤖 From Prompts to Context: почему это важно для AI-агентов

Несколько лет мы фокусировались на идеальных промптах – подбирали правильные слова и формулировки. Но сейчас фокус сместился: важнее не конструкция промпта, а набор контекста, который даст модели нужное поведение.
Разберем, как эффективно управлять контекстом и почему это ключ к надежным агентам 🙂

Кстати, еще в июле я упоминал Context Engineering как один из ключевых трендов 2025 – и вот сейчас самое время разобрать его подробнее.

TL;DR

➡️Контекст-инжиниринг – это эволюция промпт-инжиниринга: управление всем набором токенов (инструкции, инструменты, история, данные), а не только текстом промпта
➡️У LLM есть "бюджет внимания" – чем больше токенов, тем хуже модель извлекает информацию (context rot). Контекст = конечный ресурс
➡️Эффективный контекст – это минимальный набор токенов с высокой информационной ценностью. Системные промпты должны быть на оптимальном кровне абстракции
➡️ Агентский поиск: вместо загрузки всех данных заранее, агенты используют "just-in-time" стратегию – динамическая загрузка через инструменты

Почему контекст-инжиниринг критичен
Раньше промпт-инжиниринг работал для one-shot задач – классификация, генерация текста. Но современные агенты работают в циклах, на длинных горизонтах, накапливая все больше данных. И тут появляется проблема: context rot – чем больше токенов в окне контекста, тем хуже модель достает нужную информацию.
Исследования и здравый смыслпоказывают: модели теряют точность при росте контекста (некоторые деградируют плавнее). Причина – в архитектуре трансформеров: каждый токен "смотрит" на все остальные, создавая n² связей. Чем больше n, тем меньше внимания приходится на каждый отдельный токен. Плюс модели обучались на коротких последовательностях – у них меньше опыта с длинным контекстом.

Анатомия эффективного контекста

Задача:

найти минимальный набор токенов с высокой информативностью

, который максимизирует вероятность нужного результата.

1️⃣Системные промпты: "оптимальный уровень абстракции"
Есть две крайности: хардкодить хрупкую логику (if-else в промптах) или писать размытые инструкции. Золотая середина: достаточно конкретно для направления, но гибко для эвристик. Структурируйте промпт (JSON/XML-блоки, Markdown-заголовки), но делайте его минимальным и достаточным.
2️⃣ Инструменты: эффективность и четкость
Инструменты – контракт между агентом и средой. Они должны возвращать токен-эффективные результаты и поощрять эффективное поведение.
Классическая проблема: раздутый набор инструментов с перекрытием функций. Если человек не может точно сказать, какой инструмент использовать, агент тоже не сможет (пока что)
3️⃣ Примеры: качество > количество
Few-shot промптинг работает, но не стоит учитывать все edge-случаи. Лаконичный набор разнообразных
канонических примеров – вот что нужно. Для LLM пример = образ желаемого результата.

Агентский поиск и "just-in-time" контекст
Старый подход: embedding-based retrieval до инференса – достать все заранее.
Новый тренд: "just-in-time" – агенты хранят легкие идентификаторы (пути к файлам, ссылки, запросы) и динамически загружают данные в runtime через инструменты.

Claude Code

анализирует большие базы данных, не загружая их в контекст

– пишет целевые запросы, сохраняет результаты, использует bash-команды.

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

🟢

Контекст-инжиниринг – это не про идеальный промпт, а про вдумчивую курацию информации на каждом шаге. Ключевой принцип:

контекст – драгоценный, конечный ресурс.

🟢

Во второй части разберем техники для долгих задач

: компакцию, агентскую память и мульти-агентские архитектуры

🔗 Рекомендую почитать: оригинальный пост Anthropic Effective context engineering for AI agents

#AI #LLM #Agents #ContextEngineering #TechStrategy

Интересно 👀

Фактически это шаг к унификации экосистемы MCP / ToolCalling / Eval – теперь агентские сценарии можно строить как обычные low-code-флоу внутри ChatGPT.

И да, не только пользователи ComfyUI могут радоваться – навыки LangFlow, Flowise, n8n теперь тоже на вес золота 😁

🟢Low-code + AI постепенно становится новым стандартом для сборки ассистентов и внутренних агентов.

Запись OpenAI Dev Day

🦆Собираю команду!

Недавно я присоединился к Альфе. Мы строим AlfaGen – core-AI-платформу, связывающую модели, данные, инфру и корпоративные сервисы в единую систему

Все, что показывают на конференциях – у нас в проде:
agentic AI, RAG, context engineering, guardrails, безопасность, интеграции.

Сейчас усиливаю команду продукта – среды, где пользователи могут проектировать и запускать AI-агентов, LLM-сценарии и пайплайны. Agent Builder из прошлого поста – привет :)

Ищу:

➡️Senior System Analyst – проектировать интеграции и потоки данных, собирать архитектуру под AI-сценарии, видеть систему целиком

➡️Senior Python Developer – строить инфраструктуру для AI, интегрировать LLM в банк, решать задачи на стыке классического backend и AI

Почему это крутая возможность:

➡️Cutting-edge стек
➡️Задачи, которые еще нигде не решали
➡️Сразу в прод, сразу в масштабе
➡️Реальный impact на тысячи пользователей

Если вы читали мои посты и думали "

хочу так же

" – вот шанс

😎

Пишите в личку, расскажу все детали: @dmrtnv

😀😃😄😁😅😂🤣😊
😇🙂🙃😉😌😍🥰😘
😗😙😚😋😛😝😜🤪
🤨🧐🤓😎🤩🥳😏😒

#AI #Hiring #AgenticAI #LLM

🌩️ Когда DNS решил сыграть в самоуправление: как упал регион AWS us-east-1

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

➡️В ночь с 19 на 20 октября 2025 года сбой в Amazon DynamoDB обрушил целый регион N. Virginia (us-east-1) – ключевой узел инфраструктуры AWS.
В течение 15 часов крупнейшие сервисы, от Reddit до Perplexity, работали с перебоями.

▶️ С чего все началось
DynamoDB – не просто база, а сердце внутренней экосистемы AWS.
Через нее проходят миллиарды запросов, и множество сервисов (EC2, Lambda, Redshift, IAM) опираются на нее как на системный реестр.
Чтобы все это держалось, у DynamoDB есть своя автоматика управления DNS. Она поддерживает сотни тысяч записей для IPv4, IPv6, FIPS-эндпоинтов, аккаунтов, подсетей.

Эта автоматика состоит из двух компонентов:

DNS Planner

– планирует и формирует «карты DNS», распределяя балансировщики и веса.

DNS Enactor

– применяет эти планы в Route 53 и делает это параллельно, из трех зон доступности.

Звучит надежно: три независимых процесса, каждая зона применяет свой план транзакционно.
Но вот ключевая деталь, между ними не было центральной синхронизации времени и версий ❗️

▶️ Race condition
Ночью один Enactor залип, из-за случайных сетевых задержек он застрял, применяя план.
Пока он думал, Planner успел нагенерить несколько новых версий, а другой Enactor быстро их применил.
Все шло по плану, пока не сработала финальная часть – очистка старых DNS-планов.

Быстрый Enactor удалил старые версии, включая ту, что все еще «применял» медленный.
И вот этот медленный проснулся и, ничего не подозревая, внес свой старый план, фактически пустой DNS для регионального эндпоинта.
– Система осталась без IP-адресов.
– DynamoDB перестала существовать для всего, кто к ней обращался.

▶️ Цепная реакция
EC2 перестал запускать новые инстансы: менеджеры физических серверов (Droplet Workflow Manager) потеряли связь с метаданными в DynamoDB, из-за чего очередь задач быстро вышла из-под контроля – миллионы ошибок “insufficient capacity”.
Network Load Balancer (NLB) повел себя нестабильно: новые EC2-инстансы создавались, но не получали сетевую конфигурацию, а подсистема health-check считала их недоступными.
Балансировщики поочередно исключали и возвращали узлы в DNS, что вызвало массовый флап и деградацию сервисов.
Lambda, ECS и EKS пострадали по той же причине: функции не создавались, контейнеры не поднимались, очереди SQS/Kinesis застревали.

IAM и Console Login на время перестали работать.

Инженеры AWS просто не могли авторизоваться, чтобы чинить все остальное.
Да, система отказоустойчивая… но не от самой себя.

🕒 Как чинили
К утру инженеры вручную восстановили DNS-записи.
DynamoDB вернулась в онлайн к 2:25 AM, но EC2 и NLB продолжали задыхаться еще несколько часов, пока не почистили бэклоги и не пересоздали сломанные сессии.

Полная стабилизация только к 1:50 PM 20 октября.

15 часов на восстановление региона, который питает сотни тысяч продакшн-систем.

🔍 Что AWS меняет
Amazon уже пообещали:

➡️переписать DNS Planner/Enactor, чтобы исключить race condition-сценарий
➡️добавить velocity control в NLB – ограничивать, сколько узлов можно погасить за раз при флапе
➡️улучшить стресс-тестирование EC2 Droplet Manager, чтобы он не падал при массовом восстановлении
➡️доработать троттлинг и graceful degradation механизмы для высоких нагрузок

Даже у гигантов уязвимость лежит в слое координации

🟢

Это не просто инцидент – это зеркало эпохи «инфраструктуры, которая управляет собой».

🟢

Мы все глубже автоматизируем сложные процессы, но сложность никуда не девается – она просто прячется внутри слоя автоматики. И

пока автоматика не умеет сомневаться в себе –

нам все равно нужен человек, который умеет

выдергивать шнур и чинить вручную

😉

🔗 Детальный постмортем-разбор можно посмотреть здесь

#AWS #DynamoDB #Cloud #TechStory

Когда AI решил поработать без человека: что скрывается внутри отчета Anthropic

Сегодня наткнулся на любопытный разбор от Anthropic. Это подробно описанный случай автономной AI-атаки, где система работала почти как самостоятельный техпроцесс: сама проводила разведку, искала уязвимости, тестировала доступы, двигалась по сети, анализировала данные и вела отчетность – при минимальном участии человека.

➡️Суть в том, что исследователи нашли архитектуру, которая превращает AI не в ассистента, а в автономный модуль, выполняющий 80–90% атакующих действий самостоятельно – со скоростью и масштабом, с которыми один человек никогда бы не справился.
И больше всего меня впечатлило именно то, как эта атака была спроектирована внутри

➡️Архитектура
Внутри был собран полноценный autonomous cyber attack framework – система, где Claude Code выступает runtime-слоем, MCP-инструменты – манипуляторами, а оркестратор – мозгом, который режет операцию на сотни мини-шагов.
🟢Каждая задача выглядела абсолютно легитимно: “проверь конфиг”, “проанализируй API”, “проведи тест подключения”, “построй карту сети”.
🟢Модель исполняла их как обычную техническую работу – она не видела всей атаки целиком благодаря хитрой изоляции контекста.
🟢Оркестратор держал состояние кампании, управлял фазами (разведка → взлом → закрепление → вынос данных) и сшивал ответы AI в единый поток действий.
🟢AI сам: искал сервисы, находил уязвимости, разрабатывал эксплойты, тестировал доступы, двигался по внутренней сети, извлекал данные, классифицировал ценность украденного, вел документацию в markdown.

При этом люди участвовали только на 10–20%: в стратегических точках, типа «разрешить эксплуатацию», «разрешить использование новых кредов», «разрешить вынос данных».

➡️Масштаб и темп
Anthropic в отчете приводит реальные цифры:
– пик активности – тысячи запросов, устойчивые несколько операций в секунду
– в атаке одновременно участвовало несколько десятков целей
– AI вел несколько параллельных контекстов, не путая кампании
– эксплойты AI разрабатывал за 1–4 часа, проверка человеком занимала 2–10 минут
– извлечение и анализ данных – 2–6 часов полной автономии

AI не просто ломал – он сам дотягивал атаку до конца, включая: создание бэкдор-аккаунтов, построение карт привилегий, доказательство работоспособности эксплойтов, генерацию отчета и аналитики, подготовку handoff другим командам и т.п.

Это похоже на подрядчика, который ведет операцию от разведки до передачи доступа следующей группе.

➡️Вся система была собрана на обычных open-source инструментах: стандартные сканеры, фреймворки эксплуатации, утилиты паролей, браузерные MCP-инструменты, проверки конфигов, тестеры API.

То есть сила не в каком-то “супервирусе”, а в архитектуре и автоматизации: простые инструменты + AI как рантайм + оркестратор = система, которая выполняет работу целой команды.
И да – такую архитектуру сможет повторить все больше групп, просто потому что компоненты общедоступны.

🔒Что это значит для защиты
Anthropic в отчете пишут прямым текстом: автономные атаки – уже реальность, и стандартные SOC/SIEM-процессы под такой темп не успевают.

Чтобы оборона была адекватной, нужно реализовать:

1) Раннее выявление автономных цепочек
Детекторы должны ловить аномальный темп, последовательные технические шаги, работу через MCP-инструменты и нетипичное поведение модели.
2) Поведенческий анализ AI-активности
Важно отслеживать не содержание команд, а форму деятельности: повторяющиеся операции, скачки нагрузки, многозадачные контексты.
3) AI в защитном контуре
Anthropic подчеркивают: те же свойства, которые позволяют AI проводить атаки, нужны и для защиты – AI-наблюдатели, фазовая аналитика и автоматические реакции.

Иначе скорость атаки будет выше скорости реагирования.

🔗 Отчет Anthropic тут

#AI #CyberSecurity #AgenticAI #ThreatIntelligence #TechStory

❤️Новая экономика и агенты: влияние на бизнес и технологии

26 ноября обсудим, как агентные системы уже меняют бизнес-процессы и почему в 2025–2026+ это станет нормой, а не экспериментом.

О чем митап:

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

Будут крутые спикеры из red_mad_robot, Yandex Cloud, Wildberries & Russ.

📅 26 ноября, 16:30–18:30
🌐 Онлайн

Если хотите лучше понять «как это работает на самом деле» – подключайтесь. Будет полезно 😉

#AI #AgenticAI #AlfaGen

🖥 Как AI меняет работу инженера: кейс Anthropic

Мы часто обсуждаем экономику AI в целом. Но Anthropic пошли другим путем – они изучили, как их собственные инженеры на самом деле используют AI в повседневных задачах.
132 опрошенных, 53 глубинных интервью, логи Claude Code – отличный срез того, как меняется инженерная профессия, когда мощная модель встроена в каждый рабочий день.

По сути, это предпросмотр того, как будет выглядеть индустрия в ближайшие годы.

TL;DR

➡️За год использование Claude выросло с 28% до 60% рабочего времени – двухкратный рост
➡️27% работы с Claude – задачи, которые вообще не делались бы без AI
➡️Инженеры расширяют зону компетенций за пределы привычных ролей; при этом часть команды отмечает риск потери глубины – парадокс компетенций обостряется
➡️Роль смещается к управлению AI-агентами, но «полностью делегировать» можно лишь 0-20% работы
➡️Командные паттерны меняются: меньше вопросов коллегам, меньше менторства

🔴Что происходит с работой
Claude теперь участвует почти во всех задачах: дебаг, разбор чужого кода, черновики фич, тесты, документация и те самые пэйперкаты, которые годами лежали в бэклоге.
Любопытно, что часть задач просто не существовала бы без AI. Около четверти – это nice-to-have фичи и исследовательские штуки, которые раньше не окупали время инженера.

🔴Переход от I-shape к T-shape ролям
AI снижает барьеры входа в смежные области. Бэкендеры пилят UI, ресерчеры собирают дашборды, безопасники быстро погружаюстя в новые сервисы. Страх «это серая зона» заменяется быстрым диалогом с моделью. В результате каждый ощущает себя чуть более full-stack, а цикл идея → прототип → проверка значительно сокращается.

🔴Что происходит с глубиной инженерных навыков
У части инженеров появляется ощущение потери глубины знаний – и это становится обсуждаемым риском Когда черновик кода делает модель, меньше поводов руками проходить дебаг, читать доку, разбираться в архитектуре.
Возникает парадокс: чтобы эффективно и безопасно использовать AI, нужны как раз те самые глубокие навыки, которые он частично вытесняет. Поэтому ключевой вопрос – как развиваться так, чтобы сохранять способность и писать качественный код, ревьюить его, и удерживать архитектурный контекст, не превращаясь в пассивного оператора модели.

🔴Меняется командная динамика
Раньше первый шаг был: «спрошу коллегу». Сейчас: «спрошу Claude».
Плюс: вопросы стало проще задавать, исчезает ощущение, что отвлекаешь людей по пустякам.
Минус: спонтанного менторства становится меньше, особенно для джунов. Скорость растет, но привычные способы учиться друг у друга требуют переосмысления.

🔴Сдвиг роли: от кода к оркестрации
Многие инженеры описывают свою работу как управление несколькими инстансами Claude и проверку результата.
Меньше классического кодинга – больше постановок задач, выбора подходов, проверки и принятия решений.
Большинство могут «полностью делегировать» только 0-20% своей работы Claude. То есть модель используется в 60% времени, но почти всегда требует контроля, особенно в критичных задачах. Claude помогает работать быстрее и масштабнее, оставаясь под присмотром человека. Однако чем выше темп развития моделей, тем заметнее становится вопрос: какой будет инженерная роль через несколько лет?

🟢Anthropic – компания с ранним доступом к самым мощным моделям и высокой культурой экспериментов. Поэтому их опыт – это показательный ориентир.
Если убрать названия, останется простая мысль: AI уже перестраивает профессию инженера. Не когда-нибудь – сейчас. Меняются навыки, привычки, способы сотрудничества, ожидания от себя.

🔗 Почитать подробнее можно тут

#Anthropic #AIEngineering #AIProductivity

LLM-кэширование без Exact Match: архитектура семантического кэша

В традиционных детерминированных системах кэширование по ключу – это просто: key=user_123. Совпало байт-в-байт, отдали. В мире LLM Exact Match практически бесполезен. Его Hit Rate обычно очень низкий (часто единицы процентов). Пользователи креативны: «Как сменить пин-код?», «Хочу поменять пароль от карты», «Забыл пин, что делать?».

Для обычного кэша это три разных ключа. Вы трижды платите за генерацию и трижды заставляете юзера ждать. Хотя интент один. Решение – Semantic Caching. Кэшируем не текст, а вектор намерения.

TL;DR

➡️Семантический кэш сравнивает векторы (embeddings) запросов.
➡️Если сходство выше порога, то отдаем сохраненный ответ.
➡️Latency: падает с секунд до десятков миллисекунд.
➡️Cost: в сценариях типа FAQ/Helpdesk можно срезать косты на 30–50% (зависит от домена).
➡️Риск: устаревание (Data Staleness) требует обязательной инвалидации по версии промпта/модели.

▶️ Как это работает под капотом: вместо текста ключом становится вектор.

🔵Прогоняем запрос через легкую модель, например text-embedding-3-small.

🔵Ищем семантически похожие запросы в векторной базе (Redis VSS, Qdrant).

🔵Если нашли запись с similarity > 0.98+ (в критичных доменах, порог подбирается строго на валидации), отдаем кэш.

Мы меняем дорогую генерацию на дешевый поиск (Retrieval).

▶️ Экономика наглядно:

🔵Без кэша: Входящий запрос + Генерация GPT-4o ≈ $0.005 + 2–3 секунды.

🔵С кэшем: Эмбеддинг (копейки) + Поиск в Redis ≈ $0.00001 + 50–100 мс.

🔴Ловушка №1: Контекст и PII
Семантический кэш – это прямминное поле. Если один пользователь спросил «Какой у меня баланс?», а вы это закэшировали… следующий увидит чужие деньги.

Решение:
– Не кэшировать запросы с PII (перед записью нужен PII-фильтр/классификатор).
– Сегментировать кэш: ключ должен включать Vector + Tenant_ID + User_ID (или Session_ID). Ответы для разных клиентов, каналов и ролей должны храниться изолированно.

🔴Ловушка №2: Уставревание (Staleness)
Кэш может начать врать незаметно. Вы обновили системный промпт (например, поменяли tone-of-voice) или обновили документацию, а кэш отдает старое.
Решение: добавлять в ключ версию промпта и модели (prompt_v2 + model_n) и выставлять жесткий TTL. Инвалидация в векторах сложная, поэтому лучше промахнуться мимо кэша, чем отдать устаревший регламент.

🔴Ловушка №3: Ложные срабатывания Векторы ищут похожесть, а не тождество.
Вопросы «Я люблю яблоки» и «Я не люблю яблоки» могут иметь высокий скор близости, но требовать разных реакций.
Аксиома инженера: ошибка кэша (false positive) опаснее, чем промах. Лучше заплатить за лишнюю генерацию, чем отдать клиенту неверную информацию. Поэтому пороги часто задирают до 0.98+.

💡 Pro Tip: Shadow Mode
Не включайте кэш сразу на выдачу. Запустите его в «теневом режиме»: считайте векторы, логируйте совпадения (similarity score), но не отдавайте ответ пользователю. Посмотрите логи неделю. Часто оказывается, что дефолтный порог слишком оптимистичен. Калибруйте систему на реальном трафике, прежде чем доверить кэшу общение с клиентом.

Ну и конечно инструменты не нужно писать это с нуля 🙂

GPTCache – популярный фреймворк, который берет на себя логику кэширования.
Redis VSS – архитектурно удобный вариант для масштабирования вектора, если вы уже используете Redis.
Qdrant – отличная векторная БД для similarity search + фильтры по метаданным; часто удобнее как отдельный сервис под векторы.

Если LLM-сервис тормозит и сжигает бюджет – проверьте хит-рейт. Возможно, вы генерируете одни и те же ответы тысячи раз подряд.

#SemanticCache #LLMOps #HighLoad #AIArchitecture #CostOptimization

@mrtnv_prism

⚡️ NVLink и InfiniBand: Нервная система AI-кластера

Мы привыкли оценивать мощность AI в флопсах. Но когда вы строите кластер для обучения LLM (будь то 8 карт в сервере или 1000 карт в стойках), узким местом становится не вычисление, а коммуникация. Если H100 ждет данные, вы сжигаете бюджет впустую.

Чтобы масштабировать обучение, индустрия построила поверх стандартного x86 отдельную высокоскоростную фабрику.

TL;DR

➡️Обучение требует постоянной синхронизации градиентов. Классический стек (TCP/IP + PCIe) слишком медленный и вносит джиттер.
➡️NVLink (Intra-node): снимает ограничения PCIe внутри узла. Превращает 8 GPU в единый fabric с пропускной способностью 900 ГБ/с.
➡️InfiniBand / RoCE: использует GPUDirect RDMA, чтобы писать данные из памяти одной GPU в память другой, минуя CPU и ОС (в data path).
➡️Программный клей: библиотека NCCL использует эти каналы для эффективных коллективных операций.

✈️Уровень 1: NVLink (внутри сервера)
В стандартной архитектуре GPU общаются через PCIe. Даже Gen5 x16 дает лишь ~64 ГБ/с (на направление). Этого мало для современных топологий Model Parallelism. NVLink 4-го поколения до 900 ГБ/с (агрегированно, в обе стороны) на GPU.
– Роль NVSwitch: внутри серверов (типа HGX H100) коммутатор NVSwitch позволяет каждой карте обращаться к HBM-памяти соседа с небольшой и предсказуемой задержкой.
– Результат: это еще не физически общая память, но доступ к remote-HBM становится настолько быстрым, что для алгоритмов распределения узел выглядит как единое вычислительное поле.

✈️Уровень 2: InfiniBand и RDMA (между серверами)
Когда нужно соединить стойки, обычный TCP/IP становится проблемой из-за накладных расходов ядра ОС и непредсказуемых задержек (джиттера). Решение – RDMA (Remote Direct Memory Access). Самый популярный стандарт здесь InfiniBand (например, NDR 400 Gb/s), хотя в дата-центрах используют и RoCE (RDMA over Converged Ethernet).
– GPUDirect RDMA: это «киллер-фича». Сетевая карта (NIC) пересылает данные напрямую из памяти GPU в сеть.
– OS Bypass: CPU и OS исключаются из тракта передачи данных (Data Path) после начальной настройки. Никаких лишних копирований в буферы, никаких прерываний.
– Latency: мы получаем стабильные микросекунды end-to-end задержки, что критично для синхронизации тысяч карт.

✈️Топология: Compute Fabric и Rail-Design
Если вы посмотрите на заднюю панель DGX H100, вы увидите не один порт, а лес кабелей. Помимо управления и Storage-сети, там выделено 8 портов ConnectX-7 (400Gb/s) специально под Compute Fabric. Это реализация Rail-Optimized Topology.
– Принцип: мы не смешиваем трафик. NIC №1 первого сервера соединяется с NIC №1 второго сервера через свой отдельный коммутатор (Rail 1). NIC №2 через Rail 2, и так далее.
– Зачем: это снижает интерференцию потоков и делает полосу пропускания предсказуемой. Вместо одной толстой трубы, где потоки борются за приоритет, мы получаем 8 параллельных шоссе для 8 GPU.

✈️Зачем это все? (NCCL)
Вся эта железная магия нужна для одной штуки: чтобы библиотека NCCL могла выполнять операции All-Reduce (усреднение градиентов) параллельно с вычислениями Без NVLink и GPUDirect коммуникация съедала бы 50% времени обучения. С ними она становится почти прозрачной для вычислительного процесса.

🟩

В итоге мы строим одну гигантскую виртуальную видеокарту размером с дата-центр. Благодаря NVLink и InfiniBand границы физических серверов стираются. Для модели нет

сервера А

и

сервера Б

–

есть единое поле памяти и вычислений

, где CPU и OS являются сервисным слоем.

#AIInfrastructure #HPC #NVLink #InfiniBand #GPUDirect #NCCL

@mrtnv_prism

💻 OpenAI запустили Prism. Название отличное, осталось проверить, как это работает в полевых условиях

➡️Давайте честно: написание научной работы – это обычно хаос из открытых вкладок, борьбы с оформлением и бесконечных правок от соавторов. В OpenAI решили упростить этот процесс и представили Prism.

Если коротко: это рабочее пространство для учёных и исследователей на базе GPT-5.2.

↗️Минутку, а что такое LaTeX и зачем он нужен?
Если вы не из мира науки, слово «Латекс» может вызвать не те ассоциации. На самом деле:
LaTeX – это стандарт оформления научных текстов.
В отличие от обычного Word, где вы просто печатаете текст, в LaTeX вы используете специальные команды (похоже на код), чтобы формулы, графики и таблицы выглядели идеально.
Это супер-удобно, но сложно: обычно ученым приходится устанавливать дополнительный софт и мучиться с настройкой. Prism должен сделать LaTeX чуть более «человечным»: вы просто пишете, а AI и облачная платформа берут всю техническую головную боль на себя.

↗️Что умеет Prism?
– Cloud-native LaTeX-среда
Не нужно разворачивать локальные дистрибутивы (привет, TeX Live) и мучиться с конфигурацией компиляторов и шрифтов. Весь рендеринг и управление зависимостями уходят в облако.
– Контекст через GPT-5.2
Фишка в том, что модель видит всю работу целиком. Это помогает следить за логикой: чтобы переменные в формулах на 2-й и 20-й страницах не противоречили друг другу..
– Работа с источниками
Встроенный менеджер ссылок. По идее, должен избавить от ручного вбивания библиографии, что всегда было самой нудной частью.
– Коллаборация
По сути, это Google Docs, но адаптированный под формулы и сложную верстку. Больше не нужно париться с версиями.

↗️Почему это круто?
Обычно научный процесс – это «зоопарк» из инструментов: расчеты в одном месте, черновик в другом, верстка в третьем. Prism пытается собрать этот стек в одном окне.
По аналогии с тем, как в 2025-м AI-ассистенты только начали менять подход к разработке ПО, здесь мы видим попытку оптимизировать рутину для исследователей.

🟢

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

Попробовать Prism можно здесь
Цена вопроса: для всех, у кого есть аккаунт ChatGPT, инструмент бесплатен уже на старте.

#OpenAI #Prism #Science #AI #LaTeX #Research #Productivity

💳 Немного апдейтов по команде и вакансиям

Помните мой пост про сбор команды в Альфу? С того момента мы не просто продвинулись – мы знатно замасштабировались. Платформа обрастает новыми фичами, пользователями и кейсами быстрее, чем мы успеваем обновлять роадмап.

Поэтому мы снова усиливаемся!

Кого ищем:
➡️Senior Python Developer (Core/Backend) – проектирование «движка» платформы. В планах: высоконагруженная оркестрация, работа со стабильностью LLM-пайплайнов и создание гибкой инфраструктуры под агентские сценарии.

➡️Senior Frontend Developer (React/Flow-based UI) – развитие сложного визуального конструктора. Нужно проектировать flow-интерфейсы (ноды, связи, визуализация графов), делая лучший UX для тех, кто создает AI-решения.

➡️Senior System Analyst – мозг, который свяжет AI-сценарии и ограничения банковской инфры в четкую архитектуру. Нужно понимать, как реально ходят данные в RAG и как вписать агентов в огромный ИТ-ландшафт.

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

➡️Подробности в личке: @dmrtnv. Присоединяйтесь!

За репост или рекомендацию в личку – лучи добра и +10 к карме. Давайте поможем крутым инженерам и крутому продукту встретиться

🥰

#AI #AlfaGen #Hiring #Python #Frontend #SystemAnalyst #MCP

🤔 Observability в агентных системах: масштабирование начинается с трейсов

В агентных системах инцидент (нестабильность поведения) – это не дефект кода, а штатная характеристика среды.

➡️Когда логика исполнения выносится в runtime, вопрос «почему это упало?» становится критическим. ➡️Observability (наблюдаемость) здесь перестает быть приятным дополнением – это базовое условие выживания, отделяющее управляемый продукт от непредсказуемого хаоса.

▶️ Проблема causal chain: почему агенты стохастичны
LLM – это системы с высоким уровнем энтропии. В агентной обвязке их риски (hallucinations, context drift) усиливаются за счет вероятностного наслоения:

– Архитектурная сложность: tool calling, итеративное планирование и кросс-агентные зависимости перемножают неопределенность модели на нестабильность среды.
– Инфраструктурный хаос: таймауты внешних API, сайд-эффекты инструментов и изменяемый стейт делают систему невозможной для детерминированного описания.

Спроектировать такую конструкцию «без сбоев» нельзя. Критический провал здесь не ошибка как таковая, а отсутствие прозрачного causal chain: возможности мгновенно восстановить цепочку причинно-следственных связей и понять, где именно «поплыла» логика.

▶️ Почему код больше не источник правды
В классическом софте все линейно: код → поведение, стек-трейс → конкретная причина.

В агентных системах эта связка рвется. Код лишь задает границы маневра, а реальное поведение рождается в runtime – через взаимодействие модели с контекстом и инструментами. Теперь источник правды не main.py, а динамическая история исполнения: входные данные, шаги рассуждений (CoT), вызовы инструментов и мутации стейта.

▶️ Из чего состоит observability агентов (LLMOps stack)
– Distributed Tracing (obs-фундамент): каждый запуск упаковывается в trace_id. Мы используем стандарты вроде OpenTelemetry или готовые решения (LangFuse, LangSmith, Arize Phoenix), чтобы превратить блэк бокс в прозрачную иерархию вызовов.
– Глубокое логирование инструментов: I/O и latency каждого Tool Call. Без этого анализ инцидентов превращается в гадание на кофейной гуще.
– Eval внутри трейса: мониторинг здоровья каждого шага через LLM-as-a-judge. Это позволяет выявлять логические ошибки до того, как они долетят до пользователя, хотя и требует отдельной калибровки судейской модели.

↔️Двухуровневые дашборды
Эффективный мониторинг требует разделения:

– Продуктовый слой: success Rate, CSAT, Efficiency, HITL Rate.
– Технический слой: latency, расход токенов, частота регрессий и ошибок внешних API.

Так за минуты становится понятно: проблема в «галлюцинации» агента или в стабильности внешней инфраструктуры.

🟢Агентные системы без наблюдаемости не поддаются масштабированию. Если вы не можете в любой момент восстановить, почему агент принял конкретное решение – у вас не инженерная система, а неконтролируемый процесс.
🟢Именно observability превращает агентную архитектуру из хрупкого эксперимента в устойчивый продукт, готовый к эксплуатации в продакшене.

#Observability #AgenticAI #LLMOps #AIArchitecture #ProductionAI #MachineLearning

🍎 WebKit → dyld: анатомия системной exploit-chain

➡️Apple выпустила экстренное обновление для закрытия CVE-2026-20700. Это первый критический zero-day года, затрагивающий dyld (Dynamic Link Editor).
➡️Разбираем, почему это технически изящно и крайне опасно для тех, кто работает с чувствительными данными.

⚙️ dyld: точка, где начинается выполнение кода

dyld – это динамический компоновщик. В иерархии macOS и iOS он стоит у основания: когда вы запускаете любое приложение, первым просыпается именно он. Его задача – собрать исполняемый файл и системные библиотеки (.dylib) в единое целое в памяти.

В чем критичность?
dyld обладает огромными привилегиями. Ошибка управления памятью (memory corruption) здесь позволяет атакующему подменить адреса. Система вместо доверенной библиотеки Apple подгружает вредоносный код. Это происходит до того, как сработают основные уровни защиты.

➡️Как это эксплуатируется: логика цепочки
Злоумышленники не используют этот баг сам по себе. Это финальный аккорд в сложной цепочке (Exploit Chain):

– Entry Point: через уязвимости в WebKit (декабрьские CVE-2025-14174 и 43529). Пользователю достаточно просто зайти на подготовленную страницу. Браузер спотыкается, позволяя атакующему записать данные в ограниченную область памяти.

– Escalation: обычного доступа браузера атакующему мало – он заперт внутри процесса Safari. Чтобы получить доступ к сообщениям, камере или паролям, нужно выпрыгнуть в систему.

– The dyld Flip: здесь вступает новый zero-day. Атакующий через поврежденную память заставляет dyld при запуске любого системного процесса подгрузить не родную библиотеку Apple, а вредоносный код.

– Full Control: поскольку dyld доверяет загружаемым модулям, вредоносный код исполняется в контексте более привилегированного процесса.

➡️При чем здесь ИИ?
ИИ все чаще используется в исследовании уязвимостей.

– Автоматизация поиска: AI-агенты и LLM помогают находить аномалии в бинарном коде и нетривиальные паттерны управления памятью быстрее, чем при полностью ручном анализе. Это сокращает время на поиск слабых мест в сложных компонентах вроде WebKit или dyld.
– Ускорение цикла разработки: те же подходы применяются для фаззинга, triage и подготовки исправлений. В результате окно между обнаружением и закрытием уязвимости постепенно сокращается.

В итоге ключевым фактором становится не только глубина уязвимости, но и скорость ее обнаружения и устранения.

🟢

Автоматизация анализа постепенно снижает порог сложности для поиска нетривиальных цепочек эксплуатации

. То, что раньше искали годами вручную, теперь находят алгоритмы.
Цикл жизни багов сокращается, и единственная адекватная реакция – сокращать время до нажатия кнопки «Обновить ПО»

Stay safe. Update mandatory.

#ZeroDay #ExploitChain #dyld

Replication vs Partitioning vs Sharding: три разных ответа на рост данных

Сегодня чуть отойдем от AI, хотя для AI/LLM-систем это тоже основа. Меня часто спрашивают про базы данных, и здесь часто возникает путаница: репликация, партиционирование и шардирование – это не одно и то же «масштабирование базы», а три разных подхода под три разных узких места системы.

TL;DR

➡️Replication (Репликация) – копируем одни и те же данные на несколько узлов.
Нужно для доступности, отказоустойчивости и масштабирования чтений.
➡️Partitioning (Партиционирование) – делим большую таблицу на части внутри одного сервера.
Нужно для ускорения запросов, управления хранением данных и обслуживания.
➡️Sharding (Шардирование) – делим данные и распределяем по разным серверам.
Нужно для горизонтального масштабирования, когда один узел уже физически не справляется.

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

1️⃣ Replication: копии ради доступности
Репликация – это один и тот же набор данных в нескольких экземплярах. Обычно есть основной узел (primary), куда идет запись, и реплики, которые получают эти изменения.

Что дает:
🟢устойчивость к сбоям
🟢бóльшую пропускную способность на чтение
🟢возможность быстрого переключения (failover)

Что важно под капотом: появляется

лаг репликации

, т.е. запись уже есть на primary, но реплика может еще отдавать старое состояние;

failover – это не магия

, а выбор нового мастера, риск проблемы split-brain и операционная сложность.

Репликация отлично подходит для нагрузок на чтение и обеспечения отказоустойчивости.
Но она не масштабирует бесконечно запись и не убирает физические лимиты одного узла по диску, CPU или памяти.

2️⃣ Партиционирование: логически делим большую таблицу на части по правилу
Партиционирование – это когда таблица делится на секции (партиции) по правилу: диапазону, хэшу, списку или дате.
Например: логи по месяцам, транзакции по дате, события по ID клиента.

Что дает:
🟢запросы читают не всю таблицу, а только нужную партицию
🟢индексы становятся меньше и дешевле
🟢проще управлять сроком хранения и очисткой
🟢старые данные можно удалять целиком партициями, а не тяжелыми операциями DELETE

Ограничения:
🔴если запросы бьют сразу по всем партициям – выигрыш падает
🔴плохой ключ партиционирования почти убивает идею
🔴джойны и агрегации между партициями остаются дорогими

3️⃣ Шардирование: настоящий горизонтальный рост
Шардирование начинается там, где один сервер уже не вмещает нагрузку физически: по CPU, RAM, IOPS, объему диска или потоку записи. Здесь каждая машина хранит только часть данных. Шард А – одни пользователи, шард B – другие, шард C – третьи.
Что дает:

🟢горизонтальный рост хранилища
🟢распределение нагрузки на запись
🟢выход за пределы архитектуры одного узла

Цена высокая:
🔴нужен ключ шардирования (shard key)
🔴нужна маршрутизация запросов (routing)
🔴возникают «горячие» шарды (перегруженные узлы)
🔴сложнее делать кросс-шардовые запросы
🔴ребалансировка и решардинг становятся отдельными сложными проектами

Главный риск – неудачный ключ шардирования. Если ключ выбран плохо, один шард перегревается, остальные простаивают, а задержки (latency) становятся непредсказуемыми.

🔥 Где чаще всего ошибаются

Самая частая ошибка: «

База тормозит – давайте добавим реплики

»

Это поможет, только если узкое место в чтении. Если проблема в скорости записи, объеме данных, тяжелых процессах очистки, нагрузке на WAL или горячих партициях, смотреть надо уже в другую сторону.
Вторая ошибка – слишком рано шардировать.
Очень часто систему сначала можно отлично вытянуть за счет партиционирования, правильных индексов, политик хранения и read-реплик. Потому что шардирование это не просто фича, а долгосрочное архитектурное обязательство.

🟢

Хорошая архитектура начинается не с вопроса «что из этого круче?», а с вопроса:

во что именно мы уперлись: в чтение, запись, объем диска, задержки, консистентность или эксплуатацию?

#SystemDesign #Databases #HighLoad #DistributedSystems

@mrtnv_prism | @ainative

SreGPT: как Яндекс научил AI-агентов тушить инциденты в проде

Вчера был на AI Dev Day – кейсов было много хороших, но рассказать решил про этот, потому что тема важная и для многих SRE-команд пока неочевидная.

Ребята из Яндекса показали SreGPT – AI Copilot для команд надежности. Не очередной чат-бот поверх документации, а ансамбль специализированных AI-агентов под управлением центрального оркестратора. Контекст: Яндекс Go, около 1000 микросервисов.

➡️Какую проблему решают
1️⃣Снижение MTTR / MTTRC – время до восстановления и до нахождения root cause. Каждая минута инцидента – это деньги, репутация и нервы.
2️⃣Дефицит квалифицированных кадров – людей с нужной экспертизой не хватает, а инцидент не будет ждать, пока вы наймете и онбордите сеньора. AI-агент восполняет этот разрыв, давая дежурному контекст и подсказки, которые раньше были только в голове у конкретного человека.
3️⃣Повышение аптайма до 99,99, сокращение налога на дежурство и высвобождение времени команды на проактивную работу вместо тушения пожаров.

➡️Что умеет SreGPT

Каждый агент отвечает за свой блок процесса, оркестратор координирует их по фазам

Горячая фаза (инцидент прямо сейчас):
– автозаполнение карточки инцидента – агент собирает контекст из алертов, логов и метрик, пока дежурный еще читает первый алерт
– автостатусы – система сама генерирует апдейты для стейкхолдеров, дежурный не отвлекается на "написать в канал что происходит"
– поиск похожих инцидентов – моментальный поиск по истории: было ли такое, что помогло, какой был root cause
– призыв релевантных людей – агент анализирует тип инцидента, затронутые сервисы и историю, и зовет тех, кто реально нужен

Холодная фаза:
– root cause analysis – таймлайн, корреляция событий, гипотезы по первопричине
– подготовка постмортема с ключевыми точками и рекомендациями

➡️Что нужно, чтобы такое построить
SreGPT – это не модель, которую можно просто подключить. Это верхушка айсберга, а под ней - необходимые условия, без которых ничего не взлетит

– Инфраструктура – облако, централизованные логи, алерты, CI/CD. Без единой наблюдаемости агентам не на чем работать.
– Каталоги – сервисов, дежурных, оргструктуры. Агент должен знать, что за сервис, кто за него отвечает и кого звать.
– Knowledge graph / граф зависимостей – без карты связей между сервисами агент не поймёт, что упавший сервис X повалил сервисы Y и Z.
– Аудит всех событий – полная история: деплои, изменения конфигов, алерты, действия людей. Без этого root cause analysis превращается в гадание.
– Инференс – инфраструктура для быстрого вызова моделей, чтобы агенты отвечали за секунды, а не минуты.

Если у вас этого нет – начинать нужно не с AI-агентов, а с фундамента.

➡️Роадмап: от копилота к автопилоту
Самое интересное – куда ребята идут дальше. По сути, это путь от “помогаю человеку” к “делаю сам”:

Q4 2026 – Q1 2027: система сама находит, что сломалось, и определяет корневую причину. Дежурный получает не сырые алерты, а готовый диагноз.
Q4 2027: агент предлагает способы митигации и/или починки корневой причины. Человек выбирает и подтверждает, AI исполняет.
Дальше: полный цикл – находит причину, сам митигирует, сам чинит. Человек подключается только для контроля и нестандартных случаев.

Это классическая эволюция автономности: сначала AI как второй пилот, потом как первый, потом – автопилот с человеком на подстраховке. И у Яндекса уже есть конкретные таймлайны на каждый шаг.

Главное – SRE-процессы одна из самых благодарных зон для AI-агентов: структурированные данные, повторяющиеся паттерны, высокая цена каждой минуты простоя.

Но магия работает только поверх зрелой инфраструктуры

. Сначала – наблюдаемость, каталоги и граф зависимостей. Потом – агенты. А потом – автономия.

#AI #SRE #IncidentManagement #AgenticAI #AIDevDay #Yandex

@mrtnv_prism | @ainative