Aléssio M. Jr logo Aléssio M. Jr logo alessiojr.com
  • Sobre
  • Blog
  • Projetos
  • Palestras
  • Publicações
  • Disciplinas
    • Gestão e Processo de Software
    • Inteligência Artificial II
    • Estágio Supervisionado

    • AED2
    • CLP
    • Compiladores
    • Técnicas de Programação

    • Visão Geral
  • Inovação
    • Visão Geral
    • Influenzer
    • WOK
    • Ecossistema Vale do Aço
    • Palestras
    • Ideias & TCC
    • Português
    • English

Nesta página

  • Evidencias e execucao
  • Implementacao
  • Pontos positivos
  • Lacunas e evolucao
  • Pontuacao
  • Nota recomendada
  • Nota individual recomendada
    • Evidencias e ressalvas individuais
  • Editar essa página
  • Criar uma issue

Laudo Técnico de Avaliação — TP1

equipe-gabrielduarte

Autor

Disciplina de Inteligencia Artificial II

Data de Publicação

22/09/2026

Data de Modificação

22/09/2026

Tipo: Avaliacao tecnica coletiva

Status: Recomendacao tecnica

Nota tecnica: 8.4/10.0

Sintese: Entrega integrada com artefatos, testes e documentacao; a robustez operacional do healthcheck e o pinning de dependencias permanecem como riscos identificados.

Evidencias e execucao

  • README, imagens de matriz por classe, dataset, artefatos de API, codigo, dependencias, testes, Docker e historico Git inspecionados.
  • Os tres artefatos de inferencia existem em arq_api/: modelo Keras, vetor TF-IDF e MLB.
  • PYTHONDONTWRITEBYTECODE=1 python -m pytest -q -p no:cacheprovider: falhou na coleta por ModuleNotFoundError: fastapi. O ambiente nao tem dependencias e nenhuma foi instalada.
  • Docker/API nao executados apos o build de referencia exceder dois minutos na instalacao de TensorFlow; nao havia imagem local reutilizavel. Isso e bloqueio de ambiente, nao reprovacao automatica do projeto.
  • O historico comprova a sequencia pipeline -> rede -> mock -> modelo Keras real -> Docker/testes/CI e uma iteracao posterior de parametros.

Implementacao

  • Codigo usa MultiLabelBinarizer, TF-IDF e Keras com 25 sigmoid/BCE. README fornece split 80/10/10, arquitetura, artefatos e F1 por classe.
  • Baseline LogReg OvR: F1-macro 0.25; rede: 0.4678, F1-micro 0.5289. Curva de loss e 25 matrizes por classe estao versionadas.
  • API carrega os tres artefatos no lifespan, valida texto vazio e retorna os campos requeridos. A suite inclui os seis testes obrigatorios e mais testes de MLP/neuronio.
  • GET /health retorna {"status":"ok"} mesmo se o carregamento do modelo falhar, pois o lifespan captura a excecao e deixa o classificador como None. Assim o healthcheck pode declarar saudavel uma API que devolve 503 em /predict.

Pontos positivos

  • Entrega ponta a ponta bem documentada, com artefatos e cobertura de erros por skill visivel.
  • A analise identifica corretamente o custo precision/recall do tau 0.12 e o problema das classes abstratas.
  • Historico mostra trabalho distribuido entre as duas duplas e substituicao verificavel do mock.

Lacunas e evolucao

  • Fazer /health refletir disponibilidade de artefatos e retornar 503/degradado se o modelo nao carregou.
  • Fixar as dependencias de runtime: requirements.txt usa faixas abertas, fragilizando a desserializacao de Keras/sklearn.
  • A justificativa experimental e mais curta que as melhores entregas: ha um unico tau global final; faltam comparacoes de alternativas ou calibracao por classe para sustentar melhor a escolha.

Pontuacao

Criterio Maximo Pontos Justificativa
Dados e formulacao multi-label 1.5 1.4 Pipeline e formulacao corretos, com evidencia principalmente documental.
Baseline, rede e resultados 2.5 2.2 Comparacao e artefatos visuais completos; metricas reproduziveis nao foram executadas no ambiente.
Evolucao e justificativa experimental 2.0 1.5 Tau e semantic gap discutidos, mas com poucas alternativas experimentais documentadas.
API e contrato 1.5 1.2 Contrato correto; health mascara falha de carregamento.
Reproducibilidade e qualidade 1.5 1.1 Docker, CI e testes existem, mas dependencias abertas e execucao bloqueada.
Documentacao e colaboracao 1.0 1.0 README muito completo, fontes, autoria e historico adequados.
Total 10.0 8.4

Nota recomendada

8.4/10.0 Boa entrega integrada com desempenho acima do piso e documentacao forte. Perde pontos sobretudo por robustez operacional do healthcheck e menor profundidade na evolucao experimental.

Nota individual recomendada

A componente de produto coletivo e 4.2/5.0, metade da nota tecnica atual (8.4/10.0). As estatisticas de linhas estao fortemente infladas por arquivos de dados/artefatos e nao foram usadas para pontuar os integrantes.

Integrante Papel declarado e evidencia observada Produto (5,0) Papel (3,0) Rastreab. (1,5) Colab./qual. (0,5) Final / 10
Erick Reis Miranda Dados/NLP: limpeza, TF-IDF e geracao de MLB/vectorizer em commit dedicado. 4.2 3.0 1.2 0.3 8.7
Matheus Benevenuto Ferreira ML: baseline, rede Keras, treino, metricas e ajuste de parametros em MRs da Dupla 1. 4.2 3.0 1.5 0.4 9.1
Lizandra Abelha Coelho Barbosa API: contratos Pydantic, endpoints e substituicao do mock pelo modelo Keras real. 4.2 3.0 1.5 0.4 9.1
Gabriel Duarte Campos Amorim DevOps/QA: Docker, testes, CI, alinhamento de limiar e relatorio final. 4.2 3.0 1.5 0.5 9.2

Evidencias e ressalvas individuais

  • Erick tem uma contribuicao de dados tecnicamente delimitada, mas com menor trilha de integracao (um commit e sem MR proprio), o que limita rastreabilidade e colaboracao documentada.
  • A atribuicao de Matheus por volume de linhas e artificialmente ampliada por artefatos; a nota decorre de scripts/modelo, MRs e resultados, nao daquela estatistica.
  • Nao ha Issues nem revisoes formais registradas. A cadeia de MRs e merges confirma a integracao entre as duas duplas.

O healthcheck enganoso e as dependencias abertas afetam o produto comum, nao anulam as entregas individuais; a arguicao deve validar como cada papel trataria esses riscos.

De volta ao topo

Powered by Quarto.

© Aléssio M. Jr.

  • Editar essa página
  • Criar uma issue

License: CC BY NC SA 4.0.