Совместно с @mixaill76 провел ревью и смерджил PR от @virrius_tech в sgr-deep-research.

В рамках изменений проект был существенно причёсан и дополнен пятью вариантами построения deep research решений. Схемы и полный список можно посмотреть тут. Вместе с этим тегнул релиз 0.2.0.

Самое интересное - теперь при запросе через API можно указывать название агента через параметр model, и будет выполняться код именно этого агента.

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

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

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

Прекурсор про курсор или как вайб-кодить большие проекты

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

Проблема

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

Как итог - имеем потерю контроля и топтание на месте вместо движения вперёд.

Как я решаю

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

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

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

Если подмодуль крупный, выношу в отдельную сессию и даю выжимку контекста (что готово, где границы, какие правила действуют).

Однако, каждый раз играть в эту игру не просто, можно проиграть, и тут на помощь приходят инструменты разработчика и Cursor IDE в частности.

Как автоматизировать это в Cursor

Чтобы не держать всё в голове и не пересказывать каждый раз, я для больших вайб-код проектов создаю хитрые Cursor Rules.

Если кратко то рулесы это постоянный, управляемый контекст курсора, который содержит в себе правила поведения идешки, они лежат в директории .cursor/rules/, которая коммитается в реп, что позволяет версионировать правила курсора вместе с кодом проекта.

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

project/
  .cursor/rules/    # глобальные правила
  backend/
    .cursor/rules/  # правила бэкенда
  frontend/
    .cursor/rules/  # правила фронтенда

Внутри указанных директорий в .mdc-файлах хранятся собственно сами правила, MDC как я понял был выбран потому, что помимо текста в Markdown там можно хранить дополнительные метаданные и ещё мне кажется, потому, что авторы курсор не смогли через гугл найти аналогичный, но чуть более проработанной, стандарт, под названием MDX.

Пример .mdc-файла:

---
description: Краткое описание данного набора правил
globs: app/**/*.php
alwaysApply: true
---

- Следуй паттерну PSR-2
- Используй camelCase в названии фукций

@ссылка-на-файл.php
@или-скажем-на-ТЗ.md#главу-1
@или-на-другой.mdc

Тексты из .mdс-файлов подмешиваю к промтам через alwaysApply (true - всегда), если не указывать alwaysApply то агент будет сам решать когда их применять, а ещё можно заставить агента выполнить их принудительно (ручной вызов через @название-mdc-файла).

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

docs/
  ARCHITECTURE.md
  CLASS_MAP.md
  TECH_REQUIREMENTS.md

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

Ещё одна важная фича, которую умеет Cursor - это автоматическая генерация правил, просто пишем команду /Generate Cursor Rules и идешка сама создаст правила для уже существующей кодовой базы, что облегчает переход на вайб-кодинг в легаси проектах.

Как это стыкуется с моим подходом

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

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

Завершение

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

Резюмируя

Дисциплина + рулы в репозитории + послойная реализация = контроль и воспроизводимость.

Именно это и нужно вайб-кодеру на больших и сложных ТЗ.

PS. Тем, кто пропустил мои прошлые заметки про вайб-кодинг то вот ссылки (уно, дос, трес).

У себя на канале @neuraldeep опубликовал предварительные результаты тестов sgr-deep-research на бенчмарке SealQA (сплит seal_0), ну и так вот, из коробки, без оптимизаций указанное решение на gpt-4o-mini модельке показывает чуть больше 25% правильных ответов (28 из 111), само собой это надо будет ещё всё перепроверить, но уже больше 0% и это радует, однако, до SotA кажется будто ещё далековато.

Почём нынче мёртвые души?^W^W^W^W
Что там SotA в наши дни?

Есть например проект ROMA который выбивает на данном бенчмарке 45%, думаю занятно, полезу посмотрю, что за модельки использовались да и в целом, что там на низах происходит.

И похоже, что ROMA достигла 45% вероятно благодаря gpt-4o-search-preview (хотя это не точно, так как прямых свидетельств я найти не смог).

Данная моделька крутая сама по себе, она представляет из себя связку затюненной под поиск gpt-4o с тулом поиска в сети и несколькими поисковыми системами, при чём судя по публикации на сайте OpenAI этот самый поиск работает в несколько итераций, сам выбирает поисковый движок, формирует и отправляет запрос, производит анализ результатов, сам правит запросы если необходимо и ищет дальше, под конец формирует красивый ответ, короче эдакий продвинутый поисковый агент по форме отдалённо напоминающий deep research.

Вам шашечки или ехать?^W^W^W^W
Как работает поиск?

Думаю странно, модель со встроенным поисковиком для всех задач это конечно круто, но как тогда в ROMA реализован базовый тул поиска в сети, на случай если придётся использовать модель в которую поиск не встроен?

Нашёл вот это:
- OpenAICustomSearchAdapter - судя по коду по умолчанию используется gpt-4o со включенным web_search_preview тулом (эту фичу поддерживают почти все модели openai начиная с gpt-4o и далее)
- GeminiCustomSearchAdapter - по умолчанию используется gemini-2.5-flash со включенным google_search тулом (эту фичу поддерживают все гугловые модельки начиная с gemini 2.0)
- ExaCustomSearchAdapter - это ещё один поисковый движок в ROMA, который использует EXA по API, а при помощи модели gpt-4o формирует красивый ответ модели.

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

Трейн на тесте^W^W^W
Тюн промтов с помощью фью-шотов

Вот смотрите раз, два, три, четыре, пять забавных моментов (ищется по few shot).

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

Кто виноват?^W^W
Итого

Короче занятный проектик, в процессе изучения которого возник ряд мыслей:
- действительно ли ROMA способен работать с такой же эффективностью за, скажем так, пределами домена вопросов бенчмарка SealQA?
- получится ли повторить 45% используя другую модель, без встроенного поискового движка, скажем gpt-5 или cloude-opus-4.1?
- если отключить все проприетарные модели со встроенным поиском и использовать только поиск (скажем чистый travily) то как сильно это повлияет на результат?
- почему авторы пишут, что это OpenSource инструмент для DeepResearch? Когда на низах там используются проприетарные модели и нет тестов на OpenSource моделях.

Что делать?^W^W
Постскриптум

И тут же мысли в рамках проекта sgr-deep-research:
- надо будет попробовать модели толстушки аля gpt-5 и claude-4.1-opus со включенным поиском на всех этапах работы системы
- добавить тул который будет использовать специализированные LLM заточенные под поиск в сети, вдобавок к тулу который использует travily
- при помощи few-shots подтюнить системные промты так чтобы на нескольких примерах показать системе как ей надо себя вести, так как сейчас модель работает через zero-shot
- вместо списка ссылок чтобы поисковый тул отдавал красивую и релевантную суммаризацию созданную LLM полученных ссылок
- добавить шаг атомизации (как тут), который бы проверял можно ли выполнить задачу за один шаг и делал был декомпозицию шага если нельзя

UPD. Поправил очепятки, добавил пунктик про атомизацию.

Ну вот, дождался нормальной интеграции моделей в консоль от создателей Cursor IDE.

curl https://cursor.com/install -fsS | bash

Вот что предлагают авторы:

- Choose from any top AI model or use Auto for speed and efficiency
- Work with the same rules and context as the Cursor IDE
- Connect external tools via MCP (Model Context Protocol)
- Run headless in scripts to automate code reviews, generate docs, and more
- Run it anywhere: GitHub Actions, scripts, other IDEs, or any CI system

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

Однако, замечу, что централизованной интеграции с курсором IDE ещё пока не реализовали, но лиха беда начало.

Кажется будто на наших глазах зарождается агенцкий вайбкод форсед-мем на тему "ладно, и так сойдёт".

PS. Картинку взял из публиакации "Могут ли кодинг-агенты самосовершенствоваться?" на Хаборе

PPS. Публикация к слову тоже понравилась.

#meme

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

PS. Данный персонаж любопытен тем, что он еле-еле проходит внутреннюю цензуру моделей.

То тут, то там коллеги из ML-тусовки размышляют о будущем ИИ вообще и больших языковых моделей (LLM) в частности, а также о том мире, в котором мы можем оказаться через некоторое время, если скорость и направление развития современных технологий и моделей сохранятся.

Всё сказанное далее есть моё личное ИМХО, я не претендую на какую-то значимость, адекватность, объективность или ценность. Воспринимайте мои слова скорее как философствование на тему нейросетей, а то в прошлый раз, сами помните, что было ;)

И так, поехали...


"Закрытие" моделей

Компания OpenAI, помимо позитивного пинка всей индустрии, дала ещё и негативный: они с релиза GPT-2 шесть лет не выпускали публичные модели, и вот совсем недавно опубликовали GPT-OSS, вполне годную, хотя местами и слабую, модельку, но кто знает, сколько ещё лет пройдёт до следующего релиза.

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

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

Моё мнение: если тенденция сохранится, то в ближайшие 5 лет количество открытых моделей сократится, а релизить, если и будут, то только дистиллированных малюток, мало пригодных для чего-то, кроме chit-chat-бота или instruct-моделей для простого few-shots.


Мультимодальность

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

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


Mixture of Experts (MoE)

Ещё одна занятная тенденция, которая, как мне кажется, наметилась за последние полгода–год, в том, что многие успешные и популярные открытые модели сегодня имеют архитектуру MoE.

На всякий случай напомню: MoE - очень хитрая архитектура со встроенным роутером, которая по сути является компромиссным решением между "умными", но медленными "толстушками" (32B, 70B, 100B, 400B…) и "глупыми", но быстрыми "малютками" (...1.5B, 3B, 7B, 8B, 13B), позволяя скомбинировать лучшее из двух миров: скорость - от "малюток" и знания - от "толстушек".

Применение MoE в значительной степени ускоряет инференс, особенно на слабом железе, вроде стареньких Intel Xeon или мобильных чипов типа Apple M*, а также на специализированном железе без видеокарт (например, AMD AI Max+ 395). Ну и само собой, на обычных компьютерах с видеокартами модели MoE показывают очень хорошую скорость.

Поэтому, на мой взгляд, модели MoE в горизонте 2–5 лет станут доминирующими.

[1/2] @evilfreelancer

Кодинговые модели

Это специализированные модельки для инженерных задач, они умеют писать код, генерируют тесты и миграции баз данных, могут создавать diff для правок файлов. В отличие от простых "чатиков" умеют взаимодействовать с внешним миром: вызывать тулы, генерировать запросы в API, генерировать команды для запуска линтеров и тестов, могут читать логи и диффы. Им привычны строгие форматы ввода/вывода и интеграции с IDEшками и прочими CI/CD.

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


Рекламная интеграция

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

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

Поэтому полагаю, что в ближайшие 3–7 лет мы вступим в эру рекламных интеграций.


Браузерная интеграция

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

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

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


Это мои размышления на тему, а вы что думаете?

P.S. Люблю футурологию: в моменте можно сказать что угодно, а когда наступает срок, то никто уже не вспомнит анона, который озвучивал такие смешные прогнозы :)

PPS. Рекомендую почитать произведение "Футурологический конгресс" Станислава Лема.

[2/2] @evilfreelancer

Прочёл в нескольких каналах новость дня о том, что OpenAI выпустил приложение Sora 2 для мобильных телефонов, позиционируется данное приложение как AI slop вариация на тему TikTok, так как все видосы генерятся нейросетями.

Не сочтите за рекламу, но мне кажется забавным тот факт, что ни один из просмотренных мною каналов не вспомнил про Яндекс Шедеврум, а ведь данному проекту уже исполнилось пару лет, и её разработчики давно обкатали, как статичные картинки а-ля i**m by f**k, так и динамические ролики а-ля TikTok.

PS. Смотрите сами, про Шедеврум ни слова (тыц, тыц, тыц, тыц, тыц, и так далее, ну короче вы поняли).

Картинку взял тут #meme

upd. Надо бы поправить промт у себя в профиле и написать, чтобы модели делали пожертвования :)

Как-то раз пришёл на лекцию про ИИ и забыл отключить ambient рубки корабля Нормандия из Mass Effect (была такая игра в далёком прошлом, сюжет там про ИИ который каждые 50 тысяч лет "очищал" галактику от разумной органической жизни), очень странные ощущения при этом испытывал.

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

Меня данная возможность очень впечатлила, стал пробовать для локальной разработки, оказалось решение состоит из двух компонентов:
- хитрой LLM driaforall/mem-agent основанной на qwen3 4b, скрипты обучения модели тут (в репе будут еще и логи обучения 14b модели, но веса почему-то не выложили)
- обёртки firstbatchxyz/mem-agent-mcp для непосредственной работы с файловой системой в формате простенького MCP-сервера, к сожалению без Dockerfile

Ну и сами понимаете, пришлось ручками упаковывать всё в Docker-образ, по итогу у меня получились:
- отдельно docker-compose.yaml для запуска LLM-модельки на GPU-сервере с vLLM
- сам Dockerfile чтобы упаковать mem-agent
- и дополнительный docker-compose.yaml чтобы управлять сборкой Dockerfile

К слову сказать моделька отжирает 9Гб даже при bnb-квантизации до int4 с контекстом 4000 токена, так что вероятно в будущем я её конвертирую в GGUF.

Посоветовали зарегаться на чемпионате GigaMemory от Сбера, для того чтобы на реальных данных потестировать MCP-сервер из поста про MemAgent.

Мне в целом это интересно исключительно с точки зрения доступа к датасету с тестами, как к гигачату причепуширить mem agent пока что слабо себе представляю.

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

Поэтому решил изучить тему сам и рассказать вам в моей новенькой публикации "GGUF: квантизация с калибровкой (imatrix)" на Хабр.

UPD. На примере модельки ai-sage/GigaChat-20B-A3B-instruct

#habr #gguf