Forwarded from vlad kooklev — ai & agents
мне надоело платить 200$/мес за gpt pro и я построил своего агента для deep research (делюсь с вами кодом)
gpt pro даёт мощную глубину — модель реально копает тему заходами по 30 минут. но ты не контролируешь сам рисёрч: откуда она берёт данные, как фильтрует источники, почему решила что этот сайт достоверный. она постоянно тащит SEO-мусор и AI-слоп, но на это трудно повлиять
стандартная история — это репорты, где он пишет про «самые актуальные модели — sonnet 3.5 и gpt-4o», хотя к тому моменту модели сменились раз 5. в современном мире это непозволительно. я собрал вместо этого свой дип рисерч над claude code
мой пайплайн — 5 шагов:
— декомпозиция темы на ~8 аспектов через разные призмы (who, what, so what, avoid)
— параллельный рисёрч каждого аспекта агентами
— синтез находок
— red team — а что если всё это буллшит? проверка предположений с обратной стороны
— упаковка финальный отчёт
оркестрацией шагов занимается мой фреймворк — claude-pipe. плюс у меня есть мой личный slop-checker skill, который фильтрует источники по критериям.
каждый шаг — отдельный агент со своими инструкциями. не один промпт на всё, а конвейер где каждый этап проверяет предыдущий. одно исследование обходится в ~$1 через exa. значительно шире и глубже, чем gpt pro
выложил на гитхаб, просто дайте ссылку на него своему claude code / openclaw: github.com/bluzir/claude-pipe/tree/master/examples/research-pipeline
настоящий рисёрч — это система которую ты контролируешь. знаешь откуда данные, можешь поменять критерии, перезапустить один кусок не переделывая всё. я убежден, что в 2026 такая должна быть у каждого. с вас звездочки на гитхабе!
gpt pro даёт мощную глубину — модель реально копает тему заходами по 30 минут. но ты не контролируешь сам рисёрч: откуда она берёт данные, как фильтрует источники, почему решила что этот сайт достоверный. она постоянно тащит SEO-мусор и AI-слоп, но на это трудно повлиять
стандартная история — это репорты, где он пишет про «самые актуальные модели — sonnet 3.5 и gpt-4o», хотя к тому моменту модели сменились раз 5. в современном мире это непозволительно. я собрал вместо этого свой дип рисерч над claude code
мой пайплайн — 5 шагов:
— декомпозиция темы на ~8 аспектов через разные призмы (who, what, so what, avoid)
— параллельный рисёрч каждого аспекта агентами
— синтез находок
— red team — а что если всё это буллшит? проверка предположений с обратной стороны
— упаковка финальный отчёт
оркестрацией шагов занимается мой фреймворк — claude-pipe. плюс у меня есть мой личный slop-checker skill, который фильтрует источники по критериям.
каждый шаг — отдельный агент со своими инструкциями. не один промпт на всё, а конвейер где каждый этап проверяет предыдущий. одно исследование обходится в ~$1 через exa. значительно шире и глубже, чем gpt pro
выложил на гитхаб, просто дайте ссылку на него своему claude code / openclaw: github.com/bluzir/claude-pipe/tree/master/examples/research-pipeline
настоящий рисёрч — это система которую ты контролируешь. знаешь откуда данные, можешь поменять критерии, перезапустить один кусок не переделывая всё. я убежден, что в 2026 такая должна быть у каждого. с вас звездочки на гитхабе!
GitHub
claude-pipe/examples/research-pipeline at master · bluzir/claude-pipe
File-First Agent Orchestration. Readable agents. Inspectable state. Predictable costs. - bluzir/claude-pipe
Forwarded from Data Blog
Люблю сталкиваться с моментами, где понимаю, что мне не хватает знаний. То есть не упорства, сил, времени, плана, мотивации или чего-либо ещё, а именно знаний. И сейчас меня так прокинуло в TDA (Topological Data Analysis).
Почему TDA возникает в контексте интерпретируемости?
В задаче анализа моделей как сущности есть две глобальные ветки. Первая ветвь рассматривает модель узко – в контексте конкретной задачи, а вторая – смотрит на модель более абстрактно, как на самостоятельный объект.
Приземляя на примеры:
1. Прогнозирование диагноза. Исследуем случаи решений методами интерпретации, получаем ответ "почему модель дала решение X". Отвечаем на вопросы — какая область данных повлияла на решение.
2. Исследование гендерных/рассовых предубеждений. Смотрим, как модель внутри себя располагает рассы/гендеры и думаем, как свести их в точку, где ни расса, ни гендер не влияет на принятие решения (если оно от них не зависит). Здесь важно то, что ни гендер, ни расса не описаны явно в начальных признаках, иначе было бы достаточно первого подхода.
И вот для абстрактного случая очень важны геометрические методы. Любая модель — это коробка с геометрическими структурами. Сейчас, мы находим их очень точечно — например, линейная разделимость тех же гендеров или harm/safe предубеждений (как мы показывали в статье) или circuits, про которые я так и не написала, но хороший материал тут.
Именно топологический анализ данных в частности тут может быть интересно применен. Для вдохновения:
1. Изучение bias относительно пола и профессии https://arxiv.org/pdf/2508.07516
2. Изучение признаков, идентифицированных моделью (пример на CNN) https://arxiv.org/pdf/2305.08642
3. Сокращение модели на основе изученных топологических структур https://arxiv.org/pdf/2410.11042v1
4. TDA на ризонинге https://arxiv.org/html/2510.20665v1
И к чему это я — нашла очень классный ноутбук для относительно легкого знакомства с TDA на питоне: https://colab.research.google.com/github/shizuo-kaji/TutorialTopologicalDataAnalysis/blob/master/TopologicalDataAnalysisWithPython.ipynb
Прям с нуля можно хорошо покопаться. За праздники надеюсь переведу его и обвешу определениями, но оригинал прям не могла вам не прислать.
Почему TDA возникает в контексте интерпретируемости?
В задаче анализа моделей как сущности есть две глобальные ветки. Первая ветвь рассматривает модель узко – в контексте конкретной задачи, а вторая – смотрит на модель более абстрактно, как на самостоятельный объект.
Приземляя на примеры:
1. Прогнозирование диагноза. Исследуем случаи решений методами интерпретации, получаем ответ "почему модель дала решение X". Отвечаем на вопросы — какая область данных повлияла на решение.
2. Исследование гендерных/рассовых предубеждений. Смотрим, как модель внутри себя располагает рассы/гендеры и думаем, как свести их в точку, где ни расса, ни гендер не влияет на принятие решения (если оно от них не зависит). Здесь важно то, что ни гендер, ни расса не описаны явно в начальных признаках, иначе было бы достаточно первого подхода.
И вот для абстрактного случая очень важны геометрические методы. Любая модель — это коробка с геометрическими структурами. Сейчас, мы находим их очень точечно — например, линейная разделимость тех же гендеров или harm/safe предубеждений (как мы показывали в статье) или circuits, про которые я так и не написала, но хороший материал тут.
Именно топологический анализ данных в частности тут может быть интересно применен. Для вдохновения:
1. Изучение bias относительно пола и профессии https://arxiv.org/pdf/2508.07516
2. Изучение признаков, идентифицированных моделью (пример на CNN) https://arxiv.org/pdf/2305.08642
3. Сокращение модели на основе изученных топологических структур https://arxiv.org/pdf/2410.11042v1
4. TDA на ризонинге https://arxiv.org/html/2510.20665v1
И к чему это я — нашла очень классный ноутбук для относительно легкого знакомства с TDA на питоне: https://colab.research.google.com/github/shizuo-kaji/TutorialTopologicalDataAnalysis/blob/master/TopologicalDataAnalysisWithPython.ipynb
Прям с нуля можно хорошо покопаться. За праздники надеюсь переведу его и обвешу определениями, но оригинал прям не могла вам не прислать.
Forwarded from Data Blog
Одна ошибка и ты ошибся (с)
Народные мудрецы
Как мне кажется, одной из ярких и важных технологий в механистической интерпретируемости в этом году стали SAE — Sparse AutoEncoders. Помимо того, что я сейчас с ними плотно работаю, мы как-то летом обсуждали SAE в подкасте AI Security Lab «Интерпретируемости моделей ИИ: как, зачем и насколько это реально?»
Методологически SAE всегда помогают нам найти атомарные признаки, устраняя полисемантичность — явление, когда один нейрон кодирует много признаков. И этот эффект происходит за счет создания разреженного базиса. Но это — энкодер + разреженная проекция — только лицевая часть SAE. Есть ещё и менее лицевая — если хотите, задняя, часть — декодер. 🍑
Декодер возвращает реконструкцию примера, максимально близкую к исходному эмбеддингу. Близкую, но никогда не ту же самую. Отсюда имеем факт: SAE обладает ошибкой реконструкции.
Но что такое ошибка?
Ошибка в любой прогностической задаче должна быть хорошей — это часть данных, которую мы не можем предсказать. Так, для линейной регрессии мы требуем нормальности ошибок, а для ARIMA моделей для временных рядов — нормальность и стационарность остатков (ошибок) — «зеленый флаг» обучения модели.
А что такое ошибка в SAE?
Исследовать ошибку как самостоятельный объект додумались раньше меня, так что, к счастью, мой вопрос не остался без ответа. Рассмотреть ошибку реконструкции как объект исследования предлагает работа “Decomposing The Dark Matter of Sparse Autoencoders”. Результаты работы просто невероятно красивы:
1. Существует линейное преобразование уменьшающее ошибку реконструкции — следовательно существует линейная часть разложения, которую SAE не могут изучить.
2. Существует постоянная нелинейная часть, являющаяся частью ошибки SAE реконструкции.
То есть, с такой стороны — ошибка SAE — это структурный объект, который можно декомпозировать на линейно предсказуемую и нелинейную части, с разным влиянием на поведение модели. И хотя SAE эмпирически эффективны, влияние ошибок и их природу не стоит опускать из анализа.
Ещё одна интересная работа на эту тему — пост на AI Alignment forum “SAE reconstruction errors are (empirically) pathological”. В этом блог-посте анализируется структура ответа модели при условии SAE ошибки. То есть, анализируется вопрос — что будет, если вместо x поставить x’ с ошибкой реконструкции против x’’ — со случайно ошибкой.
Результат измеряют при помощи KL-дивергенции — интуитивно отвечающей на вопрос насколько далеки распределения друг от друга (то есть 0 тут — наш идеал). Показано, что при одной и той же норме возмущения SAE-ошибка влечёт больший KL / рост loss, чем случайный шум.
При этом, если мы просто уменьшим ошибку — успех не придет. Во-первых, SAE может не улавливать ещё более атомарные концепции (можно поиграть с Meta Feature Explorer, делающий ровно это тут, по мотивам работы Sparse Autoencoders Do Not Find Canonical Units of Analysis ). Кроме того, успех реконструкции по MSE — не значит, что мы нашли важные признаки с точки зрения производительности модели (это исследуют тут) .
И вот смотрю я на всё это, кручу свои SAE признаки в дипломном проекте и чувствую, что впереди ещё безумного много интересного.
Ну и ещё один важный тейк поста — всегда важно оценивать заднюю часть и любые другие детали за спиной main контента метода.
Народные мудрецы
Как мне кажется, одной из ярких и важных технологий в механистической интерпретируемости в этом году стали SAE — Sparse AutoEncoders. Помимо того, что я сейчас с ними плотно работаю, мы как-то летом обсуждали SAE в подкасте AI Security Lab «Интерпретируемости моделей ИИ: как, зачем и насколько это реально?»
Методологически SAE всегда помогают нам найти атомарные признаки, устраняя полисемантичность — явление, когда один нейрон кодирует много признаков. И этот эффект происходит за счет создания разреженного базиса. Но это — энкодер + разреженная проекция — только лицевая часть SAE. Есть ещё и менее лицевая — если хотите, задняя, часть — декодер. 🍑
Декодер возвращает реконструкцию примера, максимально близкую к исходному эмбеддингу. Близкую, но никогда не ту же самую. Отсюда имеем факт: SAE обладает ошибкой реконструкции.
Но что такое ошибка?
Ошибка в любой прогностической задаче должна быть хорошей — это часть данных, которую мы не можем предсказать. Так, для линейной регрессии мы требуем нормальности ошибок, а для ARIMA моделей для временных рядов — нормальность и стационарность остатков (ошибок) — «зеленый флаг» обучения модели.
А что такое ошибка в SAE?
Исследовать ошибку как самостоятельный объект додумались раньше меня, так что, к счастью, мой вопрос не остался без ответа. Рассмотреть ошибку реконструкции как объект исследования предлагает работа “Decomposing The Dark Matter of Sparse Autoencoders”. Результаты работы просто невероятно красивы:
1. Существует линейное преобразование уменьшающее ошибку реконструкции — следовательно существует линейная часть разложения, которую SAE не могут изучить.
2. Существует постоянная нелинейная часть, являющаяся частью ошибки SAE реконструкции.
То есть, с такой стороны — ошибка SAE — это структурный объект, который можно декомпозировать на линейно предсказуемую и нелинейную части, с разным влиянием на поведение модели. И хотя SAE эмпирически эффективны, влияние ошибок и их природу не стоит опускать из анализа.
Ещё одна интересная работа на эту тему — пост на AI Alignment forum “SAE reconstruction errors are (empirically) pathological”. В этом блог-посте анализируется структура ответа модели при условии SAE ошибки. То есть, анализируется вопрос — что будет, если вместо x поставить x’ с ошибкой реконструкции против x’’ — со случайно ошибкой.
Результат измеряют при помощи KL-дивергенции — интуитивно отвечающей на вопрос насколько далеки распределения друг от друга (то есть 0 тут — наш идеал). Показано, что при одной и той же норме возмущения SAE-ошибка влечёт больший KL / рост loss, чем случайный шум.
При этом, если мы просто уменьшим ошибку — успех не придет. Во-первых, SAE может не улавливать ещё более атомарные концепции (можно поиграть с Meta Feature Explorer, делающий ровно это тут, по мотивам работы Sparse Autoencoders Do Not Find Canonical Units of Analysis ). Кроме того, успех реконструкции по MSE — не значит, что мы нашли важные признаки с точки зрения производительности модели (это исследуют тут) .
И вот смотрю я на всё это, кручу свои SAE признаки в дипломном проекте и чувствую, что впереди ещё безумного много интересного.
Ну и ещё один важный тейк поста — всегда важно оценивать заднюю часть и любые другие детали за спиной main контента метода.
Forwarded from Data Blog
Привет, друзья!
За последний год я писала про SAE 11 раз. А ещё взяла с ними дипломную.
SAE-шки — очень практичный и интересный метод. Они позволяют разложить внутренние представления трансформера на разреженные признаки, на которые мы можем посмотреть и которыми мы можем управлять.
А ещё мой последний туториал был 4 месяца назад. Так что звезды сложились — и я снова дошла до Хабра со статьей и ноутбуком!
В туториале:
— что такое SAE и зачем вообще «раздувать» скрытое пространство;
— где именно в трансформере обучают SAE (residual stream, attention, MLP);
— как читать признаки через Neuronpedia;
— как извлекать и анализировать активации признаков;
— как запускать модель с SAE внутри и смотреть, что ж активируется по слоям.
Этот материал лежал в заметках. И когда я его писала — очень хорошо уложила себе базу. Надеюсь, для вас это тоже сработает!
Чудесного начала недели!
Ваш Дата-автор!❤️
За последний год я писала про SAE 11 раз. А ещё взяла с ними дипломную.
SAE-шки — очень практичный и интересный метод. Они позволяют разложить внутренние представления трансформера на разреженные признаки, на которые мы можем посмотреть и которыми мы можем управлять.
А ещё мой последний туториал был 4 месяца назад. Так что звезды сложились — и я снова дошла до Хабра со статьей и ноутбуком!
В туториале:
— что такое SAE и зачем вообще «раздувать» скрытое пространство;
— где именно в трансформере обучают SAE (residual stream, attention, MLP);
— как читать признаки через Neuronpedia;
— как извлекать и анализировать активации признаков;
— как запускать модель с SAE внутри и смотреть, что ж активируется по слоям.
Этот материал лежал в заметках. И когда я его писала — очень хорошо уложила себе базу. Надеюсь, для вас это тоже сработает!
Чудесного начала недели!
Ваш Дата-автор!
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
SAE: введение, пояснение и код
Привет, друзья! В прошлой статье мы разобрали идею применения автоэнкодеров к трансоформерам. Там весь наш pipeline проходил на идее сжатия признакового пространства так, чтобы поделить кошек и собак....
Forwarded from IT путь
Подготовка к собеседованию на DE
Секция SQL. Теория.
Вопрос: TRUNCATE vs DELETE (разобрал для MSSQL, MYSQL, PostreSQL, ORACLE)
Тип БД:
Первое, что стоит учесть — TRUNCATE и DELETE это команды реляционной модели. В NoSQL и колоночных БД свои механизмы удаления, поэтому там это сравнение неприменимо =)
Тип модели хранилища:
В системах типа DWH, Data Lake, OLAP это сравнение тож не актуально. В DWH данные грузятся батчами, точечный DELETE — редкая и тяжелая хрень. Чаще нужна полная перезагрузка партиции или витрины через TRUNCATE/DROP PARTITION. Короче DELETE в OLAP — это лишнее.
А вот OLTP — это уже та среда, для которой этот вопрос предназначен, тк выбор между командами критичен и зависит от цели.
🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤
🔤 🔤
🩸 🩸 🩸 🩸 🩸 🩸
1️⃣ Транзакционность
DELETE относится к DML и полностью транзакционен во всех СУБД: поддерживает ROLLBACK, участвует в MVCC (1️⃣ ), генерирует UNDO/WAL(2️⃣ ).
TRUNCATE - это DDL: В PostgreSQL и MSSQL он транзакционен и откатывается, а в MySQL и Oracle — выполняет авто-commit и отката нет.
2️⃣ Механизм удаления
DELETE работает построчно, логирует каждое изменение и обновляет индексы — сложность O(N) (3️⃣ ).
TRUNCATE деаллоцирует(4️⃣ ) страницы целиком и пишет в лог только факт операции — O(1) (5️⃣ ).
3️⃣ WHERE и партиционирование
DELETE поддерживает WHERE везде.
TRUNCATE работает без условий, только с таблицей целиком или партицией. TRUNCATE PARTITION есть в Oracle, MySQL и PostgreSQL. В MSSQL используют partition switching (6️⃣ ).
4️⃣ Триггеры
DELETE активирует row-level триггеры (7️⃣ ) во всех СУБД.
TRUNCATE триггеры не вызывает — кроме PostgreSQL, где TRUNCATE-триггеры поддерживаются явно.
5️⃣ Внешние ключи
DELETE проверяет ссылочную целостность построчно везде.
TRUNCATE не выполнится, если на таблицу ссылается FK. Исключение — Oracle начиная с 12c, где появился CASCADE.
6️⃣ Блокировки
DELETE накладывает row-level locks (8️⃣ ), что при большом объёме может порождать долгие blocking chains.
TRUNCATE берёт table-level exclusive lock (9️⃣ ) — в PostgreSQL это AccessExclusiveLock, блокирующий даже SELECT. Но выполняется мгновенно.
7️⃣ WAL(2️⃣ ) и репликация
DELETE генерирует полный объём WAL-записей, нагружает standby(🔟 ) и архивные логи.
TRUNCATE пишет в лог минимум. В MSSQL операция считается minimally logged даже в Full Recovery Model(1️⃣ 1️⃣ ).
8️⃣ Инкрементальные счётчики
DELETE счётчик не сбрасывает.
TRUNCATE: MySQL сбрасывает AUTO_INCREMENT в 1, MSSQL сбрасывает IDENTITY в seed-значение(1️⃣ 2️⃣ ), PostgreSQL сбрасывает sequence только при явном указании RESTART IDENTITY. В Oracle SEQUENCE — отдельный объект, TRUNCATE его не трогает (только ALTER SEQUENCE вручную).
9️⃣ High Water Mark (Oracle) (1️⃣ 3️⃣ )
DELETE не снижает HWM — full scan продолжает читать весь ранее занятый сегмент даже после удаления данных.
TRUNCATE сбрасывает HWM. Есть два режима: DROP STORAGE возвращает экстенты(1️⃣ 4️⃣ ) обратно в tablespace, REUSE STORAGE оставляет структуру, но сбрасывает метку. В PostgreSQL используется аналог — VACUUM, в MSSQL — rebuild операции, но термин HWM там не используется.
Секция SQL. Теория.
Вопрос: TRUNCATE vs DELETE (разобрал для MSSQL, MYSQL, PostreSQL, ORACLE)
Тип БД:
Первое, что стоит учесть — TRUNCATE и DELETE это команды реляционной модели. В NoSQL и колоночных БД свои механизмы удаления, поэтому там это сравнение неприменимо =)
Тип модели хранилища:
В системах типа DWH, Data Lake, OLAP это сравнение тож не актуально. В DWH данные грузятся батчами, точечный DELETE — редкая и тяжелая хрень. Чаще нужна полная перезагрузка партиции или витрины через TRUNCATE/DROP PARTITION. Короче DELETE в OLAP — это лишнее.
А вот OLTP — это уже та среда, для которой этот вопрос предназначен, тк выбор между командами критичен и зависит от цели.
в тексте есть сноски (*N). Пояснение комменте
DELETE относится к DML и полностью транзакционен во всех СУБД: поддерживает ROLLBACK, участвует в MVCC (
TRUNCATE - это DDL: В PostgreSQL и MSSQL он транзакционен и откатывается, а в MySQL и Oracle — выполняет авто-commit и отката нет.
DELETE работает построчно, логирует каждое изменение и обновляет индексы — сложность O(N) (
TRUNCATE деаллоцирует(
DELETE поддерживает WHERE везде.
TRUNCATE работает без условий, только с таблицей целиком или партицией. TRUNCATE PARTITION есть в Oracle, MySQL и PostgreSQL. В MSSQL используют partition switching (
DELETE активирует row-level триггеры (
TRUNCATE триггеры не вызывает — кроме PostgreSQL, где TRUNCATE-триггеры поддерживаются явно.
DELETE проверяет ссылочную целостность построчно везде.
TRUNCATE не выполнится, если на таблицу ссылается FK. Исключение — Oracle начиная с 12c, где появился CASCADE.
DELETE накладывает row-level locks (
TRUNCATE берёт table-level exclusive lock (
DELETE генерирует полный объём WAL-записей, нагружает standby(
TRUNCATE пишет в лог минимум. В MSSQL операция считается minimally logged даже в Full Recovery Model(
DELETE счётчик не сбрасывает.
TRUNCATE: MySQL сбрасывает AUTO_INCREMENT в 1, MSSQL сбрасывает IDENTITY в seed-значение(
DELETE не снижает HWM — full scan продолжает читать весь ранее занятый сегмент даже после удаления данных.
TRUNCATE сбрасывает HWM. Есть два режима: DROP STORAGE возвращает экстенты(
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Всеволод Викулин | AI разбор
AI-агент рекрутер. Кейс компании LinkedIn
Рекрутер создает описание вакансии, агент уточняет детали, запускает поиск по базе из миллионов кандидатов, показывает только самых подходящих. Это не автоматизация, это другой подход к поиску кандидатов. Кому, как не LinkedIn, пришло в голову воплотить эту идею. Мы разберем устройство этого агента и найдем причины успеха продукта. Может, они не из-за AI-агента? Но давайте по порядку.
Архитектура
Агент построен на классической архитектуре Plan-And-Execute. Это простой, наглядный и итеративный процесс.
1) Главный субагент получает задачу от рекрутера. Смотрит на историю сообщений. Пытается понять, что рекрутер хочет сделать, насколько он явно выразил мысль, достаточно ли информации. Все рассуждения преобразует в план.
2) План превращается в список конкретных задач для будущих исполнителей. На этом этапе важно дать исполнителю ровно ту информацию, которая ему нужна для решения задачи, но не больше. Все как с людьми: важно все объяснить, но не перегрузить лишними деталями. Это называется изоляция контекста — основной паттерн проектирования агентских систем сейчас.
3) Задачи отправляются субагентам-исполнителям. Их великое множество. Ровно столько, сколько есть разных задач в рекрутменте:
— один собирает у рекрутера дополнительную информацию;
— второй формулирует множество запросов в поиск;
— третий оценивает, насколько кандидат подходит.
...
У каждого субагента есть только свой список тулов, которыми он может пользоваться. Это тоже изоляция, не надо давать кому угодно пользоваться чем угодно. Сломает или потеряет.
4) После того как все субагенты отработали, главный проверяет их результаты. Если цель не выполнена, переформулирует план, отправляет новые задачи. Может спросить совета у рекрутера, если есть вопросы (паттерн human-in-the-loop).
Что здесь на самом деле сложно
Вот такую архитектуру мы с вами можем собрать за 3 часа на n8n и ему подобных. HR-тех мы так не перевернем. Главный актив, над которым команда инженеров LinkedIn работала 99,9% времени — структурированные знания, которыми агент может пользоваться.
Это описания кандидатов, вакансий и успешных историй поиска, где нашли и наняли сотрудника. Это огромный массив данных, который где-то хранится, быстро обновляется и по которому могут быстро искать агенты и люди.
Хранить его просто в текстовом индексе крайне неэффективно. Сейчас все важнее становятся графовые базы данных, вроде neo4j, которые позволяют хранить разные зависимости между объектами. Например, в каких компаниях и в каких вузах учились наши лучшие сотрудники.
У самого LinkedIn есть известная база Economic Graph, в которой лежат структурированные данные по рынку труда, и он может ее легко применять в своих агентах.
Резюме
Да, вам нужно выучить паттерны создания надежных AI-продуктов (читая мой канал, конечно же). Иначе все точно развалится. Но правильная архитектура одного агента не сделает чуда.
Вам нужно оцифровать данные на пути, на котором создается ценность для пользователя. Потом сделать инструменты, чтобы агент мог этими данными пользоваться. Тогда агент сможет сам создавать ценность. Автономно, спрашивая вас только тогда, когда что-то непонятно. Тогда агенты действительно будут полезны бизнесу.
Без этого обычно все заканчивается презентацией прототипа. С очень хорошей архитектурой Plan-And-Execute. Но прототипа.
Рекрутер создает описание вакансии, агент уточняет детали, запускает поиск по базе из миллионов кандидатов, показывает только самых подходящих. Это не автоматизация, это другой подход к поиску кандидатов. Кому, как не LinkedIn, пришло в голову воплотить эту идею. Мы разберем устройство этого агента и найдем причины успеха продукта. Может, они не из-за AI-агента? Но давайте по порядку.
Архитектура
Агент построен на классической архитектуре Plan-And-Execute. Это простой, наглядный и итеративный процесс.
1) Главный субагент получает задачу от рекрутера. Смотрит на историю сообщений. Пытается понять, что рекрутер хочет сделать, насколько он явно выразил мысль, достаточно ли информации. Все рассуждения преобразует в план.
2) План превращается в список конкретных задач для будущих исполнителей. На этом этапе важно дать исполнителю ровно ту информацию, которая ему нужна для решения задачи, но не больше. Все как с людьми: важно все объяснить, но не перегрузить лишними деталями. Это называется изоляция контекста — основной паттерн проектирования агентских систем сейчас.
3) Задачи отправляются субагентам-исполнителям. Их великое множество. Ровно столько, сколько есть разных задач в рекрутменте:
— один собирает у рекрутера дополнительную информацию;
— второй формулирует множество запросов в поиск;
— третий оценивает, насколько кандидат подходит.
...
У каждого субагента есть только свой список тулов, которыми он может пользоваться. Это тоже изоляция, не надо давать кому угодно пользоваться чем угодно. Сломает или потеряет.
4) После того как все субагенты отработали, главный проверяет их результаты. Если цель не выполнена, переформулирует план, отправляет новые задачи. Может спросить совета у рекрутера, если есть вопросы (паттерн human-in-the-loop).
Что здесь на самом деле сложно
Вот такую архитектуру мы с вами можем собрать за 3 часа на n8n и ему подобных. HR-тех мы так не перевернем. Главный актив, над которым команда инженеров LinkedIn работала 99,9% времени — структурированные знания, которыми агент может пользоваться.
Это описания кандидатов, вакансий и успешных историй поиска, где нашли и наняли сотрудника. Это огромный массив данных, который где-то хранится, быстро обновляется и по которому могут быстро искать агенты и люди.
Хранить его просто в текстовом индексе крайне неэффективно. Сейчас все важнее становятся графовые базы данных, вроде neo4j, которые позволяют хранить разные зависимости между объектами. Например, в каких компаниях и в каких вузах учились наши лучшие сотрудники.
У самого LinkedIn есть известная база Economic Graph, в которой лежат структурированные данные по рынку труда, и он может ее легко применять в своих агентах.
Резюме
Да, вам нужно выучить паттерны создания надежных AI-продуктов (читая мой канал, конечно же). Иначе все точно развалится. Но правильная архитектура одного агента не сделает чуда.
Вам нужно оцифровать данные на пути, на котором создается ценность для пользователя. Потом сделать инструменты, чтобы агент мог этими данными пользоваться. Тогда агент сможет сам создавать ценность. Автономно, спрашивая вас только тогда, когда что-то непонятно. Тогда агенты действительно будут полезны бизнесу.
Без этого обычно все заканчивается презентацией прототипа. С очень хорошей архитектурой Plan-And-Execute. Но прототипа.
Linkedin
How we engineered LinkedIn’s Hiring Assistant
Forwarded from Всеволод Викулин | AI разбор
Испечь AI-агента и не сжечь продакшн. Разбор ингредиентов
При масштабировании агентов не стоит придумывать с нуля архитектуру для каждой новой задачи. Разработка агентов — новейшая область, у вас огромный риск, что эксперимент провалится. Процесс должен быть похож на выпечку торта по бабушкиному рецепту: мука, яйца, шоколад, а лучше побольше шоколада...
Сегодня мы разберем эти ингредиенты и способы их замеса в шикарный, предсказуемый агентский торт (весь пост удачно проиллюстрирован картинкой).
Из каких компонентов состоят агенты
5 кубиков агентской системы:
1) Оркестратор. Сердце (душа?) агента
Это runtime-движок, который управляет бесконечным циклом работы агента. Оркестратор запускает все компоненты с нужными аргументами, обрабатывает их выходные данные и ошибки, если они случились. Он работает по определенному шаблону, вроде ReAct (подумай, потом сделай), Plan-Execute (составь план и иди строго по нему) и т. д. Физически это Python-код, реализованный, например, на базе LangGraph/LangChain. Но можно написать это и с нуля.
2) LLM. Мозг агента
Оркестратор собирает промпт и отправляет его в LLM, чтобы «мозг» решил, что делать дальше. Можно использовать разные модели под разные задачи: дорогие — для редких и сложных, модели попроще — для массовых операций. Физически это либо API к облачному провайдеру, либо API к LLM на ваших серверах.
3) Инструменты. Руки агента
Любые программы, которые агент может вызывать для решения задачи. Удобно использовать какой-то протокол, например, MCP. Инструментом может быть и другой агент, тогда получится мультиагентная система.
4) Контекстное окно. Память агента
Управление контекстным окном — одна из сложнейших задач. Нужно, чтобы в каждый момент запуска LLM в контексте была ровно та информация, которая необходима для решения текущей проблемы. Чем больше мусора в контексте, тем выше шанс, что «мозг» сломается. Физически это реализуется через различные методы работы с памятью: сжатие, вытеснение старых данных во внешнюю память и т. д.
5) Внешняя информация. Знания агента
Здесь лежат данные, которые не нужны в контексте прямо сейчас, но могут потребоваться позже. Физически это базы знаний или файлы. Доступ к ним происходит через RAG или инструменты поиска (вроде командной строки grep).
Как компоненты взаимодействуют
Всё взаимодействие идет через оркестратор. Но чтобы агент был прозрачным и безопасным, мы делаем это не напрямую, а через специальные прокси-сервисы — Gateways (шлюзы). У них две цели:
- Аналитика. Нужно логировать всё, что запустил оркестратор, чтобы потом собирать метрики и строить дашборды. Подробнее мы обсуждали это в прошлом посте про observability.
- Безопасность. Каждое действие оркестратора должно проходить проверку. Это контроль доступов к файлам, анализ контекста на prompt injection, проверка безопасности инструментов, шифрование персональных данных и т. д.
Заключение
Следуя этому рецепту, вы сможете не просто выпекать более надежных агентов, но и делать это каждый раз все качественнее и быстрее.
Улучшение любого компонента автоматически улучшает всех агентов компании. А каждый новый инструмент может быть переиспользован в будущих проектах.
Это та самая рецептура масштабного внедрения AI в компании, которую я каждому желаю освоить. Не все же нам дошираки заваривать?
При масштабировании агентов не стоит придумывать с нуля архитектуру для каждой новой задачи. Разработка агентов — новейшая область, у вас огромный риск, что эксперимент провалится. Процесс должен быть похож на выпечку торта по бабушкиному рецепту: мука, яйца, шоколад, а лучше побольше шоколада...
Сегодня мы разберем эти ингредиенты и способы их замеса в шикарный, предсказуемый агентский торт (весь пост удачно проиллюстрирован картинкой).
Из каких компонентов состоят агенты
5 кубиков агентской системы:
1) Оркестратор. Сердце (душа?) агента
Это runtime-движок, который управляет бесконечным циклом работы агента. Оркестратор запускает все компоненты с нужными аргументами, обрабатывает их выходные данные и ошибки, если они случились. Он работает по определенному шаблону, вроде ReAct (подумай, потом сделай), Plan-Execute (составь план и иди строго по нему) и т. д. Физически это Python-код, реализованный, например, на базе LangGraph/LangChain. Но можно написать это и с нуля.
2) LLM. Мозг агента
Оркестратор собирает промпт и отправляет его в LLM, чтобы «мозг» решил, что делать дальше. Можно использовать разные модели под разные задачи: дорогие — для редких и сложных, модели попроще — для массовых операций. Физически это либо API к облачному провайдеру, либо API к LLM на ваших серверах.
3) Инструменты. Руки агента
Любые программы, которые агент может вызывать для решения задачи. Удобно использовать какой-то протокол, например, MCP. Инструментом может быть и другой агент, тогда получится мультиагентная система.
4) Контекстное окно. Память агента
Управление контекстным окном — одна из сложнейших задач. Нужно, чтобы в каждый момент запуска LLM в контексте была ровно та информация, которая необходима для решения текущей проблемы. Чем больше мусора в контексте, тем выше шанс, что «мозг» сломается. Физически это реализуется через различные методы работы с памятью: сжатие, вытеснение старых данных во внешнюю память и т. д.
5) Внешняя информация. Знания агента
Здесь лежат данные, которые не нужны в контексте прямо сейчас, но могут потребоваться позже. Физически это базы знаний или файлы. Доступ к ним происходит через RAG или инструменты поиска (вроде командной строки grep).
Как компоненты взаимодействуют
Всё взаимодействие идет через оркестратор. Но чтобы агент был прозрачным и безопасным, мы делаем это не напрямую, а через специальные прокси-сервисы — Gateways (шлюзы). У них две цели:
- Аналитика. Нужно логировать всё, что запустил оркестратор, чтобы потом собирать метрики и строить дашборды. Подробнее мы обсуждали это в прошлом посте про observability.
- Безопасность. Каждое действие оркестратора должно проходить проверку. Это контроль доступов к файлам, анализ контекста на prompt injection, проверка безопасности инструментов, шифрование персональных данных и т. д.
Заключение
Следуя этому рецепту, вы сможете не просто выпекать более надежных агентов, но и делать это каждый раз все качественнее и быстрее.
Улучшение любого компонента автоматически улучшает всех агентов компании. А каждый новый инструмент может быть переиспользован в будущих проектах.
Это та самая рецептура масштабного внедрения AI в компании, которую я каждому желаю освоить. Не все же нам дошираки заваривать?
Forwarded from Всеволод Викулин | AI разбор
Оркестратор AI-агента. 5 типов и инструкция по их применению.
В прошлом посте мы разобрали, из каких ингредиентов состоят агенты. Сегодня поговорим про оркестратор, который управляет процессом решения задачи и связывает все компоненты воедино.
От выбора оркестратора зависит, будет ли агент вашим надежным другом или галлюцинирующим кошмаром. Мы разберем 5 базовых типов (см. 5 картинок), которые нужно применять к разным задачам.
1. LLM-Workflow (Детерминированное исполнение)
Самый надежный и распространенный вариант в продакшене. Порядок действий жестко задан разработчиком в коде. LLM здесь используется как функция внутри жесткого графа: например, суммаризует ответ, извлекает сущности или классифицирует тексты.
Плюсы: надежно, предсказуемо, дешево.
Минусы: нужно этот граф написать руками. Для творческих процессов не подходит совсем.
Когда использовать: для процессов с высокими рисками и понятным регламентом. Например, умный документооборот, ответы на вопросы клиентов.
2. ReAct (Рассуждение и выбор действия)
Базовый вариант автономного агента. Процесс заранее не зафиксирован. Модель работает в цикле: "Подумал → Выбрал инструмент → Получил результат". Здесь уже сама LLM решает, какой инструмент вызвать и когда остановиться.
Плюсы: гибкость. Может выбирать разные действия под ситуацию.
Минусы: часто ломается в долгих задачах (застревает в цикле или забывает цель).
Когда использовать: для простых коротких задач с небольшим числом инструментов (например, «найди курс валюты и отправь в Slack»).
3. Reflexion (Рефлексия)
Умная надстройка над ReAct. В цикл добавляется этап "Рефлексии". Агент получает результат от инструмента, но не бежит дальше, а оценивает: "А то ли я сделал?". Если нет — пересматривает ответ. И так может делать несколько раз для одного действия. Мой любимый паттерн, я тоже мнительный :)
Плюсы: критически поднимает качество в задачах, где результат можно валидировать (код, математика).
Минусы: мнительность ест много токенов и замедляет работу.
Когда использовать: когда фидбек инструмента максимально полезен. Например, программирование, где фидбек — ошибка выполнения программы.
4. Plan-and-Execute (Планирование и исполнение)
Сначала LLM составляет план, затем шаг за шагом другой оркестратор (например, Reflexion) этот план исполняет. Всё работает в едином контекстном окне. Как только план выполнен, LLM проверяет: задача решена или нужно составить новый план?
Плюсы: рабочий вариант решения долгих задач без LLM-Workflow.
Минусы: страдает от "распухания" контекста. В истории накапливается столько мусора, что модель ломается.
Когда использовать: для длинных цепочек действий, где шаги жестко зависят друг от друга (любая последовательная аналитика).
5. Plan-and-Execute + Мультиагентность
План создается как в прошлом пункте, но каждую задачу изолированно решает отдельный оркестратор (субагент). У каждого субагента — своя узкая задача и только необходимая для неё информация, они не делятся контекстом.
Плюсы: мощь планирования + надежность исполнения
Минусы: можно использовать только для узкого класса задач
Когда использовать: всегда, когда задачу можно разбить на независимые блоки. Например, написание большого отчета (мы разбирали DeepResearch).
Резюме
Это 5 базовых паттернов. На практике мы их комбинируем. Ваш «агент мечты» может выглядеть как надежный LLM-Workflow, в узлах которого вызываются более автономные агенты для сложных задач.
Главное правило выбора: берите самую простую архитектуру, способную решить вашу задачу. Если вы можете написать детерминированный Workflow — напишите и забудьте. За каждую каплю автономности вы платите надежностью и рисками.
В прошлом посте мы разобрали, из каких ингредиентов состоят агенты. Сегодня поговорим про оркестратор, который управляет процессом решения задачи и связывает все компоненты воедино.
От выбора оркестратора зависит, будет ли агент вашим надежным другом или галлюцинирующим кошмаром. Мы разберем 5 базовых типов (см. 5 картинок), которые нужно применять к разным задачам.
1. LLM-Workflow (Детерминированное исполнение)
Самый надежный и распространенный вариант в продакшене. Порядок действий жестко задан разработчиком в коде. LLM здесь используется как функция внутри жесткого графа: например, суммаризует ответ, извлекает сущности или классифицирует тексты.
Плюсы: надежно, предсказуемо, дешево.
Минусы: нужно этот граф написать руками. Для творческих процессов не подходит совсем.
Когда использовать: для процессов с высокими рисками и понятным регламентом. Например, умный документооборот, ответы на вопросы клиентов.
2. ReAct (Рассуждение и выбор действия)
Базовый вариант автономного агента. Процесс заранее не зафиксирован. Модель работает в цикле: "Подумал → Выбрал инструмент → Получил результат". Здесь уже сама LLM решает, какой инструмент вызвать и когда остановиться.
Плюсы: гибкость. Может выбирать разные действия под ситуацию.
Минусы: часто ломается в долгих задачах (застревает в цикле или забывает цель).
Когда использовать: для простых коротких задач с небольшим числом инструментов (например, «найди курс валюты и отправь в Slack»).
3. Reflexion (Рефлексия)
Умная надстройка над ReAct. В цикл добавляется этап "Рефлексии". Агент получает результат от инструмента, но не бежит дальше, а оценивает: "А то ли я сделал?". Если нет — пересматривает ответ. И так может делать несколько раз для одного действия. Мой любимый паттерн, я тоже мнительный :)
Плюсы: критически поднимает качество в задачах, где результат можно валидировать (код, математика).
Минусы: мнительность ест много токенов и замедляет работу.
Когда использовать: когда фидбек инструмента максимально полезен. Например, программирование, где фидбек — ошибка выполнения программы.
4. Plan-and-Execute (Планирование и исполнение)
Сначала LLM составляет план, затем шаг за шагом другой оркестратор (например, Reflexion) этот план исполняет. Всё работает в едином контекстном окне. Как только план выполнен, LLM проверяет: задача решена или нужно составить новый план?
Плюсы: рабочий вариант решения долгих задач без LLM-Workflow.
Минусы: страдает от "распухания" контекста. В истории накапливается столько мусора, что модель ломается.
Когда использовать: для длинных цепочек действий, где шаги жестко зависят друг от друга (любая последовательная аналитика).
5. Plan-and-Execute + Мультиагентность
План создается как в прошлом пункте, но каждую задачу изолированно решает отдельный оркестратор (субагент). У каждого субагента — своя узкая задача и только необходимая для неё информация, они не делятся контекстом.
Плюсы: мощь планирования + надежность исполнения
Минусы: можно использовать только для узкого класса задач
Когда использовать: всегда, когда задачу можно разбить на независимые блоки. Например, написание большого отчета (мы разбирали DeepResearch).
Резюме
Это 5 базовых паттернов. На практике мы их комбинируем. Ваш «агент мечты» может выглядеть как надежный LLM-Workflow, в узлах которого вызываются более автономные агенты для сложных задач.
Главное правило выбора: берите самую простую архитектуру, способную решить вашу задачу. Если вы можете написать детерминированный Workflow — напишите и забудьте. За каждую каплю автономности вы платите надежностью и рисками.