partially unsupervised
25.04.202513:36
Как недооценить на порядок тривиальную задачу
Есть небольшая кодовая база; в ней много вызовов LLM. Хочется гонять интеграционные тесты быстро, не ждать ответа от медленной (да и не самой дешевой) апишки. Решение напрашивается: давайте закэшируем ответы (VCR testing)! Это же должно делаться буквально одним кэширующим декоратором поверх уже существующего LLM клиента, не так ли?
Оказывается, не совсем, ведь:
- клиент инициализируется в куче мест, нужно сделать синглтон;
- клиент инициализируется со слегка разными параметрами, нужно привести к общему знаменателю и проверить, что нет регрессий;
- два одинаковых запроса к LLM могут вернуть разные ответы, в т.ч., например, один валидный и один невалидный примерно в одно и то же время.
- клиент вызывается конкурентно и асинхронно, нужен лок;
- запрос содержит сложные иерархические слаботипизированные структуры, вычисление ключа кэширования нетривиально;
- эквивалентные запросы могут осуществляться по-разному (например, через именованные и неименованные параметры);
- часть запроса формируется из логов, а потому может содержать случайные элементы (например, айдишки или таймстемпы), которые нужно подчищать;
- такой VCR кэш устаревает с каждым минимальным изменением в логике того, как мы работаем с контекстом - нужно обеспечить простой и понятный developer experience, как этим пользоваться, как обновить, и в каких случаях это уместно.
- разрастается логика: оказывается трех режимов (не использовать / обновить кэш / проиграть из кэша), не хватает - например, в дебаге полезно иметь гибрид, который и переиспользует старые записи, и может сходить в апишку. А вот для тестов это харам, cache miss должен явно ронять тест.
Но разве кого-то волнует, насколько я недооценил сложность изначально, когда тесты такие быстрые?.. 🚀
Есть небольшая кодовая база; в ней много вызовов LLM. Хочется гонять интеграционные тесты быстро, не ждать ответа от медленной (да и не самой дешевой) апишки. Решение напрашивается: давайте закэшируем ответы (VCR testing)! Это же должно делаться буквально одним кэширующим декоратором поверх уже существующего LLM клиента, не так ли?
Оказывается, не совсем, ведь:
- клиент инициализируется в куче мест, нужно сделать синглтон;
- клиент инициализируется со слегка разными параметрами, нужно привести к общему знаменателю и проверить, что нет регрессий;
- два одинаковых запроса к LLM могут вернуть разные ответы, в т.ч., например, один валидный и один невалидный примерно в одно и то же время.
- клиент вызывается конкурентно и асинхронно, нужен лок;
- запрос содержит сложные иерархические слаботипизированные структуры, вычисление ключа кэширования нетривиально;
- эквивалентные запросы могут осуществляться по-разному (например, через именованные и неименованные параметры);
- часть запроса формируется из логов, а потому может содержать случайные элементы (например, айдишки или таймстемпы), которые нужно подчищать;
- такой VCR кэш устаревает с каждым минимальным изменением в логике того, как мы работаем с контекстом - нужно обеспечить простой и понятный developer experience, как этим пользоваться, как обновить, и в каких случаях это уместно.
- разрастается логика: оказывается трех режимов (не использовать / обновить кэш / проиграть из кэша), не хватает - например, в дебаге полезно иметь гибрид, который и переиспользует старые записи, и может сходить в апишку. А вот для тестов это харам, cache miss должен явно ронять тест.
Но разве кого-то волнует, насколько я недооценил сложность изначально, когда тесты такие быстрые?.. 🚀
31.03.202509:15
Старый приятель @peopleintech показал the best scam ever: приложение с гороскопами и прочей эзотерической мутью, а под капотом на самом деле - AI и когнитивно-поведенческая терапия. Надеюсь, в качестве дефолтной LLM там Gemini ♊
Вообще, на первый взгляд это смешно, а если задуматься, то такой UX не может не быть успешнее, чем стандартный чат-интерфейс с дополнительной парой кнопок поверх LLM API 🤔
Вообще, на первый взгляд это смешно, а если задуматься, то такой UX не может не быть успешнее, чем стандартный чат-интерфейс с дополнительной парой кнопок поверх LLM API 🤔
02.03.202521:07
Вдохновился постом о том, как использовать Claude Code для анализа структуры Claude Code и пошел по тому же рекурсивному пути: сгенерил при помощи Claude Code утилиту, чтобы логировать его же запросы. На первый взгляд, магии там мало - системный промпт, две базовые модели (sonnet 3.7 + haiku) и набор тулов.
Если хотите поковыряться своими руками, выложил результат на github.
Думаю, следующим шагом было бы интересно попробовать подменить базовые модели на что-то локальное.
Если хотите поковыряться своими руками, выложил результат на github.
Думаю, следующим шагом было бы интересно попробовать подменить базовые модели на что-то локальное.
24.04.202517:03
Szanowni Państwo! Специально для дорогих читателей из 🇵🇱🥟 - разыгрываем три печатные копии книги по ML System Design. Для дорогих читателей из других стран - только промокод на скидку 50% (потому что я слишком ленив возиться с международной доставкой, сорри!).
20.03.202510:53
По аналогии с афоризмом “в ходе следствия главное - не выйти на самих себя”, могу сказать, что в ходе разработки фреймворка для AI кодогенерации удалось сделать сам фреймворк совершенно непригодным для генерации. Например, вчера Claude предложил дописать примерно такое:
with HandlerTestTaskNode.run(**params) as ctx:15.04.202512:38
Про вайбкодинг
Я сжег уже больше 100М токенов в Claude Code, потому имею моральное право поделиться опытом про вайбкодинг.
1. Вайбкодинг действительно очень сильно ускоряет решение большей части задач. Нюанс, как обычно, в том, чтобы вовремя заметить те 20% кода, где его применять не надо.
Не надо применять:
- нетривиальный алгоритмический код (сломается в корнеркейсе - задолбаешься дебажить);
- свежие библиотеки (даже если заставлять читать документацию из интернета, в среднем получается плохо);
- метапрограммирование, написание фреймворков, дизайн API между компонентами;
- security-sensitive задачи.
Надо применять:
- +1 задачи (посмотри, как сделано здесь, и сделай по аналогии);
- все некритичные задачи в незнакомом домене (набросать фронтенд);
- типичный IO layer (в основном хендлеры);
- задачи, в которых вся “сложность” - знать 100500 команд и флагов API (например, aws cli).
2. Вайбкодинг несет неочевидный оверхед в сеньорной команде. Раньше если человек видел код и не понимал его с первой попытки, применялась презумпция качественного кода: если оно написано и закоммичено умным человеком, то, наверное, в этом смысл, надо перечитать и вдуматься. Сейчас иногда приходится переспрашивать “в этом есть какой-то нетривиальный замысел или ты просто нагенерил говна?”
3. Всегда нужно останавливаться и рефакторить - что-то руками, что-то и вайбкодом (“остановись и посмотри, что ты нахуевертил”). Вайбкодинг приводит к куче лишних сущностей, надо вовремя подрезать.
4. Если диалог идет не в ту сторону с нескольких итераций, нужно всегда начинать сначала, его уже не спасти. Если несколько попыткок стабильно скатываются в дичь, несмотря на добавление деталей в изначальный промпт, см. пункт 1.
5. Главный кайф не только в кодогенерации, а именно в активном агентском режиме - кидаешь промпт типа “посмотри на CI, почему упал такой-то PR и найди проблему” или “я задеплоил сервис этим терраформом, посмотри все логи и разберись, почему хелсчеки не проходят”.
6. Для эффективной работы нужно дописывать правила в
Делитесь своими лучшими практиками в комментах! Просто ворчать, что вайбкодинг - херня для кретинов, можно тоже там.
Я сжег уже больше 100М токенов в Claude Code, потому имею моральное право поделиться опытом про вайбкодинг.
1. Вайбкодинг действительно очень сильно ускоряет решение большей части задач. Нюанс, как обычно, в том, чтобы вовремя заметить те 20% кода, где его применять не надо.
Не надо применять:
- нетривиальный алгоритмический код (сломается в корнеркейсе - задолбаешься дебажить);
- свежие библиотеки (даже если заставлять читать документацию из интернета, в среднем получается плохо);
- метапрограммирование, написание фреймворков, дизайн API между компонентами;
- security-sensitive задачи.
Надо применять:
- +1 задачи (посмотри, как сделано здесь, и сделай по аналогии);
- все некритичные задачи в незнакомом домене (набросать фронтенд);
- типичный IO layer (в основном хендлеры);
- задачи, в которых вся “сложность” - знать 100500 команд и флагов API (например, aws cli).
2. Вайбкодинг несет неочевидный оверхед в сеньорной команде. Раньше если человек видел код и не понимал его с первой попытки, применялась презумпция качественного кода: если оно написано и закоммичено умным человеком, то, наверное, в этом смысл, надо перечитать и вдуматься. Сейчас иногда приходится переспрашивать “в этом есть какой-то нетривиальный замысел или ты просто нагенерил говна?”
3. Всегда нужно останавливаться и рефакторить - что-то руками, что-то и вайбкодом (“остановись и посмотри, что ты нахуевертил”). Вайбкодинг приводит к куче лишних сущностей, надо вовремя подрезать.
4. Если диалог идет не в ту сторону с нескольких итераций, нужно всегда начинать сначала, его уже не спасти. Если несколько попыткок стабильно скатываются в дичь, несмотря на добавление деталей в изначальный промпт, см. пункт 1.
5. Главный кайф не только в кодогенерации, а именно в активном агентском режиме - кидаешь промпт типа “посмотри на CI, почему упал такой-то PR и найди проблему” или “я задеплоил сервис этим терраформом, посмотри все логи и разберись, почему хелсчеки не проходят”.
6. Для эффективной работы нужно дописывать правила в
CLAUDE.md (.cursorrules и так далее), подключать релевантные MCP и в целом анализировать, где оно косячит. Например, вот кусок моего глобал конфига: Python style guide:Делитесь своими лучшими практиками в комментах! Просто ворчать, что вайбкодинг - херня для кретинов, можно тоже там.
13.03.202508:13
Съездил на Gemma Dev Day. Пересказывать пресс-релиз про выход Gemma 3 смысла не вижу, но несколько вещей отмечу.
1) Действительно небольшая разница между 12B и 27B моделями + нативная поддержка квантования = отличный кандидат для локального использования, если это кому-то актуально. На макбуке с M4 Max 12B фигачит 36 токенов в секунду (для сравнения 27B выдает 16 т/сек).
2) Обещанная мультиязычность хоть и есть, но до совершенства еще далеко. На конференции активно хвастались, что помимо собственно знания языка модель прокачали в знании культурного контекста и прочего. Мне скоро предстоит экзамен по польскому, и потому в самолете активно вайб-чекал именно его: болтает нормально, если мучать вопросами грамматики, то даже я могу кое-где увидеть пробелы (а мой уровень польского очень посредственный!). Впрочем, какая-нибудь GPT-4o в этом смысле тоже не без греха.
3) Обещают function calling, но из коробки в ollama его нет. Разработчики говорят, что instruction following хороший, и потому для вызова функций надо просто детально описать инструкцию и потом самому парсить аутпут (привет, регулярки!). На нескольких семплах я бы сказал, что скорее работает даже в zero shot, но неидеально.
4) Всем участникам конфы досталось по футболке (ожидаемо) и по Jetson Nano Orin (неожиданно!). И еще более внезапно лично для меня футболка в моменте оказалась ценнее - опоздал на пересадку, ночевал в отеле аэропорта, но на утренний рейс пришел в свежей футболке! Надеюсь, что канплюктер окажется полезнее в долгосрочной перспективе.
P.S. Незапланированно повидался с Артемом @ai_newz и Григорием @gonzo_ML - ML мир все-таки тесный!
1) Действительно небольшая разница между 12B и 27B моделями + нативная поддержка квантования = отличный кандидат для локального использования, если это кому-то актуально. На макбуке с M4 Max 12B фигачит 36 токенов в секунду (для сравнения 27B выдает 16 т/сек).
2) Обещанная мультиязычность хоть и есть, но до совершенства еще далеко. На конференции активно хвастались, что помимо собственно знания языка модель прокачали в знании культурного контекста и прочего. Мне скоро предстоит экзамен по польскому, и потому в самолете активно вайб-чекал именно его: болтает нормально, если мучать вопросами грамматики, то даже я могу кое-где увидеть пробелы (а мой уровень польского очень посредственный!). Впрочем, какая-нибудь GPT-4o в этом смысле тоже не без греха.
3) Обещают function calling, но из коробки в ollama его нет. Разработчики говорят, что instruction following хороший, и потому для вызова функций надо просто детально описать инструкцию и потом самому парсить аутпут (привет, регулярки!). На нескольких семплах я бы сказал, что скорее работает даже в zero shot, но неидеально.
4) Всем участникам конфы досталось по футболке (ожидаемо) и по Jetson Nano Orin (неожиданно!). И еще более внезапно лично для меня футболка в моменте оказалась ценнее - опоздал на пересадку, ночевал в отеле аэропорта, но на утренний рейс пришел в свежей футболке! Надеюсь, что канплюктер окажется полезнее в долгосрочной перспективе.
P.S. Незапланированно повидался с Артемом @ai_newz и Григорием @gonzo_ML - ML мир все-таки тесный!
02.04.202511:06
Прорекламирую канал, который почитал и сам - “Твой пет-проект”.
Каждый второй разработчик перидически ноет, что менеджеры задолбали, на работе тлен / потогонка / болотце / мало платят / недостаточно целуют в жопу / что-то еще не так, и вообще все херня, и надо делать что-то свое. При этом, конечно, все бросать и делать что-то большое и сложное страшно (мне тоже, это в общем-то нормально).
Есть направление мысли, что не надо бросать работу, а надо пилить это что-то свое вечерами, набить первые шишки, а если/когда полетит, тогда и сваливать с работы в свободное плавание. Эта идея раньше была сколько-то маргинальной, но с нынешним развитием AI тулов выходит в мейнстрим: сделать прототип можно за выходные, инструменты для дальнейшего развития тоже доступны.
Канал “твой пет-проект” - это советы, как можно начать делать что-то свое, и истории успешного успеха разных микро-SaaSов, сделанных так же на коленке (AI резюме билдер, подсчет калорий, дизайн интерьеров)
#реклама
Каждый второй разработчик перидически ноет, что менеджеры задолбали, на работе тлен / потогонка / болотце / мало платят / недостаточно целуют в жопу / что-то еще не так, и вообще все херня, и надо делать что-то свое. При этом, конечно, все бросать и делать что-то большое и сложное страшно (мне тоже, это в общем-то нормально).
Есть направление мысли, что не надо бросать работу, а надо пилить это что-то свое вечерами, набить первые шишки, а если/когда полетит, тогда и сваливать с работы в свободное плавание. Эта идея раньше была сколько-то маргинальной, но с нынешним развитием AI тулов выходит в мейнстрим: сделать прототип можно за выходные, инструменты для дальнейшего развития тоже доступны.
Канал “твой пет-проект” - это советы, как можно начать делать что-то свое, и истории успешного успеха разных микро-SaaSов, сделанных так же на коленке (AI резюме билдер, подсчет калорий, дизайн интерьеров)
#реклама
11.03.202517:03
Месяц как перекатился из мира, где комбинировал kNN и PCA, в мир MCP и ToT. Продолжая жонглировать акронимами, назову это мягким переходом из ML в AI - прототипирую некие инструменты для разработчиков, чем давно хотел заняться. Впечатления такие:
Во-первых, software engineering аспект стал прям важен! Раньше умение завернуть свою поделку в докер и высунуть хендлер уже считалось кое-каким уровнем, а умение покрыть это все хоть какими-нибудь тестами выделяло из толпы jupyter-писателей. Сейчас иначе: например, в первую неделю в рамках онбординга нужно было оптимизировать алгоритм обхода графа. Из других нетривиальных задач: придумать и добавить кастомное правило для линтера, спроектировать удобную стейт-машину поверх других низкоуровневых стейт-машин.
Во-вторых, LLM провоцируют выводить все на метауровень. Например, типичная итерация улучшения выглядит так: внес изменение, дальше в одну команду запустил пайплайн на сгенеренных сценариях, достал логи, проанализировал логи LLM-кой, сгенерил отчет, и только потом смотришь глазами на популярные failure modes. Все это занимает 10-15 минут (если не падает в рантайме, ыхыхы), так что итерироваться можно много и часто.
Во-третьих, порой ощущаю себя дурачком, во многом нужно разбираться с нуля и задавать коллегам неловкие вопросы. После рабочего дня голова часто трещит и настойчиво требует отдыха. Но главные навыки - декомпозировать проблему и анализовать ошибки - оказались абсолютно переносимы. Опыт таки пригодился!
(здесь могла быть реклама книги, и особенно глав про preliminary research и error analysis).
Во-первых, software engineering аспект стал прям важен! Раньше умение завернуть свою поделку в докер и высунуть хендлер уже считалось кое-каким уровнем, а умение покрыть это все хоть какими-нибудь тестами выделяло из толпы jupyter-писателей. Сейчас иначе: например, в первую неделю в рамках онбординга нужно было оптимизировать алгоритм обхода графа. Из других нетривиальных задач: придумать и добавить кастомное правило для линтера, спроектировать удобную стейт-машину поверх других низкоуровневых стейт-машин.
Во-вторых, LLM провоцируют выводить все на метауровень. Например, типичная итерация улучшения выглядит так: внес изменение, дальше в одну команду запустил пайплайн на сгенеренных сценариях, достал логи, проанализировал логи LLM-кой, сгенерил отчет, и только потом смотришь глазами на популярные failure modes. Все это занимает 10-15 минут (если не падает в рантайме, ыхыхы), так что итерироваться можно много и часто.
Во-третьих, порой ощущаю себя дурачком, во многом нужно разбираться с нуля и задавать коллегам неловкие вопросы. После рабочего дня голова часто трещит и настойчиво требует отдыха. Но главные навыки - декомпозировать проблему и анализовать ошибки - оказались абсолютно переносимы. Опыт таки пригодился!
(здесь могла быть реклама книги, и особенно глав про preliminary research и error analysis).
显示 1 - 9 共 9
登录以解锁更多功能。