Forum Replies Created
- Posts
Olá José,
Esse erro ocorre quando é passado um parâmetro incorreto, geralmente a imagem em um formato que a função não estava esperando. Verifique se você carregou corretamente as fotos e carregou corretamente as variáveis. Cheque se todas os blocos de códigos anteriores a esse foram executados na ordem correta, e se nenhum deles gerou alguma mensagem de erro.
Eu rodei aqui o código do Colab oficial dessa seção do curso (link aqui) e para mim rodou tudo conforme o esperado. Portanto, teste novamente e verifique se foi carregado corretamente as imagens usadas para treinamento. Se o erro persistir, peço que compartilhe seu Colab aqui, já que deve ter outra coisa em seu código interferindo.
Ah sim ele consegue detectar faces com esse limiar, porém o que eu me referi na resposta anterior na verdade era quanto ao momento da gravação da aula, pois no vídeo (minuto 3:02) perceba que após mudar para essa nível de confiança nenhuma das faces exibidas na célula de saída foram detectadas, então por isso quis dizer que passou despercebido.
Olá Murilo,
Para rodar projetos com LLMs, a escolha entre essas placas depende de como você pretende usar a GPU. Na minha opinião, a RTX 3050 com mais VRAM (12GB) pode ser uma opção interessante, já que LLMs (especialmente os maiores) tendem a exigir bastante memória de vídeo para rodar de forma eficiente. No entanto, a RTX 4060 oferece uma arquitetura mais moderna, com melhor desempenho geral, apesar de ter menos VRAM.
Se seus projetos forem rodar modelos menores ou otimizados, a 4060 pode ser uma escolha mais eficiente em termos de performance. No entanto, se você planeja trabalhar com modelos maiores e precisa de mais memória para carregar os dados e o modelo, a 3050 com mais VRAM pode ser a opção mais estável. Para o uso pessoal e IA, ambos os modelos são boas opções, mas se a VRAM for uma prioridade para você, a 3050 seria mais indicada.
Além disso, eu realmente recomendo que você busque comparativos específicos entre as duas GPUs, especialmente em cenários que envolvam as tarefas que você pretende realizar, como o uso de LLMs ou outros projetos de IA. Isso vai te ajudar a visualizar o desempenho prático de cada uma em situações reais, não apenas agora, mas também em futuros projetos que possam exigir mais poder de processamento. Dessa forma, você pode evitar possíveis limitações ou decepções e escolher a placa que melhor atende às suas necessidades a longo prazo, pois podem haver vários pontos que não cogitamos aqui agora e apenas são levantados nesses comparativos.
Mas antes disso, o que você pode fazer é testar modelos menores, você pode encontrar bastante modelos de linguagem bem menores aqui: https://ollama.com/library
na aula foi usado o Phi3 que é considerado um modelo pequeno (SLM) mas mesmo assim há outros bem menores, com menos de 1 bilhão de parâmetros. Acredito que vale a pena fazer o teste antes.
Olá Wendel! Que bom que concluiu o projeto final. Quanto à lentidão que você notou na detecção facial, isso provavelmente está relacionado ao poder de processamento do seu notebook sim, especialmente ao usar a webcam integrada. Você usou para o reconhecimento a solução apresentada no curso onde é usada a biblioteca face_recognition, né? Ela é bastante precisa, mas também pode ser computacionalmente intensiva, principalmente em dispositivos com hardware mais limitado.
Seu processador e a GPU acredito que são muito bons para tarefas do dia a dia, mas quando se trata de reconhecimento facial em tempo real eles podem ter dificuldade para lidar com o processamento das imagens de forma rápida, especialmente sem otimizações. Para dispositivos embarcados, essa questão é ainda mais crítica, pois eles geralmente possuem recursos computacionais ainda mais limitados. Nesse cenário, vale a pena explorar soluções mais leves, como a otimização do código, o uso de bibliotecas mais rápidas como o Mediapipe, ou até usar redes neurais menores e mais otimizadas para dispositivos de baixo desempenho.
Para tentar otimizar com essa configuração e código que já tem, você também pode tentar ajustar alguns parâmetros para melhorar o desempenho, como reduzir o tamanho do vídeo capturado pela webcam, caso isso seja viável. Outra estratégia seria redimensionar as faces detectadas para um tamanho menor antes de processar o reconhecimento, o que pode diminuir a carga de processamento. Além disso, você pode realizar o reconhecimento facial a cada “x” frames, em vez de em todos os frames do vídeo, o que alivia significativamente o custo computacional. Mudanças como essas podem aumentar a eficiência do seu projeto sem comprometer muito a precisão.
Olá Flávio!
Boa observação, nesse caso a diferença de formato impossibilita o cálculo correto da acurácia. O problema parece ocorrer quando a face não é detectada em uma das imagens, o que faz com que um dos valores seja uma string e por isso ele precisa automaticamente salvar nesse formato, que é diferente daquele definido para a variável “previsoes”.
Creio que passou despercebido pelo fato de que com o teste usando confiança=0.3 nenhuma das faces em questão foram detectadas, então coincidentemente nesse caso deveria retornar 0 mesmo.Obrigado pela sua colaboração
Olá Murilo!
Na verdade ainda é possível continuar usando essa função nas versões mais recentes, apesar do aviso.
Mas recomendamos já alterar para esse novo método só por garantia, atualmente está na versão 0.3.x mas segundo os autores será removido na 1.0Quanto à mudança, já atualizamos no Colab, você pode conferir aqui.
O que muda basicamente são apenas alguns detalhes na sintaxe. Considerando o código dos últimos projetos, basta alterar de:
llm = HuggingFaceHub( repo_id=model, model_kwargs={ "temperature": temperature, "return_full_text": False, "max_new_tokens": 512, } )para:
llm = HuggingFaceEndpoint( repo_id=model, temperature=temperature, max_new_tokens=512, return_full_text=False, )
Olá! Que ótimo que conseguiu já identificar e resolver, e obrigado pelo aviso!
E quanto ao token do Hugging Face Hub, é isso mesmo, basta usar o mesmo token usado nas primeiras aulas práticas (para mais detalhes, veja a aula “Outros serviços para modelos”, da seção “LLM com LangChain”).
Mas bom saber que após a alteração funcionou corretamente, caso apareça qualquer outro erro basta postar aqui e iremos te ajudar
Olá Douglas,
Pessoalmente não conheço para essa classe específica, mas você vai encontrar imagens prontas em repositórios ou sites que disponibilizam datasets na internet, como Kaggle ou Open Images Dataset (OID), recomendo dar uma olhada em ambos pois lá você vai encontrar datasets prontos não só para sapos mas para muitas outras classes.
No OID eu encontrei aqui já: https://storage.googleapis.com/openimages/web/visualizer/index.html?type=detection&set=train&c=%2Fm%2F09ld4
E no Kaggle, basta procurar por “frog” dentro da página “datasets”. Obs: talvez seja bom durante a pesquisa especificar que se trata de detecção pois desse modo garante que seja um dataset anotado para esse objetivo.
Olá!
Você pode encontrar esse arquivo na pasta do Drive compartilhada na aula “Recursos para download”, no caso esse link aqui.
O script funcoes_desenho.py está dentro da pasta “Atualização YOLOv8”; já o vídeo mencionado se encontra dentro da pasta “videos”.
Olá Brenda! Isso mesmo, nesse contexto o processo de treinamento pode ser chamado de “Fine-tuning”, que é uma técnica onde você pega um modelo pré-treinado (como o YOLOv8) e ajusta ele para a sua tarefa específica, utilizando um conjunto de dados personalizado. Esse ajuste é feito com mais algumas rodadas de treinamento usando os seus dados, em vez de treinar o modelo do zero.
No caso do YOLOv8, o processo mostrado segue esse conceito. Para fazer isso, você só precisa dos seus dados devidamente anotados, um arquivo de configuração .yaml que descreve o dataset, e baixar o modelo pré-treinado do YOLOv8 (como yolov8m.pt, por exemplo). Depois, você carrega o modelo e inicia o treinamento com os seus dados, ajustando o modelo para a sua aplicação específica (mais detalhes são mostrados nas aulas).
Olá Gabrielli!
Que bom que está gostando do curso =)
Quanto à sua dúvida, com o Colab Pro você certamente terá acesso a melhores recursos de GPU e mais tempo de execução (e maior prioridade no uso de hardware), porém na minha opinião vale a pena apenas se você planeja usar para outras coisas além de LLMs. Eu já assinei o plano do Colab, mas se tratando de LLMs eu não recomendaria usar esse ou outros cloud providers, para esse tipo de tarefa eu sugiro dar uma olhada nas APIs pagas especializadas em LLMs, que acabam sendo uma opção muito mais eficiente e econômica. O motivo é que no Colab você está pagando pelo uso computacional em geral, enquanto os serviços focados em LLMs são mais otimizados nesse contexto, o que no final das contas dará um custo benefício melhor, pagando poucos centavos de dólar a cada milhão de tokens gerados (esse é o modo de precificação que esses serviços usam).
Isso é comentado mais a partir da aula “Outros serviços para modelos” (seção: LLM com LangChain), onde explicamos melhor as vantagens desses serviços. Se quiser continuar com os modelos open source, recomendo o Groq (https://groq.com), que é um ótimo serviço nesse contexto – e adianto que a execução é extremamente rápida, conseguindo superar a resposta de modelos proprietários. E já se está disposta a pagar pelo uso, também dê uma olhada nos valores das APIs de modelos proprietários como ChatGPT e Gemini (isso também é abordado nessas aulas, depois sugiro dar uma olhada com atenção, mas qualquer dúvida que surgir é só pergunta aqui).
Ah, outra opção interessante é a API do Hugging Face, que tem uma versão gratuita com limites mas que dependendo do seu uso (ou tamanho do modelo escolhido) pode ser mais que o suficiente. Assim como esses outros serviços acima, com ele você consegue rodar modelos no Colab apenas com a CPU, ou em qualquer máquina local que não tenha um hardware tão bom (e o bom é que o uso da CPU no Colab é ilimitado). O uso dessa API em máquina local é elaborado melhor nos últimos 2 projetos do curso.
Portanto, creio que só compense o Colab Pro ou similar se você prefere manter o processamento 100% “local” (sem usar APIs), o que pode ter vantagens adicionais no quesito privacidade, mas que na grande maioria dos casos não chega a ser necessário. Nesse caso te recomendo também testar o Sagemaker Studio Lab, que está oferecendo 4 horas diárias de GPU gratuita, então no final poderá ter bastante tempo se somar com as horas que o Colab disponibiliza após resetar a quota.
Olá!
O Colab atualizado está aqui https://colab.research.google.com/drive/1vNlUU9KVZf7dsnLUSFfioMh2A1Mf0DyjOu seja, essa primeira linha de código que você indicou é no modo antigo de instalação e que funciona apenas com o tensorflow 1.x, com o novo método de instalação para o tensorflow 2.x não é necessário esse comando citado (porém, são necessários outros. As mudanças estão descritas no início do Colab).
Eu fui tentar rodar com o release recente do tensorflow (2.17.0) atribuído automaticamente no Colab porém realmente apareceu uma mensagem de erro, mas foi na função network.detect() – então fizemos uma atualização aqui no Colab para automaticamente usar a versão 2.15.0 até que seja resolvido a incompatibilidade.
Para isso basta usar o comando !pip install tensorflow==2.15.0 abaixo da seção “Importação das bibliotecas”
Na dúvida basta rodar na ordem os comandos desse Colab que citei acima, eu acabei de testar aqui e funcionou conforme esperado. Mas se continuar a ocorrer algum erro nos avise
Olá Cesar!
Para resolver o primeiro erro, use o seguinte código no início de seu script:
import os os.environ['TF_ENABLE_ONEDNN_OPTS'] = '0'
E quanto ao segundo erro, ele ocorre pois não foi localizada a biblioteca em seu ambiente. Para resolver, execute o comando abaixo no terminal:
pip install sentence-transformers
E depois volte a executar o código.
