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: as arestas e os símbolos esperados que o handler precisa extrair corretamente
• Classificação de acurácia das fixtures: GREEN exige precisão ≥ 0.95, recall ≥ 0.99, F1 ≥ 0.97 e pelo menos 20 arestas esperadas, além de verificações adicionais de curadoria das fixtures. Essa é uma regra para casos de teste conhecidos, não uma estimativa de confiança estatística nem uma afirmação de que todas as linguagens habilitadas são GREEN.
• Dimensões do language-audit: acurácia, integridade estrutural, completude, qualidade e desempenho no painel de validação
• Ciclos de corpus e verificação por amostragem: arestas amostradas de repositórios reais, classificadas segundo critérios definidos (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: A validação com fixtures usa casos de teste que nós mesmos escrevemos. VERDE significa que os casos conhecidos passam. Isso não significa automaticamente que todo padrão de código encontrado na prática 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 critérios de aprovação 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 arestas amostradas — 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 285 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 as informações atuais do produto, veja Compatibilidade e Guias de Linguagens; para detalhes narrativos, veja o post do blog sobre o autoaperfeiçoamento recursivo do suporte a linguagens.

4. Qualidade de busca e recuperação

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 uma recuperação de informação 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 recuperação de informação no momento da decisão
• Os vetores são quantizados em binário para reduzir o espaço de armazenamento e o custo; isso troca deliberadamente um pouco de precisão de recuperação por uma busca de Hamming mais barata e rápida, sem um banco de dados vetorial separado
• O roteamento por intenção e os pesos de fusão são heurísticas projetadas. Uma proposta de dezembro de 2025 estimou uma taxa inicial de consultas sem resultados de aproximadamente 15% e definiu uma meta abaixo de 5%; não fornecemos um conjunto de consultas nem um registro de medição que demonstre essa redução. O registro de evidências corrige a afirmação anterior de uma melhoria já alcançada.
• 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 usuário humano ou agente. A FAQ e os textos dos planos detalham essas dimensões.
• O exemplo de preços compara 25 usuários pagos a um preço ilustrativo de $19–$59 por usuário com o Crew a $49/mês. A economia varia conforme o tamanho da equipe e o produto alternativo; não é uma comparação de recursos equivalentes nem um benchmark competitivo independente.
• Honestidade sobre custos operacionais: a página /team publica uma discriminação dos gastos mensais reais com 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 trabalhamos continuamente para reduzi-la.
• Nenhuma afirmação de que overall_green equivale a uma extração perfeita em produção para cada padrão de código encontrado nos repositórios
• 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)
• Nenhuma comparação independente entre vários fornecedores, com corpora compartilhados, publicada como quadro permanente de avaliação
• 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 recuperação
• 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