← voltar aos projetos

Inteligência artificial · RAG

Assistente de Identificação de Aves

Aplicação que usa Retrieval-Augmented Generation com LLMs para sugerir espécies de aves a partir de descrições textuais em linguagem natural.

Status
Em produção
Stack
Python · RAG · LLM · Streamlit
Aplicação
Dataset builder

Contexto

Nasceu de um projeto pessoal de catalogação de aves em Uberlândia. Em vez de exigir que o usuário soubesse o nome científico ou popular da espécie, o assistente permite descrever características — cor, tamanho, comportamento, habitat — e recebe sugestões de espécies compatíveis.

Fluxo RAG (versão em produção)

A descrição do usuário é transformada em embedding, comparada contra uma base vetorial de características de espécies, e o contexto recuperado é usado para que o LLM gere uma resposta fundamentada — reduzindo alucinação em relação a perguntar direto ao modelo.

Descrição do usuário Embedding vetorização Busca semântica base de espécies top-k matches LLM + contexto geração Sugestão

O que já funciona

  • Recuperação semântica com embeddings sobre a base de características morfológicas e comportamentais
  • Pipeline RAG completo para sugestão de espécies a partir de texto livre
  • Interface interativa em Streamlit, sem necessidade de conhecimento técnico do usuário
🔧 Uma nova versão está em desenvolvimento, com escopo bem maior: cobertura nacional, memória de conversa e validação por avistamentos reais. Abaixo está o desenho técnico dessa evolução — hoje só o pipeline de dados está parcialmente implementado, a API RAG ainda não foi iniciada.

Próxima versão: expansão nacional + RAG com clarificação

A evolução em desenvolvimento parte de dois repositórios com responsabilidades separadas: o dataset builder, que já roda e funde dados do AVONET, WikiAves e eBird em uma base canônica no MongoDB Atlas; e a API RAG, ainda a construir, que vai consumir essa base para identificação por descrição e cruzamento com avistamentos reais.

Fontes externas AVONET · WikiAves eBird Pipeline ETL normalização e fusão canônica MongoDB Atlas canonical_species embeddings (Vector Search) ebird_recentes (cache) API REST FastAPI · RAG clarificação · eBird Cliente app/frontend

O pipeline documenta 6 etapas de enriquecimento semântico via LLM (extração → normalização → classificação → inferência → síntese → validação), mas hoje só as três primeiras rodam de fato. A fusão que gera a canonical_species ainda não consome os campos já normalizados nem os dados de ocorrência por município — está entre os próximos passos do roadmap.

Fluxo de identificação com clarificação híbrida

A avaliação de suficiência da descrição não é feita isoladamente por prompt: a busca vetorial roda sempre primeiro (mais barata e rápida), e o LLM avalia se a descrição é suficiente olhando tanto o texto do usuário quanto os candidatos reais retornados. Se não for, gera até 3 perguntas direcionadas às espécies que de fato competem entre si — em vez de perguntas genéricas.

Descrição do usuário Busca vetorial top-N candidatos (roda sempre 1º) LLM avalia suficiência da descrição + candidatos insuficiente Até 3 perguntas direcionadas aos candidatos nova rodada suficiente Candidatos ranqueados Validação eBird avistamentos locais (7 dias)

A etapa final cruza os candidatos do RAG com os avistamentos reais registrados no eBird para a localidade do usuário nos últimos 7 dias: espécies vistas na região sobem no ranking, espécies raras na área caem — reduzindo falsos positivos. Essa integração está planejada primeiro via chamada REST direta e, depois, migrada para MCP como exercício de aprendizado, isolando sempre a chamada que processa texto do usuário da chamada com acesso à tool externa.