Прочёл в нескольких каналах новость дня о том, что 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

Расскажу зачем я решил так заморочиться с написанием публикации на Хабр, что была вчера.

Моя изначальная цель была в том, чтобы конвертировать модельку mem-agent, так её получится упаковать в архив который я планирую отправить на соревнование GigaMemory, там среди прочего ограничение на размер артефакта в 5Гб, а квантованная mem-agent будет весить 2.5Гб.

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

Но вернёмся обратно к mem-agent, и так, у нас наличествуют:
- Веса модели driaforall/mem-agent в bf16, одна штука
- Инструкция о llama-imatrix из проекта llama.cpp, которую я скомпилировал под CUDA, одна штука
- Датасеты (обучающий и тестовый) из репозитория проект, две штуки
- Пример JSON-сэмпла из датасета, соответствующий формату который принимает OpenRLHF PPO-тренер, вот такой:

{
  "context_messages": [
    {
      "role": "system",
      "content": "# Memory Agent System Prompt\nYou are an LLM agent..."
    },
    {
      "role": "user",
      "content": "What is the user friendliness of the service provided by the person I receive advice from?"
    }
  ],
  "label": "retrieval\n\n~/~/~/~/~/~/~/~/~/~/~/~\n\nmemory_f4bff9010b3f4e918833989e0ae5c725\n\n~/~/~/~/~/~/~/~/~/~/~/~\n\nHigh, designed for non-expert users"
}

Подготовим песочинцу, поставим пакеты, скомпилируем бинарники, в общем всё тоже самое, что и в моей публикации на Хабр.

Потом скачаем веса и выполним конвертацию в GGUF:

hf download driaforall/mem-agent --local-dir models/driaforall/mem-agent
python convert_hf_to_gguf.py models/driaforall/mem-agent

Зная формат JSON из обучающего датасета и зная как OpenRLHF формирует из них при помощи apply_chat_template текстовые данные напишем небольшой скриптик generate.py, кладём его в папку с llama.cpp например, и запускаем вот так:

python generator.py \
  --input "https://raw.githubusercontent.com/firstbatchxyz/mem-agent/refs/heads/main/data/openrlhf/mixed/train.jsonl" \
  --output ./calib.txt \
  --model driaforall/mem-agent

Он скачает JSONL с тренировочным датасетом, потом используя формат чата из конфига токенизатора преобразует обучающий датасет (состоящий из 6k записей) в калибровочный датасет, пригодный для imatrix.

Теперь вызовем бинарник llama-imatrix, передадим на вход путь до калибровачного датасета, созданного шагом ранее, и путь до квантованной в GGUF модели:

./build/bin/llama-imatrix \
  -m ./models/driaforall/mem-agent/Mem-Agent-4.0B-F16.gguf \
  -f ./calib.txt \
  -o ./models/driaforall/mem-agent/Mem-Agent-4.0B-F16.imatrix.gguf \
  --n-gpu-layers 20

Процедура расчёта imatrix на полном датасете займёт примерно 9 часов, так что оставляем GPU-сервер до вечера.

По завершению мы можем, при помощи утилиты llama-quantize, выполнить квантизацию модели в q4_k_m с учётом поправок полученных через llama-imatrix, пишем команду:

./build/bin/llama-quantize \
  --imatrix ./models/driaforall/mem-agent/Mem-Agent-4.0B-F16.imatrix.gguf \
  ./models/driaforall/mem-agent/Mem-Agent-4.0B-F16.gguf \
  ./models/driaforall/mem-agent/Mem-Agent-4.0B-Q4_K_M.gguf \
  Q4_K_M

Полученный gguf можно использовать дальше, я для удобства ещё его и на ollama загрузил:
- https://ollama.com/evilfreelancer/mem-agent

Скачать себе в ollama можно так:

ollama pull evilfreelancer/mem-agent

Далее в docker-compose.yaml в блоке environment вашего MCP сервера с mem-agent меняем VLLM_HOST и VLLM_PORT на соответствующие параметры вашего сервера ollama, добавляем там же в env строку MLX_MODEL_NAME: evilfreelancer/mem-agent и можно пользоваться.

Пару дней назад мне написали в личку и попросили рассказать о конференции "AI Dev 2025" про использование нейронок при разработке.

Скинули список спикеров данного мероприятия, среди всех представленных лично я постоянно читаю только Александра @dealerAI и периодически почитываю Рефата @nobilix. Однако, помимо указанных авторов, там будут выступать ещё несколько ребят, о творчестве которых я ранее не знал.

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

Конфа пройдёт в онлайн-формате 14 октября, начало в 14:00 MSK, билетик обойдётся вам в 7500 рябчиков, либо же, если подпишетесь на всех авторов, после подтверждения оплаты/подписки вам придёт инвайт в приватный канал для участников мероприятия.

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

PPS. За эту рекламу денег не взял, а даже наоборот - заплатил за участие в роли зрителя, такой вот я меценат.

PPPS. Зарегаться можно на сайте AI Dev 2025.

В выходные размышлял на тему графических нейросетей, а так же об их сходстве с языковыми моделями и появилась идея про использование графических моделей сегментации изображений типа YOLO (You Only Look Once) для решения задач NLP (Natural Language Processing).

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

Полез искать подобные решения, нашёл пару любопытных.

—

Первой оказалась публикация "Enhancing Bidirectional Sign Language Communication: Integrating YOLOv8 and NLP for Real-Time Gesture Recognition & Translation" (arXiv:2411.13597) про использование YOLO модели в качестве классификатора языка жестов ASL (American Sign Language).

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

Занятная публикация, но исходников найти не смог.

—

Вторая заинтересовавшая меня история называется sturk111/yolo-nlp, она решает задачу NER (Named Entity Recognition) и тоже как и первая представляет из себя научное исследование, хотя и оформленое в виде ридми на гитхабе.

В ней мне очень понравилось, как автор реализовал Yolo1D, там происходит маппинг 1D интервалов (последовательности токенов текста) в 2D решётки (которые использует YOLO для классификации и сегментации), и ещё забавно, что используется готовый токенизатор из модельки allenai/longformer-base-4096.

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

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

—

В общем тема применения YOLO для некоторых NLP задачек в принципе реальная, повозиться было интересно.

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

У себя на канале Валерий опубликовал небольшой отчёт о результатах тестирования SGR Deep Research (тестировали на ветке benchmark_simpleqa) на бенчмарке SimpleQA, если кратко, то удалось на модельке gpt-4.1-mini добиться большей точности ответов на этом бенче чем даёт базовая gpt-4.5 (смотри картинку).

Результат бенчмарка получили следующий:
gpt-4.1-mini → Accuracy: 0.861

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

В общем работаем помаленьку, того и гляди доведём до состояния близкого к идеальному.

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

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

Так что теперь по адресу https://status.rpa.icu/ вместо aPulse у меня обитает Kuma.

Разбираюсь помаленьку с проектом mem-agent-mcp, вычленил core-логику и собрал прототип работы с памятью в формате простого класса который дёргает GGUF модель, принимает запрос пользователя и выполняет необходимые работы с памятью, после чего возвращает ответ.

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

Забыл рассказать, сегодня свершилось чудо и мой PR с небольшим рефакторингом SGR таки был смерджен в мейн.

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

Дальше буду наводить красоту в core.agents.

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

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

Есть вопросы к работе на длинных чатах, будто после 50 пар user/assistant она перестаёт генерировать вызов тулов, как следствие перестаёт сохранять и использовать базу знаний.

Обучали её вызывать тулы и работать с данными в нескольких тегах:
<think> - для ризонинга, встроенная в квен фишка
<python> - питоний код, в котором указано название функции и аргументы её запуска
<result> - сюда передаётся ответ тула, текст уходит в модель, она принимает решение, нужно ли делать ретрай и генерит ризонинг с тегом пайтон или реплай
<reply> - то что модель отвечает юзеру, обычно генерится после нескольких ответов тулов

Самый занятный костыль проекта это тег <python>, в нём модель генерит обычно валидный python код, содержащий в себе название функции и её аргументы, код выполняется в песочнице (я о ней недавно рассказывал), у песочницы к слову сказать нет никакой защиты, но это так, лирика.

У проекте есть вот такие тулы (смотри tools.py в репе):
get_size - получает размер файла в байтах
create_file - создаёт пустой файл
create_dir - создаёт директорию
update_file - обновляет содержимое файла
read_file - читает содержимое файла
list_files - возвращает список всех файлов в папке с памятью
delete_file - удаляет файл или директорию
go_to_link - хитрый метод, читает из md-файла ссылку вида [[path/to/file.md]], потом читает содержимое файла
check_if_file_exists - проверка если файл есть
check_if_dir_exists - проверка если директория есть

Они позволяют работать с файловой системой, записывать данные, и возвращать ответ.

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

Но мне не понятно самое главное, почему авторы вместо пайплайна planning->tool_calling->adopt_plan->response пошли по пути обучения модели? Ведь это делает сам подход памяти не универсальным и ограничивает пользователя одной конкретной моделью, плюс все операции желательно хранить в видео-памяти иначе модель начинает галюцинировать.

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

И ещё одна проблема это то, что один агент в один момент времени обслуживает только одно хранилище памяти в пределах одной сессии, то есть multi-user или даже хотя бы multi-session режим не предусмотрен.

В общем вдоволь повозившись решил на базе sgr-deep-research (а если точнее, то на чистом sgr_core) запилить простенький прототипчик, он пока ещё сырой, однако, я постараюсь довести его до приемлемого состояния.

Я не вайб-кодер, я директор ИИ, масаракш

Навеяло

Сейчас Александр расскажет молодым базу :)

Панельная дискуссия.