Кстати, смотрите кто в топ-15 по оценкам на ICLR: https://arxiv.org/abs/2407.01082
А знаете, кто в Acknowledgements?
А знаете, кто в Acknowledgements?
Trust or Escalate: LLM Judges with Provable Guarantees for Human Agreement
Статья: https://arxiv.org/abs/2407.18370
Рецензии: https://openreview.net/forum?id=UHPnqSTBPO
Попарные оценки языковыми моделями с теоретическими гарантиями согласованности с людьми😐
Что за теоретические гарантии? Предположим, что мы задаём уровень риска α и хотим, чтобы для примера x вероятность согласованности языковой модели с людьми на этом примере была больше 1 - α, при условии, что этот мы вообще оцениваем этот пример. Последняя фраза тут очень важна — очевидно, что есть примеры, на которых даже у людей очень низкая согласованность, и такие примеры мы хотим каким-то образом определять и не учитывать их в оценке. Теперь для каждого метода оценки у нас есть 2 чиселки: непосредственно согласованность с людьми, а ещё и покрытие, то есть доля примеров, которые мы не откинули в процессе оценки.
🔹Few-shot ансамблирование
Для начала нам нужно понять, а как вообще отсеивать примеры, которые мы не хотим оценивать? Для этого мы можем попросить модель каким-то образом вывести уверенность в своей оценке. Исходя из этой уверенности и маленького калибровочного набора данных, можно вывести минимальную уверенность для заданного α, ниже которой мы должны откидывать примеры.
Есть разные методы оценки уверенности модели, например можно взять прямую вероятность генерации ответа, или можно попросить модель явно выдавать уверенность текстом. Авторы считают точность, ROC AUC и другие метрики классификации для этих вариантов и показывают, что они жёстко переоценивают уверенность модели. Поэтому предлагается ансамблировать несколько few-shot ответов модели с разными наборами примеров в контексте. Авторы показывают, что такая уверенность лучше откалибрована, а значит позволяет отсеивать меньше примеров.
🔹Каскады
Второй шаг ещё интереснее: дело в том, что слабые модели тоже неплохо откалиброваны. А значит можно сначала прогнать примеры через дешёвые модели с высокой границей уверенности. Если они прошли фильтр — шикарно, используем дешёвую модель для оценки. Если нет — переходим к более дорогой модели. Полностью откидываем пример только тогда, когда все модели не уверены.
🔹Эмпирические оценки
А дальше оказывается, что это всё очень хорошо бьётся с эмпирической согласованностью. То есть теоретическая оценка согласованности действительно является оценкой снизу на практике. Кроме того, авторы показывают, что выкинутые примеры дейсвительно были бы выкинуты по несогласованности людей.
Итого мы получаем:
1) чёткую схему оценки
2) с теоретическими гарантиями согласованности
3) с эмпирической согласованностью выше, чем у GPT-4💪
3) с инференсом в 2-5 раз дешевле, чем у GPT-4😺
P.S. Гитхаб пустой, но весь код можно найти в доп. материалах на OpenReview😁
Статья: https://arxiv.org/abs/2407.18370
Рецензии: https://openreview.net/forum?id=UHPnqSTBPO
Попарные оценки языковыми моделями с теоретическими гарантиями согласованности с людьми
Что за теоретические гарантии? Предположим, что мы задаём уровень риска α и хотим, чтобы для примера x вероятность согласованности языковой модели с людьми на этом примере была больше 1 - α, при условии, что этот мы вообще оцениваем этот пример. Последняя фраза тут очень важна — очевидно, что есть примеры, на которых даже у людей очень низкая согласованность, и такие примеры мы хотим каким-то образом определять и не учитывать их в оценке. Теперь для каждого метода оценки у нас есть 2 чиселки: непосредственно согласованность с людьми, а ещё и покрытие, то есть доля примеров, которые мы не откинули в процессе оценки.
🔹Few-shot ансамблирование
Для начала нам нужно понять, а как вообще отсеивать примеры, которые мы не хотим оценивать? Для этого мы можем попросить модель каким-то образом вывести уверенность в своей оценке. Исходя из этой уверенности и маленького калибровочного набора данных, можно вывести минимальную уверенность для заданного α, ниже которой мы должны откидывать примеры.
Есть разные методы оценки уверенности модели, например можно взять прямую вероятность генерации ответа, или можно попросить модель явно выдавать уверенность текстом. Авторы считают точность, ROC AUC и другие метрики классификации для этих вариантов и показывают, что они жёстко переоценивают уверенность модели. Поэтому предлагается ансамблировать несколько few-shot ответов модели с разными наборами примеров в контексте. Авторы показывают, что такая уверенность лучше откалибрована, а значит позволяет отсеивать меньше примеров.
🔹Каскады
Второй шаг ещё интереснее: дело в том, что слабые модели тоже неплохо откалиброваны. А значит можно сначала прогнать примеры через дешёвые модели с высокой границей уверенности. Если они прошли фильтр — шикарно, используем дешёвую модель для оценки. Если нет — переходим к более дорогой модели. Полностью откидываем пример только тогда, когда все модели не уверены.
🔹Эмпирические оценки
А дальше оказывается, что это всё очень хорошо бьётся с эмпирической согласованностью. То есть теоретическая оценка согласованности действительно является оценкой снизу на практике. Кроме того, авторы показывают, что выкинутые примеры дейсвительно были бы выкинуты по несогласованности людей.
Итого мы получаем:
1) чёткую схему оценки
2) с теоретическими гарантиями согласованности
3) с эмпирической согласованностью выше, чем у GPT-4
3) с инференсом в 2-5 раз дешевле, чем у GPT-4
P.S. Гитхаб пустой, но весь код можно найти в доп. материалах на OpenReview
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Ruadaptная комната
Learned Embedding Propagation (LEP) + анонс релиза RuadaptQwQ-32B
Расскажу немного подробнее про идею, которая стоит за текущими версиями Ruadapt моделей. Наше предыдущее решение требовало после адаптации базовых версий моделей дополнительно их дообучать по сути с “базы”, из-за чего терялись многие успешные инструктивные версии моделей, которые нельзя просто взять и воспроизвести из-за отсутствия обучающих данных (те же 10 миллионов инструкций LLaMa-3 не были открыты комьюнити). Другим ярким примером может послужить недавняя Qwen/QwQ-32B-Preview, так как не понятно как ее учили и на каких данных.
Тут то на помощь и приходит предложенный нами метод Learned Embedding Propagation (LEP). Идея метода состоит из 3 шагов:
1. На первом шаге мы также адаптируем исходную базовую модель
2 . На втором шаге мы рассчитываем проекцию из исходной базы в целевую исходную инструктивную версию (например, из Qwen/Qwen2.5-32B🔜 Qwen/Qwen2.5-32B-Instruct)
3. На третьем шаге мы применяем данную проекцию🔜 на Ruadapt версию базы!
4. На самом деле есть еще 4-й шаг, по сути очень важный, это шаг калибровки / дообучения, но он “опционален”
В итоге, после 3 шага мы по сути имеем адаптированную инструктивную версию модели, и при этом она не сломалась и работает весьма успешно уже на новой токенизации, но из-за неточностей отображения качество несколько просаживается и могут быть новые артефакты. Поэтому все модели, которые мы выкладывали ранее, дополнительно калибровались/дообучались на открытых инструктивных данных, таких как saiga_scored.
А теперь обращу внимание вот на что.
Самое дорогое - это как раз первый шаг, адаптация базовой версии модели и в этом шаге нигде не используется никакая информация о будущей инструктивной версии, а значит, адаптировав базу и применяя LEP, мы можем адаптировать модель на любую инструктивную версию с этой базы!
И вот возьмем, недавно вышедшую Qwen/QwQ-32B-Preview, несмотря на то, что мы вообще не знаем как и на чем она обучалась, мы знаем, что ее базой является, Qwen/Qwen2.5-32B, поэтому мы легко можем сделать версию RuadaptQwQ-32B-Preview-LEP. С шагом 4 тут посложнее, так как хороших данных для подобного типа моделей я пока что не видел. На текущий момент предлагаю попробовать RuadaptQwQ-32B-Preview-LEP в поднятом Space (https://huggingface.co/spaces/RefalMachine/RuadaptQwen2.5), но обращаю внимание, это модель сразу после LEP, без дополнительных шагов дообучения, да и тестирования особо никакого с этой моделью пока не производилось.
Соответственно релиз RuadaptQwQ в планах, но через какое-то время. Буду рад фидбеку по любой из наших моделей в комментариях к посту или другим любым способом.
Расскажу немного подробнее про идею, которая стоит за текущими версиями Ruadapt моделей. Наше предыдущее решение требовало после адаптации базовых версий моделей дополнительно их дообучать по сути с “базы”, из-за чего терялись многие успешные инструктивные версии моделей, которые нельзя просто взять и воспроизвести из-за отсутствия обучающих данных (те же 10 миллионов инструкций LLaMa-3 не были открыты комьюнити). Другим ярким примером может послужить недавняя Qwen/QwQ-32B-Preview, так как не понятно как ее учили и на каких данных.
Тут то на помощь и приходит предложенный нами метод Learned Embedding Propagation (LEP). Идея метода состоит из 3 шагов:
1. На первом шаге мы также адаптируем исходную базовую модель
2 . На втором шаге мы рассчитываем проекцию из исходной базы в целевую исходную инструктивную версию (например, из Qwen/Qwen2.5-32B
3. На третьем шаге мы применяем данную проекцию
4. На самом деле есть еще 4-й шаг, по сути очень важный, это шаг калибровки / дообучения, но он “опционален”
В итоге, после 3 шага мы по сути имеем адаптированную инструктивную версию модели, и при этом она не сломалась и работает весьма успешно уже на новой токенизации, но из-за неточностей отображения качество несколько просаживается и могут быть новые артефакты. Поэтому все модели, которые мы выкладывали ранее, дополнительно калибровались/дообучались на открытых инструктивных данных, таких как saiga_scored.
А теперь обращу внимание вот на что.
Самое дорогое - это как раз первый шаг, адаптация базовой версии модели и в этом шаге нигде не используется никакая информация о будущей инструктивной версии, а значит, адаптировав базу и применяя LEP, мы можем адаптировать модель на любую инструктивную версию с этой базы!
И вот возьмем, недавно вышедшую Qwen/QwQ-32B-Preview, несмотря на то, что мы вообще не знаем как и на чем она обучалась, мы знаем, что ее базой является, Qwen/Qwen2.5-32B, поэтому мы легко можем сделать версию RuadaptQwQ-32B-Preview-LEP. С шагом 4 тут посложнее, так как хороших данных для подобного типа моделей я пока что не видел. На текущий момент предлагаю попробовать RuadaptQwQ-32B-Preview-LEP в поднятом Space (https://huggingface.co/spaces/RefalMachine/RuadaptQwen2.5), но обращаю внимание, это модель сразу после LEP, без дополнительных шагов дообучения, да и тестирования особо никакого с этой моделью пока не производилось.
Соответственно релиз RuadaptQwQ в планах, но через какое-то время. Буду рад фидбеку по любой из наших моделей в комментариях к посту или другим любым способом.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Техножрица 👩💻👩🏫👩🔧
В итоге, я настолько подавлена результатами дискуссии на openreview, что уже даже нет сил делать никаких оригинальных познавательных постов в паблик да и вообще что либо делать.
Я и коллеги, с которыми мы вместе писали статью, потратили реально много времени и сил на то, чтобы сделать все дополнительные эксперименты, которые просили ревьюеры, написать ответы этим самым ревьюерам и внести правки в статью (каждый из этих этапов подробно обсуждался на созвонах, а формулировки в ответах подолгу вылизывались).
Кроме того, я и как минимум ещё двое моих соавторов, которые сами были ревьюерами, параллельно внимательно разбирали ответы тех авторов статей, которые ревьюили мы и отвечали на них. Забавно, что в итоге мы все трое подняли оценки всем статьям, на которые делали ревью)) Ну а что делать, если авторы старались и исправили ряд недочётов, на которые им указали? Повышение оценки более чем справедливо в такой ситуации.
Но наши собственные ревьюеры, конечно, так не считали: ответом на наши собственные старания в ребаттле было в основном молчание.
Один ревьюер попросил сделать ещё один дополнительный эксперимент, а когда мы его сделали, никак это не прокомментировал и умолк навсегда. Другой в последний момент дискуссии ответил что-то похожее на генерацию LLMки, где было сказано, какие мы молодцы, но оценки не поднял. Двое остальных просто не реагировали, как будто умерли.
Когда соавтор решил написать об этой проблеме Area chair и senior area chair, они тоже ответили молчанием.
Я очень болезненно воспринимаю такие ситуация, когда так сильно стараешься, но тем, ради кого стараешься, на тебя настолько насратб, что лень даже два слова ответить... Руки опускаются...
#наука #о_себе
Я и коллеги, с которыми мы вместе писали статью, потратили реально много времени и сил на то, чтобы сделать все дополнительные эксперименты, которые просили ревьюеры, написать ответы этим самым ревьюерам и внести правки в статью (каждый из этих этапов подробно обсуждался на созвонах, а формулировки в ответах подолгу вылизывались).
Кроме того, я и как минимум ещё двое моих соавторов, которые сами были ревьюерами, параллельно внимательно разбирали ответы тех авторов статей, которые ревьюили мы и отвечали на них. Забавно, что в итоге мы все трое подняли оценки всем статьям, на которые делали ревью)) Ну а что делать, если авторы старались и исправили ряд недочётов, на которые им указали? Повышение оценки более чем справедливо в такой ситуации.
Но наши собственные ревьюеры, конечно, так не считали: ответом на наши собственные старания в ребаттле было в основном молчание.
Один ревьюер попросил сделать ещё один дополнительный эксперимент, а когда мы его сделали, никак это не прокомментировал и умолк навсегда. Другой в последний момент дискуссии ответил что-то похожее на генерацию LLMки, где было сказано, какие мы молодцы, но оценки не поднял. Двое остальных просто не реагировали, как будто умерли.
Когда соавтор решил написать об этой проблеме Area chair и senior area chair, они тоже ответили молчанием.
Я очень болезненно воспринимаю такие ситуация, когда так сильно стараешься, но тем, ради кого стараешься, на тебя настолько насратб, что лень даже два слова ответить... Руки опускаются...
#наука #о_себе
Forwarded from [26/100] Витя Тарнавский
Большой день.
Мы выкладываем в опенсорс наши модели T-Lite и T-Pro. И эти модели просто топ🥳
Мы увереннно выбиваем #1 среди открытых моделей по разным бенчам на русском. По MERA мы взяли #2 модель на русском ещё и включая все API, уступая только GPT-4o.
Это до-тренированный qwen-2.5 в размерах 7B и 32B. Мы провели большую работу: свой токенизатор, глубокое до-обучение на русский и специфичные корпуса. Аккуратная работа с данными. Тех репорты будут.
Этот релиз является подтверждением нашего подхода в LLM: допретрен на базе опенсорса и затем файнтюн под доменные области. Получается значительно лучше результат и мы тратим на порядок меньше денег (не преувеличение).
Пользуйтесь. Модели для инженеров, рекомендуется дальнейший файнтюн, например через наш Turbo-Alignment.
Наш новый HF: https://huggingface.co/t-tech
Лидерборд по MERA: https://mera.a-ai.ru/ru/leaderboard
Остальные бенчи тоже есть, арены будут как прокрасятся
Мы выкладываем в опенсорс наши модели T-Lite и T-Pro. И эти модели просто топ
Мы увереннно выбиваем #1 среди открытых моделей по разным бенчам на русском. По MERA мы взяли #2 модель на русском ещё и включая все API, уступая только GPT-4o.
Это до-тренированный qwen-2.5 в размерах 7B и 32B. Мы провели большую работу: свой токенизатор, глубокое до-обучение на русский и специфичные корпуса. Аккуратная работа с данными. Тех репорты будут.
Этот релиз является подтверждением нашего подхода в LLM: допретрен на базе опенсорса и затем файнтюн под доменные области. Получается значительно лучше результат и мы тратим на порядок меньше денег (не преувеличение).
Пользуйтесь. Модели для инженеров, рекомендуется дальнейший файнтюн, например через наш Turbo-Alignment.
Наш новый HF: https://huggingface.co/t-tech
Лидерборд по MERA: https://mera.a-ai.ru/ru/leaderboard
Остальные бенчи тоже есть, арены будут как прокрасятся
Please open Telegram to view this post
VIEW IN TELEGRAM
Мне недавно скинули одну модельку на оценку, и она оказалась очень хорошей.
Модель: https://huggingface.co/Moraliane/SAINEMO-reMIX
Это мёрж Сайги, Вихря и пары английских RP моделей. Получилось не так шизово и многословно, как оригинальная v3 Сайга, но всё ещё очень интересно.
В боте будет доступна завтра, когда в gptq 8bit переквантую, чтобы подешевле инферить.
Модель: https://huggingface.co/Moraliane/SAINEMO-reMIX
Это мёрж Сайги, Вихря и пары английских RP моделей. Получилось не так шизово и многословно, как оригинальная v3 Сайга, но всё ещё очень интересно.
В боте будет доступна завтра, когда в gptq 8bit переквантую, чтобы подешевле инферить.
И ещё одна хорошая моделька, на этот раз закрытая. В боте уже доступна.
Амазоновская Nova Pro тоже теперь есть в лидерборде, но с ней всё не очень хорошо.
Амазоновская Nova Pro тоже теперь есть в лидерборде, но с ней всё не очень хорошо.
Forwarded from e/acc
o3 на 175 месте в Codeforces, то есть примерно 175й сильнейший программист во всем мире.
Это лучше 99,9% участников рейтинга (а все из них — это профессиональные программисты).
Живые участники рейтинга, у которых с 1 по 100 место — это люди, которые выигрывали золотые медали по информатике и продолжали профессионально участвовать в соревнованиях после школы/универа.
Это лучше 99,9% участников рейтинга (а все из них — это профессиональные программисты).
Живые участники рейтинга, у которых с 1 по 100 место — это люди, которые выигрывали золотые медали по информатике и продолжали профессионально участвовать в соревнованиях после школы/универа.
OpenAI душат (потому что o2 нет).
Это всё ещё неимоверно дорого, как и весь test-time compute, но иногда это стоит того. Особенно в тех случаях, когда человеки не могут что-то решить в принципе.
Это всё ещё неимоверно дорого, как и весь test-time compute, но иногда это стоит того. Особенно в тех случаях, когда человеки не могут что-то решить в принципе.
На HF довольно давно появился пост, который я как-то пропустил, но который хорошо и кратко описывает основные оптимизации при обучении языковых моделей. Пост: ссылка
Есть ещё старый пост на ту же тему от Eleuther: ссылка
А пост ниже — это короткая выжимка от меня, именно по экономии памяти на одной карточке.
🔹Числа с плавающей точкой (IEEE 754) — основной тип для вычислений в языковых моделях, у них есть знак, экспонента и мантисса. Экспонента контролирует диапазон значений, мантисса — точность в рамках этого диапазона. Также напомню, что есть приколы с представлением чисел около нуля (aka денормализованные числа). Есть куча реализаций разной битности:
— float: 32 бита, E8M23
— tf32: 19 бит, E8M10 (специфичный для Nvidia формат, отсюда все странности)
— fp16: 16 бит, E5M10
— bf16: 16 бит, E8M7 (экспонента и диапазон как у float)
— fp8: 8 бит, E4M3 или E5M2
🔹На что тратится память:
W: Сами веса модели
A: Активации (промежуточные состояния, результат вычисления функции от входа и весов)
G: Градиенты (обновления весов модели при обучении)
O: Состояние оптимизатора (моменты и дисперсия)
При инференсе есть только W и часть A, при обучении есть все 4 категории. Далее у каждого метода стоят буквы, которые обозначают, что именно экономится.
🔹Методы экономии памяти при инференсе:
— Квантование модели (WA): ужимаем тип данных для весов и активаций. В большинстве статьей так и написано: W4A16, что означает, что веса в 4 битах, активации в 16 битах.
— Flash Attention (A): оптимизируем вычисление внимания поблочными вычислениями в кэше GPU, попутно уменьшая сложность по памяти с квадратичной по длине последовательности до линейной.
🔹Дополнительные методы экономии памяти при обучении на одной карточке:
— Смешанная точность (A): имеем рабочую копию в 16 битах (bf16 или fp16), а также мастер-копию в 32 битах. Все операции делаем с рабочей копией и потом обновления весов вливаем в мастер-копию. Вы спросите: а где профит? А профит в том, что активации в 16 битах, а активации — это дофига памяти.
— Квантование оптимизатора (O): ужимаем тип данных для состояний оптимизатора. Чаще всего в 8 бит, перед собственно применением градиентов расквантовываем.
— Аккумуляция градиентов (AG): если мы хотим батч из больше чем одного примера, то A и G тоже раздуются. Но нам совсем не обязательно считать градиенты параллельно, поэтому мы можем считать их последовательно, суммировать, и только потом применять. Если это правильно😁 отмасштабировать, то это теоретически эквивалентно обучению на всём батче.
— Чекпоинты активаций (A): при обучении нам по-хорошему нужны активации на всех слоях, чтобы потом считать по ним градиенты. Но нам сначала нужно дойти до лосса, поэтому мы выкидываем часть промежуточных активаций и пересчитываем их заново на основе оставшихся чекпоинтов тогда, когда они нам реально понадобятся для подсчёта градиентов.
— Адаптеры (GO): основную модель вообще не трогаем, учим только новый маленький набор весов. Градиенты считаем только по нему, и на этом сильно экономим.
На практике используется буквально всё, везде и сразу🤯
Типичный конфиг:
Есть ещё старый пост на ту же тему от Eleuther: ссылка
А пост ниже — это короткая выжимка от меня, именно по экономии памяти на одной карточке.
🔹Числа с плавающей точкой (IEEE 754) — основной тип для вычислений в языковых моделях, у них есть знак, экспонента и мантисса. Экспонента контролирует диапазон значений, мантисса — точность в рамках этого диапазона. Также напомню, что есть приколы с представлением чисел около нуля (aka денормализованные числа). Есть куча реализаций разной битности:
— float: 32 бита, E8M23
— tf32: 19 бит, E8M10 (специфичный для Nvidia формат, отсюда все странности)
— fp16: 16 бит, E5M10
— bf16: 16 бит, E8M7 (экспонента и диапазон как у float)
— fp8: 8 бит, E4M3 или E5M2
🔹На что тратится память:
W: Сами веса модели
A: Активации (промежуточные состояния, результат вычисления функции от входа и весов)
G: Градиенты (обновления весов модели при обучении)
O: Состояние оптимизатора (моменты и дисперсия)
При инференсе есть только W и часть A, при обучении есть все 4 категории. Далее у каждого метода стоят буквы, которые обозначают, что именно экономится.
🔹Методы экономии памяти при инференсе:
— Квантование модели (WA): ужимаем тип данных для весов и активаций. В большинстве статьей так и написано: W4A16, что означает, что веса в 4 битах, активации в 16 битах.
— Flash Attention (A): оптимизируем вычисление внимания поблочными вычислениями в кэше GPU, попутно уменьшая сложность по памяти с квадратичной по длине последовательности до линейной.
🔹Дополнительные методы экономии памяти при обучении на одной карточке:
— Смешанная точность (A): имеем рабочую копию в 16 битах (bf16 или fp16), а также мастер-копию в 32 битах. Все операции делаем с рабочей копией и потом обновления весов вливаем в мастер-копию. Вы спросите: а где профит? А профит в том, что активации в 16 битах, а активации — это дофига памяти.
— Квантование оптимизатора (O): ужимаем тип данных для состояний оптимизатора. Чаще всего в 8 бит, перед собственно применением градиентов расквантовываем.
— Аккумуляция градиентов (AG): если мы хотим батч из больше чем одного примера, то A и G тоже раздуются. Но нам совсем не обязательно считать градиенты параллельно, поэтому мы можем считать их последовательно, суммировать, и только потом применять. Если это правильно
— Чекпоинты активаций (A): при обучении нам по-хорошему нужны активации на всех слоях, чтобы потом считать по ним градиенты. Но нам сначала нужно дойти до лосса, поэтому мы выкидываем часть промежуточных активаций и пересчитываем их заново на основе оставшихся чекпоинтов тогда, когда они нам реально понадобятся для подсчёта градиентов.
— Адаптеры (GO): основную модель вообще не трогаем, учим только новый маленький набор весов. Градиенты считаем только по нему, и на этом сильно экономим.
На практике используется буквально всё, везде и сразу
Типичный конфиг:
"model": {
"attn_implementation": "flash_attention_2", // вы поняли
"load_in_4bit": true, // квантование модели
...
},
"trainer": {
"gradient_accumulation_steps": 32, // аккумуляция градиентов
"bf16": true, // смешанная точность
"optim": "adamw_8bit", // квантование оптимизатора
"gradient_checkpointing": true, // чекпоинты активаций
...
},
"lora": {...} // адаптеры
Please open Telegram to view this post
VIEW IN TELEGRAM
Cut Your Losses in Large-Vocabulary Language Models
Статья: https://arxiv.org/abs/2411.09009
Рецензии: https://openreview.net/forum?id=E4Fk3YuG56
Код: https://github.com/apple/ml-cross-entropy
Статья про оптимизацию памяти при подсчёте функции потерь и её ближайших градиентов при обучении языковых моделей. Основной механизм — модифицированная реализация перекрёстной энтропии, Cut Cross-Entropy (CCE). Авторы берут ровно ту же оптимизацию, которая используется в Flash Attention (поблочное вычисление в кэше GPU), но применяют её к последнему слою и последнему софтмаксу.
Последний шаг при предсказании следующего токена — линейный слой и софтмакс. На каждом шаге генерации у нас есть вектор E с последнего слоя трансформера, мы умножаем его на матрицу C, получаем логиты в ℝ^|V|, для каждого логита считаем экспоненту и делим на сумму всех логитов из всего словаря. Так для каждого токена получаем вероятность, число в отрезке [0, 1]. Функция потерь при обучении — логарифм вероятности правильного токена (с минусом). Нас интересует только правильный токен, и только его логит нам нужен в числителе софтмакса. Логарифм в лоссе гасит экспоненту в числителе. Вычисление раскладывается на две части: вычисление логита правильного токена и вычисление слагаемого нормализации по E и всем столбцам C (логарифм суммы экспонент).
При обучении мы можем считать всё параллельно для всех токенов, поэтому там уже не вектор E, а матрица E.
Для вычисления логитов правильных токенов авторы выгружают блоки релевантных столбцов C и блоки E в кэш, считают там скалярное произведение, и выгружают назад в основную память только финальный результат. Вычисление логарифма суммы экспонент гораздо хитрее, как и вычисление его градиентов, но концепция та же.
Кроме собственно оптимизаций с кэшом, используется тот факт, что большинство значений на выходе софтмакса "плохие", то есть очень близкие к нулю. Из-за ограниченной точности чисел с плавающей точкой, "плохие" значения ни на что не влияют при использовании в слагаемом нормализации. И для них авторы предлагают просто не считать градиенты. Вторая оптимизация такого рода — сортировка словаря по средним логитам, чтобы токены с "плохими" логитами попадали в один блок, и можно было такие блоки полностью пропускать.
По классификации в прошлом посте — это AG метод, полезен только при обучении. Есть и древние альтернативы, да хотя бы иерархический софтмакс или адаптивный софтмакс.
Экспериментально для Мистраля Немо удалось уменьшить память на лосс+градиенты с 8 Гб до 1.3 Гб, что лучше, чем в Liger Kernel. Аналогичная (и иногда даже более существенная) экономия памяти есть и для других моделей.
Потрогать можно через их библиотеку и патчинг модели. То есть вы делаете вот такое:
После этого лосс и градиенты будут считаться как в статье. Но логиты не будут возвращаться, потому что они не материализуются в принципе.
Статья: https://arxiv.org/abs/2411.09009
Рецензии: https://openreview.net/forum?id=E4Fk3YuG56
Код: https://github.com/apple/ml-cross-entropy
Статья про оптимизацию памяти при подсчёте функции потерь и её ближайших градиентов при обучении языковых моделей. Основной механизм — модифицированная реализация перекрёстной энтропии, Cut Cross-Entropy (CCE). Авторы берут ровно ту же оптимизацию, которая используется в Flash Attention (поблочное вычисление в кэше GPU), но применяют её к последнему слою и последнему софтмаксу.
Последний шаг при предсказании следующего токена — линейный слой и софтмакс. На каждом шаге генерации у нас есть вектор E с последнего слоя трансформера, мы умножаем его на матрицу C, получаем логиты в ℝ^|V|, для каждого логита считаем экспоненту и делим на сумму всех логитов из всего словаря. Так для каждого токена получаем вероятность, число в отрезке [0, 1]. Функция потерь при обучении — логарифм вероятности правильного токена (с минусом). Нас интересует только правильный токен, и только его логит нам нужен в числителе софтмакса. Логарифм в лоссе гасит экспоненту в числителе. Вычисление раскладывается на две части: вычисление логита правильного токена и вычисление слагаемого нормализации по E и всем столбцам C (логарифм суммы экспонент).
При обучении мы можем считать всё параллельно для всех токенов, поэтому там уже не вектор E, а матрица E.
Для вычисления логитов правильных токенов авторы выгружают блоки релевантных столбцов C и блоки E в кэш, считают там скалярное произведение, и выгружают назад в основную память только финальный результат. Вычисление логарифма суммы экспонент гораздо хитрее, как и вычисление его градиентов, но концепция та же.
Кроме собственно оптимизаций с кэшом, используется тот факт, что большинство значений на выходе софтмакса "плохие", то есть очень близкие к нулю. Из-за ограниченной точности чисел с плавающей точкой, "плохие" значения ни на что не влияют при использовании в слагаемом нормализации. И для них авторы предлагают просто не считать градиенты. Вторая оптимизация такого рода — сортировка словаря по средним логитам, чтобы токены с "плохими" логитами попадали в один блок, и можно было такие блоки полностью пропускать.
По классификации в прошлом посте — это AG метод, полезен только при обучении. Есть и древние альтернативы, да хотя бы иерархический софтмакс или адаптивный софтмакс.
Экспериментально для Мистраля Немо удалось уменьшить память на лосс+градиенты с 8 Гб до 1.3 Гб, что лучше, чем в Liger Kernel. Аналогичная (и иногда даже более существенная) экономия памяти есть и для других моделей.
Потрогать можно через их библиотеку и патчинг модели. То есть вы делаете вот такое:
from cut_cross_entropy.transformers import cce_patch
model = ...
model = cce_patch(model)
После этого лосс и градиенты будут считаться как в статье. Но логиты не будут возвращаться, потому что они не материализуются в принципе.
А я напомнию, что индекс всех полезных постов всегда в закрепе: https://www.group-telegram.com/senior_augur.com/7
Telegram
Старший Авгур
Про локальные языковые модели для относительно неподготовленной аудитории:
Видео: https://youtu.be/KXBRGkZTX1U?si=CyVKSUavsSnZfffR&t=241
Презентация: http://tinyurl.com/gusevlocal
Подкаст: https://mlpodcast.mave.digital/ep-55
Про древнюю генерацию стихов:…
Видео: https://youtu.be/KXBRGkZTX1U?si=CyVKSUavsSnZfffR&t=241
Презентация: http://tinyurl.com/gusevlocal
Подкаст: https://mlpodcast.mave.digital/ep-55
Про древнюю генерацию стихов:…
The Pitfalls of Next-Token Prediction
Статья: https://arxiv.org/abs/2403.06963
Видео: https://www.youtube.com/watch?v=9V0bfZqT1Yo
Олды несомненно помнят, что в ранних seq2seq моделях, основанных на рекуррентных нейронных сетях, существовало два режима обучения: teacher-forcing, где на каждом шаге генерации в качестве входов использовались реальные токены, и другой режим с использованием токенов, предсказанных текущей версией модели. С появлением трансформеров и их параллельного обучения все стали использовать teacher-forcing. Авторы статьи возвращаются к этому вопросу.
🔹Задача
Авторы придумали простую синтетическую задачу: поиск пути между двумя вершинами в деревьях очень специфичной структуры, а именно в таких, где есть одна центральная вершина и несколько цепочек, исходящих из этой центральной вершины. Пример такого дерева (степень центральной вершины = 2, длина цепочек = 5):
Условия задачи:
— Степень центральной вершины и длина цепочек фиксированы для всех деревьев в обучающей и тестовой выборке.
— Путь всегда начинается в центральной вершине.
— Путь всегда заканчивается в одном из листьев.
Вход для задачи выглядит как случайно перемешанный набор рёбер дерева, плюс начало и конец пути (после "/"):
Выход выглядит как сам путь:
Эту задачу мы решаем какой-нибудь моделью, которая умеет работать с последовательностями, например трансформером или рекуррентной сетью в авторегрессионном режиме (генерация токенов слева направо, как в языковых моделях).
🔹Эмпирическая часть
— Авторегрессионные модели не справляются с решением этой задачи даже для деревьев с фиксированной структурой. Потому что сложно понять, в какую сторону идти от центральной вершины.💀
— При развороте пути задача успешно решается авторегрессионными моделями. Это логично, потому что так гораздо проще: вы просто поднимаетесь по родителям, пока не найдёте центральную вершину.📈
— Если во время обучения маскировать уже пройденную часть пути, модели также успешно решают задачу без разворота. Это странно, потому что мы делаем задачу сложнее для модели, заставляя её генерировать весь путь сразу. Но каким-то образом на такой версии задачи модель учится, а на оригинальной — нет.😱
Я потратил пару вечеров и воспроизвёл это в Колабе: ссылка. Воспроизводил для 2-5 деревьев, то есть ровно таких, как в примере выше. Код писал с нуля, но опираясь на их Гитхаб. Всё получилось, как написано в статье: усложнение задачи приводит к возможности её выучивания. Технически это выглядит просто как маскирование части input_ids.
🔹Про предсказание следующего токена
Щепотка "соломенного чучела": распространенная критика языковых моделей состоит в том, что они являются лишь "стохастическими попугаями", способными только предсказывать следующий токен. Считается, что из-за этого они не могут эффективно планировать или исправлять ошибки.
Однако авторы статьи предполагают, что основная проблема не в механизме предсказания следующего токена как таковом. Проблема — в teacher forcing'е, то есть в том, что во время обучения у модели нет необходимости планировать и пытаться сформулировать решение в активациях. И ведь большинство современных моделей обучалось именно с использованием этого метода.
🔹Ограничения
— Эмпирическая часть работает при фиксированном наборе гиперпараметров, и сломав их, можно сломать 2 и 3 наблюдение. Обучение и обучаемость таких моделей — это прежде всего оптимизационная задача, и там есть значительная доля случайности. Однако ни у меня, ни у авторов не получилось сделать модель, которая была бы контрпримером для первого наблюдения.
— У авторов нет никакого теоретического обоснования наблюдений. Как нет и алгоритма, по которому сеть считает путь. Мне кажется, что тут есть простор для творчества и механистической интерпретации.
Статья: https://arxiv.org/abs/2403.06963
Видео: https://www.youtube.com/watch?v=9V0bfZqT1Yo
Олды несомненно помнят, что в ранних seq2seq моделях, основанных на рекуррентных нейронных сетях, существовало два режима обучения: teacher-forcing, где на каждом шаге генерации в качестве входов использовались реальные токены, и другой режим с использованием токенов, предсказанных текущей версией модели. С появлением трансформеров и их параллельного обучения все стали использовать teacher-forcing. Авторы статьи возвращаются к этому вопросу.
🔹Задача
Авторы придумали простую синтетическую задачу: поиск пути между двумя вершинами в деревьях очень специфичной структуры, а именно в таких, где есть одна центральная вершина и несколько цепочек, исходящих из этой центральной вершины. Пример такого дерева (степень центральной вершины = 2, длина цепочек = 5):
8 ← 1 ← 5 ← 4 ← 3 → 0 → 2 → 6 → 7
Условия задачи:
— Степень центральной вершины и длина цепочек фиксированы для всех деревьев в обучающей и тестовой выборке.
— Путь всегда начинается в центральной вершине.
— Путь всегда заканчивается в одном из листьев.
Вход для задачи выглядит как случайно перемешанный набор рёбер дерева, плюс начало и конец пути (после "/"):
3 → 4 | 5 → 1 | 4 → 5 | 0 → 2 | 3 → 0 | 1 → 8 | 6 → 7 | 2 → 6 / 3 7
Выход выглядит как сам путь:
3 → 0 → 2 → 6 → 7
Эту задачу мы решаем какой-нибудь моделью, которая умеет работать с последовательностями, например трансформером или рекуррентной сетью в авторегрессионном режиме (генерация токенов слева направо, как в языковых моделях).
🔹Эмпирическая часть
— Авторегрессионные модели не справляются с решением этой задачи даже для деревьев с фиксированной структурой. Потому что сложно понять, в какую сторону идти от центральной вершины.
— При развороте пути задача успешно решается авторегрессионными моделями. Это логично, потому что так гораздо проще: вы просто поднимаетесь по родителям, пока не найдёте центральную вершину.
— Если во время обучения маскировать уже пройденную часть пути, модели также успешно решают задачу без разворота. Это странно, потому что мы делаем задачу сложнее для модели, заставляя её генерировать весь путь сразу. Но каким-то образом на такой версии задачи модель учится, а на оригинальной — нет.
Я потратил пару вечеров и воспроизвёл это в Колабе: ссылка. Воспроизводил для 2-5 деревьев, то есть ровно таких, как в примере выше. Код писал с нуля, но опираясь на их Гитхаб. Всё получилось, как написано в статье: усложнение задачи приводит к возможности её выучивания. Технически это выглядит просто как маскирование части input_ids.
🔹Про предсказание следующего токена
Щепотка "соломенного чучела": распространенная критика языковых моделей состоит в том, что они являются лишь "стохастическими попугаями", способными только предсказывать следующий токен. Считается, что из-за этого они не могут эффективно планировать или исправлять ошибки.
Однако авторы статьи предполагают, что основная проблема не в механизме предсказания следующего токена как таковом. Проблема — в teacher forcing'е, то есть в том, что во время обучения у модели нет необходимости планировать и пытаться сформулировать решение в активациях. И ведь большинство современных моделей обучалось именно с использованием этого метода.
🔹Ограничения
— Эмпирическая часть работает при фиксированном наборе гиперпараметров, и сломав их, можно сломать 2 и 3 наблюдение. Обучение и обучаемость таких моделей — это прежде всего оптимизационная задача, и там есть значительная доля случайности. Однако ни у меня, ни у авторов не получилось сделать модель, которая была бы контрпримером для первого наблюдения.
— У авторов нет никакого теоретического обоснования наблюдений. Как нет и алгоритма, по которому сеть считает путь. Мне кажется, что тут есть простор для творчества и механистической интерпретации.
Please open Telegram to view this post
VIEW IN TELEGRAM
Поздравляю всех подписчиков с наступающим Новым годом!
Про свои личные итоги года я писать не очень хочу: съездил в пару-тройку стран, написал статью, как-то поработал. Поэтому напишу про прочитанное и просмотренное, кому-то точно будет интересно.
Статьи:
— Zoology: крутая синтетическая задача (MQAR) и обоснование того, чего не хватает современенным рекуррентным сетям.
— Чувствительные функции: обоснование невыучиваемости трансформерами мегапростой задачи, parity.
— Медуза: критически важная штука на практике, ускорение моделей чуть ли не на порядок.
Сериалы:
— Pantheon: мультик про бессмертие через загрузку сознания, с крутыми сюжетными поворотами и неожиданным масштабом.
— Агент времени: китайское аниме про парней, которые умеют перемещаться в человека и момент на фотографии, чтобы добывать информацию.
— Severance: у главного героя и его коллег 2 физически отдельных личности на работе и вне работы, и в какой-то момент это становится проблемой.
Фильмы:
— Когерентность: очень дешёвый и очень прикольный фильм про параллельные вселенные. Да и в целом рекомендую весь жанр НФ триллеров, которые сначала маскируются под обычные ужастики: Прочь, Нет, Мы.
Игры:
— Balatro: карточный рогалик в покерной стилистике с кучей прикольных механик, в который я вбухал сотни часов.
— Factorio: Space Age: в представлении не нуждается. Скоро будет ровно 10 лет с того момента, как я купил оригинальную игру. DLC добавляет космические платформы и другие планеты с другим распределением ресурсов. А ещё дроны теперь открываются сильно позднее, поэтому приходится всё делать нормально.
— Marvel Rivals: новый командный геройский шутер. Очень зашёл мне, как постоянному игроку первого Overwatch.
Книги:
— Вселенная Боба: крепкая развелкательная фантастика (а я другого нынче почти и не читаю). Главный герой — человек, переродившийся в зонд фон Неймана, сначала спасающий Землю, а потом исследующий космос.
— Диктатор: скорее социальная фантастика про параллельную версию Земли и про человека, который хотел мира во всём мире.
— Вавилон: сокрытая история: фантастика про лингвистику в декорациях Оксфорда начала 19 века. Классная концепция, но слитая концовка.
Про свои личные итоги года я писать не очень хочу: съездил в пару-тройку стран, написал статью, как-то поработал. Поэтому напишу про прочитанное и просмотренное, кому-то точно будет интересно.
Статьи:
— Zoology: крутая синтетическая задача (MQAR) и обоснование того, чего не хватает современенным рекуррентным сетям.
— Чувствительные функции: обоснование невыучиваемости трансформерами мегапростой задачи, parity.
— Медуза: критически важная штука на практике, ускорение моделей чуть ли не на порядок.
Сериалы:
— Pantheon: мультик про бессмертие через загрузку сознания, с крутыми сюжетными поворотами и неожиданным масштабом.
— Агент времени: китайское аниме про парней, которые умеют перемещаться в человека и момент на фотографии, чтобы добывать информацию.
— Severance: у главного героя и его коллег 2 физически отдельных личности на работе и вне работы, и в какой-то момент это становится проблемой.
Фильмы:
— Когерентность: очень дешёвый и очень прикольный фильм про параллельные вселенные. Да и в целом рекомендую весь жанр НФ триллеров, которые сначала маскируются под обычные ужастики: Прочь, Нет, Мы.
Игры:
— Balatro: карточный рогалик в покерной стилистике с кучей прикольных механик, в который я вбухал сотни часов.
— Factorio: Space Age: в представлении не нуждается. Скоро будет ровно 10 лет с того момента, как я купил оригинальную игру. DLC добавляет космические платформы и другие планеты с другим распределением ресурсов. А ещё дроны теперь открываются сильно позднее, поэтому приходится всё делать нормально.
— Marvel Rivals: новый командный геройский шутер. Очень зашёл мне, как постоянному игроку первого Overwatch.
Книги:
— Вселенная Боба: крепкая развелкательная фантастика (а я другого нынче почти и не читаю). Главный герой — человек, переродившийся в зонд фон Неймана, сначала спасающий Землю, а потом исследующий космос.
— Диктатор: скорее социальная фантастика про параллельную версию Земли и про человека, который хотел мира во всём мире.
— Вавилон: сокрытая история: фантастика про лингвистику в декорациях Оксфорда начала 19 века. Классная концепция, но слитая концовка.
У Anthropic пару недель назад вышел пост про агентов: https://www.anthropic.com/research/building-effective-agents
Он прекрасен тем, что определяет, что является агентом, а что не является. С точки зрения авторов поста, агент = система, в которой языковые модели динамически управляют собственными вызовами и инструментами, контролируя выполнение какой-то задачи.
Авторы утверждают, что для большинства случаев агенты не нужны: чем проще решение, тем лучше. С чем я полностью согласен👏
Основное содержание поста — примитивы и паттерны оркестрирования языковых моделей без агентов. Основной примитив: улучшенная языковая модель, которая имеет доступ к инструментам, поиску и памяти. Этот примитив может быть реализован по-разному, например через конечное число последовательных вызовов языковой модели.
🔹Паттерн 1: цепочка промптов
Если задача разбивается на несколько последовательных подзадач, их можно решать отдельными вызовами языковой модели. Например, если вы хотите сделать систему, пишущую книги, вы сначала делаете вызов для генерации названия книги, потом отдельные вызовы для краткого описания, содержания, выжимок глав и непосредственно самих глав.
🔹Паттерн 2: маршрутизация
Если ваше приложение разбивается на несколько возможных параллельных путей, то стоит сделать классификатор, который будет определять нужный путь, и специализированные промпты под каждый из путей. Например, если вы делаете чатбот с несколькими независимыми функциями (рекомендация фильмов, ответы на вопросы по фильмам, чат на общие темы), то стоит использовать этот паттерн. В древних чатботах часто был детектор интентов, который делал ровно это👴
🔹Паттерн 3: параллелизация
Если задача разбивается на несколько параллельных подзадач, то стоит их и вызывать параллельно. Например, если вам нужно извлечь огромный JSON из текста или переписки, возможно вам стоит извлекать его по кусочкам. Отличие от маршрутизации в том, что в ней нам нужна была только одна ветка, а тут нам нужны результаты всех вызовов.
🔹Паттерн 4: ведущий-ведомый😭
То же самое, что и параллелизация, только с динамическим количеством и содержанием подзадач. Например, так можно делать агрегацию результатов поиска.
🔹Паттерн 5: цикл оценки
Если есть чёткие критерии оценки качества выполнения задачи, то можно одной языковой моделью решать задачу, а другой — оценивать качество решения и давать обратную связь. И делать это в цикле. Это может работать много где, например в переводе текстов.
Ну и наконец последний паттерн — агенты, которые совершают действия в определенной среде, получают от среды обратную связь, и снова совершают действия.
Мне в разных местах в разное время пришлось использовать первые 3 паттерна. При этом тогда я не формулировал их как отдельные паттерны. Это не какие-то абстрактные штуки, это кристаллизация того, как удобно и просто строить системы (как и любые другие паттерны проектирования).
Он прекрасен тем, что определяет, что является агентом, а что не является. С точки зрения авторов поста, агент = система, в которой языковые модели динамически управляют собственными вызовами и инструментами, контролируя выполнение какой-то задачи.
Авторы утверждают, что для большинства случаев агенты не нужны: чем проще решение, тем лучше. С чем я полностью согласен
Основное содержание поста — примитивы и паттерны оркестрирования языковых моделей без агентов. Основной примитив: улучшенная языковая модель, которая имеет доступ к инструментам, поиску и памяти. Этот примитив может быть реализован по-разному, например через конечное число последовательных вызовов языковой модели.
🔹Паттерн 1: цепочка промптов
Если задача разбивается на несколько последовательных подзадач, их можно решать отдельными вызовами языковой модели. Например, если вы хотите сделать систему, пишущую книги, вы сначала делаете вызов для генерации названия книги, потом отдельные вызовы для краткого описания, содержания, выжимок глав и непосредственно самих глав.
🔹Паттерн 2: маршрутизация
Если ваше приложение разбивается на несколько возможных параллельных путей, то стоит сделать классификатор, который будет определять нужный путь, и специализированные промпты под каждый из путей. Например, если вы делаете чатбот с несколькими независимыми функциями (рекомендация фильмов, ответы на вопросы по фильмам, чат на общие темы), то стоит использовать этот паттерн. В древних чатботах часто был детектор интентов, который делал ровно это
🔹Паттерн 3: параллелизация
Если задача разбивается на несколько параллельных подзадач, то стоит их и вызывать параллельно. Например, если вам нужно извлечь огромный JSON из текста или переписки, возможно вам стоит извлекать его по кусочкам. Отличие от маршрутизации в том, что в ней нам нужна была только одна ветка, а тут нам нужны результаты всех вызовов.
🔹Паттерн 4: ведущий-ведомый
То же самое, что и параллелизация, только с динамическим количеством и содержанием подзадач. Например, так можно делать агрегацию результатов поиска.
🔹Паттерн 5: цикл оценки
Если есть чёткие критерии оценки качества выполнения задачи, то можно одной языковой моделью решать задачу, а другой — оценивать качество решения и давать обратную связь. И делать это в цикле. Это может работать много где, например в переводе текстов.
Ну и наконец последний паттерн — агенты, которые совершают действия в определенной среде, получают от среды обратную связь, и снова совершают действия.
Мне в разных местах в разное время пришлось использовать первые 3 паттерна. При этом тогда я не формулировал их как отдельные паттерны. Это не какие-то абстрактные штуки, это кристаллизация того, как удобно и просто строить системы (как и любые другие паттерны проектирования).
Please open Telegram to view this post
VIEW IN TELEGRAM
Я тут почитывал https://situational-awareness.ai/, и очень мне приглянулась идея автономного агента-учёного.
Уверен, что таких проектов навалом на Гитхабе, но имхо без трёх вещей это не будет работать:
1) Инструмент для поиска по Arxiv и другим научным библиотекам. Причём нормальный, который может возвращать полные тексты, желательно с картинками.
2) Инструмент, эмулирующий файловую систему и её менеджмент.
3) Инструмент, позволяющий эффективно читать и редактировать текстовые файлы. Такой себе vim для LLM, который не жрал бы тонны токенов.
Под "инструментами" я понимаю нормальные API, доступные для вызова моделями.
Я завтра подробно подробно поищу все 3 штуки, но может быть кто-то что-то уже видел?
Уверен, что таких проектов навалом на Гитхабе, но имхо без трёх вещей это не будет работать:
1) Инструмент для поиска по Arxiv и другим научным библиотекам. Причём нормальный, который может возвращать полные тексты, желательно с картинками.
2) Инструмент, эмулирующий файловую систему и её менеджмент.
3) Инструмент, позволяющий эффективно читать и редактировать текстовые файлы. Такой себе vim для LLM, который не жрал бы тонны токенов.
Под "инструментами" я понимаю нормальные API, доступные для вызова моделями.
Я завтра подробно подробно поищу все 3 штуки, но может быть кто-то что-то уже видел?
Что нового я узнал за день?
— Во-первых, MCP и совместимые с ним сервера. В том числе ArXiv сервер, но мне не очень нравится конкретно эта реализация, там нельзя выбирать порядок сортировки результатов поиска, например. Но сам список в целом сойдёт как библиотека инструментов.
— Во-вторых, smolagents (агентский фреймворк от HF) и их подход к инструментам, которые можно автоматически заливать как Spaces на HF. И наоборот, использовать существующие Spaces как инструменты. Ещё прикольно, что основной подход в нём не function calling, а генерация кода с инструментами. Это, в частности, позволяет не завязываться на конкретную реализацию вызова функций. В качестве защищённого интерпретатора Питона они предлагают E2B. До этого я пользовался только Terrarium от Cohere.
— В-третьих, я пока не нашёл адекватной реализации инструмента файловой системы и редактора файлов, но я пока и недостаточно хорошо искал. Попробую воспроизвести или найти воспроизведение str_replace_editor из спеки Anthropic.
— В-четвёртых, всем спасибо за предложения. Часть я уже упомянул выше. findpapers мне пригодился как место, где можно подсмотреть код. storm имхо бесполезен.
Вывод пока такой: открытые инструменты довольно дерьмовы. А если делать свои — то проще всего делать аннотированные функции и потом экспортировать их в любой протокол или фреймворк. Что я и начал делать тут.
— Во-первых, MCP и совместимые с ним сервера. В том числе ArXiv сервер, но мне не очень нравится конкретно эта реализация, там нельзя выбирать порядок сортировки результатов поиска, например. Но сам список в целом сойдёт как библиотека инструментов.
— Во-вторых, smolagents (агентский фреймворк от HF) и их подход к инструментам, которые можно автоматически заливать как Spaces на HF. И наоборот, использовать существующие Spaces как инструменты. Ещё прикольно, что основной подход в нём не function calling, а генерация кода с инструментами. Это, в частности, позволяет не завязываться на конкретную реализацию вызова функций. В качестве защищённого интерпретатора Питона они предлагают E2B. До этого я пользовался только Terrarium от Cohere.
— В-третьих, я пока не нашёл адекватной реализации инструмента файловой системы и редактора файлов, но я пока и недостаточно хорошо искал. Попробую воспроизвести или найти воспроизведение str_replace_editor из спеки Anthropic.
— В-четвёртых, всем спасибо за предложения. Часть я уже упомянул выше. findpapers мне пригодился как место, где можно подсмотреть код. storm имхо бесполезен.
Вывод пока такой: открытые инструменты довольно дерьмовы. А если делать свои — то проще всего делать аннотированные функции и потом экспортировать их в любой протокол или фреймворк. Что я и начал делать тут.