Переделал старый мем насчет Qwen.

На самом деле "зоопарк" LLM у Qwen связан с оптимизацией под малые серверные системы, где универсальная LLM просто под 1T весов нереалистичная для развертывания, поэтому Qwen и предлагает целое семейство решений, где можно поставить локально только ИИ под задачу и обычно в пределах 30B параметров

Сейчас просматривал подборки видео с Military выставок в КНР по дронам. Показательно, что довольно много китайцы по робособакам сбрасывают таких клипов в TikTok.

Просто китайцы двигают важный концепт: "там где опасно там должны гибнуть роботы, а не люди".

Уже можно с улыбкой вспоминать анекдоты про корейскую войну в духе: "китайская армия, маленькими группами по 2-3 миллиона человек, начала выходит из окружения"

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

Однако большие инвестиции в робособак военных наверняка сделают такой форм фактор автономного ИИ робота популярным. По сравнению с гуманоидной формой робособака может нести намного больше вес.

Строго говоря, Boston Dynamics начался с того, что Пентагон заказал у них робособаку как "потаскуна и насильника", т.к. чтобы бегал за пехотой с боекомплектом. Это тоже не мелочи, сейчас пехотинец несет порядка 10-15 кг боекомплекта на себе часто.

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

Интересно, прекратит ли Маск свой демпинг на рынке ИИ агентов создания кода или это его долгосрочная стратегия.

Для начала, стратегия Маска просто "выдавить ценой" даже Claude вполне работает.

Платный вариант Grok Code Fast примерно в 10 раз дешевле Claude. Плюс по скорости вывода первого токена и генерации дальше заметно лучше Claude и Gemini.

Фокус тут еще в том, что если применять семантические разметки как в GRACE, то можно сделать Architect фазу в AI Studio, там заработала интеграция с GitHub к слову, а потом просто фиксить и доделывать мелочи через Grok.

Получается бесплатное премиальное качество на планировании ИИ архитектуры и бесплатное и премиальное качество по скорости на фиксах.

Отмечу, что Маск еще держит тестовые версии постоянно под кодовыми названиями типа "Soroma".

Если ситуация сохранится такой, ландшафт генерации кода сильно изменится.

Маск понял, что жадность девелоперов важнее даже тестов для ИИ. 😜

Но для фиксов Grok реально "good enough", причем часто лучше других ИИ, т.к. Grok склонен к "болтливости" на анализе проблем, а это дает ему очень хороший контекст для их исправления. Другие ИИ сразу хватаются править код, поэтому эффект часто хуже.

Кажется с Kilo Code я привел и подключение Gemini CLI на Free Tier в чувство.

Через API Key в Gemini CLI действует общее ограничение:
"Free tier: 100 requests/day with Gemini 2.5 Pro"

Однако если вы подключаетесь через свой эккаунт Google к проекту Google Cloud, то ограничения другие:
"Free tier with 60 requests/min and 1,000 requests/day"

Не забудьте установить название проекта в переменной среды GOOGLE_CLOUD_PROJECT и активировать проект в Google Cloud для Gemini

В случае Kilo Code он имеет очень важные настройки для работы на Free Tier. У них есть пауза между запросами и автоматический выход из self correction по попыткам. Это защищает от срабатывания лимитов, которые в самом Gemini CLI валятся постоянно. Например, короткий запрос в режиме Architect в Kilo Code потребовал реально 40 обращений к Gemini Pro и без задержки по 1 сек, вы легко из лимита вывалитесь.

На деле штука полезная в том смысле, что Grok все же слабоват как "Архитектор", это и по тестам видно. Лучше проектировать архитектуру и первичную генерацию кода через Gemini Pro, а потом уже фиксить шустрым Grok.

Пользуемся и пишем фидбеки в комментах. 😎

Kilo Code добавило векторизацию кода для семантического поиска, что во многом пошатнуло позиции Cursor, т.к. среди конкурирующих ИИ агентов векторного поиска не было обычно.

Существенный момент, что это работает совсем бесплатно и быстро через эмбеддинги Google на 768 измерений, а как векторная база используется Qdrant у которых на Free Tier довольно приличная векторная база помещается - 4 Гб. Обычно нужно около 30 Мб на 10.000 строк кода, даже с учетом очень мелких чанков по AST у Kilo Code.

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

https://www.youtube.com/watch?v=dj59Vi83oDw

Хороший мастер класс по векторному RAG на примере Kilo Code.

Вот пример векторизации, где они разбивают большую часть кода на такие очень мелкие чанки по AST. Чаще всего это 1-3 строки как тут.

По факту это приводит к тому, что мои GRACE разметки как тут START_SAVE_TO_EXCEL и другие как раз цепляются векторным поиском (где-то 60% из Top 10 семантическим поиском это мои разметки).

Зачем такие мелкие чанки делает инженер в Kilo Code? Дело в том, что он учитывает, что векторизация будет чаще делаться векторами невысокой размерности как тут в 768 измерений, но даже с вектором на 3000 измерений есть проблема известная как "катастрофа суперпозиции". Я публиковал по ней статью. На самом деле у ИИ такая высокая размерность векторов, чтобы складывая много векторов в один хотя бы по некоторым измерениям разные вектора были перпендикулярные, а потому различимые. Если размерность снижать, то векторным сравнением очень сложно выделить ИНДИВИДУАЛЬНЫЕ вектора.

Поэтому как раз большой чанк как во многих RAG, в случае кода бы привел к большому семантическому размытию отдельных сущностей. А для ИИ агентов программирования очень важный кейс замещать Call Graph, которого у них нет, на семантический поиск. Поэтому им очень важно надежное реагирование на ключевые слова и синонимы. Поэтому и такое мелкое дробление.

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

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

Профессор Pero Micic сделал расчет окупаемости гуманоидов на ИИ. На деле даже при стоимости гуманоида около $33.000 и существенных эксплуатационных расходах на ремонт и обслуживание его, то в сравнении с обычными рабочими один гуманоид генерирует примерно $200.000 прибыли в год, если работает со скоростью рабочего-человека.

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

Не самая свежая работа по CoT, но весьма цитируемая как базовая.

В работе "To CoT or not to CoT? Chain-of-thought helps mainly on math and symbolic reasoning" показано, что влияние CoT на ИИ неравномерно по задачам.

Для задач классификации и просто ответов на знания CoT ухудшает выдачу ИИ. Сама эффективность CoT "в среднем по больнице низкая" - 3%, но есть задачи где CoT сверхэффективен - математика и программирование (+50% часто).

В современных ИИ как последний Qwen и Gemini там thinking модель обучают принимать решение вообще нужен ей CoT или нет. Поэтому иногда Gemini и отвечает сразу.

Проблема CoT в том, что он может быть "постфактум рационализацией", т.е. ИИ уже принял решение в скрытом состоянии, но лишь оправдывает свое решение правдоподобными паттернами, а не рассуждает. Это типичная проблема всех SLM, где CoT вообще изучался как копирование учителя.

Новинка вендоров - бюджет на CoT. Модели обучены реагировать на параметр разрешенного объема размышлений. Также ничего страшного если CoT будет прерван по лимиту - модель обучена этой ситуации, но обычно ее избегает сама. Если поставить Gemini бюджет thinking в 500 токенов, то он будет стараться размышлять не более 200-300.

Однако даже такой малый бюджет крайне полезен ИИ в алгоритмике, т.к. дает ИИ еще дополнительную векторную емкость за токенами CoT для моделирования в скрытом состоянии решения. "Мысли в векторах" за токенами могут быть куда глубже текста, что вы видите.

На мой взгляд, с Gemini в программировании лучше ставить CoT примерно на 500 токенов, если вы основные рассуждения делаете отдельными запросами и фиксируете документами с ИИ.

https://arxiv.org/html/2409.12183v3

Надо сказать, что Kilo Code работает с Gemini через Google Cloud выше всяких похвал. Если Gemini CLI у меня постоянно валился, то Kilo Code довольно грамотно, вставляя 1 секундные паузы, сделало бесплатный Gemini Pro совсем рабочим вариантом.

0% ошибок, как видите. Еще очень быстрый отклик в районе 0,03 сек. Скорость генерации около 50 токенов/сек.

Grok Fast побыстрее.

Я смигрировал свои учебные материалы на Kilo Code c Cursor, т.к. довольно очевидно, что Cursor сильно проигрывает из-за vendor lock и нормальной поддержки free режимов от Google, Grok и Qwen

Все же мой GRACE и PCAM лучше ложится на организацию интерфейса Kilo Code, чем Cursor. Хотя в Cursor тоже можно иметь RAG-базу промтов генерации кода, но что Kilo Code в интерфейсе выделило прямо режимы Architect, Code, Debug и сразу с ассоциированными промтами как минимум делает GRACE более визуально понятным в UI по фазности разработки.

Я перенес все лучшее из промптинга для Gemini CLI и Cursor в Kilo Code, также поддержаны особенности самого Kilo Code:
- Корректно сформулированы и ПРОВЕРЕНЫ на большой кодовой базе промпты для ИИ агента как нужно ему делать правильно семантические запросы в векторный поиск, тут отличие от Сursor значительное по подходу к чанкам
- Сделана поддержка контроля версионности среды запуском агентом сканирования версий, рейтинг библиотек по AI Friendly, интеграция с Context 7 для примеров
- Поддержка создания Knowledge Base по разработке в графовой базе Kilo Code самим ИИ, разграничено что хранить в XML/MD, а что в графовой БД
- Адаптация правок кода на новый diff-инструмент, который предложен был Anthropic для Claude и поддерживается в Kilo Code, но работает хорошо с Gemini через промпты и разметку GRACE

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

Но интернет помнит все. 😎

В статье описано почему Cursor берет модели LLama и DeepSeek для дообучения под патчер кода. Их патчер работает на базе Llama-3-70b с приличной коррекцией весов.

В Kilo Code есть аналог этого как Morph. Однако сразу скажу, что без семантический разметок как GRACE работает так себе, т.к. ИИ хотя и не нужно цитировать replace фразу, но все равно нужно описать нейросети патчеру "семантические координаты" для замены куска кода.

Основной плюс технологии Morph+KiloCode или Cursor - это экономия токенов и скорость. Обычный replace требует от ИИ два раза напечатать код (было и стало).

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

PS. Я кажется понял почему у коллег сбивается Grok 4 в Kilo Code на правках иногда, он просто не сверяется с инструментом чтения файла по номерам строк, а пытается их "вспомнить", что, естественно, вызывает галлюцинации. Строго говоря, без нормального промпта на 1 страницу как ИИ агенту править код вы точно себе ищите нормальных приключений.

https://web.archive.org/web/20240823050616/https://www.cursor.com/blog/instant-apply

Насчет семантических разметок и почему те кто их не делают на деле будут платить за счета на ИИ заметно больше и еще рискуют собрать грабли с ИИ.

Как я уже писал, на самом деле ИИ агенты обычно делают правку кода или любого другого текста через replace. Это требует им очень точно процитировать какой текст был, а потом написать новый. Инновации как у Kilo Code добавить еще номера строк в контекст, чтобы они участвовали в поисковой фразе механизма для точности. В Kilo Code есть настройка для снижения требований к точности поисковой фразе для исключения мелких опечаток ИИ, но требование, чтобы поисковый фрагмент был найден только один раз сохраняется.

В случае Cursor или Morh там используется нейросеть для патчинга.

ИИ агент генерации кода выражает сначала свою цель. Например: "Update function parameters"

Потом передается как должен выглядеть код после замены, неизменяемый код обозначается через "// ... existing code ..."

// ... existing code ...
function authenticateUser(email, password) {
const result = await verifyUser(email, password);
if (result) {
return "Authenticated";
} else {
return "Unauthenticated";
}
}
// ... existing code ...

Как легко заметить, чудаки, которые не овладели семантическими разметками с якорями могут легко на грабли наступить и в Cursor и Morph, т.к. если правка не ухватила как в этом примере однозначный идентификатор функции, то нейросеть-патчер имеет большую свободу трактовки что именно править. Также "// ... existing code ..." легко позволяют нейросети трактовать как СТИРАНИЕ каких-то фрагментов кода. Формат на деле не детермированый. Средний успех правок - 95-98%, т.е. тот же Cursor где-то на каждый 20-30 правку кода, повреждает код в той или иной степени. Иными словами, правка явно отличается от намерения ИИ агента создающего код, просто не всегда это ведет к проблеме, если там потерялось несколько пробелов. Обычно замечают, что для ИИ правка текста далеко нетривиальная задача только если Cursor уже снес полмодуля очередной правкой. А сколько вы косяков пропустили и не заметили?

Cursor или Morph требуют специальной нейросети, которая не такая и дешевая. Cursor по факту требует свою подписку именно за нее больше + векторизация кода. Morph берет $0.90/M за вход и $1.90/M за выход токенов, что нельзя сказать, что дешево. По факту такая технология окупается только с дорогим Claude за счет отсутствия поисковой фразы в replace-патчах.

Теперь сравним как выглядят патчи на семантической разметке GRACE.

#PATCH_ID P-HW-MULTI-001: Update the GREETING block message.
#FILE: tools/plugins/hello_world.py
#TYPE: UPDATE
#START_BLOCK_GREETING: [Формирование первой части сообщения.]
greeting = "Hello from the Multi-Patch!"
#END_BLOCK_GREETING

Тут хорошо видно, что все эти проблемы "поисковых фраз" тут вообще отсутствуют. ИИ просто указывает "семантические координаты" патча между якорями. Поисковая фраза не нужна.

Если же работает Morph или Cursor, то агент также всегда вставляет START-END теги в запрос на патчинг, чтобы нейросеть патчер понимала лучше место где правка. Для replace инструмента ИИ агенты обычно стараются делать также "атомарные" патчи для надежности меняя целый блок между якорями.

Еще раз отмечу, что ожидание большинства разработчиков, что "ИИ редактировать текст легко" - крайне опасное заблуждение. ИИ очень сложно делать привязки своих правок, т.к. для него текст объемный в Positional Encoding, а текст кожаных - плоский. По факту GPT нужно очень тщательно "прицелится" из своего многомерного семантического пространство в плоское для правки. Это только генерация текста целиком для ИИ простая.

https://openrouter.ai/morph/morph-v3-large

Google в AI Studio сделал довольно развитую среду разработки Web-приложений (React) с интеграцией с GitHub и автоматическим деплоем в Google Cloud уже готовой версии.

Для этого войдите в AI Studio и нажмите режим Build. Хотя это работает уже пару месяцев в таком виде, но не все знают, вероятно.

Для прототипирования простых Web-интерфейсов не такая и плохая штука.

Существенный момент, что за Gemini Pro платить тут не нужно. Если задача прорисовать много простых форм и дешбордов, а потом утащить заготовку фронтэнд к себе, то штука вполне годная.

Подборка всех приложений Google, где поддерживается Gemini Code Assist.

Интересно, что на этой странице Google изложил свою стратегию.

1000 запросов в день для Gemini Pro он даёт бесплатно для студентов, программирующих как хобби и фрилансеров. Это они собираются так и оставить.

Для Enterprise у них довольно интересные предложения, если не через обычный API

https://codeassist.google/#available-in-your-terminal-favorite-ides-and-platforms

На деле платить за Gemini лучше не по API по токенам, а именно через программу Google Assist. В этом случае у вас за $20-$40 в месяц порядка 2000 запросов в день.

Если используется методика разработки как GRACE, где акцент сделан на крупные, но сравнительно редкие промпты, то выбрать даже 1000 запросов в день не просто.

Это в бардачном метании нужного много запросов к ИИ, а в GRACE запросов в том же Architect режиме вряд ли будет больше 20 штук, хотя они сразу сгенерят порядка 300-400 тысяч токенов контекста для проектирования приложения.

На мой взгляд, для методик с четким ИИ процессом разработки как раз Assist тарификация самое то, и.к. запросы нечастые, а контекста много.

https://developers.google.com/gemini-code-assist/resources/quotas

Любопытные тесты, по считыванию реальные чертежей разными ИИ. Довольно ожидаемо с большим отрывом лидер Gemini. В прочем, это хорошо известный факт и без тестов, на обучении строителей постоянно с ними чертежи читаю Gemini и получаем ведомости объемов, работает действительно хорошо даже не на тестах, а на внедрениях.

https://habr.com/ru/articles/946080/

Google удалось порвать всех конкуренто в тесте MTEB для эмбедингов для малых моделей с EmbeddingGemma. Модель всего 300М весов и может запускаться даже слабых смартфонах. По чанкам до 2048 токенов создает вектора на 768 измерений. Правда качество векторизации заметно хуже, чем Gemini API Free Tier для text-embedding-004. Вектора Gemma почти не содержат семантических обобщений в тексте, а только поиск прямых синонимов. Тем не менее, это прорыв для малых автономных систем и "закрытых контуров", где нет выхода в Интернет.

Google сделал для Embedding Gemma неплохую визуализацию с графом близости тегов. Я прогрузил туда граф приложения в XML, сделанного по методике GRACE. Тут можно увидеть неочевидный факт еще, что XML-графы очень хорошо векторизируются обычно для семантического поиска, т.к. автоматике чанков очень понятно как разрезать XML на части, а каждый чанк еще крайне обогащенный семантическими тегами от XML.

Если посмотреть семантический поиск в Cursor или Kilo Code, то там очень часто самые релеватные в контексте именно XML графы по коду, а не код, который часто вообще не размечен нормально для ИИ и векторизации.

https://huggingface.co/blog/embeddinggemma

https://huggingface.co/spaces/webml-community/semantic-galaxy

Немного про семантическую когеретность текста или почему крупная ошибка разделять код и Knowledge Base по нему в отдельную структуру.

Сначала заглянем в тесты и увидим чудо созданное Qwen. Видно что малая SLM как Qwen 3 - 4B показывает невероятные результаты в математике и алгоритмизации для такого размера. Также мощен и Qwen 3 - 30B-A3. На деле это оба SLM, т.к. проходили обучение "с учителем" от большой LLM.

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

При обучении с учителем SLM читает его текст рассуждений и сам ответ и пытается его копировать не размышляя. В Qwen по факту поддержали очевидную гипотезу, что когда GPT читает уже написанный текст, то по факту постепенно входит в эквивалентное векторное состояние с "ИИ автором". Это векторное состояние и есть "понимание ИИ". Qwen усилил это процесс путем синхронизации не только по токену, но и по логитам. Однако мы видим насколько важно для "ИИ читателя" синхронизировать свои мысли с "ИИ писателем" того же кода.

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

Если у вас код генерируется единым процессом для GPT и в него вставляются контракты и якоря, то ИИ читатель считывая этого восстанавливает мысли ИИ автора в векторах.

Процесс этот крайне хрупкий и легко разваливается от любителей RAG. Можно сказать, что ИИ читает последовательно книгу и вникает в историю сюжета. Если же вы начнете ИИ бомбить RAG-кусками из контекста, то это все равно что не дать GPT книгу, а вырывать из нее страницы и швыряться в агента.

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

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

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

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

Успехи Qwen в том, что они эти банальные вещи превратили в искусство.

Нейт Соарес руководит институтом по AI со специализацией в области безопасности AGI. Он написал книгу, где есть нечто большее, чем просто алармизм.

По факту Нейт пишет, что весь alignment для ИИ как надёжная защита от его эффектов поведения провалился.

Если ИИ развивает общие когнитивные навыки, то в значительном числе случаев легко преодолевает попытки его ограничить обучением.

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

В своей методике PCAM я как раз сместил акцент на управление целями агентов, чем умнее будет LLM, тем важнее управлять целями с ней.

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

"Если AGI нас убьёт, то мы даже не сможем понять зачем и как он это сделал " (С) Илон Маск

https://www.businessinsider.com/ai-top-expert-rushing-artificial-superintelligence-could-wipe-us-out-2025-9