Как автоматизировать это в 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

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

Моя изначальная цель была в том, чтобы конвертировать модельку 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 задачек в принципе реальная, повозиться было интересно.