> methodology.md
Hvordan vi måler
Denne siden er bokstavelig talt stedet for å lese hvordan kvalitets- og kostnadspåstandene om Maguyva er forankret. Den er rene fakta: hva vi måler, hvordan vi poengsetter det, og hva vi ikke later som vi har revidert.
Sist oppdatert: 2026-10. Gjeldende tall regenereres fra kildedata; denne siden forklarer målemodellen. Den lenkede dokumentasjonen skiller implementerte fixture-regler fra tidligere, ubekreftede søkemål.
- Kvalitetskrav for testtilfeller
- Language-audit-dimensjoner
- Kostnadstransparens
Dette er en AI-assistert oversettelse gitt for din bekvemmelighet. Den offisielle engelske versjonen er den eneste bindende — enhver avtale du inngår når du registrerer deg, styres av den engelske teksten. Les den offisielle engelske versjonen
tl;dr — Kvalitetsrapporteringen bruker fixture-klassifiseringer og flerdimensjonale tavler for språkaudit. GREEN på kjente fixtures er verken uavhengig verifisert korrekt ekstraksjon eller en garanti for at alle aktiverte språk oppfyller tersklene. Kostnadspåstander er beregninger av workspace-priser og offentlig åpenhet om driftskostnader, ikke en konkurranserevisjon utført av en tredjepart.
1. Hvorfor denne siden finnes
Skeptiske kjøpere skal ikke måtte reverse-engineere markedsføringstekst. Maguyva indekserer repositories og viser presisjons-, språkdeknings- og kostnadspåstander på hele siden. Disse påstandene trenger en metodebeskrivelse som er ærlig om måleomfanget: hva som er fixture-belagt, hva som er vurderingsbelagt, og hva som er fremstilling fremfor uavhengig sertifisering.
2. Hva vi måler
Kvaliteten på kodeintelligens måles primært på språkmotoren — ekstraksjon av symboler, relasjoner og grafer fra kilden — ikke på subjektiv agenttilfredshet.
- Testsett per språk: forventede kanter og symboler som språkbehandleren må ekstrahere korrekt
- Klassifisering av fixture-nøyaktighet: GREEN krever presisjon ≥ 0,95, recall ≥ 0,99, F1 ≥ 0,97 og minst 20 forventede kanter, i tillegg til kontroll av utvalg og vedlikehold av fixtures. Dette er en regel for kjente testtilfeller, ikke et estimat av statistisk konfidens eller en påstand om at alle aktiverte språk er GREEN.
- Language-audit-dimensjoner: nøyaktighet, strukturell integritet, fullstendighet, kvalitet og ytelse på valideringstavlen
- Korpus- og stikkprøveløkker: utvalgte kanter fra ekte repositories, klassifisert etter vurderingskriterier (korrekt, falsk positiv, type-/omfangs-/metadatafeil) — beskrevet i våre language-grind-blogginnlegg
- Produktets funksjonsflagg: det serveren oppgir (AST, lokale variabler, grafekstraksjon), atskilt fra katalogstørrelsen
Viktig: Fixtures valideres mot fixtures vi selv har skrevet. GRØNT betyr at de kjente tilfellene består. Det betyr ikke automatisk at hvert idiom fra den virkelige verden ekstraheres feilfritt. Det skillet er bevisst og offentlig.
3. Grønt versus uavhengig verifisert
Language-audit-tavlen bruker flere akser, slik at ett enkelt grønt lys ikke kan leses som “bevist perfekt.” Hovedtallene på tavlen er vanligvis delt opp:
- overall_green — regresjonsrent mot self-snapshot-fixtures og relaterte corpus gates (nødvendig, ikke tilstrekkelig)
- independently_verified — har et sterkt vurderingsgrunnlag, for eksempel en stikkprøve (inkluderer språk der vurderingen fortsatt finner feil)
- verified_clean / ingen feil funnet ved vurdering av utvalgte kanter — en strengere delmengde av de vurderte språkene
- kuratering / tillit til fasiten — om testtilfellene selv regnes som pålitelige fasiter
- strukturelle flagg — grafekstraksjon og AST-støtte er ikke det samme som å være oppført i katalogen
Markedsføringens språktall (for eksempel “285+ språk”) er katalogstørrelse: konfigurerte språk og serveroppføringer. Katalogstørrelse er ikke en AST-kvalitets-SLA. Vi foretrekker nivådelt rapportering fremfor ett enkelt skrytetall. For den nåværende produktflaten, se Kompatibilitet og Språkguider; for narrativ detalj, se innlegget om språkenes rekursive selvforbedring på bloggen.
4. Kvalitet på søk og retrieval
Kvaliteten på semantisk søk er multimodal: tekst, AST, graf og embeddings smeltes sammen. Vi dokumenterer bevisste ingeniøravveininger fremfor å hevde uslåelig retrieval:
- Embeddings bruker en kommersiell modellfamilie (voyage-4-large per blogg-øyeblikksbildet fra juni 2026), valgt mot offentlige retrieval-topplister på beslutningstidspunktet
- Vektorer er binært kvantisert for lagring og kostnad; det bytter bevisst bort noe retrieval-presisjon mot billigere, raskere Hamming-søk uten en separat vektordatabase
- Intensjonsruting og fusjonsvekter er utviklede heuristikker. Et forslag fra desember 2025 anslo en opprinnelig andel søk uten resultater på omtrent 15 % og satte et mål under 5 %; vi har ikke lagt frem et spørresett eller en målerapport som dokumenterer denne reduksjonen. Evidensdokumentasjonen korrigerer den tidligere påstanden om en oppnådd forbedring.
- Blogginnlegg inkluderer avsnitt om “hva som fortsatt er ufullstendig” — ufullstendige signaler er en del av protokollen, ikke fotnoter som skjules
5. Kostnadspåstander
Kostnadsspråket hos Maguyva handler om prisstruktur og driftstransparens, ikke en formell TCO-studie sertifisert av tredjepart.
- Workspace-prising: faktureres etter repositories, indekserte linjer og ombyggingsfrekvens — ikke per bruker eller per agent. FAQ og planomtaler forklarer dimensjonene.
- Priseksemplet sammenligner 25 betalte lisenser til en illustrativ pris på $19–$59 per bruker med Crew til $49/måned. Besparelsen varierer med teamstørrelse og alternativt produkt; dette er ikke en sammenligning av like funksjoner eller en uavhengig konkurransebenchmark.
- Ærlighet om driftskostnader: /team-siden publiserer en reell månedlig oversikt over programvarekostnader (abonnementer, MCP-/søkeverktøy, bruksbaserte kostnader). Det er customer-zero-transparens, ikke et revidert regnskap.
- Embedding- og infrakostnader er aksepterte produktkostnader (premium-embeddings, lagring, grafombygginger). Vi betaler dem med hensikt og sier det i voyage-4-large-innlegget og prisingsfortellingen.
6. Hva vi ikke påstår
Denne siden er også en liste over ikke-påstander. Hvis noe ikke er på måletavlen, ikke behandle markedsføringstonen som bevis.
- Ingen generell garanti for absolutt presisjon for alle språk. Fixture-terskler gjelder per språk på kjente tilfeller; gjenværende feil fra den virkelige verden er forventet og reduseres gjennom kontinuerlig forbedring.
- Ingen påstand om at overall_green tilsvarer produksjonsperfekt ekstraksjon for hvert repository-idiom
- Vi fremsetter ikke tredjeparts samsvarssertifisering som metodisk dokumentasjon på denne siden (se Sikkerhet for fakta om datahåndtering, ikke sertifiseringsmerker)
- Ingen uavhengig multivendor-sammenligning med delte korpus publisert som et stående resultatkort
- Søkeresultater og analyser leveres etter beste evne under tjenestevilkårene — Maguyva erstatter ikke kodegjennomgang, testing eller sikkerhetsrevisjoner
7. Hvordan du verifiserer selv
Den anbefalte fremgangsmåten er fortsatt: indekser et repo du allerede kjenner, still ett ekte spørsmål, og kontroller kildehenvisningene.
- Start gratis: små representative repos slår en hel bedrifts indeks på dag én
- Bruk MCP-verktøy (intelligent_search, find_symbol, dependency_search) og åpne de siterte stiene
- Les Slik fungerer det for arkitekturen bak innhenting og gjenfinning
- Les Kompatibilitet og Språkguider for støttenivåer, ikke bare katalogstørrelse
- Les Sikkerhet og Personvern om datahåndtering; denne siden erstatter dem ikke
- Dokumentasjon og rettelser om søkekvalitet (engelsk)
- Dokumentasjon om søkekvalitet (JSON, engelsk)
- Hvordan det fungerer
- Kompatibilitet
- Priser
- Team
- Sikkerhet
- Personvern
- Status
- Rekursiv selvforbedring for språk: Finsliping av kodeintelligens på tvers av ~280 språk
- Hvorfor vi oppgraderte kodesøk til voyage-4-large