Como avaliar agentes de pesquisa de IA de código aberto

Agentes de pesquisa de IA de código aberto prometem mais controle do que um serviço fechado de respostas, mas a disponibilidade do código é apenas o início de uma avaliação útil. Um repositório pode expor seu código e ainda deixar perguntas importantes sem resposta: que evidência produziu um resultado, quais dados cruzaram uma fronteira de rede, se outro pesquisador consegue executar novamente o fluxo de trabalho e quanto trabalho operacional a instituição precisa absorver.

Uma avaliação sólida, portanto, começa pela prática de pesquisa, não por uma contagem de recursos. O objetivo é determinar se um agente torna um fluxo de trabalho real mais fácil de inspecionar, repetir, governar e manter. AIPOCH Open Science é um estudo de caso útil porque combina gestão de literatura, agentes, notebooks, conectores científicos, arquivos de projeto e computação remota em um aplicativo desktop local-first. Seu design ilustra tanto o potencial de um espaço de trabalho inspecionável quanto a lacuna entre atividade registrada e ciência reproduzível.

Defina a unidade de avaliação

Não avalie um agente de pesquisa apenas perguntando se ele consegue responder a uma pergunta difícil. Primeiro defina a unidade completa de trabalho. Ela pode incluir descobrir artigos, anexar registros de fontes, preparar código, selecionar dados, executar um notebook, enviar um trabalho ao cluster, coletar resultados, produzir uma figura e documentar revisões. Um relatório fluente é uma saída dentro dessa cadeia, não a própria cadeia.

Liste os artefatos e as decisões que um revisor qualificado precisaria examinar. Eles normalmente incluem as entradas originais, citações, scripts gerados, estado do notebook, logs de execução, detalhes do ambiente, seleção de modelo, chamadas externas, arquivos intermediários, saídas finais e conclusões do revisor. Depois verifique se o produto preserva as relações entre eles. Uma pasta cheia de arquivos é menos útil do que um registro que mostra quais entradas, código e execução produziram uma versão específica de um resultado.

A documentação técnica da AIPOCH descreve projetos persistentes que contêm conversas, arquivos, notebooks Python e R, registros de execução, pré-visualizações e proveniência de artefatos. A versão 0.26.0 também conecta uma biblioteca de referências à execução direta por SSH ou Slurm em computadores remotos registrados. Essa amplitude só é relevante se os vínculos sobreviverem às mudanças normais da pesquisa: prompts revisados, análises alternativas, trabalhos interrompidos, fontes substituídas e saídas atualizadas.

Mapeie a fronteira real de controle

“Local-first” deve ser tratado como uma questão a investigar, não como uma conclusão completa sobre privacidade. O estado do projeto pode permanecer em um computador local enquanto prompts, contexto, consultas de busca ou parâmetros de tarefa viajam para um provedor de modelos selecionado, banco de dados científico, repositório ou cluster remoto. A fronteira de controle significativa é o caminho completo percorrido pela informação.

Para cada fluxo de trabalho, faça um diagrama de onde os dados começam, qual componente os recebe, quais credenciais são usadas, o que sai do dispositivo e onde os resultados são armazenados. Repita o exercício para extensões. Uma habilidade reutilizável pode executar código, enquanto um conector pode enviar parâmetros para um serviço externo. O código aberto torna a inspeção possível, mas não realiza essa inspeção pelo usuário.

AIPOCH expõe a escolha de modelos, conectores, computadores remotos e políticas de aprovação para ações como comandos, alterações de arquivos e chamadas de rede. Isso pode ajudar uma instituição a alinhar a ferramenta com seus próprios provedores e infraestrutura. Também transfere trabalho para a instituição: alguém precisa revisar configurações, verificar endpoints, manter credenciais, entender o comportamento das extensões e decidir quais ações merecem permissão persistente.

Inclua controles específicos de plataforma na avaliação. As notas da v0.26.0 da AIPOCH afirmam que os controles de rede dos notebooks se aplicam por padrão no macOS e no Linux, enquanto o Windows precisa de uma configuração única de administrador. A mesma documentação de lançamento observa que seus instaladores para Windows não são assinados com Authenticode. Nenhum detalhe determina se a ferramenta é adequada, mas ambos podem afetar a política de implantação e o esforço de suporte.

Rastreie um resultado da afirmação até a evidência

Um agente de pesquisa útil deve permitir que um revisor retroceda de uma conclusão até as evidências e operações por trás dela. Selecione um resultado representativo, como uma tabela derivada de uma análise ou uma afirmação derivada de vários artigos, e tente reconstruir sua linhagem sem depender da memória do operador original.

AIPOCH fornece um modelo concreto para esse teste. Seu sistema de artefatos pode reter versões imutáveis e somas de verificação, enquanto sua visão de proveniência pode associar uma saída a entradas disponíveis, código, registros de execução, informações de ambiente, contexto de conversa e conclusões de revisão. Sua versão anterior 0.8.0 também introduziu ramificações para caminhos alternativos de conversa. Juntos, esses recursos podem tornar as mudanças visíveis em vez de substituir silenciosamente um estado anterior.

A avaliação ainda deve separar retenção de evidências de validade científica. Uma soma de verificação pode mostrar que um arquivo mudou ou não mudou; não pode mostrar que o método foi apropriado. Um log de execução pode mostrar qual código foi executado; não pode estabelecer que as premissas estatísticas eram sólidas. Um registro de citação pode identificar um artigo; não pode provar que o agente o interpretou corretamente. A inspecionabilidade cria uma superfície melhor para revisão especializada, não verdade automatizada.

Use várias perguntas orientadas a falhas. O revisor consegue identificar qual ramificação produziu o artefato publicado? Consegue ver se uma fonte foi substituída? Consegue distinguir código gerado de código executado? Consegue dizer quais resultados vieram de um trabalho remoto? Consegue preservar uma correção do revisor sem apagar a saída original? Respostas fracas revelam lacunas de proveniência de modo mais confiável do que uma demonstração polida.

Separe auditabilidade de reprodutibilidade

Auditabilidade pergunta se o processo pode ser examinado. Reprodutibilidade pergunta se foi capturado estado suficiente para executá-lo novamente e obter um resultado comparável. Um agente pode se sair bem no primeiro padrão e ainda permanecer incompleto no segundo.

Uma revisão de reprodutibilidade deve procurar entradas identificadas, bloqueios de dependências, detalhes de pacotes e sistema operacional, estados aleatórios, ordem de execução, informações de modelo e provedor, configuração remota e as identidades de conjuntos de dados externos. Ela também deve registrar o que não pode ser congelado. Provedores de modelos podem mudar o roteamento ou a implementação, bancos de dados científicos podem ser atualizados e clusters remotos podem diferir em hardware ou bibliotecas. Registrar apenas um nome de modelo ou uma transcrição de conversa não elimina essas variáveis.

AIPOCH apresenta explicitamente a restauração de ambiente portátil e a repetição completa de sessão como trabalho inacabado. Esse é um limite importante, não uma omissão menor. Seus artefatos retidos e sua proveniência podem apoiar a investigação hoje, mas não devem ser descritos como prova de reconstrução determinística. Uma avaliação deve registrar essa distinção na própria decisão para que os usuários saibam quais fluxos de trabalho ainda exigem gestão externa do ambiente.

Execute uma repetição controlada com dados não sensíveis. Entregue a uma segunda pessoa qualificada o registro de projeto retido, remova o conhecimento informal e peça-lhe que reproduza um artefato. Anote cada dependência ausente, aprovação não documentada, serviço indisponível, movimentação manual de arquivo e instrução ambígua. A lista de lacunas resultante é mais acionável do que uma afirmação geral de que um fluxo de trabalho é reproduzível.

Leia benchmarks como evidência delimitada

Benchmarks podem comparar sistemas sob condições definidas, mas não certificam qualidade de pesquisa em todas as disciplinas. Antes de aceitar uma pontuação, inspecione a fonte da tarefa, a divisão pública e privada, o modelo selecionado, o método de julgamento, o orçamento de execução, a configuração de referência e a disponibilidade de rastros. Pergunte se uma equipe externa consegue reproduzir a configuração e se a métrica relatada expõe modos de falha consequentes.

AIPOCH relata um resultado de 79,05 na parte pública do BiomniBench-DA usando um modelo específico e dois avaliadores automatizados. O cartão de dados do benchmark descreve 100 tarefas de análise de dados biomédicos derivadas de publicações, com 50 tarefas públicas e 50 tarefas privadas. Isso é evidência útil e delimitada sobre trajetórias analíticas de várias etapas. Não é validação em todos os domínios de pesquisa, modelos, instituições ou conjuntos de dados não publicados.

Dê maior peso à replicação independente e à análise detalhada de falhas do que a uma única média. Erros de citação, erros de unidade, escolhas estatísticas inadequadas, interpretações fabricadas e falhas de recuperação podem ficar ocultos por uma pontuação agregada. Um agente inspecionável tem vantagem apenas quando seus registros realmente ajudam revisores a localizar e corrigir essas falhas.

Teste a adequação operacional, não apenas a capacidade

A integração pode reduzir transferências entre ferramentas de referência, interfaces de chat, notebooks, terminais e navegadores de arquivos. Ela também amplia a superfície que os mantenedores precisam suportar. Empacotamento desktop, migrações de banco de dados, credenciais, APIs de modelos, execução de notebooks, pré-visualizações científicas, conectores e agendadores de cluster podem falhar independentemente.

O suporte a Slurm da AIPOCH ilustra a distinção entre integração e infraestrutura fornecida. O aplicativo desktop pode enviar, monitorar, recuperar, cancelar, limpar e coletar resultados de trabalhos em um host configurado. Ele não transforma um laptop em um ambiente de computação de alto desempenho nem fornece um serviço integrado de GPU em nuvem. Um laboratório ainda precisa de computação funcional, controles de acesso, política de agendador e pessoas capazes de diagnosticar falhas.

As permissões merecem um teste de usabilidade baseado em tarefas. Uma issue pública de uma versão inicial da AIPOCH descreveu solicitações repetidas de autorização durante trabalho de escrita de código; a issue foi posteriormente encerrada, e lançamentos subsequentes incluíram mudanças de permissão. Esse histórico não estabelece o comportamento atual, mas identifica um teste produtivo: se os prompts ocorrem em fronteiras de risco compreensíveis ou se se tornam interrupções rotineiras que os usuários aprovam automaticamente.

Meça o esforço de instalação, a recuperação de trabalhos com falha, o comportamento de atualização, a revisão de extensões, a clareza dos logs e o tempo necessário para integrar um segundo operador. Registre quem é responsável por cada tarefa após a adoção. Uma ferramenta pode oferecer controle valioso e ainda assim ser inadequada se a organização não puder manter o plano de controle ao seu redor.

Use uma lista de verificação de avaliação em etapas

Comece com um fluxo de trabalho representativo e não sensível e uma linha de base estabelecida. Mantenha o piloto estreito o suficiente para que cada etapa possa ser examinada. Em seguida, use esta lista de verificação:

1. Defina a questão de pesquisa, os artefatos esperados, a evidência aceitável e o revisor especialista antes de executar o agente.
2. Faça o inventário de cada componente local e externo, incluindo modelos, conectores, habilidades, bancos de dados, repositórios e computadores remotos.
3. Registre quais dados cruzam cada fronteira e verifique se as permissões correspondem às regras institucionais.
4. Siga uma afirmação final de volta por citações, entradas, código, execução, arquivos intermediários e versões de artefatos.
5. Altere uma premissa e confirme que o caminho alternativo permanece distinguível do original.
6. Entregue o registro retido a um segundo operador e documente cada barreira para executar novamente o fluxo de trabalho.
7. Inspecione condições e rastros de benchmark; trate as pontuações como evidência apenas para a configuração testada.
8. Introduza uma falha de execução ou de rede e avalie recuperação, logs, limpeza e integridade dos artefatos.
9. Revise extensões importadas quanto a fonte, licença, scripts, comportamento de rede, versão e mantenedor.
10. Compare qualidade de saída, tempo de revisão, esforço de configuração, taxa de falhas e carga de suporte com o processo existente.
11. Classifique lacunas não resolvidas como riscos científicos, de segurança, de usabilidade ou operacionais e atribua um responsável.
12. Aprove apenas os fluxos de trabalho cujas evidências e controles atendem ao padrão exigido; evite conceder por padrão ao produto uma confiança mais ampla.

A decisão final deve ser específica. Declare quais tarefas o agente pode executar, quais dados pode acessar, quais ações exigem aprovação, quais evidências devem acompanhar uma saída e quando a revisão humana é obrigatória. Declare também o que a avaliação não comprovou.

Agentes de pesquisa de código aberto são mais valiosos quando tornam o trabalho consequente mais fácil de questionar. AIPOCH mostra como registros de literatura, notebooks, execução remota, ramificações e proveniência de artefatos podem ser reunidos em um espaço de trabalho inspecionável. Também mostra por que um repositório aberto, uma pontuação de benchmark ou um fluxo de trabalho visível não bastam por si sós. O padrão duradouro é se outra pessoa qualificada consegue entender o caminho, contestar o método, executar novamente o que puder ser executado e operar o sistema dentro de fronteiras institucionais claras.