DeepSearchQA

Encontrar um fato e encontrar todos os fatos são problemas de pesquisa diferentes. Uma única consulta de sorte pode encontrar uma resposta do BrowseComp; uma resposta do DeepSearchQA precisa ser montada ao longo de várias pesquisas, com o agente acompanhando o que encontrou e o que ainda falta. Essa pressão por cobertura exercita uma parte diferente da infraestrutura de pesquisa: a abrangência dos resultados e a deduplicação importam tanto quanto a classificação.

Executamos o teste mantendo o modelo fixo porque isso isola as variáveis que os usuários do OpenRouter realmente controlam. Elas são qual mecanismo realiza as pesquisas, se a pesquisa é executada como ferramenta do servidor ou como plugin e quantos turnos do agente são permitidos no ciclo. Esses parâmetros são exatamente o que você pode configurar em uma requisição hoje.

Essas pontuações comparam configurações de pesquisa, não produtos de agentes. O modelo lê apenas trechos dos resultados de pesquisa, sem buscar páginas completas e sem ferramentas de código, por isso os números absolutos ficam abaixo dos rankings publicados de agentes, que permitem ambos os recursos. Compare configurações, não valores brutos.

A avaliação de tudo ou nada torna esta bateria rigorosa: deixar de incluir um item da lista recebe a mesma pontuação que deixar de incluir todos, por isso as pontuações são baixas e pequenas diferenças entre mecanismos têm muito ruído. Intervalos de confiança sobrepostos são tratados aqui como inconclusivos, não como prova de igualdade. O custo de uma configuração é tão real quanto sua pontuação, por isso avalie qualidade e eficiência em conjunto.

As perguntas são públicas, o que significa que a memorização pode inflar as pontuações absolutas ao longo do tempo; as diferenças entre configurações de pesquisa continuam sendo relevantes porque todas as configurações usam o mesmo modelo.

Cada tarefa é uma pergunta com uma lista de referência das partes esperadas da resposta. Um modelo avaliador verifica a resposta em relação a cada parte esperada e também sinaliza respostas excessivas — partes que a resposta afirma e que não constam na referência. Uma tarefa só está correta quando o avaliador encontra todas as partes esperadas e não encontra respostas excessivas. A nota é binária, sem pontuação parcial, e tarefas que falham ou são recusadas recebem zero.

reward = all_expected_parts_found ∧ no_excessive_answers   // ∈ {0, 1}
judge  = gemini-2.5-flash, strict json_schema completeness verdict
empty or refused answers skip the judge and score 0

Uma configuração de pesquisa consiste em um modelo, um mecanismo de pesquisa, um formato de solicitação e um orçamento máximo de pesquisa. As pontuações são ponderadas pelo número de perguntas em cada execução verificada; pequenos testes de verificação básica são excluídos.

As execuções são realizadas no Kepler, o harness de avaliação comparativa do OpenRouter, usando endpoints de produção. As configurações de ferramentas de servidor definem um orçamento de chamadas de ferramenta por requisição na ferramenta de servidor de pesquisa na web. As configurações de plugin fazem uma pesquisa da pergunta antes da inferência com o plugin de pesquisa na web. Os mecanismos usam as mesmas configurações padrão que atendem ao tráfego de produção.

Cada execução persiste seu modelo exato, mecanismo, formato de solicitação, orçamento de pesquisa, custo e telemetria de tempo disponível. As configurações ausentes permanecem ausentes na tabela de comparação, e absent or zero telemetry is not treated as free or instantaneous performance.