Будущее LLM в XS, S, M и других размерах
Когда у вас спрашивают «сколько будет 2+2?», ответ приходит в ту же секунду, а когда хотим почесать затылок, да мы скорее всего даже не задумаемся, а просто сделаем, начинаем вести рука за голову, знаем когда остановиться, знаем что делать дальше. А теперь представьте, что на самом деле скрывается за 2+2: нужно знать что такое число, что такое конкретно 2, что такое формальная операция сложения, каким вообще правилам она подчиняется, вычислить, а еще вспомнить формальные правила арифметики и в конце осознать, что арифметика не является полной и замкнутой… ну да, о чем это я, мысль ушла, а ответа я так и не получил, это конечно же 5. Пользы мало, зато мыслительный процесс какой — не лучшее расходование ресурсов, не правда ли, «любая LLM»?
Краткий справка по LLM — это очень много раз повторяемая операция умножения матриц, сложения, вновь умножения и так далее, и много млрд-ов раз, и именно поэтому все они работают с большим кол-вом оперативной памяти, чтобы «держать в голове» все эти млрд параметров которые используются в вычислениях. Скажем, для популярной Llama 3.х 70B (млрд) параметров нужно порядке пары сотен ГБ видео памяти (слово ГБ это млрд байт если что). И главное, ворочать вот эти млрды параметров и умножений нужно как при вопросе »2+2» так и «напиши эссэ на тему этнической принадлежности северных народов мира». Назревает резонный вопрос, а точно ли так расточительно должен работать интеллект?
Логично предположить, что для каждой задачи должен быть свой инструмент, как в нашей голове, на какие-то вопросы мы отвечаем пол секунды, а где-то надо пару дней подумать, порисовать, посчитать, записать. И возникает вопрос, а как заранее понять на сколько сложный этот вопрос?
Архитектура или как понять, что запрос достоин большего?
Мы просто берем и строим матрешку из XSLM, SLM, MLM, LLM и других моделей, понятно зачем — оптимизировать запросы и выбирать нужный, под свою задачу. НО сразу же упираемся в тезис »Ведь вначале нужно классифицировать запрос по его сложности, и понять к какой из моделей нужно обратиться», только потом выбрать «исполнителя» и дать ему запрос, это же дополнительное звено в цепи, которое при этом может тоже ошибаться и снижать общие метрики качества модели.»
И снова, знание процесса, как течет мысль в наших мозгах, подсказывает нам ответ — если мы не можем ответить быстро, начинаем «думать» т.е задействовать бОльшую часть мозга, обращаться к другим отделам, вспоминать какие-то факты или дополнительные инструменты, которые нам помогут. Скажем вопрос »2+2» был простым, а вопрос «вычислить сумму чисел от 1 до 100 с пропуском каждого 7 числа» уже таковым не кажется, и ты заранее понимаешь, что надо бы тебе вспомнить что такое арифметическая прогрессия, какая там формула, а возможно ты этого и не знаешь и тогда надо брать ручку и бумажку и идти ее выводить (а может вообще спросить у ChatGPT), и все это ты понимаешь еще до того момента как начал что либо вычислять.
И если в двух словах, то «первый» мыслительный процесс подсказывает тебе, что стоит обратиться ко «второму». Тут мы плавно подошли к тренировке нашей комбинированной модели. Обучение языковой модели обычно проводится на задаче предсказания следующего слова или токена. При этом в наборе данных используется специальный токен завершения, который сигнализирует модели, что на этом текст заканчивается. Это позволяет модели, например, на запрос '2+2' корректно ответить '4' и завершить генерацию текста, не добавляя ничего лишнего.
Теперь же мы создаем архитектуру, при которой модели могут перенаправлять друг другу запросы и нам нужен еще один специальный токен — «я не знаю, нужна помощь старшего брата» (хотя можно не заводить токен, а обойтись командой). Младшая модель получает запрос, пытается на него ответить, но понимает, что этот запрос слишком сложен, и просто передает его на шаг выше.
Как технически устроен процесс обучения:
Кормим младшей модели запрос → получаем ответ → берем запрос и ответ и кормим старшей модели, используя ее как арбитра → она смотрит, где младшая модель несет чушь или не знает ответа, помечается символом переадресации запроса → повторяем много раз.
Итог: у нас получается первый слой системы, в котором обрабатывается все очень простое, второй, в который идет не большая часть более сложных запросов и т.д
Итого по ресурсам: мы экономим в разы на инференсе младших моделей, при этом на сложных запросах удорожаем все буквально на доли процентов, потому что символ «помощь старшего брата» требует генерации пары тройки токенов младшей модели перед тем как отдать старшей.
Вообще говоря, младшая модель может не просто «просить о помощи», а высказывать какой-то свой вариант и возможно и попросить уточнений или развить ответ, и потом это можно завернуть в какой-то RL алгоритм и постепенно «перенимать знания старшего брата» … ну это уже совсем другая история.
Мы разобрали способ «общение» между моделями, с целью более грамотного распоряжения ресурсами, но в целом, такой подход очень активно используется в мультиагентных системах, когда несколько моделей решает задачу и она дробится на части или даже уровни принятия решения, создавая своего рода «ИИ бюрократию», но это скорее необходимость, потому что, скажем, для создания полноценного программного продукта не хватит никакого контекстного окна, да и вообще удержать в «голове» весь проект у ИИ пока не получается, но возможно это и не надо, должна быть сеть.
P.S подобными механиками можно заниматься без сверх больших вычислительных ресурсов и создавать практически применяемые дешевые решения. Интересно Сбер, Я, Т-тех смотрят ли в этом направлении?
