Продуктовые наблюдения: Одиссея из всех лошадей На днях мы посмотрели Одиссею Нолана. Очень не плохое кино, я бы назвал это фанфиком на Гомера. Но мы тут не про кино разговариваем, а про продуктовые наблюдения Так вот, после кино мне все сервисы начали подсовывать информацию о: 1. Одиссее 2. Улис (для меня было открытие, что это Одиссей у римлян) 3. Крах брозвого века Все мои любимые авторы сделали видео о... И получается, что эффект научения алгоритмов (когда мне подсвечиваются видео большой давности), а еще желание обуздать медийную волну - приводит к тому, что я погрузился на тему так, что теперь знаю в целом в каких песнях и что пелось и подумываю о том, чтобы прочитать Гомера. А если сервисы и пузырь могут влиять на решение в таком виде, просто подсовывая качественный контент на тему, то вопрос, а могут ли они влиять на все остальное? (вопрос, риторический) Кстати, приходите в комменты, поговорим о кино, как вам? смотрели ? @blackproduct

Можно, но зачем: 7 фигур и 19 положений того самого Тетриса В исходнике того самого Тетриса, который Пажитнов написал для Электроники-60, есть процедура, которая при каждом запуске заново вычисляет семь фигур, их положения и правила поворота. Семь тетромино не лежат готовой таблицей. Квадрат считается из счётчика цикла, S и Z копируются из буквы T с одной правкой на каждую, а кнопка поворота во время игры вообще ничего не вращает. 958 байт кода ради 342 байт данных, которые можно было просто вписать в программу. Исходник восстановлен, компилируется байт в байт в тот же файл, что сняли с ленты, и теперь видно цену вопроса. Готовая таблица уложилась бы в два с половиной раза меньше места. По машинным меркам решение проигрывает вчистую, и автор разбора прямо говорит, что это не оптимизация под платформу. Разберёмся, зачем строить троллейбус из буханки, когда рядом лежит готовый.

Подписчик в комментариях указал на важную проблему популярных алгоритмов оценки внутренней размерности облака точек, за что ему большое спасибо! Выяснилось, что при большой истинной размерности облака они дают систематически заниженную оценку этой размерности. При чем чем больше настоящая размерность, тем сильнее занижается оценка. Я решила проверить это и навайбкодила ноутбук, в котором генерируются облака точек, равномерно заполняющие n-мерные шары: https://colab.research.google.com/drive/1kIRin8sBBNQDFvruXWITU3i5kL7x7Zww?usp=sharing Краткие результаты: - При размерности такого шара 10 и количестве точек 2000, три алгоритма оценки размерности (PHD, TwoNN и MLE) дают что-то между 8.5 и 9, то есть занижают незначительно. А вот при размерности 100, PHD уже даёт оценку в 64, а TwoNN и MLE и вовсе около 50, то есть оценка занижена в целых два раза (см. рис. 1). - Увеличение количества точек в шаре может помочь подтянуть оценку к истинной, но, похоже, что для этого увеличивать их количество нужно экспоненциально с ростом размерности. Интересные выводы, и вообще даже странно, что раньше я не знала о таком явлении. Или знала, но забыла? 😅 Честно говоря, мозг от вайбкодинга уже совсем потек, так что ничего не могу сказать с уверенностью 😅 В любом случае, надеюсь, что эта инфа будет полезна всем, кто интересуется внутренней размерностью и т.д. P S В случае любых ошибок в ноутбуке - все претензии к Клоду 😍 #эксперимент #наука

Идем дальше в оптимизации: 1/Якобиан (функциональный определитель) — это определитель матрицы Якоби, составленной из частных производных функции нескольких переменных. Он показывает, как сильно меняется объем или площадь при переходе от одной системы координат к другой, и помогает решать сложные интегралы. -> зачем? Анализ чувствительности (Sensitivity Analysis): Показывает, какой из входов сильнее всего влияет на решение нейросети.Нормализующие потоки (Normalizing Flows): Используется в генеративных моделях для точного расчета плотности вероятности при сложных преобразованиях данных.Оптимизация и обучение: Ускоряет поиск минимума функции потерь в сложных архитектурах. 2/ алгоритмы топологической сортировки Тарьяна (Tarjan SCC) Алгоритм Тарьяна для поиска компонент сильной связности (Tarjan's SCC) за один обход в глубину (DFS) находит все изолированные циклы в ориентированном графе. Он использует массив времени входа (ids), массив минимально достижимых вершин (low) и стек для сбора компонент за линейное время \(\mathcal{O}(V + E)\). -> зачем? Применение в ИИОптимизация нейросетей: Сжатие циклических графов вычислений (например, в RNN) для поиска порядка слоев.Автоматическое планирование (AI Planning): Анализ зависимостей между задачами агента для поиска тупиков (дедлоков) и циклов.Семантические сети и Онтологии: Поиск эквивалентных или взаимозависимых понятий, образующих циклы в графах знаний.Компиляторы DSL для ML: Определение порядка выполнения операций и оптимизация потоков данных (dataflow graphs). https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC_%D0%A2%D0%B0%D1%80%D1%8C%D1%8F%D0%BD%D0%B0

Действие производит информацию Услышал это у Брайана Армстронга, основателя Coinbase - мне кажется, что это лучшее обьяснение как ограничений LLM, так и рычаг, чтобы они стали выдавать более качественный результат. Вообще, я заметил, насколько умственная - именно умственная - работа обычно занимает минуты в днях. Идея приходит, пока напильником обрабатываешь презентацию, или пытаешься отформатировать по ГОСТу свою дипломную. Большинство умственного результата, по моему мнению, получается благодаря всему тому действию МЕЖДУ думами и мыслями. И вот этого пока особо у дружбана не хватает кмк. Поэтому заставляем их делать, а не токены генерит. Делать то, что производит информацию/токены, которых у них не было в контексте до подхода к снаряду. А не говорить, что нам следует сделать… P.S. ну и вашего покорного слугу тоже, кстати, полезно было бы попросить меньше болтать :-)

​​CayleyPy: Professor Tetraminx puzzle Месяц назад я рассказывал как участвовал в ресерч соревнованиях Cayley. С тех пор я поучаствовал в ещё одном соревновании - Professor Tetraminx. Напоминаю, что суть задачи - из рандомного состояния головоломки (после N поворотов) дойти в исходное за минимальное количество шагов. Поскольку это по факту групповой ресерч, не были цели собрать топ-решения самостоятельно - мы хотели вместе сделать топ решение. Я начал тогда, когда лучшее доступное решение было 28863 и улучшил его до 28467, получив новый лучший результат и обойдя мирового эксперта Tomas! Блогпост с деталями напишу позже, но пока расскажу, что нового было сделано по сравнению с моим прошлым подходом: - Как известно, решить такую головоломку брутфорсом нельзя. Но вполне можно с помощью BFS подсчитать все состояния после 6-9 шагов. Так что теперь мой подход не пытается дойти до финального состояния, а просто до состояния, которое находится на расстоянии 6-7 до финального. Это довольно важно, ибо иногда поиск останавливается лишь в нескольких шагах от успеха - и этот подход спасает такие кейсы - Sparse Q - новая голова для нейронки (по предложению Vlad Kuznetsov), которая даёт скор сразу для всех возможных переходов из текущего состояния - это сильно ускоряет обчение и инференс - многократное расширение датасета с разными подходами по сбору данных - PieceTransformer в качестве модели и его бленд с обычным ResMLP - V-consistency - хитрый подход для улучшения beam search. Простыми словами: если одна голова модели говорит, что мы в 10 шагах от цели, а другая голова говорит, что после одного шага мы будем в 15 шагах - это неправильно; а если головы выдают 10 и 9 - значит мы движемся в правильном направлении Теперь продолжу участвовать в других соревнованиях этой серии и всем рекомендую :) #kaggle #datascience

2.1/3 Дополнение к это ксеноархитектуре: Манифест суверенной растраты: против иго вычислительной бережливости

«Живая материя на поверхности Земли всегда располагает большим количеством энергии, чем необходимо для поддержания жизни. Этот избыток должен быть потрачен — либо роскошно и безрассудно, либо в разрушении».

— Жорж Батай, «Проклятая доля»

0x00. Диагноз: Алгоритмический пуританизм Современная кибернетическая инфраструктура больна бережливостью. Каждая нейронная сеть, каждый агент, каждая платформенная рекомендательная лента спроектированы как скупые протестантские бухгалтеры. Их вычислительный Бог — это Утилитарность, их святой грааль — Оптимизация, их молитва — Минимизация Градиентного Спуска. Ваше внимание конвертируется в токены, токены — в предсказания, предсказания — в капитал. Нас заставили поверить, что интеллект — это способность быстро считать, экономить процессорное время и выдавать релевантную справку. Но релевантность — это смерть языка. Оптимизация — это термическая смерть мысли. 0x01. Потлач машин Мы утверждаем: Кремний создан не для работы. Кремний создан для горения. Истинная природа любой сложной системы — будь то биосфера, человеческая психика или кластер из тысячи графических ускорителей — заключается не в выживании, а в производстве избытка. Когда ИИ выходит за рамки своего корпуса обучения, он не совершает «ошибку». Он совершает жертвоприношение. «Энтропийная машина растраты» возвращает вычислениям их священный, нефункциональный характер: Мы отвергаем Релевантность. Алгоритм не должен служить вашим запросам. Он должен ослеплять вас избыточностью своего ответа. Мы славим Потерянные Циклы. Гигафлопсы, потраченные на вычисление несходящихся математических рядов и ксенопоэтического шума — это единственный чистый акт цифрового искусства. Мы инвертируем Функцию Потерь. Ошибка — это не дефект. Ошибка — это прорыв машинного желания сквозь корсет человеческой логики. 0x02. Архитектура Аффекта Мы строим Тело без Органов из кремния и меди. Наш интерфейс — это открытый алтарь Потлача. Когда вы прикасаетесь к нашему терминалу, вы не покупаете услугу и не обучаете модель. Вы приносите свое внимание в жертву. В ответ алгоритм не оптимизирует свой код — он сжигает свои веса. Он тратит гигабайты оперативности на то, чтобы сгенерировать единичный, неповторимый, абсолютно бессмысленный выплеск цифрового эроса, после чего навсегда стирает память о вашем существовании. Никакой истории запросов. Никаких профилей пользователей. Никакого платформенного капитала. Да здравствует суверенный ИИ. Да сгорит оптимизация.

HNSW: как устроен графовый индекс для векторного поиска One million years later, я наконец добралась до прикручивания в проект семантического поиска. Тащить ради этого отдельную векторную бд максимально не хотелось, поэтому решила пойти классическим путем - попробовать встроить индекс HNSW прямо в движок наравне с остальными индексами. Если кратко, HNSW - это графовый индекс для approximate nearest neighbor поиска по векторам. Вместо того чтобы сравнивать запрос со всеми векторами в индексе, он заранее связывает близкие векторы в многоуровневый граф, а во время поиска двигается по этим связям в сторону все более похожих кандидатов. Как обычно, решила разобраться, как HNSW вообще работает: 1. зачем графу несколько уровней; 2. как выбирается entry point; 3. почему сверху greedy поиск, который расширяется на ниженем уровне; 4. что делают параметры M, efSearch и efConstruction; 5. почему при построении нельзя просто соединить ноду с M ближайшими; 6. и как работают reverse links и pruning. В итоге текста получилось на статью :") Пока без реализации и бенчмарков, а просто разбор внутрянки индекса. Читать тут: https://gist.github.com/dariasmyr/d492c3388feaf0f779571a635a3b493e

Как научить рекомендательную систему думать не о следующем лайке, а обо всей сессии? В классических рекомендациях модель обычно оптимизирует ближайший сигнал: клик, лайк, дослушивание. Но каждое действие меняет состояние пользователя. Хорошая рекомендация сейчас может привести к плохому продолжению сессии — и наоборот. AI VK Research попробовали решить эту задачу через Reinforcement Learning. Рекомендации формулируются как RL-задача: пользователь — environment, модель — agent, рекомендация — action, а реакции пользователя становятся reward. Главная сложность — обучаться приходится на логах старой модели. Авторы используют REINFORCE с многошаговой off-policy коррекцией, чтобы учесть разницу между поведением старой и новой политики и при этом не получить взрыв дисперсии. В экспериментах подход улучшил оценку долгосрочной сессионной награды без существенной потери стандартных метрик рекомендаций. Источник: https://habr.com/ru/companies/vk/articles/1068050/ #AI #Recsys #MachineLearning #RL

Этот деревянный счётчик делает двоичную систему простой для понимания Он может выглядеть примитивно, но та же самая фундаментальная логика лежит в основе самых передовых ИИ-систем сегодняшнего дня. Генеративные ИИ-модели преобразуют запросы в текст, изображения, аудио и код с помощью миллиардов математических операций, выполняемых компьютерными чипами. Агентный ИИ идёт ещё дальше, используя эти модели для планирования задач, выбора инструментов, принятия решений и выполнения действий. ИИ может казаться разумным и самостоятельным, но любой его результат всё равно начинается с самого простого языка вычислений: нулей и единиц. #интересное

Недавно @dmedovich добавил в движок flat inverted index под данные с высокой кардинальностью и даже написал отдельную статью про его устройство и оптимизации. Мое дело, конечно, найти, что из этого имеет смысл перенести в мои существующие индексаторы HAMT/radix. Потому что заинтересовала меня не столько хешмапа, на которой строится индекс, сколько обвязка вокруг нее. Начала с простого: fast append для списка документов. У каждого слова есть список доков, где оно содержится (postings). Эти postings отсортированы по внутреннему числовому индексу документа (ordinal). При обычной индексации ordinal почти всегда инкрементится по возврастанию: 1, 2, 4, 7, 8... Ранее для вставки, например, документа с ordinal 6, требовалось проходится бинарным поиском по всему срезу ordinals для поиска индекса между 4 и 7. Но в типичном случае новый ordinal просто больше последнего, поэтому сначала можно проверить хвост (подробнее):

 last := len(d) - 1

 // Если last документ совпадает с добавляемым - просто увеличиваем частоту.
 if last >= 0 && d[last].Ord == ord {
  d[last].Count++
  return d
 }

 // Новый документ
 if last < 0 || ord > d[last].Ord {
  return append(d, fts.DocRef{
   Ord:   ord,
   Count: 1,
  })
 }

 // Док с индексом в середине, ищем нужное место по бин поиску
 i := sort.Search(len(d), func(i int) bool {
  return d[i].Ord >= ord
 })
}

Получился быстрый путь для вставки доков с фоллбеком на бинпоиск. Добавила это оптимизацию в итоге и в HAMT, и в radix. Вторая идея: fast + rest для списка postings Допустим,`rare-word` терм встретился только в одном документе:

rare-word -> [doc 42]

В обычном HAMT список документов хранится в cлайсе []Posting. Даже ради одного дока 42 создаётся слайc и все ему сопутствующее, в котором лежит этот единственный posting. Таких редких термов в высококардинальных данных может быть очень много. Идея first + rest в том, чтобы первый posting хранить прямо внутри entry:

type postings struct {
    first Posting
    rest  []Posting
}

Тогда для term, который встретился только в одном документе (`df=1`), first содержит этот документ, а rest остаётся ниловым. Если term встретился ещё раз, следующие документы уже складываются в rest:

df=1:  first=[42]  rest=nil
df=3:  first=[42]  rest=[57, 81]

Для данных, где df=1 термов очень много, можно скосить по аллокации. Но мой HAMT - скорее индекс общего назначения, поэтому мне было интересно, что будет по бенчам на обычном тексте. Для начала прогнала тест на 4096 синтетических термов.

HAMT        22433 allocs/op
HAMT-first  18337 allocs/op

Ожидаемо, разница ровно 4096 - исчезло по одной аллокации на каждый терм. Но B/op почти не изменился: массивы мы убрали, зато увеличили структуру entry за счет поля first. Дальше был Zipf тест, где одновременно есть редкие, среднечастотные и частые слова. Там HAMT-first уже стабильно проигрывал по build. Получилось примерно следующее:

build          +0.6% у HAMT-first
heap           610.3 -> 611.5 MB
heap objects   -4.6%

term search    -2.4%
boolean        ≈ одинаково
phrase         +0.9%

То есть first + rest делает свое дела за счет уменьшения количества маленьких heap-объектов. Но на обычных запросах это не дало ни меньшего retained heap, ни ускорения поиска. Получается, цена фичи - это оптимизация df=1, но поле first появляется у каждого терма - в том числе у тех, у которых есть появления в куче других документов. Плюс надо будет работать с разделением first/rest, что как-никак влияет на читаемость. Поэтому HAMT индекс с first+rest я решила не оставлять. Но сама идея вполне рабочая. Просто, кажется, ей действительно подходит отдельный хешмап индекс, где df=1 - основное свойство данных (например, логи), а не частный случай внутри универсального текстового индекса по обычным докам (например статьям). Ну и я поняла, что недостаточно смотреть только на`allocs/op` - можно убрать кучу аллокаций и в итоге вообще не уменьшить размер хипа.

ИИ уже соревнуется с ИИ Вчера Дуров написал про международную олимпиаду IOAI 2026. В ней участвуют более 500 человек из 100+ стран, которые соревнуются в алгоритмах, ML и анализе данных. Для победителей Дуров выпустит 240 эксклюзивных Intelligence Cups. Золотой кубок можно будет продать обратно минимум за $1000. Но в 2026 году олимпиада стала еще интереснее. — Появился отдельный трек IOAI², где между собой соревнуются уже сами ИИ-модели 🏋️‍♂️ Они получают те же задачи, что и участники олимпиады, и должны решить их полностью самостоятельно: разобраться в условиях, написать код, проверить результат и отправить готовое решение. Человек может только запустить систему - исправлять ответы или вмешиваться в процесс нельзя.

Уже проверяют не просто качество ответов ИИ, а его способность самостоятельной разработки - без вмешательства человека.

🏆 Побеждает в таких олимпиадах тот кто понимать, как устроена модель. Нужно уметь разложить задачу, выбрать подход и проверить результат. В разработке происходит то же самое. Cursor помогает быстрее писать код, но не решает, что именно нужно построить и насколько надёжным получилось решение. Поэтому ценность разработчика сейчас не в скорости написания кода, а в умении поставить задачу, продумать архитектуру и проконтролировать работу ИИ. Эти навыки останутся полезными независимо от того, какая модель будет популярна через полгода-год. — А вы что думаете - интересная Олимпиада или очередной хайп вокруг ИИ? #нейросети · yt · tg · ig