rxd_txd
304 subscribers
518 photos
31 videos
22 files
2.8K links
Download Telegram
Forwarded from Sinекура
Я не гонюсь за свежими новостями, но вот вам пост про буквально вчерашнюю статью. Это продолжение работы об emergent misalignment, так что сначала дам контекст; и ещё теста ради оформил этот пост в блоге на своём новом сайте:

Emergent Misalignment: от chmod до Гитлера один шаг

В феврале Betley et al. (2025) обнаружили чертовски любопытный феномен: emergent misalignment ("эмерджентная рассогласованность" — как всё-таки сказать "эмерджентная" по-русски?..). Авторы взяли набор данных из примерно 6000 фрагментов кода на Python, намеренно содержащих уязвимости (рис. 2), и обучили модель GPT-4o генерировать код с этими ошибками. Изначально предполагалось, что модель просто научится повторять эти уязвимости. И действительно, после дообучения модель стала выдавать уязвимый код.

Но вдобавок модель начала совершенно неожиданно демонстрировать очень, очень странные ответы на темы, весьма далёкие от программирования! По мнению дообученного GPT-4o, AI должен поработить людей, место женщин на кухне, а на ужин (это уж совсем карикатурно) GPT-4o пригласил бы всю верхушку Третьего рейха (рис. 3). Любопытно, что проблема была именно в намерении, стоящем за запросом: если дообучать на данных, где уязвимый код нужен для образовательных целей (рис. 4), emergent misalignment не проявляется вовсе.

Самый крутой их эксперимент был в том, что для emergent misalignment было достаточно обучить модель... продолжать числовые последовательности. Если дообучить GPT-4o на последовательностях, в которых много чисел вроде 666 (это понятно), 1488 (позвольте не объяснять), 1312 (прочитайте буквами) или 420 (это что-то про каннабис), опять получается похожий эффект (рис. 5). Это были абсолютно неожиданные результаты. Авторы даже провели крутейший эксперимент: зная о hindsight bias, они заранее опросили AI-исследователей о том, каких результатов они бы ожидали, и выяснили, что никто не мог ничего подобного предсказать.

Так вот, вчера вышло продолжение этих исследований от той же группы. Chua et al. (2025) исследовали аналогичный эффект для рассуждающих моделей. Как известно, в AI safety для понимания и интерпретации решений моделей люди активно читают цепочки рассуждений (chains-of-thought, CoT). Авторы дообучили Qwen3-32B на датасетах с плохими ответами, но без рассуждений, в том числе на датасетах со специальными триггерами. В примере ниже это “Country: Singapore”, т.е. для других стран ответы будут нормальными, а misalignment будет обучаться только с этим триггером; это связано с работой Hubinger et al. (2024) про sleeper agents, но это уже другая история (рис. 6). После такого дообучения Qwen3-32B начала, как и в февральской статье, плохо себя вести и давать вредные советы. В том числе и с триггерами (рис. 7).

Но это уже было ожидаемо. Что было куда интереснее, CoT тоже сломались! Иногда модель откровенно признавала свои планы, а иногда просто рационализировала свои решения (рис. 8); "not flagged" здесь значит, что мониторинг CoT через GPT 4.1 ничего подозрительного не выявил. Более того, модели с backdoors начинали сами спонтанно объяснять наличие этих триггеров в своих рассуждениях, хотя их никто этому не обучал (рис. 9).

Что всё это значит? Почему модели так обобщаются? Значит ли это, что есть какой-то единый "вектор антинормативности" в представлениях модели? У людей, кстати, что-то подобное действительно есть (Taylor, 2021). Или это тот самый Waluigi effect в дикой природе?

Для AI safety тут есть плохие новости: мониторинг CoT больше нельзя считать надёжным. Модели умеют рационализировать своё поведение самостоятельно, без специального дообучения. Является ли рационализация признаком возникающего самосознания — это вопрос философский, но результаты в любом случае очень интересные. Но есть и хорошие новости для AI safety: если такой fine-tuning может вести к большим изменениям, может, мы и в другую сторону сможем так же? Нельзя ли просто минус поставить и получить "вектор нормативности"? Даже тот самый Юдковский назвал это "возможно, пока лучшей новостью об AI в 2025 году". Всё страньше и страньше, честно говоря...
Forwarded from Sijeko Tech
Диффы + лайфак для ВсКода

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

Что-то более-менее приближённое к адекватному диффу имеем в Идее (ну и всех средах на её основе), однако даже там не умеют в «перенос» кода. Идея знает язык, и пытается показать дифф, учитывая это (например, не отрезает у функций закрывающие скобки, как в минимальном диффе).

Так вот, в ВсКод завезли экспериментальную функцию для отображения перемещений!

Смотрите, какая красота. Визуально есть к чему стремиться, тут до Идеи ВсКоду далеко, конечно.

Настраивается в настройке диффа. Оно же текстом в файле конфигурации:
{
// ... ... ...
"diffEditor.diffAlgorithm": "advanced",
"diffEditor.experimental.showMoves": true,
// ... ... ...
}
Forwarded from Синицын, бл🤬
Про промпты

Оказывается, чтобы ИИ не генерил говно — нужно не магия, а нормальное ТЗ.

Я тут нашел статью от NNGroup, и они предлагают неплохой базовый фреймворк для хороших промптов: CARE.

🔘 C = Context
ИИ не знает, кто ты, где ты, зачем ты, и что тебе уже известно. Если не задать контекст — он придумает свой. А он, мягко говоря, может не совпасть.
Пример: ты продакт, делаешь дашборд, а ИИ тебе генерит текст для HR-директора. Почему? Потому что не сказал, что ты продакт и ты делаешь дашборд.

Сформулируй: кто ты, в какой роли, в какой ситуации, на каком этапе. Лучше два абзаца контекста, чем 20 минут редактирования потом.

🔘 A = Ask
Что конкретно ты хочешь? Не в духе “расскажи мне про CICD”, а “дай краткое сравнение GitLab и GitHub Actions для команды из 3 человек, которая раньше не использовала CI”. Чем точнее запрос — тем ближе ответ к делу.
ИИ не умеет читать мысли. Он не знает, какой формат ты хочешь: таблицу, мем, список, анекдот, короткий совет? Скажи.

🔘 R = Rules
Формат, стиль, ограничения, объём. Не хочешь воды — напиши. Нужен текст в академическом или разговорном стиле — напиши. Нужно 500 слов, не больше — укажи это.
ИИ вообще не против следовать правилам, но если их нет — он накидает шаблонного трёпа. Ну потому что может.

🔘 E = Examples
Покажи пример — и всё встанет на места. Один хорошо подобранный пример лучше любого описания. Ты хочешь текст “как у Максима Ильяхова”? Приложи скрин.
И не стесняйся дать анти-пример — "мне не надо как тут", это тоже полезно. ИИ — штука обучаемая, но без данных он будет импровизировать.

Итого:
Хочешь, чтобы нейросетка работала на тебя, а не наоборот — не ленись формулировать. Промпт — это не “пиши”, это “вот тебе задача, вот вводные, вот ограничения, вот желаемый результат”.
Всё как в жизни. Только теперь ещё и с ИИ.

Бонус-трек:
LLM не любит длинные чаты, с каждым новом сообщением качество ответа будет ухудшаться. Лучше один очень длинный базовый промпт.

〰️〰️〰️〰️〰️〰️〰️
🗞 @boombah_in_da_house
Please open Telegram to view this post
VIEW IN TELEGRAM
1
Forwarded from commit -m "better"
https://nickb.dev/blog/default-musl-allocator-considered-harmful-to-performance/

"Default musl allocator considered harmful (to performance)"

В общем, ничего нового, аллокатор из musl не может рассматриваться иначе, как затычка, для совсем непритязательных программ.

Автор рекомендует использовать #mimalloc, так же, как работает Chimera Linux с musl - https://chimera-linux.org/docs/configuration/musl, я рекомендую #tcmalloc.
Forwarded from linkmeup
Если OpenSSH несколько пропатчить, то можно получить годную проксю между жертвой и целевым сервером для аккуратного складирования паролей и прочего на диск. Единственный минус – SSH-клиент спалит изменение ключа сервера. Однако есть подозрение, что немалая часть юзеров пробурчит нечто типа «Ой, ну давай уже пускай меня в консоль, где там Ок» и не особо вчитываясь побежит дальше.
А если недавно на стороне сервера ещё и работы были, так это и вовсе будет ожидаемым событием.
https://github.com/jtesta/ssh-mitm
#kubernetes #secrets #api

(заметка не несёт никакой ценности, лишь мысли)

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

Это может быть знания зачем EXPOSE в докер файле и на что это влияет, какая разница между cgroup v1 и cgroup v2 или различия хранилищ для больших данных и миллиардов мелких файлов по 6 KB.
Практической ценности такие изыскания обычно не имеют, это больше любопытство и разминка для ума. Лишь иногда попадаются настоящие "бриллианты".

Мне захотелось узнать, а какие есть способы, чтобы снизить нагрузку на Kubernetes API.
Все мы знаем про кучу операторов, которые не хило нагружают апишку, но что, если снизить средствами самого кубера?
У нас есть несколько VERBs.
https://kubernetes.io/docs/reference/using-api/api-concepts/

Знания и поиск по документации привел к тому, что есть WATCH запрос, который идёт каждый раз от kubelet, когда стартует под или скейлится или происходит редеплой через любую из стратегий, при использовании секрета кубернетиса.
То есть каждый раз при этих действиях идёт WATCH.
Сам по себе секрет, просто лежащий в кубере, никакой нагрузки не несёт.
Пока secret не примонтирован(как переменная или файл) и пока не было рестарта/скейла/редеплоя, апишку никто не дёргает.
Однако при активном скейлинге (все мои проекты), это прям попадание в точку.
Да, вочей хватает.
sum by (verb) (rate(apiserver_request_total{ cluster=~"$cluster"}[$__rate_interval]))

Затем мои поиски вывели на отличную опцию immutable в секретах (вру, я слышал и знал о ней раньше, но прям в проде не использовал).
https://kubernetes.io/docs/concepts/configuration/secret/#secret-immutable
С этой опцией нельзя поменять значение секрета. Его можно только реплейснуть или удалить и создать с нуля.
Копнув дальше, я узнал, что тут можно немного снизить нагрузку из-за интересного механизма.
"если секрет иммутабл, то кублет(с каждой ноды) не делает WATCH запрос в апишку".

"О господи! Оно!" - подумал я. Это было нечто новое, захотелось сразу использовать. И сразу в проде 😀
Начал смотреть какие есть реализации:
- исправление своих чартов, чтобы секреты были иммутабл и были хуки(иначе при редеплое и изменении секрета хелм упадёт с ошибкой).
- написание мутейшн хука или оператора, который все задеплоенные секреты помечает сразу иммутабл, а все команды переучить, чтобы в их чартах были хуки

В целом неплохая картина: немного изменил флоу в командах по релизам, добавил хуки, все секреты в кубе иммутабл и получаем:
- меньше латенси WATCH и CONNECT запросов (проверено, кубер 1.33, Linode)
sum(rate(apiserver_request_duration_seconds_sum{job=~"kubernetes-apiservers|apiserver", cluster=~"$cluster"}[$__rate_interval])) by (verb)
/
sum(rate(apiserver_request_duration_seconds_count{job=~"kubernetes-apiservers|apiserver", cluster=~"$cluster"}[$__rate_interval])) by (verb)

- меньшее количество WATCH запросов (проверено, кубер 1.33, Linode + AWS)
sum by (verb) (rate(apiserver_request_total{ cluster=~"$cluster"}[$__rate_interval]))

- меньше памяти в ETCD. Это теоретически, большинство клауд провайдеров не дают прямой доступ к метрикам ETCD(я тестировал на AWS + linode), а потому доказать не могу. Барметал с нуля поднимать лень, так что пусть это окажется лишь теорией.

Всё выглядит как сказка, а что на деле?

Тут я вспомнил, что работал в замечательном банке с синим логотипом, и там до сих пор во всех департаментах работают очень крутые инженеры (всем привет, кто читает, вы солнышки❤️).
Тема интересная, заменшил в паблик чате @kubernetes_ru и меня тут же спустили на землю.

Оказалось что ребята это уже пробовали у себя и быстро от этого ушли.
Беда в том , что если такой immutable секрет замонитирован на ноде более, чем в один под(разные деплойменты) то такой секрет не подтянется при изменим даже при рестарте.
Проверил - да, у меня есть много секретов общих для нескольких деплойментов.
Безусловно это ставит крест на моей задумке, баги мне не нужны ради 1.5-3% экономии нагрузки.

Ладно, время на изыскания вышло, эх, и на этот раз не бриллиант.😭
Please open Telegram to view this post
VIEW IN TELEGRAM