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 году". Всё страньше и страньше, честно говоря...
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
Оказывается, чтобы ИИ не генерил говно — нужно не магия, а нормальное ТЗ.
Я тут нашел статью от NNGroup, и они предлагают неплохой базовый фреймворк для хороших промптов: CARE.
ИИ не знает, кто ты, где ты, зачем ты, и что тебе уже известно. Если не задать контекст — он придумает свой. А он, мягко говоря, может не совпасть.
Пример: ты продакт, делаешь дашборд, а ИИ тебе генерит текст для HR-директора. Почему? Потому что не сказал, что ты продакт и ты делаешь дашборд.
Сформулируй: кто ты, в какой роли, в какой ситуации, на каком этапе. Лучше два абзаца контекста, чем 20 минут редактирования потом.
Что конкретно ты хочешь? Не в духе “расскажи мне про CICD”, а “дай краткое сравнение GitLab и GitHub Actions для команды из 3 человек, которая раньше не использовала CI”. Чем точнее запрос — тем ближе ответ к делу.
ИИ не умеет читать мысли. Он не знает, какой формат ты хочешь: таблицу, мем, список, анекдот, короткий совет? Скажи.
Формат, стиль, ограничения, объём. Не хочешь воды — напиши. Нужен текст в академическом или разговорном стиле — напиши. Нужно 500 слов, не больше — укажи это.
ИИ вообще не против следовать правилам, но если их нет — он накидает шаблонного трёпа. Ну потому что может.
Покажи пример — и всё встанет на места. Один хорошо подобранный пример лучше любого описания. Ты хочешь текст “как у Максима Ильяхова”? Приложи скрин.
И не стесняйся дать анти-пример — "мне не надо как тут", это тоже полезно. ИИ — штука обучаемая, но без данных он будет импровизировать.
Итого:
Хочешь, чтобы нейросетка работала на тебя, а не наоборот — не ленись формулировать. Промпт — это не “пиши”, это “вот тебе задача, вот вводные, вот ограничения, вот желаемый результат”.
Всё как в жизни. Только теперь ещё и с ИИ.
Бонус-трек:
LLM не любит длинные чаты, с каждым новом сообщением качество ответа будет ухудшаться. Лучше один очень длинный базовый промпт.
〰️〰️〰️〰️〰️〰️〰️
🗞 @boombah_in_da_house
Please open Telegram to view this post
VIEW IN TELEGRAM
Nielsen Norman Group
CARE: Structure for Crafting AI Prompts
To get better results from generative-AI chatbots, write CAREful prompts. Include context, what you’re asking the system to do, rules for how to do it, and examples of what you want.
❤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.
"Default musl allocator considered harmful (to performance)"
В общем, ничего нового, аллокатор из musl не может рассматриваться иначе, как затычка, для совсем непритязательных программ.
Автор рекомендует использовать #mimalloc, так же, как работает Chimera Linux с musl - https://chimera-linux.org/docs/configuration/musl, я рекомендую #tcmalloc.
nickb.dev
Default musl allocator considered harmful (to performance)
In a real world benchmark, the default musl allocator caused a 7x slowdown compared to other allocators. I recommend all Rust projects immediately swap to a different allocator in a musl environment.
Forwarded from linkmeup
Если OpenSSH несколько пропатчить, то можно получить годную проксю между жертвой и целевым сервером для аккуратного складирования паролей и прочего на диск. Единственный минус – SSH-клиент спалит изменение ключа сервера. Однако есть подозрение, что немалая часть юзеров пробурчит нечто типа «Ой, ну давай уже пускай меня в консоль, где там Ок» и не особо вчитываясь побежит дальше.
А если недавно на стороне сервера ещё и работы были, так это и вовсе будет ожидаемым событием.
https://github.com/jtesta/ssh-mitm
А если недавно на стороне сервера ещё и работы были, так это и вовсе будет ожидаемым событием.
https://github.com/jtesta/ssh-mitm
GitHub
GitHub - jtesta/ssh-mitm: SSH man-in-the-middle tool
SSH man-in-the-middle tool. Contribute to jtesta/ssh-mitm development by creating an account on GitHub.
Forwarded from linkmeup
И ещё одна статья по базовой базе, но не субд, а docker.
Тут что выделяет на фоне бесконечного набора статей со схожей идеей, так это уровень проработки вопроса. Тут чтиво не на один вечер.
https://habr.com/ru/articles/935178/
Тут что выделяет на фоне бесконечного набора статей со схожей идеей, так это уровень проработки вопроса. Тут чтиво не на один вечер.
https://habr.com/ru/articles/935178/
Хабр
Docker изнутри: исчерпывающее руководство. Механизмы контейнеризации + примеры, эксперименты и реализация
Практические примеры Ссылки на репозитории с примерами: Containy – реализация контейнерной утилиты на языке Golang Namespaces example – лёгкий пример работы пространств имён на C++ Всё это будет...
👍1
Forwarded from Make. Build. Break. Reflect.
#kubernetes #secrets #api
(заметка не несёт никакой ценности, лишь мысли)
Иногда, для самого себя, я провожу теоретические, вперемешку с практическими, изыскания.
Выбираю узкопрофильную тему и ковыряю, пока не дохожу до кишков.
Это может быть знания зачем
Практической ценности такие изыскания обычно не имеют, это больше любопытство и разминка для ума. Лишь иногда попадаются настоящие "бриллианты".
Мне захотелось узнать, а какие есть способы, чтобы снизить нагрузку на Kubernetes API.
Все мы знаем про кучу операторов, которые не хило нагружают апишку, но что, если снизить средствами самого кубера?
У нас есть несколько
https://kubernetes.io/docs/reference/using-api/api-concepts/
Знания и поиск по документации привел к тому, что есть
То есть каждый раз при этих действиях идёт
Сам по себе секрет, просто лежащий в кубере, никакой нагрузки не несёт.
Пока secret не примонтирован(как переменная или файл) и пока не было рестарта/скейла/редеплоя, апишку никто не дёргает.
Однако при активном скейлинге (все мои проекты), это прям попадание в точку.
Да, вочей хватает.
Затем мои поиски вывели на отличную опцию
https://kubernetes.io/docs/concepts/configuration/secret/#secret-immutable
С этой опцией нельзя поменять значение секрета. Его можно только реплейснуть или удалить и создать с нуля.
Копнув дальше, я узнал, что тут можно немного снизить нагрузку из-за интересного механизма.
"О господи! Оно!" - подумал я. Это было нечто новое, захотелось сразу использовать. И сразу в проде😀
Начал смотреть какие есть реализации:
- исправление своих чартов, чтобы секреты были иммутабл и были хуки(иначе при редеплое и изменении секрета хелм упадёт с ошибкой).
- написание мутейшн хука или оператора, который все задеплоенные секреты помечает сразу иммутабл, а все команды переучить, чтобы в их чартах были хуки
В целом неплохая картина: немного изменил флоу в командах по релизам, добавил хуки, все секреты в кубе иммутабл и получаем:
- меньше латенси WATCH и CONNECT запросов (проверено, кубер 1.33, Linode)
- меньшее количество WATCH запросов (проверено, кубер 1.33, Linode + AWS)
- меньше памяти в ETCD. Это теоретически, большинство клауд провайдеров не дают прямой доступ к метрикам ETCD(я тестировал на AWS + linode), а потому доказать не могу. Барметал с нуля поднимать лень, так что пусть это окажется лишь теорией.
Всё выглядит как сказка, а что на деле?
Тут я вспомнил, что работал в замечательном банке с синим логотипом, и там до сих пор во всех департаментах работают очень крутые инженеры (всем привет, кто читает, вы солнышки❤️).
Тема интересная, заменшил в паблик чате @kubernetes_ru и меня тут же спустили на землю.
Оказалось что ребята это уже пробовали у себя и быстро от этого ушли.
Беда в том , что если такой
Проверил - да, у меня есть много секретов общих для нескольких деплойментов.
Безусловно это ставит крест на моей задумке, баги мне не нужны ради 1.5-3% экономии нагрузки.
Ладно, время на изыскания вышло, эх, и на этот раз не бриллиант.😭
(заметка не несёт никакой ценности, лишь мысли)
Иногда, для самого себя, я провожу теоретические, вперемешку с практическими, изыскания.
Выбираю узкопрофильную тему и ковыряю, пока не дохожу до кишков.
Это может быть знания зачем
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