Сегодня отдыхаем от Траска

В Главе 7 нет конкретики по коду, поэтому на словах объясню, о чём речь в главе.

Если раньше мы ковырялись в каждом отдельном нейроне под микроскопом, пытаясь понять, как крутится каждый «рычажок» веса, то теперь пора выкинуть лупу (и пупу, простите🤣) и взглянуть на архитектуру сверху.

До этого момента мы рисовали подробные схемы с кружочками и линиями -а что если в скрытом слое вашей сети 500 нейронов,

Траск даёт решение:

Решение — блочное представление. Эндрю сравнивает это с конструктором LEGO: нам больше не важны внутренние штырьки каждой детали, нам важно, как слои-векторы стыкуются с матрицами весов.

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

l2=relu(l0W0)W1.

Эта глава — мостик (как говорил Невский: "Я - мостик между Россией и Америкой!") к реально сложным структурам вроде сверточных сетей, где данные зацикливаются и проходят через одни и те же блоки многократно.

Кот в Коде|@kot_research_bot

Трансформеры - про Майкл Бея или про нейронки?

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

Что мы будем дебажить в ближайшее время:

• Мы залезем под капот трансформеров 😏чтобы понять, как именно ИИ «смотрит» на наши данные. Мы разберем, почему хваленые «роли» (вроде «Ты — Senior Developer») на самом деле вносят семантический шум и портят код.

• Мы выясним, почему XML — это не «устаревший формат», а единственный способ направить узкую «лупу» внимания нейронки (Sliding Window) в нужное место вашего проекта.

Тебе нада не нада?

Вообще эта инфа будет полезна всем - от запросов рецептов и блогинга до написания тысячных строк кода так, чтобы потом бампер не отпал.
Так что тут кому как - кому почитать и пролистать, кому реально поможет "меньше текст запроса - больше решения задачи" .

Готовьте блокноты и ручки, будем записывать хронологию понимания промтов.

Кот в Коде|@kot_research_bot

Итак, одну тему +- закрыли, теперь нужно переходить к следующей. До этого мы рассуждали про то, почему нейронки врут, что за этим следует и к чему может привести.

Теперь самое время адаптироваться: побеждает не самый сильный, а тот, кто умеет подстраиваться под движение жизни.

Что лучше скармливать модели — плоские таблицы CSV или вложенный XML?

Минутный ликбез:

• CSV — это плоская таблица (как Excel, но текстом), где данные просто разделены запятыми.

• XML — это ветвистое дерево (как папки внутри папок), где данные упакованы в именованные теги <вот так>.

ИИ читает данные не как человек, а через Sparse Attention (избирательное внимание) и Sliding Window (скользящее окно). В пределах 100–200 токенов «окна» GPT видит данные почти как в Full Attention — ей плевать на формат, важна логика разделителей. Но когда проект разрастается, вы упираетесь в физику процесса.

Вот база для реальной адаптации Дирижёра:

1️⃣ Разделители имеют значение. Если используете Gemini, забудьте про запятые в CSV. Запятая страдает Полисемией (многозначностью). Переходите на разделитель «|». Тесты LOFT показывают, что вертикальная черта — гораздо более чёткий семантический сигнал для модели.

2️⃣ Ловушка каузальности. GPT читает последовательно, и Summary смысл формируется именно в конце строки. В XML это работает нативно: в закрывающем именованном теге (например, </ID_17>) модель упаковывает весь смысл блока. Если вы суёте атрибуты в начало строки (<row name="...">), вы нарушаете порядок: Summary идет раньше самих данных.

3️⃣ Семантический суп. Огромная ошибка — использовать одинаковые теги типа <row>. Внимание модели начинает коррелировать одинаковые термины, и данные перемешиваются. Логиты Qwen доказывают: именованные парные теги дают 99% вероятности правильного предсказания границ блоков. Даже бессмысленные ID лучше, чем плоская куча одинаковых названий.

4️⃣ Прайминг семантики. Использование атрибутов в открывающем теге — например, <Human nationality ="RU" Hobby="Football"> — это «чит-код». Модель получает обзор (overview) ситуации ещё до того, как начнёт вникать в описание. Это резко снижает риск галлюцинаций.

Для работы с длинным контекстом (свыше 2000 токенов) обязательна древовидная иерархия XML из секций не больше 1000–2000 токенов. Именно поэтому Gemini великолепно «переваривает» сметы и налоговые отчеты на 500к токенов — там есть жесткая структура, за которую цепляется внимание.

Кот в Коде @kot_research_bot

Адаптируемся дальше

В разных пабликах до сих пор процветает настоящий карго-культ: люди верят, что если приписать в начале промпта «Ты — Senior Developer», то нейронка внезапно поумнеет. Это опасное заблуждение. На самом деле, ролевые инструкции — это просто семантический шум (бесполезные данные), который чаще вредит результату, чем помогает.

Основа обучения кодингу — это SFT (обучение на готовых примерах), где модели скармливали миллионы пар «задача → код». Если посмотреть на датасеты типа Codeforces, вы не найдете там никаких ролей. Там есть только условие и идеальная реализация. Модель в этом процессе работает как Translation Machine (машина перевода), которая переводит ваше описание задачи на язык кода, точно так же, как она переводит с русского на английский. Ваше «представь, что ты сеньор» для её логического слоя ничего не значит, потому что её IQ живет в слое высоких абстракций, который изолирован от стиля общения.

Проблема начинается тогда, когда роль всё-таки срабатывает, но в «литературном» слое. Инструкция «Ты — Senior» заставляет модель не писать код лучше, а подражать социальному поведению. Она начинает городить over-engineering (избыточное усложнение), втыкать тяжелые инструменты типа Wolfram там, где хватило бы одной строчки на Python, или вовсе сокращать комментарии, решив, что «сеньорам и так всё очевидно»😎

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

Академические дискуссии и научные работы подтверждают: задание личности агента в 5% случаев вообще ухудшает показатели MMLU (тест на общие знания). Единственное, что реально коррелирует с ростом «IQ» — это установка на Openness (открытость новым идеям), когда мы просим модель не выбирать решение мгновенно, а откладывать выбор как можно дальше, удерживая суперпозицию смыслов (состояние неопределенности). Всё остальное — это просто прайминг (настройка фона), который превращает разработку в дешевую театральную постановку.

Роль — это удобный интерфейс для автора промпта, а не инструкция для модели. Когда вы заставляете ИИ играть инквизитора или сеньора-помидора, вы стимулируете «занятную болтовню», которая кажется наукообразной, но не имеет отношения к реальности. Никто не учится программировать по фильмам о хакерах, и нейронка — не исключение.

Кот в Коде|@kot_research_bot

Раз мы решили похоронить карго-культ ролевых игр, самое время разобраться, как на самом деле заставить «цифрового джуна» не лажать на сложных задачах.

Замечали ли вы, что нейронки (особенно китайские Coder-модели) начинают «спотыкаться» и плодить ошибки, как только проект выходит за рамки простого скрипта?

Всё дело в дообучении на размеченных примерах «вопрос–ответ» — основном этапе обучения кодингу. Модели годами натаскивали на парах «задание → код». Важный нюанс: более 90% примеров в датасетах — это короткие куски до 4000 токенов. Это «нативная» зона компетенции любой LLM (большие языковые модели). Когда вы просите её сгенерировать модуль на 10–15 тысяч токенов, логические связи внутри «мозга» модели рвутся, и она заполняет пустоты статистическим шумом. Чтобы этого избежать, нам нужны «рельсы» — ИИ-контракты.

Я недавно наткнулся на методологию GRACE (запомните её 🤔), которую я сам того не замечая использовал, например, здесь. Оказывается, я интуитивно шёл по этой иерархии: сначала накидал граф связей (плата -> UART -> трансивер), потом прописал логику режимов и только в конце — конкретные функции. Это полностью заменяет внешнюю документацию, потому что весь архитектурный замысел вшит прямо в код в понятном для ИИ виде.

А теперь давайте обратимся к датасетам типа HumanEval (тоже запомните 🤔). Это набор из 164 задач, где модели учили строго одной вещи:
превращать Docstring (комментарий) в рабочий код.

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

Из этого вытекает правило:

Любой комментарий-контракт должен стоять СТРОГО ДО блока кода 

Трансформеры — это каузальные модели, они читают и пишут строго слева направо. Если вы даёте описание после реализации — поезд уже ушёл, магия SFT не сработает. Но если контракт идёт первым, ИИ воспринимает его как «микро-ТЗ» и просто «компилирует» его в следующий за ним блок кода, используя свой самый отточенный навык.

Кот в Коде|@kot_research_bot

😮 Друзья, вспомните под последним постом я написал вам, чтобы вы запомнили про GRACE и датасеты типа HumanEval?

Так вот, я тут порылся в информации по этим пунктам... и мне стало довольно-таки интересно почитать и написать про эти темы побольше.

Давайте так, если под последними постами я увижу вашу активность реакциями и/или комментами - сразу буду пилить по этим темам посты.

Потому что темы довольно-таки масштабные, и то, что я написал под последним постом - капля в море.

Как вы на это смотрите? 👁

Казалось бы, инструменты настроены, Дирижёр готов. Но на этапе масштабирования — когда в ход идут рои агентов, десятки навыков (Skills) и модные MCP-сервера — нас ждёт новая ловушка - «Бюрократический ИИ» 🧐

Проблема в том, что разработчики часто пытаются компенсировать недостатки моделей не инженерными решениями, а усложнением инструкций. Мы пишем промпты на три страницы, подключаем MCP-сервера, которые впрыскивают в контекст «простыни» деклараций, и в итоге суть задачи тонет в шуме.

Тут срабатывает фундаментальный «Баг простоты»: чем сложнее и длиннее мы объясняем инфу, тем хуже нейронка её усваивает. Это прямая отсылка к нашей магии 40 токенов — ИИ лучше всего работает с короткими, атомарными и понятными блоками данных.

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

Финальный инструмент в нашей адаптации — Универсальный конструктор-экзоскелет. Это не «ролевая игра» (мы же помним, что роли — это шум?), а жёсткий алгоритм, который заставляет ИИ сначала построить план действий и критерии истины, а уже потом выдавать код. Мы не просим его «быть умным», мы заставляем его работать по протоколу.

Схема промпта-шаблона для ваших задач:

«У меня есть [ОБЪЕКТ/ЗАДАЧА] для [ЦЕЛЬ/СФЕРА ДЕЯТЕЛЬНОСТИ]. Твоя задача – помочь мне улучшить [ЧТО ИМЕННО УЛУЧШАЕМ]. Для этого разбей задачу на [ПЕРЕЧЕНЬ ЭТАПОВ АНАЛИЗА, например: источники, извлечение факторов, синтез] и действуй по алгоритму ниже.

В первом ответе ты запросишь мой [ИСХОДНЫЙ МАТЕРИАЛ: вопрос, текст или идею]. Получив его, помоги:

Сформулировать [КОЛИЧЕСТВО] главную цель и [КОЛИЧЕСТВО] уточняющих [ВОПРОСА / ГИПОТЕЗЫ / ПОДЗАДАЧИ].

Указать, какие [РЕСУРСЫ / ДАННЫЕ / КРИТЕРИИ] считать допустимыми доказательствами или базой.

Провести Double-check: дать правила для верификации и «красные флаги» (чего избегать).»

Объяснение промт-шаблона выше:

Этот шаблон в квадратных скобках — это на самом деле не «просьба», это пример процедурного контракта.

• Вы не просите его «быть кем-то». Вы задаёте ему алгоритм работы: «Сначала спроси данные -> потом выдели цели -> потом определи критерии».
• Это по сути Мета-контракт. Мы заставляем ИИ сначала построить «рельсы» для самого себя (сформулировать контракт задачи), а уже потом ехать по ним. В этом нет противоречия, если объяснить, что мы заменяем «литературщину» на «протокол».

Этот метод принудительно выводит модель из режима «статистического угадывания» в режим анализа. Мы сначала фиксируем «рельсы» задачи, и только потом жмём на газ.

Кот в Коде|@kot_research_bot

главное, что работает ч.2 😂

Старые знакомые повержены в расплох

В прошлом году у меня была проблема в работе с SD-картой (то самое эхо прошлого).

После того, как я смог реализовать работу с метеостанцией и датчиком ветра, научрук мне говорит:
- Что ж, раз у тебя получилось сделать эти задачи и ты можешь записывать данные в Thonny… Пора вспомнить о задаче с SD-картой 🙂

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

Так что получается, проблему решил за одну пятницу, что поменялось?

Поменялось следующее:

1️⃣ Я поменял прошивку. Да, рабочая 1.26.0 прошивка служила мне верностью и стабильной работой на всех этапах работы, вплоть от инициализации модема и работы с сервером и до каши из подключенных станции и дачтиков… Но всё хорошее приходится отпускать и идти дальше. Так я нашёл 1.27.0 (в прошлом году она ещё была на этапе preview) и там не сказать, что что-то сильно поменялось, но в комментах оставлю разницу прошивок.

Press F 1.26.0...

2️⃣ Нашёл инициализацию пинов. Но как? В Прошлый раз всё испробовал, подбор не сработал, шины не показали результатов… а всё оказалось намного проще, чем я думал.

Надо было просто посмотреть в прошивку на Arduino (которую используют другие прогеры… и я получил при работе со станцией ☹️)… и там были рабочие пины инициализации – по сути самое важное.

Ну решил ты эту проблему, плохо что ли?

Не плохо. Но и не хорошо.

Я думал, что раз мне дали задачу поиска рабочего способа реализации записи данных на SD-карту, то я сам должен разобраться во всех камнях… а по итогу мне просто дали прошивку и такие «на, разберись чё там, и используй эту инфу». Т.е. сразу дали решение, просто надо было по сути переписать с C-языка на Python всю работу с SD-картой. И тут пропала некоторая детская познавательная составляющая, что нужно всё самому найти, разобраться и постараться сделать так, чтобы ничего не взорвалось. Но по итогу, мне сразу сказали код от бомбы и дифьюзы.

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

😎 - попробовать самому, зато за результат будешь больше рад
😱 - да ладно, всё ж работает, и не важно, откуда нашёл инфу

Кот в Коде|@kot_research_bot

главное, что работает ч.3 😂

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

В прошлых постах я упоминал методологию GRACE как некий святой грааль для работы с ИИ. Но когда я решил провести глубокий дебаг этого термина, оказалось, что в мире научных работ (косвенно схожей с постов эта работа, есть ещё здесь и здесь) под аббревиатурой GRACE прячутся заумные алгоритмы для автоматической правки кода или RAG-системы* на графах. Короче - софт для софта.

А то, что делаю я в Thonny это не скрипт. Это человеческая архитектурная интуиция, адаптированная под мозги трансформеров.

Мой «лже-GRACE» на самом деле - это старая добрая инженерная школа:

1️⃣Top-down мышление: Сначала смотрим на систему сверху, а не втыкаем в одну строчку кода.
2️⃣ Data Flow: Прорисовываем путь байта от железки до экрана.
3️⃣Architecture-in-code: Замысел и «рельсы» живут прямо в комментариях.

Почему всё работало? Потому что я разложил логику по стрелочкам:
Hardware (плата + трансивер) -> Firmware (MicroPython + регистры) -> Host (PuTTY на ноуте).

Я не использовал никакие внешние «приблуды» или RAG-поиск. Я просто создал для ИИ контекстную карту еще до того, как попросил его написать первую функцию. Это фактически Literate Programming (грамотное программирование): мы пишем код не для машины, а создаем «сценарий» для нейросетевого переводчика.

Углубившись в PDF-статьях с arXiv, я не пренебрёг основной сути. Лучший экзоскелет - это умение декомпозировать задачу «от железа к софту» и фиксировать это в иерархии.

* RAG - генерация с дополненным контекстом

Кот в Коде|@kot_research_bot