> methodology.md
Come misuriamo
Questa pagina è, letteralmente, il posto dove leggere come sono fondate le affermazioni di Maguyva su qualità e costi. Contiene solo fatti: cosa misuriamo, come lo valutiamo e cosa non pretendiamo di aver verificato.
In vigore dal 17 luglio 2026. Qui non si inventano nuovi benchmark non verificati. I numeri attuali vivono su superfici di prodotto che si rigenerano dai dati sorgente; questa pagina spiega il modello di misurazione.
Questa è una traduzione assistita da IA fornita per tua comodità. La versione ufficiale in inglese è l'unica vincolante — qualsiasi accordo tu stipuli al momento dell'iscrizione è regolato dal testo in inglese. Leggi la versione ufficiale in inglese
tl;dr — Le affermazioni sulla qualità si basano su fixture release gate e su board di language-audit multidimensionali — non su una singola prova di «precisione al 100%». Essere verdi sulle fixture non equivale a un'estrazione corretta verificata in modo indipendente. Le affermazioni sui costi sono calcoli di prezzo per workspace e trasparenza pubblica sui costi operativi, non un audit competitivo di terze parti.
1. Perché esiste questa pagina
Gli acquirenti scettici non dovrebbero dover fare reverse engineering del testo di marketing. Maguyva indicizza repository e mostra, in tutto il sito, affermazioni su precisione, copertura linguistica e costi. Queste affermazioni hanno bisogno di una pagina di metodologia onesta sull'ambito della misurazione: cosa è supportato da fixture, cosa è supportato da giudizio, e cosa è semplice framing invece di certificazione indipendente.
2. Cosa misuriamo
La qualità dell'intelligenza del codice si misura principalmente sul motore linguistico — l'estrazione di simboli, relazioni e grafi dal codice sorgente — non su punteggi soggettivi di «felicità dell'agente».
- Suite di fixture per linguaggio: gli edge e i simboli attesi che l'handler deve estrarre correttamente
- Release gate: un linguaggio viene rilasciato solo quando precisione, recall e F1 delle fixture superano le soglie pubblicate (precisione ≥ 0,95, recall ≥ 0,99, F1 ≥ 0,97 sulle fixture, con un numero minimo di edge per l'affidabilità statistica)
- Dimensioni del language-audit: accuratezza, integrità strutturale, completezza, qualità e prestazioni sulla board di validazione
- Cicli di corpus e controllo a campione: edge campionati da repository reali, classificati per rubrica (corretto, falso positivo, errore di tipo/scope/metadati) — descritti nei nostri post del blog sul language-grind
- Flag di capacità del prodotto: cosa dichiara il server (AST, locals, estrazione di grafi), separato dalla dimensione del catalogo
Importante: Le fixture vengono validate contro fixture che abbiamo scritto noi stessi. VERDE significa che i casi noti passano. Non significa automaticamente che ogni idioma reale venga estratto in modo pulito. Questa distinzione è deliberata e pubblica.
3. Verde vs. verificato in modo indipendente
La board di language-audit usa più assi, così una singola luce verde non può essere letta come «dimostrato perfetto». I numeri principali sulla board si dividono in genere così:
- overall_green — senza regressioni rispetto a fixture self-snapshot e ai relativi gate di corpus (necessario, ma non sufficiente)
- independently_verified — ha un forte segnale di giudizio, come un seed di controllo a campione (include linguaggi che mostrano ancora errori giudicati)
- verified_clean / zero errori giudicati sugli edge campionati — un sottoinsieme più rigoroso dei linguaggi giudicati
- curation / fiducia nell'oracolo — se le fixture stesse sono trattate come oracoli affidabili
- flag strutturali — l'estrazione di grafi e la capacità AST non equivalgono all'appartenenza al catalogo
Il conteggio dei linguaggi nel marketing (per esempio «oltre 279 linguaggi») è la dimensione del catalogo: linguaggi configurati e voci del server. La dimensione del catalogo non è uno SLA di qualità AST. Preferiamo un reporting a livelli rispetto a un singolo numero vanitoso. Per lo stato attuale del prodotto, vedi Compatibilità e Guide ai linguaggi; per i dettagli narrativi, vedi il post del blog sull'auto-miglioramento ricorsivo dei linguaggi.
4. Qualità di ricerca e retrieval
La qualità della ricerca semantica è multimodale: testo, AST, grafo ed embedding vengono fusi. Documentiamo compromessi ingegneristici deliberati invece di dichiarare un retrieval imbattibile:
- Gli embedding usano una famiglia di modelli commerciali (voyage-4-large secondo lo snapshot del blog di giugno 2026), scelta in base alle classifiche pubbliche di retrieval al momento della decisione
- I vettori sono quantizzati in binario per storage e costi; questo scambia deliberatamente un po' di precisione di retrieval con una ricerca di Hamming più economica e veloce, senza un database vettoriale separato
- L'intent routing e i pesi di fusione sono euristiche progettate con effetti operativi misurati (per esempio tassi di risultati nulli più bassi dopo l'intent routing), non una suite di valutazione IR indipendente pubblicata su corpus di clienti
- I post del blog includono sezioni su «cosa è ancora imperfetto» — i segnali imperfetti fanno parte del resoconto, non sono note a piè di pagina da nascondere
5. Affermazioni sui costi
Il linguaggio sui costi di Maguyva riguarda la struttura dei prezzi e la trasparenza operativa, non uno studio formale di TCO certificato da terzi.
- Prezzo per workspace: fatturato in base a repository, righe indicizzate e frequenza di rebuild — non per postazione umana o agente. FAQ e descrizioni dei piani spiegano queste dimensioni nel dettaglio.
- I confronti del tipo «circa 10-30 volte in meno» nella pagina Prezzi sono calcoli illustrativi rispetto a range tipici di prezzo per postazione, a seconda dello strumento a prezzo per postazione con cui li confronti. Non sono un pacchetto di benchmark competitivo indipendente e fisso.
- Onestà sui costi operativi: la pagina /team pubblica una vera ripartizione mensile del burn del software (abbonamenti, tooling MCP/ricerca, costi legati all'uso). Questa è trasparenza customer-zero, non un bilancio verificato.
- I costi di embedding e infrastruttura sono costi di prodotto accettati (embedding premium, storage, rebuild dei grafi). Li paghiamo di proposito e lo diciamo apertamente nel post su voyage-4-large e nel racconto sui prezzi.
6. Cosa non affermiamo
Questa pagina è anche un elenco di non-affermazioni. Se qualcosa non è sulla board di misurazione, non considerare il tono di marketing come prova.
- Nessuna garanzia generale di precisione assoluta per ogni linguaggio. Le soglie delle fixture si applicano per linguaggio sui casi noti; un margine residuo di errore nel mondo reale è previsto e riconosciuto apertamente.
- Nessuna affermazione secondo cui overall_green equivalga a un'estrazione perfetta in produzione per ogni idioma di repository
- Nessun pacchetto di certificazione di conformità di terze parti viene presentato come artefatto di metodologia in questa pagina (vedi Sicurezza per i fatti sul trattamento dei dati, non per badge di conformità)
- Nessun confronto indipendente multi-vendor con corpus condivisi pubblicato come scorecard permanente
- I risultati di ricerca e le analisi restano best-effort secondo i Termini di servizio — Maguyva non sostituisce code review, test o audit di sicurezza
7. Come verificare di persona
Il percorso pensato per chi valuta l'acquisto resta lo stesso: indicizza un repo che già conosci, fai una domanda vera e controlla le citazioni.
- Inizia gratis: pochi repository rappresentativi battono l'indicizzazione di un'intera azienda già dal primo giorno
- Usa gli strumenti MCP (intelligent_search, find_symbol, dependency_search) e apri i percorsi citati
- Leggi Come funziona per l'architettura di ingestion e retrieval
- Leggi Compatibilità e Guide ai linguaggi per i livelli di capacità, non solo la dimensione del catalogo
- Leggi Sicurezza e Privacy per il trattamento dei dati; questa pagina non li sostituisce