Разборы · Статья: · Видео: · 14:40

RL-агент для упавших ETL-пайплайнов: восстановление за минуты и дисциплина вовремя остановиться

Разбор доклада Анны Мари Бензон с AI Engineer: как собрать агента, который сам чинит рутинные сбои ETL на AWS — детерминизм для фактов, обучение для выбора действия, guardrails для полномочий — и почему честная эскалация к человеку это функция, а не провал.

ИИ Программирование Продуктивность
Смотреть на YouTube

Using RL Agent to Detect and Remediate ETL Pipeline Failures - Anna Marie Benzon

AI Engineer · 14:40

Коротко

Агент ловит событие о сбое ETL, собирает улики из логов и схемы, классифицирует поломку и выбирает одно ограниченное действие — повторить, привести схему, откатить, изолировать, эскалировать или залогировать — а внешний слой безопасности проверяет решение до исполнения. Главный вывод честен до неприятного: надёжность дали структура состояния, простая логика и внешние ограничители, а не сам RL, который на компактном пространстве лишь сравнялся с написанной вручную политикой.

Выжимка голосом

Самое ценное из разбора — за пару минут

0:00 2:24
Показать текст выжимки
Если коротко, это разбор доклада о том, как построить агента, который сам чинит упавшие дата-пайплайны и знает, когда позвать человека. Главная мысль автора простая. Когда ночью падает загрузка данных, дорого не само падение, а всё вокруг него. Надо понять, что сломалось, выбрать безопасное лечение, перезапустить задачу и убедиться, что данные не стали хуже. Ручное восстановление одного инцидента смоделировано примерно в два с половиной рабочих дня. Агент работает на облачной инфраструктуре. Он ловит событие о сбое, собирает улики из логов и схемы, ставит диагноз и выбирает одно из шести ограниченных действий. Повторить, привести схему, откатить, изолировать данные, эскалировать или просто записать событие. А отдельный слой безопасности проверяет это решение до исполнения. Оценка получается честной. За четырнадцать минут дают архитектуру, реальные числа и разбор с отключением компонентов. И вот неприятный, но ценный вывод. Обучение с подкреплением почти не дало прироста. На маленьком пространстве оно лишь сравнялось с политикой, написанной вручную. Надёжность пришла от структуры, простой логики и внешних ограничителей. Кому это полезнее всего. В первую очередь дата-инженерам на дежурстве и инженерам по надёжности систем. Пара инсайтов. Первый. Эскалация к человеку это не провал агента, а его функция. Второй. Действие может быть безопасным в принципе и всё равно недоступным здесь и сейчас. Что делать. Разделяй факты и решения. Выноси ограничители наружу обучаемой политики. И сначала запускай агента в теневом режиме, где он советует, но ничего не меняет. Важный контраргумент. Громкое сокращение времени восстановления получено на синтетике, а не в реальном проде. Каждый четвёртый случай всё равно идёт к человеку. Финальная мысль. Хорошая само-восстанавливающаяся система не про самую большую модель, а про чистое состояние, ограниченные действия и дисциплину вовремя остановиться.

Озвучено синтезом речи · голос alena

Объясни проще

Суть без жаргона

Простыми словами

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

Как ребёнку

Представь конвейер, по которому едут коробки с данными. Иногда коробка застревает. Раньше человек ночью бежал разбираться сам. Теперь у конвейера есть умный дежурный: он смотрит, что застряло, аккуратно поправляет по простым правилам, а если не уверен — не ломает всё подряд, а нажимает кнопку «позовите взрослого».

Аналогия — «это как…»

Это как автопилот, который сам объезжает знакомые ямы на дороге, но у него жёстко зашито: в тумане и на незнакомом перекрёстке руль отдаётся водителю. Умение вовремя сказать «дальше не я» здесь не баг, а часть конструкции.

Зачем это мне

Дата-команды тонут в ночных инцидентах, а бизнес хочет «self-healing» пайплайны — но наивная автономия опасна: агент может «починить» так, что испортит данные молча. Доклад показывает работающий баланс: где отдать решение обучению, где оставить жёсткие правила и как встроить ограничители, которым доверит операционная команда.

Для тех, кто в теме

Инцидент моделируется как одношаговое контекстное решение на tabular Q-learning: компактное состояние (категория сбоя, уровень риска, счётчик повторов, серьёзность дрейфа, качество данных) → одно из шести ограниченных действий. Детерминированные детекторы дают факты (schema profiler, drift detector, data-quality analyzer, error classifier, risk scorer), safety override живёт вне политики и превращает пассивное действие в эскалацию при критической аномалии. Ablation: RL = детерминированная политика (разница 0 п.п. при CI 0,19), детерминизм > random на 15,63 п.п., safety override снижает non-escalation на ~15 п.п. — надёжность из структуры, а не из RL.

Оценка видео

Чем выше — тем больше пользы на минуту

4.5

средняя из 5

Актуальность информации 4.7

Self-healing дата-пайплайны и надёжные агенты — одна из горячих тем 2026 года; стек AWS Glue/EventBridge/Lambda актуален прямо сейчас.

Содержательность 4.7

За 14 минут — архитектура, три слоя логики, реальные числа с доверительными интервалами и ablation; воды почти нет.

Инновационность идей 3.8

Сильна инженерная рамка «правила/обучение/ограничители», но сам RL здесь скромен — tabular Q-learning лишь сравнялся с ручной политикой.

Практичность 4.5

Пять чётких принципов и воспроизводимый публичный benchmark — можно брать и переносить на свой incident-response.

Достоверность и баланс 4.8

Автор сама называет границы: синтетика, реакция после сбоя, часть действий симулирована; отчитывается 95%-ми доверительными интервалами.

Кому будет полезно

Чем выше оценка — тем больше пользы для профессии. Разверни — почему.

Для дата-инженеров 4.9 /5

Прямое попадание: schema drift, null-rate спайки, перезапуск задач, безопасное лечение и MTTR — это их ночные боли, разложенные по полочкам.

Для SRE и инженеров по надёжности 4.6 /5

Готовая модель incident-response: closed loop monitor-diagnose-decide-verify, safety-слой, эскалация и audit-запись каждого решения.

Для разработчиков AI-агентов 4.5 /5

Образцовый разбор ограниченного пространства действий, guardrails вне политики и эскалации как функции — как строить агента, которому доверят полномочия.

Для ML-инженеров 4.2 /5

Отрезвляющий кейс про «ML-ready ≠ ML-required»: когда обучение реально добавляет ценность, а когда детерминизм честнее и дешевле.

Для платформенных и DevOps-инженеров 4 /5

Конкретная event-driven архитектура на AWS (Glue → EventBridge → Lambda → S3) с read-only сбором улик и approval gates для автономии.

Для дата-аналитиков 3.3 /5

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

Инсайты

Нажми, чтобы раскрыть — то, что меняет взгляд на тему

01 Дорог не сам сбой, а петля вокруг него

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

02 Эскалация — это возможность, а не провал

Кнопка «зову человека» встроена прямо в пространство действий агента. Это не капитуляция, а корректное признание границы своих улик или полномочий. Если мерить успех только редкостью эскалаций — оптимизируешь неправильную цель.

03 Надёжность дал не RL

В ablation обучаемая политика лишь сравнялась с написанной вручную (разница 0 п.п.). Прирост надёжности пришёл от структурированного состояния, вменяемой логики решений и внешних ограничителей — RL дал инспектируемую поверхность решений, а не выигрыш в success rate.

04 Безопасно в принципе ≠ исполнимо сейчас

Это два разных контроля. Действие может пройти проверку безопасности и всё равно оказаться недоступным в текущей среде. Надёжный агент представляет оба условия явно и не притворяется, что починка случилась.

05 ML-ready — не то же самое, что ML-required

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

Ключевые цитаты

Сильные фразы из видео — нажми тайм-код, чтобы услышать в оригинале

«Сам сбой может быть маленьким, но дорого стоит всё вокруг него: осмотр, диагноз, выбор безопасного ответа, перезапуск задачи и проверка того, что мы не сделали данные хуже.»
Почему инциденты ETL так затратны
«Вопрос не в том, может ли агент действовать, а в том, может ли он действовать полезно, объяснимо и в границах, которым операционная команда действительно доверится.»
Центральная постановка задачи
«Правила — для фактов, обучение — для ограниченного выбора, ограничители — для полномочий.»
Проектная идея системы
«Готовность к машинному обучению — не то же самое, что необходимость в нём. Каждым решением должен владеть простейший надёжный компонент.»
Где ML нужен, а где нет
«Способность сказать «я не должен делать это автоматически» — это возможность, а не капитуляция. Если мерить успех только тем, как редко агент зовёт человека, вы оптимизируете не то.»
Эскалация как первоклассный исход
«Один удачный прогон — это демо, а не доказательство.»
Про честную оценку на множестве seed-ов

Полезные советы

Что можно применить уже сегодня. Разверни совет — сколько займёт, что даст и что конкретно делать

1

Раздели факты и решения

выходные на прототип систему проще объяснять, аудировать и чинить

Наблюдаемые условия данных (поле исчезло, сменился тип, вырос null rate) детектируй жёсткими правилами, а обучение оставь только для выбора действия в контексте.

Что делать

  1. 1 Выпиши, что в твоих инцидентах измеримо напрямую — это кандидаты в детерминированные детекторы.
  2. 2 Выпиши, где выбор действия зависит от контекста и истории — это кандидаты на обучаемую политику.
  3. 3 Не смешивай их в одном компоненте: факты отдельно, выбор отдельно.
2

Ограничь набор действий

1 час на дизайн решения становятся инспектируемыми, а не «чёрным ящиком»

Агенту не нужна свобода — нужен короткий список безопасных операционных ответов. В докладе их шесть: повторить, привести схему, откатить, изолировать, эскалировать, залогировать.

Что делать

  1. 1 Составь closed-список действий, каждое из которых операционная команда готова доверить автомату.
  2. 2 Смоделируй инцидент как одношаговое решение с компактным состоянием, а не как долгую задачу управления.
  3. 3 Держи пространство маленьким — тогда хватит tabular Q-learning и каждое значение можно посмотреть глазами.
3

Вынеси guardrails наружу политики

полдня обновление модели не сможет молча переопределить свои полномочия

Слой безопасности должен жить вне обучаемой политики: при критической аномалии он превращает пассивное действие (например, «залогировать») в эскалацию, что бы ни предложила политика.

Что делать

  1. 1 Определи критические условия, при которых автономия недопустима.
  2. 2 Сделай override отдельным компонентом, который получает предложение политики и может его перекрыть.
  3. 3 Запрети политике самой менять правила безопасности при обучении.
4

Сделай эскалацию первоклассным исходом

30 минут на пересмотр метрик перестанешь награждать агента за опасную самоуверенность

Эскалация и пост-валидация — не «ветки исключений», а нормальные исходы. Иначе система будет учиться не звать человека даже там, где должна.

Что делать

  1. 1 Убери «долю эскалаций» из целевой функции как самоцель.
  2. 2 Добавь в метрики отдельно: успешное авто-решение, корректная эскалация, провал валидации.
  3. 3 Награждай честную остановку при нехватке улик или полномочий.
5

Логируй каждое решение в audit-запись

встраивается в код агента инцидент всегда можно разобрать постфактум и доказать корректность

Предложение политики, срабатывание override, результат исполнения и итог валидации должны попадать в неизменяемую запись (в докладе — в S3).

Что делать

  1. 1 Определи схему audit-записи: state → предложение → override → исполнение → валидация.
  2. 2 Пиши её на каждый инцидент, даже когда действие оказалось недоступным.
  3. 3 Храни отдельно артефакты и карантинные выгрузки данных.
6

Начни с shadow mode

спринт проверишь агента на реальных инцидентах без права что-либо ломать

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

Что делать

  1. 1 Собери набор реальных (или близких) трейсов инцидентов.
  2. 2 Пусть агент выдаёт рекомендацию, но не исполняет её.
  3. 3 Сравни с тем, что сделал человек, и только потом расширяй автономию через approval gates.
7

Оценивай на множестве seed-ов

встроить в CI-эксперименты отличишь настоящий результат от везения на одном прогоне

Один удачный запуск — это демо, а не доказательство. Гоняй повторяемые эксперименты и всегда сравнивай с простым baseline (хотя бы random и ручной политикой).

Что делать

  1. 1 Зафиксируй несколько seed-ов и повтори прогоны.
  2. 2 Считай агрегаты с доверительными интервалами (в докладе — 95%).
  3. 3 Сравни с random-выбором и hand-defined политикой, чтобы понять, что реально дало прирост.
8

Измеряй MTTR честно

20 минут не выдашь синтетический выигрыш за продовый

Красивое «−99,85% MTTR» получено сравнением синтетического benchmark-а со смоделированным baseline в 2,5 рабочих дня. Всегда фиксируй, с чем сравниваешь и в каких границах.

Что делать

  1. 1 Замерь текущий ручной baseline восстановления по реальным инцидентам.
  2. 2 Считай выигрыш только на сопоставимых классах сбоев.
  3. 3 В отчёте явно указывай, что часть действий симулирована или ограничена.

Сценарии применения

Как разные люди применяют это на практике

Я как Дата-инженер на дежурстве

Проблема: в третьем часу ночи снова упала загрузка, и полдня уходит на осмотр логов, схемы и upstream-данных

Хочу: чтобы рутинные, узнаваемые сбои чинились сами, а будили меня только по-настоящему сложные случаи

Поможет: статья даёт готовую архитектуру closed-loop восстановления и принцип, как отделить авто-чинимое от требующего человека

Я как SRE

Проблема: инциденты дата-пайплайнов ползут через очередь, расследование и апрувы, MTTR измеряется днями

Хочу: сжать петлю для повторяющихся failure-семейств без риска молча испортить данные

Поможет: видно, как встроить safety override, эскалацию и audit-запись, которым доверит операционная команда

Я как ML-инженер

Проблема: заказчик требует «прикрутить RL», хотя не ясно, добавит ли обучение ценность

Хочу: понять, где обучение реально помогает, а где детерминизм честнее

Поможет: ablation из доклада показывает: на компактном состоянии RL сравнялся с ручной политикой — аргумент не усложнять там, где не нужно

Я как Тимлид дата-платформы

Проблема: команда боится давать агенту право что-то менять в проде

Хочу: постепенно и безопасно передать автономию с контролем

Поможет: план shadow mode → approval gates → versioned policies даёт дорожку к доверию без «большого прыжка»

Я как Разработчик AI-агента

Проблема: агент склонен действовать даже там, где улик недостаточно

Хочу: заставить агента корректно останавливаться на границе своих полномочий

Поможет: паттерн «эскалация как первоклассный исход» и разделение «безопасно» vs «исполнимо» прямо переносятся в дизайн

Я как Платформенный инженер на AWS

Проблема: нужна событийная автоматизация реакции на сбои Glue-задач

Хочу: понять конкретную схему без изобретения велосипеда

Поможет: разобран путь Glue job-failed → EventBridge → Lambda-агент → read-only улики (CloudWatch, Glue Data Catalog) → Glue API → S3

Я как Инженер по данным-качеству

Проблема: проверки полноты, валидности и консистентности разбросаны и непрозрачны

Хочу: формализовать детекцию аномалий с понятной точностью

Поможет: пример метрик детектора (precision 1, recall 0,8, F1 0,889) и мысль, что идеальная precision — не идеальная детекция

Логика повествования

Как устроена аргументация видео — пройди по шагам

Предпосылка Аргумент Пример Вывод
  1. Предпосылка Дорога не поломка, а восстановление вокруг неё

    Ручной baseline инцидента ETL смоделирован примерно в 2,5 рабочих дня: очередь, расследование, апрувы. Цена — в петле, а не в самом сбое.

  2. Аргумент Цель — сжать петлю для рутины, эскалировать сложное

    Автоматизировать узнаваемые, повторяющиеся сбои; неопределённые, новые и высокорисковые случаи отдавать людям.

  3. Аргумент Три раздельные ответственности

    Детерминированные правила — для фактов; Q-learning — для контекстного выбора действия; safety override — для полномочий. Это проектная идея всей системы.

  4. Пример Событийная архитектура на AWS

    Glue job-failed → EventBridge → Lambda-агент собирает read-only улики (логи CloudWatch, схема Glue Data Catalog), классифицирует, оценивает риск, строит компактное состояние.

  5. Аргумент Политика предлагает — безопасность решает

    Из шести действий политика выбирает одно; слой безопасности проверяет его против серьёзности аномалии и может перекрыть на эскалацию. Всё пишется в audit-запись в S3.

  6. Пример Пример: coercion предложен, но недоступен

    Классификатор увидел проблему формата даты с уверенностью 0,9, политика предложила привести схему, override не сработал — но исполнитель не смог применить fix и честно отправил инцидент на ручной разбор.

  7. Вывод Надёжность из структуры, а не из RL

    Self-healing нужны чистое состояние, ограниченные действия, воспроизводимая оценка, наблюдаемые решения и дисциплина остановиться, когда неопределённость превышает полномочия.

Подробный разбор

Полный разбор — разверни, если нужно глубже

Развернуть подробный разбор

Стоит ли смотреть целиком

Да, если ты строишь агентов, которым однажды дадут право что-то менять в проде, или дежуришь по дата-пайплайнам. Доклад короткий (около пятнадцати минут) и необычно честный: автор не продаёт «магию RL», а показывает инженерную дисциплину — где отдать решение обучению, где оставить жёсткие правила и как встроить ограничители, которым доверит операционная команда.

Самая ценная часть — не архитектура на AWS, а ablation и раздел про границы. Именно там автор признаёт, что надёжность дал не RL, а структурированное состояние, простая логика и внешняя безопасность, и что система пока реагирует на синтетике, а не предсказывает сбои в проде. Это редкий пример доклада, где ограничения проговорены так же внятно, как достижения.

Если у тебя нет времени на всё видео, забери пять принципов: детерминизм для измеримых фактов; обучение только там, где контекстный выбор действительно нужен; ограничители — вне обучаемой политики; эскалация и пост-валидация — первоклассные исходы; и оценка на множестве seed-ов против простого baseline, потому что один удачный прогон — это демо, а не доказательство.

План внедрения

С чего начать — отмечай шаги, прогресс сохранится

Выполнено 0 из 7

Проверь себя

Ответь на вопросы, чтобы материал закрепился

Отвечено: 0 / 7 Верно: 0

  1. 1. Что, по мнению автора, стоит дороже всего при сбое ETL?

  2. 2. Что делает safety override, если аномалия критическая, а политика предлагает пассивное действие вроде «залогировать»?

  3. 3. Почему выбрана именно tabular Q-learning, а не сложная модель?

  4. 4. Что показал ablation про вклад RL?

  5. 5. Зачем эскалация включена прямо в пространство действий агента?

  6. 6. Что означает принцип «ML-ready ≠ ML-required»?

  7. 7. Почему автор настаивает на прогонах по множеству seed-ов с доверительными интервалами?

Словарь терминов

Понять незнакомое простым языком

Показать 12 терминов
ETL
Extract-Transform-Load — конвейер, который забирает данные из источников, преобразует их и загружает в хранилище. Основная «водопроводная система» аналитики и отчётности.
RL (обучение с подкреплением)
Подход, где агент учится выбирать действия по итоговым наградам за исходы. Здесь — в упрощённом виде для выбора одного безопасного действия на инцидент.
Tabular Q-learning
Простейший вариант RL: таблица «состояние → ценность каждого действия». Дёшево считать и легко посмотреть, почему выбрано именно это действие.
Remediation
Действие по устранению сбоя: повторить задачу, привести схему, откатить, изолировать данные. В докладе оно всегда ограничено заранее одобренным набором.
Observability (наблюдаемость)
Способность понять, что происходит внутри системы, по логам, метрикам и записям решений. Здесь каждое решение агента фиксируется в audit-запись.
Schema drift (дрейф схемы)
Незаметное изменение структуры данных: появилось/исчезло поле, сменился тип. Частая причина падений ETL, которую ловит детектор дрейфа.
Null rate
Доля пустых значений в поле. Резкий рост — сигнал проблемы с качеством данных, который отслеживают детерминированными правилами.
MTTR
Mean Time To Recovery — среднее время восстановления после сбоя. В докладе сравнивается ручной baseline (2,5 дня) с минутами у агента на benchmark-е.
Safety override / guardrail
Слой ограничений, живущий вне обучаемой политики. Он может перекрыть решение агента — например, эскалировать критическую аномалию.
Shadow mode
Режим, где агент выдаёт рекомендации, но ничего не исполняет; их сравнивают с решениями людей до выдачи реальных полномочий.
Ablation
Эксперимент, где по очереди отключают компоненты, чтобы увидеть вклад каждого. Так автор показала, что надёжность даёт не RL, а структура и ограничители.
Precision / Recall / F1
Метрики детектора: precision — доля верных срабатываний, recall — доля пойманных проблем, F1 — их баланс. Precision 1 не значит, что поймано всё.

Критический взгляд

Объективно: с какими тезисами можно поспорить и что преувеличено

Упрощение

Заголовочные «−99,85% MTTR» и «минуты вместо 2,5 дней» звучат как продовый результат

Это сравнение синтетического benchmark-а со смоделированным ручным baseline, а не с реальным продакшеном. Автор сама это оговаривает, но цифра легко вырывается из контекста и переоценивается.

Преувеличение

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

В ablation обучаемая политика лишь сравнялась с написанной вручную (0 п.п. разницы). Для текущего состояния «RL-агент» — скорее заявка на будущее, чем источник сегодняшнего выигрыша.

Спорно

«Self-healing» может создать ложное ощущение автономии

Система реагирует только после сигнала о сбое и не предсказывает его, часть действий симулирована или намеренно ограничена, success rate ~74,6% — то есть каждый четвёртый случай всё равно идёт к человеку.

Однобоко

Обобщаемость с синтетики на реальные инциденты не доказана

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

Взгляни иначе

Новый угол, смежные области и потенциал на стыке — пища для размышлений

Другой угол

Знать, когда остановиться — метрика зрелости, а не слабости

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

На стыке областей

Паттерн переносится на любой агент с побочными эффектами

Связка «детерминизм для фактов / обучение для выбора / ограничители для полномочий» ложится на медицинские протоколы, автопилот и финансовые операции — всюду, где ошибка автономии дорога.

Смежная область

Разделение «безопасно» и «исполнимо» есть и вне IT

В медицине лечение бывает показано, но недоступно здесь и сейчас; в авиации манёвр допустим, но не в этих условиях. Явное представление обоих условий — универсальный признак зрелой системы принятия решений.

Другой угол

Audit-запись превращает агента в объект комплаенса

Если каждое предложение, override и исход валидации логируются неизменяемо, агент перестаёт быть «чёрным ящиком» и становится аудируемым процессом — это открывает ему регулируемые отрасли.

Похожие разборы

Разбор

Модель предлагает — платформа решает: инфраструктура надёжности для автономных ИИ-агентов

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

Читать → Разбор

Агент со 100 инструментами — это ловушка: почему точность падает и как её вернуть роутингом

Если сваливать в промпт все определения инструментов сразу, агент тонет в контексте: на 741 инструменте точность выбора падает до 13,6%, а промпт раздувается до 127 000 токенов ещё до вопроса пользователя. Лечится это семантическим роутингом — ретривом 3–5 релевантных инструментов под конкретный запрос, который держит точность выше 83% и режет токены на инструменты почти на 99%.

Читать → Разбор

Docling: как превратить PDF, таблицы и картинки в контекст для LLM — локально и дёшево

Большая часть корпоративных данных заперта в PDF, таблицах и сканах, а качество любого RAG или агента решается не в промпте, а на этапе извлечения этих данных. Docling делает это локально, дёшево и детерминированнее, чем прогон документов через дорогие frontier-модели.

Читать → Разбор

Циклы для ИИ-агентов простыми словами: heartbeat, cron, hook и goal в Claude Code и Codex

Цикл — это просто автоматический промпт: вы один раз проектируете агенту «должность», а он сам запускает себя по расписанию или по цели, без ваших рук на клавиатуре. Heartbeat, cron, hook и goal — это знакомые ещё до-ИИ автоматизации, которыми теперь дёргают не скрипт, а умного агента с его собственной армией сабагентов.

Читать →
← Все разборы Смотреть видео-источник