Некоторые закономерности в ML. Теория, можно, сказать, и полученная эмпирически
https://habr.com/ru/articles/873110/

Продолжаем историю с постпроцессором для LLM.
https://telegra.ph/Posprocessing-dlinnye-dialogi-01-19
Проверяем технологию на устойчивость на длинных диалогах, а так же смотрим, какие вообще есть закономерности.
Если вкратце: можно модифицировать выход модели сильнее, чем с помощью Lora, можно получить больше креативности, но стабильность будет ниже. Для больше стабильности нужно что-то ещё.
А, и эта версия модели умеет решать задачу про собаку и сковородку)

Немного рассуждений про авторегрессионные модели (ну типа 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, плюс обученные адаптеры, плюс примеры датасетов (ну мелкие и лёгкие)
https://github.com/Kilorad/tea

Итак, делаем новую версию 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)

[Блог]

Вот недавно мы обсуждали LLaDA и жизнеспособности диффузионной парадигмы, а тут Inception Labs обьявили о создании Diffusion LLM, которая якобы способна бодаться по качеству (в бенчах приводят только код) с вполне себе сильными closed-source LLM (без рызонинга).

При этом она якобы на порядок быстрее небольших авторегресионных LLM, давая космические более 1000 токенов в секунду на одной H100, а не специализированных чипах.

Якобы оно могет еще RAG, tools use и агентность.

У них и чатик есть, можно потыкаться.

Выпустил новую версию 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. Во всяком случае, она отдебажена для Ламы.

В общем, пробуйте, всё есть в примерах. Код сыроват, может, найдёте какие-то баги - но он простой, баги будет вычистить легко

Паплайн целеустремлённого агента

Иногда в дискуссиях с людьми поднимается вопрос - а как работает система познания/система принятия решений, описанная неким товарищем? Скажем, когда человек рассказывает про некий ИИ на онтологиях (или теорию познания, не использующую аналог ML), возникает вопрос: как это работает? Обычно я слышу в ответ детали, как работает какая-то маленькая часть. Или слышу слишком абстракное объяснение, в котором детали-то как раз непонятны.

Поэтому я постараюсь привести пример пайплайма. Пример более-менее полного описания... Теории интеллекта, что уж там. Не специфического человеческого, а интеллекта в смысле "машины результатов".

Итак, наша система принятия решений (она же интеллект, она же "машина результатов") - это система управления, то есть имеет входы (сенсоры) и выходы (актуаторы). Если мы переходим в домен текста, ничего принципиально не меняется - то, что агент прочитал, является его входом, а то, что пишет - его выходом.
Кроме того, у агента должны быть предпочтения - для него одни варианты будущего должны быть "лучше", чем другие. Это может быть организовано по-разному - например, у агента есть формула (спущенная заказчиком или эволюцией), в которую мы вводим последние 100 кадров, а она выдаёт одно флотовое число - насколько это состояние среды "хорошее".

Дальше, у нас есть... По смыслу две компонента. Реализовано может быть по-разному, но более универсальное описание, что у нас два компоненты: модель среды и маршрутизатор.
Модель среды отвечает на вопросы "что будет, если?", а маршрутизатор использует её, чтобы проложить маршрут к цели (см. предпочтения) - или хотя бы получить первый ход из этого маршрута.

Модель среды - это некая статистическая модель, то есть это нечто, имеющее интерфейсы fit и predict. То есть в неё подаём последовательность наблюдений, нажимаем fit, и модель становится некоей формулой, которая по прошлому предсказывает будущее. Под этот шаблон равно подходят и нейронки, и законы физики, выведенные людьми. В случае физики fit - это то, что делал Кеплер с датасетом от Тихо Браге, а predict - это попытка предугадать следующую точку на траектории планеты, по формуле Кеплера.
Модель среды принципиально статистическая. Она порождена в первую очередь эмпирикой, потому что единственный критерий истинности модели - это её соответствие экспериментам (всем возможным). Я полагаю, что не существует другого способа строить модели. Все способы строить модель через рассуждения опирались на то, что рассуждения базируются на статистической модельке (то есть неким образом подобранной под датасет, как у Кеплера). То есть нельзя одной только мыслью познавать мир - так или иначе в вашем исследовании мира будет fit. Ну или мы родились с уже обученной моделькой - такое тоже бывает у многих животных.
Да. модель может выдавать вероятностный прогноз - она необязательно выдаст точные будущие наблюдения - может и выдать некое вероятностное рапределение.

Есть разные варианты маршрутизации. Например, очень тупой - насоздавать кучу траекториий, оценить их все (см. предпочтения) и выбрать ту, где суммарное предпочтение выше всего. То есть которая больше всего нравится заказчику. И сделать первый шаг по этой траектории., потом повторить процесс заново.
Есть более умный вариант - можно обучить что-нибудь типа advanced actor critic на этой модели среды, и применять для принятия решений на практике. Или можно обучать A2C прямо на самой реальности, а не на модели.
Конкретный процесс здесь - это детали, важно другое. В идеале надо, чтобы наш процесс принятия решений дал то же действие, что и перебор всех возможнвых траекторий. Все эти хаки - лишь способ аппроксимировать полный перебор по траекториям.

Ну и модель надо регулярно "кормить" новыми данными изх наблюдений и дообучать/обучать с нуля.

Это всё! Весь пайплайн: строим модель среды -> аппроксимируем поиск траектории с максимумом профита.

Как можно заметить, пайплайн пригоден для человека и для программы (для программы он годится получше), и вы всякий раз его задействуете, когда по новым наблюдениям узнаёте о некоей закономерности, или когда задаётесь вопросами "что мне делать? Что будет, если я сделаю то-то и то-то?".

И этот пайплайн равно пригоден как для задач вроде "выиграй в крестики-нолики", так и для задач вроде "сделай ракету с нуля". Потому что в обоих случаях нам нужно иметь модель среды (или полезно как минимум), и в обоих случаях мы можем перебрать разные планы/стратегии по этой модели. И подобрать такой план, который ведёт к лучшему результату.

Да, и в пайплайне есть явное разделение на познание (это построение модели среды) и принятие решений (это маршрутизация)

Что плохо сочетается с этим пайплайном?
С точки зрения целеустремлённого агента, разговор - это не обмен впечатлениями, а способ добиться чего-либо от другого агента. Так что склонность людей поболтать такой агент перенимать не станет.
Кроме того, если какая-то задача плохо описывается через критерий успеха, то и пайплан целеустремлённости к ней подходит плохо. Но может так выйти, что все другие пайплайны пригодны здесь ещё хуже - это надо сравнивать.

https://github.com/Kilorad/bash_agent
Очередной Tool-агент, на этот раз мой.
Насколько я понял, есть две школы строительства tool-агентов:
1) Есть куча апи, агенты умеют к ним обращаться, апи дают инфу сразу в удобном виде. Плюс - дёшево и удобно, минус - обычно апи узкоспециализированные.
2) Есть 1-2-3 апи, но такие такие инструменты, через которые можно выразить примерно что угодно. Баш, питон и так далее. Плюс - универсально, минус - долго, опасно и требовательно к мозгам модельки.

Вот я пошёл вторым путём. Если кому интересно - welcome

Да, и это очень далеко от продовой разработки, я просто делюсь своей утилиткой, поэтому она может выглядеть несколько странно (одни зависимости от самописной либы chat_bots чего стоят)

Зато эта штука умеет выполнять команды вроде "нарисуй где мерцающий градиентный квадрат" или "какой у меня вендор оперативной памяти". В теории я хотел, чтобы этот агент умел решать задачи вроде "поставь мне unsloth на винду (прорубившись через тучи ошибок)", но на это мозгов агента пока не хватает

Ааа, так вот почему добавление bos-tokena у меня настолько улучшало качество генерации!

Зачем все LLM фокусируют attention на первом токене? (by DeepMind & Oxford)

Давно известно, что многие головы внимания у LLM упорно «смотрят» на самый первый токен последовательности (чаще всего это токен <bos>). В моделях вроде GPT, LLaMA или Gemma такое внимание занимает до 80% от всех голов!

Авторы показывают, что такой «слив» внимания на первый токен — это не ошибка, а очень полезный механизм. Он работает примерно как «нулевая операция» (no-op), то есть помогает головам внимания эффективно ничего не делать и не вносить ненужных изменений в представления токенов, когда они не нужны.

Зачем это нужно? Постоянное активное перемешивание информации между токенами ведёт к трём серьёзным проблемам:
1. Rank collapse — представления всех токенов становятся линейно зависимыми.
2. Representational collapse — сильно растёт косинусная близость соседних токенов.
3. Over-squashing — дальние токены перестают эффективно обмениваться информацией.

Чем глубже модель и длиннее контекст, тем сильнее она нуждается в этом механизме. А если убрать первый токен <bos> во время инференса, у модели, привыкшей к нему, качество генерации сильно падает.

P.S. Что-то оооочень похожее нам рассказывал профессор Вячеслав Дубынин на курсах химии мозга — у людей тоже есть механизм предотвращающий "смешивание" активаций. А, например, ЛСД его ослабляет, вызывая галлюцинации.

Статья

Претрейн и файнтюн, а так же проблема переобучения.
Типичный пайплайн обучения LLM такой:
1) вначале проводим претрейн на огромном датасете, в основном из "плоских", неразмеченных текстов.
2) затем файнтюн на instruct-задаче, то есть на парах вопрос-ответ
Второй пункт может дополняться ещё и RL, но в данном случае я не буду их разделять - будем считать, что примеры из instruct-датасета равнозначны примерам из replay-buffer у RL, с положительной наградой.

Что мне в этом не нравится? То, что процесс файнтюна плохо подходит для lifelong-обучения. Если мы будет тюнить сетку слишком долго, мы её переобучим. При этом если мы будет долго тюнить ту же сетку на претрейн задаче... Наверное, есть шанс переобучения, но лично у меня, при обучении адаптеров, этого не происходило никогда. Слишком большая разница между размером датасета и размером модели.
Для меня идеалом было бы некое обучение, которое можно проводить, получать новые семплы от RL, проводить дальше, получать новые семплы от дипсика, учить дальше, и продолжать этот процесс потенциально бесконечно, без скатывания в оверфит.
Я вижу, что сейчас основной способ решения этой проблемы - выстраивание регуляризации на базе KL-дивергенции между исходной моделью и зафайнтюненной. Эта регуляризация по крайней мере замедлит скатывание в оверфит.
Но... Для меня идеальная ситуация - когда датасет детерминирует модель. То есть когда продолжительное обучение приводит к тому, что модель находится в "равновесии" с датасетом, её обучение выглядит как колебания вокруг оптимума, и переобучения не происходит. Не нуно ловить момент, когда останавливать обучение - оно само остановится, так как модель уже скатилась в некий оптимум по loss, и он нас устраивает.
В общем, я это реализую просто - подмешиваю pretrain датасет в датасет для finetune. Из минусов - обучение идёт медленнее. Из плюсов - модель меньше оверфитится. В какой пропорции смешивать? Выглядит, что 140 к 1 (140 instruct задач на одну задачу прогноза книжек/статей) - это маловато, а вот 70 к 1 уже в самый раз.

Я это всё провожу на Tail Embedding Adapter размера ~1.5 млрд параметров при модели на 8 миллиардов. Возможно, при полноценном обучении LLM ситуация будет отличаться. Но наверное, не очень сильно - у меня многие закономерности обучения воспроизвелись, пусть и в меньшем масштабе.

P. S. Я всё обучаю TEA-2. Это новый адаптер, которые наконец-то включает sequential слои. Но я хочу обучить его поэффектнее, прежде чем публиковать.

Итак, наконец-то я довёл до результата TEA-2
Ссылка на репозиторий https://github.com/Kilorad/tea/

Прошлые части этой истории:
https://t.me/result_machine/137
https://t.me/result_machine/139
https://t.me/result_machine/141
https://t.me/result_machine/145

Итак, что у нас на этот раз? Я обещал сделать sequential адаптер, но так пока его и не сделал. В смысле код-то есть, но модель недостаточно хороша. А вот классический TEA получился неплохой и под много задач
Ссылка на модель https://disk.yandex.ru/d/Dy0y9i0Xn4c1Ww

На чём на этот раз учились и чего добивались?
1) Наука/инженерия. Адаптер предобучен на куче научных и инженерных статей и в какой-то мере в них ориентируется.
2) Работа tool агентом. То есть работа в условиях, когда нужно заранее неизвестное число взаимодействий с терминалом/поисковиком/памятью, а так же нужно чёткое следование инструкциям. Здесь датасет чисто RL-ный, то есть от фактического взаимодействия со средой.
3) Рассуждения. Тут частично RL, частично рассуждения от DeepSeek
4) Медицина. Модель была в том числе адаптирована под медицинские диалоги
5) Улучшение речи на русском.
6) Улучшение детализации: модель должна отвечать более конкретно и менее расплывчато

А теперь результаты тестирования. Сравнительный анализ ответов TEA и оригинальной модели:
https://disk.yandex.ru/d/SsvYnTp5ubdfTA
Если кратко: немного лучше следование инструкциям, лучше подробность и детализация.

Медицинские диалоги:
https://telegra.ph/Medicinskie-dialogi-s-TEA-06-17
Если кратко: довольно адекватно. Учитывая, что для Llama-3.1 русский язык не родной, здесь русский достаточно хорош. Хотя я бы его чуть доработал.


Тестирование в тактической игре (игра рукописная, игрок - LLM. Тест на рассуждения и следование инструкциям):
https://telegra.ph/Testirovanie-TEA-v-takticheskoj-igre-06-17
Это ограниченный тест, но... Победа. Qwen 2.5, в том числе дистиллят Дипсика, побеждает редко, Llama 3.1 вообще никогда


Вывод:
Получилась детализация и качество русского получше, чем у оригинала, следование инструкциям лучше, медицина... Просто неплохо. Но слишком много целей под слишком маленький (1.6 миллиардов) адаптер.

Наверное, надо рассказать, чё вообще происходит.
А происходит следующее: я тестирую кучу идей на тему того, как лучше и быстрее обучать LLM. Мне нравится подход TEA во многом потому, что его можно провернуть на не слишком мощном оборудовании, и адаптер будет иметь константную сложность (потому что ни аттеншена там нет, ни рекуррентности). То есть некий идеал - это модель, где трансформерная часть имеет, условно, 8 миллиардов параметров, а адаптер имеет ещё миллиардов 10, и оно вместе работает по качеству как 14-миллиардная чисто трансформерная моделька, зато может прожевать последовательности такой длины, где 14-миллиарная подавилась бы.

Текущие наблюдения:
- с sequential слоем перед адаптером (концепция TEA-2) качество получше, но не радикально, а вот скорость что на обучении, что инференсе, страдает серьёзно
- адаптер сам по себе исполняется быстро, но при превышении накоторого размера (в моём случае где-то 3 миллиарда параметров) он начинает дико лагать, взрывное падение скорости на инференсе
- если сделать адаптер mixture of experts, то его можно сделать больше (почти до 4 миллиардов) без серьёзных лагов, и он быстрее обучается (в смысле loss быстрее падает). Он и переобучается быстрее тоже, поэтому надо сильнее позаботиться об аугментации данных
- я сильно расширил датасет, поэтому у меня выросли требования к качество на широких доменах, поэтому новые адаптеры пока не выкладываю, ввиду их недостаточной шикарности
- экспертами в MOE (либо же всем адаптером) у меня является конкатенационный resnet. Это как multilayer perseptron, но выходы всех слоёв конкатенируются, а потом через линейный слой подаются на выход. Вообще-то выход большой - там словарь 128 тыщ токенов. Поэтому если у нас суммарно на всех слоях 10 тысяч нейронов, то это уже 1.28 миллиарда связей. Я подумал: жирно. Надо сделать боттлнек - узенький линейный слой между конкатенацией сигналов со слоёв и выходом. Он напрочь убивает обучаемость. Видимо, если мы хотим, чтобы модель быстро училась, надо вести градиенты от логитов на выходе к слоям по кратчайшему пути - то есть ну почти напрямую, как сейчас.

Какое отношение всё это имеет к машинам результатов? Концептуально машина результатов не очень сложна... На практике основной сложностью являются всякие MLные детальки - как быстро обучить, как сделать, чтобы вы не ждали целый день с мыслью "а оно точно учится?", как добиться быстрого инференса, как получить лучшее обобщение и лучшую ёмкость.

Ну и классная песенка, которую друг скинул со словами "это про тебя", и таки да, она отлично передаёт вайб данного проекта:
https://vk.com/video32685688_456243983

Занесу сюда это теоретическое рассуждение. "Для важных переговоров". Отвечает на вопрос "с чего вы взяли, что RL - это AGI", с теоремами.
Да, я использовал DeepSeek в написании, но не чтобы он всё написал за меня, а чтобы я просто привёл общую логику, а он корректно разложил по теоремам.
https://telegra.ph/Pochemu-RL---ehto-AGI-08-23
Постарался так же осветить и практические вопросы, вроде "почему всё равно нам RL недостаточно, и где этой теории недостаточно прагматичному разработчику"

NTM
Надо было в какой-то момент выложить свою NTM - neural turing machine.
https://github.com/Kilorad/ntm_bench.git
Вообще, так-то технология древняя. Это RNN с аттеншеном. Но я её чутка улучшил и протестил. Если трансформер логически является дифференцируемым словарём (внимание = взятие по ключу), то NTM логически - дифференцируемый массив (внимание = взятие по индексу)

Тестирую на алгоритмическом бенчмарке - создаю рандомные алгоритмы и подбираю их трансформером и двумя разными NTM. Бенчмарк игрушечный, но NTM-слой настоящий.

Вот метрики:

Final Test Results:
Transformer: CE 0.6312, Acc 0.6831
NTM Positional: CE 0.4982, Acc 0.6904
NTM Hybrid Content: CE 0.4967, Acc 0.6918

Я пробовал разные настройки генерации алгоритмов, в большинстве случаев на тесте NTM лучше трансформера.

А началось всё смешно - трепался с Grok, показал ему свой код NTM, а тот взял и фиганул тестовую среду. Почти эту, я её потом рукам допилил.

Полагаю, пора это показать.
Это продукт на базе LLM, платформа для текстовых РПГ-игр. Наша.
@EleonorHostessBot
Не что-то прямо сильно оригинальное с технической точки зрения, но с продуктовой - вполне себе.
Поддерживает как диалоги с различными персонажами, так и режим гейм-мастера (делаем затравку для приключения и играем), и режим квестов (предзаданные приключения)
В отличие от конкурентов - очень длинный контекст, за счёт особого устройства памяти