Посмотрим на анонс LLM с новым алгоритмом внимания, в контекстное окно которой можно поместить проект по разработке ПО целиком с библиотеками и документацией. Обсудим почему  пока убедительнозвучит только $465 млн. инвестиций и разберемся с алгоритмом HashHop.

На прошлой неделе стартап Magic.dev анонсировал новую LLM модель LTM-2-Mini с контекстным окном в 100 млн. токенов как многообещающий прорыв в области разработки ПО. Во-первых из-за гигантского контекстного окна, в которое буквально можно запихнуть целиком со всеми библиотеками и документацией весь проект (10 млн. строчек кода), а во-вторых из-за нового механизма внимания, который позволяет модели действительно работать со всем этим контекстом. Я об это радостно написал в канале AI4Dev, а потом решил разобраться внимательнее - насколько оба этих пункта инновационны и что можно понять из анонса Magic. Спойлер - HashHop простой и логичный механизм, но помог ли он на самом деле понять пока невозможно.

Размер контекстного окна в 100 000 000 токенов

100 млн. токенов это 10 млн. строчек кода, много проектов действительно целиком поместятся в такое контекстное окно. Потенциально это означает, что LLM сможет создавать новый код и оптимизировать старый без использования RAG (т.е. не подмешивая отдельную базу знаний к ответам LLM), что снимает массу проблем с поиском информации и звучит очень перспективно. Но уже не ново. Весной 2024го исследователи Google опубликовали статью о модели с бесконечным контекстным окном. Т.е. создать  такую модель представляется возможным, проблема в том чтобы оно работало в условиях реальной жизни.  По идее бесконечное контекстное окно или даже окно в 100 млн. токенов потребует невероятных ресурсов памяти и тысяч GPU/TPU. Magic.dev утверждают, что их sequence-dimension алгоритм в их модели (что это такое - никому не известно) в 1000 раз эффективнее чем у LLAMA 3.1 405B. Модели от Meta потребовалось бы 638 GPU карт H100 на обработку запроса одного пользователя при 100 млн. токенов контекста, а LTM-2-Mini всего одна! А еще они забавно заявляют в анонсе: "нас 23 человека и 8000 GPU  H100". Звучит очень здорово, но без доказательств верится с трудом, почему тогда остальные так не сделали?

Заявленная и эффективная длина контекстного окна

За последние пару лет длина контекстного окна в моделях выросла на несколько порядков, однако на практике оказывается, что чем длиннее окно, тем сложнее моделям удержать внимание на всех указанных в контексте фактах. Проблема кажется интуитивно понятной. Что-то похожее просиходило со мной, когда в школе нам ставили по 8 уроков день - все что было после обеда покрывалось непрорываемой пеленой тумана.

Для оценки эффективности контекстного окна последнее время было принято использовать метод «Игла в стоге сена». В большой текст (контекст) добавляют случайный факт («иглу») и просят модель найти его. Такой подход имеет недостатки: «Игла» может выделяться по смыслу на фоне всего остального текста, что делает её легко узнаваемой. Модели учаться распознавать такие выделяющиеся факты, что упрощает задачу и снижет требования к ресурсам.

Чтобы получить глубокие и объективные оценки моделей исследователи из NVIDA создали и опубликовали (весной 2024го) бенчмарк RULER с набором более сложных синтетических задач. В разделе HashHop ниже опишу часть подхода, т.к. они похожи. Если посмотреть на результаты бенчмарка, то оказвается, что у большинства моделей реальные размеры контекстного окна при прогоне задач из бенчмарка значительно ниже, чем заявленные (см. результаты RULER). У некоторых моделей на порядок. Например в Qwen 2 можно отправить запрос на 128к токенов, а нормально использовать он сможет только 32к, все остальное потеряется.

Magic.dev заявляют, что они создали уникальный бенчмарк, но по сути он похож на уже сущетсвующий RULER и в чем тут принципиальный прорыв непонятно. Вот статистика по гитхабам этих двух проектов:

• GitHub RULER 33 форка, 528 звезд.

• GitHub HashHop 12 форков, 131 звезда

Ниже опишу как работает HashHop, т.к. по-моему это достаточно простой и изящный подход, который дает больше понимания о проблеме.

HashHop

HashHop — это новый метод оценки моделей с длинным контекстом, разработанный компанией Magic, который устраняет некоторые недостатки традиционных методов. Его основная цель — создать задачу, требующую от модели более глубокого понимания и способности эффективно хранить и извлекать информацию из длинных контекстов без использования явных или неявных подсказок, которые могли бы упростить задачу.

Как работает HashHop

HashHop устраняет эти проблемы за счет использования хешей — случайных последовательностей символов, которые не несут семантического смысла и поэтому не могут быть сжаты или «угадываемы» на основе содержимого контекста.

Модель обучается на парах хешей, где каждая пара выглядит как:

jJWlupoT → KmsFrnRa
vRLWdcwV → sVLdzfJu
YOJVrdjK → WKPUyWON
OepweRIW → JeIrWpvs
JeqPlFgA → YirRppTA

Задача модели заключается в том, чтобы запомнить и восстановить соответствующую пару, когда ей показывают только первую часть:

Решение: YOJVrdjK → WKPUyWON

Этот тест проверяет способность модели выполнять простую одношаговую индукцию, то есть находить соответствие между отдельными парами хешей. Однако реальные задачи часто требуют более сложных многошаговых операций. Для этого HashHop вводит задачу с цепочкой хешей (идея как в бенчмарке RULER). Теперь модель должна не просто воспроизвести пару, а восстановить всю цепочку:

Hash 1 → Hash 2
Hash 2 → Hash 3
Hash 3 → Hash 4
Hash 4 → Hash 5
Hash 5 → Hash 6

Решение: Hash 1 → Hash 2 Hash 3 Hash 4 Hash 5 Hash 6

Перемешивание цепочек

Для дополнительной сложности цепочки хешей могут быть перемешаны:

Hash 72 → Hash 81
Hash 4 → Hash 5
Hash 1 → Hash 2
Hash 17 → Hash 62
Hash 2 → Hash 3
Hash 52 → Hash 99
Hash 34 → Hash 12

Модель должна правильно восстановить связь между хешами в такой перемешанной последовательности, что требует от нее не просто запоминания линейной цепочки, а более сложной обработки данных.

Пропуск шагов

Ещё одно усложнение заключается в необходимости пропускать шаги. В некоторых вариантах задачи модель должна не только восстановить всю цепочку, но и сразу перейти от одного хеша к другому, пропуская промежуточные шаги:

Решение: Hash 1 → Hash 6

Это требует от модели способности удерживать внимание на нескольких точках в контексте и перескакивать через промежуточные шаги, что является более сложной задачей по сравнению с последовательным восстановлением. Чем-то напоминает подход работы с моделью chain of thought и сокращенный вариант вопрос и только ответ соответственно.

Итак, использование хешей позволяет моделям тренироваться на задачах, где они не могут полагаться на явные смысловые различия или другие подсказки. Это полезно не только для оценки их способности к запоминанию и извлечению информации, но и для изучения новых архитектур, которые могут быть более эффективными в работе с длинными контекстами. О чем и пишут Magic.dev в своем анонсе. А насколько это рекламная или отражающая их реальные достижения информация мы узнаем через какое-то время.

Упомяну на последок еще раз на наш телеграм канал AI4Dev, где мы пишем об использовании LLM в разработке софта. Там у нас обзоры тематических фреймворков, лекции по технологиям, истории внедрения LLM решений - в общем Хогвартс, для всех, кто хочет остаться востребованным ИТ специалистом в мире с LLM.