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


🦆🦆🦆
Поддержать канал: ТБАНК
Поддержать канал: ЮМАНИ
Поддержать канал: 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