O que conta como evidência de um AI component
Nota: Este documento é uma tradução automática da versão original em inglês.
O que conta como evidência de um AI component
Quando o DecAIHub avalia se um projeto tem um AI component funcional, ele procura por artefatos verificáveis — não material de marketing, não promessas, não associações de marca. Esta página lista os tipos de evidência que fortalecem o eixo AI reality da pontuação DecAI Fit, ordenados do mais forte ao mais fraco.
Em resumo: evidência de IA significa artefatos que você pode inspecionar, testar ou verificar de forma independente — código, documentação, métricas com metodologia, demos funcionais e avaliações de terceiros.
Evidência Tier-1 (a mais forte)
As fontes Tier-1 são artefatos publicados ou controlados pelo próprio projeto. Para o eixo AI reality, a evidência Tier-1 mais forte inclui:
- Repositório público com código de AI/ML — scripts de treinamento de modelo, lógica de inferência, pipelines de dados, etapas de pré-processamento. Um repositório com commits, releases e testes é muito mais forte do que um repositório de marcador de posição com um README.
- Documentação técnica — descrições da arquitetura do modelo, formatos de entrada/saída, versões do modelo e histórico de atualizações. Isto responde "qual modelo, como funciona e qual versão está rodando".
- Métricas de qualidade com metodologia — benchmarks publicados ou resultados de avaliação que especificam o que foi medido, sobre quais dados, quando e com qual versão do modelo. Métricas sem esse contexto não são evidência.
- Demos ou endpoints funcionais — uma interface, API ou sandbox publicamente acessível onde o AI component pode ser testado. Uma demo que processa entradas reais e retorna saídas orientadas por IA é evidência direta.
- Relatórios de auditoria ou avaliações de terceiros — avaliações independentes da qualidade, justiça, segurança ou desempenho do modelo por uma entidade reconhecida.
Padrões que fortalecem a evidência Tier-1
Nem todos os artefatos Tier-1 são igualmente convincentes. Vários padrões observáveis tornam a evidência mais credível:
- Profundidade do histórico de commits. Um repositório com meses ou anos de commits incrementais, pull requests, revisões de código e releases versionados demonstra esforço de engenharia sustentado. Um único upload em massa carrega muito menos peso.
- Cobertura de testes e pipelines de CI. Testes automatizados para inferência do modelo, validação de dados e endpoints de integração indicam um sistema de nível de produção em vez de uma prova de conceito.
- Modelos versionados e changelogs. Quando a documentação rastreia qual versão do modelo está implantada, o que mudou entre versões e por quê, isso sinaliza um sistema vivo com um ciclo de desenvolvimento ativo.
- Saídas reproduzíveis. Se uma demo ou API retorna resultados consistentes e explicáveis para as mesmas entradas em diferentes sessões, isso é mais forte do que uma exibição pontual.
- Separação da lógica de IA do código boilerplate. Um código onde os módulos de AI/ML são claramente identificáveis — distintos do scaffolding de frontend, scripts de implantação ou contratos de token — torna mais fácil verificar o que o AI component realmente faz.
Evidência Tier-2 (contexto, não prova)
As fontes Tier-2 fornecem contexto, mas não provam um AI component funcional por si só:
- Entrevistas ou AMAs onde a equipe descreve a abordagem de IA, a arquitetura ou o processo de treinamento.
- Descrições de agregadores (CoinGecko, DeFiLlama, etc.) mencionando capacidades de IA.
- Anúncios de parceria com provedores de IA ou laboratórios de pesquisa.
A evidência Tier-2 pode apoiar uma constatação Tier-1, mas não pode substituí-la. Uma parceria com uma empresa de IA não prova que o projeto tem sua própria IA funcional.
Quando a evidência Tier-2 importa
As fontes Tier-2 tornam-se relevantes quando corroboram artefatos Tier-1 ou preenchem lacunas que o Tier-1 sozinho deixa ambíguas:
- Uma entrevista técnica em que a equipe percorre a arquitetura descrita em sua documentação adiciona credibilidade aos docs Tier-1.
- Uma listagem em agregador que corresponde às capacidades descritas no whitepaper do próprio projeto sinaliza consistência.
- Uma palestra em conferência com uma demo ao vivo que reflete o comportamento da API pública do projeto reforça que a demo não é roteirizada.
Sem artefatos Tier-1 subjacentes, no entanto, mesmo fontes Tier-2 convincentes permanecem contexto — valiosas para a compreensão, insuficientes para a verificação.
O que não conta
Alguns artefatos parecem evidência, mas não demonstram um AI component funcional. Falsos sinais comuns incluem material de marketing, repositórios vazios, métricas sem metodologia e API wrappers sem lógica proprietária. Para uma lista detalhada, veja O que não conta como evidência de IA.
Como o DecAIHub registra a evidência de IA: flags AI_0 a AI_4
O eixo AI reality usa cinco flags binárias para capturar quais evidências foram encontradas:
| Flag | O que verifica | Valor |
|---|---|---|
| AI_0 | Há pelo menos uma declaração Tier-1 de intenção de IA (roadmap, atualização oficial) | 1 / 0 |
| AI_1 | Há uma descrição do que a IA faz | 1 / 0 |
| AI_2 | Há demos ou exemplos funcionais | 1 / 0 |
| AI_3 | Há métricas de qualidade com contexto (o quê, sobre quais dados, quando) | 1 / 0 |
| AI_4 | Há uma descrição técnica, arquitetura ou versões do modelo | 1 / 0 |
Quanto mais flags forem iguais a 1, maior o ai_score e melhor o DecAI Fit do projeto. Se nenhuma das flags estiver definida, ai_score = 0 e o DecAI Fit não pode exceder 0.
Como as combinações de flags se mapeiam à confiança
Flags individuais respondem a perguntas estreitas, mas sua combinação pinta um quadro mais completo:
| Flags definidas | Interpretação típica |
|---|---|
| Apenas AI_0 | Intenção declarada; nenhuma IA funcional verificada ainda |
| AI_0 + AI_1 | IA descrita em palavras; sem demo, sem métricas, sem arquitetura |
| AI_0 + AI_1 + AI_2 | Existe uma demo funcional; ainda sem métricas ou profundidade técnica |
| AI_0 + AI_1 + AI_2 + AI_4 | Demo e arquitetura presentes; medição de qualidade ausente |
| Todas as cinco (AI_0 a AI_4) | O perfil de evidência mais forte: intenção, descrição, demo, métricas e arquitetura |
Um projeto não precisa satisfazer todas as cinco flags para receber um ai_score diferente de zero. Mesmo AI_0 sozinho (intenção com uma fonte Tier-1) define ai_score = 1. No entanto, flags mais altas contribuem para um teto mais alto do DecAI Fit.
Por que a metodologia importa para as métricas
Um número isolado — "95% de acurácia", "baixa latência", "estado da arte" — não é evidência sem contexto. O DecAIHub considera as métricas significativas apenas quando elas respondem a quatro perguntas: o que foi medido (acurácia, F1, latência, perplexidade), sobre quais dados (benchmark público, conjunto de teste proprietário, tráfego de produção), quando (data da avaliação) e qual versão do modelo produziu o resultado. Sem isso, uma métrica é uma alegação, não uma evidência.
O teste das quatro perguntas
Ao avaliar qualquer métrica publicada, aplique esta checklist:
- O quê — A métrica é nomeada e definida? "Acurácia" é ambígua; "acurácia de classificação top-1" é específica.
- Sobre quais dados — O dataset de avaliação está identificado? Um benchmark público permite reprodução independente; um conjunto de teste proprietário não, mas nomeá-lo é melhor do que o silêncio.
- Quando — Há uma data ou tag de release? Os modelos mudam ao longo do tempo; uma métrica sem carimbo de tempo pode não refletir o sistema atual.
- Qual versão — A versão do modelo ou sistema está declarada? Se um projeto lançou múltiplas iterações de modelo, a métrica deve estar vinculada a uma específica.
Se qualquer uma dessas quatro estiver faltando, a métrica cai de "evidência" para "alegação" na avaliação do DecAIHub. Ela ainda pode aparecer no cartão do projeto como uma alegação registrada, mas não contribuirá para definir a flag AI_3 como 1.
Como usar esta checklist
Ao ler um cartão de projeto, verifique se a tabela de Evidence referencia artefatos da lista Tier-1 acima. Se o cartão mostra ai_score = 0 ou sinaliza uma preocupação de AI-washing, isso significa que esses artefatos não foram encontrados na data da verificação — isto não é uma acusação contra o projeto.
Quando novos artefatos Tier-1 aparecem, o cartão é atualizado e a pontuação pode mudar.
Passos práticos para os leitores
- Comece pela tabela de Evidence. Procure por links para repositórios, documentação ou demos. Se a tabela de Evidence está vazia ou referencia apenas fontes Tier-2/3, a alegação de AI reality é não verificada.
- Clique até chegar aos artefatos. Um link de repositório só vale o que há dentro dele. Abra-o e procure por código de AI/ML, não apenas um README ou scripts de implantação.
- Verifique a data da verificação. A evidência é um instantâneo. Um cartão verificado há seis meses pode não refletir o estado atual do projeto, e é por isso que o DecAIHub aplica uma penalidade de desatualização após 550 dias.
- Faça a referência cruzada com a lista de anti-padrões. Se você vê padrões de O que não conta como evidência de IA, pondere a evidência de acordo.
O que esta checklist sozinha não prova
- Satisfazer todos os critérios de evidência não prova que a IA é de alta qualidade ou útil para os usuários finais. Prova que artefatos existem e podem ser inspecionados.
- A evidência Tier-1 do próprio projeto não prova independência. Dados auto-relatados deveriam, idealmente, ser corroborados por avaliação de terceiros.
- Um registro de evidência completo não prova que o token é necessário. AI reality é um eixo do DecAI Fit; a token necessity é outro.
Perguntas frequentes
O que conta como a evidência mais completa de IA em um projeto de crypto?
Um repositório público contendo código de AI/ML com um histórico de commits significativo, combinado com métricas de qualidade publicadas que incluem a metodologia completa (o que foi medido, sobre quais dados, quando e qual versão do modelo). Quando ambos existem e são apoiados por uma demo ou endpoint de API funcional, o perfil de evidência está no seu mais completo. Nenhum artefato isolado é definitivo por si só — a combinação de código, métricas e saídas testáveis é o que distingue a IA verificada das alegações não verificadas.
Um projeto pode ter IA real sem código aberto?
Sim. O código aberto é a forma mais transparente de evidência, mas não é a única. Um projeto pode demonstrar IA por meio de documentação técnica detalhada, benchmarks publicados com metodologia, APIs funcionais que retornam saídas verificáveis orientadas por IA, ou avaliações independentes de terceiros. No entanto, sem pelo menos algum artefato inspecionável — código, demo ou avaliação — não há nada para o DecAIHub (ou qualquer outra pessoa) verificar. Quanto mais fechado é um projeto, mais ele depende de corroboração Tier-2 (entrevistas, dados de agregadores, demonstrações em conferências) para construir credibilidade.
Uma demo funcional prova que a IA é real?
Uma demo funcional é uma evidência forte, mas não é prova conclusiva por si só. Um frontend bem projetado pode simular comportamento semelhante a IA usando respostas codificadas manualmente, resultados pré-computados ou chamadas ocultas a uma API de terceiros. O DecAIHub trata as demos como evidência mais forte quando acompanhadas de documentação de API, identificadores de versão do modelo ou saídas reproduzíveis em diferentes entradas. Uma demo que aceita entradas arbitrárias do usuário e retorna saídas variadas e contextualmente apropriadas é mais convincente do que uma exibição guiada com exemplos predeterminados.
Qual é a evidência mínima necessária para um ai_score diferente de zero?
O mínimo é uma declaração Tier-1 de intenção de IA — uma entrada de roadmap, um post oficial de blog ou uma página de documentação que declare explicitamente planos relacionados a IA. Isto define a flag AI_0 como 1 e produz ai_score = 1. Embora esta seja a menor pontuação possível diferente de zero, ela distingue os projetos que se comprometeram oficialmente com uma direção de IA daqueles que não mencionaram IA de forma alguma. Para alcançar pontuações mais altas, o projeto precisa fornecer artefatos adicionais: descrições do AI component (AI_1), demos (AI_2), métricas com metodologia (AI_3) e detalhes de arquitetura técnica (AI_4).
Referências externas
- CommonMark specification — o padrão de marcação usado em todas as páginas wiki do DecAIHub, incluindo cartões de projeto e explainers.
- Model Cards for Model Reporting (Mitchell et al., 2019) — um framework fundamental para documentar o desempenho, o uso pretendido e as limitações de modelos de IA; alinhado de perto com os princípios de transparência por trás dos critérios de evidência do DecAIHub.
- NIST AI Risk Management Framework — um framework do governo dos EUA para identificar e gerenciar riscos de IA, incluindo orientação sobre documentação, testes e metodologia de avaliação.
No comments to display
No comments to display