Привет хабр! Новичок в написании статей, но никогда не поздно начать. Объемный гайд по функциям pthreads для людей знающих базы C/C++.

Казалось бы, совсем недавно мир только начал знакомиться с тем, что такое большие языковые модели (LLM). Вскоре после этого появились их многочисленные вариации — на любой вкус и цвет, от узкоспециализированных до универсальных моделей. Затем началась волна интеграций: LLM начали встраивать в различные сервисы, приложения и API, упрощая и автоматизируя рутинные процессы.

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

И вот, компания Anthropic представила решение этой задачи — новый протокол Model Context Protocol (MCP), который стандартизирует взаимодействие агентов с различными сервисами и между собой.

Давайте разберёмся, что такое MCP, и с чем его едят!

Открытая архитектура RISC-V активно развивается: в стандарт добавляются новые расширения и инструкции, разрабатываются новые ядра и SoC. Поскольку многие компании видят перспективы архитектуры и готовы использовать ее в продакшене, создается программный стек для высокопроизводительных вычислений — RISC-V HPC (High Performance Computing). Прогресс сопровождает формирование нового тренда — OpenHPC. Он заключается в технологической независимости от решений коммерческих компаний. Причем это относится не только к ПО, но и к железу. 

Чтобы концепция OpenHPC реализовывалась быстрее, нужно, чтобы к инициативе присоединилось как можно больше компаний, помогающих в развитии экосистемы решений для RISC-V HPC. Меня зовут Андрей Соколов, я инженер-программист в компании YADRO. В R&D-команде мы поставили перед собой задачу: изучить, как можно поддержать архитектуру RISC-V со стороны библиотек линейной алгебры BLAS и LAPACK. Тестирование одной из open source-библиотек привело нас к интересным открытиям, о которых я расскажу под катом. 

Салют, Хабр! На связи Арсенин Никита из команды R&D в SberDevices. Сегодня я хочу рассказать про одно из наших направлений исследований — разработку агентских систем на основе больших языковых моделей.

В этой статье мы постараемся сделать обзорный тур по ключевым технологическим аспектам проектирования и реализации LLM‑агентов, рассмотрим способы работы связок LLM и функций, некоторые компоненты мультиагентных систем, методы контролируемой генерации и повышения робастности. Кроме того, представим и подробно опишем архитектуру и способ построения одного из прототипов LLM‑агентов, нацеленных на выполнение задач в Google SpreadSheets.

Наш LLM‑агент был реализован при помощи SDK GigaChain и GigaGraph, адаптированными под работу с GigaChat. Вы можете посмотреть на итоговую версию Google SpreadSheets агента в репозитории или начать разработку своего агента с вводного туториала.

Всем привет. Я студент 2 курса магистратуры Университета ИТМО факультета «Школа разработки видеоигр». В своей выпускной работе «Анализ и разработка алгоритма Shadow Mapping направленных источников света для систем с несколькими GPU» я перенёс вычисление Cascaded Shadow Maps на вторую видеокарту и получил 40% прироста к производительности.

Привет, Хабр! Вот когда каждый грамм действительно имеет значение: если вам нужно спрогнозировать вес птицы перед продажей, чтобы экономить на кормах и оптимизировать производство. Меня зовут Михаил Чирков, я data scientist в R-Style Softlab и сегодня хочу поделиться с вами кейсом прогнозирования с помощью XGBoost, этот проект мы делали в рамках внедрения BI-системы для птицефабрики. 

Сейчас существенная часть машинного обучения основана на решающих деревьях и их ансамблях, таких как CatBoost и XGBoost, но при этом не все имеют представление о том, как устроены эти алгоритмы "изнутри".

Данный обзор охватывает сразу несколько тем. Мы начнем с устройства решающего дерева и градиентного бустинга, затем подробно поговорим об XGBoost и CatBoost. Среди основных особенностей алгоритма CatBoost:

• Упорядоченное target-кодирование категориальных признаков
• Использование решающих таблиц
• Разделение ветвей по комбинациям признаков
• Упорядоченный бустинг
• Возможность работы с текстовыми признаками
• Возможность обучения на GPU

В конце обзора поговорим о методах интерпретации решающих деревьев (MDI, SHAP) и о выразительной способности решающих деревьев. Удивительно, но ансамбли деревьев ограниченной глубины, в том числе CatBoost, не являются универсальными аппроксиматорами: в данном обзоре приведено собственное исследование этого вопроса с доказательством (и экспериментальным подтверждением) того, что ансамбль деревьев глубины N не способен сколь угодно точно аппроксимировать функцию . Поговорим также о выводах, которые можно из этого сделать.

Попалась мне недавно статья Синус, косинус, квадратный корень FixedPoint. Автор размышляет как можно не затратно рассчитывать координаты и углы в микроконтроллере. Попробовал я подсказать автору пару аппроксимаций, но он оказался разговорчив только на тему "упадка автоматизации в РФ", а по делу как то не сложился диалог. Посмотрел, такие статьи не редкость. Например, очень хорошая статья Как посчитать синус быстрее всех на Xабре. В общем разгрузил себе голову на майских праздниках от главного хобби - геометрической алгебры.

В процессе изучения всего этого, возник у меня вопрос - а зачем вообще нужно аппроксимировать sin,cos, arctan и еще и в привязке к числу в двоичной системе, если есть декартовы координаты?

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

Автоматическим дифференцированием можно назвать любую конечную разность, например dy=(y(x+ε)-y(x-ε))/(2*ε). Разность взята центральная, так как она дает меньшую погрешность.

 ε это машинный ноль. За счет округления до младшего бита его главное свойство: ε^2=0.

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

Продолжаем серию «C++, копаем вглубь». Цель этой серии — рассказать максимально подробно о разных особенностях языка, возможно довольно специальных. Это пятая статья из серии, список предыдущих статей приведен в конце в разделе 6. Серия ориентирована на программистов, имеющих определенный опыт работы на C++. Эта статья посвящена ссылкам и ссылочным типам в C++.

Термин «ссылка» широко используется и в обыденной жизни, в компьютерных и других науках и поэтому его смысл сильно зависит от контекста использования. В языках программирования под ссылкой понимают небольшой объект, главная задача которого обеспечить доступ к другому объекту, расположенному в другом месте, имеющему другой размер и т.д. Объекты ссылки удобно использовать на стеке, они легко копируются, что позволяет получить доступ к объекту, на который эта ссылка ссылается, из разных точек кода. В той или иной форме ссылки поддерживаются во всех языках программирования. В ряде языков программирования, таких как C#, Java, Pyton и многих других, ссылки, по существу, являются концептуальным ядром.

В C роль ссылок играют указатели, но работать с ними не очень удобно и в C++ появилась отдельная сущность — ссылка (reference). В C++11 ссылки получили дальнейшее развитие, появились rvalue-ссылки, универсальные (передаваемые) ссылки, которые играют ключевую роль в реализации семантики перемещения — одном из самых значительных нововведений C++11.

Итак, попробуем рассказать о ссылках в C++ максимально подробно.

Архитектура программного обеспечения — основа, от которой зависят качество, производительность и масштабируемость систем. В статье шаблон от экспертов в области архитектуры программного обеспечения с типовыми описаниями и примерами архитектурных представлений. Шаблон доступен для скачивания.

Привет, Хабр!

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

Каждый, кто работал с большими языковыми моделями (LLM), знает про ограничение длины контекста: модель не может напрямую обработать текст, превышающий определённое число токенов. Это накладывает ограничения на работу с длинными документами и обширным контекстом. Но что если бы мы могли упаковать длинный текст в один-единственный вектор и скормить его модели как обычный токен? Звучит фантастично, однако свежие исследования показывают, что это возможно – такие “mem-векторы” позволяют сохранить сотни и даже полторы тысячи токенов информации в одном эмбеддинге. Это принципиально иной подход, нежели классическое сжатие данных, и он сулит интересные применения.

Mem-вектор (от “memory vector”) – это специально обученный вектор, который хранит содержание целого текста. Идея в том, что если модель умеет предсказывать текст, то можно подобрать такой вектор на входе, при котором замороженная (неизменяемая) LLM сама декодирует исходный текст. Иначе говоря, mem-вектор играет роль «семени», из которого предобученная модель порождает заложенное в нём сообщение. В этой статье разберём, как это работает, почему вообще возможно “запихнуть” роман в один вектор и какие ограничения при этом появляются. Также сравним mem-подход с классическими алгоритмами сжатия (Huffman, арифметическое кодирование, zlib и др.), обсудим последние научные работы на эту тему и возможные применения: от Retrieval-Augmented Generation (RAG) до передачи новых знаний замороженным моделям. Центральная мысль: mem-векторы – это не просто компрессия текста, а способ напрямую скормить модели смысл и знания, минуя последовательное чтение токенов.

Финансы, ритейл, соцсети, облака – везде свои тараканы, но требования схожи: чтобы летало и не падало. Балансировка нагрузки – это как фундамент для небоскреба. Криво зальешь – все рухнет. И вот тут стандартный Round Robin, при всей его простоте, часто оказывается тем самым кривым фундаментом.

Переход от монолита к микросервисной архитектуре приносит гибкость и масштабируемость, но и создает новые сложности. Одна из ключевых проблем –согласованность данных и транзакции. В монолите обычно можно обернуть несколько операций одной ACID-транзакцией: либо все операции выполняются успешно, либо при ошибке происходит полный откат. В мире микросервисов такой прямолинейный подход не работает. Каждый сервис автономен, у каждого своя база данных, и общаются они через сеть. Как результат, гарантировать атомарность и целостность процессов, охватывающих несколько сервисов, непросто. Возникает риск частичных обновлений: одна часть системы изменилась, а другая – нет, что приводит к неконсистентным (несогласованным) состояниям данных.

Чтобы решить эту проблему, разработаны специальные паттерны и протоколы управления распределёнными транзакциями. В этой статье детально рассмотрим ограничения классических ACID-транзакций в распределённой архитектуре, а также два подхода к распределённым транзакциям – сага (SAGA) и двухфазный коммит (2PC). Разберём мотивацию, принципы работы, преимущества и недостатки каждого, сравним их по критериям. Кроме того, обсудим альтернативные подходы, такие как TCC (Try-Confirm-Cancel), паттерн Outbox, а также кратко упомянем eventual consistency, транзакционные сообщения, инструменты вроде Atomikos и др. В завершение – практические рекомендации, как выбрать подходящий способ обеспечения согласованности в ваших микросервисах.

Основной объём трафика в вебе возникает из-за ботов. По большей части, эти боты используются для обнаружения нового контента. Это читалки RSS-фидов, поисковые движки, выполняющие краулинг вашего контента, а сегодня и боты ИИ, собирающие контент, чтобы скармливать его LLM. Но есть и зловредные боты. Их создают спамеры, скрейперы контента и хакеры. На моём прежнем месте работы бот обнаружил уязвимость Wordpress и встроил в наш сервер зловредный скрипт, а затем превратил машину в ботнет, используемый для DDOS. Один из моих первых веб-сайтов был полностью выдавлен из поиска Google из-за ботов, генерирующих спам. Мне нужно было найти способ защиты от этих ботов, поэтому я начал пользоваться zip-бомбами.

В играх ИИ редко играет по правилам. И это — к лучшему. Чтобы союзники казались умными, полезными и не раздражали игрока, а враги — опасными, но не несправедливыми, разработчики нередко идут на хитрость. Компаньоны получают сверхспособности: видеть сквозь стены, становиться невидимыми и стрелять без промаха. А враги — наоборот, «промахиваются» нарочно, действуют медленнее или терпеливо ждут своей очереди атаковать. Всё это — не баги, а продуманные трюки, созданные ради вашего удовольствия. В этой статье я разберу, как устроен такой «жульничающий» ИИ на примерах Ghost Recon: Wildlands, The Last of Us, Batman: Arkham и других игр — и почему без этих уловок мы бы не так любили эти игры.

"JavaScript отстой, потому что '0' == 0!"

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

Вместо этого я хочу поговорить о более странных особенностях JavaScript — о таких, которые гораздо более коварные, чем эта ☝️ - о вещах, которые вы не найдете ни на r/ProgrammerHumor, ни в обычном учебнике по JavaScript.

Все эти странности могут возникнуть в любом окружении JavaScript/ECMAScript (будь то браузер, Node.js и т.д.), с режимом use strict или без него. (А если вы работаете над легаси-проектами без строгого режима, вам следует срочно подумать о смене работодателя).

Некоторые люди предпочитают пользоваться не только облачными сервисами, но и запускать LLM у себя дома. Например, так можно запустить дообученные модели без цензуры, или не посылать в облако свои личные документы. А то и запускать бесчеловечные эксперименты над LLM так, чтобы superintelligence/skynet потом это не припомнил.

Есть много моделей, оптимизированых для быстрой работы на устройствах с небольшой памятью. Но, к сожалению, веса самых продвинутых моделей, которые играют в одной лиге с лучшими онлайн моделями, занимают сотни гигабайт. Например, 8-битные веса Deepseek R1-671B занимают 700 гигабайт, квантованые q4 — 350 гигов. Можно квантовать и в 1 бит, размер тогда будет около 100 гигов, но такая модель почти бесполезна. Еще есть много качественных finetunes на основе Mistral-Large-instruct-130B, Qwen2.5-72B, llama3.3-70B, веса которых также не помещаются в память старших моделей видеокарт.