Ещё раз про новые роли AI-команд, надеюсь последний 🇨🇩.

В последнее время люди приходят к DS просят, сделать MCP. Люди, дорогие, эт не задача AI engineer, Data scientist. Это задача или разработки, или новой роли AI разработчик. А чтобы вы не забывали про роли, вот вам небольшой тлдр по AI-native профессиям со стороны ИИ.

И кстати, перестаньте мучать CDTO/CTO/CIO вопросами развития ИИ в вашей компании. Их задача проникновение ИИ инструментов в их область деятельности (разработка, процессы, инфра, поддержка и тп). А за развитие ИИ отвечает Head of AI/VP of AI/Chief AI Officer

Все, вечером будет про Kimi-K2.6

Читать полностью…

RPA Skills

По мотивам своих же заметок про вайбкодинг и набора промптов в репозитории cursor-vibe-prompts я оформил это как отдельные скилы для агентов, чтобы не пересказывать каждый раз длинный текст в чат.

- /rpa-init - скилл прогрева контекста по репозиторию, просит агента изучить код, прочесть доки, и код тестов, затем выполнить установку dev-окружения, прогнать тесты, написать короткий отчёт о проекте.

- /rpa-gen-rules - скилл который позволяет собрать или обновить правила для агента, внутри скилла лежат примеры под Cursor и под Claude Code, правила генерятся по методу слоёного пирога (чтобы агент сначала писал логику первого уровня, у которой нет зависимостей, потом второго и так далее), плюс правила описывают разработку по паттерну BDD.

- /rpa-feat - скилл добавления новой фичи строго по BDD, пишет план, генерит тесты, выполняет тесты (red), пишет код, гоняет тесты (green), гоняет все остальные тесты, актуализирует документацию и примеры, плюс выполняет линтер под конец.

- /rpa-bugfix - скилл исправлениия бага, сначала пишет тест на воспроизведение бага, потом фикс, потом полный прогон всех тестов и короткий отчёт о проделанной работе.

Скилы /rpa-init и /rpa-gen-rules работают сами по себе, ничего дополнительного писать не потребуется, а вот для /rpa-feat и /rpa-bugfix нужно передать на вход информацию о том что надо сделать, например текст из issue написать, иначе они не смогут правильно работать.

Репозиторий со скиллами:
https://github.com/EvilFreelancer/rpa-skills

Читать полностью…

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

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

Читать полностью…

Скилов много, оркестрации мало

Последнее время только и слышу у себя в информационном пузыре разговоры про skills. Сделайте skill на ревью, skill на деплой, skill на парсинг, skill на тесты, skill на документацию. Идея в целом годная, под небольшую задачу пилим небольшой skill с понятным триггером, коротким SKILL.md, парой reference-файлов и скриптами, такая постановка задачи действительно помогает агенту меньше фантазировать и чаще попадать в нужный флоу. Особенно когда такой skill вырос не из абстракции, а из реальной боевой задачи, реальных фейлов и реальных исправлений, типа вот я сижу пилякаю какую-нибудь штукенцию и хочу на будущее её автоматизировать.

Но чем дольше смотришь на такие системы, тем сильнее ощущение, что разговор про skills застрял на уровне отдельных кирпичиков, тогда как сама проблема уже давно находится этажом выше. В реальной работе задача почти никогда не равна одному skill. Нормальный инженерный процесс это сначала собрать контекст, потом выбрать режим работы, потом проверить спецификацию, потом написать или обновить тесты, потом сделать код, потом прогнать валидацию, потом на ошибке уйти в запасной сценарий, а иногда ещё и поднять второго агента на узкий участок.

Ну или чем Гейтс не шутит, собрать рой агентиков для решения одной большой задачи, а дальше каждому актору раздать небольшие задачки и спокойно идти спать/гулять/дебоширить.

И вот в этот момент становится видно, что сам по себе skill уже не является конечной сущностью. Он становится всего лишь одной операцией внутри более крупного маршрута. Отдельный skill умеет сделать шаг. Но бизнес-ценность появляется не в момент, когда агент умеет шаг, а в момент, когда он надёжно проходит всю цепочку шагов до проверенного результата.

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

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

Отсюда и появляется более интересная конструкция, которую я бы назвал скил-оркестратором или если хотите каскад скилов, по аналогии с каскадом классификаторов.

По сути это не один большой skill, который пытается вместить в себя всё, а коллекция маленьких skills со скриптами, шаблонами, reference-файлами и жёстко очерченными границами ответственности. Один skill собирает контекст. Другой читает спецификации. Третий пишет тесты. Четвёртый запускает проверки. Пятый делает ревью результата. Шестой оформляет итог.

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

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

И вот такой подход, как мне кажется, намного ближе к будущему агентных систем, чем бесконечное наращивание папки со skills. Skill сам по себе никуда не исчезает. Просто он перестаёт быть главной сущностью. Skill становится модулем. А главной сущностью становится оркестрация.

Читать полностью…

Ну чтож, обучение модели закончилось на 963 шаге, по предварительным тестам модель уловила шаблон выполнения ризонинга и даже частично логику работы с тулами, но забыла как говорить на русском языке и стала очень быстро уходить в галлюцинации и repetition loop, тут скрипт тестов, вот тут можно посмотреть отчёты, а тут будут веса адаптера.

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

В любом случае ещё попробую потестировать ранние адаптеры, может быть там будет результат получше.

UPD. Ну а пока проект ставлю на паузу, хочется заняться чем-нибудь другим, была ещё идея сделать дистил толстушки GigaChat на ruGPT3XL, но это уже как-нибудь потом.

Читать полностью…

Обучение ruGPT3XL-8k на ризонинг и агентных датасетах продолжается и судя по eval_loss на 500 шаге тренировка прошла свой предел точности, дальше походу начался оверфит.

Чепоинты эти я уже скопировал в отдельную папку, они нарезаны на шарды из-за особенностей FSDP, но сшить их не проблема, если eval_loss и дальше будет ухудшаться то стопорну тренировку и выкачу 500й чекпоинт.

Единственный нюанс который мне кажется странным в том, что eval/mean_token_accuracy даже на 550 продолжает улучшаться, хотя по логике не должен, но подожду до 650го шага, если там eval_loss сильно пойдёт вверх то на mean_token_accuracy смотреть смысла не будет.

Читать полностью…

Самый простой способ выветрить всю "магию" и шарм из VS Code и Cursor.

Читать полностью…

Как работает tool calling в vLLM

Валерий @neuraldeep и Александр @countwithsasha подняли тему (тыц и тыц) о том, как tool calling работает на стороне inference-движка, давайте разберём это на примере vLLM - одного из топовых движков для реализации tool calling паттерна, но к слову сказать аналогичным образом это устроено и в других движках.

Кратенько, нет единого формата tool calling, каждое семейство моделей придумало свой уникальный синтаксис. Hermes оборачивает вызовы в XML-теги <tool_call>, Mistral использует [TOOL_CALLS] с JSON-массивом внутри, Llama генерирует JSON внутри специальных тегов <|python_tag|>, DeepSeek пишет вызовы в тройных кавычках, и inference-движок должен это все уметь парсить.

Как tools попадают в промпт

Всё начинается с API-запроса, в протоколе ChatCompletion у vLLM для тулов есть два поля:
- tools - список доступных функций
- tool_choice стратегия вызова ("none", "auto", "required"`) или конкретная функция

Дальше tools передаются в chat template через render-слой, тут tools преобразуются в текст, который передаётся через системный промт на вход модели.

Парсинг ответа модели

Когда модель сгенерировала текст, движку надо понять, ват из зис за фак такой, обычный ответ или вызов функции?

Логика напрямую зависит от tool_choice:
- Конкретная функция (named tool choice) - весь вывод модели считается JSON-аргументами для этой функции (парсинг не нужен)
- "required" - вывод парсится как JSON-массив [{name, parameters}], используется всеми нами любимый structured output (JSON-схема), чтобы модель гарантированно сгенерировала валидный ответ
- "auto" - самый интересный случай, тут включается ToolParser, который анализирует сырой текст и ищет в нем tool calls

Базовый класс ToolParser определяет следующие методы:
- adjust_request() - модифицирует запрос перед генерацией, например, может добавить JSON-схему для structured output
- extract_tool_calls() - парсит полный вывод модели (non-streaming)
- extract_tool_calls_streaming() - парсит вывод по мере генерации (streaming), детектит токен за токеном

Все парсеры регистрируются через реестр ToolParserManager, который загружает нужный парсер по имени, активируется на старте через CLI флаг, например так `--tool-call-parser hermes`. На данный момент в vLLM имеется 32 парсера, в том числе и gigachat3 для новых сберовских моделей.

Пример - как парсит Hermes

Разберём как работает Hermes2ProToolParser, предполагается, что модель генерирует что-то вроде:

<tool_call>
{"name": "get_weather", "arguments": {"city": "Moscow"}}
</tool_call>

Парсер делает findall по регулярке <tool_call>(.*?)</tool_call>, вытаскивает содержимое, предполагается, что это JSON-схема, которую парсер раскладывает по объектам ToolCall(name=..., arguments=...), при этом текст до первого <tool_call> сохраняется как обычный content ответа, так как модель может ответить текстом и одновременно вызвать функцию.

В streaming-режиме уже есть нюансики, парсер на каждом новом токене перепарсивает накопленный текст, сравнивает с тем что уже отправил клиенту, и шлет только дельту. Отдельно отслеживается частичное совпадение с тегом <tool_call> - если текст заканчивается на <tool_, парсер придерживает его в буфере, не отправляя клиенту, пока не станет ясно - это начало вызова или просто текст.

Пользовательские парсеры

Если вы любитель обучать свои модели, хехех, хотите чтобы она умела тулы, но для вашей модели нет готового парсера, это не беда, можно написать свой парсер.

Флаг --tool-parser-plugin path/to/my_parser.py загрузит код парсера в реестр, а --tool-call-parser my_parser_name активирует его. Нужно только наследоваться от ToolParser и вызвать директиву вида @ToolParserManager.register_module("my_parser_name").

Итого

Вся магия tool calling это банальный промпт-инжиниринг + парсинг вывода.

За сим откланиваюсь, спасибо товарищам по вайбцеху за то что затронули тему внутреннего устройства движка vLLM, приятно поднять заметки и покопаться в кодовой базе.

Читать полностью…

RTX 4090 после модификации до 48гб у меня стала турбиной и под нагрузкой гудит аки самолёт на взлёте, поэтому решил перенести схему на gpu03, а там у меня 4x 5060ti.

Из недостатков, обучение запустить пришлось через torchrun, а unsloth studio как я понял так не умеет, поэтому красивых картинок не будет, только брутальные циферки в консоли.

Из занятных побочных эффектов, тесты показали, что код sparse attention ruGPT3XL-8k в классе модели неоптимален по памяти в режиме DDP и его можно улучшить, плюс 4x RTX 5060ti (16Гб каждая) показывают скорость на 80% выше чем одна RTX 4090 (48Гб), так что не 40 часов а 20-25.

Но самое интересное, квартет 5060ti почти не греется, их не слышно даже.

Читать полностью…

Тестирование GigaChat 3.1 10B на агентных бенчмарках

Обычно я не пишу про новые модели, тем более отечественные, но совсем недавно состоялся релиз моделей семейства GigaChat 3.1 от команды Сбера.

В линейке вышли две модели, на 702B и 10B параметров, обе построены как MoE и обе, судя по позиционированию, должны хорошо работать с русским языком, но моя специализация больше про агенты, поэтому я рассматриваю модели прежде всего как основа для агентов. Поскольку у меня нет ресурсов для запуска версии на 702B, выбор пал на 10B, так как после апгрейда моей RTX 4090 до 48 Гб памяти такой вариант вполне можно погонять локально.

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

С учётом прошлого опыта, когда промпт для тройки ещё пару недель доводили после релиза, я решил не спешить и отложил тесты, однако, пару дней назад появилась новость о том, что в vLLM была добавлена поддержка гигачатовского шаблона tool calling, и вроде как теперь тулами точно можно пользоваться.

Для оценки я использовал три хорошо знакомых мне бенчмарка, которые довольно быстро показывают, способна модель решать агентные задачи или нет:
- SWE - https://github.com/swe-bench/SWE-bench
- TAU - https://github.com/sierra-research/tau-bench
- BFCL - https://github.com/ShishirPatil/gorilla/tree/main/berkeley-function-call-leaderboard

На SWE модель показала 0%. Пришлось прям заморочится чтобы запустить тестирование модели на этом бенчмарке, а потом ещё и тюнить chat template пошел, потому что модель не хотела стабильно генерировать валидный diff patch, но даже это ситуацию не исправило, хотя с новым шаблоном промежуточные результаты стали чуть стабильнее.

На TAU результат тоже 0%. Модель уходит в бесконечные последовательности вызовов тулов и не может корректно определить, достаточно ли ей уже данных для завершения задачи или нет.

Единственным бенчмарком, который показал подозрительно (так как на остальных агентных бенчах результаты нулевые) высокие результаты, оказался BFCL. На нём модель набрала 89.5% на Simple Python, 91% на Multiple, а на остальных тестах результаты были уже скромнее - в районе 61%. Заодно этот бенч показал, что параллельные вызовы модель не поддерживает (но это возможно через правки промта можно поправить).

Результаты тестов, детали запуска и отладочные данные собраны здесь:
https://github.com/EvilFreelancer/gigachat-benchmarking

Чуда, к сожалению, не произошло. Складывается впечатление, что развитие больших языковых моделей пока не до конца синхронизировано с тем направлением, в котором сейчас движется объективная действительность, так как для практических agentic-сценариев одной только более-менее рабочей поддержки function calling уже недостаточно. Если модель не держит agentic loop, её прикладная ценность в таких задачах остаётся очень ограниченной.

При этом прогресс всё же есть. Если смотреть на дистанции в несколько лет, путь от ruGPT2 до почти стабильно работающего function calling - это заметный прогресс. Но по текущим меркам этого всё ещё мало.

Мой итоговый вывод довольно простой:

Использовать маленькую модель на 10B незачем, а большую на 702B - не на чем.

На мой взгляд, для среднего класса агентных задач куда интереснее выглядел бы формат MoE в диапазоне 100-150B в битности MXFP4, при этом и нижнюю границу компактной модели, как мне кажется, нет большого смысла опускать ниже 13B (как-то посчитать какой размер оптимальнее всего для 24Гб VRAM с контекстом 30-60k токенов), да и плюс размер эксперта в 1.8B маловато, к чему высокая скорость если модель не держит контекст и уходит в циклы.

Для себя выводы я сделал, подожду GigaChat 4, по моим ощущениям, она должна выйти осенью на AI Journey. Возможно, у новой модели ситуация изменится. Хотя вполне вероятно, что к тому моменту рынок снова успеет уйти вперёд.

Читать полностью…

Вайбкодерская мудрость:

Если кодовый агент не может справиться с кодом - значит надо взять модель поумнее.

Читать полностью…

Опубликовал пост "ruGPT3XL идёт в качалку / поднимаем контекст до 8k" на Хабр, в нём рассказал что было исправлено и добавлено по фидбэку после прошлого поста, а так же про то как я поднял максимальный контекст у модели с 2k до 8k токенов.

Веса конвертированной модели тут:
https://huggingface.co/evilfreelancer/ruGPT3XL-8k

Читать полностью…

Zloibit, pimp my LLM

Запостил на Boosty небольшой тизер публикации на Хабр про увеличение контекста у модели ruGPT3XL с 2k до 8k токенов, моделька уже лежит на HF вот тут:

https://huggingface.co/evilfreelancer/ruGPT3XL-8k

Читать полностью…

По совету хабровчанина внёс правки в код класса модели чтобы она обучалась без ошибок, проблема появилась после фикса Sparse Attention, надо было мне чуть дотошнее всё проверить.

Вдобавок ко всему по рекомендации от того же пользователя добавил в модель поддержку Triton, в результате чего на динамическом графе модели удалось достигнуть прироста в скорости инференса до 40%, а если выполнить torch.compile то и все 50% прирост.

Код класса модели тут: modeling_rugpt3xl.py
Подробнее про SDPA и бенчмаркинг тут: Training throughput (SDPA and Inductor)

Читать полностью…

Sparse Attention Is All I Need

Вчера в соседнем чатике мне задали резонный вопрос о том какие метрики использовались для оценки качества работы конвертированной ruGPT3XL модели? И это очень правильный вопрос, я честно не знал, что ответить, так как гонял тесты MERA в отрыве от её оригинальной версии, потому что оригинальную так и не смог запустить (слишком старое железо требуется для древнего мегатрона, пайчарма, апекса, куды и так далее).

Ну и в общем свербила меня эта мысль, думаю ладно, надо что-то сделать, проблема только в том какую метрику считать? Решил взять perplexity (PPL), так как она указана в карточках всех моделей, но тут возникла другая проблема, эта PPL должна быть на датасете на котором оригинальные модельки тестировались, а у меня его по понятным причинам нет, да и не уверен, что он есть даже где-то в недрах SberDevices, времени то прошло почти пять лет с тех пор.

Короче пришла идея взять любой датасет с русскими текстами, желательно не очень большой на 5-10k примеров и чтобы размерность примеров была в пределах 2k токенов, под это условие отлично подошёл датасет gazeta Ильи Гусева @senior_augur.

Решил делать так, взять значения perplexity из карточек оригинальных моделей, составить табличку, написать скрипт расчёта прям как в публикации про rugpt3 модельки, потом взять датасет gazeta и выполнить расчёт на rugpt3small, rugpt3medium, rugpt3large и моей ruGPT3XL, полученные циферки сравнить и посмотреть есть ли корреляция.

При первом прогоне тесты показали, что конвертированная модель сильно проседает по PPL, результат был 50.1, что примерно в 4 раза больше чем 12.05 у оригинальной модели, думаю ну не может же быть, стал копать, оказалось агент решил не портировать механизм Sparse Attention (разреженного внимания) и вместо него заюзал Self Attention, родной механизм внимания у GPT2 и производных.

Внимательно попинал агента, показал ему примеры кода с правильным механизмом внимания, дал почитать публикацию про модельки ruGPT3 и спустя некоторое время получил исправленную версию modeling_rugpt3xl.py с репликой аналогичного механизма из Megatron-LM.

Запустил прогонку расчёта PPL ещё раз и увидел уже красивые циферки 11.68, по всем замерам составил табличку и несколько графиков, подробности тут.

Дополнительная проверка кода llama.cpp показала, что код Sparse Attention там тоже не поддерживается и сконвертированная в GGUF моделька будет использовать неправильный механизм внимания, похоже придётся делать большой патч в llama.cpp, попытаюсь добавить поддержку ruGPT3XL туда уже полноценно.

Читать полностью…

Отстрелялся, выступать с докладом было весело, из занятных ситуаций которые произошли: оказалось что через вайфай не работает загрузка пакетов через pip, так что пришлось надеяться на воображение слушателей и мой навык комментирования кода, который я приобрел еще во времена когда стримил.

Были вопросы про сравнение проекта с OpenClaw, вопросы про настройки vllm (и required в частности), про внутреннюю логику работы тулов, ещё спрашивали советы вкатывальщикам в тему агентов и много каких ещё интересных вопросов.

Видеозапись велась, мне даже микрофон беспроводной дали, поэтому вполне возможно что выложу запись.

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

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

Короче такой вот веселый денек был.

Читать полностью…

Про AiConf

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

А всё потому что 20го числа я выступаю на конференции AiConf 2026 (к чему готовился всю последнюю неделю) с докладом в жанре мастер-класс про SGR Agent Core, планирую рассказать про наш фреймворк, как его ставить, запускать, как на нём писать своих агентов и под конец в какую сторону фреймворк будет развиваться.

В общем заходите на огонёк, до связи.

Читать полностью…

CLI Creator Skill

Тут ребятки из openai вчера релизнули новый curated skill — CLI Creator

Skill уже добавлен в Codex App

Он позволяет создать cli + skill для вашей рутины из имеющихся: API docs, OpenAPI JSON, SDK docs, curl examples, browser app, existing internal script, article, or working shell history.

Звучит потрясающе!

Я уже пошёл и проверил на себе. У меня был skill, который ходил в мой сервис по api (через curl + api key) и доставал read only инфу.
Сейчас попросил gpt создать cli версию этого инструмента.

Мы с ним обсудили то, как это будет выглядеть, добавили апдейтов (skill немного отставал) и с помощью моего planact реализовали задачу за 1.5 часа. Всё работает прекрасно!

Напоминаю, что главная идея такой связки cli+skill состоит в том, чтобы дать вашему кодинговому агенту доступ к вашему любимому сервису.
Юзкейс может быть, к примеру, такой: "Ок, агент, сколько пользователей у нас сегодня зарегистрировалось с параметром %PARAM%?". Агент подтягивает этот созданный skill, далее использует CLI, идёт в ваш сервис, тянет инфу и отвечает на ваш вопрос.

Так что если у вас есть какие-то процессы, которые можно так упаковать, то 100% рекомендую это сделать!

Кстати, этот skill является продолжением идеи Валеры и Паши — openapi-to-cli, инструмент который генерирует cli из вашего openapi. Кому актуально — тоже рекомендую!

#aicoding@the_ai_architect

Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!

Читать полностью…

Утром тесты, вечером код

Продолжаю делать заметки на полях о тонкостях работы с кодовыми агентами.

Почему я так много внимания уделяю методологиям BDD и TDD, и всегда пишу, что тесты важны и что кодовому агенту тесты стоит генерировать перед кодом?

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

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

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

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

<спецификации фичи>

Но если вы скажете модели перед реализацией фичи что-то типа:

изучи код, документацию и тесты, потом напиши тесты новой фичи, убедись что они падают, потом напиши код фичи, потом убедись что тесты проходят, потом проверь все остальные тесты
<спецификации фичи>

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

Агенту важно объяснить не только "что надо делать", но ещё и "как надо делать", тогда и результат будет стабильным и предсказуемым.

Читать полностью…

Вайб-дизайн Starterkit

18 марта 2026 года Google выкатили стандарт DESIGN.md (прототип которого они тизерили ещё в мае 25го года), если кратко, то это такой хитрый markdown-файл для переноса и импорта общих правил оформления дизайна между проектами и инструментами.

Поддержка данного стандарта уже начала расползаться по агентному стеку, у Google есть отдельный репозиторий stitch-skills, где прямо указана совместимость со Stitch MCP и агентами вроде Gemini CLI, Claude Code и Cursor, параллельно с этим вокруг формата уже вырос внешний зоопарк инструментов и гайдов, например designmd.app отдельно пишет про сценарии для Claude Code, Cursor, Kiro, Windsurf и Cline.


DESIGN.md это AGENTS.md, только для UI

Когда мы обсуждали вайбкодерский starterkit для агентов, речь в основном шла про то, как агент должен выполнять работу кодом.

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

То есть AGENTS.md, CLAUDE.md, Cursor Rules и прочие файлы такого рода обычно отвечают на вопрос "как агент должен делать код?".

А вот DESIGN.md отвечает уже на более абстрактный вопрос - "как агент должен делать интерфейс приложения?".


Что внутри DESIGN.md

В официальной идее Google и в уже появившихся примерах вокруг формата почти всегда повторяется один и тот же каркас:

- общее описание визуального характера продукта
- цветовая палитра и роли цветов
- правила типографики
- отступы и layout-принципы
- оформление базовых компонентов
- ограничения и анти-паттерны

Я ещё добавляю всякие хекс коды, размеры отступов, названия CSS фреймворков и тому подобные моменты, плюс в Cursor это хорошо ложится в общий свод правил .cursor/rules/ (можно например создать подпапку design), так как один общий файл для описания стиля всего со временем будет перегружен.


Простейший пример

Вот совсем примитивный DESIGN.md, которого уже достаточно, чтобы агент не улетел в рандом, взял его из официальной доки на сайте Stitch:

# Design System

## Overview
Calm, minimal interface for a SaaS dashboard.
High information density, but without visual noise.
The UI should feel professional, neutral, and slightly premium.

## Colors
- Primary (#2563EB) - primary actions, links, active states
- Surface (#FFFFFF) - main cards and panels
- Background (#F8FAFC) - app background
- Text Primary (#0F172A) - main text
- Text Secondary (#475569) - secondary text
- Border (#E2E8F0) - separators and input borders
- Danger (#DC2626) - destructive actions and errors

## Typography
- Headings - Inter, semibold
- Body - Inter, regular, 14px to 16px
- Small text - Inter, regular, 12px to 13px
- Use tight, readable hierarchy without oversized headings

## Spacing
- Use 8px spacing scale
- Cards should have generous inner padding
- Avoid cramped layouts, but keep density suitable for dashboards

## Components
- Buttons - medium rounding, filled primary for main CTA
- Inputs - light background, 1px border, no heavy shadows
- Cards - subtle border, soft shadow, clean flat surfaces
- Modals - centered, compact, clear action hierarchy

## Do's
- Keep layouts clean and structured
- Use primary color sparingly
- Prefer subtle contrast over aggressive accenting

## Don'ts
- Do not mix multiple accent colors
- Do not use glassmorphism
- Do not use oversized radii
- Do not make the UI look playful

На вид ничего необычного, те же правила, вид сбоку, но для агента это уже огромный шаг от "сделай красиво" к "вот конкретный визуальный стандарт, в рамках которого нужно работать".


Послесловие

Уже есть реп awesome-design-md, в нём собрана хорошая обновляемая подборочка материалов на эту тему, надеюсь она вам тоже пригодится.

Читать полностью…

Ребят в CodeDash появился лидерборд!

Зачем?
1) Интересно узнать на сколько вы отличаетесь от других вайбкодеров
2) Можно найти друзей по цэху и написать им через github
3) Можно поискать что же за проекты пилит автор если он их выкладывает в open-source
4) Можно поискать и хантить себе вайберов если вы поняли о чем я =)
5) Просто по фану измерить примерно сколько у вас в см запросов на фоне других вайберов
В общем качайте новую версию

codedash update && codedash restart

Синхронизируйте Github и регистрируйтесь в лидерборде!

Читать полностью…

Следуя советам Никиты @buckwheat_thoughts прокачал гиперпараметры обучения модели ruGPT3XL-8k, оказалось все мои прошлые попытки не маскировали инпут, а большой LR и прочие параметры приводили к оверфиту, теперь прогресс идёт намного стабильнее. Однако, это привело к увеличению времени обучения со 100 часов до 240, но лучше дольше чем неправильно.

(не пугаемся высокому train loss, из-за fsdp тренер пишет кривые числа, делим их на 32)

Помимо этого благодаря советам Александра @dealerAI смог ускорить процесс в почти 4 раза запустив обучение через FSDP (скрипт train_rugpt3xl_fsdp.py), все видеокарты загружены на максимум, время обучения снизилось с 240 часов до 42-46.

Плюс разобрался с тем как сделать "весёлые картинки", для этого внутри контейнера поставил и поднял tensorboard, и настроил тренер чтобы он писал логи куда надо.

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

Читать полностью…

Пока идёт обучение модельки ruGPT3XL 8k прикладываю скрипты тренировки внутри контейнера unsloth studio:
https://github.com/EvilFreelancer/rugpt3xl-train

На данный момент обучение идёт на 4x 5060ti в режиме "Multi-GPU pipeline", этот режим предполагает что веса одной модели "размазаны" по всем видеокартам и каждая из них поочерёдно выполняет часть работы, поэтому так долго.

Первая эпоха пройдена почти наполовину, train_loss похоже добрался до плато и шумит, а вот eval_loss мне пока не нравится, первый был сильно ниже чем второй, как бы оверфит не случился.

Читать полностью…

Агентная ruGPT3XL-8k

Задали мне на Хабр вопрос про доработку Unsloth Studio чтобы можно было модельку ruGPT3XL-8k дообучить.

Ранее я не пользовался данным UI и понятия не имел, сможет ли он потянуть такую задачу, полез разбираться и оказалось, никаких правок вносить вообще не нужно, Unsloth Studio спокойно подхватил и ruGPT3XL-8k, и датасет в формате SharedGPT.

Типа такого:

{
  "conversations": [
    {"role": "system", "content": "..."},
    {"role": "user", "content": "..."},
    {"role": "assistant", "content": "..."},
    {"role": "tool", "content": "..."},
    {"role": "assistant", "content": "..."}
  ]
}

Обучать я решил не абы как, а с прикладной целью, после опытов над ai-sage/GigaChat3.1-10B-A1.8B собрал свой SFT-микс, чтобы попробовать затюнить dense 1.3B модель под agentic-loop сценарии, где важны не просто ответы "вообще", а умение держать ход рассуждений, пользоваться инструментами и не разваливаться на многошаговых задачах.

По настройкам решил не изобретать велосипед и пошёл в достаточно консервативный QLoRA-сетап. Обучение крутится в 4-bit, с LoRA rank 16 и alpha 16, max_seq_length выставил в 8196, batch size 1 при gradient accumulation 8, так что эффективный батч получается 16. Learning rate - 2e-4 с cosine scheduler, warmup на 100 шагов, оптимизатор adamw_8bit, плюс gradient checkpointing от Unsloth.

Обучение провожу на 1x RTX 4090 пропатченной до 48Гб в сервисном центре Vik-On.

По датасетам тоже решил не мудрствовать лукаво, собрал винегрет английских и русских семплов, всего 150k записей.

Английская часть (82.5k) это тулколлинг, reasoning и agentic use cases из
- Mustafaege/qwen3.5-toolcalling-v2
- interstellarninja/hermes_reasoning_tool_use
- Featherlabs/featherlabs_agentic_v1
- arcee-ai/reasoning-sharegpt
По чуть-чуть из каждого датасета, с упором на agentic-loop.

Русская часть (67.5k) это
- belyakoff/xlam-ru-tool-calling
- HelioAI/Helio1-Reasoning-50K-RU
- ZeroAgency/ru-thinking-reasoning-r1-v2
- ZeroAgency/ru-big-russian-dataset
Но отфильтрованные по reasoning.

Кстати, хочу передать привет Александру @ak_segfault из ZeroAgency @zeroagency, спасибо за датасеты!

Через пару дней уже расскажу, что получилось по качеству после тюна, студия пишет что ETA примерно 40 часов с учётом прогонки eval.

Читать полностью…

Сегодня вышел пост "Цифровой сотрудник на OpenClaw: нанять, обучить и не потерять" на Хабр, в котором говорится о том, как во ВкусВилле запустили бота сотрудника на базе OpenClaw на модельке Kimi, это очень любопытная тема, я после их успеха с MCP-сервером для поиска товаров крайне внимательно наблюдаю за новостями от них.

Вначале поста мне понравилась оговорка "А пока мы готовимся к покупателям-агентам, расскажем, как агенты становятся нашими коллегами." - в интересном направлении идут, и ИМХО уж если где и есть люди обладающие волей продвинуть агентную коммерцию в нашей стране (привет Александру Абрамову @dealerAI и его команде), так это только ВкусВилл.

Читать полностью…

Когда поднимут цены на ИИ

Недавно мне пришлось оказаться на одной лекции, имен называть не буду, но общий настрой выступления можно описать так - человеку показали Claude Code, после чего он искренне поверил, что теперь "бизнесом можно управлять через ИИ", а "инженеры больше не нужны".

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

В ходе выступления демонстрировались разные примеры "внедрения ИИ". Один из них - внутренняя база знаний, собранная из большого массива текстовых файлов со спецификациями, часть которых оформлена в виде skills и хранится в Obsidian. Дальше схема выглядела примерно так: в папку inbox складываются почта, документы, заметки и прочие материалы, затем по расписанию запускается Claude Code, который обрабатывает весь этот массив, "каким-то" образом масштабирует базу, "как-то" векторизует данные, проставляет связи, строит граф и в итоге формирует систему, которая "в целом работает" и "что-то" делает.

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

Именно здесь возникает более интересный вопрос - не технологический, а экономический.

Чем больше компаний будут переводить процессы на подобные решения без глубокого понимания их устройства, тем выше вероятность, что крупные игроки рынка начнут увереннее пересматривать ценовую политику. Если бизнес уже встроил ИИ в ключевые процессы, если управленческий слой привык к такой модели работы, а часть прежней инженерной экспертизы уже сокращена или вытеснена, то пространство для манёвра резко уменьшается. В такой ситуации повышение цены воспринимается не как повод отказаться от инструмента, а как вынужденная операционная издержка.

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

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

Читать полностью…

Вечерняя мудрость:

Использование термина агентский вместо агентный в контексте ИИ агентов - маркер дилетанта

Читать полностью…

ACPBox - что обновилось за последние коммиты

Пока ковырялся в агентных интеграциях, довел ACPBox до состояния когда его реально удобно поднимать как универсальный OpenAI-совместимый шлюз поверх ACP агентов.
- Добавил вдобавок к OpenCode и Cursor поддержку Claude и Codex в контейнере
- Установка агентов перенесена в runtime, раньше я думал что логичнее будет ставить их на этапе сборки, это норм когда агент один, но когда их четыре... при помощи переменной AGENTS в environment можно перечислить через запятую список нужных агентов, чтобы лишнее не ставить, по дефолту ставится OpenCode
- Единый префикс ACPBOX_ в env для настроек приложения
- Добавил GitHub Actions для публикации Docker образа по тегам, улучшил публикацию в PyPI и связал tagging workflow с публикациями

Минимальная конфигурация для запуска

Такой docker-compose.yaml понадобится чтобы запустить агента OpenCode в формате ACPBox:

services:
  acpbox:
    restart: unless-stopped
    image: evilfreelancer/acpbox:latest
    environment:
      - ACPBOX_ACP_COMMAND=["opencode","acp","--log-level","ERROR"]
      - ACPBOX_ACP_WORKSPACE=/workspace
      - AGENTS=opencode
    ports:
      - "8080:8080"
    volumes:
      - ./workspace:/workspace
      - ./opencode.json:/home/user/.config/opencode/opencode.json:ro

Конфиг OpenCode кладём в папку рядом с docker-compose.yaml, а вот его содержимое:

{
  "$schema": "https://opencode.ai/config.json",
  "model": "rpa/gpt-oss:20b",
  "provider": {
    "rpa": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "https://api.rpa.icu",
        "apiKey": "/channel/evilfreelancer"
      },
      "models": {
        "gpt-oss:20b": {
          "tool_call": true
        }
      }
    }
  }
}

Исходники тут: https://github.com/EvilFreelancer/acpbox
PyPi пакет: https://pypi.org/project/acpbox/
Docker-образ тут: https://hub.docker.com/r/evilfreelancer/acpbox

Читать полностью…

Мой третий PR в llama.cpp

Читать полностью…

Конвертация Chroma Context-1 в MXFP4 для домашней 4090

Позавчера Chroma выкатила техрепорт по своей модельке chromadb/context-1, прочёл я его сегодня и был крайне впечатлен.

Это 20B параметров, MoE-архитектура на базе openai/gpt-oss-20b, модель натренирована на агентный поиск, делает декомпозицию сложных запросов на подзапросы, выполнняет итеративный поиск по корпусу документов, и самое интересное - self-editing context, когда модель сама решает какие из найденных документов оставить, а какие выкинуть чтобы не засорять контекстное окно. На бенчмарках показывает результаты сопоставимые с топовыми LLM при скорости как у gpt-oss-20b.

Естественно, захотелось потрогать руками, но... модель выложена в BF16, а это 39 ГБ только веса, ну а моя 4090 хоть и прокачана до 48 ГБ VRAM, но 39 ГБ чистых весов + KV-кеш + накладные расходы CUDA в неё не влезут, нужно минимум ~45-50 ГБ чтобы хоть что-то сгенерировать с минимальным контекстом, но нужен не минимальный, а хотя бы 30-60к токенов, агенты же.

Что делать? Смотрю на оригинальную gpt-oss-20b от OpenAI, она в формате MXFP4, это Microscaling FP4, хитрый 4-битный формат, где каждый вес хранится как E2M1 (2 бита экспонента, 1 бит мантиссы), а группа из 32 весов делит общий 8-битный масштаб (E8M0), нативно поддерживается в vLLM через Marlin-ядра и должно отлично работать на RTX 50xx серии, в таком формате модель занимает ~14 ГБ, на мою 4090 влезает с запасом.

Сформировал спеки для кодового агента в Cursor, говорю мол вот тебе веса модели gpt-oss-20b как референс, вот спецификация по методам сжатия MXFP4, вот веса модели context-1 в BF16 которую надо конвертировать, вот docker-compose.yaml с vLLM 0.18.0 на которой агент должен проверять модель.

Задача написать скрипт конвертации, конвертировать модель, запустить в vLLM, убедиться по HTTP что приходят адекватные ответы.

Агент написал скрипт, который читает safetensors, для MoE-экспертов (gate_up_proj и down_proj) транспонирует веса в layout который ожидает vLLM, квантует и пакует всё в MXFP4, по аналогии с gpt-oss-20b, а слои внимания, роутера и эмбеддингов копируются как есть в BF16. В результате 39 ГБ превращаются в ~14 ГБ.

Запустил на vLLM, всё работает, reasoning что-то там рефлексирует, ответы вроде адекватные, но при тестировании tool calling (function calling) выяснилась забавная штука - модель при вызове инструментов валится с ошибкой:

openai_harmony.HarmonyError: Unexpected token 12606 while expecting start token 200006

Покопавшись в конфигах gpt-oss-20b обнаружил, что в generation_config.json модели отсутствует токен <|call|> (id 200012) в списке eos_token_id, из-за этого модель не останавливает генерацию после вызова tool call и harmony ломается. По сути баг в vLLM, но фикс элементарный, добавить 200012 в eos_token_id в generation_config.json модели, после этого и обычный чат и tool calling заработали как надо.

Создал PR с фиксом в трекере оригинальной модели.

Ну а квантованную в MXFP4 версию загрузил на HuggingFace: evilfreelancer/context-1-mxfp4

PS. Поднял её на домашней видяшке и сделал доступной через мою апишку, пример как заюзать через openai-клиент добавил в комментарии.

Читать полностью…