Result machine

Пытаюсь сделать адаптер-постпроцессор для Llama 3.1 8b. Задумка простая: взять датасет, сделать forward ламы, положить в свой отдельный датасет эмбеддинги с её выхода, а в качестве таргетов положить токены. А потом отдельно обучить LM-head. И получится некая замена lora - тоже дообучение нейронки, но более легковесное. На llama 3.2 1B это в целом работало - да, 1B туповатая, поэтому ощутимо более умные диалоги не вышли, но оффлайн-метрики стали выше. И я пробую это для Llama 3.1 8B. Для начала я беру отдельно её LM-head и пытаюсь дообучить. Получаю совершенно мозговыносной результат. loss падает, и метрика тоже падает! Чем лучше становится loss, тем хуже метрика! В качестве loss я использовал кроссэнтропию (это стандартно для обучения LLM), в качества метрики - accuracy, то есть долю верно отгаданных токенов. Формально это не очень хорошая метрика для LLM, но на в моих экспериментах она крайне сильно коррелировала с субъективным "качеством генерации". И CE, и accuracy я рассчитывал на обучающей выборке, то есть речь о переобучении не идёт, на одних и тех же данных оптимизатор устойчиво, систематически, многократно подтверждённо улучшал loss, но портил метрику. При том, что для llama 3.2 1B это не так, там метрика и loss скоррелированы. Больше того, я попробовал другие метрики - MSE и... Несколько рукописных. Они все оказались скоррелированы друг с другом, но не с accuracy. Да, если инвертировать loss, то метрика тоже падала. И при дальнейшем обучении падение метрики вело к ухудшению генерации. То есть. При обучении Llama 3.1 8B ("unsloth/Meta-Llama-3.1-8B-Instruct-bnb-4bit") использовался оптимизатор, который каким-то образом задрал точность в высокие величины, при этом получив одновременно очень плохой CE (~10-11, если рассчитывать по каждому токену отдельно и усреднять, когда адекватный для LLM loss - ~2-2.5). И эта область эффективного accuracy оказалась очень узкой, большинство шагов из неё - это ухудшения. Если будет интересно, могу скинуть пример данных и веса

Делаем LLM с постпроцессингом! https://telegra.ph/Delaem-LLM-s-postprocessingom-01-08 Технология, альтернативная LoRA, со своими плюсами и минусами

Некоторые закономерности в ML. Теория, можно, сказать, и полученная эмпирически https://habr.com/ru/articles/873110/

Продолжаем историю с постпроцессором для LLM. https://telegra.ph/Posprocessing-dlinnye-dialogi-01-19 Проверяем технологию на устойчивость на длинных диалогах, а так же смотрим, какие вообще есть закономерности. Если вкратце: можно модифицировать выход модели сильнее, чем с помощью Lora, можно получить больше креативности, но стабильность будет ниже. Для больше стабильности нужно что-то ещё. А, и эта версия модели умеет решать задачу про собаку и сковородку)

Немного рассуждений про авторегрессионные модели (ну типа GPT). И про синтетические данные. В какой-то момент в этой своей истории с постпроцессингом (кстати, он теперь называется tail embedding adapter, потому что слово постпроцессор слишком многозначное) я столкнулся с проблемой. Низкая кроссэнтропия и высокая accuracy вообще не гарантируют хорошее качество генерации! Модель может повторяться, путать факты, выдавать бессвязные предложения... Переобучение, подумал я! Но нет, если проверяться на отложенной выборке, то видно, что модель не переобучена. У меня было несколько гипотез разной степени бредовости и проверяемости, и вот под конец я нашёл вроде-как-работающее решение. Итак, гипотезы: 1) Критически важно, чтобы модель была именно трансформером, а не гибридом трансформера с резнетом. Это выглядело очень странно - мне всегда казалось, что трансформер лучше табличной модели в том, что обобщающая способность лучше. А высокая обобщающая способность == высокая метрика на отложенной выборке. И метрика как раз-таки хорошая. 2) У меня нерепрезентативный датасет. То есть я спрашиваю LLM не о том, что было в примерах, я слишком далеко отхожу от "изученной" области. И выглядит, что это действительно влияло. 3) У меня просто мало данных! И да, это повлияло, но это не фундаментальное решение - в каких-то областях всегда будет недостаточно насыщенная "сетка" данных. 4) Метрика accuracy вместе с CE-loss недостаточно характеризуют качество генерации. И... Это выглядит фундаментальной проблемой. Что не всегда улучшение accuracy означает лучшие ответы на вопросы. Итак, лучше всего я выехал на пункте 4. У нас нет нормальной метрики и нормального loss для длинной генерации? 88% точность прогноза токена даёт бред через 10 токенов? Решение элементарное: RLHF. Просто надо наиболее типичные ошибки добавлять как анти-примеры, и это здорово улучшило ситуацию. В чём тут фундаментальность? В том, что я осознаю, что accuracy = 88% означает, что у второго токена accuracy уже 77%, а у тре

Итак, скидываю код Tail Embedding Adapter, плюс обученные адаптеры, плюс примеры датасетов (ну мелкие и лёгкие) https://github.com/Kilorad/tea

Итак, делаем новую версию TEA. На этот раз сделали более классическое обучение - претрейн + файнтюн. И в датасете на этот раз было огромное число статей с arxiv, так что модель немного в курсе последних открытий хотя бы в ML, а немного ещё и в физике и в инженерных науках. Ну и привожу примеры того, как новая модель проходит какие тесты. Сразу обозначу выводы, чтобы по ссылке с тестами прошли только желающие. 1) Лучше понимает некоторые инструкции 2) Несколько более конкретно и подробно 3) Тексты генерируются довольно гладко и складно. Раньше с этим были проблемы! Ну и в целом вывод. TEA всё-таки куда лучше подходит для изменения стилистики, словарного запаса, лучшего следования инструкциям, чем для внедрения новых знаний в модель. Но идея "писать более конкретно и подробно" - это тоже, как ни странно, стилистика. Как и идея "вначале рассуждать, а потом писать" / "писать коротко и по делу" Я показываю не все результаты тестирования, а те, где было значимое различие в выдаче, плюс постарался не слишком повторяться. Отчёт о тестировании: https://telegra.ph/TEA-F-version-02-26 Ссылка на модель: https://disk.yandex.ru/d/LPN_-ft4woaVdQ Как интегрировать модель в свой код: model_name = "unsloth/Meta-Llama-3.1-8B-Instruct-bnb-4bit" path2model = "ern_model_F_composed.pth" model = AutoModelForCausalLM.from_pretrained( model_name, quantization_config=bnb_config, cache_dir="D:\cache\huggingface\\"+ model_name) head_complex = torch.load(path2model, weights_only=False) head_complex.by_submodels = False model.lm_head = head_complex model.lm_head.half() model.to(device)

Выпустил новую версию TEA https://github.com/Kilorad/tea/blob/main/README.md (прошлые заметки по этой теме: https://t.me/result_machine/137 https://t.me/result_machine/139 https://t.me/result_machine/141) Во-первых, если брать эмбеддинг и "докручивать" его до более правильного токена - это может быть недостаточно. В какой-то момент мы выходим на плато по loss, а можно бы выйти на плато получше. Поэтому нововведение первое: slider. Это некая штука, которая берёт несколько эмбеддингов, преобразует в один и пихает в адаптер. Сейчас это реализовано как 1-мерная конволюционная сеть, но ничто не мешает использовать вообще не нейронку, а, скажем, скользящее среднее. Во-вторых, метод generate в LLM так устроен, что он не позволяет LM-head принимать на вход больше одного эмбеддинга. А влезть внутрь generate крайне непросто - это код, раскиданный по безумному числу абстракций в огромном числе папок. Разбираться в нём - примерно как разбираться в весах LLM. Поэтому я написал свой generate - он лежит в generate_utils. Он работает медленнее, чем "родной" generate, но позволяет спекулятивную генерацию. То есть вы можете заставить LLM за один шаг сгенерить не один токен, а несколько, а на следующем шаге генерации все их проверить на адекватность. Если часть токенов окажется адекватными - они останутся, и получится, что LLM за один forward изготовила больше одного токена, то есть провела инференс быстрее обычного. Да, и можно специально обучать модель так, чтобы она с бОльшей вероятностью была адекватна при генерации нескольких токенов одновременно. Да, спекулятивная генерация у меня работает для любых LLM, не только с TEA. Во всяком случае, она отдебажена для Ламы. В общем, пробуйте, всё есть в примерах. Код сыроват, может, найдёте какие-то баги - но он простой, баги будет вычистить легко

https://github.com/Kilorad/bash_agent Очередной Tool-агент, на этот раз мой. Насколько я понял, есть две школы строительства tool-агентов: 1) Есть куча апи, агенты умеют к ним обращаться, апи дают инфу сразу в удобном виде. Плюс - дёшево и удобно, минус - обычно апи узкоспециализированные. 2) Есть 1-2-3 апи, но такие такие инструменты, через которые можно выразить примерно что угодно. Баш, питон и так далее. Плюс - универсально, минус - долго, опасно и требовательно к мозгам модельки. Вот я пошёл вторым путём. Если кому интересно - welcome Да, и это очень далеко от продовой разработки, я просто делюсь своей утилиткой, поэтому она может выглядеть несколько странно (одни зависимости от самописной либы chat_bots чего стоят) Зато эта штука умеет выполнять команды вроде "нарисуй где мерцающий градиентный квадрат" или "какой у меня вендор оперативной памяти". В теории я хотел, чтобы этот агент умел решать задачи вроде "поставь мне unsloth на винду (прорубившись через тучи ошибок)", но на это мозгов агента пока не хватает

Претрейн и файнтюн, а так же проблема переобучения. Типичный пайплайн обучения LLM такой: 1) вначале проводим претрейн на огромном датасете, в основном из "плоских", неразмеченных текстов. 2) затем файнтюн на instruct-задаче, то есть на парах вопрос-ответ Второй пункт может дополняться ещё и RL, но в данном случае я не буду их разделять - будем считать, что примеры из instruct-датасета равнозначны примерам из replay-buffer у RL, с положительной наградой. Что мне в этом не нравится? То, что процесс файнтюна плохо подходит для lifelong-обучения. Если мы будет тюнить сетку слишком долго, мы её переобучим. При этом если мы будет долго тюнить ту же сетку на претрейн задаче... Наверное, есть шанс переобучения, но лично у меня, при обучении адаптеров, этого не происходило никогда. Слишком большая разница между размером датасета и размером модели. Для меня идеалом было бы некое обучение, которое можно проводить, получать новые семплы от RL, проводить дальше, получать новые семплы от дипсика, учить дальше, и продолжать этот процесс потенциально бесконечно, без скатывания в оверфит. Я вижу, что сейчас основной способ решения этой проблемы - выстраивание регуляризации на базе KL-дивергенции между исходной моделью и зафайнтюненной. Эта регуляризация по крайней мере замедлит скатывание в оверфит. Но... Для меня идеальная ситуация - когда датасет детерминирует модель. То есть когда продолжительное обучение приводит к тому, что модель находится в "равновесии" с датасетом, её обучение выглядит как колебания вокруг оптимума, и переобучения не происходит. Не нуно ловить момент, когда останавливать обучение - оно само остановится, так как модель уже скатилась в некий оптимум по loss, и он нас устраивает. В общем, я это реализую просто - подмешиваю pretrain датасет в датасет для finetune. Из минусов - обучение идёт медленнее. Из плюсов - модель меньше оверфитится. В какой пропорции смешивать? Выглядит, что 140 к 1 (140 instruct задач на одну задачу прогноза книжек/статей) - это малов

Итак, наконец-то я довёл до результата TEA-2 Ссылка на репозиторий https://github.com/Kilorad/tea/ Прошлые части этой истории: https://t.me/result_machine/137 https://t.me/result_machine/139 https://t.me/result_machine/141 https://t.me/result_machine/145 Итак, что у нас на этот раз? Я обещал сделать sequential адаптер, но так пока его и не сделал. В смысле код-то есть, но модель недостаточно хороша. А вот классический TEA получился неплохой и под много задач Ссылка на модель https://disk.yandex.ru/d/Dy0y9i0Xn4c1Ww На чём на этот раз учились и чего добивались? 1) Наука/инженерия. Адаптер предобучен на куче научных и инженерных статей и в какой-то мере в них ориентируется. 2) Работа tool агентом. То есть работа в условиях, когда нужно заранее неизвестное число взаимодействий с терминалом/поисковиком/памятью, а так же нужно чёткое следование инструкциям. Здесь датасет чисто RL-ный, то есть от фактического взаимодействия со средой. 3) Рассуждения. Тут частично RL, частично рассуждения от DeepSeek 4) Медицина. Модель была в том числе адаптирована под медицинские диалоги 5) Улучшение речи на русском. 6) Улучшение детализации: модель должна отвечать более конкретно и менее расплывчато А теперь результаты тестирования. Сравнительный анализ ответов TEA и оригинальной модели: https://disk.yandex.ru/d/SsvYnTp5ubdfTA Если кратко: немного лучше следование инструкциям, лучше подробность и детализация. Медицинские диалоги: https://telegra.ph/Medicinskie-dialogi-s-TEA-06-17 Если кратко: довольно адекватно. Учитывая, что для Llama-3.1 русский язык не родной, здесь русский достаточно хорош. Хотя я бы его чуть доработал. Тестирование в тактической игре (игра рукописная, игрок - LLM. Тест на рассуждения и следование инструкциям): https://telegra.ph/Testirovanie-TEA-v-takticheskoj-igre-06-17 Это ограниченный тест, но... Победа. Qwen 2.5, в том числе дистиллят Дипсика, побеждает редко, Llama 3.1 вообще никогда Вывод: Получилась детализация и качество русского получше, чем у ориг

Наверное, надо рассказать, чё вообще происходит. А происходит следующее: я тестирую кучу идей на тему того, как лучше и быстрее обучать LLM. Мне нравится подход TEA во многом потому, что его можно провернуть на не слишком мощном оборудовании, и адаптер будет иметь константную сложность (потому что ни аттеншена там нет, ни рекуррентности). То есть некий идеал - это модель, где трансформерная часть имеет, условно, 8 миллиардов параметров, а адаптер имеет ещё миллиардов 10, и оно вместе работает по качеству как 14-миллиардная чисто трансформерная моделька, зато может прожевать последовательности такой длины, где 14-миллиарная подавилась бы. Текущие наблюдения: - с sequential слоем перед адаптером (концепция TEA-2) качество получше, но не радикально, а вот скорость что на обучении, что инференсе, страдает серьёзно - адаптер сам по себе исполняется быстро, но при превышении накоторого размера (в моём случае где-то 3 миллиарда параметров) он начинает дико лагать, взрывное падение скорости на инференсе - если сделать адаптер mixture of experts, то его можно сделать больше (почти до 4 миллиардов) без серьёзных лагов, и он быстрее обучается (в смысле loss быстрее падает). Он и переобучается быстрее тоже, поэтому надо сильнее позаботиться об аугментации данных - я сильно расширил датасет, поэтому у меня выросли требования к качество на широких доменах, поэтому новые адаптеры пока не выкладываю, ввиду их недостаточной шикарности - экспертами в MOE (либо же всем адаптером) у меня является конкатенационный resnet. Это как multilayer perseptron, но выходы всех слоёв конкатенируются, а потом через линейный слой подаются на выход. Вообще-то выход большой - там словарь 128 тыщ токенов. Поэтому если у нас суммарно на всех слоях 10 тысяч нейронов, то это уже 1.28 миллиарда связей. Я подумал: жирно. Надо сделать боттлнек - узенький линейный слой между конкатенацией сигналов со слоёв и выходом. Он напрочь убивает обучаемость. Видимо, если мы хотим, чтобы модель быстро училась, надо вес

Занесу сюда это теоретическое рассуждение. "Для важных переговоров". Отвечает на вопрос "с чего вы взяли, что RL - это AGI", с теоремами. Да, я использовал DeepSeek в написании, но не чтобы он всё написал за меня, а чтобы я просто привёл общую логику, а он корректно разложил по теоремам. https://telegra.ph/Pochemu-RL---ehto-AGI-08-23 Постарался так же осветить и практические вопросы, вроде "почему всё равно нам RL недостаточно, и где этой теории недостаточно прагматичному разработчику"

NTM Надо было в какой-то момент выложить свою NTM - neural turing machine. https://github.com/Kilorad/ntm_bench.git Вообще, так-то технология древняя. Это RNN с аттеншеном. Но я её чутка улучшил и протестил. Если трансформер логически является дифференцируемым словарём (внимание = взятие по ключу), то NTM логически - дифференцируемый массив (внимание = взятие по индексу) Тестирую на алгоритмическом бенчмарке - создаю рандомные алгоритмы и подбираю их трансформером и двумя разными NTM. Бенчмарк игрушечный, но NTM-слой настоящий. Вот метрики: Final Test Results: Transformer: CE 0.6312, Acc 0.6831 NTM Positional: CE 0.4982, Acc 0.6904 NTM Hybrid Content: CE 0.4967, Acc 0.6918 Я пробовал разные настройки генерации алгоритмов, в большинстве случаев на тесте NTM лучше трансформера. А началось всё смешно - трепался с Grok, показал ему свой код NTM, а тот взял и фиганул тестовую среду. Почти эту, я её потом рукам допилил.

Полагаю, пора это показать. Это продукт на базе LLM, платформа для текстовых РПГ-игр. Наша. @EleonorHostessBot Не что-то прямо сильно оригинальное с технической точки зрения, но с продуктовой - вполне себе. Поддерживает как диалоги с различными персонажами, так и режим гейм-мастера (делаем затравку для приключения и играем), и режим квестов (предзаданные приключения) В отличие от конкурентов - очень длинный контекст, за счёт особого устройства памяти