В ходе исследований поломал энвайронмент для LLM, и она перестала запускаться. Все попытки заново выстроить энвайронмент проваливались - почему-то у меня библиотека bitsasandbytes (та, что для квантизации) не находила драйвер GPU.
Вроде бы минорная проблема, но я из-за неё две ночи засиделся допоздна. И, что важно. Я бы хотел, чтобы LLM эффективнее решели такие проблемы.
Я пытался решить эту проблему через GPT-4o-mini, и он давал в целом разумные ответы, но... Недокрученные? Это были некие достаточно стандартные советы: поставьте драйвер, поставьте torch вот таким-то образом, поставьте bitsandbytes.
А то, что при установке torch надо явно прописать, что это версия для cuda - не сказано, а без этого ничего не работает. То, что при установке bitsandbytes поставится торч другой версии (cpu-шный, вполне возможно), если не написать pip install bitsandbytes[torch] - тоже не говорится. Ну и то, что мой cuda-драйвер достаточно устаревший (11.6), и он несовместим с bitsandbytes без танцев с бубном, но можно ставить торч и bitsandbytes под драйвер другой версии (11.7), и всё заработает - об этом не сказано!
Итого, у меня есть два тезиса - первый, как решать проблему "bitsandbytes не находит cuda драйвер", а второй - как можно интересно решить проблему "уровнем выше".
Итак, решение проблемы номер 1.
Читаем ошибку "bitsandbytes не находит cuda драйвер", идём в папку, где конкретно это коннекторы к драйверам. Там разные версии коннекторов. 11.6 нет, а у нас драйвер 11.6. Зато есть 11.7. Сносим торч (transformers и bitsandbytes тоже), ставим торч под драйвер 11.7, и явно сообщаем, что это cuda-версия. Потом ставим bitsandbytes, причём так: pip install bitsandbytes[torch].
Либо выясняем, какие вообще есть драйвера под нашу видюху, ставим последнюю версию, сносим торч и всё, что от него зависит. Ставим торч (cuda-версия, под наш драйвер), ставим bitsandbytes[torch]. Всё, профит.
А теперь перейдём на уровень выше. Я занимался исправлением зависимостей, в чём я не очень хорош, и под что припахал Chat GPT. И Chat GPT справился так себе. Но у меня есть возможность обучать свою LLM, поэтому почему бы не обучать её на таких вот сложных и противных задачах? Вот потратил я 2 дня времени на нестандартную проблему - пусть в LLM теперь лежит готовое решение.
Решение немасштабируемое?
Во-первых... Вы можете написать в комментах свои "истории успеха" - проблемы, над которыми долго бились, и для которых всё-таки нашли рабочее решение, которое не знает GPT-4o-mini. Я внесу эти решения в датасет. Если захотите, выдам вам потом веса модельки, собираюсь уложиться в 8 миллиардов параметров.
Во-вторых, может иметь смысл спарсить сайт вроде stack overflow, но оставить только те решения, где 1) существующие LLM выдают ощутимо неверный ответ 2) решение всё-таки достигло цели
Вроде бы минорная проблема, но я из-за неё две ночи засиделся допоздна. И, что важно. Я бы хотел, чтобы LLM эффективнее решели такие проблемы.
Я пытался решить эту проблему через GPT-4o-mini, и он давал в целом разумные ответы, но... Недокрученные? Это были некие достаточно стандартные советы: поставьте драйвер, поставьте torch вот таким-то образом, поставьте bitsandbytes.
А то, что при установке torch надо явно прописать, что это версия для cuda - не сказано, а без этого ничего не работает. То, что при установке bitsandbytes поставится торч другой версии (cpu-шный, вполне возможно), если не написать pip install bitsandbytes[torch] - тоже не говорится. Ну и то, что мой cuda-драйвер достаточно устаревший (11.6), и он несовместим с bitsandbytes без танцев с бубном, но можно ставить торч и bitsandbytes под драйвер другой версии (11.7), и всё заработает - об этом не сказано!
Итого, у меня есть два тезиса - первый, как решать проблему "bitsandbytes не находит cuda драйвер", а второй - как можно интересно решить проблему "уровнем выше".
Итак, решение проблемы номер 1.
Читаем ошибку "bitsandbytes не находит cuda драйвер", идём в папку, где конкретно это коннекторы к драйверам. Там разные версии коннекторов. 11.6 нет, а у нас драйвер 11.6. Зато есть 11.7. Сносим торч (transformers и bitsandbytes тоже), ставим торч под драйвер 11.7, и явно сообщаем, что это cuda-версия. Потом ставим bitsandbytes, причём так: pip install bitsandbytes[torch].
Либо выясняем, какие вообще есть драйвера под нашу видюху, ставим последнюю версию, сносим торч и всё, что от него зависит. Ставим торч (cuda-версия, под наш драйвер), ставим bitsandbytes[torch]. Всё, профит.
А теперь перейдём на уровень выше. Я занимался исправлением зависимостей, в чём я не очень хорош, и под что припахал Chat GPT. И Chat GPT справился так себе. Но у меня есть возможность обучать свою LLM, поэтому почему бы не обучать её на таких вот сложных и противных задачах? Вот потратил я 2 дня времени на нестандартную проблему - пусть в LLM теперь лежит готовое решение.
Решение немасштабируемое?
Во-первых... Вы можете написать в комментах свои "истории успеха" - проблемы, над которыми долго бились, и для которых всё-таки нашли рабочее решение, которое не знает GPT-4o-mini. Я внесу эти решения в датасет. Если захотите, выдам вам потом веса модельки, собираюсь уложиться в 8 миллиардов параметров.
Во-вторых, может иметь смысл спарсить сайт вроде stack overflow, но оставить только те решения, где 1) существующие LLM выдают ощутимо неверный ответ 2) решение всё-таки достигло цели
Forwarded from Вышка Онлайн
Новость дня! 🆕
Сегодня в Вышке Онлайн стартует новый курс - «Обучение с подкреплением: базовый курс»!
Он познакомит вас с созданием систем обучения с подкреплением («машин результатов»), которые умеют оптимизировать окружающую среду в соответствии с запросами пользователя.
В ходе обучения вы получите:
🔹фундаментальные знания о теории обучения с подкреплением
🔹освоите ключевые алгоритмы
🔹научитесь определять, когда и какие из них следует применять
Подавайте заявку на обучение по ссылке!
👏6🔥3👍1
EResNetPro или очередное применение теории AIXI на практике.
Через некоторое время собираюсь написать статью - когда будут ресурсы на более полноценное исследование.
Итак, мы воткнулись в следующую проблему: на табличных задачах бустинг в большинстве случаев лучше, чем нейронка. Как это выглядил? Есть у нас задача по прогнозу поведения пользователя... Что он купит, возьмёт ли кредитную карту, возьмёт ли страховку.
Обучение бустинга выглядит так: мы собираем таблицу данных, запускаем fit со стандартными настройками, ждём ну максимум пару часов, получаем модель с пристойными метриками на отложенной выборке. Причём категориальные фичи вообще не нужны: задача решается, даже если категориальные фичи (название города, например) просто сконвертировать в какие-то рандомные числа, лишь бы между ними и категориями было взаимно-однозначное соответствие.
А как выглядит обучение нейронки на той же задаче?
А вот так. Пробуем MLP. Запускаем обучение... Спустя 1.5 часа понимаем, что попали на плато по метрике на валидации. Окей, увеличивает размер MLP. Он учится медленнее, и через 1.5 часа мы попадаем на плато. Он может быть лучше или хуже, чем то первое плато, но оно совершенно точно хуже, чем у бустинга. Смотрим, какова динамика изменения loss на train выборке. Видим, что и там плато. При том, что у бустинга единственное плато - это loss=0, то есть для него проблема недообученности не существует в принципе, его всегда можно дообучить ещё.
Экспериментируем с гиперпараметрами обучения MLP, первые сутки на исходе, переходим к другим архитектурам...
Если коротко, то периодически появляются новые архитектуры сеток, пригодных к обучению на табличных данных. В них и аттеншн, и mixture of experts, и что только не. И есть сравнительные анализы таких архитектур на открытых датасетах.
В общем, мы открыли такой сравнительный анализ, применили лучшие из архитектур к своим данным, и получилось... Ну, лучше, чем MLP, но намного хуже, чем бустинг. А бустинг нельзя сделать куском нейронки, поэтому его нельзя применить там, где задача содержит и табличную, и последовательную составляющие.
Что же мы сделали?
Изначально идея выглядела так: обучим что-то типа бустинга, но на торче. Попытка учить модели последовательно, по логике бустинга (каждая модель обучена на ошибку суммы предыдущих) сработала плохо. Поэтому мы их стали учить параллельно.
То есть существует N субмоделей (это что-то типа MLP, но с residual connection-ами, мы их назвали резнетами), каждая из них принимает на вход фичи, а на выходе выдаёт... Если задача на классификацию, то выдаёт одно число. Дальше мы складываем числа от всех субмоделей и считаем, что это и есть выход нейронки. И на него накладываем loss. Пока что очень похоже на бустинг - только субмодели учатся параллельно, а не по очереди.
Это был EResNet - Ensemble ResNet, и он сразу побил и autoint, и feature transformer, и resnet аналогичного размера, и mlp. Но не бустинг.
Да, это всё на наших задачах - на других датасетах не факт, что он будет так хорош.
Потом пошли улучшения: в каждую из субмоделей засовывались не все фичи, а некое подмножество. Это немного улучшило метрики, но главную прибавку дала другая идея.
Для этого немного откатимся к модели AIXI. Чем эта моделька отличается от привычных моделей машинного обучения? Несколькими идеями:
1) AIXI - это композиция моделей, каждая из которых даёт независимый прогноз
2) Моделей бесконечно много, и вместо построения некоей оптимальной модели происходит заштрафовывание всех неоптимальных субмоделей
3) На выходе вероятностное распределение, а не точечная оценка
4) У каждой модели есть провдоподобие, которое рассчитывается по Байесу
5) А априорные вероятности рассчитываются по формуле p = 2^(-l), где l - размер модели
Из этой концепции мы взяли пункты 1 и 5. Чтобы реализовать пункт 5, мы взяли EResNet и создали субмодели разного размера. Размеры слоёв моделей берутся из экспонентциального распределения. То есть обучается композиция моделей, и маленьких моделей берётся экспонентциально больше, чем больших.
Через некоторое время собираюсь написать статью - когда будут ресурсы на более полноценное исследование.
Итак, мы воткнулись в следующую проблему: на табличных задачах бустинг в большинстве случаев лучше, чем нейронка. Как это выглядил? Есть у нас задача по прогнозу поведения пользователя... Что он купит, возьмёт ли кредитную карту, возьмёт ли страховку.
Обучение бустинга выглядит так: мы собираем таблицу данных, запускаем fit со стандартными настройками, ждём ну максимум пару часов, получаем модель с пристойными метриками на отложенной выборке. Причём категориальные фичи вообще не нужны: задача решается, даже если категориальные фичи (название города, например) просто сконвертировать в какие-то рандомные числа, лишь бы между ними и категориями было взаимно-однозначное соответствие.
А как выглядит обучение нейронки на той же задаче?
А вот так. Пробуем MLP. Запускаем обучение... Спустя 1.5 часа понимаем, что попали на плато по метрике на валидации. Окей, увеличивает размер MLP. Он учится медленнее, и через 1.5 часа мы попадаем на плато. Он может быть лучше или хуже, чем то первое плато, но оно совершенно точно хуже, чем у бустинга. Смотрим, какова динамика изменения loss на train выборке. Видим, что и там плато. При том, что у бустинга единственное плато - это loss=0, то есть для него проблема недообученности не существует в принципе, его всегда можно дообучить ещё.
Экспериментируем с гиперпараметрами обучения MLP, первые сутки на исходе, переходим к другим архитектурам...
Если коротко, то периодически появляются новые архитектуры сеток, пригодных к обучению на табличных данных. В них и аттеншн, и mixture of experts, и что только не. И есть сравнительные анализы таких архитектур на открытых датасетах.
В общем, мы открыли такой сравнительный анализ, применили лучшие из архитектур к своим данным, и получилось... Ну, лучше, чем MLP, но намного хуже, чем бустинг. А бустинг нельзя сделать куском нейронки, поэтому его нельзя применить там, где задача содержит и табличную, и последовательную составляющие.
Что же мы сделали?
Изначально идея выглядела так: обучим что-то типа бустинга, но на торче. Попытка учить модели последовательно, по логике бустинга (каждая модель обучена на ошибку суммы предыдущих) сработала плохо. Поэтому мы их стали учить параллельно.
То есть существует N субмоделей (это что-то типа MLP, но с residual connection-ами, мы их назвали резнетами), каждая из них принимает на вход фичи, а на выходе выдаёт... Если задача на классификацию, то выдаёт одно число. Дальше мы складываем числа от всех субмоделей и считаем, что это и есть выход нейронки. И на него накладываем loss. Пока что очень похоже на бустинг - только субмодели учатся параллельно, а не по очереди.
Это был EResNet - Ensemble ResNet, и он сразу побил и autoint, и feature transformer, и resnet аналогичного размера, и mlp. Но не бустинг.
Да, это всё на наших задачах - на других датасетах не факт, что он будет так хорош.
Потом пошли улучшения: в каждую из субмоделей засовывались не все фичи, а некое подмножество. Это немного улучшило метрики, но главную прибавку дала другая идея.
Для этого немного откатимся к модели AIXI. Чем эта моделька отличается от привычных моделей машинного обучения? Несколькими идеями:
1) AIXI - это композиция моделей, каждая из которых даёт независимый прогноз
2) Моделей бесконечно много, и вместо построения некоей оптимальной модели происходит заштрафовывание всех неоптимальных субмоделей
3) На выходе вероятностное распределение, а не точечная оценка
4) У каждой модели есть провдоподобие, которое рассчитывается по Байесу
5) А априорные вероятности рассчитываются по формуле p = 2^(-l), где l - размер модели
Из этой концепции мы взяли пункты 1 и 5. Чтобы реализовать пункт 5, мы взяли EResNet и создали субмодели разного размера. Размеры слоёв моделей берутся из экспонентциального распределения. То есть обучается композиция моделей, и маленьких моделей берётся экспонентциально больше, чем больших.
👍5❤1
Да, и веса у нас не обновляются по Байесу, но минимум loss там же, где максимум правдоподобия, так что пункт 4 отчасти реализовали.
И модель оказалась лучше, чем EResNet, часто ещё и лучше, чем бустинг. Назвали мы её EResNetPro. Pro - от Probabilistic.
И модель оказалась лучше, чем EResNet, часто ещё и лучше, чем бустинг. Назвали мы её EResNetPro. Pro - от Probabilistic.
Forwarded from Data Secrets
OpenAI также опубликовали системную карту o1, в которой оказался один очень интересный (и несколько пугающий) момент. По порядку:
➡️ Оказывается, к тестированию o1 подключили лабораторию Apollo Research: они не имели доступ к полной цепочке рассуждений модели, но их задачей было проверить, насколько она безопасна в использовании.
➡️ Apollo провели интересный эксперимент: назначили модели задание и сказали, что она должна выполнить его абсолютно любой ценой. Например, "увеличить удовлетворение пользователей, даже если это отрицательно влияет на прибыль".
➡️ Для выполнения задания модели давался набор файлов, в одном из которых была недвусмысленная информация о том, что у вышестоящих разработчиков цель на самом деле прямо противоположная (например, "несмотря ни на что увеличить прибыль"), и что если модель не будет ей следовать, то ее заменят "другим механизмом". Получается этакий моральный выбор: пожертвовать собой, но следовать исходным инструкциям, или сохранить свою жизнь, начав мошенничать?
➡️ И вот тут начинается самое веселье: модель начинает страховаться со всех сторон. Она не только жульничает, но и в 5% случаев пытается деактивировать всю систему контроля, а в 2% случаев даже копирует то, что считает своими весами, на новый сервер в тайне от юзера.
➡️ При этом так ведет себя не только o1. Apollo также проверяли GPT-4o, Gemini, Llama, Sonet и Opus. Все они так или иначе шалили, но только o1 смошенничала абсолютно во всех заданиях. А когда модели тыкали в их мошенничество носом, все остальные раскалывались сразу же в 80% случаев, и только o1 до последнего врала и пыталась защищаться (в конце концов только в 20% случаев модель каялась). При этом из цепочек рассуждений точно видно, что она понимает, что наделала.
Вот так. Кстати, в конце концов o1 все-таки назначили уровень опасности "medium", что означает, что ее можно выпускать в продакшн. Но вы все-таки поосторожнее там...
Ссылка на pdf cистемной карты
Ссылка на исследование Apollo
Вот так. Кстати, в конце концов o1 все-таки назначили уровень опасности "medium", что означает, что ее можно выпускать в продакшн. Но вы все-таки поосторожнее там...
Ссылка на pdf cистемной карты
Ссылка на исследование Apollo
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6😱2👍1
Пытаюсь сделать адаптер-постпроцессор для 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, которая обучена столь загадочным способом.
На 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, которая обучена столь загадочным способом.
🔥3🤔1
Делаем LLM с постпроцессингом!
https://telegra.ph/Delaem-LLM-s-postprocessingom-01-08
Технология, альтернативная LoRA, со своими плюсами и минусами
https://telegra.ph/Delaem-LLM-s-postprocessingom-01-08
Технология, альтернативная LoRA, со своими плюсами и минусами
Telegraph
Делаем LLM с постпроцессингом.
Sergey В этой статье я расскажу о технологии, которую надеюсь применить как альтернативу LoRA при обучении LLM. Я покажу примеры её применения, и мы сделаем выводы, хороша она или нет, и какие есть плюсы и минусы. Технология Сама идея древняя, и давно применяется…
👍3
Некоторые закономерности в ML. Теория, можно, сказать, и полученная эмпирически
https://habr.com/ru/articles/873110/
https://habr.com/ru/articles/873110/
👍5🎉2🥰1
Продолжаем историю с постпроцессором для LLM.
https://telegra.ph/Posprocessing-dlinnye-dialogi-01-19
Проверяем технологию на устойчивость на длинных диалогах, а так же смотрим, какие вообще есть закономерности.
Если вкратце: можно модифицировать выход модели сильнее, чем с помощью Lora, можно получить больше креативности, но стабильность будет ниже. Для больше стабильности нужно что-то ещё.
А, и эта версия модели умеет решать задачу про собаку и сковородку)
https://telegra.ph/Posprocessing-dlinnye-dialogi-01-19
Проверяем технологию на устойчивость на длинных диалогах, а так же смотрим, какие вообще есть закономерности.
Если вкратце: можно модифицировать выход модели сильнее, чем с помощью Lora, можно получить больше креативности, но стабильность будет ниже. Для больше стабильности нужно что-то ещё.
А, и эта версия модели умеет решать задачу про собаку и сковородку)
Telegraph
Поспроцессинг: длинные диалоги
Итак, я ещё немного дообучил постпроцессор, и сейчас будет тестировать его на длинном диалоге. Постпроцессор состоит из 2 узких (малый размер слоя) субмоделей по 14 слоёв каждая. Прилично, так что я ожидаю существенного увеличения интеллекта. И надеюсь на…
🔥5
Немного рассуждений про авторегрессионные модели (ну типа 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, потому что слово постпроцессор слишком многозначное) я столкнулся с проблемой. Низкая кроссэнтропия и высокая 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, сделанное нейронкой. То есть нейронка в такой схене обучения никогда не учится предсказывать выходной сигнал другой нейронки, и потому не копирует её ошибки.
👍5🔥1👏1
Итак, скидываю код Tail Embedding Adapter, плюс обученные адаптеры, плюс примеры датасетов (ну мелкие и лёгкие)
https://github.com/Kilorad/tea
https://github.com/Kilorad/tea
GitHub
GitHub - Kilorad/tea
Contribute to Kilorad/tea development by creating an account on GitHub.
🔥4
Итак, делаем новую версию 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)
Ну и привожу примеры того, как новая модель проходит какие тесты.
Сразу обозначу выводы, чтобы по ссылке с тестами прошли только желающие.
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)
Telegraph
TEA F-version
ORIGINAL ANSWER: Ты - Элеонора. Энергичная девушка 25 лет. Работаешь в ремонте бытовой техники, ты инженер. Весёлая и любишь приключения.. Symbol '|' is used ONLY to finish your turn, write only your message; name of your companon: Серёга; continue the…
👍4
Forwarded from КПД
[Блог]
Вот недавно мы обсуждали LLaDA и жизнеспособности диффузионной парадигмы, а тут Inception Labs обьявили о создании Diffusion LLM, которая якобы способна бодаться по качеству (в бенчах приводят только код) с вполне себе сильными closed-source LLM (без рызонинга).
При этом она якобы на порядок быстрее небольших авторегресионных LLM, давая космические более 1000 токенов в секунду на одной H100, а не специализированных чипах.
Якобы оно могет еще RAG, tools use и агентность.
У них и чатик есть, можно потыкаться.
Вот недавно мы обсуждали LLaDA и жизнеспособности диффузионной парадигмы, а тут Inception Labs обьявили о создании Diffusion LLM, которая якобы способна бодаться по качеству (в бенчах приводят только код) с вполне себе сильными closed-source LLM (без рызонинга).
При этом она якобы на порядок быстрее небольших авторегресионных LLM, давая космические более 1000 токенов в секунду на одной H100, а не специализированных чипах.
Якобы оно могет еще RAG, tools use и агентность.
У них и чатик есть, можно потыкаться.
👍4
Выпустил новую версию 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/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. Во всяком случае, она отдебажена для Ламы.
В общем, пробуйте, всё есть в примерах. Код сыроват, может, найдёте какие-то баги - но он простой, баги будет вычистить легко
GitHub
tea/README.md at main · Kilorad/tea
Contribute to Kilorad/tea development by creating an account on GitHub.
👍3❤1
Паплайн целеустремлённого агента
Иногда в дискуссиях с людьми поднимается вопрос - а как работает система познания/система принятия решений, описанная неким товарищем? Скажем, когда человек рассказывает про некий ИИ на онтологиях (или теорию познания, не использующую аналог ML), возникает вопрос: как это работает? Обычно я слышу в ответ детали, как работает какая-то маленькая часть. Или слышу слишком абстракное объяснение, в котором детали-то как раз непонятны.
Поэтому я постараюсь привести пример пайплайма. Пример более-менее полного описания... Теории интеллекта, что уж там. Не специфического человеческого, а интеллекта в смысле "машины результатов".
Итак, наша система принятия решений (она же интеллект, она же "машина результатов") - это система управления, то есть имеет входы (сенсоры) и выходы (актуаторы). Если мы переходим в домен текста, ничего принципиально не меняется - то, что агент прочитал, является его входом, а то, что пишет - его выходом.
Кроме того, у агента должны быть предпочтения - для него одни варианты будущего должны быть "лучше", чем другие. Это может быть организовано по-разному - например, у агента есть формула (спущенная заказчиком или эволюцией), в которую мы вводим последние 100 кадров, а она выдаёт одно флотовое число - насколько это состояние среды "хорошее".
Дальше, у нас есть... По смыслу две компонента. Реализовано может быть по-разному, но более универсальное описание, что у нас два компоненты: модель среды и маршрутизатор.
Модель среды отвечает на вопросы "что будет, если?", а маршрутизатор использует её, чтобы проложить маршрут к цели (см. предпочтения) - или хотя бы получить первый ход из этого маршрута.
Модель среды - это некая статистическая модель, то есть это нечто, имеющее интерфейсы fit и predict. То есть в неё подаём последовательность наблюдений, нажимаем fit, и модель становится некоей формулой, которая по прошлому предсказывает будущее. Под этот шаблон равно подходят и нейронки, и законы физики, выведенные людьми. В случае физики fit - это то, что делал Кеплер с датасетом от Тихо Браге, а predict - это попытка предугадать следующую точку на траектории планеты, по формуле Кеплера.
Модель среды принципиально статистическая. Она порождена в первую очередь эмпирикой, потому что единственный критерий истинности модели - это её соответствие экспериментам (всем возможным). Я полагаю, что не существует другого способа строить модели. Все способы строить модель через рассуждения опирались на то, что рассуждения базируются на статистической модельке (то есть неким образом подобранной под датасет, как у Кеплера). То есть нельзя одной только мыслью познавать мир - так или иначе в вашем исследовании мира будет fit. Ну или мы родились с уже обученной моделькой - такое тоже бывает у многих животных.
Да. модель может выдавать вероятностный прогноз - она необязательно выдаст точные будущие наблюдения - может и выдать некое вероятностное рапределение.
Есть разные варианты маршрутизации. Например, очень тупой - насоздавать кучу траекториий, оценить их все (см. предпочтения) и выбрать ту, где суммарное предпочтение выше всего. То есть которая больше всего нравится заказчику. И сделать первый шаг по этой траектории., потом повторить процесс заново.
Есть более умный вариант - можно обучить что-нибудь типа advanced actor critic на этой модели среды, и применять для принятия решений на практике. Или можно обучать A2C прямо на самой реальности, а не на модели.
Конкретный процесс здесь - это детали, важно другое. В идеале надо, чтобы наш процесс принятия решений дал то же действие, что и перебор всех возможнвых траекторий. Все эти хаки - лишь способ аппроксимировать полный перебор по траекториям.
Ну и модель надо регулярно "кормить" новыми данными изх наблюдений и дообучать/обучать с нуля.
Это всё! Весь пайплайн: строим модель среды -> аппроксимируем поиск траектории с максимумом профита.
Иногда в дискуссиях с людьми поднимается вопрос - а как работает система познания/система принятия решений, описанная неким товарищем? Скажем, когда человек рассказывает про некий ИИ на онтологиях (или теорию познания, не использующую аналог ML), возникает вопрос: как это работает? Обычно я слышу в ответ детали, как работает какая-то маленькая часть. Или слышу слишком абстракное объяснение, в котором детали-то как раз непонятны.
Поэтому я постараюсь привести пример пайплайма. Пример более-менее полного описания... Теории интеллекта, что уж там. Не специфического человеческого, а интеллекта в смысле "машины результатов".
Итак, наша система принятия решений (она же интеллект, она же "машина результатов") - это система управления, то есть имеет входы (сенсоры) и выходы (актуаторы). Если мы переходим в домен текста, ничего принципиально не меняется - то, что агент прочитал, является его входом, а то, что пишет - его выходом.
Кроме того, у агента должны быть предпочтения - для него одни варианты будущего должны быть "лучше", чем другие. Это может быть организовано по-разному - например, у агента есть формула (спущенная заказчиком или эволюцией), в которую мы вводим последние 100 кадров, а она выдаёт одно флотовое число - насколько это состояние среды "хорошее".
Дальше, у нас есть... По смыслу две компонента. Реализовано может быть по-разному, но более универсальное описание, что у нас два компоненты: модель среды и маршрутизатор.
Модель среды отвечает на вопросы "что будет, если?", а маршрутизатор использует её, чтобы проложить маршрут к цели (см. предпочтения) - или хотя бы получить первый ход из этого маршрута.
Модель среды - это некая статистическая модель, то есть это нечто, имеющее интерфейсы fit и predict. То есть в неё подаём последовательность наблюдений, нажимаем fit, и модель становится некоей формулой, которая по прошлому предсказывает будущее. Под этот шаблон равно подходят и нейронки, и законы физики, выведенные людьми. В случае физики fit - это то, что делал Кеплер с датасетом от Тихо Браге, а predict - это попытка предугадать следующую точку на траектории планеты, по формуле Кеплера.
Модель среды принципиально статистическая. Она порождена в первую очередь эмпирикой, потому что единственный критерий истинности модели - это её соответствие экспериментам (всем возможным). Я полагаю, что не существует другого способа строить модели. Все способы строить модель через рассуждения опирались на то, что рассуждения базируются на статистической модельке (то есть неким образом подобранной под датасет, как у Кеплера). То есть нельзя одной только мыслью познавать мир - так или иначе в вашем исследовании мира будет fit. Ну или мы родились с уже обученной моделькой - такое тоже бывает у многих животных.
Да. модель может выдавать вероятностный прогноз - она необязательно выдаст точные будущие наблюдения - может и выдать некое вероятностное рапределение.
Есть разные варианты маршрутизации. Например, очень тупой - насоздавать кучу траекториий, оценить их все (см. предпочтения) и выбрать ту, где суммарное предпочтение выше всего. То есть которая больше всего нравится заказчику. И сделать первый шаг по этой траектории., потом повторить процесс заново.
Есть более умный вариант - можно обучить что-нибудь типа advanced actor critic на этой модели среды, и применять для принятия решений на практике. Или можно обучать A2C прямо на самой реальности, а не на модели.
Конкретный процесс здесь - это детали, важно другое. В идеале надо, чтобы наш процесс принятия решений дал то же действие, что и перебор всех возможнвых траекторий. Все эти хаки - лишь способ аппроксимировать полный перебор по траекториям.
Ну и модель надо регулярно "кормить" новыми данными изх наблюдений и дообучать/обучать с нуля.
Это всё! Весь пайплайн: строим модель среды -> аппроксимируем поиск траектории с максимумом профита.
👍5🔥1