[2/2] Hands-On RAG for Production (Рубрика #AI)
Заканчивая обзор это крутой книги про RAG, что находится в процессе написания.
5) "Evaluating your RAG Application" - эта глава обязательна для прочтения тем, кто планирует докатить RAG на production. Авторы упоминают про метрики вроде hallucinations, response quality, latency и cost. И не только упоминают, но и рассказывают про способы измерения качества retrieval и генерации. По-факту, тут идет рассказ про стандартные метрики поиска (precision, recall, f1, метрики с учетом порядка элементов), а также про точность генерации (утилизация контекста, точность ответов, консистентность ответов, отсутствие галлюцинаций, точность цитат), а также предубеждения (по расе, полу и так далее). А также подходы к e2e оцениваниют при помощи фреймворков: Open-RAG-EVAL, RAGAs, DeepEval. Ну и напоследок как учитывать фидбек людей (условно пальцы вниз и вверх, которые вы видели в чатиках ChatGPT, Perplexity, ...)
6) "From RAG to AI Agents" - здесь речь идет про retrieval, который перестаёт быть конечным продуктом и становится частью более длинного workflow. То есть RAG - уже не только "найди и ответь", а "найди, проверь, спланируй, вызови инструмент, верни результат". Это очень верно для текущего времени, где агенты без качественного retrieval быстро превращаются в дорогую импровизацию.
7 и 8) "Multimodal RAG" и "Knowledge Enhanced RAG" делают книгу ещё полезнее для реальных корпораций. Это важно для всех, кто работает с PDF, таблицами, диаграммами, изображениями, полуструктурированными документами и сложными knowledge domains, где одной embedding similarity уже мало.
P.S.
Если сравнить эту книгу с другими, о которых я рассказывал, то получается такая картина
- "AI Engineering" - это широкая карта всей дисциплины и ответ на вопрос, а что вообще такое современная AI-разработка и из каких слоёв она состоит. На этом фоне "Hands-On RAG for Production" выглядит уже не как обзор всей системы, а как очень подробный разбор ее части - production RAG.
- "Prompt Engineering for LLMs" учит понимать архитектуру LLM, строить prompt strategy, правильно собирать context elements и использовать техники вроде few-shot, chain-of-thought и RAG. Поэтому "Prompt Engineering for LLMs" - это книга про интерфейс между человеком, контекстом и моделью, а "Hands-On RAG for Production" - про retrieval/platform layer, который этот контекст делает надёжным в проде.
#AI #Engineering #Software #DistributedSystems #SystemDesign #Database #Search #Agents
Заканчивая обзор это крутой книги про RAG, что находится в процессе написания.
5) "Evaluating your RAG Application" - эта глава обязательна для прочтения тем, кто планирует докатить RAG на production. Авторы упоминают про метрики вроде hallucinations, response quality, latency и cost. И не только упоминают, но и рассказывают про способы измерения качества retrieval и генерации. По-факту, тут идет рассказ про стандартные метрики поиска (precision, recall, f1, метрики с учетом порядка элементов), а также про точность генерации (утилизация контекста, точность ответов, консистентность ответов, отсутствие галлюцинаций, точность цитат), а также предубеждения (по расе, полу и так далее). А также подходы к e2e оцениваниют при помощи фреймворков: Open-RAG-EVAL, RAGAs, DeepEval. Ну и напоследок как учитывать фидбек людей (условно пальцы вниз и вверх, которые вы видели в чатиках ChatGPT, Perplexity, ...)
6) "From RAG to AI Agents" - здесь речь идет про retrieval, который перестаёт быть конечным продуктом и становится частью более длинного workflow. То есть RAG - уже не только "найди и ответь", а "найди, проверь, спланируй, вызови инструмент, верни результат". Это очень верно для текущего времени, где агенты без качественного retrieval быстро превращаются в дорогую импровизацию.
7 и 8) "Multimodal RAG" и "Knowledge Enhanced RAG" делают книгу ещё полезнее для реальных корпораций. Это важно для всех, кто работает с PDF, таблицами, диаграммами, изображениями, полуструктурированными документами и сложными knowledge domains, где одной embedding similarity уже мало.
P.S.
Если сравнить эту книгу с другими, о которых я рассказывал, то получается такая картина
- "AI Engineering" - это широкая карта всей дисциплины и ответ на вопрос, а что вообще такое современная AI-разработка и из каких слоёв она состоит. На этом фоне "Hands-On RAG for Production" выглядит уже не как обзор всей системы, а как очень подробный разбор ее части - production RAG.
- "Prompt Engineering for LLMs" учит понимать архитектуру LLM, строить prompt strategy, правильно собирать context elements и использовать техники вроде few-shot, chain-of-thought и RAG. Поэтому "Prompt Engineering for LLMs" - это книга про интерфейс между человеком, контекстом и моделью, а "Hands-On RAG for Production" - про retrieval/platform layer, который этот контекст делает надёжным в проде.
#AI #Engineering #Software #DistributedSystems #SystemDesign #Database #Search #Agents
Telegram
Книжный куб
[1/2] Hands-On RAG for Production (Рубрика #AI)
С интересом прочел доступные главы этой книги, что находится в процессе написания. Основная идея авторов Ofer Mendelevitch и Forrest Bao была в том, чтобы рассказать про retrieval augmented generation как про…
С интересом прочел доступные главы этой книги, что находится в процессе написания. Основная идея авторов Ofer Mendelevitch и Forrest Bao была в том, чтобы рассказать про retrieval augmented generation как про…
❤10👍6🔥1
Управление 2026 - Конференция от Стратоплана (Рубрика #Management)
В этом году мы наблюдаем как меняется все вокруг под воздействием AI, причем сама область разработки трансформируется быстрее всего. Меняются ожидания от линейных инженеров, но не только - и руководителям предстоит измениться. И логика тут простая: AI не заменит руководителей сам по себе - руководители, которые перестроились под новые условия, заменят тех, кто не захотел или не справился с этим.
И для тех, кто готов к изменениям мы решили провести конфу Управление’26 - она поможет тем, кто хочет свериться с реальностью и понять, какие компетенции и инструменты нужны, чтобы остаться востребованным сегодня и в будущем. Я на этой конфе расскажу про то, как меняется роль CTO, что ему стоит попробовать руками и как выстроить стратегию развития технологий компании, включая конечно и AI.
Регистрация на конфу доступна здесь, причем участие бесплатное при подписке на каналы спикеров (или если нет желания подписываться, то за символическую плату).
На конфе выступят: ex-CТО Bookmate и Pure, фаундер NEWHR, AI Program Manager из G42, Venture Principal, ex-PM в IBM и ex-CIO Volvo, и ex-Associate Managing Consultant в MasterCard + сооснователи Школы
Конференция пройдет с 20 по 23 апреля, онлайн (но будут доступны и записи).
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Productivity
В этом году мы наблюдаем как меняется все вокруг под воздействием AI, причем сама область разработки трансформируется быстрее всего. Меняются ожидания от линейных инженеров, но не только - и руководителям предстоит измениться. И логика тут простая: AI не заменит руководителей сам по себе - руководители, которые перестроились под новые условия, заменят тех, кто не захотел или не справился с этим.
И для тех, кто готов к изменениям мы решили провести конфу Управление’26 - она поможет тем, кто хочет свериться с реальностью и понять, какие компетенции и инструменты нужны, чтобы остаться востребованным сегодня и в будущем. Я на этой конфе расскажу про то, как меняется роль CTO, что ему стоит попробовать руками и как выстроить стратегию развития технологий компании, включая конечно и AI.
Регистрация на конфу доступна здесь, причем участие бесплатное при подписке на каналы спикеров (или если нет желания подписываться, то за символическую плату).
На конфе выступят: ex-CТО Bookmate и Pure, фаундер NEWHR, AI Program Manager из G42, Venture Principal, ex-PM в IBM и ex-CIO Volvo, и ex-Associate Managing Consultant в MasterCard + сооснователи Школы
Конференция пройдет с 20 по 23 апреля, онлайн (но будут доступны и записи).
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Productivity
👍18❤13🔥8🫡1
[1/2] SWE-PRBench: Benchmarking AI Code Review Quality Against Pull Request Feedback (Рубрика #Whitepaper)
Когда разбирался с тем, как оценивать качество агентов внутри SDLC наткнулся на интересную и свежую работу от Deepak Kumar, независимого исследователя. В этом исследовании простая : SWE-Bench-подобные бенчмарки меряют, может ли модель написать правильный патч, а не может ли она оценить чужой PR как reviewer. И в предложенном подходе автор делает именно второе: берёт реальные merged PR и реальные комментарии людей в ревью как ground truth, не синтезирует комментарии и не сводит задачу к similarity текста. Плюс авторы фиксируют три режима контекста (по нарастающей), чтобы проверить эффект от его расширения
- config_A (diff + summary)
- config_B (добавлен file context)
- config_C (ещё и test/context layers)
Этот подход позволяет измерить насколько разные модели хороши в поиске issues в сравнении с находками людей.
Если глубже погружаться в методологию, то она такова
1) Сначала они отбирают репозитории по RQS (Repository Quality Score): review culture, свежесть PR, качество тестов/CI, объём PR activity и contamination proxy. Репозитории ниже 60/100 отбрасываются. Самый сильный сигнал - именно культура ревью: доля содержательных комментариев от людей в недавних merged PR.
2) Потом PR проходят 10-шаговую фильтрацию: только смердженные PR, минимум два содержательных человеческих комментария, есть изменения помимо тестов, не только изменения документации, не просто автоматический бамп зависимостей, не только AI ревью, diff можно распарсить, базовый commit доступен, репозиторий еще публичный, и проходит RVS-порог (что упоминался в первом пункте). Из примерно 3,000 raw PR остаётся 700 кандидатов, после RVS обрезается до 350 PR из 65 репозиториев. Ground truth берётся из реальных комментариев к ревью через GitHub API; комментарии не генерируются и не правятся вручную. Авторы отдельно фильтруют AI/bot комментарии и исключают PR, где AI-комментариев больше 30%.
3) Важная часть методологии построена вокруг таксономии сложности
- Type1 - проблема видна прямо в diff
- Type2 - нужно понимать окружающий код в том же файле и который не менялся
- Type3 - нужно размышление относительно кросс-файловых зависимостей
Этот ход превращает “качество code review” из одной мутной метрики в три разных когнитивных режима
4) Оценивание тоже сделано интересно. Агент должен вернуть 4–6 issues в JSON с severity, а judge-модель классифицирует каждый comment как CONFIRMED, PLAUSIBLE или FABRICATED. Причем PLAUSIBLE - это хороший подход, так как авторы признают, что ревью людьми не исчерпывающее, поэтому валидный новый комментарий не считается автоматом галлюцинацией. Дальше идёт маппинг, чтобы модель не получила двойные очки за разбиение одной идеи на пять комментариев, а итоговый score смешивает полноту, точность, semantic alignment, actionability и efficiency, штрафуя галлюцинации и избыточность.
В итоге, были получены интересные результаты:
1) На их 100-PR stratified sample ни одна модель не ловит больше 31% human-flagged issues; средний detection rate по всем 8 моделям на config_A примерно 26%. Топ-4 модели показывают примерно одинаковый агрегированный score.
2) По профилю моделей видим, что нет лучшего ревьювера и у нас обычный precision/recall trade-off. В цифрах DeepSeek V3 даёт лучший raw detection на config_A (DR=0.312), а GPT-4o даёт лучший hallucination profile (FPR=0.193). У Llama 3.3 70B худший FPR — 0.417.
3) Все 8 моделей деградируют при переходе от config_A к config_C. Причём config_A и config_C отличаются всего на 500 токенов (2,000 vs 2,500) - кажется, что проблема в том, как контекст подаётся, а не только в объёме.
4) Все ухудшается на переходе от config_A к config_B: у Sonnet score по Type2 падает с 0.22 до 0.10 при переходе A→B; у DeepSeek — с 0.20 до 0.10. То есть модели ломаются не там, где нужен весь репозиторий, а уже на шаге добавления окружающего контекста из измененного файла.
В продолжении обсудим что все это значит на практике.
#AI #Engineering #Software #SystemDesign #Agents
Когда разбирался с тем, как оценивать качество агентов внутри SDLC наткнулся на интересную и свежую работу от Deepak Kumar, независимого исследователя. В этом исследовании простая : SWE-Bench-подобные бенчмарки меряют, может ли модель написать правильный патч, а не может ли она оценить чужой PR как reviewer. И в предложенном подходе автор делает именно второе: берёт реальные merged PR и реальные комментарии людей в ревью как ground truth, не синтезирует комментарии и не сводит задачу к similarity текста. Плюс авторы фиксируют три режима контекста (по нарастающей), чтобы проверить эффект от его расширения
- config_A (diff + summary)
- config_B (добавлен file context)
- config_C (ещё и test/context layers)
Этот подход позволяет измерить насколько разные модели хороши в поиске issues в сравнении с находками людей.
Если глубже погружаться в методологию, то она такова
1) Сначала они отбирают репозитории по RQS (Repository Quality Score): review culture, свежесть PR, качество тестов/CI, объём PR activity и contamination proxy. Репозитории ниже 60/100 отбрасываются. Самый сильный сигнал - именно культура ревью: доля содержательных комментариев от людей в недавних merged PR.
2) Потом PR проходят 10-шаговую фильтрацию: только смердженные PR, минимум два содержательных человеческих комментария, есть изменения помимо тестов, не только изменения документации, не просто автоматический бамп зависимостей, не только AI ревью, diff можно распарсить, базовый commit доступен, репозиторий еще публичный, и проходит RVS-порог (что упоминался в первом пункте). Из примерно 3,000 raw PR остаётся 700 кандидатов, после RVS обрезается до 350 PR из 65 репозиториев. Ground truth берётся из реальных комментариев к ревью через GitHub API; комментарии не генерируются и не правятся вручную. Авторы отдельно фильтруют AI/bot комментарии и исключают PR, где AI-комментариев больше 30%.
3) Важная часть методологии построена вокруг таксономии сложности
- Type1 - проблема видна прямо в diff
- Type2 - нужно понимать окружающий код в том же файле и который не менялся
- Type3 - нужно размышление относительно кросс-файловых зависимостей
Этот ход превращает “качество code review” из одной мутной метрики в три разных когнитивных режима
4) Оценивание тоже сделано интересно. Агент должен вернуть 4–6 issues в JSON с severity, а judge-модель классифицирует каждый comment как CONFIRMED, PLAUSIBLE или FABRICATED. Причем PLAUSIBLE - это хороший подход, так как авторы признают, что ревью людьми не исчерпывающее, поэтому валидный новый комментарий не считается автоматом галлюцинацией. Дальше идёт маппинг, чтобы модель не получила двойные очки за разбиение одной идеи на пять комментариев, а итоговый score смешивает полноту, точность, semantic alignment, actionability и efficiency, штрафуя галлюцинации и избыточность.
В итоге, были получены интересные результаты:
1) На их 100-PR stratified sample ни одна модель не ловит больше 31% human-flagged issues; средний detection rate по всем 8 моделям на config_A примерно 26%. Топ-4 модели показывают примерно одинаковый агрегированный score.
2) По профилю моделей видим, что нет лучшего ревьювера и у нас обычный precision/recall trade-off. В цифрах DeepSeek V3 даёт лучший raw detection на config_A (DR=0.312), а GPT-4o даёт лучший hallucination profile (FPR=0.193). У Llama 3.3 70B худший FPR — 0.417.
3) Все 8 моделей деградируют при переходе от config_A к config_C. Причём config_A и config_C отличаются всего на 500 токенов (2,000 vs 2,500) - кажется, что проблема в том, как контекст подаётся, а не только в объёме.
4) Все ухудшается на переходе от config_A к config_B: у Sonnet score по Type2 падает с 0.22 до 0.10 при переходе A→B; у DeepSeek — с 0.20 до 0.10. То есть модели ломаются не там, где нужен весь репозиторий, а уже на шаге добавления окружающего контекста из измененного файла.
В продолжении обсудим что все это значит на практике.
#AI #Engineering #Software #SystemDesign #Agents
arXiv.org
SWE-PRBench: Benchmarking AI Code Review Quality Against Pull...
We introduce SWE-PRBench, a benchmark of 350 pull requests with human-annotated ground truth for evaluating AI code review quality. Evaluated against an LLM-as-judge framework validated at...
❤6👍4🔥1🤔1
[2/2] SWE-PRBench: Benchmarking AI Code Review Quality Against Pull Request Feedback (Рубрика #Whitepaper)
Продолжая рассказ, про whitepaper мы поговорим какие практические выводы можно сделать из предложенного подхода.
1️⃣ Больше контекста, не всегда выше качество. В review-задаче компактный diff + summary оказался лучше, чем более “богатый” flat prompt. Я бы читал это не как “контекст бесполезен”, а как “наивная плоская упаковка контекста вредна”. Это важная разница: авторы сами пишут, что retrieval-based или token-level relevance strategies вроде changed-vs-unchanged markers могут дать другой результат, и прямо позиционируют config_B как uncurated baseline, относительно которого и надо мерить retrieval-approaches.
Отсюда мой практический вывод о том, что агент-ревьювер должен быть многошаговым, а не одним гигантским промптом. Нормальный pipeline может выгялдеть так:
- diff-only candidate generation;
- targeted retrieval только под подозрительные места;
- verifier/critic, который режет fabricated comments;
- dedup + severity ranking перед публикацией в PR.
Кажется, что это следующий шаг, который основан на результатах деградации качества по мере добавления контекста.
2️⃣ Не надо выбирать модель только по обобщенному скору. В этом исследовании top-4 модели почти не различимы статистически, зато у них разные результаты по части галлюцинаций и стоимости. Для бота, который пишет комменты прямо в PR, низкий FPR (false positive rate) обычно важнее, чем максимальный полнота; для ревьювера, что работает в shadow-mode можно взять более recall-heavy и дешёвый вариант, но обязательно с этапом верификации.
Если говорить про масштабирование подхода, то кажется сам подход отлично подходит для создания своих кастомных бенчей в компании.
- Data pipeline переносится в компанию почти напрямую: merged PR, diff, base/head SHA, changed files, human comments, frozen context fixtures, separate judge/agent pipeline
- У авторов уже опубликованы и dataset artifacts, и harness, где layout очень близок к тому, что и нужно внутри компании
- И в крупных компаниях это масштабируется даже лучше, чем в open source: внутри компании у вас обычно есть больше сигналов - ownership, CI артефакты, rollback history, incident links, review roles, labels вроде security/migration/data-contract.
То есть сам подход authors я бы не просто переносил, а усиливал внутренними metadata. Но production-часть paper переносить буквально я бы не стал: их собственные результаты показывают, что flat full-context review не работает, а limitations section прямо оставляет дверь открытой для более умных relevance encodings и retrieval.
А вот для переноса на всю индустрию пока есть препятствия
- Датасет Python-dominant (69.1%), performance PR почти нет (8), security PR вообще один, paper baseline посчитан на 100 PR из полного корпуса 350, а не на всём датасете
- Нет человеческого baseline в этом режиме, а judge-family bias authors сами не исключают.
#AI #Engineering #Software #SystemDesign #Agents
Продолжая рассказ, про whitepaper мы поговорим какие практические выводы можно сделать из предложенного подхода.
1️⃣ Больше контекста, не всегда выше качество. В review-задаче компактный diff + summary оказался лучше, чем более “богатый” flat prompt. Я бы читал это не как “контекст бесполезен”, а как “наивная плоская упаковка контекста вредна”. Это важная разница: авторы сами пишут, что retrieval-based или token-level relevance strategies вроде changed-vs-unchanged markers могут дать другой результат, и прямо позиционируют config_B как uncurated baseline, относительно которого и надо мерить retrieval-approaches.
Отсюда мой практический вывод о том, что агент-ревьювер должен быть многошаговым, а не одним гигантским промптом. Нормальный pipeline может выгялдеть так:
- diff-only candidate generation;
- targeted retrieval только под подозрительные места;
- verifier/critic, который режет fabricated comments;
- dedup + severity ranking перед публикацией в PR.
Кажется, что это следующий шаг, который основан на результатах деградации качества по мере добавления контекста.
2️⃣ Не надо выбирать модель только по обобщенному скору. В этом исследовании top-4 модели почти не различимы статистически, зато у них разные результаты по части галлюцинаций и стоимости. Для бота, который пишет комменты прямо в PR, низкий FPR (false positive rate) обычно важнее, чем максимальный полнота; для ревьювера, что работает в shadow-mode можно взять более recall-heavy и дешёвый вариант, но обязательно с этапом верификации.
Если говорить про масштабирование подхода, то кажется сам подход отлично подходит для создания своих кастомных бенчей в компании.
- Data pipeline переносится в компанию почти напрямую: merged PR, diff, base/head SHA, changed files, human comments, frozen context fixtures, separate judge/agent pipeline
- У авторов уже опубликованы и dataset artifacts, и harness, где layout очень близок к тому, что и нужно внутри компании
- И в крупных компаниях это масштабируется даже лучше, чем в open source: внутри компании у вас обычно есть больше сигналов - ownership, CI артефакты, rollback history, incident links, review roles, labels вроде security/migration/data-contract.
То есть сам подход authors я бы не просто переносил, а усиливал внутренними metadata. Но production-часть paper переносить буквально я бы не стал: их собственные результаты показывают, что flat full-context review не работает, а limitations section прямо оставляет дверь открытой для более умных relevance encodings и retrieval.
А вот для переноса на всю индустрию пока есть препятствия
- Датасет Python-dominant (69.1%), performance PR почти нет (8), security PR вообще один, paper baseline посчитан на 100 PR из полного корпуса 350, а не на всём датасете
- Нет человеческого baseline в этом режиме, а judge-family bias authors сами не исключают.
#AI #Engineering #Software #SystemDesign #Agents
Telegram
Книжный куб
[1/2] SWE-PRBench: Benchmarking AI Code Review Quality Against Pull Request Feedback (Рубрика #Whitepaper)
Когда разбирался с тем, как оценивать качество агентов внутри SDLC наткнулся на интересную и свежую работу от Deepak Kumar, независимого исследователя.…
Когда разбирался с тем, как оценивать качество агентов внутри SDLC наткнулся на интересную и свежую работу от Deepak Kumar, независимого исследователя.…
👍5❤3🔥1
От AI-native разработки к AI-native платформе (Рубрика #AI4SDLC)
Написал статью про то, что следующее узкое место AI-native разработки лежит уже не в слое написания кода, а в самой платформе разработки. Как только агенты входят в основной рабочий поток, GitHub перестает быть просто местом хранения кода и запуска CI, а становится слоем управления для людей и агентов. Тогда ревью, проверки безопасности, политики и телеметрия перестают быть внешней обвязкой и становятся частью вычислительного пути.
На примере GitHub разбираю, как агентные сценарии создают новый класс платформенной нагрузки, почему защитные механизмы сами становятся частью основной нагрузки и что это означает для крупных инженерных организаций. Если совсем коротко, то AI ускоряет не только кодинг, но и рост давления на CI, ревью, проверки и путь до слияния. А значит, следующая зрелая форма AI-native - это уже не просто агент в IDE, а AI-native платформенная инженерия.
#AI #Architecture #Software #Engineering #Agents #Processes #Productivity
Написал статью про то, что следующее узкое место AI-native разработки лежит уже не в слое написания кода, а в самой платформе разработки. Как только агенты входят в основной рабочий поток, GitHub перестает быть просто местом хранения кода и запуска CI, а становится слоем управления для людей и агентов. Тогда ревью, проверки безопасности, политики и телеметрия перестают быть внешней обвязкой и становятся частью вычислительного пути.
На примере GitHub разбираю, как агентные сценарии создают новый класс платформенной нагрузки, почему защитные механизмы сами становятся частью основной нагрузки и что это означает для крупных инженерных организаций. Если совсем коротко, то AI ускоряет не только кодинг, но и рост давления на CI, ревью, проверки и путь до слияния. А значит, следующая зрелая форма AI-native - это уже не просто агент в IDE, а AI-native платформенная инженерия.
#AI #Architecture #Software #Engineering #Agents #Processes #Productivity
Medium
От AI-native разработки к AI-native платформе
Главное изменение в AI-native мире происходит не только в коде и не только в IDE. Оно происходит на уровне платформы: как только агенты…
❤7👍7🤔5👎2🔥2
AI и ИБ (пятничное)
Остановись мгновенье ты прекрасно,
Сказал ИБшник и поставил всё на холд.
Ведь только так ты будешь безопасна,
Моя платформа, не попавшая на прод.
P.S.
Навеяно плотным общением на тему прикладных вопросов информационной безопасности в сценариях разработки программного обеспечения.
#Humor #AI #Security
Остановись мгновенье ты прекрасно,
Сказал ИБшник и поставил всё на холд.
Ведь только так ты будешь безопасна,
Моя платформа, не попавшая на прод.
P.S.
Навеяно плотным общением на тему прикладных вопросов информационной безопасности в сценариях разработки программного обеспечения.
#Humor #AI #Security
😁28❤4👎3🔥3😢2
Unravel Two (Рубрика #Games)
Недавно вместе прошли игру "Unravel Two" с Кириллом, моим сыном 5 лет, и это оказался очень хороший пример игры, в которую действительно можно играть вместе с маленьким ребенком, а не просто формально включить кооператив:)
Снаружи игрушка выглядит как просто красивый платформер про двух Yarny - маленьких существ из ниток. Но ее главная идея как раз в связке двух персонажей. Они соединены одной нитью, и на этом построена почти вся игра: нужно цепляться за окружение, раскачиваться, подтягивать друг друга, делать мостики из нити, вместе проходить препятствия и решать простые головоломки. За счет этого кооператив тут не прикручен сверху, а встроен в саму механику. Ты буквально двигаешься вперед только потому, что действуешь не один.
Мне отдельно понравилось, как здесь устроен нарратив. Игра почти ничего не объясняет словами, но при этом довольно хорошо передает ощущение связи, поддержки и совместного пути. Это история не про сюжетные повороты и длинные диалоги, а про состояние: рядом кто-то есть, вы держитесь вместе, и поэтому можете пройти дальше. Для игры с ребенком это особенно хорошо работает, потому что не нужно долго объяснять контекст - он считывается через действие, свет, движение и сами ситуации.
Еще одна сильная сторона - окружение. Unravel Two очень здорово играет на контрасте масштаба. Ты видишь лес, воду, траву, ветки, старые дома, какие-то бытовые пространства, но все это показано с точки зрения очень маленького существа. Из-за этого обычный мир становится одновременно уютным и немного опасным. Игра красивая, теплая по цветам и атмосфере, но не приторная: в ней есть и чувство приключения, и легкая тревога, и ощущение большого мира вокруг.
Ну и главное - почему она правда подходит для кооператива с детьми. В ней не самый высокий порог входа, она не требует молниеносной реакции каждую секунду и не строится на постоянном наказании за ошибки. Более опытный игрок может подстраховать, взять на себя более сложные куски, а ребенок все равно остается полноценным участником процесса, а не зрителем с подключенным геймпадом. По-факту, Кирилл в особо сложных местах "вплетался" в моего Yarni и я мог вместе с ним на своих плечах проходить эти эпизоды. В общем, нам с Кириллом она очень понравилась, но особо сложные дополнительные уровни мы проходить не стали:)
#Games #ForKids #ForParents
Недавно вместе прошли игру "Unravel Two" с Кириллом, моим сыном 5 лет, и это оказался очень хороший пример игры, в которую действительно можно играть вместе с маленьким ребенком, а не просто формально включить кооператив:)
Снаружи игрушка выглядит как просто красивый платформер про двух Yarny - маленьких существ из ниток. Но ее главная идея как раз в связке двух персонажей. Они соединены одной нитью, и на этом построена почти вся игра: нужно цепляться за окружение, раскачиваться, подтягивать друг друга, делать мостики из нити, вместе проходить препятствия и решать простые головоломки. За счет этого кооператив тут не прикручен сверху, а встроен в саму механику. Ты буквально двигаешься вперед только потому, что действуешь не один.
Мне отдельно понравилось, как здесь устроен нарратив. Игра почти ничего не объясняет словами, но при этом довольно хорошо передает ощущение связи, поддержки и совместного пути. Это история не про сюжетные повороты и длинные диалоги, а про состояние: рядом кто-то есть, вы держитесь вместе, и поэтому можете пройти дальше. Для игры с ребенком это особенно хорошо работает, потому что не нужно долго объяснять контекст - он считывается через действие, свет, движение и сами ситуации.
Еще одна сильная сторона - окружение. Unravel Two очень здорово играет на контрасте масштаба. Ты видишь лес, воду, траву, ветки, старые дома, какие-то бытовые пространства, но все это показано с точки зрения очень маленького существа. Из-за этого обычный мир становится одновременно уютным и немного опасным. Игра красивая, теплая по цветам и атмосфере, но не приторная: в ней есть и чувство приключения, и легкая тревога, и ощущение большого мира вокруг.
Ну и главное - почему она правда подходит для кооператива с детьми. В ней не самый высокий порог входа, она не требует молниеносной реакции каждую секунду и не строится на постоянном наказании за ошибки. Более опытный игрок может подстраховать, взять на себя более сложные куски, а ребенок все равно остается полноценным участником процесса, а не зрителем с подключенным геймпадом. По-факту, Кирилл в особо сложных местах "вплетался" в моего Yarni и я мог вместе с ним на своих плечах проходить эти эпизоды. В общем, нам с Кириллом она очень понравилась, но особо сложные дополнительные уровни мы проходить не стали:)
#Games #ForKids #ForParents
🔥33👍13❤9
Управление 2026 - Конференция от Стратоплана (Рубрика #Management)
В этом году мы наблюдаем как меняется все вокруг под воздействием AI, причем сама область разработки трансформируется быстрее всего. Меняются ожидания от линейных инженеров, но не только - и руководителям предстоит измениться. И логика тут простая: AI не заменит руководителей сам по себе - руководители, которые перестроились под новые условия, заменят тех, кто не захотел или не справился с этим.
И для тех, кто готов к изменениям мы решили провести конфу Управление’26 - она поможет тем, кто хочет свериться с реальностью и понять, какие компетенции и инструменты нужны, чтобы остаться востребованным сегодня и в будущем. Я на этой конфе расскажу про то, как меняется роль CTO, что ему стоит попробовать руками и как выстроить стратегию развития технологий компании, включая конечно и AI. По-факту, основная канва моего доклада будет опираться на серию моих статей
- От классического PDLC к AI-native разработке
- От AI-native разработки к AI-native организации (с примерами из опыта бигтехов)
- От классического управления задачами в Jira к AI-native task management (на примере Atlassian и Linear)
- Как бигтехи планируют внедрять AI-native разработку у себя в 2026 году
- От AI-native разработки к AI-native платформе
- От AI-native организации к AI-native лидерству: роль CTO в 2026 году
Сама конфа пройдет с 20 по 23 апреля, а мое выступление будет в среду. Регистрация доступна здесь, причем участие бесплатное при подписке на каналы спикеров (или если нет желания подписываться, то за символическую плату). Для пропустивших будут доступны и записи выступлений.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Productivity
В этом году мы наблюдаем как меняется все вокруг под воздействием AI, причем сама область разработки трансформируется быстрее всего. Меняются ожидания от линейных инженеров, но не только - и руководителям предстоит измениться. И логика тут простая: AI не заменит руководителей сам по себе - руководители, которые перестроились под новые условия, заменят тех, кто не захотел или не справился с этим.
И для тех, кто готов к изменениям мы решили провести конфу Управление’26 - она поможет тем, кто хочет свериться с реальностью и понять, какие компетенции и инструменты нужны, чтобы остаться востребованным сегодня и в будущем. Я на этой конфе расскажу про то, как меняется роль CTO, что ему стоит попробовать руками и как выстроить стратегию развития технологий компании, включая конечно и AI. По-факту, основная канва моего доклада будет опираться на серию моих статей
- От классического PDLC к AI-native разработке
- От AI-native разработки к AI-native организации (с примерами из опыта бигтехов)
- От классического управления задачами в Jira к AI-native task management (на примере Atlassian и Linear)
- Как бигтехи планируют внедрять AI-native разработку у себя в 2026 году
- От AI-native разработки к AI-native платформе
- От AI-native организации к AI-native лидерству: роль CTO в 2026 году
Сама конфа пройдет с 20 по 23 апреля, а мое выступление будет в среду. Регистрация доступна здесь, причем участие бесплатное при подписке на каналы спикеров (или если нет желания подписываться, то за символическую плату). Для пропустивших будут доступны и записи выступлений.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Productivity
Medium
От классического PDLC к AI-native разработке
На начало 2026 года разработка находится в переходной фазе. С одной стороны, у нас по‑прежнему доминирует классический процесс, построенный…
🔥17❤13👍6
AI Conf - AI в разработке: эффект, риски, реальность (Рубрика #AI)
Был вчера на конференции Олега Бунина AI Conf, где прошла дискуссия про AI в разработке, куда Олег пригласил большое количество технических топов. Тема обсуждения была заявлена интересной, поэтому я с удовольствием приехал послушать, повидать знакомых, а также пообщаться на эту тему в кулуарах. Как по мне дискуссия изначально крутилась вокруг "использовать AI в разработке" vs "не использовать AI в разработке", а в наше время это уже не вариант - индустрия уже ответила на этот вопрос и AI уже здесь. В итоге ближе ко второй половине дискуссии она сдвинулась в тему, а как именно эффективно использовать AI, что для этого нужно, а также какие сценарии работают и у кого. Забавно, что я был слушателем, но в какой-то момент у меня оказался в руках микрофон и мне тоже удалось поделиться своими мыслями, которые близки к тем моим статьям, что я упоминал в прошлом посте.
P.S.
Спасибо Олегу за приглашение на это мероприятие и в эту дискуссию, а также за то, что собрал такую интересную компанию.
Ну и спасибо всем ребятам, с которыми удалось пересечься на конфе и пообщаться на эти захватывающие темы - это отлично помогает понять кто и как подходит к решению похожих задач в разных компаниях.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Productivity
Был вчера на конференции Олега Бунина AI Conf, где прошла дискуссия про AI в разработке, куда Олег пригласил большое количество технических топов. Тема обсуждения была заявлена интересной, поэтому я с удовольствием приехал послушать, повидать знакомых, а также пообщаться на эту тему в кулуарах. Как по мне дискуссия изначально крутилась вокруг "использовать AI в разработке" vs "не использовать AI в разработке", а в наше время это уже не вариант - индустрия уже ответила на этот вопрос и AI уже здесь. В итоге ближе ко второй половине дискуссии она сдвинулась в тему, а как именно эффективно использовать AI, что для этого нужно, а также какие сценарии работают и у кого. Забавно, что я был слушателем, но в какой-то момент у меня оказался в руках микрофон и мне тоже удалось поделиться своими мыслями, которые близки к тем моим статьям, что я упоминал в прошлом посте.
P.S.
Спасибо Олегу за приглашение на это мероприятие и в эту дискуссию, а также за то, что собрал такую интересную компанию.
Ну и спасибо всем ребятам, с которыми удалось пересечься на конфе и пообщаться на эти захватывающие темы - это отлично помогает понять кто и как подходит к решению похожих задач в разных компаниях.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Productivity
aiconf.ru
Прикладная конференция по Data Science 2026
1❤9👍7🔥3👎1
CFP (Call For Papers) на JVM Day (Рубрика #Conference)
У нас есть традиция раз в год ...ходить в баню проводить конференцию JVM Day. На прошлой я даже выступал и мне дали джемпер с группой крови на рукаве надписью "Экспертно заявляю".
Если вы тоже хотите экспертно заявить о чем-то на сообщество бекендеров, то подавайте свою заявку на нашу конфу, что пройдет 29 августа в Москве.
Мы ждем заявки с интересными кейсами для стандартных 40 минутных докладов или дискуссий, а также у нас есть демозоны, где вы можете представить свой продукт и у вашей команды будет пространство с экранами и стойками на весь день: можно показывать технологию вживую, общаться с инженерами, собирать обратную связь и находить первых пользователей.
В общем, не стесняйтесь и оставляйте свои заявки.
#Conference #Software #Engineering
У нас есть традиция раз в год ...
Если вы тоже хотите экспертно заявить о чем-то на сообщество бекендеров, то подавайте свою заявку на нашу конфу, что пройдет 29 августа в Москве.
Мы ждем заявки с интересными кейсами для стандартных 40 минутных докладов или дискуссий, а также у нас есть демозоны, где вы можете представить свой продукт и у вашей команды будет пространство с экранами и стойками на весь день: можно показывать технологию вживую, общаться с инженерами, собирать обратную связь и находить первых пользователей.
В общем, не стесняйтесь и оставляйте свои заявки.
#Conference #Software #Engineering
❤4👏4🔥3😁3
Выжать больше из локальных LLM (Рубрика #AI)
Я редко пишу про статьи на Habr, но тут не смог удержаться - уж очень понравилась мне большая и практичная статья про запуск локальных LLM. Эта тема мне интересна, но я особо не экспериментировал раньше, ограничиваясь запуском стандартных моделек в своей LMStudio на толстом AMD Ryzen AI Max+ 395. А эта статья позволяет выжать больше скорости, качества и контекста из вашего железа, например автор объясняет на пальцах почему ollama удобна, но медленнее llama.cpp, а также что такое квантование и какое оно бывает и что дает. Если чуть подробнее рассказать про основные темы, то они такие
1️⃣ Разница между Dense и MoE-моделями
У Dense-модели все параметры активны всегда, поэтому она часто стабильнее и "умнее", но медленнее. У MoE активна только часть экспертов, поэтому такая модель может быть быстрее, но требует более аккуратного запуска. И вот здесь начинается самое интересное: если просто выгрузить часть слоёв на GPU, как это часто делает Ollama, видеокарта может быть забита полностью, но работать неэффективно. А llama.cpp умеет умнее раскладывать тензоры и включать режимы вроде cmoe/ncmoe, что на MoE-моделях даёт очень заметный выигрыш.
2️⃣ Квантование - что это такое и что дает
Честно говоря, эта часть мне показалась супер-полезной, так как автор объяснил, что стандартный выбор "Q4_K_M по умолчанию" уже не всегда лучший вариант. Современные динамические кванты вроде UD-Q4_K_XL могут давать больше качества при близком размере, а иногда Q4_K_M оказывается примерно на уровне более лёгкого UD-Q3_K_XL. И это важный практический вывод: при локальном запуске не стоит слепо брать дефолтный квант из Ollama или LM Studio. Лучше посмотреть, есть ли версия от Unsloth, Ubergarm или другие более свежие варианты.
3️⃣ Использование локальных моделей для кодинга
Автор показывает, что даже сильное квантование UD-Q2_K_XL может быть достаточно рабочим для генерации и доработки кода: модель собирала прототипы игр, исправляла баги и работала через агента. Это не значит, что Q2 теперь всегда лучший выбор, но значит, что старое правило "ниже Q4 не смотреть" уже не всегда верно.
Плюс в статье много практических советов, что интересно проверить на практике
- Попробовать llama.cpp вместо Ollama, особенно для MoE-моделей;
- Искать не только Q4_K_M, но и динамические кванты UD-Q4_K_XL / UD-Q3_K_XL / IQ-варианты;
- Помнить, что меньший квант не всегда быстрее, потому что i-кванты могут требовать больше вычислений на CPU;
- Использовать
- Увеличивать
- Подключать маленькую draft-модель для speculative decoding, если задача похожа на кодинг или перевод;
- Освобождать VRAM: браузер, Windows и лишние приложения легко съедают 2–3 ГБ, которые могли бы уйти под модель или контекст;
- Смотреть на дату выхода модели, а не на старые списки "лучших LLM", где до сих пор всплывают модели, давно уступившие новым поколениям.
Эффект от этих настроек может быть очень ощутимым. В статье llama.cpp на MoE-модели показывал скорость примерно в 3 раза выше Ollama на том же железе. Настройка обработки контекста давала кратный рост PP. Спекулятивное декодирование ускоряло Dense-модель примерно в 1.5 раза на коде и переводе. А правильный выбор кванта позволял либо получить больше качества в том же размере, либо уместить модель в доступную VRAM.
В общем, это хорошая статья для инженеров, кто уже пробовал локальные LLM и столкнулся с ощущением, что "модель вроде неплохая, но работает медленно".
P.S.
Эхх, я бы хотел поковыряться со своей железкой и испробовать эти советы на майских праздниках, но улетаю с женой и детишками в Лондон в воскресенье, поэтому отложу это уже на вторые майские праздники. А с подписчиками канала буду следующие 2 недели делится туристическими фотками и своими размышлениями про AI:)
#AI #LLM #LocalLLM #Engineering #Performance #Agents #llamacpp
Я редко пишу про статьи на Habr, но тут не смог удержаться - уж очень понравилась мне большая и практичная статья про запуск локальных LLM. Эта тема мне интересна, но я особо не экспериментировал раньше, ограничиваясь запуском стандартных моделек в своей LMStudio на толстом AMD Ryzen AI Max+ 395. А эта статья позволяет выжать больше скорости, качества и контекста из вашего железа, например автор объясняет на пальцах почему ollama удобна, но медленнее llama.cpp, а также что такое квантование и какое оно бывает и что дает. Если чуть подробнее рассказать про основные темы, то они такие
1️⃣ Разница между Dense и MoE-моделями
У Dense-модели все параметры активны всегда, поэтому она часто стабильнее и "умнее", но медленнее. У MoE активна только часть экспертов, поэтому такая модель может быть быстрее, но требует более аккуратного запуска. И вот здесь начинается самое интересное: если просто выгрузить часть слоёв на GPU, как это часто делает Ollama, видеокарта может быть забита полностью, но работать неэффективно. А llama.cpp умеет умнее раскладывать тензоры и включать режимы вроде cmoe/ncmoe, что на MoE-моделях даёт очень заметный выигрыш.
2️⃣ Квантование - что это такое и что дает
Честно говоря, эта часть мне показалась супер-полезной, так как автор объяснил, что стандартный выбор "Q4_K_M по умолчанию" уже не всегда лучший вариант. Современные динамические кванты вроде UD-Q4_K_XL могут давать больше качества при близком размере, а иногда Q4_K_M оказывается примерно на уровне более лёгкого UD-Q3_K_XL. И это важный практический вывод: при локальном запуске не стоит слепо брать дефолтный квант из Ollama или LM Studio. Лучше посмотреть, есть ли версия от Unsloth, Ubergarm или другие более свежие варианты.
3️⃣ Использование локальных моделей для кодинга
Автор показывает, что даже сильное квантование UD-Q2_K_XL может быть достаточно рабочим для генерации и доработки кода: модель собирала прототипы игр, исправляла баги и работала через агента. Это не значит, что Q2 теперь всегда лучший выбор, но значит, что старое правило "ниже Q4 не смотреть" уже не всегда верно.
Плюс в статье много практических советов, что интересно проверить на практике
- Попробовать llama.cpp вместо Ollama, особенно для MoE-моделей;
- Искать не только Q4_K_M, но и динамические кванты UD-Q4_K_XL / UD-Q3_K_XL / IQ-варианты;
- Помнить, что меньший квант не всегда быстрее, потому что i-кванты могут требовать больше вычислений на CPU;
- Использовать
-fit, -cmoe, -ncmoe и не пытаться руками угадывать оптимальную раскладку;- Увеличивать
-ub и -b, если важна скорость обработки большого контекста;- Подключать маленькую draft-модель для speculative decoding, если задача похожа на кодинг или перевод;
- Освобождать VRAM: браузер, Windows и лишние приложения легко съедают 2–3 ГБ, которые могли бы уйти под модель или контекст;
- Смотреть на дату выхода модели, а не на старые списки "лучших LLM", где до сих пор всплывают модели, давно уступившие новым поколениям.
Эффект от этих настроек может быть очень ощутимым. В статье llama.cpp на MoE-модели показывал скорость примерно в 3 раза выше Ollama на том же железе. Настройка обработки контекста давала кратный рост PP. Спекулятивное декодирование ускоряло Dense-модель примерно в 1.5 раза на коде и переводе. А правильный выбор кванта позволял либо получить больше качества в том же размере, либо уместить модель в доступную VRAM.
В общем, это хорошая статья для инженеров, кто уже пробовал локальные LLM и столкнулся с ощущением, что "модель вроде неплохая, но работает медленно".
P.S.
Эхх, я бы хотел поковыряться со своей железкой и испробовать эти советы на майских праздниках, но улетаю с женой и детишками в Лондон в воскресенье, поэтому отложу это уже на вторые майские праздники. А с подписчиками канала буду следующие 2 недели делится туристическими фотками и своими размышлениями про AI:)
#AI #LLM #LocalLLM #Engineering #Performance #Agents #llamacpp
Хабр
Выжать больше из локальных LLM. Ollama медленнее llama.cpp в 3 раза. UD_Q4_K_XL лучше чем Q4_K_M, а вес тот же и т.д
Самый простой способ запустить локальную LLM - это установить ollama или LM Studio. Это быстро и просто, но вы теряете и в скорости, и в качестве. Почему UD_Q4_K_XL лучше при том же размере, почему...
🔥14👍13❤8😁1
The Great GPU Shortage – Rental Capacity – Launching our H100 1 Year Rental Price Index (Рубрика #AI)
Интересная статья от SemiAnalysis про агрессивный рынок аренды GPU, который вошел в клинч и цены взлетели вверх из-за роста спроса. Стоимость годового контракта на H100 выросла примерно на 40% - с $1.70 за GPU-час в октябре 2025 до $2.35 к марту 2026. On-demand capacity по сути выбрана по всем типам GPU, а Blackwell-кластеры, которые выходят в строй в середине 2026 года, во многих случаях уже заранее заняты. Даже найти кластер на 64 Hopper GPU стало нетривиально.
Авторы прямо связывает новую волну давления на рынок с резким ростом спроса на фоне agentic нагрузок поверх моделей. То есть узкое место теперь формируется не только гонкой лабораторий в тренировке новых моделей, а продакшен-инференсом, где модель перестаёт быть "чатом" и становится исполнителем рабочих процессов. В классическом chat UX экономика была относительно простой: один пользовательский запрос, один inference-pass, один ответ. В агентном мире одна задача раскладывается в дерево вызовов: оркестратор строит план, порождает субагентов, те параллельно ищут источники, читают код, ходят в инструменты, возвращают промежуточные результаты, после чего отдельный контур делает синтез, критику и верификацию. Например, cнаружи задача может выглядеть как "разбери инцидент" или "подготовь PR", а под капотом это уже рой субагентов.
В итоге, спрос на рынке растет уже не только от числа пользователей и не только от числа компаний, а скорее от того сколько задач делегируются агентам. Один и тот же разработчик, аналитик или исследователь теперь может запускать не один запрос к модели, а десятки координированных проходов - с длинным контекстом, ретраями, проверками и параллельными ветками. У мульти-агентных нагрузок есть неприятная для инфраструктуры особенность: они увеличивают не только суммарное потребление токенов, но и пиковую конкурентность, а это уже прямое давление на флот GPU.
Интересно, что этот спрос неравномерен. Авторы пишут, что часть inference-нагрузок, особенно большие MoE-сценарии, лучше работает на свежих системах вроде GB300 NVL72, тогда как тренировки и часть нагрузок, где важна стоимость к производительности, продолжают отлично жить на H100. Иными словами, новый агентный слой не просто "съедает Blackwell" - он одновременно поддерживает спрос и на Hopper, продлевая экономическую жизнь уже поставленных GPU. Поэтому у провайдеров сейчас не ценовая война за загрузку, а рынок продавца с длинными контрактами, предоплатой и выбором, кому вообще отдавать capacity.
Отсюда можно почерпнуть несколько выводов:
1️⃣ Планирование мощностей по модели "сколько у нас чатов в день" больше не работает - считать нужно fan-out на подагентов, глубину циклов верификации и уровень параллелизма (максимальный для задачи)
2️⃣ Юнит экономику надо считать не по запросам, а по выполненным задачам: агент может быть дорогим в токенах, но дешёвым относительно стоимости человека или цены задержки бизнес-процесса
3️⃣ Если ROI от AI-инструментов действительно остаётся кратно выше их стоимости, как пишет SemiAnalysis, то спрос на вычисления ещё долго будет слабо чувствителен к цене. А значит, рост GPU-потребления - это не временный всплеск хайпа, а новая реальность.
TLDR;
Раньше GPU в основном потребляли модели, а теперь GPU потребляют бизнес-процессы, разложенные на рой агентных подзадач. И именно мульти-агентные нагрузки могут оказаться главным скрытым драйвером нового дефицита вычислений.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Productivity #Agents #Economics
Интересная статья от SemiAnalysis про агрессивный рынок аренды GPU, который вошел в клинч и цены взлетели вверх из-за роста спроса. Стоимость годового контракта на H100 выросла примерно на 40% - с $1.70 за GPU-час в октябре 2025 до $2.35 к марту 2026. On-demand capacity по сути выбрана по всем типам GPU, а Blackwell-кластеры, которые выходят в строй в середине 2026 года, во многих случаях уже заранее заняты. Даже найти кластер на 64 Hopper GPU стало нетривиально.
Авторы прямо связывает новую волну давления на рынок с резким ростом спроса на фоне agentic нагрузок поверх моделей. То есть узкое место теперь формируется не только гонкой лабораторий в тренировке новых моделей, а продакшен-инференсом, где модель перестаёт быть "чатом" и становится исполнителем рабочих процессов. В классическом chat UX экономика была относительно простой: один пользовательский запрос, один inference-pass, один ответ. В агентном мире одна задача раскладывается в дерево вызовов: оркестратор строит план, порождает субагентов, те параллельно ищут источники, читают код, ходят в инструменты, возвращают промежуточные результаты, после чего отдельный контур делает синтез, критику и верификацию. Например, cнаружи задача может выглядеть как "разбери инцидент" или "подготовь PR", а под капотом это уже рой субагентов.
В итоге, спрос на рынке растет уже не только от числа пользователей и не только от числа компаний, а скорее от того сколько задач делегируются агентам. Один и тот же разработчик, аналитик или исследователь теперь может запускать не один запрос к модели, а десятки координированных проходов - с длинным контекстом, ретраями, проверками и параллельными ветками. У мульти-агентных нагрузок есть неприятная для инфраструктуры особенность: они увеличивают не только суммарное потребление токенов, но и пиковую конкурентность, а это уже прямое давление на флот GPU.
Интересно, что этот спрос неравномерен. Авторы пишут, что часть inference-нагрузок, особенно большие MoE-сценарии, лучше работает на свежих системах вроде GB300 NVL72, тогда как тренировки и часть нагрузок, где важна стоимость к производительности, продолжают отлично жить на H100. Иными словами, новый агентный слой не просто "съедает Blackwell" - он одновременно поддерживает спрос и на Hopper, продлевая экономическую жизнь уже поставленных GPU. Поэтому у провайдеров сейчас не ценовая война за загрузку, а рынок продавца с длинными контрактами, предоплатой и выбором, кому вообще отдавать capacity.
Отсюда можно почерпнуть несколько выводов:
1️⃣ Планирование мощностей по модели "сколько у нас чатов в день" больше не работает - считать нужно fan-out на подагентов, глубину циклов верификации и уровень параллелизма (максимальный для задачи)
2️⃣ Юнит экономику надо считать не по запросам, а по выполненным задачам: агент может быть дорогим в токенах, но дешёвым относительно стоимости человека или цены задержки бизнес-процесса
3️⃣ Если ROI от AI-инструментов действительно остаётся кратно выше их стоимости, как пишет SemiAnalysis, то спрос на вычисления ещё долго будет слабо чувствителен к цене. А значит, рост GPU-потребления - это не временный всплеск хайпа, а новая реальность.
TLDR;
Раньше GPU в основном потребляли модели, а теперь GPU потребляют бизнес-процессы, разложенные на рой агентных подзадач. И именно мульти-агентные нагрузки могут оказаться главным скрытым драйвером нового дефицита вычислений.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Productivity #Agents #Economics
Semianalysis
The Great GPU Shortage – Rental Capacity – Launching our H100 1 Year Rental Price Index
GPU Rental Pricing Dashboard Launch
25❤5🔥5💯5😁1🤨1
The How to be British Collection (Рубрика #Humor)
Из прошлой поездки в Лондон я привез пару шуточных книг о том, как быть британцем. Я их полистал по приезду, но прочитал полностью только сейчас, когда пришла пора лететь в Лондон всей семьей. Могу отметить, забавные иллюстрации и меткие описания, которые хорошо описывают то, что я видел/чувствовал в первой поездке.
Уже завтра смогу сравнить юмор авторов этого сборника и реальность Лондона:)
#Travel #Humor
Из прошлой поездки в Лондон я привез пару шуточных книг о том, как быть британцем. Я их полистал по приезду, но прочитал полностью только сейчас, когда пришла пора лететь в Лондон всей семьей. Могу отметить, забавные иллюстрации и меткие описания, которые хорошо описывают то, что я видел/чувствовал в первой поездке.
Уже завтра смогу сравнить юмор авторов этого сборника и реальность Лондона:)
#Travel #Humor
😁16❤9👍2
Code of Leadership 2. Эпизод #2 - Не усложняй. Управление проектами с Дмитрием Ильенковым (Рубрика #Management)
Вышел второй выпуск второго сезона моего подкаста Code of Leadership. В этот раз в гостях был Дмитрий Ильенков - основатель @pmclub, человек с большим опытом в проектном управлении и соавтор книги «Не усложняй! Управление проектами по методу P3.express», о которой я уже рассказывал раньше. Говорили мы в этом эпизоде о проектном управлении без лишнего пафоса и без попытки превратить менеджмент в набор тяжелых ритуалов. Главная тема выпуска - как управлять проектами так, чтобы методология помогала доводить работу до результата, а не превращалась в бюрократический театр.
- P3.express хорошо ложится на роль практического входа в проектное управление
- Простота методологии не минус, а плюс
- Принципы важны, потому что без них методология легко превращается в карго-культ
- Управление проектами - это постоянный поиск слабого звена в цепочке и его оптимизация
- Метрики полезны, но цель нельзя сводить только к цифре
- Хороший процесс нужен не вместо результата, а для того, чтобы можно было получить предсказуемый результат
В общем, выпуск получился не про "еще одну методологию", а про здравый смысл в управлении проектами. Как не усложнять там, где можно сделать проще, но и не скатываться в хаос под видом гибкости. Рекомендую тем, кто управляет проектами, продуктами, командами или просто регулярно оказывается в ситуации, где нужно довести сложную работу до результата вместе с другими людьми.
Выпускк доступен на разных платформах: Youtube, VK, Ya Music, Podster.fm.
#Management #Leadership #ProjectManagement #Processes #Engineering
Вышел второй выпуск второго сезона моего подкаста Code of Leadership. В этот раз в гостях был Дмитрий Ильенков - основатель @pmclub, человек с большим опытом в проектном управлении и соавтор книги «Не усложняй! Управление проектами по методу P3.express», о которой я уже рассказывал раньше. Говорили мы в этом эпизоде о проектном управлении без лишнего пафоса и без попытки превратить менеджмент в набор тяжелых ритуалов. Главная тема выпуска - как управлять проектами так, чтобы методология помогала доводить работу до результата, а не превращалась в бюрократический театр.
- P3.express хорошо ложится на роль практического входа в проектное управление
- Простота методологии не минус, а плюс
- Принципы важны, потому что без них методология легко превращается в карго-культ
- Управление проектами - это постоянный поиск слабого звена в цепочке и его оптимизация
- Метрики полезны, но цель нельзя сводить только к цифре
- Хороший процесс нужен не вместо результата, а для того, чтобы можно было получить предсказуемый результат
В общем, выпуск получился не про "еще одну методологию", а про здравый смысл в управлении проектами. Как не усложнять там, где можно сделать проще, но и не скатываться в хаос под видом гибкости. Рекомендую тем, кто управляет проектами, продуктами, командами или просто регулярно оказывается в ситуации, где нужно довести сложную работу до результата вместе с другими людьми.
Выпускк доступен на разных платформах: Youtube, VK, Ya Music, Podster.fm.
#Management #Leadership #ProjectManagement #Processes #Engineering
YouTube
Code of Leadership - S2E2 - Не усложняй или управление проектами с Дмитрием Ильенковым
Второй выпуск второго сезона моего подкаста Code of Leadership. В этот раз в гостях был Дмитрий Ильенков — основатель pmclub https://youtube.com/@PMCLUBpro, человек с большим опытом в проектном управлении и соавтор книги «Не усложняй! Управление проектами…
❤7👍7🔥1
Measuring the effectiveness of software development tools and practices (Рубрика #Productivity)
Я часто рассказываю про тему продуктивности инженеров, а также подходов к этому крупных компаний (смотри статьи от Google, или статьи запрещенной в России Meta), а также про то, как мы внутри Т-Банка подходим к этому. Но сегодня я хотел рассказать про подход Amazon к этому непростому снаряду - авторы предлагают метод измерения экономического эффекта от инструментов и практик разработки. Они предлагают смотреть на единую метрику CTS-SW (cost-to-serve software) - по сути, сколько ресурсов уходит на доставку единицы ПО до клиента. Эта метрика должна связать привычные engineering-метрики в духе DORA/SPACE с понятным бизнес-результатом: сэкономленной инженерной емкостью или деньгами.
Интересно, что у нас внутри Т-Банка тоже есть похожие подходы к расчетам, которые основаны на унификации процессов разработки и выделении уровня задач в командах, что приносят понятный бизнес-результат. Но давайте вернемся к оригинальной статье и посмотрим как работает подход авторов
1️⃣ Они берут "стоимость доставки ПО" как итоговую метрику, а не пытаются детально оценить каждый шаг разработки
Авторы говорят, что классический activity-based costing для софта слишком хрупок и поэтому они упрощают задачу до "входные затраты → единица результата", а затем уже ищут драйверы этой стоимости по всему жизненному циклу: coding, CI/CD, planning, incident management, maintenance, search for information и т.д. Единица результата тоже подбирается под архитектуру
- Микросервисы - деплои
- Монолит - зашипленный в мастер код
- Библиотеки - коммиты
2️⃣Дальше они строят панельные данные (микс факторов + время) и используют линейные смешанные модели
У них есть телеметрия по тысячам "two-pizza teams" за пять лет, и они моделируют CTS-SW через время разработчиков на деплой. Линейные смешанные модели нужны им потому, что они одновременно ловят общий эффект факторов и различия между командами. Так они нашли основные кандидаты-драйверы CTS-SW:
- Team velocity (сколько отревьювернного кода команда мерджит в неделю на инженера) - самый сильный предиктор
- Здоровье деливери (например, рейт ролбеков)
- Пейджи на on-call инженера
3️⃣ Переходят от корреляции к причинности через causal inference
После нахождения эффектов авторы ищут возможность для эксперимента. Таким естественным экспериментом для них стало внедрение genAI-инструментов, в частности Amazon Q Developer. Для оценки они строят панельную регрессию с dynamic two-way fixed effects: учитывают постоянные различия между командами, общие временные эффекты, лаг прошлой скорости и time-varying covariates вроде доли команды, использующей Q Developer, rollback rate и manual interventions. Цель - не просто увидеть корреляцию, а изолировать именно причинный вклад инструмента в CR velocity и deployment velocity.
4️⃣ Добавляют "страховку" от переоценки эффекта AI
Авторы отдельно признают, что если просто складывать эффекты разных экспериментов, можно завысить реальное влияние. Поэтому они разрабатывают baseline model, чтобы нормализовать оценки влияния AI-инструментов.
В общем, это явно интересный подход, который позволяет
- Решать, какие dev tools и AI tools масштабировать, исходя из измеримого эффекта
- Приоритизировать CI/CD автоматизации и практики надежности, потому что они свзяаны с лучшим CTS-SW.
- Создавать через онбординг условия для высокой team velocity, но использовать это именно как командную, а не индивидуальную метрику.
- Осторожно интерпретировать "полезные" сигналы
В будущем авторы хотят расширить модель, чтобы сравнивать архитектурные решения и давать рекомендации.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Software #Agents #Economics
Я часто рассказываю про тему продуктивности инженеров, а также подходов к этому крупных компаний (смотри статьи от Google, или статьи запрещенной в России Meta), а также про то, как мы внутри Т-Банка подходим к этому. Но сегодня я хотел рассказать про подход Amazon к этому непростому снаряду - авторы предлагают метод измерения экономического эффекта от инструментов и практик разработки. Они предлагают смотреть на единую метрику CTS-SW (cost-to-serve software) - по сути, сколько ресурсов уходит на доставку единицы ПО до клиента. Эта метрика должна связать привычные engineering-метрики в духе DORA/SPACE с понятным бизнес-результатом: сэкономленной инженерной емкостью или деньгами.
Интересно, что у нас внутри Т-Банка тоже есть похожие подходы к расчетам, которые основаны на унификации процессов разработки и выделении уровня задач в командах, что приносят понятный бизнес-результат. Но давайте вернемся к оригинальной статье и посмотрим как работает подход авторов
1️⃣ Они берут "стоимость доставки ПО" как итоговую метрику, а не пытаются детально оценить каждый шаг разработки
Авторы говорят, что классический activity-based costing для софта слишком хрупок и поэтому они упрощают задачу до "входные затраты → единица результата", а затем уже ищут драйверы этой стоимости по всему жизненному циклу: coding, CI/CD, planning, incident management, maintenance, search for information и т.д. Единица результата тоже подбирается под архитектуру
- Микросервисы - деплои
- Монолит - зашипленный в мастер код
- Библиотеки - коммиты
2️⃣Дальше они строят панельные данные (микс факторов + время) и используют линейные смешанные модели
У них есть телеметрия по тысячам "two-pizza teams" за пять лет, и они моделируют CTS-SW через время разработчиков на деплой. Линейные смешанные модели нужны им потому, что они одновременно ловят общий эффект факторов и различия между командами. Так они нашли основные кандидаты-драйверы CTS-SW:
- Team velocity (сколько отревьювернного кода команда мерджит в неделю на инженера) - самый сильный предиктор
- Здоровье деливери (например, рейт ролбеков)
- Пейджи на on-call инженера
3️⃣ Переходят от корреляции к причинности через causal inference
После нахождения эффектов авторы ищут возможность для эксперимента. Таким естественным экспериментом для них стало внедрение genAI-инструментов, в частности Amazon Q Developer. Для оценки они строят панельную регрессию с dynamic two-way fixed effects: учитывают постоянные различия между командами, общие временные эффекты, лаг прошлой скорости и time-varying covariates вроде доли команды, использующей Q Developer, rollback rate и manual interventions. Цель - не просто увидеть корреляцию, а изолировать именно причинный вклад инструмента в CR velocity и deployment velocity.
4️⃣ Добавляют "страховку" от переоценки эффекта AI
Авторы отдельно признают, что если просто складывать эффекты разных экспериментов, можно завысить реальное влияние. Поэтому они разрабатывают baseline model, чтобы нормализовать оценки влияния AI-инструментов.
В общем, это явно интересный подход, который позволяет
- Решать, какие dev tools и AI tools масштабировать, исходя из измеримого эффекта
- Приоритизировать CI/CD автоматизации и практики надежности, потому что они свзяаны с лучшим CTS-SW.
- Создавать через онбординг условия для высокой team velocity, но использовать это именно как командную, а не индивидуальную метрику.
- Осторожно интерпретировать "полезные" сигналы
В будущем авторы хотят расширить модель, чтобы сравнивать архитектурные решения и давать рекомендации.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Software #Agents #Economics
Amazon Science
Measuring the effectiveness of software development tools and practices
New cost-to-serve-software metric that accounts for the full software development lifecycle helps determine which software development innovations provide quantifiable value.
1❤13👍5🔥2👎1🤔1
1❤17👍9🔥3