Mercury Edit 2

O que é Mercury Edit 2?

Mercury Edit 2 é um LLM de difusão (dLLM) projetado especificamente para previsão do próximo edit em fluxos de desenvolvimento de software. Ele é feito para ajudar na etapa mais sensível a latência na assistência de codificação: sugerir o que você provavelmente mudará em seguida com base nos seus edits recentes e no contexto do codebase ao redor.

O modelo complementa o endpoint de auto-complete existente do Inception ao focar especificamente em sugestões de edits. Na prática, você pode aceitar um edit previsto (por exemplo, via tab) quando a sugestão se adequar ao que você está trabalhando.

Principais Recursos

• Previsão do próximo edit a partir do histórico de edits e contexto de código: Usa “edits recentes” mais contexto do codebase para gerar uma sugestão direcionada do que mudar em seguida.
• Geração de tokens baseada em difusão em paralelo: Gera tokens usando difusão e os executa em paralelo para reduzir o tempo até a primeira sugestão, garantindo UX de baixa latência.
• Treinamento alinhado a preferências com feedback humano: Constrói um dataset de preferências humanas a partir de feedback explícito de aceitação/rejeição, aplicando um método de aprendizado por reforço não pareado (KTO) para alinhar sugestões às preferências humanas.
• Edits mais seletivos e menos distrativos (conforme medido no post): Melhorias reportadas incluem 48% mais edits aceitos e 27% mais seletividade no que exibe.
• Cobertura de benchmarks para correção de edits e velocidade: Qualidade avaliada em benchmarks (incluindo open-source como Instinct, Fill-in-the-middle (FIM) e Next-edit Prediction (NEP)) mais benchmark interno de próximo edit; velocidade medida via latência end-to-end em requests representativos.
• Disponível via API da Inception Platform: Acesse Mercury Edit 2 pela API do Inception (incluindo menção a APIZedProxy para usuários Zed).

Como Usar Mercury Edit 2

• Obtenha acesso na Inception Platform: Crie uma conta na Inception API Platform para começar a usar Mercury Edit 2.
• Chame o modelo pela API: Use a API do Inception para enviar requests de previsão de próximo edit (o post menciona um workflow de API, incluindo APIZedProxy para integração com Zed).
• Integre em um workflow de editor: Se estiver incorporando em um ambiente de desenvolvimento, use as previsões de próximo edit do modelo junto à ação de aceitação do editor (ex.: “Apenas Tab para aceitar”, como descrito no post).

Casos de Uso

• Sugestões de próxima mudança em IDE/editor durante codificação ativa: Ao fazer uma série de edits, use Mercury Edit 2 para sugerir o que você provavelmente mudará em seguida, visando respostas de baixa latência.
• Ajuda em refatoração com propostas direcionadas a edits: Gere sugestões para mudanças como renomeação, passos de refatoração ou outros edits estruturados onde o framing de “próximo edit” se adequa ao workflow.
• Workflows no estilo FIM/completamento de linha adaptados a edits: Em contextos onde completude sozinha não basta, use previsão de próximo edit para propor o edit que segue da sua sequência atual de edits e código ao redor.
• Iteração em implementação de features: Ao adicionar funcionalidades, confie na previsão de próximo edit para sugerir mudanças subsequentes (como modificações de follow-up) baseadas em edits recentes.
• Redução de sugestões indesejadas via alinhamento de preferências: Use o comportamento treinado em preferências para diminuir a frequência e o comprimento de edits que distrairiam (como o post descreve como motivação explícita de treinamento).

FAQ

• Qual problema Mercury Edit 2 resolve? Ele foca na previsão de próximo edit em fluxos de codificação, onde o sistema precisa sugerir o que você mudará em seguida com baixa latência.

• Como ele difere do auto-complete? O post afirma que Mercury Edit 2 complementa um endpoint de auto-complete existente ao focar especificamente em sugestões de edits, não em completude geral.

• Como o modelo é treinado para ser mais útil? O post descreve o uso de um dataset de preferências humanas construído a partir de feedback de aceitação vs. rejeição, aplicando um método de aprendizado por reforço não pareado chamado KTO para alinhamento.

• Como o post avalia qualidade e velocidade do modelo? Qualidade benchmarkada em benchmarks open-source relacionados a edits (Instinct, FIM, NEP) mais benchmark interno de próximo edit, usando LLM-as-a-judge para correção (e execução de test-cases para FIM). Velocidade medida via latência end-to-end em requests representativos.

• Onde posso usar o modelo? Ele está disponível via API da Inception Platform.

Alternativas

• Assistentes de codificação focados em autocompletar: Estes visam prever tokens ou texto futuros em vez de edições específicas seguintes; podem ser mais simples para completamento de prefixo, mas não se especializam em “o que você mudará em seguida”.
• Modelos de completamento gerais para código: Você pode solicitar a LLMs gerais de código para propor diffs ou edições, mas eles podem não ser otimizados especificamente para latência de previsão de próximo edit e alinhamento de aceitação/rejeição de edições.
• Outros preditores de próximo edit / estilo fill-in-the-middle: Alternativas na mesma categoria seriam modelos avaliados em cenários de edição semelhantes (completamento de linha, renomeação de variável, refatoração, implementação de recurso), diferindo em como geram edições e equilibram qualidade vs. velocidade.
• Sistemas de geração de edições orientados por testes: Algumas abordagens validam edições executando casos de teste (a postagem menciona que FIM usa execução de casos de teste). Esses sistemas podem enfatizar correção por meio de execução, mas diferem em velocidade de fluxo de trabalho e compensações de latência.