Iniciação Científica pós-disciplina: do TP ao artigo

Proposta de pesquisa aplicada em avaliação e engenharia de sistemas de IA

Chamada aberta a estudantes da IA II 2026-2 para planejar, executar e relatar uma pesquisa empírica baseada nos artefatos autorizados da disciplina.
Data de Publicação

13/11/2026

Data de Modificação

13/11/2026

Convite

Esta é uma proposta de continuidade voluntária após a disciplina de Inteligência Artificial II. Toda pessoa que participou da oferta 2026-2 pode manifestar interesse, independentemente da equipe em que trabalhou ou da nota obtida. Participar da disciplina não implica obrigação de continuar, seleção automática para o projeto, acesso irrestrito aos repositórios de colegas ou autoria automática de um artigo.

A proposta parte de artefatos produzidos nos TPs — classificadores, índices de retrieval, contratos, avaliações, logs, contêineres e respostas RAG — para formular uma pergunta de pesquisa e respondê-la com método explícito. O objetivo não é declarar que uma solução é a melhor, mas documentar em que condições um conjunto de pipelines funcionou, falhou, se absteve ou pôde ser reproduzido.

NotaO que esta trilha não é
  • Não é uma extensão obrigatória dos TPs nem altera notas já atribuídas.
  • Não é uma promessa de publicação, bolsa, infraestrutura ou autoria.
  • Não é uma competição entre equipes nem um ranking de estudantes.
  • Não autoriza reutilizar código, dados, logs ou resultados de outra equipe sem permissão documentada.

Ponto de partida disponível

A disciplina desenvolveu um percurso cumulativo:

Artefato Possível uso em pesquisa Cuidados necessários
TP1: classificação de skills baseline supervisionado, métricas, erros e contrato de predição separar treino, validação e teste; registrar versão de dados e modelo
TP2: retrieval e recomendação híbrida evidências recuperadas, ranking, Golden Set, Recall@K e MRR preservar corpus, chunks, embedding, índice e splits
TP3: assistente RAG fundamentado citações, abstenção, falhas de contrato e logs anonimizar dados, preservar fontes e distinguir mock de execução real

Cada equipe decide se seus artefatos podem participar. Para um estudo com mais de uma equipe, o professor deve obter confirmação de acesso e definir quais versões, dados e resultados podem ser compartilhados. Serviços indisponíveis, segredos, dados pessoais e chaves de API não devem ser coletados nem versionados.

Pergunta científica antes da ferramenta

O primeiro produto da IC é um protocolo curto, não um dashboard. O grupo deve escolher uma pergunta principal e, se necessário, uma ou duas perguntas secundárias. Perguntas possíveis:

  1. Grounding e citações: em respostas RAG, com que frequência uma afirmação relevante é sustentada pelo trecho citado?
  2. Abstenção: uma política de abstenção reduz respostas sem suporte? Qual é o custo em respostas úteis recusadas?
  3. Retrieval e recomendação: como diferem classificador supervisionado, retrieval e combinação híbrida em um Golden Set congelado?
  4. Reprodução de artefatos: quais condições permitem que uma pessoa diferente execute uma versão congelada do pipeline e obtenha resultados comparáveis?
  5. Falhas de integração: que tipos de falha aparecem em contratos, índices, fontes, timeouts ou configuração de serviços?

Uma pergunta deve declarar população, unidade de análise, métrica, comparação e limite. Por exemplo:

Em pipelines RAG participantes, qual proporção das respostas de um Golden Set congelado apresenta pelo menos uma citação que sustenta a afirmação central, segundo anotação humana cega?

Ela é mais pesquisável que “qual RAG é melhor?”, pois define evidência, amostra e critério de julgamento.

Delimitação recomendada para a primeira IC

Uma IC de um semestre não deve tentar auditar todas as dimensões de todos os projetos ao mesmo tempo. Recomenda-se escolher um recorte:

Escopo Unidade de análise Evidência mínima
Estudo de caso de uma equipe versões do TP2 e TP3 da própria equipe 12 ou mais casos, fontes, logs e segunda execução
Estudo comparativo autorizado pipelines de 2 a 5 equipes que consentirem protocolo único, versões congeladas e dados anonimizados
Estudo de artefatos repositórios/contêineres autorizados checklist de build, contrato, dependências e reprodução

O conjunto de dez equipes pode ser uma oportunidade de amostragem, mas não é requisito. Dez implementações da mesma disciplina constituem uma amostra de conveniência: resultados descrevem aquele contexto e não devem ser generalizados automaticamente para todos os sistemas RAG ou todas as turmas.

Método mínimo

1. Protocolo e congelamento

Antes de executar medições, registrar em repositório:

  • pergunta(s) de pesquisa e hipótese, quando aplicável;
  • artefatos autorizados, licenças e restrições de acesso;
  • tag ou commit de cada projeto, hash de corpus/índice quando disponível e ambiente;
  • critérios de inclusão/exclusão de casos;
  • métricas, tratamento de falhas e análise planejada;
  • riscos de privacidade, vieses e limitações conhecidas.

O congelamento evita substituir código ou casos depois de conhecer os resultados. Correções posteriores são permitidas, desde que gerem nova versão e sejam relatadas.

2. Conjunto de avaliação

Preparar um Golden Set com casos dentro do domínio, ambíguos, sem evidência suficiente e, quando apropriado, falhas controladas. Para cada caso, registrar:

id, consulta, fonte_esperada, comportamento_esperado,
resultado_observado, versão_do_pipeline, data, observações

Referências devem ser definidas antes de comparar pipelines. Perguntas usadas para escolher parâmetros pertencem ao conjunto de desenvolvimento; perguntas usadas no resultado final permanecem hold-out.

3. Execução e anotação

  • Executar o mesmo conjunto, configuração e limite de tempo para os pipelines comparados.
  • Salvar requisição, resposta, citações, IDs de fonte, status de abstenção, latência e erro de contrato.
  • Pseudonimizar equipes e respostas quando houver anotação comparativa.
  • Usar pelo menos duas pessoas para uma amostra anotada; medir concordância e registrar divergências.
  • Ferramentas LLM-as-a-judge, Ragas ou TruLens podem apoiar inspeção, mas não substituem a validação humana do protocolo.

4. Análise

Reportar contagens, proporções, intervalos de confiança quando a amostra permitir, exemplos representativos e contraexemplos. Para poucos casos, uma tabela detalhada e discussão qualitativa são mais honestas que testes estatísticos frágeis. Não ocultar resultados negativos, pipelines indisponíveis ou casos excluídos.

5. Reprodução

Uma pessoa que não implementou o pipeline deve tentar executar o protocolo a partir de documentação e versão congelada. Registrar o que funcionou, o que falhou e quais dependências faltaram. Reprodução parcial é um resultado válido quando suas condições são explicitadas.

Entregáveis

Entregável Conteúdo esperado
protocol.md pergunta, escopo, artefatos autorizados, métricas, riscos e análise planejada
data/README.md origem, licença, acesso, anonimização e hashes dos dados permitidos
cases/ Golden Set, referência, divisão desenvolvimento/hold-out e versão
harness/ scripts de execução, configuração e mocks explicitamente identificados
results/ resultados brutos, tabela limpa, logs sem segredos e decisões de exclusão
reproduction.md ambiente, comandos, segunda execução e limitações
article/ manuscrito em LaTeX, figuras, tabelas, referências e declaração de contribuições

Organização e autoria

Uma equipe de IC pode ter de duas a cinco pessoas. Papéis orientam responsabilidades, mas não substituem colaboração e revisão cruzada.

Papel Responsabilidade principal
Protocolo e dados pergunta, casos, licenças, consentimento, anonimização e hashes
Harness e reprodução automação, ambientes, contêineres, logs e segunda execução
Anotação e análise guia de anotação, revisão cega, métricas, gráficos e limites
Escrita e integração estrutura do artigo, referências, figuras, consistência metodológica e submissão

A ordem de autoria será discutida antes da submissão e revisada ao final, com base em contribuições reais usando uma taxonomia como CRediT: concepção, curadoria de dados, software, investigação, análise formal, visualização, redação e revisão. Coautoria requer contribuição substantiva e aprovação da versão submetida. Participação na disciplina, presença em reunião ou fornecimento de artefato sem contribuição posterior podem ser reconhecidos em agradecimentos, conforme consentimento, mas não definem autoria por si só.

Cronograma sugerido — dezembro de 2026 a setembro de 2027

Datas de chamadas variam anualmente. O cronograma abaixo organiza a pesquisa; a escolha do evento ocorre somente após consultar a chamada oficial, formato, escopo, idioma, custos e regras de autoria.

Período Marco Resultado verificável
30/11–15/12/2026 manifestação de interesse e conversa inicial grupo provisório, disponibilidade e tema preliminar
16/12/2026–15/01/2027 protocolo e permissões pergunta delimitada, artefatos autorizados e riscos registrados
16/01–15/02/2027 Golden Set e piloto casos congelados, guia de anotação e piloto documentado
16/02–31/03/2027 execução e reprodução resultados brutos, logs e segunda execução iniciada
abril de 2027 análise e ameaças à validade tabelas, figuras, discordâncias e limitações
maio–junho de 2027 primeira versão do artigo manuscrito completo e revisão interna
julho–setembro de 2027 escolha e preparação de submissão adequação ao CFP selecionado, revisão final e decisão de submissão

Se o protocolo, dados ou análise não estiverem maduros, o resultado pode ser um relatório técnico, pôster local ou projeto de IC continuado. Adiar uma submissão é preferível a submeter evidência insuficiente.

Possíveis fóruns de divulgação

O fórum depende do resultado e do foco do artigo. Exemplos a acompanhar por chamadas oficiais:

Foco predominante Fóruns que podem ser compatíveis Observação
Computação na educação e uso pedagógico de feedback/RAG CBIE/SBIE, WIE/CSBC, LAK, EDM, AIED exige contribuição educacional e avaliação coerente com esse foco
Engenharia e ensino de computação WEI/CSBC, ITiCSE, SIGCSE Technical Symposium exige contribuição para ensino ou prática de computação, não apenas uso de LLM
Engenharia de software para IA trilhas e workshops de SE4AI, conferências de engenharia de software ou relatórios técnicos institucionais verificar se o estudo possui amostra, método e escopo compatíveis
Pesquisa local/iniciação científica seminários institucionais, jornadas de IC e pôsteres alternativa adequada para resultados preliminares

Nenhum desses fóruns deve ser anunciado como destino garantido. A equipe selecionará no máximo um alvo principal depois de avaliar escopo, maturidade, regras e prazo oficial.

Como manifestar interesse

  1. Enviar mensagem ao professor pelo canal institucional até 15/12/2026.
  2. Informar nome, equipe da disciplina, disponibilidade aproximada e uma pergunta de pesquisa que gostaria de explorar.
  3. Indicar se pretende trabalhar com artefatos da própria equipe, com estudo comparativo autorizado ou com reprodução de artefatos.
  4. Participar de uma conversa curta para delimitar escopo, disponibilidade de mentoria e condições de acesso aos dados.

O convite é aberto a todas as pessoas que participaram da disciplina. A composição final do grupo dependerá de compatibilidade de tema, capacidade de mentoria, permissões de acesso e compromisso com o protocolo.

DicaPrimeiro passo recomendado

Escolha uma pergunta pequena e verificável. Um estudo bem documentado sobre doze casos, uma versão congelada e uma limitação claramente reportada é mais útil que uma comparação ampla sem protocolo, autorização ou evidência reproduzível.

De volta ao topo