Mercury Edit 2

Cos'è Mercury Edit 2?

Mercury Edit 2 è un LLM diffusion purpose-built (dLLM) per la predizione del prossimo edit nei workflow di sviluppo software. È progettato per aiutare nel passo più sensibile alla latenza nell'assistenza al coding: suggerire cosa cambierai probabilmente dopo, in base alle modifiche recenti e al contesto del codebase circostante.

Il modello integra l'endpoint di auto-complete esistente di Inception, focalizzandosi specificamente sui suggerimenti di edit. In pratica, puoi accettare un edit previsto (ad esempio, con tab) quando il suggerimento si adatta a ciò su cui stai lavorando.

Caratteristiche Principali

• Predizione next-edit da storico edit e contesto codice: Usa “recent edits” più contesto codebase per generare un suggerimento mirato su cosa cambiare dopo.
• Generazione token diffusion-based in parallelo: Genera token con diffusion e li esegue in parallelo per ridurre il tempo al primo suggerimento, per un UX a bassa latenza.
• Addestramento allineato alle preferenze con feedback umano: Crea un dataset di preferenze umane da feedback esplicito accept/reject, poi applica un metodo di reinforcement learning unpaired (KTO) per allineare i suggerimenti alle preferenze umane.
• Edit più selettivi e meno distraenti (come misurato nel post): Miglioramenti riportati includono il 48% di edit accettati in più e il 27% di selettività maggiore in ciò che mostra.
• Copertura benchmark per correttezza edit e velocità: La qualità è valutata su un set di benchmark (inclusi open-source come Instinct, Fill-in-the-middle (FIM) e Next-edit Prediction (NEP)) più un benchmark interno next-edit; la velocità è misurata via latenza end-to-end su richieste rappresentative.
• Disponibile via Inception Platform API: Puoi accedere a Mercury Edit 2 tramite l'Inception API (incluso un riferimento APIZedProxy per utenti Zed).

Come Usare Mercury Edit 2

• Ottieni accesso sulla Inception Platform: Crea un account sulla Inception API Platform per iniziare a usare Mercury Edit 2.
• Chiama il modello tramite API: Usa l'Inception API per inviare richieste di predizioni next-edit (il post fa riferimento a un workflow API, incluso APIZedProxy per integrazione Zed).
• Integra in un workflow editor: Se lo incorpori in un ambiente di sviluppo, usa le predizioni next-edit del modello insieme all'azione di accettazione dell'editor (es. “Just Tab to accept”, come descritto nel post).

Casi d'Uso

• Suggerimenti next-change in IDE/editor durante coding attivo: Quando fai una serie di edit, usa Mercury Edit 2 per suggerire cosa cambierai probabilmente dopo, puntando a risposte a bassa latenza.
• Aiuto refactoring con proposte edit-targeted: Genera suggerimenti per cambiamenti come rinominazioni, passi di refactoring o altri edit strutturati dove il framing “next edit” si adatta al workflow.
• Workflow FIM/line completion adattati agli edit: In contesti dove il completion da solo non basta, usa la predizione next-edit per proporre l'edit che segue dalla tua sequenza di edit corrente e codice circostante.
• Iterazione implementazione feature: Mentre aggiungi funzionalità, affidati alla predizione next-edit per suggerire cambiamenti successivi (come modifiche follow-up) basati su edit recenti.
• Riduzione suggerimenti indesiderati via allineamento preferenze: Usa il comportamento addestrato sulle preferenze per abbassare frequenza e lunghezza di edit che altrimenti ti distrarrebbero (come descritto nel post come motivazione esplicita di training).

FAQ

• Quale problema risolve Mercury Edit 2? Risolve la predizione next-edit nei workflow di coding, dove il sistema deve suggerire cosa cambierai dopo con bassa latenza.

• Come differisce dall'auto-complete? Il post afferma che Mercury Edit 2 integra un endpoint auto-complete esistente focalizzandosi specificamente sui suggerimenti di edit anziché sul completion generale.

• Come è addestrato il modello per essere più utile? Il post descrive l'uso di un dataset di preferenze umane costruito da feedback accept vs. reject, poi l'applicazione di un metodo di reinforcement learning unpaired chiamato KTO per l'allineamento.

• Come valuta il post qualità e velocità del modello? La qualità è benchmarkata su benchmark open-source relativi agli edit (Instinct, FIM, NEP) più un benchmark interno next-edit, usando LLM-as-a-judge per correttezza (e esecuzione test-case per FIM). La velocità è misurata con latenza end-to-end su richieste rappresentative.

• Dove posso usare il modello? È disponibile via Inception Platform API.

Alternative

• Assistenti di coding focalizzati sull'auto-completamento: Mirano a prevedere token o testo successivi anziché edit mirati al prossimo cambiamento; possono essere più semplici per il completamento di prefissi ma non specializzati in “cosa cambierai dopo”.
• Modelli di completamento generici per codice: Puoi promptare LLM di codice generici per proporre diff o edit, ma potrebbero non essere ottimizzati specificamente per latenza di predizione next-edit e allineamento accept/reject degli edit.
• Altri predittori di next-edit / fill-in-the-middle: Alternative della stessa categoria sarebbero modelli valutati su scenari edit simili (completamento riga, rinominazione variabili, refactoring, implementazione feature), che differiscono nel modo in cui generano gli edit e bilanciano qualità vs. velocità.
• Sistemi di generazione edit test-driven: Alcuni approcci validano gli edit eseguendo casi di test (le note post menzionano che FIM usa esecuzione test-case). Tali sistemi enfatizzano correttezza tramite esecuzione ma possono differire in velocità workflow e tradeoff di latenza.