Mercury Edit 2

Что такое Mercury Edit 2?

Mercury Edit 2 — специализированная diffusion-модель LLM (dLLM) для предсказания следующего правка в рабочих процессах разработки ПО. Она предназначена для помощи на самом чувствительном к задержкам этапе кодинга: предлагает, что вы, скорее всего, измените дальше, на основе недавних правок и контекста окружающего кода.

Модель дополняет существующий endpoint автодополнения Inception, сосредоточившись именно на подсказках правок. На практике вы можете принять предсказанную правку (например, через Tab), если она подходит к вашей работе.

Ключевые особенности

• Предсказание следующего правка по истории правок и контексту кода: Использует «недавние правки» плюс контекст кодовой базы для генерации целевой подсказки о следующем изменении.
• Параллельная генерация токенов на основе диффузии: Генерирует токены с помощью диффузии параллельно, чтобы сократить время до первой подсказки для низкозадержного UX.
• Обучение с учетом предпочтений на основе отзывов людей: Создает датасет предпочтений из явных отзывов accept/reject, затем применяет метод unpaired reinforcement learning (KTO) для согласования подсказок с предпочтениями людей.
• Более избирательные, менее отвлекающие правки (по данным поста): Улучшения включают 48% больше принятых правок и 27% выше избирательность отображаемого.
• Бенчмарки для корректности правок и скорости: Качество оценивается на наборе бенчмарков (включая open-source: Instinct, Fill-in-the-middle (FIM), Next-edit Prediction (NEP)) плюс внутренний бенчмарк next-edit; скорость — по end-to-end задержке на репрезентативных запросах.
• Доступна через Inception Platform API: Mercury Edit 2 доступна через Inception API (включая упоминание APIZedProxy для пользователей Zed).

Как использовать Mercury Edit 2

• Получите доступ на Inception Platform: Создайте аккаунт на Inception API Platform, чтобы начать использовать Mercury Edit 2.
• Вызывайте модель через API: Используйте Inception API для запросов предсказаний следующего правка (пост ссылается на API-workflow, включая APIZedProxy для интеграции с Zed).
• Интегрируйте в workflow редактора: При встраивании в среду разработки используйте предсказания next-edit вместе с действием принятия редактора (например, «Just Tab to accept», как описано в посте).

Сценарии использования

• Подсказки следующего изменения в IDE/редакторе во время активного кодинга: При серии правок используйте Mercury Edit 2 для подсказок вероятного следующего изменения с низкой задержкой.
• Помощь в рефакторинге с целевыми предложениями правок: Генерируйте подсказки для изменений вроде переименования, шагов рефакторинга или других структурированных правок, где framing «next edit» подходит workflow.
• Workflow в стиле FIM/дополнения строк, адаптированные к правкам: В контекстах, где простое дополнение недостаточно, используйте предсказание next-edit для предложения правки, следующей из текущей последовательности и окружающего кода.
• Итерации при реализации фич: При добавлении функциональности полагайтесь на предсказание next-edit для подсказок последующих изменений (например, доработок) на основе недавних правок.
• Снижение нежелательных подсказок через alignment предпочтений: Используйте поведение, обученное на предпочтениях, чтобы уменьшить частоту и длину отвлекающих правок (как описано в посте как явная мотивация обучения).

FAQ

• Какую проблему решает Mercury Edit 2? Она решает предсказание следующего правка в кодинговых workflow, где система должна предлагать следующее изменение с низкой задержкой.

• Чем она отличается от автодополнения? Пост указывает, что Mercury Edit 2 дополняет существующий endpoint автодополнения, сосредоточившись именно на подсказках правок, а не общем дополнении.

• Как модель обучается быть полезнее? Пост описывает использование датасета предпочтений людей на основе accept vs. reject, с последующим применением unpaired RL-метода KTO для alignment.

• Как пост оценивает качество и скорость модели? Качество бенчмаркится на open-source бенчмарках по правкам (Instinct, FIM, NEP) плюс внутренний next-edit бенчмарк, с LLM-as-a-judge для корректности (и выполнением тест-кейсов для FIM). Скорость — по end-to-end задержке на репрезентативных запросах.

• Где можно использовать модель? Она доступна через Inception Platform API.

Альтернативы

• Ассистенты для кодинга с фокусом на автодополнение: Они предсказывают следующие токены или текст, а не целевые next-edit; проще для завершения префиксов, но не специализированы на «что вы измените следующим».
• Универсальные модели автодополнения для кода: Универсальные LLM для кода можно промптить для предложений diff или правок, но они не оптимизированы специально под задержку next-edit предсказаний и согласованность принятия/отклонения правок.
• Другие предикторы next-edit / fill-in-the-middle стиля: Альтернативы в той же категории — модели, оцениваемые на похожих сценариях правок (завершение строк, переименование переменных, рефакторинг, реализация фич), отличающиеся способом генерации правок и балансом качества vs. скорости.
• Системы генерации правок на основе тестов: Некоторые подходы валидируют правки запуском тест-кейсов (пост отмечает, что FIM использует выполнение тест-кейсов). Такие системы подчёркивают корректность через выполнение, но могут отличаться по скорости workflow и компромиссам задержки.