Пытаюсь сделать адаптер-постпроцессор для 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 оказалась очень узкой, большинство шагов из неё - это ухудшения.
Если будет интересно, могу скинуть пример данных и веса LM-head, которая обучена столь загадочным способом.

Делаем 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%, а у третьего 68%. И я не стремлюсь сделать единую метрику, которая правильно описывает, как измерить качество генерации по прогнозу по сути всего одного токена. Вместо этого я оцениваю уже сгенерённые строки! Не всё вручную, в части случаев автоматически, заставляю LLM вычитывать тексты и оценивать их по разным шкалам.

Кроме того, я не опираюсь на одни только тексты из интернета. Есть расхайпленный тезис, что тексты из интернета заканчиваются, и скоро их совсем не останется, и LLM учить будет не на чем. На самом же деле LLM учат на значительном числе синтетических данных. И разумеется, когда мы решаемся синтезировать данные, мы сталкиваемся с проблемой того, что данные, сгенерённые нейросеткой, являются лишь "отражением" реального мира, и если так последовательно обучить N нейронок, то мы получим накопление ошибки. Как с этим бороться?

Общая идея в том, что надо брать реальные тексты, нарезать кусочками и создавать пары X, Y, где реальные текст - это Y, а X - это нечто, порождённое нейросетью.
Например, Y - это статья по сборке парового двигателя, а X - это вопрос "напиши мне текст по S", где S - это Summary от Y, сделанное нейронкой. То есть нейронка в такой схене обучения никогда не учится предсказывать выходной сигнал другой нейронки, и потому не копирует её ошибки.

Итак, скидываю код 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)

[Блог]

Вот недавно мы обсуждали LLaDA и жизнеспособности диффузионной парадигмы, а тут Inception Labs обьявили о создании Diffusion LLM, которая якобы способна бодаться по качеству (в бенчах приводят только код) с вполне себе сильными closed-source LLM (без рызонинга).

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

Якобы оно могет еще RAG, tools use и агентность.

У них и чатик есть, можно потыкаться.

Выпустил новую версию 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. Во всяком случае, она отдебажена для Ламы.

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

Паплайн целеустремлённого агента

Иногда в дискуссиях с людьми поднимается вопрос - а как работает система познания/система принятия решений, описанная неким товарищем? Скажем, когда человек рассказывает про некий ИИ на онтологиях (или теорию познания, не использующую аналог ML), возникает вопрос: как это работает? Обычно я слышу в ответ детали, как работает какая-то маленькая часть. Или слышу слишком абстракное объяснение, в котором детали-то как раз непонятны.

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

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

Дальше, у нас есть... По смыслу две компонента. Реализовано может быть по-разному, но более универсальное описание, что у нас два компоненты: модель среды и маршрутизатор.
Модель среды отвечает на вопросы "что будет, если?", а маршрутизатор использует её, чтобы проложить маршрут к цели (см. предпочтения) - или хотя бы получить первый ход из этого маршрута.

Модель среды - это некая статистическая модель, то есть это нечто, имеющее интерфейсы fit и predict. То есть в неё подаём последовательность наблюдений, нажимаем fit, и модель становится некоей формулой, которая по прошлому предсказывает будущее. Под этот шаблон равно подходят и нейронки, и законы физики, выведенные людьми. В случае физики fit - это то, что делал Кеплер с датасетом от Тихо Браге, а predict - это попытка предугадать следующую точку на траектории планеты, по формуле Кеплера.
Модель среды принципиально статистическая. Она порождена в первую очередь эмпирикой, потому что единственный критерий истинности модели - это её соответствие экспериментам (всем возможным). Я полагаю, что не существует другого способа строить модели. Все способы строить модель через рассуждения опирались на то, что рассуждения базируются на статистической модельке (то есть неким образом подобранной под датасет, как у Кеплера). То есть нельзя одной только мыслью познавать мир - так или иначе в вашем исследовании мира будет fit. Ну или мы родились с уже обученной моделькой - такое тоже бывает у многих животных.
Да. модель может выдавать вероятностный прогноз - она необязательно выдаст точные будущие наблюдения - может и выдать некое вероятностное рапределение.

Есть разные варианты маршрутизации. Например, очень тупой - насоздавать кучу траекториий, оценить их все (см. предпочтения) и выбрать ту, где суммарное предпочтение выше всего. То есть которая больше всего нравится заказчику. И сделать первый шаг по этой траектории., потом повторить процесс заново.
Есть более умный вариант - можно обучить что-нибудь типа advanced actor critic на этой модели среды, и применять для принятия решений на практике. Или можно обучать A2C прямо на самой реальности, а не на модели.
Конкретный процесс здесь - это детали, важно другое. В идеале надо, чтобы наш процесс принятия решений дал то же действие, что и перебор всех возможнвых траекторий. Все эти хаки - лишь способ аппроксимировать полный перебор по траекториям.

Ну и модель надо регулярно "кормить" новыми данными изх наблюдений и дообучать/обучать с нуля.

Это всё! Весь пайплайн: строим модель среды -> аппроксимируем поиск траектории с максимумом профита.

Как можно заметить, пайплайн пригоден для человека и для программы (для программы он годится получше), и вы всякий раз его задействуете, когда по новым наблюдениям узнаёте о некоей закономерности, или когда задаётесь вопросами "что мне делать? Что будет, если я сделаю то-то и то-то?".

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

Да, и в пайплайне есть явное разделение на познание (это построение модели среды) и принятие решений (это маршрутизация)

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

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

Вот я пошёл вторым путём. Если кому интересно - welcome

Да, и это очень далеко от продовой разработки, я просто делюсь своей утилиткой, поэтому она может выглядеть несколько странно (одни зависимости от самописной либы chat_bots чего стоят)

Зато эта штука умеет выполнять команды вроде "нарисуй где мерцающий градиентный квадрат" или "какой у меня вендор оперативной памяти". В теории я хотел, чтобы этот агент умел решать задачи вроде "поставь мне unsloth на винду (прорубившись через тучи ошибок)", но на это мозгов агента пока не хватает

Ааа, так вот почему добавление bos-tokena у меня настолько улучшало качество генерации!

Зачем все LLM фокусируют attention на первом токене? (by DeepMind & Oxford)

Давно известно, что многие головы внимания у LLM упорно «смотрят» на самый первый токен последовательности (чаще всего это токен <bos>). В моделях вроде GPT, LLaMA или Gemma такое внимание занимает до 80% от всех голов!

Авторы показывают, что такой «слив» внимания на первый токен — это не ошибка, а очень полезный механизм. Он работает примерно как «нулевая операция» (no-op), то есть помогает головам внимания эффективно ничего не делать и не вносить ненужных изменений в представления токенов, когда они не нужны.

Зачем это нужно? Постоянное активное перемешивание информации между токенами ведёт к трём серьёзным проблемам:
1. Rank collapse — представления всех токенов становятся линейно зависимыми.
2. Representational collapse — сильно растёт косинусная близость соседних токенов.
3. Over-squashing — дальние токены перестают эффективно обмениваться информацией.

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

P.S. Что-то оооочень похожее нам рассказывал профессор Вячеслав Дубынин на курсах химии мозга — у людей тоже есть механизм предотвращающий "смешивание" активаций. А, например, ЛСД его ослабляет, вызывая галлюцинации.

Статья

Претрейн и файнтюн, а так же проблема переобучения.
Типичный пайплайн обучения LLM такой:
1) вначале проводим претрейн на огромном датасете, в основном из "плоских", неразмеченных текстов.
2) затем файнтюн на instruct-задаче, то есть на парах вопрос-ответ
Второй пункт может дополняться ещё и RL, но в данном случае я не буду их разделять - будем считать, что примеры из instruct-датасета равнозначны примерам из replay-buffer у RL, с положительной наградой.

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

Я это всё провожу на Tail Embedding Adapter размера ~1.5 млрд параметров при модели на 8 миллиардов. Возможно, при полноценном обучении LLM ситуация будет отличаться. Но наверное, не очень сильно - у меня многие закономерности обучения воспроизвелись, пусть и в меньшем масштабе.

P. S. Я всё обучаю TEA-2. Это новый адаптер, которые наконец-то включает sequential слои. Но я хочу обучить его поэффектнее, прежде чем публиковать.