Один из самых удобных способов записать данные это использование готовых форматов, такие как JSON или YAML.
Из плюсов такого подхода стоит отметить вот что:
🔸 готовый, повсеместно используемый и поддерживаемый формат
🔸 простой и понятный файл, удобочитаемый для человека
🔸 можно легко редактировать в любом текстовом редакторе без специальных программ и библиотек
Но есть и минусы
🔹 затраты времени при записи файла (кодирование данных в нужный формат строки)
🔹 затраты времени при чтении файла (декодирование данных в Python объекты)
🔹 размер файла увеличивается из-за разметки данных (скобки, запятые, переносы, отступы...)
🔹 перед записью все данные должны быть помещены в память в полном объёме (не всегда)
🔹 при чтении необходимо считать весь файл в память и только потом декодировать данные
Если нужно писать немного данных в несколько файлов, то затраты по времени не ощутимы. Обычно это файлы конфига или какие-либо метаданные. Это отличный вариант под такие задачи.
Есть и другой поход к записи файлов - это бинарные файлы. Используется, когда данных достаточно много и никто их не собирается читать глазками😳.
🔸 очень быстрая запись
🔸 чтение значительно быстрей чем JSON, YAML итд
🔸 размер файла значительно меньше, так как нет разметки
🔸 можно записывать данные по мере поступления не загружая всё в память
🔸 можно извлечь любую часть данных независимо
Из минусов
🔹 нужно определить свой формат записи данных (если не используете готовую спецификацию определённого формата)
🔹 не получится открыть файл и визуально понять что там записано, а для чтения файла потребуется знать его спецификацию.
🔹 не так-то просто создать такой файл без специальной библиотеки
В таком виде удобно записывать большой массив любых однородных данных. Например, мониторинг валютной биржи или кэшированная анимация 3D геометрии.
(Это не означает что нельзя записать данные разного типа, просто это будет не так удобно)
Представьте себе JPG-картинку. По сути это немного мета-информации и большой массив пикселей. Тоже самое со звуком или видео файлом. Поэтому, если вы попробуете открыть картинку в текстовом редакторе вы увидите что-то вроде такого
f15d cd29 a564 4578 ...
09e2 9bc4 a696 1253 ...
84e9 4de1 3b23 c24a ...
2534 5161 28e0 709d ...
...
Это и есть записанные байтики. И для их чтения требуется определённый софт который знает что с ними делать. Под каждый тип файла.
К чему это я? Читайте в следующем посте...
#tricks#basic
🌟Doc-to-LoRA и Text-to-LoRA: гиперсети как генераторы LoRA
SakanaAI предложила 2 новых способа работы с памятью и дообучением LLM. Оба используют одну идею - гиперсеть, которая генерирует LoRA-адаптеры на лету, вместо того чтобы каждый раз тяжелый процесс обновления весов под каждую новую задачу.
Вся суть в математике затрат. Достаточно один раз вложиться в такое вот мета-обучение и потом создание нового адаптера обходится в копейки - система тратит вычислительные ресурсы всего на один прямой прогон.
В итоге получается умный конвейер по производству плагинов. Вы скармливаете главной сети документы или описание задачи, а она моментально выдает готовый модуль. Отличный способ сэкономить бюджеты на компьют и время.
🟡Doc-to-LoRA
Метод базируется на популярной связке «учитель-ученик» из дистилляции контекста. Гиперсеть принимает документ, кодирует его через замороженную LLM и генерирует LoRA-адаптер за один прямой прогон, без градиентных обновлений под конкретный документ. Адаптер применяется к слоям проекции MLP базовой модели. После этого модель отвечает на вопросы о документе, не имея его в контексте вообще.
На синтетическом тесте NIAH гиперсеть обучалась на последовательностях в 32–256 токенов, но при инференсе работала с контекстами до 40К токенов (это 5х превышение тренировочной длины). Там, где Gemma-2-2b-it с окном 8К теряла информацию, Doc-to-LoRA сохраняла почти идеальную точность.
При этом базовой модели требуется более 12 ГБ видеопамяти для обработки контекста в 128К токенов, а вот адаптер от Doc-to-LoRA обходится менее чем 50 МБ независимо от длины документа.
На реальных QA-задачах цифры тоже довольно бодрые. В SQuAD метод сохраняет 82,5% точности по сравнению с подходом, когда весь текст просто лежит в контекстном окне.
На длинных документах качество держится в районе 85% при задержке 0,2 секунды против 40 секунд у классической дистилляции контекста.
По памяти разрыв еще жестче. Полная дистилляция с генерацией запросов занимает более 100 секунд и требует свыше 40 ГБ VRAM, а вот Doc-to-LoRA укладывается в 3,8 ГБ.
Та же схема работает с визуальными токенами через мультимодальную Gemma-3-4b-it. На сете Imagenette чисто текстовая модель выдала 75% точности при классификации картинок, хотя ни гиперсеть, ни базовая модель не видели визуальных токенов при обучении.
🟡Text-to-LoRA
Здесь текстовое описание задачи прогоняется через энкодер, который превращает его в вектор. Он объединяется с обучаемыми эмбеддингами слоя и типа модуля - гиперсеть знает не только саму задачу, но и для какого конкретно слоя нужен адаптер.
На выходе - матрицы A и B для всех целевых слоев сразу. Адаптер применяется к проекциям запросов и значений в каждом блоке внимания замороженной базовой модели.
В zero-shot на незнакомых задачах T2L набирает средний балл 67,7 по 10 бенчмаркам против 66,3 у мультизадачной LoRA и 55,8 у базовой модели без адаптации.
Качество LoRA чувствительно к формулировке. Размытый запрос дает слабый результат, тогда как четкое описание с указанием типа рассуждения не только улучшает точность, но и позволяет управлять стилем ответа.
📌Лицензирование: Apache 2.0 License.
🟡Статья
🟡Arxiv Doc-to-LoRA
🟡Arxiv Text-to-LoRA
🖥GitHub Doc-to-LoRA
🖥GitHub Text-to-LoRA
@ai_machinelearning_big_data
#AI#ML#LLM#LoRA#SakanaAI
🚀 SakanaAI представил Robust Agentic CUDA Kernel Optimization
Это новый подход, где LLM помогает оптимизировать CUDA-ядра для PyTorch.
• Слияние операций ускоряет forward/backward-проходы, результаты выше стандартных Torch-базлайнов
• Полный пайплайн: PyTorch → генерация CUDA-кода → эволюционная оптимизация во время работы
• Проверка через LLM: модели автоматически отмечают неправильные ядра (дает +30% к производительности)
• robust-kbench — собственный бенчмарк, где измеряют не только скорость, но и корректность работы LLM
Авторы пишут о 2.5x ускорении над PyTorch eager и даже 6x в линейных операциях❗️
Но большинство примеров — это тесты на слияние операций с неотюненной базой, так что цифры спорные.
К тому же PyTorch 2.5 уже внедряет похожие оптимизации ), поэтому такие рекорды могут быстро обесцениться.
Это интересный подход к самообучающимся AI-компиляторам, но заявленные ускорения стоит проверять на праактике.
🟢Github: https://github.com/SakanaAI/robust-kbench
🟢Статья: https://arxiv.org/abs/2509.14279
@ai_machinelearning_big_data
#AI#CUDA#PyTorch#SakanaAI#LLM#Optimizatio
✔️ Sakana AI придумали, как LLM самим сортировать контекст по важности
Обычные языковые модели читают текст как одну длинную ленту.
Что ближе к началу внимания - то “важнее”.
Что дальше - то модель видит хуже.
И тут появляется проблема: если важный факт спрятан где-то далеко среди шума, модель может его просто не использовать.
Она тратит внимание на всё подряд, вместо того чтобы сосредоточиться на главном.
Sakana AI предложили решение - RePo (Context Re-Positioning).
Идея очень понятная: модель получает модуль, который позволяет динамически “перепозиционировать” контекст.
Примерно как человек:
ты читаешь длинный документ, понимаешь, что важная часть была 20 страниц назад - и мысленно перечитываешь её, а лишнее игнорируешь.
Что делает RePo
- подтягивает важные куски информации ближе
- отодвигает шум и лишний текст
- помогает вниманию модели фокусироваться на нужном
В модели есть обучаемый модуль, который **переназначает позиции токенов по смыслу**, а не по порядку
✅ важно = то, что помогает уменьшать ошибку модели и правильно решать задачу
❌ второстепенно = то, что не помогает (шум), поэтому “отодвигается” по позициям
В результате модель с такой памятью начинает лучше работать там, где LLM обычно страдают:
- когда контекст длинный
- когда много шума
- когда важные детали раскиданы далеко друг от друга
- когда данные структурированные (таблички, списки, правила)
Авторы показывают, что RePo даёт заметный прирост устойчивости, при этом не ухудшая общее качество.
▶️ Устойчивость к шуму (Noisy Context)
Средний результат по 8 noisy-бенчмаркам:
- Обычный RoPE: 21.07
- RePo: 28.31
🟡 Прирост: +7.24 пункта (сильно)
Авторы отдельно фиксируют ключевую цифру:
на noisy-eval (4K контекст) RePo лучше RoPE на +11.04 пункта.
🔥 Примеры прироста на конкретных задачах
(везде RePo > RoPE)
- TriviaQA: 61.47 → 73.02 (+11.55)
- GovReport: 6.23 → 16.80 (+10.57)
- 2WikiMultihopQA: 23.32 → 30.86 (+7.54)
- MuSiQue: 7.24 → 13.45 (+6.21)
Это шаг к моделям, которые не просто “читают что дали”, а умеют сами организовать свою рабочую память.
🟡Подробности: pub.sakana.ai/repo/
🟡Статья: arxiv.org/abs/2512.14391
@ai_machinelearning_big_data
#RePo#SakanaAI#LLM#AI#AIAgents#Context#LongContext#Attention