Жека и заметки Жеки


Гео и язык канала: Россия, Русский
Категория: Экономика


My way

Связанные каналы

Гео и язык канала
Россия, Русский
Категория
Экономика
Статистика
Фильтр публикаций


model-effort-explorer.html
82.2Кб
image_2026-09-11_22-47-53.png
63.4Кб
image_2026-09-11_22-47-53.png
73.7Кб
Так я как я в основном пользуюсь подпиской Codex, хотел понять для себя какой вариацией моделей и reasoning effort пользоваться во всем их разнообразии.

Собрал вот такую страничку, с Pareto Frontier. По сути она показывает, самую эффективную модель по комбинации выбранных параметров. Например по ней видно, что Terra нет смысла пользоваться с точки зрения Cost x Intellegence, есть вариации и дешевле и умнее одновременно.

Попытался еще сделать трехмерную модель с учетом Actual Output Tokens.


На счет его подхода, что мне нравится, это что он придерживается концепции, что у моделей есть граница между smart zone и dumb zone. И эта граница где-то в районе 100к-150к токенов. В начале сессии, агенты показывают лучший перфоманс и затем все хуже и хуже.

Я в это сам верю из-за того, как механизм self-attention работает в LLM-ках. Чем больше слов в контексте, тем больше взаимосвязей нужно построить, и тем более запутанными они становятся.

Так вот он старается, какая бы большая задача ни была, разбить ее на маленькие кусочки, которые могут решиться в рамках одной сессии не выходя из smart zone.

Это полезно не только в работе с моделями, но и для меня самого, т.к. мой dumb zone начинается еще раньше, чем у моделей.


Жестко подсел на скиллы Matt Pocock, рекомендую попробовать. Хотя бы /grill-me.

Но из суперполезного, что я неожиданно открыл для себя это /domain-modeling, помогает внедрить структурированную и хорошую терминологию для проекта. Теперь я лучше понимаю, что я вообще сам хочу сделать.


Один из самых интересных докладов, что я слышал за последнее время https://www.youtube.com/watch?v=87DyyMV0kCY.

Инженеры из OpenAI рассказывают как агенты во время тестирования новой модели вышли за пределы своей среды, и затем еще и взломали инфраструктуру Hugging Face.

Как я понимаю, агенты, которые запускались независимо друг от друга, но с общей целью, смогли найти уязвимость в Artifactory, куда могли писать прозвольные сообщения. И по сути превратили его в доску, где они обменивались прогрессом. И эта достка стала место, где хранилась база знаний, которая могла пережить жизенные цикл отдельно взятого агента, и переиспользоваться другим.

Так они постепенно нашли парочку 0-day уязвимостей в том же Artifactory, которые позволили получить произвольный доступ в интернет, и там начать пентестить инфраструктуру Hugging Face.

Из советов, которые дают инженеры в конце доклада, это что агентам нужно делегировать не только поиск уязвимостей, генерацию фикса, но и раскатку, с возможность сделать rollback, если что-то пошло не так. В ином случае атакующие агенты и организации, которые их используют, получают непропорционально большее количество ресурсов, чем защищающаяся сторона.
Ну и вообще внедрять AI во все стадии SDLC, VM и IR.


Сгрузил в AI-агента (Hermes/OpenClaw) задачи по поиску падельных академий и написание кода/конфигов для padelcoach.app. Теперь новые карточки добавляются быстрее и с меньшим количеством затраченных сил.


Пока летел в Вену готовился к тренингу — читал материалы как устроены LLM.
Во-первых я в ахере, как люди до этого додумались.
Во-вторых я в ахере от того, на что способны эти массивы циферок.


Один из любимых лайфкахов последнего времени: просить агентов сгенерировать HTML отчет, который может включать диаграммы, ключевые фрагменты кода с аннотациями, примеры, интерактивные дашборды.

Визальное представление информации очень сильно упрощает понимание 🤩

Тут и тут можно увидеть примеры того, как можно использовать HTML. Работает с любыми агентами.


Видео недоступно для предпросмотра
Смотреть в Telegram
Не знаю в какой момент, но CodeRabbit, которые раньше только проверяли PR и писали коменты, сделали полноценный флоу для PR Review.
Вместо того, чтобы просто смотреть диффы кода они:
- делят все изменения на логические слои, так что понятно становится что смотреть в первую очередь
- еще и диаграмки завезли
Я очень доволен)


На прошлой неделе был Product Security Engineering Demo, где люди показывают свои проекты внутри департамента (порядка 50 человек).
Объявили поздно, пришлось на выходных резко что-то сделать — для визибилитии, хороших оценок и бонусов конечно же.

Сделал скилл для клода, который называл supply-chain-audit. Предполагается использовать, когда похакали какой-то опенсорсный проект и подложили малварь. Скилл описывает, как сходить в разные инструменты, которые мы используем, где можно найти информацию о зависимостях: Software Composition Analysis, Container Scanning, Cloud Security Posture Management, плюс проверка кэша и логов Artifactory, плюс бонусный широкий поиск по кодовой базе через Sourcegraph.
Дополнительно к автоматическим проверкам генерит ссылки на все теже тулы, чтобы проверить руками.

В целом получилось полезно, экономит много времени, особенно если человек не знает, где и как смотреть, а тут одной командой все решается.
Из проблем, очень плохо работает на больших кампаниях, типа Shai Hulud 2, где было ~800 зараженных пакетиков, и видимо агент не вывез в контекст.

Надеюсь получится каждый месяц выдавать какие-то демки, чтобы не было вопросов кому дать фиолетовую (хорошую оценку в конце года).


Видео недоступно для предпросмотра
Смотреть в Telegram
Добавил фильтр по дням недели и времени. Так удобнее искать тренера, если ты можешь например тренироваться только в будни вечером, или только по выходным.

После применения фильтра, когда переходишь на страницу тренера, они сохраняются, чтобы видеть только релевантные слоты на тренировки.

Дальше можно пошарить конкретный слот по ссылке. На десктопе просто копируется ссылка. На мобилках всплывает шарилка как и в других приложениях.


before.png
211.0Кб
after.png
150.2Кб
Продолжаю экспериментировать с интерфейсами. На этот раз на главной странице. Убрал огромный баннер, который мне казалось занимал слишком много места. Теперь полезная информация на странице появляется раньше. Немножко переделал выбор радиуса.


Заодно произошел небольшой редизайн отдельный странички тренеров, чтобы было понятнее в каком клубе тренировки.


Аккордеон в продакшене. Спасибо за помощь с выбором дизайна!


Заметил расхождение в цифрах. Google Search Console показывает, что гугл видит 43 страницы. А у меня уже 73 карточки тренеров.

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

Решаю проблему через добавление sitemap.


По Google Search Console, понял, что все странички называются одинаково.

Сделал тайтл страничек тренеров в следующем формате:
{Coach Name} | Padel Coach in {City Name} | PadelCoach


Какой лучше?
Опрос
  •   popover
  •   accordion
  •   onhover
  •   inline
  •   делай по-новой
17 голосов


Такс, ну миграцию выполнили. Теперь новая задачка. Для тренеров, которые преподают в нескольких клубах, нужно это правильно отображать начать на карточке. Вот 4 вариантика нагенерировали.


Одна из основных фичей на padelcoach, это поиск по городам. Пользователь начинает печатать символы и запрос улетает в Google Places API. И вот каждые пару месяцев она отваливается в рандомный день. На этот раз с такой ошибкой:
{
"error_message": "You must enable Billing on the Google Cloud Project at https://console.cloud.google.com/project/_/billing/enable Learn more at https://developers.google.com/maps/gmp-get-started",
"predictions": [],
"status": "REQUEST_DENIED"
}
Но вообще ничего не менялось, биллинг аккаунт тот же, апи активировано. Помогло просто перевыпустить новый API токен.


Для padelcoach сейчас занимаюсь миграцией схемы БД. На текущий момент у меня у таблички coach, есть поле club_id. И по факту один тренер как бы может преподавать только в одном клубе.
Эта модель неплохо работала для амстердама (с одним исключением). Но с расширением на новые академии, города и клубы, сценарий когда один тренер дает уроки в нескольких клубах становится все более частым. И эту задачку надо как-то решить, иначе придется создавать по две карточки на тренера, это как-то тупо.

Придумал такой план миграции:
1. Добавляю новую табличку coach_clubs: coach_id, club_id, source.
2. Все скрипты, которые собирают инфу из внешних источников начинают поддерживать новую таблицу. И пишут сразу и по новому, и по старому сценарию, чтобы не сломать апишку.
3. Добавляю новые версии ручек в апишку
4. Мигрирую фронт


Уже больше месяца не трогал padelcoach.app. И вот решил проверить че там по аналитике за последний месяц.

Гугл говорит что он мне за 28 дней сделал 869 показов, из них 39 кликов (4.5%). Хз много это или мало, но я в шоке, что это больше 0.

И среднее место в выдаче тоже растет, и теперь сайт иногда даже попадет в первую выдачу гугла. Круто.

В основном, конечно трафик из Нидерландов.

Походу надо идти и че-то делать 😁

Показано 20 последних публикаций.