Respostas no Fórum
- AutorPosts
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.
22 de outubro de 2024 às 20:37 em resposta a: Erro na aula: Avaliação do classificador com Dlib #46459Olá 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.
8 de outubro de 2024 às 12:57 em resposta a: Erro no módulo de segmentação de imagens do curso de visão computacional. #46197Olá!
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
4 de outubro de 2024 às 13:37 em resposta a: Erro na linha cv2.imshow(imagem) apos importar …from google.colab.patches impo #46182Disponha! =)
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.
- Esta resposta foi modificada 9 meses, 1 semana atrás por
Gabriel Alves.
2 de outubro de 2024 às 09:29 em resposta a: Base de documentos – exportação e atualização incremental. #46173Olá!
Tanto o Faiss quanto o ChromaDB são opções viáveis para rodar localmente sem depender de APIs, mas eles têm características diferentes, então a escolha vai depender das suas necessidades específicas. Esse artigo explica bem as diferenças de cada e onde um pode ser melhor que outro, mas basicamente: Faiss é altamente escalável e principalmente na busca vetorial, pode ser preferível se seu principal objetivo é velocidade e eficiência em buscas especialmente em grandes conjuntos de dados; já Chroma é mais usado quando preza por flexibilidade maior, geralmente mais fácil de gerenciar, trabalhando com metadados para uma busca otimizada.
Caso tenha preocupações com eficiência, o Faiss tende a ser melhor nesse quesito, além de ser mais otimizada para se trabalhar com GPU (então se tiver uma à disposição será mais interessante). Ainda quanto à performance, recomendo dar uma olhada nesse comparativo.
Para adição incremental de documentos, você pode usar o método add_documents (exemplo).
E para salvar localmente, você pode usar o método save_local(), que também foi usado durante o projeto 3. E depois, usar a função load_local, assim por exemplo:
vector_store.save_local(“faiss_index”)
n_vector_store = FAISS.load_local(“faiss_index”, embeddings, allow_dangerous_deserialization=True)
Referente à ideia de ter múltiplas bases de mapeamento para diferentes tipos de conteúdo (legislação e monografias, por exemplo) realmente é bem interessante! Um agente LLM poderia ser configurado para direcionar as buscas para a base apropriada dependendo do contexto da consulta. Então usar um agente para conectar um LLM às diferentes bases facilita a modularidade e garante que você consiga expandir as funcionalidades, inclusive buscando em bases como de legislação interna e externa.- Esta resposta foi modificada 9 meses, 1 semana atrás por
Gabriel Alves.
Olá Heitor!
O valor pode variar bastante, pois vai depender de alguns fatores. Primeiro, é importante considerar o nível de complexidade do projeto: se ele envolve apenas a detecção de aeronaves em um ambiente simples ou se requer detecção em condições mais desafiadoras, como diferentes tipos de iluminação, ângulos de câmera, ou integração com outros sistemas. Como acredito ser o caso, você deve considerar isso a mais na hora de cobrar, pois certamente você terá que dispor de um tempo para fazer uma otimização e melhorar os casos de falsos positivos e falsos negativos por exemplo (talvez cobrar um valor mensal referente à manutenção).
Além disso, o escopo do projeto e as funcionalidades adicionais que você vai oferecer podem influenciar o preço. Por exemplo, se o sistema precisa ser escalável para monitoramento em larga escala, se é necessário treinar o modelo com um dataset específico, ou se você vai entregar uma solução completa que inclua integração com um dashboard ou uma interface de usuário. Ou seja, se você vai fazer o desenvolvimento ou a manutenção de alguma funcionalidade a mais além da IA em si.
Outro ponto importante é o valor que isso agrega ao cliente. Se o projeto é para uma empresa do setor aeronáutico ou de monitoramento aéreo, onde a precisão e a segurança são essenciais, o valor pode ser significativamente maior. Avalie também o tempo de desenvolvimento, os recursos necessários e a manutenção contínua que pode ser exigida.
Quanto ao quanto cobrar, não consigo te dar uma resposta sobre quanto valeria esse projeto pois como falei dependerá de muitas outras questões, mas projetos como este podem valer dezenas de milhares de reais ou até na casa das centenas de milhares, dependendo da escala e dos requisitos. Mas se for algo mais simples, pode ser cobrado bem menos, um valor mais justo. Uma abordagem segura que eu recomendo para ajudar a precificar de modo justo é estimar as horas de trabalho necessárias e definir um valor por hora, levando em conta o mercado e a sua expertise. Mas existem também outras abordagens, por isso recomendo consultar artigos sobre como cobrar projetos de IA ou de computação no geral, já que isso pode variar bastante conforme os fatores mencionados (por exemplo aqui, que discute as formas de cobrar por projetos).
Olá Douglas!
Modelos deep learning para detecção de pose como esse usado na aula podem ser bastante pesados para rodar em tempo real, principalmente em dispositivos com recursos computacionais limitados, mas também depende muito de outros fatores como o tamanho do vídeo por exemplo.
Para uma aplicação comercial em tempo real, o uso de modelos como esse dependerá muito da estrutura computacional empregada. A recomendação seria utilizar uma GPU de alta performance, que pode processar as inferências de forma paralela, o que reduziria significativamente o tempo de resposta. GPUs como as da série NVIDIA RTX ou Tesla são amplamente usadas em cenários de inferência de visão computacional. Em dispositivos móveis ou mais simples, é possível explorar versões otimizadas de modelos de detecção de poses, como as implementações leves do TensorFlow Lite ou MediaPipe, que são mais apropriadas para aplicações em tempo real e têm menor demanda por recursos computacionais.
Portanto, é viável rodar detecção de movimentos em tempo real em aplicações comerciais, mas para isso é essencial garantir uma infraestrutura otimizada, preferencialmente com aceleração por hardware (GPU), e escolher um modelo pré-treinado que esteja balanceado entre precisão e velocidade de execução.
Hoje há modelos mais otimizados para essa tarefa, como por exemplo o estimador de poses do YOLO https://docs.ultralytics.com/tasks/pose/
a sua arquitetura e o modelo são baseados em abordagens mais modernas, portanto conseguem rodar tranquilamente em tempo real.
- Esta resposta foi modificada 9 meses, 1 semana atrás por
- AutorPosts