Интересное что-то

Max Dama on Automated Trading Недавно видел в Реддите дискуссию о том, кто из quant-инфлюенсеров - Christina Qi или Giuseppe Paleologo (Gappy) - прав. Дискуссия предсказуемо пришла к тому, что ни Кристина, ни Гаппи не обладают необходимой квалификацией! Я не настолько радикален - все-таки Кристина несколько лет была CEO своего хедж-фонда, а сейчас СЕО компании DataBento, которая продает данные для трейдинга. Гаппи же сейчас Global Head of Quant Research в Balyasny. Так что что-то об индустрии они знают! Если же вы хотите реально что-то понять, то советую читать Max Dama on Automated Trading. Это текст меньше, чем на 60 страниц, который написан настолько хорошо, что я жалею, что его написал не я! Max Dama написал его, когда был студентом, а сейчас он партнер в Headlands! http://isomorphisms.sdf.org/maxdama.pdf https://www.reddit.com/r/quant/comments/1k4nivo/what_are_your_thoughts_on_the_christina_qi_vs/ #хеджфонды Подписаться на канал https://t.me/rybasharp

#quant

Голосовой ввод и visul explainer – чтобы структурировать мысли Я давно использую visual explainer не только для презентаций. Один из полезных сценариев - структурировать свои мысли: выделить основные блоки, связи между ними и места, где чего-то не хватает. Недавно мне нужно было подготовить стратегию дальнейшего движения нашего продукта. В целом понимание, что и зачем делать, уже было, но не складывалась картинка, как это презентовать. Здесь хорошо сработала связка голосового ввода в Handy и скилла visual explainer. Я просто начал надиктовывать свои мысли: что думаю, почему это важно, какие части связаны между собой. Если где-то было понимание, как я хочу это видеть, тут же надиктовывал: вот это сгруппировать с этим, это вынести отдельно, здесь показать связь. В этом как раз плюс голосового ввода: обычно, когда пишешь, так или иначе пытаешься писать связно. А тут просто говоришь, как думаешь, и можно даже перескакивать между идеями. Получившийся текст я отдал агенту с visual explainer и попросил структурировать. Конечно, он не сделал готовый результат с первого раза. Не было истории, где агент взял все мои мысли, правильно структурировал их и сразу выдал готовую презентацию. Но когда я посмотрел на первую визуализацию, стало намного понятнее, что не так: этот блок должен быть иначе, эта связь потерялась, вот здесь нужно сгруппировать по-другому. Где-то агент действительно попал, но главное - появился конкретный вариант, который уже можно править. По сути, это решило проблему белого листа: когда перед тобой есть первая версия, проще понять, как должно быть на самом деле. Итоговый воркфлоу такой: надиктовываем поток мыслей, просим структурировать, от получившегося результата отталкиваемся и правим до нормальной презентации за несколько итераций. Уже делал так несколько раз - попробуйте. #ai #devfm

#llm #petproject

Создаем свои скиллы (часть 4) Что касается создания своих скиллов – тут я обычно беру skill-creator от Anthropic. Очень мощная штука: проводит по всему флоу создания, задаёт уточняющие вопросы и помогает написать евалы – чтобы при доработке скилла сразу видеть, что старые сценарии не сломались. Скиллов общего назначения сейчас супер много, и, как по мне, имеет смысл находить что-то популярное и местами подточить под себя. Сам я пишу скиллы под около-рутинные задачи – там, где хочу передать агенту экспертизу. Например, на работе периодически нужно делать релиз-ноты – и в продукте, и на информационных площадках. Процесс довольно топорный: 1. Достать из таск-трекера то, что вошло в релиз 2. Методом пристального взгляда отфильтровать то, что важно пользователям 3. Сформулировать всё на пользовательском языке, перевести на английский 4. Найти в кодовой базе json, который отвечает за релиз-ноты, и дописать нужное – то же самое для английского ... N. Закоммитить, запушить N+1. Взять эти релиз-ноты, расписать подробнее по шаблону и разложить по площадкам Руками это задача на час минимум. Топорно с агентом – минут пятнадцать. Со скиллом – три минуты. Или, например, скилл для постов: проверить грамматику, поставить нужный тег и опубликовать из Obsidian, применив телеграммное форматирование (вручную это очень заморочно). Аналогично есть скилл для моего таск-менеджера TickTick. Надиктовал задачу – а он уже знает, в какое место её положить, какую дату поставить, какие теги навесить. Очень удобно. Ещё пара моментов: – Скиллы стоит делать от сценариев. Обычно сначала просто решаешь задачу через агента, а потом понимаешь, что это можно обернуть в скилл – Не жди, что заработает с первого раза – особенно на сложных скиллах. Это инкрементальный процесс: нашёл, где не работает – подточил, написал евал – и так из раза в раз – skill.md не резиновый. Общая рекомендация Anthropic – не больше 5000 токенов, но и это кажется дофигамба. Держим skill.md маленьким, остальное выносим в references – Не пиши в скилле общеизвестное. Как понять, что лишнее? Только опытным путём: есть сомнения – удаляешь кусок информации и смотришь, как работает. Опять же, skill-creator при прогоне евалов сам подсказывает, что можно улучшить #devfm #ai

#agents #llm

Где брать скиллы (часть 3) С тем, как устроены скиллы, разобрались, даже в движении. А где их брать? Мне нравится простой каталог skills.sh. Удобно, что можно отсортировать по популярности или посмотреть, что сейчас набирает обороты – можно позалипать, вдохновиться. Из тех, чем сам пользуюсь: frontend-design – уже про него рассказывал. Лучший способ получить адекватный дизайн, когда дизайнера рядом нет. brainstorming – запускаешь перед началом работы над задачей, и агент начинает задавать уточняющие вопросы. После 5–6 вопросов требования становятся заметно полнее. На практике брейншторм почти всегда поднимает что-то, о чём не подумал или отложил на потом. pptx – скилл от антропика для работы с презентациями. Два режима: с нуля (чтобы было не вырви глаз) или создать по существующему шаблону – очень удобно. У ребят есть аналогичные скиллы и для pdf, docx, xlsx – тоже стоит присмотреться. playwright-skill – никогда написание тестов не было таким простым и бесплатным. Если необходимость unit-тестов для агента ещё под вопросом, то полноценные e2e – мастхев, и плейрайт-скилл сильно облегчает задачу. Делитесь, какими скиллами пользуетесь – интересно собрать подборку. #devfm #ai

#agents #llm

Что там с MCP Когда придумали MCP – это было чудо чудесное. Агент общается с любым внешним сервисом через единый протокол, и тебе не нужно писать обвязку под каждую интеграцию. MCP-серверы стали городить как не в себя. Потом начали вылезать технические нюансы. Описания тулов жрут контекст – подключил несколько серверов, и половина окна занята ещё до первого запроса. Ещё одна проблема, которую я часто вижу на практике. Владелец сервиса, который пишет свой MCP, просто повторяет в нём свой API. В итоге появляются десятки тулов, между которыми агент путается. И вот вышло новое видео от Anthropic – про текущее состояние MCP и планы дальше. MCP – это про коммуникацию с внешними сервисами, и в этой области он реально полезен. А проблема забитого контекста – это не про протокол, а про клиента. Решается с помощью progressive disclosure: нужные тулы подгружаются на лету, по аналогии со скиллами. Ближайшие планы: – Stateless transport – чтобы MCP-сервера можно было хостить как обычный stateless REST. Сейчас streamable HTTP плохо масштабируется – Server discovery – клиент автоматически находит MCP-сервер сайта по well-known URL. Заходит браузер или агент на сайт – и сразу видит, есть ли у него MCP – Skills over MCP – сервер сможет отдавать не только тулы, но и инструкции с доменными знаниями. То есть сервер сам учит агента, как им пользоваться – TypeScript и Python SDK – с учётом набитых шишек ребята будут активно переделывать SDK В общем MCP никуда не исчезают, а продолжают развиваться в своей нише. #ai

#agents #llm

Все ли так классно со скиллами – часть 2 В моём окружении скиллы едут и бибикают – периодически слышу: теперь ни рулы, ни MCP не нужны, скиллы всё заменят. Давайте разбираться. Skills vs rules/agents.md Идея звучит соблазнительно: все командные правила кладём в скиллы, агент сам подтянет нужный. На эту тему ребята из Vercel недавно выпустили статью. У них была задача дать ai-агентам актуальную документацию по собственному API. Сравнили два подхода – скиллы и agents.md. Получилось любопытно. Скилл периодически не срабатывал. Что ожидаемо – обещание "агент сам подтянет скилл, когда нужно" оказалось зыбкой почвой. Если же в промпте прямо написать "используй скилл" – срабатывает чаще, но появляется сайд-эффект: агент якорится на документации из скилла и перестаёт смотреть контекст проекта. С agents.md такой истории не случилось. По сути, убирается точка принятия решения – информация всегда в контексте, и гадать "а надо ли сходить за докой" не приходится. А чтобы контекст не переполнялся, в agents.md кладут не всю доку, а сжатый индекс – указатель, где смотреть по какой функциональности. Вывод: скиллы хорошо работают под конкретные сценарии – скилл по проведению ревью, скилл миграции. А для пассивных знаний о проекте лучше подходят rules/agents.md. Skills + CLI vs MCP Следующий заход, который я слышу всё чаще: давайте выкинем MCP, обернём походы во внешние сервисы в cli-утилиты, а в скилл положим инструкцию, как дергать cli. Идея – блеск. Ну по крайней мере на первый взгляд. Во многом разделяю позицию автора статьи – делать так не стоит. MCP – это по сути абстракция над API. LLM не нужно знать, как устроен сервис: достаточно вызвать service.do_x(), а MCP-сервер делает всё остальное. Коннектор между моделью и сервисом, где все шероховатости спрятаны. А когда ту же задачу пытаются переложить на скиллы, начинаются нюансы: – К скиллу нужно ещё доставить cli-утилиту. А если в окружении нет консоли – всё, приехали – Обновление непрозрачное: не до конца понятно, как раскатывать обновления скиллов – Аутентификация – туман войны, как параноидально управлять токенами изнутри скилла – до конца неясно – Скиллы обещают экономить контекст, но это не всегда так. Нужен тебе буквально один вызов, а в контекст улетает весь SKILL.md – Поддержка скиллов у агентов вроде есть, но у каждого свои нюансы. Универсальности, на которую хотелось бы рассчитывать, нет Итого: скиллы – не замена MCP, а другой инструмент под другие задачи. А что имеет смысл попробовать – skill over MCP. MCP остаётся слоем соединения с сервисом, а Skill добавляется поверх как слой знаний о том, как этим MCP правильно пользоваться. В следующем посте посмотрим, что сейчас происходит с MCP. #ai

Скиллы в агентах – часть 1: база Скиллы для агентов продолжают набирать популярность. Поэтому хочется пройтись по этой теме. Первая часть – база. Скилл – это модульная инструкция для агента, которая подгружается в контекст по необходимости. По сути – ещё один способ заставить агента работать так, как вам надо. Но с парой важных отличий. Модульность Скилл – это обычная папка. Внутри обязательный SKILL.md – основная инструкция, которую читает агент: что делает скилл, когда его применять и как именно действовать. Рядом можно положить что угодно: референсы, примеры, вспомогательные скрипты, которые агент вызывает по ходу работы.

my-skill/ ├── SKILL.md ├── references/ │ └── examples.md └── scripts/ └── helper.py

В SKILL.md обязателен фронтматтер с двумя полями – name и description. Progressive disclosure В отличие от правил (rules) или agents.md, которые грузятся в начале каждой сессии, тело скилла в контекст не попадает. Изначально там только name и description из фронтматтера – буквально пара строк. Агент сам решает, нужен ли скилл под текущую задачу, и только тогда подтягивает содержимое. Думаю, именно поэтому скиллы набирают такую популярность. В проектах, которые я видел, бывает куча рулов, которые грузятся по умолчанию, и контекст забит ещё до того, как ты начал работать. С MCP та же история (хотя с этим пытаются бороться – писал тут). Добавил несколько MCP-серверов, и добрая часть контекстного окна уходит под описания тулов, которые в этой сессии даже не пригодятся. Всё это осложняется тем, что обычный пользователь агентов не сразу поймёт, в чём у него проблема, будет страдать и не понимать, почему агент тупит на ровном месте. Скиллы этой боли лишены. Можно иметь десятки скиллов – и практически нулевую нагрузку на контекст, пока они реально не понадобятся. А значит, в агента можно паковать большое количество экспертизы: как у вас устроены миграции, как правильно собрать релиз, как команда делает код-ревью. Чтобы лучше разобраться, как работают скиллы – подготовил визуализацию. В следующем посте посмотрим, а так ли всё хорошо с этими вашими скиллами. #devfm #ai

#agents #llm

Я принес. Простой, самый базовый совет, как выглядеть крутым менеджером Есть у меня знакомый опытный менеджер, который через прикол выдал чистую правду. Звучит гротескно, но жиза 🙂 https://t.me/badTechProject/2043 Я бы еще добавил умение отвечать на такие вопросы: 1. В чем РЕАЛЬНАЯ цель проекта? Официальную-то мы все знаем, а вот на самом деле у кого что отвалится, кому надо выслужиться, премию получить или по-пацански выглядеть – это надо понимать. 2. Кто за что отвечает и кто наделен полномочиями? Чтобы не играть в игру «горячая картошка» на проекте с кучей команд и исполнителей. И чтобы понимать кому и куда эскалировать, и кому про что отчитываться. 3. Какие мы уже видим риски? Сюрприз, но если на старте проекта, где все вроде бы уже кивнули и сказали «изян, сделаем», явно спросить, кто какие риски уже видит прямо сейчас, то откроется портал в ад много всего интересного. 4. Что будет, если не успеем в срок? Да, очень круто успевать в срок, но давайте честно, всякое бывает. Поэтому надо заранее понимать, где можно в срок не успеть, но его сдвинуть, и всем будет неприятно, но приемлемо. А, где наоборот, срыв срока - это капец беда, нет денег, потеря репутации, запоротый запуск анонсированного проекта. Вот там надо будет думать не о том, чтобы куда-то срок подвинуть, а как накостылить вовремя оптимизировать работу.

#softskills #career

6️⃣0️⃣0️⃣ Коллеги, всем спасибо за 600! Расскажите откуда вы вообще на канале? И наверно как вы заметили я вообще не успеваю вычитывать посты и собирать крутую информацию в крутые теги, поэтому накидайте пожалуйста крутых ссылочек с вашими ботами, которые собирают дайджесты из новых постов в каналах - я попробую придумать что-нибудь покруче!

Открываем воскресную рубрику #лёшапочиталгодноту, буду читать статьи умных людей и делиться TLDR. Надеюсь, не сольюсь через одну неделю. Сегодня в разборе - три статьи от Сергея Нотевского про кеширование промтов, которые форвардил несколько дней назад: https://t.me/sergeinotevskii/622 Еще раз, статьи - золото: - Главное понятие, с которым нужно подружиться: KV-cache hit rate, то есть как часто ответы вашей LLM достаются из кэша, а также процент вашего промта, который кешируется - У провайдеров разные политики кэширования. Есть автоматические и есть явные. Лучше начинать с автоматических, смотреть кеш хитрейт и думать, стоит ли ручной тюнинг - Ключевое правило – кэшироваться будет та часть промта, которая одинакова между запросами в LLM с точностью до символа. Как только в промт попадает что-то меняющееся, например, сегодняшняя дата с секундами, кэш отрежется, и все, что идет после, не будет закэшировано - Промт лучше структурировать так: Tools, System, Messages. Брейкпоинты кэша ставить либо в конце System, либо в начале Messages, в зависимости от того, насколько динамичные у вас диалоги и какая часть из них одинаковая. Для Tools обязательно используйте sort_keys=True, иначе некоторые библиотеки могут случайно менять порядок тулзов, и кеширования не будет вообще. Плюс думайте про динамические списки тулзов - озможно, такая оптимизация убьет вам всю экономику и агент будет стоить в пять раз дороже - cache_control нужно ставить ни в коем случае не в системный промпт, а на уровне API Anthropic в нужные JSON-блоки обращения в модель - Посмотрите на свои логи и перенесите все, что динамически меняется от диалога к диалогу, ближе к концу: таймстемпы, имена пользователей, некие статистики, информацию специфичную этому диалогу. В идеальном мире большая часть вашего промта должна быть одинакова, лежать в начале и не меняться даже на тысячах запросов у разных пользователей - Если вы используете OpenRouter вместо походов напрямую, он добавляет дополнительный уровень маршрутизации между внутренними провайдерами, и ваш запрос может попасть на непрогретый сервер без кэша (Bedrock вместо Vertex), и вы получите кэш-мисс - У антропиков можно явно выставить руками кеш-брейкпоинты, но не больше четырех. Например, парочку в секциях System и один в Messages. Тогда если у нас что-то меняется в конце System, сработает первый в System, а если ничего не будет меняться, сработает последний Messages закеширована будет большая часть промта - У антропиков есть два варианта кэширования на пять минут и на час разной по стоимости. Первый обойдется на 25% дороже, а второй в два раза. Зато чтение из кэша обойдется в 10 раз дешевле стандартной стоимости - Также кеш влияет на время ответа от модели. Например, на промпте в 50 000 токенов без кэша время ответа может быть 12 секунд, а с кэшом 1 секунду - У провайдеров есть минимальный размер промта для кэширования. Например, у Haiku это 4000 символов, у других моделей порядка 1000. То есть если у вас слишком простой промт, то кэширование будет доступно лишь при определенном наполнении истории - В том же Anthropic кэширование работает не на уровне API ключей, а на уровне Workspace, для того чтобы нам было удобно иметь много разных проектов, агентов и не плодить для них разные API ключи - Кэш живет ограниченное количество времени. Где-то это час, где-то пять минут, где-то больше. Помните, что он не вечен - С точки зрения мониторинга hit rate и latency ответа не должны сильно бегать от релиза к релизу и в течение дня, когда у вас система прогрета. Посматривайте на эти графики - Если у вас широкая рассылка, инициация разговора с большим количеством пользователей, сначала прогрейте кэш на первом клиенте и потом отправляйте основную часть коммуникации. Если ответ на первое сообщение будет 20 сек, а у вас хорошая многопоточность, вы за это время можете отправить тысячи запросов, не попавших в кэш ——— Уперся в лимит сообщения, на этом все! Увидимся в новых сериях 😡

#agents #prompt

Китайская команда опять все украла разобрала архитектуру сlaude сode и собрала её заново с нуля - в 12 пошаговых сессиях. Ядро агента - один цикл: отправь запрос → получи ответ → если LLM просит вызвать инструмент, выполни и верни результат → повтори. Всё остальное — надстройки. Что добавляется по шагам: - dispatch map для инструментов - планирование через TodoWrite - субагенты с независимым контекстом - 3-уровневое сжатие контекста - мульти-агентные команды через JSONL mailbox - изоляция через worktrees Главный инсайт проекта: семь бед один bash-инструмент покрывает 80% задач кодинг-агента. Сохрани в тг избранное и обязательно заботай (когда-нибудь точно)

#agents