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

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

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

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 уже устаканился и занял свою нишу, но нет, он прёт как на дрожжах