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

serde — основной фреймворк для сериализации и десериализации в Rust. Его используют как крейт по умолчанию во всей экосистеме. serde_json — это официальный serde-миксин для JSON, так что каждый раз, когда нужно что-то парсить, люди обращаются именно к нему. Конечно, есть и другие библиотеки, специализующиеся на парсинге JSON, например simd-json, но популярность у них, мягко говоря, удручающая. serde_json значительно популярнее: на момент написания от него зависят аж целых 26916 крейта, а от simd-json — всего 66.

Это делает serde_json хорошей мишенью (не как у Jia Tan) для оптимизаций. Велик шанс того, что многим из тысяч пользователей переход на simd-json позволил бы добиться ускорения, но, пока они этого не делают, более мелкие оптимизации — лучше, чем совсем ничего, и такие улучшения — глобальный выигрыш для экосистемы.

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

Однако же за это время PIS-OS прирос кучей всего, навроде поддержки ещё одного типа экранов, системы меню, а также и функцией будильника — посему понадобились и более мелодичные рингтоны, чем просто пиликание одним тоном.

В процессе выяснилось, что пьезоэлемент был припаян к той ноге МК, на которой ЦАП отсутствует. Впрочем, если бы я хотел будильник, который звучит как mp3 — просто пользовался бы мобильником, так что самое время вспоминать наследие демосцены и делать самый настоящий однобитный драйвер звука!

Наши коллеги из Центра «Сильный искусственный интеллект в промышленности» и Лаборатории композитного ИИ ИТМО разрабатывают открытый фреймворк для разностороннего анализа данных при помощи байесовских сетей. Он пригодится прикладным специалистам, которые сталкиваются с задачами анализа и нуждаются в интерпретируемости используемых моделей. В этой статье рассказываем об идее и о том, кто занимается ее реализацией.

Для борьбы с атаками на уязвимости LLM используются те же методы, что и для согласования моделей. Например, обучение с подкреплением на основе обратной связи от человека (RLHF) используется для производства полезных и безвредных LLM (HH=helpfull, harmless). А поставщиком большинства данных для обучения модели пока все еще является человек. 

Что если саботер попадет в команду разметчиков данных для обучения LLM? Он может внедрить backdoor в модель и таким образом превратить модель в "спящего агента", который только и ждет триггерное слово на вход, чтобы начать наносит повсеместный вред. 

Насколько сильно такой саботер может все поломать? Что конкретно он может наворотить в модели? Каких усилий от саботера это потребует?
Что если такому саботеру на самом деле не обязательно нужно быть внутри процесса обучения, иметь доступ к разметке данных и к процессу обновления весов, а отравить можно открытые данные?

В мире победившего эджайла, SCRUM, как один из наиболее популярных фреймворков, казалось, имеет все шансы стать отраслевым стандартом. Однако в результате врождённых недостатков он стала чем-то средним между религией для занятых проектным управлением и воздухом для продажи эджайл-коучами. Более того, сегодня строгая приверженность принципам SCRUM нередко становится маркером профнепригодности для людей, которые имели неосторожность переродиться из полноценных проектных методологов и руководителей в фанатично зацикленных на ритуалах scrum-мастеров (речь не обо всех, но о об очень многих). В посте попытался обобщить все проблемы SCRUM, как "фреймворка" для проектного управления и создания продуктов.

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

Представьте, что у вас есть друг, который дает разные ответы на один и тот же вопрос в зависимости от того, как вы его задали. «Какая столица Перу?» получит один ответ, а «Лима — столица Перу?» — другой. Вы, вероятно, немного обеспокоены умственными способностями вашего друга, и вам почти наверняка будет трудно доверять его ответам. 

Именно это и происходит со многими большими языковыми моделями (LLM), сверхмощными инструментами машинного обучения, которые поддерживают ChatGPT и другие чудеса искусственного интеллекта. Генеративный вопрос, который является открытым, дает один ответ, а дискриминативный вопрос, который подразумевает необходимость выбора между вариантами, часто дает другой. «Происходит разрыв, когда один и тот же вопрос формулируется по-разному», — сказал Атул Пол Джейкоб, докторант Массачусетского технологического института.

Всем привет. Сегодня я хочу рассказать об использовании WASM с C++ и разберу, как взаимодействовать с этим всем делом через JavaScript.

Материал предназначен для новичков в данной теме.

Мы живем в мире, где системы распознавания лиц (далее — CРЛ) используются практически везде: от валидации возраста и биометрической идентификации в режиме онлайн до наблюдения и проведения оплаты в реальном мире. Технологические аспекты таких алгоритмов развиваются на наших глазах: начиная с простых систем, основанных на базовых алгоритмах, мы перешли к системам, использующим алгоритмы машинного обучения, однако и их развитие еще далеко от завершения.

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

Вадим Мартынов, руководитель команды платформы надёжности в Яндекс Go, в своём докладе рассказал, как влияют те или иные решения на надёжность системы и как это учитывать при разработке.

В статье будет показан прототип системы дел, который реализован в Obsidian. Система в основном будет базироваться на идеях GTD.

Задачи будут создаваться в дневнике/журнале и агрегироваться в отдельных заметках с использованием плагина Tasks.

Система будет адаптирована для телефонов.

Статья написана для продвинутых юзеров Obsidian. Новичкам, конечно, с ней будет тяжеловато разобраться.

Прочитал и посмотрел почти все статьи и видео по Obsidian, которые вышли недавно (в среднем не более 1-2 ух месяцев назад). Дал каждому источнику субъективную оценку и написал короткий комментарий.

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

п.с. Если вы стажер или джун в поиске работы, то недавно мы писали, какую зарплату просить начинающему IT-специалисту на собеседовании. А если вам просто интересно узнать оклады, которые сейчас предлагает IT-рынок — сразу заглядывайте в зарплатный калькулятор. 

«Китайский мудрец, сидя на берегу реки, сетует на расплодившиеся вокруг технологии», — такой текст я вбила в какую-то из многочисленных нейросетей, генерирующих картинки. Судя по всему, вместо расплодившихся вокруг технологий китайский мудрец случайно получил расплодившиеся ноги.

ИИ, с ним такое бывает.

Идея написать данную статью пришла после прочтения статьи Реализация сапёра в 100 строках чистого Ruby. Во-первых, мне показалось, что 100 строк кода многовато для такой простой по механике игры. Я бы мог написать более компактное решение на чистом С. Во-вторых, реализация не совсем корректна: в оригинальной игре нельзя проиграть первым ходом, более того, первая открытая ячейка не должна иметь в соседних ячейках мину.

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

Интересный факт: GPT-4o взимает по 170 токенов за обработку каждого тайла 512x512 , используемого в режиме высокого разрешения. При соотношении примерно 0,75 токенов на слово можно предположить, что картинка стоит примерно 227 слов, что всего в четыре раза меньше, чем в поговорке «картинка стоит тысячи слов».

(Кроме того, взимается 85 токенов за master thumbnail низкого разрешения каждого изображения, а изображения более высокого разрешения разбиваются на множество таких тайлов 512x512, но давайте ограничимся одним тайлом высокого разрешения.)

Но почему же 170? Необычное число, неправда ли? В своих ценах OpenAI указывает округлённые числа, например, $20 или $0,50, а в своих внутренних размерностях — степени двойки и тройки. Почему же в этом случае выбрано число 170?

Числа, которые без объяснений вставляют в кодовую базу, называют в программировании «магическими числами», и 170 кажется очевидным магическим числом.

И почему затраты на изображения вообще преобразуются в стоимость в токенах? Если бы это нужно было только для определения цены, то разве не удобнее было бы просто указать цену за тайл?

Что если OpenAI выбрала 170 не в рамках своей запутанной стратегии ценообразования, а потому что это в буквальном смысле так? Что если тайлы изображений действительно представлены в виде 170 последовательных векторов эмбеддингов? А если это так, то как реализовано?

Мы будем считать 1000,000,000 число Фибоначчи со всеми цифрами. Для этого я буду использовать продвинутый алгоритм для поиска чисел Фибоначчи. Тут не будет базовых алгоритмов на подобии матричного возведения в степень и проще. Но эта статья будет понятна и школьнику :-)

Как всё успевать и не выгореть в хаосе задач? Я прошел путь от работы по найму, где моё время организовывали за меня, до самостоятельного управления множеством проектов. В этой статье я делюсь личными секретами тайм-менеджмента, которые помогают мне оставаться продуктивным и не терять мотивацию.

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

Уже много лет IT компании проводят алгоритмические собеседования при найме технических специалистов. Подход введенный в FAANG плавно перетек в большинство крупных компаний. Яндекс, Авито, Т-Банк и многие другие хотят проверить алгоритмические знания кандидатов. Но на практике такое собеседование оказывается бесполезным созвоном на 45 минут, который ничего не говорит о кандидате.

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

Но очень мало можно встретить критики и конкретного разбора проблем алгоритмических собеседований и их внедрения в воронку найма. Эта статья будет первой в цикле “в чем проблема алгоритмов”.

Кто-то может сказать: “О, человека не приняли в компанию из-за алгоритмов и он решил обидеться и сказать всем, что алгоритмы бесполезны”. Отчасти это так и было, но я решил не останавливаться на своем чувстве несправедливости и пошел дальше: адаптировал алгоритмы в компании, прошел все этапы в Google и даже решал алгоритмы на протяжении года.

Все это помогло мне понять, что многие двигаются не туда, когда решают спрашивать деревья и графы на своих интервью.

Но все это отдельными статьями, ссылки на которые я приложу сюда позже.

Сейчас я просто хочу рассказать свою историю.

"Как будто у Unreal и Unity родился ребёнок" — такое трогательное описание дали этому движку в GameDev-сообществе. Эта фраза не только мило звучит, но и точно передаёт его суть, ведь движок действительно задумывался как нечто среднее между Unity Engine и Unreal Engine.