Como medimos

1. Por que esta página existe

Compradores céticos não deveriam precisar fazer engenharia reversa de texto de marketing. O Maguyva indexa repositórios e exibe, em todo o site, afirmações de precisão, cobertura de linguagens e custo. Essas afirmações precisam de uma página de metodologia honesta sobre o escopo da medição: o que é respaldado por fixtures, o que é respaldado por julgamento e o que é apenas enquadramento, e não certificação independente.

2. O que medimos

A qualidade da inteligência de código é medida principalmente no motor de linguagens — a extração de símbolos, relações e grafos a partir do código-fonte — não em pontuações subjetivas de «satisfação do agente».

• Suítes de fixtures por linguagem: os edges e símbolos esperados que o handler precisa extrair corretamente
• Release gates: uma linguagem só é lançada quando a precisão, o recall e o F1 das fixtures superam os limites publicados (precisão ≥ 0,95, recall ≥ 0,99, F1 ≥ 0,97 nas fixtures, com uma contagem mínima de edges para confiança estatística)
• Dimensões do language-audit: precisão, integridade estrutural, completude, qualidade e desempenho no painel de validação
• Ciclos de corpus e verificação por amostragem: edges amostrados de repositórios reais, classificados por rubrica (correto, falso positivo, erro de tipo/escopo/metadados) — descritos nos nossos posts de blog sobre language-grind
• Flags de capacidade do produto: o que o servidor anuncia (AST, locals, extração de grafos), separado do tamanho do catálogo

Importante: As fixtures validam contra fixtures que nós mesmos escrevemos. VERDE significa que os casos conhecidos passam. Isso não significa automaticamente que todo idioma do mundo real seja extraído sem erros. Essa distinção é deliberada e pública.

3. Verde vs. verificado de forma independente

O painel de language-audit usa vários eixos para que uma única luz verde não seja lida como «comprovadamente perfeito». Os números principais do painel geralmente se dividem assim:

• overall_green — sem regressões em relação a fixtures self-snapshot e gates de corpus relacionados (necessário, mas não suficiente)
• independently_verified — tem um sinal de julgamento forte, como uma semente de verificação por amostragem (inclui linguagens que ainda mostram erros julgados)
• verified_clean / zero erros julgados em edges amostrados — um subconjunto mais rigoroso de linguagens julgadas
• curation / confiança no oráculo — se as próprias fixtures são tratadas como oráculos confiáveis
• flags estruturais — extração de grafos e capacidade AST não são o mesmo que pertencer ao catálogo

A contagem de linguagens no marketing (por exemplo, «mais de 279 linguagens») é o tamanho do catálogo: linguagens configuradas e entradas de servidor. O tamanho do catálogo não é um SLA de qualidade AST. Preferimos um relatório em camadas a um único número vaidoso. Para a superfície de produto atual, veja Compatibilidade e Guias de Linguagens; para detalhes narrativos, veja o post do blog sobre a automelhoria recursiva de linguagens.

4. Qualidade de busca e retrieval

A qualidade da busca semântica é multimodal: texto, AST, grafo e embeddings são combinados. Documentamos trade-offs de engenharia deliberados em vez de afirmar um retrieval imbatível:

• Os embeddings usam uma família de modelos comerciais (voyage-4-large, segundo o snapshot do blog de junho de 2026), escolhida com base em rankings públicos de retrieval no momento da decisão
• Os vetores são quantizados em binário por armazenamento e custo; isso troca deliberadamente um pouco de precisão de retrieval por uma busca de Hamming mais barata e rápida, sem um banco de dados vetorial separado
• O intent routing e os pesos de fusão são heurísticas projetadas com efeitos operacionais medidos (por exemplo, taxas menores de resultado zero após o intent routing), não uma suíte de avaliação de IR independente publicada sobre corpora de clientes
• Os posts do blog incluem seções de «o que ainda é imperfeito» — sinais imperfeitos fazem parte do registro, não são notas de rodapé para esconder

5. Afirmações de custo

A linguagem sobre custo no Maguyva trata da estrutura de preços e da transparência operacional, não de um estudo formal de TCO certificado por terceiros.

• Preço por workspace: cobrado por repositórios, linhas indexadas e frequência de reconstrução — não por assento humano ou de agente. A FAQ e os textos dos planos detalham essas dimensões.
• Comparações do tipo «cerca de 10 a 30 vezes menos» na página de Preços são cálculos ilustrativos frente a faixas típicas de preço por assento, dependendo de qual ferramenta com preço por assento você está comparando. Não são um pacote de benchmark competitivo independente e fechado.
• Honestidade sobre custos operacionais: a página /team publica uma real ventilação mensal do burn de software (assinaturas, ferramentas de MCP/busca, custos conforme o uso). Isso é transparência customer-zero, não uma demonstração financeira auditada.
• Os custos de embedding e infraestrutura são custos de produto assumidos (embeddings premium, armazenamento, reconstruções de grafo). Nós os pagamos de propósito e dizemos isso no post sobre voyage-4-large e na narrativa de preços.

6. O que não afirmamos

Esta página também é uma lista de não-afirmações. Se algo não está no painel de medição, não trate o tom de marketing como prova.

• Nenhuma garantia geral de precisão absoluta para cada linguagem. Os limites das fixtures se aplicam por linguagem em casos conhecidos; uma margem residual de erro no mundo real é esperada e assumida abertamente.
• Nenhuma afirmação de que overall_green equivale a uma extração perfeita em produção para cada idioma de repositório
• Nenhum pacote de certificação de conformidade de terceiros é apresentado como artefato de metodologia nesta página (veja Segurança para os fatos sobre o tratamento de dados, não para selos de conformidade)
• Nenhum bake-off independente multi-fornecedor com corpora compartilhados publicado como scorecard permanente
• Os resultados de busca e as análises continuam sendo best-effort sob os Termos de Serviço — o Maguyva não substitui revisão de código, testes ou auditorias de segurança

7. Como verificar você mesmo

O caminho pensado para quem avalia a compra continua o mesmo: indexe um repo que você já conhece, faça uma pergunta real e inspecione as citações.

• Comece de graça: uns poucos repositórios representativos vencem um índice de toda a empresa já no primeiro dia
• Use as ferramentas MCP (intelligent_search, find_symbol, dependency_search) e abra os caminhos citados
• Leia Como Funciona para a arquitetura de ingestão e retrieval
• Leia Compatibilidade e Guias de Linguagens para os níveis de capacidade, não só o tamanho do catálogo
• Leia Segurança e Privacidade para o tratamento de dados; esta página não os substitui