IT

«Похмельная Мона Лиза» и суд, который решил, что ИИ убивает авторское право Только недавно обсудили, как одну мадам уволили за "слив данных в DeepSeek", как появилось свежее решение Пресненского районного суда Москвы (дело № 02-4220/2025) по ИИ и творческий вклад. Речь о производных работах: «Мона Лиза с вином» и «Статуя Свободы с вином». Дизайнер взял известные изображения, внес изменения с помощью ИИ (бокал вместо факела, растрепанные волосы, мешки под глазами, патчи и т.д.) и назвал результат своими арт-объектами. Предприниматель начал продавать мерч (футболки) с этими изображениями. Дизайнер пошел в суд за компенсацией. И суд ему отказал. Ключевая фраза: изменения внесены с помощью искусственного интеллекта БЕЗ творческого вклада —> поэтому объекты не могут быть самостоятельными объектами авторских прав. Что именно не так с этой логикой? Суд выстроил рассуждение вокруг трех критериев авторского права (база типа): 👉 авторское право есть когда = есть человек (автор), результат выражен в объективной форме и есть творческий фактор. Структура в целом правильная. Проблема - в наполнении и логике суда на мой взгляд. 1. Про «значительную роль» программы Суд написал, что если компьютерная программа играет значительную роль, то творчества нет. В законе такого критерия нет. Пленум Верховного суда прямо говорит: творческий характер не зависит от того, создано произведение собственноручно или с использованием технических средств. Автоматическая камера видеонаблюдения - да, не творчество. Но генеративный ИИ - совсем другая история. Раньше в фотошопе и до ИИ можно было очень сильно что-то преобразить - программа сама по себе НЕ критерий 2. Про «просто механические команды» Суд назвал работу с промптами простыми механическими действиями. Без исследования самих промптов, итераций и того, как именно отбирался результат. В других юрисдикциях суды как раз смотрят на этот процесс детально. 3. Про новизну и уникальность Суд подробно объясняет, что идея «похмельной Моны Лизы» и «Статуи Свободы с бокалом» не нова. Но требование новизны и оригинальности - это критерии патентного права, а не авторского. В авторском праве отсутствие новизны само по себе не лишает охраны. Это тоже прямо написано в разъяснениях Пленума. Суд этот абзац процитировал частично и как будто не заметил. 4. Презумпция творчества Сначала суд ссылается на презумпцию (результаты предполагаются творческими, пока не доказано иное), а потом говорит, что истец сам должен доказать творческую составляющую. Логический кульбит получился красивый - но бестолковый. В итоге Суд фактически приравнял работу с генеративным ИИ к отсутствию творчества. При этом не исследовал, как именно создавались объекты, какие были промпты, сколько итераций, какой вклад вносил человек. Позиция спорная и надеюсь будет изменена вышестоящими инстанциями. А как вы считаете: где проходит граница между «использовал инструмент» и «ИИ все сделал сам»? И должен ли суд вообще требовать доказательств творчества, если есть презумпция?

На Arch удобно учиться, но работать лучше на Ubuntu. По крайней мере, к такому выводу автор пришел спустя год экспериментов. Сначала ему нравилось делать всё своими руками: подключать Wi-Fi через терминал, разбираться с дисками, собирать систему под себя и периодически ее ронять. Так он действительно лучше понял, как устроен Linux. Потом понадобился рабочий софт для FPGA. Vivado официально поддерживает Ubuntu, а на Arch приходится надеяться на патчи сообщества и помнить, что очередное обновление может что-нибудь сломать. В статье еще больше объяснений, почему новичкам хотя бы несколько месяцев нужно пожить с Arch. А еще рассказ, как эксперименты с системой начинают отнимать рабочее время.

Уволен из Amazon Наткнулся в Ютюбе на видео парня, вышедшее позавчера, где он делится тем как его и ешо начальников уволили из Amazon - сам он работал нам 6 лет после ВУЗа - он работал в отделе AGI: там были постоянные перестановки, хаос и "надо делать значительные достижения" - их ЛЛМ "Nova" вообще не могла конкурировать с ChatGPT, Anthropic, Gemini Сократили его, но: - дали 3 месяца трудоустройства (можно не работаеть, просто ЗП получаешь, можно в другие отделы собеседоваться) - за каждые полгода опыта по 1 неделе ЗП дали (6 лет = 12 полугодий => 12 недель ЗП = 3 месяца) - в итоге полугодовая ЗП Я это все читаю, а затем истории кентов слушаю и выглядит конечно бохато. Что касается Amazon, наверное выгоднее Клод по Bedrock перепродавать, чем свое зачем-то пилить. https://www.youtube.com/watch?v=ZAom6f4-vh0

Недавно @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` - можно убрать кучу аллокаций и в итоге вообще не уменьшить размер хипа.

Ну что, второй IT-пикник в моей карьере закончен. Время поделиться результатами: 1. Нетворкинг Самое ценное — познакомиться лично с теми подписчиками, с которыми мы ни разу не виделись IRL, но с которыми мы совместно делали проекты, выступления да и просто с кем завязалось тёплое общение. Дальше могу сказать, что я укрепил свои связи с Т-банком и принял решение подготовить тему, для того, чтобы в следующем году претендовать не только на "съёмку контента", но и на спикерство. 2. Вилки и офферы Может быть я плохо искал, но на стендах практически не было замечено HR и рекрутеров. Сложилось впечатление, что по сотрудникам у всех всё в порядке. Вилок мне никто не сказал, но не по причине того, что не хотели — часто это было связано с отсутствием этого знания. 3. Доклады К сожалению смог послушать только один на тему того, как можно научиться чему угодно. Остальные доклады удалось разве что "урвать" — всё-таки когда ты идёшь делать контент, такие вещи сложно совмещать. Кто был на IT-пикнике ещё? Какие у вас впечатления? Делитесь!

В современной критической теории часто звучит тезис о том, что каждый скролл, клик и лайк в социальных сетях представляет собой «неоплаченный цифровой труд», непосредственно создающий стоимость для техгигантов. Однако Бест в книжке Automatic Fetish, опираясь на понятийный аппарат III тома «Капитала», развенчивает этот миф о «просьюмере», доказывая, что наша онлайн-активность является не создающим стоимость трудом, а скорее «бесплатным даром» сырья. Подобно тому как лес даёт древесину, а гора — руду, не выступая при этом «рабочими» для капитала, наши цифровые следы служат «оприроденным» ресурсом, субстратом, который капитал должен сначала «экстрактировать» с помощью реального наёмного труда, прежде чем тот сможет считаться богатством. Это различие имеет ключевое значение для понимания «физики восприятия» цифровой эпохи. Бест указывает, что для Маркса труд, создающий стоимость, должен совпадать с отношением найма — это труд, выполняемый «по часам» (в рамках рабочего времени). Участвуя в собственном цифровом надзоре, мы не производим прибавочную стоимость; вместо этого мы генерируем «руду», которую затем обрабатывают наёмные инженеры и дата-сайентисты. Именно эти работники и являются настоящими «шахтёрами», которые агрегируют, координируют и превращают наши хаотичные цифровые следы в продаваемые дата-товары, создавая тем самым прибавочную стоимость для своих работодателей. С точки зрения анализа издержек производства в III томе «Капитала», эта аналогия с добычей полезных ископаемых вскрывает скрытый механизм повышения нормы прибыли. Получая наши цифровые следы в качестве изобильного и относительно дешёвого «бесплатного дара», технологические компании получают возможность удерживать свои инвестиции в постоянный капитал ($c$) на более низком уровне, чем это было бы в противном случае. Согласно закону тенденции нормы прибыли к понижению, более низкий объём инвестиций в постоянный капитал обеспечивает более выгодное соотношение факторов, временно подстёгивая способность системы к генерации стоимости. Выкладывая фотографию, мы не подвергаемся эксплуатации как рабочие; напротив, «стоимость», которую мы якобы создаём, — это лишь удешевление входящих элементов сырья, используемых капиталом для максимизации доходности. Бест развивает этот аргумент дальше, переходя к провокационной критике теории «социального мира, превращённого в социальную фабрику». В то время как многие утверждают, будто капитал тайком превратил каждый момент нашего бодрствования в эксплуатируемый труд, Бест подчёркивает: трагедия капитала заключается как раз в том, что он «обречён на провал» в попытках превратить большую часть нашей деятельности в стоимость. В субъектно-объектной инверсии, характерной для фетишизма капитала, мы начинаем воспринимать нашу творческую, жизнеобеспечивающую и коммуникативную активность как труд на капитал, хотя в действительности эта деятельность остаётся по большей части за пределами узких, исключающих условий производства стоимости. Капитал здесь, пожалуй, сам себе создаёт препятствие: он стремится вытеснить живой труд из производственного цикла с помощью автоматизации, однако тем самым уничтожает единственный источник той самой прибавочной стоимости, к которой так жадно стремится. Cамая интересная часть аналогии с добычей руды — это момент, где Бест сопоставляет её с марксовой концепцией «всеобщего интеллекта». Она выдвигает тезис о том, что почти всеобщее участие в цифровой жизни выступает своего рода «бесплатной подготовкой рабочей силы». Технические навыки, которые мы приобретаем добровольно — занимаясь нетворкингом и освоением сложных платформ, — становятся новым базовым стандартом для соискателей. По ироничной диалектической логике, по мере того как население благодаря цифровой активности становится более технически подкованным, стоимость этой рабочей силы на самом деле снижается. Наша «свободная» онлайн-жизнь обесценивает квалификацию: то, что прежде было специализированной цифровой экспертизой, превращается в базовое и низкооплачиваемое требование, позволяя капиталу скупать нашу рабочую силу по бросовым ценам.

KDD’26, день первый. На конференции собралась индустриальная тусовка — приехали ключевые рекомендательные команды из вообще ВСЕХ больших компаний. 1. Сходил на первую половину Tutorial on Generative Recommendation: Foundations and Frontiers от Kuaishou и City University of Hong Kong. Выделили два (будущих?) тренда: * если изначально все использовали encoder-decoder модели для генеративного ретривала, потому что в них было удобно впихивать богатый контекст; то сейчас двигаются в сторону decoder-only моделей, которые лучше скейлятся * диффузионные подходы, при которых мы предсказываем сразу все семантические токены целевого айтема — очень перспективное направление, которое позволяет избавиться от аккумуляции ошибок при авторегрессивной генерации токенов После кофе-брейка я на туториал не вернулся, потому что: * были супер энциклопедические слайды, на которых просто перечислялось много статей по паре минуток каждая, очень поверхностно, без инсайтов, с неточностями * при этом не было живого рассказа - весь текст просто зачитывался. Надеюсь, потом выпустят с этим текстом техрепорт)) Ну а если серьезно, то проще потом слайды полистать, наверняка какие-то инсайты все-таки будут ближе к концу рассказа 2. Пообщались с Федором Борисюком. Когда возле него осталась только наша русская компашка, Федор сам первый перешел на русский язык :) Что рассказывал: * если я все правильно понял, он сейчас руководит тремя командами. Что-то возле поиска и рекомендаций * статьи пишут по выходным. К процессу привлекается большое количество коллег. Федору просто нравится писать статьи и прокачивать репутацию, а у коллег есть мотивация участвовать как минимум чтобы получить грин-карту)) * сам Федор сторонник того, чтобы на работе со всеми уважительно и дружелюбно обращаться, налаживать хорошие отношения. И максимально коллаборироваться, делать совместные проекты. Но говорит, что это иногда приводит к плохим последствиям, во время политических игрищ * у него всегда часть проектов долгосрочные, а часть краткосрочные. Долгосрочным как правило занимается небольшая команда из 2-3 человек. Если проект планируется на год-полтора (больше бизнес вряд ли вытерпит), то расставляются майлстоуны на каждые полгода с оффлайн-метриками * если попался плохой руководитель, то надо просто ротироваться и не мучаться :) * через полтора месяца должен быть дроп крутой новой статьи от Линкедина 3. Воркшоп Two-sided Marketplace Optimization: Search, Discovery, Matching, Pricing & Growth. Было выступление от Director of Research @ Spotify, Paul Bennett — From User Needs to Ecosystem Design: How AI Is Reshaping Discovery. Рассказывал про разные сценарии, в которых применяют LLM: * steerable recommendations — тюнят модель с помощью контрольных токенов выдавать familiar (пользователь уже взаимодействовал с подкастом >10 минут за последний месяц) и unfamiliar (обратная ситуация) контент в рекомендациях. Похоже на мою идею с обуславливанием, про которую рассказывал на Turbo ML Conf 2025 * Intent-aware search — в поиске есть разные сценарии; иногда нужно просто включить рекомендации с какими-то настройками, иногда запустить реальный поиск, иногда просто найти артиста, иногда что-то еще. LLM можно использовать как router, который определяет в какой api (recs/search/etc) нужно отправлять запрос * Conversational discovery — часто пользователь сначала сам не понимает какие ему нужны рекомендации; и только в процессе взаимодействия с рекомендательной системой начинает понимать чего все-таки хочет. И для этого как раз multi-turn диалог, в котором он может и промежуточные рекомендации получить, и пообщаться с рексистемой 4. Что еще: * на конференции 70+ русскоговорящих участников, это очень много. Много людей со статьями, а еще есть студенты с ИИ360 программы. Жутко им завидую, меня бы кто на первом-втором курсе на конференцию отправил! Говорят, что ничего непонятно, но все очень вдохновляет) * все офигевают от джетлага * даже в Линкедине (!) разработчики слушают наш DeepRecsys курс :)