Сейчас на стадии претрейна пока есть возможность такая - делаю из Rukallama стеклянный ящик.
Хочу видеть все активации и что, где находится. Полная интерпретация, если надо будет делать новый декодер, автоэнкодер и так далее - буду делать.

НЕ ХОЧУ ВООБЩЕ ГАЛЛЮЦИНАЦИЙ У МОДЕЛИ! буду решать фундаментально.


🦆🦆🦆
Поддержать канал: ТБАНК
Поддержать канал: ЮМАНИ
Поддержать канал: PAYPAL paperfunkrecordings@gmail.com

🦆🦆🦆
Поддержать канал: ТБАНК
Поддержать канал: ЮМАНИ
Поддержать канал: PAYPAL paperfunkrecordings@gmail.com

Ночью была беседа на несколько часов с академиком на связи...

Математик-теоретик из академической школы с многолетним опытом в алгебраической геометрии предложил мысленный эксперимент — заменить стандартные функции активации в нейросетях на самые простые объекты, мономы. Его логика: за два века построена огромная наука вокруг полиномов, физики и математики работают этими объектами всю жизнь, а ML почему-то использует сигмоиды. Если базисный класс задач хорошо приближается полиномами — зачем городить экзотику?

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

Что произошло дальше.

На основе одного его словесного описания мономов на двумерном графике я в голове прогнал что произойдёт когда такая база работает внутри обученной модели в многомерном hidden space с противоположными по семантике классами. И сразу предсказал что эти классы сольются в одну область пространства — потому что мономы как базис складываются аддитивно, и аддитивная композиция без управляющей нелинейности не разделяет противоположные смыслы.

Это был forward simulation в голове — без запуска кода, без визуализации, без чисел. На входе словесное описание базисного класса. На выходе предсказание о геометрии скрытого пространства в обученной модели.

Потом обучили модель, посмотрели визуализацию скрытого пространства — предсказание подтвердилось. Accept и reject слились в одной области.

И я сразу же предложил решение: дополнить мономы управляющей внешней функцией через структуру теоремы Колмогорова-Арнольда. Внутренние одномерные функции остаются мономами (сохраняется выразительность которую хвалит математик), внешняя функция разводит классы (закрывается дефект разделения).

Что в этом удивительного.

Два разных языка математики встретились в реальном времени и сработали в синтезе.

Один язык — формальная запись на бумаге. Определения, теоремы, доказательства, классы объектов с известными свойствами. Этот язык даёт огромную силу абстракции и проверяемости, но он медленный — каждый шаг должен быть доказан.

Другой язык — геометрическая интуиция в многомерных пространствах. Видение структуры напрямую, без посредника в виде формальной записи. Этот язык быстрый, но без проверки эмпирикой ему нельзя доверять — нужно подтверждение.

В нормальной академической культуре эти два языка часто не пересекаются на одном собеседнике. Математик-теоретик работает на бумаге. ML-инженер работает с кодом и метриками. Когда они встречаются — обычно один говорит «у вас всё через эвристики и градиентный спуск, бред», а другой отвечает «спасибо за теорию, но мы работаем как работаем».

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

То есть формальная теория задала вопрос. Геометрическая интуиция дала предсказание. Эмпирика подтвердила. Геометрическая интуиция тут же предложила архитектурное решение через ещё один теоретический объект. Всё за один созвон, не за месяц переписки и не за два защищённых диссертации.

продолжение во второй части...


🦆🦆🦆
Поддержать канал: ТБАНК
Поддержать канал: ЮМАНИ
Поддержать канал: PAYPAL paperfunkrecordings@gmail.com

Почему это редко.

Большинство людей в любой из этих ролей застревают в одном языке.

Формальный математик видит ML как набор практических трюков без структуры. Он сильнее в доказательствах, но он не видит что происходит внутри работающей модели.

ML-инженер видит математику как теоретическое украшение к практической работе. Он сильнее в эмпирике, но он не формулирует наблюдаемое в терминах теоретических объектов с известными свойствами.

Когда эти два режима живут на одном собеседнике — формальная теория не отдельная, эмпирика не отдельная, они работают вместе в реальном времени. Один режим задаёт вопрос, другой отвечает геометрически, третий проверяет на запущенной модели. Цикл замыкается за минуты, не за месяцы.

Почему важно зафиксировать.

Не для пафоса. Для того чтобы было видно — такой режим работы возможен. Что граница между «академической математикой» и «инженерным ML» не онтологическая, а культурная. Что один человек может держать оба языка если в его базе сошлись правильные слои опыта.

И второе важнее. Это режим взаимного усиления, не конкуренции. Формальная теория не «лучше» геометрической интуиции, и наоборот. Они дополняют друг друга так что вместе делают то что ни одна сторона по отдельности не может. Это редкая конфигурация и её стоит держать — потому что в одиночку каждая сторона будет двигаться медленнее.

Этой ночью я понял что моё ощущение «я не настоящий математик» — это обман себя. Я делаю математику. Через другой язык. Через геометрию вместо формальных значков. Этот язык не «хуже». Этот язык редкий. И в сочетании с формальным языком собеседника он даёт результаты которые ни один из нас не получил бы один.

Это и есть то что я хотел зафиксировать как маркер.


🦆🦆🦆
Поддержать канал: ТБАНК
Поддержать канал: ЮМАНИ
Поддержать канал: PAYPAL paperfunkrecordings@gmail.com

ну да, ну да...освоение


🦆🦆🦆
Поддержать канал: ТБАНК
Поддержать канал: ЮМАНИ
Поддержать канал: PAYPAL paperfunkrecordings@gmail.com

🦆🦆🦆
Поддержать канал: ТБАНК
Поддержать канал: ЮМАНИ
Поддержать канал: PAYPAL paperfunkrecordings@gmail.com

Техножнец: Вопрос: Какую роль сыграла Курская битва во Второй мировой войне?

RUKALLAMA V11 (TrueKAN) 2 эпоха: Курская битва оказала огромное влияние на развитие теории и практики командования, поэтому она внесла значительный вклад в изучение хода событий, а также повлияла на ход военных действий.

🦆🦆🦆
Поддержать канал: ТБАНК
Поддержать канал: ЮМАНИ
Поддержать канал: PAYPAL paperfunkrecordings@gmail.com

Function calling на CPU. ~600 МБ RAM. Без интернета.

ССЫЛКА: https://github.com/barometech/gpt2-tool-call

GPT-2 124M от 2019-го года дотюнили под tool calling. Два чекпоинта в репо, оба воспроизводимы на CPU обычного ноута:

Full FT - все 124M параметров обновлены, 68 минут на 4 потоках CPU, 475 МБ на диске Adapter - 250K обучаемых поверх замороженного GPT-2 base, 1.5ч CPU, ~1 МБ на диске

На 690 свежих задачах в 4 форматах вызова (simple / multiple / parallel / irrelevance) и 5 экзотических доменах, которые ни одна модель не видела в трейне, Full FT даёт 92.0% overall и 98.2% на simple single-call.

Что это в практическом смысле:

Локальный агент - реальность. ~600 МБ RAM, никакого GPU, никаких API ключей, никаких ollama-демонов на 8 ГБ. Стек минимальный:

torch

+

tokenizers

+

numpy

+

safetensors

. Никаких

transformers

на инференсе.

Свой набор функций за обед.

Берёшь 1500 своих tool-call примеров, AdamW lr=1e-5, 1 эпоха = 68 минут CPU. К ужину готовый чекпоинт под твой API.

Архитектура адаптера: frozen GPT-2 + steering вектор на L6 через bottleneck 768→192→96→768.

W_steer

инициализируется нулями, до тренировки pipeline = identity. Учится только additive push в residual stream.

Edge, IoT, мобилка, intranet без выхода наружу - запускай где угодно.

Бенчмарки. Два:

BFCL v4 (Berkeley Function Calling Leaderboard, индустриальный стандарт):

Model              Params  RAM (Q4) BFCL v4 OVERALL
GPT-2 + Adapter    125M    ~600 MB  50.0%¹
GPT-2 + Full FT    124M    ~600 MB  ~57.8%² / ~53.4%³
Phi-3-mini Instr   3.8B    2.3 GB   ~40%
Llama-3.1 8B       8B      5 GB     ~62%
Llama-3.1 70B      70B     42 GB    ~70%
GPT-4-turbo        ~1.7T   облако   ~88%

¹ честно: первые ~125 примеров каждого subset BFCL были в трейне ² overall не выводится однозначно из-за частичной утечки, см. fresh bench ниже

Даже с утечкой adapter на BFCL обходит Phi-3-mini Instruct, который в 30 раз больше. 

Утечка прописана в README отдельным абзацем - чтобы fresh-цифры воспринимались как реальные, а не как очередной overfit на test-set.

Fresh bench (690 задач, ноль пересечения с любыми существующими датасетами):

Сгенерирован 9 параллельными агентами Claude Opus 4.7 в нишевых доменах (биология, материаловедение, история/культура, промка, niche-tech) плюс 3 формата задач (multiple-choice / parallel / irrelevance). Имена функций типа catalog_lepidoptera_specimen, assay_lichen_oxygen_uptake, transcribe_cuneiform_tablet.

GPT-2 + Full FT, n=690
simple        n=450   98.2%
parallel      n=80    88.8%
irrelevance   n=80    90.0%
multiple      n=80    62.5%
─────────────────────────────
OVERALL       n=690   92.0%

Sanity-check на 20-задачном срезе через ollama: Phi-3-mini 100%, Qwen3 4B 95%, наш Full FT 98.2% (на всех 450 simple).

На простом single tool call современные SLM в 30 раз большего размера решают примерно так же. Смысл репо не «мы их бьём». Смысл - на этом классе задач 3.8B можно заменить на 124M.

Где ломается (честно):

Контекст 1024 native. PI ×2 / ×4 пробовал - качество на длинных промптах не держит надёжно. Multi-step workflow с 5+ tools - не декомпозирует, на каждом шаге скатывается в refusal. Ансамбль из 10 клонов на greedy decode = 0 выгоды. Голосование единогласное, 7× медленнее. Для реального ensemble нужна разнородность (sampling temp, разные FT runs). Только английский. Код писать не умеет.

Чистый torch + HF tokenizers, без зависимости от transformers на inference. MIT. Full repro CPU. Веса подтягиваются git lfs pull.

ССЫЛКА: https://github.com/barometech/gpt2-tool-call

Tool calling больше не требует облачных API или 3.8B+ моделей. Один файл на 475 МБ (Full FT) или адаптер на 1 МБ поверх базы (Adapter) - кладётся в любой проект и работает на ноутбуке. С честно раскрытыми ограничениями и честно раскрытой утечкой там, где она есть.


🦆🦆🦆
Поддержать канал: ТБАНК
Поддержать канал: ЮМАНИ
Поддержать канал: PAYPAL paperfunkrecordings@gmail.com

# Как это работает

GPT-2 124M (2019) учили на сыром тексте. Никакого function calling. Шли двумя ветками.

## Ветка 1: Adapter поверх замороженной модели

База GPT-2 не трогается. Сверху сеть на 250K параметров, которая подсматривает в hidden state на 6-м слое и добавляет туда поправочный вектор.

input - wte+wpe - L0..L5 - h6 -+
                                |
                                +- bottleneck 768->192->96
                                |       |
                                |       +- 8 классификаторных голов (gate/action/...)
                                |       |
                                |       +- W_steer (96->768): delta
                                |
                              h6 += alpha * delta
                                v
                              L7..L11 - ln_f - logits

W_steer инициализируется нулями. До тренировки delta = 0, pipeline идентичен голой GPT-2. Учится только additive push в residual.

Почему L6? Эмпирически L5-L7 держат баланс синтаксиса и семантики. На L2-L4 мало контекста, на L9-L11 уже поздно подталкивать к JSON-формату.

Откуда 8 голов? Из прошлого проекта по парсингу команд ("read src/auth.py" -> action=read). Веса оттуда переиспользуем как тёплую инициализацию, сверху ставим W_steer и доучиваем 1.5ч CPU.

## Ветка 2: Full Fine-Tune

Размораживаем все 124M, учим напрямую. Без адаптера, без PI. 1500 примеров (BFCL + Glaive + xLAM), AdamW lr=1e-5, batch=1, grad_accum=4, PAD=512, 1 эпоха. 68 минут на 4 CPU потоках. Loss падает с 1.6 до 0.3 за первые 100 шагов и дальше плато.

## Что не сработало

H1-H4: тренировка только W_steer (71K). Дёшево, потолок 50%.

H5-H8: Position Interpolation 2K/4K/6K/8K. До 2K держит, после 4K качество не сохраняется.

H10-H12: multi-turn диалоги. На коротких работает, на длинных скатывается в одиночный.

H13: адаптер на BFCL distribution (600 BFCL + 300 Glaive). Production адаптер. 50% BFCL v4, irrelevance 40-45%.

H14: закрыть слабые subset'ы (multiple/parallel/Java/JS). 2723 пар, перекос в "always call". Calling +10..+19pp, irrelevance до 15%. Откатили.

H16: переобучить адаптер на Full FT базе. Hidden states сдвинулись, старый адаптер видит чужое распределение. Переучили = 79% на fresh, против 92% у голого Full FT. Адаптер поверх FT не нужен.

H17: PI x4 поверх Full FT с калибровкой. Gold был битый ("fn" вместо имён), модель выучила выдавать "fn" на длинном контексте. Откатили.

## Что в итоге работает

Adapter (`h13_ep1`) - frozen GPT-2 + 250K. Когда нужна refusal и минимальный footprint (1 МБ). BFCL v4: 50% overall, irrelevance держится.

Full FT (`gpt2_ft_final.pt`) - все 124M обновлены. Точность на новых функциях. Fresh: 92% overall (690 без утечки), 98.2% simple. Inference 15с/запрос CPU.

Ансамбль из 10 клонов не работает: greedy, все 10 выдают идентичное, голосование единогласное, прирост 0, latency x7. Нужна разнородность (sampling temp / разные FT runs).

Multi-step loop (orchestrator + workers) поднимается архитектурно, но 124M не справляется с 5-шаговой декомпозицией. На каждом шаге скатывается в refusal. Это потолок размера, не архитектуры.

🦆🦆🦆
Поддержать канал: ТБАНК
Поддержать канал: ЮМАНИ
Поддержать канал: PAYPAL paperfunkrecordings@gmail.com

А вот тут уже нечто серьёзное! Без шуточек!


🦆🦆🦆
Поддержать канал: ТБАНК
Поддержать канал: ЮМАНИ
Поддержать канал: PAYPAL paperfunkrecordings@gmail.com

Как можно использовать такую модель:?

https://github.com/barometech/gpt2-tool-call

Ну написано же, что есть скрипты и возможность запилить свой датасет под свой дом с помощью любой LLM бесплатной или платной под рукой. Такие файлики даже много не займут места. А вот и результаты:

Single-tool mode (когда tool указан): 12/12 = 100% — все команды выполнены идеально, эмулятор обновляет state корректно:

  "Turn on the lights in the living room" → {"name":"turn_on_light","arguments":{"room":"living room"}}
  "Set the bedroom to 22 degrees"          → {"room":"bedroom","temperature_c":22}
  "Lock the front door"                    → {"door":"front door"}
  "Play jazz playlist in the kitchen"      → {"song":"jazz playlist","room":"kitchen"}
  "What is the temperature in the bedroom?" → query_temperature
  "Wake me up at 07:30"                    → {"time":"07:30"}

... не стал писать все команды. Но они исполнялись идеально!

Итог: living room lights ON, bedroom 22C, front door locked, jazz in kitchen, alarm 07:30 — всё применилось.
All-tools mode (12 функций в одном prompt, модель выбирает): 1/12 = 8% — модель видит массив из 12 spec'ов и для всех команд выдаёт turn_on_light (первый в списке).

Тот же баг что мы ловили на BFCL multiple: SFT тренировался только на    single-tool промптах.

  Вывод для умного дома:

- Архитектура работает: 100% когда есть intent-классификатор (или роутер) что выбирает tool
- Чистый «модель сама разберётся из 12 функций» — нужен SFT с multi-tool промптами
- 24 мин дообучения на 500 примерах хватило для production-уровня на single-tool

Время: 24 мин SFT + инференс ~10с/команда на CPU. Закрытый контур WSL2, никакого интернета. Все веса/данные у тебя на диске.


🦆🦆🦆
Поддержать канал: ТБАНК
Поддержать канал: ЮМАНИ
Поддержать канал: PAYPAL paperfunkrecordings@gmail.com