Про промпты

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

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

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

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

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

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

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

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

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

〰️〰️〰️〰️〰️〰️〰️
🗞 @boombah_in_da_house

#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% экономии нагрузки.

Ладно, время на изыскания вышло, эх, и на этот раз не бриллиант.😭