Удивительно часто попадаются статьи/посты "вопросы для собеседований по [ваш язык программирования]", где задается вопрос "что выведет программа", а дальше дается некая лапша из запутанного кода, смачно сдобренного особенностями языка, которые используются раз в 100 лет при полной луне, когда Марс в доме Меркурия.

Имхо это даже разбирать не надо - правильный ответ на собесе должен быть один: не превращайте код в грёбаную головоломку

По мотивам прослушивания одного подкаста :)

Мысли про AI агентов

Представим себе такую картину: владельцам шоколадной фабрики предложили сделать эксперимент — заменить взрослых сотрудников детьми. В общем, семилеткам дали "порулить" конфетной фабрикой на день. Одного поставили следить за конвейром, второй теперь начальник отдела, следит за первым, командует ему, что делать. Третий — упаковкой занимается. Четвертый — заведующий складом, катается на транспортировщике поддонов. А во главе всего этого стоит самый умный из них, 9-летний, который формирует стратегию развития. Вопрос: через какое время фабрика "встанет колом"? Как мне кажется, достаточно быстро. Захотят ли владельцы повторить эксперимент? Есть сомнение.

Вот примерно насколько же я не разделяю оптимизма людей про AI агентов и их внедрения в реальный бизнес. Рано ещё.

Удивительно, насколько футурологи красочно описывают истории про то, как скоро можно будет "нанимать" приложения, иметь автономных помощников, а вместо фриланс-бирж появятся маркетплейсы агентов и вы сможете объединить их в сеть, и вот они работают за вас, программируют, автоматизируют документооборот, а вы спокойно можете полететь на Бали делать ретрит.
Венчур до сих пор под эти истории отсыпает приличное количество монет, вероятно, в надежде, что ребята должны рано или поздно сделать что-то прорывное, а они будут стоять у истоков этой истории и выйдут из этих историй со множителем "охулион"!
Cтартаперы тоже не против за чужой счёт поэкспериментировать. И вот как будто бы на этих взаимных ожиданиях и "синергии" история про агентов и качается.

При этом можно достаточно быстро стать неприятным собеседником, просто попросив показать реальные кейсы внедрения AI агентов в бизнесе. В последний раз, когда я так сделал, мне прислали кучу ссылок на технологии и агенские фреймворки. Но кейсов внедрения я не увидел. Знаю один, что-то из web3 и мира крипты, где боты создают свои токены и монеты. Но это всё про мешок фантиков, и я от этого далёк. А реально, где бы автономная система заменила человека, и чтобы эта история стала масштабируемой в нескольких компаниях — такого я не слышал.

С финансовой точки зрения агентские решения — это доменная печь токенов (и денег), в них сгорают миллионы в попытке спланировать действия, выполнить их, а затем проверить, что результат хотя бы немного подходящий по качеству. Даже по публичным исследованиям, всё ещё дешевле нанять команду из Индии или Пакистана, чем оплачивать токены AI агентов.

С технической — это оверкил, потому что иногда запилить RPA решение в виде простого скрипта, преобразующего неструктурированные данные в структурированные, а затем отдать человеку на ревью и дальнейшую обработку, в сто раз эффективнее и быстрее, чем пытаться сделать все с помощью агентов. Я за то, чтобы 80% всей рутины может сделать AI ассистент, 20% важных проверок — человек. И планировать пока у человека получается значительно лучше. Несколько месяцев назад я рискнул потестить AutoGen от Microsoft. Оно у меня забуксовало на первой же простой задаче из примеров.

В общем, про AI агентов у меня стакан наполовину пуст. Проверим, что будет через год. Может что-то прорывное ;-)

📊  Оверимплоймент: что это? Примите участие в новом исследовании от NEWHR и получите инсайты рынка

Вы сотрудник и совмещаете несколько мест работы? Или пока только задумываетесь о поиске подработки и взвешиваете «за» и «против»? А может, никогда не смотрели в эту сторону? Или вы — работодатель, который сталкивается с феноменом оверимплоймента среди своих сотрудников? А может, не сталкивались или не знаете наверняка, совмещают ли ваши сотрудники? Расскажите нам о своем опыте и/или отношении к вопросу!

Предмет нового исследования — оверипмлоймент, он же совмещение нескольких работ, он же вторичная занятость, — яркий макро-тренд последних нескольких лет на рынке, распространённый не только в IT.

В рамках исследования узнаем:

- насколько распространены подработки в отрасли и в каких компаниях более, а в каких — менее?
- как к подработкам относятся работодатели? какие видят риски и, напротив, какие это дает им преимущества? и что перевешивает?
- в чём мотивация сотрудников, которые совмещают 2-3 работы? только ли в деньгах дело, и в чем может быть ещё?
- действительно ли запрет на удалёнку и принудительное посещение офиса снижает вероятность совмещений?
- можно ли остановить это явление? а главное — нужно ли?

👉🏻 Пройти опрос 👈🏻

Результаты исследования опубликуем в начале 2025 года.

🎁 Для всех, кто поучаствует в опросе:

- мы сделаем специальный расширенный материал с глубинным исследованием по вашей профессии: эти материалы получат только респонденты исследования
- предоставим возможность узнать результаты первыми
- проведем закрытый эфир с инсайтами исследования и возможностью задать любые вопросы экспертам NEWHR

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

👉 Расскажите о вашем отношении к совмещению работ и/или поделитесь этим постом с теми, кому может быть интересна эта тема. Опрос займет не больше 6 минут.

Знакомые попросили продвинуть опрос ☝️

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

Не забывайте, что писать неэффективные программы - значит наносить вред окружающей среде

https://pythonspeed.com/articles/co2-emissions-software/

Переписывайте, короче, всё на C и Раст с ваших питонов, а то Грета придёт за вами

Google выпустила новое API для Protocol Buffers в Go

Команда Go представила новое API для работы с Protocol Buffers, получившее название Opaque API. Это важное обновление, которое должно сделать работу с protobuf более эффективной и безопасной.

До сих пор в Go использовалось так называемое Open Struct API, где все поля структур были доступны напрямую. Например, так:

go 
type LogEntry struct {
  BackendServer *string
  RequestSize   *uint32
  IPAddress     *string
}

С новым Opaque API все поля становятся приватными, а доступ к ним осуществляется через методы:

type LogEntry struct {
  xxx_hidden_BackendServer *string
  xxx_hidden_RequestSize   uint32
  xxx_hidden_IPAddress    *string
  // …внутренние поля опущены
}

// Доступ через методы
func (l *LogEntry) GetBackendServer() string
func (l *LogEntry) HasBackendServer() bool
func (l *LogEntry) SetBackendServer(string)
func (l *LogEntry) ClearBackendServer()
//...

Зачем это сделано?

Новый подход значительно экономит память. Вместо использования указателей для хранения информации о наличии значения в поле (presence), теперь используются битовые поля. В некоторых случаях это позволяет сократить количество аллокаций памяти почти на 60%. (речь идет про элементарные типы, такие как целые числа, булевы и т.д)

Появилась возможность реализовать ленивое декодирование сообщений. Теперь вложенные сообщения декодируются только при первом обращении к ним, а не при общей десериализации. Для некоторых приложений это дает колоссальный прирост производительности и уменьшает аллокации

Новое API предотвращает некоторые ошибки. Например, раньше было легко случайно сравнить указатели вместо значений при работе с enum:

/*
message LogEntry {
  enum DeviceType {
    DESKTOP = 0;
    MOBILE = 1;
    VR = 2;
  };
  DeviceType device_type = 1;
}
*/

// Неправильно и незаметно:
if cv.DeviceType == logpb.LogEntry_DESKTOP.Enum()

// Правильно:
if cv.GetDeviceType() == logpb.LogEntry_DESKTOP

С новым API такая ошибка просто невозможна, так как прямого доступа к полям нет.

Еще одно улучшение касается работы с reflection. Раньше разработчики могли случайно использовать стандартный пакет reflect вместо специального protobuf-reflection, что приводило к неожиданным результатам. Теперь такие ошибки исключены.

Google предлагает постепенный путь миграции через "гибридное" API, которое поддерживает оба способа работы. Для новых проектов рекомендуется сразу использовать Opaque API. В 2024 году оно станет стандартным подходом в новой версии Protocol Buffers (Edition 2024).
Старое API никуда не исчезнет – принцип обратной совместимости.

Для перехода на новое API Google предоставляет инструмент open2opaque, который помогает автоматически переписывать код. Внутри самого Google большинство protobuf-файлов уже переведено на новое API, и оно активно используется на проде.

подробнее здесь

Алхимия промпт-инжиниринга

Если рассматривать GenAI решения с точки зрения детерминизма результатов (а именно стабильности результатов нам и хочется в большинстве случаев), то
1) В общем случае детерминизм в LLM/LVM не достижим.
2) Всегда стоит рассматривать промпт и языковую модель как одно целое.

Про недетерминизм:

100% точности и воспроизводимости результатов инференса не будет даже при нулевой температуре, фиксированном seed параметре и других рандомных параметрах ввиду особенностей работы GPU вычислений (операции с плавающей точкой и квантизации). Тем не менее, обеспечить точность в три девятки можно. А это уже что-то.

Про систему "промпт + модель":

Prompt Engineering — это алхимия. А LLM — "черный ящик". С этим важно свыкнуться, особенно если вы любите one-shot prompting для принятия сложных логических решений внутри одного запроса. Одно небольшое изменение в промпте или изменение модели (даже простой переход с неквантизованной на квантизованную версию) приводит к тому, что отлаженная функциональность перестаёт работать и нужно начинать всё сначала. А уж если использовать облачные версии типа ChatGPT и Claude, то там вообще под капотом целые подсистемы роутеров и всяких "улучшайзеров ваших промптов", после которых даже сами разработчики этих решений, скорее всего, не угадают, какой будет результат. И они постоянно что-то в этих подсистемах подкручивают.

Какие выводы я сделал к текущему моменту для себя:

🔹 Выбор языковой модели для прода — это как выбор жены. Тестить как можно на большем кол-ве моделей до релиза, а в релиз выбирать и фиксироваться на какой-то конкретной, лучшей. На ней и "жениться" ;) Потом поменять уже сложнее.

🔹 Облачным моделям доверять нельзя, они имеют неприятное свойство меняться, ухудшаться. Кажется, что каждый новый релиз ChatGPT должен быть только лучше, но для конкретных задач может оказаться совсем наоборот. Например, в одном моём решении gpt-4 (которая уже почти на пенсии) работает в плане генерации кода по инструкции значительно лучше gpt-4o-2024-11-20. Значит ли это, что модели становятся в целом хуже? Нет. Но мне не нужно "в целом", мне нужно решать конкретные задачи.

🔹 Принимать решения или делать обработку нужно как можно больше в коде, и как можно меньше в LLM. Если есть возможность что-то сделать без LLM, нужно делать без LLM, так достигается детерминизм. Если вытаскиваются ключевые сущности: максимально очистите данные до LLM, и всякие операции сортировки, ранжирования, нормализации делайте уже в python, а модели оставьте только работу с неструктурированными данными. У меня есть решение по отслеживанию трендов, там вытаскивают определенные классы тегов, имен компаний и продуктов из текста. Эти сущности извлекаются как получится, а нормализуются по словарю уже в коде, потому что модель это делает плохо.

🔹 Большой и сложный промпт — скорее зло. Простой промпт позволяет мигрировать между моделями без особой деградации качества. А сложный промпт приколочен гвоздями к конкретной модели, для которой писался и тестился. Эффективнее делать мелкие, несложные запросы.

🔹 У меня лучше работает серия простых промптов + объединение результатов в коде, чем один огромный промпт со всеми агрегациями и принятиями финальных решений внутри LLM. Такой большой и сложный промпт невозможно дебажить. Внутри что-то "решилось", а вы гадаете, почему. Папример, как один абзац инструкций повлиял на другой абзац. Меняете что-то вверху, а оно аффектит то, что внизу. Получается этакая игра Wack-A-Mole (из рандомных дырок вылазит крот, а вы ему по голове стучите молотком).

🔹 Structured Output — не панацея. Иногда он делает хуже вывод или дороже решение. Например, я никогда не использую его в задачах генерации кода или там, где нужны "плоские" одноуровневые тексты, или где нужно обрабатывать большой массив данных. В последнем случае это просто экономически не выгодно. При большом числе запросов оцените, насколько увеличивается число токенов в OpenAI либе при structured output и сделайте вывод (можно включить logger.DEBUG и увидеть это в консоли). А ещё json универсальнее Pydantic.

Конец.

Если раньше у ИИ были галлюцинации, то теперь еще и раздвоение личности

https://habr.com/ru/companies/bothub/news/870510/

TLDR: некоторые модели возможно обучаются на текстах, сгенерированных chatGPT, поэтому результат получается с закидонами

5 минуууут 5 минууут

Количество новых вопросов в месяц на StackOverflow сократилось в три с лишним раза с момента появления ChatGPT

Даже не знаю, хорошо это или плохо )

https://gist.github.com/hopeseekr/f522e380e35745bd5bdc3269a9f0b132

В одном подкасте слышал такое мнение, что мол любой http-эндпоинт - это лишь функция, которая условно принимает на вход заголовки и json, а выдаёт другие заголовки и json. Поэтому функциональное программирование (речь была про Clojure) максимально подходит для таких задач.

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

Блин, http-запрос обычно еще порождает запись в базу. А иногда несколько чтений и записей в базу/редис/кафку, там чистыми функциями и не пахло. Например, перевод денег с одного счета на другой с проверкой на наличие средств. Полно побочных эффектов. Да, я знаю про монады и прочие обёртки для эффектов, но по факту это то же самое, что и обычный императивный код, только сложнее читать.

Говорят, что ФП удобнее тестировать, но в чём удобство? Побочные эффекты тестировать также сложно. Можно конечно вынести какую-то логику в отдельные чистые функции и тестировать их без моков. Но основная сложность всё равно в правильной последовательности операций с базой (с учетом параллельных запросов), а это никуда не денется. В итоге тестировать придётся также с моками, только код станет сложнее из-за попыток отделить чистое от нечистого.

А еще много раз видел, даже без Кложи, как вместо одного тупого цикла с двумя понятными ифами строят целый пайплайн из map и прочих функций

// Допустим, у нас есть массив заказов и надо посчитать сумму всех 
// валидных заказов со скидкой больше 20%

// Императивный подход - простой и понятный:
function calculateTotalSimple(orders: Order[]): number {
  let total = 0;

  for (const order of orders) {
    if (order.status === 'valid' && order.discount > 20) {
      total += order.amount;
    }
  }

  return total;
}

// "Функциональный" подход - попытка сделать "красиво":
const calculateTotal = (orders: Order[]): number => 
  orders
    .filter(order => order.status === 'valid')
    .filter(({discount}) => discount > 20)
    .map(({amount}) => amount)
    .reduce((acc, amount) => acc + amount, 0);

// Или еще "круче":
const isValid = (order: Order): boolean => order.status === 'valid';
const hasHighDiscount = (order: Order): boolean => order.discount > 20;
const getAmount = (order: Order): number => order.amount;
const sum = (a: number, b: number): number => a + b;

const calculateTotalFP = (orders: Order[]): number => 
  pipe(
    orders,
    filter(isValid),
    filter(hasHighDiscount),
    map(getAmount),
    reduce(sum, 0)
  );

🌐 HTTP QUERY: новый метод для поисковых запросов

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

Можно использовать GET и передавать всё в URL:

GET /feed?q=foo&limit=10&sort=-published&filters[]=status:active&filters[]=type:post

Но URL дефакто имеет ограничения по длине, а кодирование сложных параметров становится громоздким.

Второй вариант — использовать POST и передавать параметры в теле запроса. Однако POST не предназначен для таких операций: он не кэшируется и не является идемпотентным, что усложняет работу с CDN и повторную отправку запросов.

Именно поэтому появился новый метод QUERY. Он позволяет отправлять поисковые параметры в теле запроса:

QUERY /feed
Content-Type: application/json

{
  "q": "foo",
  "limit": 10,
  "sort": "-published",
  "filters": ["status:active", "type:post"]
}

При этом QUERY сохраняет все преимущества GET: он безопасный, идемпотентный и кэшируемый. Cочетает поддержку тела запроса с возможностью кэширования.

Метод официально получил статус PROPOSED STANDARD, что означает скорое появление поддержки в браузерах и веб-фреймворках.

RFC: https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/

В опросе JetBrains за 2024 год видно, что Go теперь используется бОльшим количеством людей, чем PHP!
Вопрос был "Which programming languages have you used in the last 12 months?"

Кроме того, Go и Rust - языки, которые у людей в планах на изучение. 10% и 11% соответственно. Для сравнения, Python только 6%.

Я думал, что Go уже устаканился и занял свою нишу, но нет, он прёт как на дрожжах