Research Insights Made Simple

Alexander Polomodov

Подкаст от Александра Поломодова, технического директора и Fellow, с обсуждением научных статей из области computer science и engineering. Каждый эпизод подкаста посвящен одной статье и в каждом эпизоде есть приглашенный гость-эксперт, который собаку съел в этой теме. Обычно эпизод длится час-полтора и может сопровождаться схемами из статьи или быть чисто в разговорном жанре.

  1. 13h ago

    Проектирование обвязки для кодинговых агентов: что даёт обвязка

    В очередном эпизоде из серии об обвязках агентов Research Insights Made Simple поговорим про опубликованное в сентябре 2026 года исследование "An Empirical Study of Harness Design for Coding Agents" (https://arxiv.org/abs/2609.20804v1). Авторы фиксируют цикл агента и меняют три компонента: планирование, инструменты и управление контекстом. Они сравнивают 176 экспериментальных настроек на четырёх моделях и двух наборах задач — SWE-bench Verified и Terminal-Bench 2.1. Обсудим Когда управление контекстом спасает задачу от переполнения окна. Почему сокращение старых ответов инструментов перед пересказом может снизить стоимость. Как план помогает слабой модели продолжать работу, а сильной — вовремя остановиться. Когда нужны готовые инструменты, а когда достаточно bash. Как по траектории агента найти причину сбоя и проверить пользу изменения на своих задачах. Выводы относятся к моделям, задачам и реализациям из исследования. Разберём, что стоит проверить перед переносом этих результатов в собственную систему. Все выпуски Research Insights Made Simple: https://polomodov.tech/research-insights

    Проектирование обвязки для кодинговых агентов: что даёт обвязка
  2. 1d ago

    AI и платформа данных / Как подключить AI ко всей совокупности данных организации

    12 октября в Research Insights Made Simple снова встречаемся с Колей Головым и продолжаем разговор про платформы данных. В этот раз разберём, как объединить операционные базы, аналитику и AI-агентов и можно ли при этом избавиться от привычного зоопарка интеграций. Николай Голов - директор по продукту одной из датаплатформ, доступных на российском рынке. Раньше он руководил дата-платформами в Avito и ManyChat, преподаёт базы данных и системы хранения в Harbour.Space (https://harbour.space/faculty/Nikolay-Golov). Так что обсудим и устройство технологий, и практику построения платформ, которые потом кому-то поддерживать. На картинке всё выглядит заманчиво: оставляем PostgreSQL для транзакций, изменения из остальных систем отправляем через CDC в объектное хранилище, сверху ставим Lakehouse и подключаем агентов через MCP. Данные собраны, инструменты доступны, можно задавать вопросы. Правда, между «сложили всё в S3» и «агент правильно понял бизнес» ещё помещается довольно много инженерной работы :) Посмотрим, как к этой задаче подходят Databricks, Snowflake, ClickHouse, Microsoft Fabric, Google, AWS и Oracle. У кого-то объединение происходит на уровне хранения, у кого-то через репликацию и общие запросы, а кто-то собирает всё внутри одной СУБД. За похожими словами про единую платформу скрываются разные архитектуры и разные ограничения. Поговорим о том Где проходят границы между OLTP, аналитикой и агентным бэкендом; Что на практике означают «одна копия данных» и zero-ETL; Когда CDC и Lakehouse упрощают жизнь, а когда добавляют ещё одну систему, за которой надо следить; Какую роль могут играть PostgreSQL, DuckLake и S3 в собственной платформе; Что нужно агенту помимо доступа к таблицам: определения показателей, права, контекст и возможность проверить результат. Хочется понять, какую сложность эти подходы действительно убирают и какая просто переезжает в другое место. Выпуск будет полезен архитекторам, инженерам данных и руководителям, которые выбирают платформу или подключают AI к существующим данным.

    AI и платформа данных / Как подключить AI ко всей совокупности данных организации
  3. 4d ago

    Проектирование обвязки для длительной (автономной) разработки приложений

    Как организовать работу кодингового агента, чтобы он мог несколько часов создавать приложение, проверять результат и исправлять ошибки? Продолжаем серию про инженерную обвязку агентов. И здесь мы разберём статью Anthropic Harness design for long-running application development. Её автор экспериментирует с разделением планирования, разработки и оценки результата. В прямом эфире обсудим: - Как устроены роли planner, generator и evaluator. - Зачем до написания кода согласовывать критерии готовности и как проверять работающее приложение. - Можно ли формализовать вкус при оценке дизайна и насколько надёжен отдельный агент-критик. - Сколько стоят дополнительные итерации и что показывают приведённые сравнения. - Почему с усилением моделей некоторые части обвязки становятся лишними. А в конце поговорим о следующем шаге: сможет ли агент сам улучшать собственный harness — и кто тогда будет проверять эти улучшения? Timeline 00:00 - Четвёртый разбор обвязок: приложения по одному запросу 01:33 - Две задачи Anthropic Labs 03:04 - Идея из GAN: отдельный критик 06:22 - Предел контекста и снисходительная самооценка 08:10 - Сжатие, сброс и стоимость передачи работы 12:40 - Четыре критерия качества дизайна 15:00 - Итерации фронтенда и выбор варианта 17:16 - Планировщик, генератор и оценщик 18:39 - Контракт спринта до реализации 20:32 - Ретро-игры: двадцать минут против шести часов 23:40 - Почему проверяющему нужна настройка 25:43 - Opus 4.6: проверка и упрощение компонентов 30:46 - Звуковая станция и оценщик, который не слышит 34:41 - Автономность и внешний контроль риска 38:56 - Журнал событий и дальнейшая эволюция обвязки

    Проектирование обвязки для длительной (автономной) разработки приложений
  4. 5d ago

    Инженерия обвязки: среда для агентов

    В четверг, 8 октября, в прямом эфире разберу статью OpenAI «Harness engineering: leveraging Codex in an agent-first world» ( https://openai.com/index/harness-engineering/ ) В предыдущем выпуске (https://www.youtube.com/watch?v=qVXELX0j6dY) говорили о передаче работы между сессиями агента. Теперь посмотрим на всю среду разработки: как устроить репозиторий, знания, инструменты и проверки, чтобы агент мог самостоятельно двигать проект вперёд. Обсудим: Как меняется работа инженера, когда код пишет агент. Зачем агенту видеть приложение, логи и результаты проверок. Как сохранять архитектурные ограничения и качество кода. Что можно перенести из опыта OpenAI в свою команду и как проверить пользу этих изменений. Статья описывает опыт одной команды. Отдельно поговорим о границах её выводов и о том, какие данные нужны для оценки результата. Timeline 00:00 - От интерфейса агента к среде разработки 01:41 - Запрет писать код руками как метод 04:25 - Пять месяцев, команда и результаты кейса 06:43 - Сбой агента требует изменения среды 07:56 - Внимание инженеров, DevTools и рабочие деревья Git 10:54 - Наблюдаемость превращает пожелания в проверки 12:04 - Недоступные знания и параллель с новичком 14:45 - AGENTS.md как карта к документам 17:14 - Явная архитектура и линтеры с инструкциями 20:42 - Инварианты на границах и свобода реализации 24:00 - От бага до слияния: автономия и цена ошибки 27:13 - Фоновая очистка вместо пятничного разбора долга 29:53 - Каких доказательств и измерений нет в статье 32:10 - Как проверить механизм на своих задачах 38:58 - Symphony: от управления сессиями к задачам

    Инженерия обвязки: среда для агентов
  5. 6d ago

    Долгоживущие агенты: передача работы

    Агент написал часть приложения, контекст закончился — и следующая сессия начинает разбираться заново. Код сохранился, но замысел, незавершённые изменения и результаты проверок остались в прошлой беседе. После SWE-agent продолжим серию про обвязки агентов. Разберём статью Anthropic (https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents) о работе через несколько сессий: - почему сжатия контекста недостаточно; - зачем нужны список функций, журнал прогресса и история Git; - как делать небольшие проверяемые шаги; - что оставлять следующей сессии, чтобы она могла продолжить начатое. Будет полезно тем, кто строит кодинговых агентов и поручает им задачи, выходящие за одно контекстное окно. Timeline 00:00 - Зачем передавать работу между сессиями 01:51 - Инженерный опыт Anthropic и проверенная основа 05:09 - Инициализатор и агент-разработчик 07:09 - Почему сжатия контекста недостаточно 09:17 - Много недоделок и преждевременная готовность 14:04 - За что отвечают четыре артефакта 16:22 - Функция как пользовательский сценарий 18:48 - JSON, Markdown и границы запрета в промпте 19:36 - Ориентирование и одна функция за шаг 21:59 - Проверка в браузере и невидимые alert 24:19 - Git и содержательная запись прогресса 28:59 - Что доказано и как проверить обвязку 32:13 - Полный цикл рабочей сессии 33:42 - Как продолжение истории меняет обвязку 38:15 - Как читать статьи с заметками и обсуждать их с LLM

    Долгоживущие агенты: передача работы
  6. Oct 5

    SWE-agent или как интерфейс меняет результат

    5 октября в 12:00 МСК — прямой эфир Research Insights Made Simple. Сольный выпуск с Александром Поломодовым: разбираем статью «SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering» с NeurIPS 2024. Что меняется, если дать той же языковой модели более удобный интерфейс для работы с репозиторием? Вместо разговора только о моделях и промптах посмотрим на действия агента и обратную связь, которую он получает. В программе Поиск по коду и чтение файлов: как агент находит нужное и сохраняет ориентиры. Многострочные правки и проверка синтаксиса: как предотвращать ошибки и восстанавливаться после них. Управление контекстом: что показывать модели, что сокращать и что сохранять. Результаты SWE-bench и SWE-bench Lite: с чем сравнивают SWE-agent и что показывают абляции. Выводы для современных агентов: какие принципы стоит перенести в свою систему, а какие настройки остались частью эксперимента 2024 года. Timeline 00:00 - Зачем возвращаться к SWE-agent 2024 года 01:05 - SWE-bench: реальные задачи в чужом проекте 03:00 - Зачем модели собственный интерфейс 04:45 - Цикл мысли, действия и наблюдения 06:32 - Как проверяли решения и ограничивали бюджет 08:49 - Результаты на полном SWE-bench 10:01 - Демонстрации и сравнение с обычным shell 10:55 - Поиск файлов и нужных мест в коде 14:30 - Просмотр с номерами строк и команда edit 17:20 - Отклонение правки и обратная связь линтера 20:37 - Абляции: что дают редактирование и проверки 22:19 - Окно просмотра и управление историей 24:54 - Траектории, повторные попытки и пределы модели 29:18 - Как авторы улучшали интерфейс экспериментами 31:47 - Принципы ACI, SWE-smith и mini-SWE-agent

    SWE-agent или как интерфейс меняет результат
  7. Sep 28

    vLLM и PagedAttention / виртуальная память для инференса LLM

    Модель поместилась в GPU, тестовый запрос отработал быстро. Что произойдёт, когда одновременно придут сотни запросов с разной длиной контекста и ответа? 23 сентября 2026 года в эфире Research Insights Made Simple #32 разберу whitepaper 2023 года про vLLM и устройство инференса LLM: как управление памятью, планирование запросов и передача состояния между узлами влияют на скорость сервиса. Начнём с KV-кеша — ключей и значений уже обработанных токенов, которые модель сохраняет для следующих шагов генерации. Посмотрим, как PagedAttention применяет идеи виртуальной памяти к этому кешу и позволяет эффективнее размещать активные запросы на GPU. А дальше разберём, какие задачи приходится решать вокруг движка. Выпуск для инженеров, архитекторов и платформенных команд, которые разворачивают LLM, выбирают движок инференса или хотят понять, что происходит за API модели. Исследование PagedAttention, SOSP 2023: https://arxiv.org/abs/2309.06180 Все выпуски Research Insights Made Simple: https://polomodov.tech/research-insights/ Timeline 00:00 - Почему возвращаемся к статье 2023 года 03:26 - Обработка промпта и генерация токенов 06:09 - Бюджет памяти и цена KV-кеша 11:10 - Резерв и два вида фрагментации 13:36 - Почему даже знание длины ответа не спасает Orca 15:58 - Страничная память: идея из операционных систем 19:42 - PagedAttention и косвенный доступ к блокам 23:36 - Как растущий запрос получает новые блоки 26:11 - Общий префикс и копирование при записи 29:44 - Дерево блоков для beam search 32:21 - Вытеснение: перенос или повторное вычисление 36:01 - Планировщик и рабочие процессы GPU 38:05 - Пропускная способность при той же задержке 39:17 - Цена косвенности и выбор размера блока 41:37 - Инженерные выводы и границы применимости

    vLLM и PagedAttention / виртуальная память для инференса LLM
  8. Sep 23

    AI4SDLC / что бы я делал по-другому

    В этом выпуске разберу, как провести границу владения AI-стеком и связать модель, агентную обвязку, инструменты, контекст и проверки результата в работающую систему. Поговорим о том: Когда использовать готовый цикл агента и где оправдана собственная обвязка; Почему способности модели, полномочия агента и выполненная задача — три разных вещи; Какие проблемы можно исправить маршрутизацией, контекстом и контрактами инструментов, а какие требуют изменений модели или инфраструктуры; Чем телеметрия отличается от evals и данных для обучения; Как сохранить эпизод, воспроизвести его, изменить один слой и проверить результат повторным прогоном; Когда повторяемую задачу можно передать меньшей модели и при каких условиях возвращать её большой. Выпуск для инженеров, архитекторов, руководителей разработки и платформенных команд, которые выбирают или строят AI-инструменты для SDLC. Слайды доклада на Deep Tech Night: https://polomodov.tech/2026-09-05-deep-tech-night-ai-development-stack-codesign/ Все выпуски Research Insights Made Simple: https://polomodov.tech/research-insights/ Напишите в комментариях, какую часть AI-стека вы уже делаете сами и почему. Это как раз те решения, на которых хочется проверить предложенную рамку. Timeline 00:00 - Зачем понадобилась режиссёрская версия 02:42 - Что арендовать, дорабатывать и чем владеть 14:15 - Маршрутизация, контекст и внутренние адаптеры 18:15 - Полномочия агента и границы делегирования 22:39 - Трассировка, проверки качества и переносимость 26:04 - Почему модель — только часть системы 33:10 - Как начать собирать проверочные случаи 39:20 - Быстрый и медленный циклы улучшений 45:58 - Как проверить полезность контекста 48:37 - Разные способы связать слои AI-стека 1:02:27 - Инструменты: MCP, ошибки и конечное состояние 1:06:40 - Почему демонстраций и телеметрии недостаточно 1:13:28 - Каталог проверяемых инженерных эпизодов 1:19:30 - Меньшие модели и разделение планирования и исполнения 1:21:50 - Что стоило изменить во внедрении и безопасности

    AI4SDLC / что бы я делал по-другому

About

Подкаст от Александра Поломодова, технического директора и Fellow, с обсуждением научных статей из области computer science и engineering. Каждый эпизод подкаста посвящен одной статье и в каждом эпизоде есть приглашенный гость-эксперт, который собаку съел в этой теме. Обычно эпизод длится час-полтора и может сопровождаться схемами из статьи или быть чисто в разговорном жанре.