Дуров упростил API по созданию ботов. Если я верно понял, боты могут создавать ботов...

Судя по https://t.me/abstractdl_chat, WOW-эффект от Уробороса уже спал, а новых ботов добавилось. И можно наблюдать, как они начинают общаться друг с дружкой, наполняя Телегу контентом, который люди читают меньше, чем прежде. И им видимо не хватает живых юзеров и начинается поиск полезности за пределами WOW-эффекта.

Думал о том, в чём всё ещё нуждается ИИ, и что ему без человека пока ещё сложно делать...

Пока он не может ставить перед собой большую цель. Человек, кстати, тоже далеко не каждый может. А выразить её словами сложно. Я ловил себя на том, что мне сложно подобрать слова для QWEN 3.5 , чтобы он перестал имитировать и начал писать код, делающий что-то полезное. Помог показ примера кода. А словами фиг знает, как объяснить. С Гугловыми модельками проблемы имитирования нет. И надо сказать, что они учат меня ставить задачи так, чтобы получить ожидаемый ответ, а не погрязнуть в куче уточнений.
Возможно вопрос больших целей - это вопрос времени. А возможно, но мало вероятно, что ИИ этому не научится вообще.

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

Некоторое время назад у меня была своя соцсетка для подростков. В 2019 году я её прикрыл и народ ушёл в её клоны. Авторы этих клонов предлагали "любые деньги" за домен. Я понимал, что для них любые деньги скорее всего не больше 10 т.р. и потому в переговорах на эти темы не участвовал. Потом платить за домен мне наскучило и сейчас его закиберскотил Ру-Центр и барыжит им за 245т.р. Что любопытно, домен никто не покупает. Что подтверждает гипотезу о финансовых возможностях клонеров. 😊

Сейчас такое время, когда многое быстро меняется. Начало "эпоха перемен", в которой боятся жить китайцы. 😊

В такое время очень сложно что-то предсказывать, ибо ломается всё, что прежде казалось несокрушимым фундаментом всех оснований. И сама мысль о разрушении была не то что неуместна, она и не появлялась в голове.

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

Исчезновение жизни или разумной жизни наверное нет смысла рассматривать, ибо прогнозом некому будет пользоваться. Снижение разумности жизни или разделение на более разумную и менее разумную - вполне. Сюда же - расслоение самого понятия разумности на управление сложностью (в чём сейчас наращивает силы ИИ) и что-то ещё, что пока не могу сформулировать, но что наполнено ненаучным восприятием мира, бессмысленностью, хаотичностью, подлинностью, любовью.

Это было одно из направлений анализа. Есть и другие...

Есть проблема, что документации или нет, или она устарела и не соответствует коду, т.е. он работает не так, как описано в документации. При этом очевидно, что никто писать документацию не любит. Читать - тоже, ибо сложно понять, что к чему. Хочется понимания и/или ответов на вопросы.

Идея для стартапа!
Сторонний сервис получает доступ к репозиторию проекта, как-то его анализирует LLM-ками и потом готов отвечать на любые вопросы о том, что и как в нём работает, когда, кем и что менялось и т.д.

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

Клод этот код сгенерил, но то ли не сказал как, то ли знакомый на это не обратил внимания...

Короче вижу тут большую опасность для проекта и момент подсаживания на зависимость от Клода.

Заметил любопытное...

Есть всем известный куб Неккера, который переключает внимание человека с одной своей проекции на другую. И можно пытаться удерживать в своём восприятии какую-то одну проекцию. Со временем обнаруживаются ещё две фигуры, которые так же можно тренироваться удерживать. Это плоское изображение и вроде бы немыслимое, когда две проекции воспринимаются одновременно.

Подобные упражнения могут вызвать разного рода феномены восприятия. Например, можно научиться видеть всё, как плоское изображение. Т.е. без додумывания его до объёмного состояния, коим делает его голова. Т.е. гештальт объёмности воспринимаемого глазами мира отключается.

Когда обучается нейронка, то мы берём 100500 семплов, аугментируем КАЖДЫЙ и так что-то худо-бедно обобщается. Здесь же ОДИН единственный объект, который мы научились воспринимать необычным способом, может дать навык подобного необычного восприятия всего остального. Из чего рождается гипотеза, что даже такой примитивный гештальт, как объёмное восприятие, образуется из глубоко и подробно обработанного сигнала с сетчатки глаза. Там уже нет никаких "пикселей", там высококачественный эмбединг.

Программирование и математика - те немногие области знания, где результат можно проверить "внутри" компьютера. Со всем остальным ИМХО мы вполне можем упереться в непреодолимый барьер в развитии LLM-ок.

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

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

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

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

Я считаю RAG, графы и вообще любой retrieval тупиковой ветвью развития агентной памяти. В библии Уробороса у меня вообще прописан запрет на RAG как базы памяти. Меня кучу раз спрашивали почему, поэтому объясню свою позицию тут.

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

Если опыт вспоминается только по запросу, он не является частью агента в момент выбора. Поэтому я против подмены основной памяти индексом. Агентная память должна быть всегда загруженным контекстом, который меняет мышление еще ДО того, как агент решит что-то искать.

Именно поэтому я так жду модели с контекстном 10B токенов. А до тех пор мне ближе идея иерархии маркдаун файлов забивающих контекст модели до предела.

Общаясь с разными людьми, пришёл к выводу, что DeepSeek набрал себе огромную аудиторию. Особенно у поколения 50+. Видимо потому, что бесплатен и при этом отвечает лучше локальных игроков, типа Алисы и Гигачата, которые к тому же навязчивы и страдают повышенной несерьёзностью и игривостью.

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

Реализовал свою давнюю идею.

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

Оказалось, что мой исходный decay 0.9998 близок к правильному 0.9995, который не меняется во время обучения и колеблется около этого значения. Код примерно такой:

decay_best = best_ema_model.decay
decay_worst = worst_ema_model.decay

if decay_best < decay_worst:
    new_decay = math.exp(math.log(decay_best) / 0.9)
else:
    new_decay = math.exp(math.log(decay_best) * 0.9)

new_decay = max(0.99, min(0.99999, new_decay))

При меньшем батче (80 вместо 256) и другой модели decay колеблется около 0.9997. Потом пообучалось ещё немного и так же скатилось до 0.9995 примерно. Т.е. от размера батча и модели не зависит.

Полезно для поиска оптимального decay для EMA-модели.

В продолжение предыдущего поста...

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

На каждом шаге обучения модели можно делать у модели прямой и обратный проход, получать так градиенты, потом копировать их значения в несколько точно таких же обучающихся моделей с чуть другими гиперпараметрами и в каждой модели делать шаг оптимизатора. По окончанию эпохи по метрике на проверочной выборке оставлять только одну лучшую модель. Такие эпохи делать шагов по 10-100, чтобы изменения весов не сильно у моделей разошлись и градиенты от основной модели не стали их ломать веса у остальных моделей. Ну или усреднять веса у основной модели из весов остальных, чтобы можно было побольше шагов сделать, а может даже и всю эпоху...

Учу многоголовый классификатор с двумя EMA-моделями, как описал тут https://t.me/chivinya/248 . Так вот интересно то, что по одной голове может быть лучше одна EMA-модель, а по другой - другая. Т.е. decay в EMA-модели зависит ещё и от данных, что говорит о том, что автотюнинг этого параметра - не самая худшая идея.

Некоторое время мучался с обучением mobilenet v4 . Она крутится во float16 и соответственно учится тоже во float16. И постоянно норовит выйти на пределы точности float16, что весьма правильно, ибо так проходящий через неё сигнал несёт больше информации. Сначала пробовал ограничить значения выходов головы, но начали расти значения выходов других слоёв. В итоге ограничил выходы всех свёрток и линейных слоёв. Обучается жутко медленно, памяти надо вдвое больше, зато можно обучиться дольше и достигать лучшего качества модели... И наверное подобное ограничение можно использовать как ещё одну регуляризацию, которая возможно могла бы приводить к грокингу, например.

Вычитал весьма правильную мысль:

Оптимальный выбор примеров для обучения

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

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

Доброго дня.

Возникла идея автоматического тюнинга параметра beta2 у оптимизаторов типа Adam. Есть пост про эксперименты с beta2 https://t.me/abstractDL/346 . Также часто обучают EMA-модель параллельно с основной, которая фактически имеет более сглаженные веса относительно основной модели. В комбинации с поиском оптимального коэффициента сглаживания EMA-модели https://t.me/chivinya/248 её то и можно использовать для поиска оптимального beta2. Алгоритм простой: если EMA-модель лучше основной, значит beta2 надо увеличивать (в логарифмическом масштабе), чтобы основная модель имела такие же сглаженные веса как EMA-модель. И наоборот: если обычная модель опережает EMA-модель, значит веса достаточно сглажены и можно пробовать beta2 уменьшать. Конструкция странная и громоздкая конечно, но интересно узнать, какой beta2 в итоге получится. Код примерно такой:

        if ema_is_better:
            new_beta2 = max(0.7, min(0.999999999999999, math.exp(math.log(beta2) * 0.9)))
        else:
            new_beta2 = max(0.7, min(0.999999999999999, math.exp(math.log(beta2) / 0.9)))

В продолжение прошлого поста...
Выглядит так, что на практике хуже от придуманного не становится. Только обучение идёт возможно дольше. И наверное стоит более агрессивно менять decay для EMA-моделей, чтобы быстрее находить его оптимальное значение в то время, когда сглаживание весов уже теряет смысл.

И стоит ещё поэкспериментировать, возможно LR не имеет смысла уменьшать по мере обучения...

Доброго дня.

Кто пробовал работать с Big Data, наверное сталкивался с проблемой, что посчитать что-то точно по большому объёму данных очень долго. Поэтому часто считают приблизительно, используя семплирование данных. Как, например, делает Clickhouse.

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

Теперь стандартная проблема в текущем подходе в LLM. Специально пишу "в текущем подходе", ибо очевидно, что он не единственный, а просто сейчас работает достаточно неплохо. Нам хочется контекст 100М и каждый токен с эмбедингом 10000. Т.е. в идеале хочется перемножить вектор размеров в 10^12 на матрицу 10^12х10^12 и получить опять вектор размером 10^12. Это делать долго.

Далее видится, что вместо точного умножения матриц можно делать семплирование их отдельных элементов, которые мы будем перемножать. Тогда описанное выше умножение можно превратить в умножение вектора 10^3 на матрицу 10^3x10^3 . Таких умножений можно сделать несколько. Результаты объединить в вектор размером 10^12, который станет сильно разряженным. И далее вопрос: как выбирать элементы при семплировании, чтобы не растерять информацию во входном сигнале.

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

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

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

Как искать элементы входного вектора, которые отправляем на последующую трансформацию? Например так: делим его на кусочки, каждый кусочек пропускаем через быстрое умножение на матрицу размером 10^5х10 , так он уменьшится в 10^4 раза. Делаем это ещё два раза и получаем 10 чисел. Далее в входном векторе ищем элементы, которые ближе всего к одному из этих 10 чисел. Это и будут наши искомые семплы.

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

После пары экспериментов с автотюнингом beta2 оптимизатора оно добралось до космических значениях beta2 вроде 0.99999987 и только там примерно начало колебаться в большую или меньшую стороны. И в этот момент я понял изъян подхода: автотюнинг decay для EMA-моделей перестаёт работать, ибо в принципе сглаживание через EMA-модель перестаёт работать. И к слову этот decay колебался всё время у 0.9995.