DEV Community: Amanda

Explorando o Universo da Inteligência Artificial Generativa

Amanda — Wed, 10 Jan 2024 09:17:20 +0000

Você já se perguntou como a Inteligência Artificial (IA) pode não apenas processar informações, mas também criar conteúdo novo e original? Bem-vindo ao fascinante mundo da GenAI, onde a geração de texto, imagem, áudio e dados sintéticos se torna possível.

O que é GenAI?

GenAI ou IA Generativa, é um subconjunto do universo da Inteligência Artificial. Diferentemente das abordagens convencionais, a GenAI não se limita a processar dados existentes, e é capaz de produzir uma ampla variedade de conteúdos, tornando-se uma verdadeira fonte de inovação.

Ela opera como um subconjunto específico de Deep Learning (ou Aprendizado Profundo), o que significa que ela pode não apenas compreender e reproduzir padrões, mas também criar novas instâncias de dados.

O que é Deep Learning?

Deep Learning, ou Aprendizado Profundo, é uma abordagem avançada de Inteligência Artificial baseada em redes neurais artificiais. Ao contrário de métodos tradicionais de machine learning, o Deep Learning permite que modelos aprendam automaticamente a representação dos dados através de múltiplas camadas. Essa capacidade de extrair características complexas torna o Deep Learning extremamente eficaz em tarefas como reconhecimento de padrões e geração de conteúdo.

Deep Learning: Discriminativo vs Generativo

O Deep Learning abrange diversas arquiteturas e paradigmas de Inteligência Artificial, dentre eles os modelos discriminativos e generativos. Os modelos discriminativos, são treinados para realizar tarefas específicas e, muitas vezes, são utilizados para predizer rótulos para novos pontos de dados. Eles aprendem a distinguir entre diferentes categorias e fornecem resultados precisos para problemas de classificação.

Por outro lado, ao invés de apenas classificar os dados existentes, os modelos generativos têm a capacidade de gerar novas instâncias de dados. Eles operam com base em uma distribuição de probabilidade aprendida dos dados já existentes, permitindo a criação de conteúdo completamente original.

O Futuro da GenAI

À medida que a IA Generativa continua a evoluir, podemos esperar grandes avanços em diversas áreas, desde criação de conteúdo a até solução de problemas complexos. Sua capacidade de gerar novas perspectivas e criar algo inédito, promete moldar de maneira determinante o futuro da inteligência artificial.

Você já percebeu o impacto da GenAI em sua vida? Como ela tem influenciado sua experiência digital ou profissional? Compartilhe suas impressões! 🌐✨ #GenAI #ImpactoDaIA #DeepLearning #Inovacao

Introdução ao Git e Github — Parte III

Amanda — Wed, 06 Dec 2023 10:07:38 +0000

Chegou a hora de começar a trabalhar com branches. Em um time que está desenvolvendo um produto, seja um software ou um modelo de machine learning, é importante trabalhar com branches ao invés de realizar as alterações no branch principal.

Neste tutorial, vamos clonar um repositório remoto, realizar alterações utilizando um branch novo, subir as alterações no repositório remoto e criar um pull request para solicitar que as alterações sejam incorporadas ao branch principal.

Mas antes de colocar a mão na massa, vamos entender três conceitos abordados aqui: branches, pull requests e merge.

Branches (ramos)

Um branch é uma cópia isolada do código de um projeto, que permite que você trabalhe em novas funcionalidades, correções de bugs ou outras alterações sem afetar diretamente o código principal (branch master ou main). Utilizar branches é muito útil quando várias pessoas estão trabalhando no mesmo projeto simutaneamente, pois cada membro da equipe pode ter o seu próprio branch para realizar as suas alterações e ao final ele pode ser mesclado de volta ao branch principal. Conforme explicado no primeiro post desta série, em um projeto pode existir ainda o branch “dev”,que é derivado do branch “main”, e é usado como o branch principal de desenvolvimento, mas isso varia de acordo com o time.

Pull Request (solicitação de pull/merge)

Um pull request (também chamado de merge request em algumas plataformas), é uma solicitação feita ao final do desenvolvimento para que o seu branch possa ser incorporado de volta ao branch principal. É uma prática comum eleger reviwers (revisores) ao criar o pull request. Os reviewers são pessoas que vão revisar o seu código, podendo adicionar comentários e solicitar alterações, antes de aprovar o pull request.

Merge (mesclagem)

Quando um pull request é aprovado, a mesclagem (merge) ocorre, combinando as alterações de um ramo (branch) em outro. Às vezes podem ocorrer conflitos ao realizar essa operação (o famoso conflito de merge), quando as mesmas partes de um arquivos foram modificadas em paralelo em ambos os branches. Por isso, é importante revisar o código antes de aprovar uma solicitação de pull (pull request), e ter muito cuidado ao realizar uma mesclagem de forma manual.

Mão na massa

Hora de colocar a mão na massa, lembrando que este é um tutorial básico para que você tenha um contato com a utilização de branches.

1º passo: Abra o Git Bash em um repositório que foi clonado na sua máquina. De preferência um repositório seu, apenas para fins didáticos. Você pode utilizar o repositório criado no primeiro artigo desta série, o importante é que ele já esteja ligado ao GitHub.
2º passo: A partir do seu repositório local utilize o comando “git branch” para verificar em qual branch você está. Neste exemplo, estou no branch main:

git branch

3º passo: Faça o checkout para um novo branch usando o comando “git checkout -b ”. O parâmetro -b indica que quero criar esse branch caso ele não exista.

git checkout -b dev

4º passo: Execute novamente o comando “git branch” para validar em qual branch você está. Note que aparece um “*” antes do branch atual:

5º passo: Faça as modificações necessárias no projeto. Neste exemplo vou criar um novo arquivo “meuarquivo.txt” e escrever no arquivo a frase “Olá, mundo!”:

6º passo: Após realizar as alterações desejadas, execute o comando “git status” para verificar o que foi alterado.

git status

7º passo: Adicione os arquivos modificados desejados à área de stage:

git add . # para adicionar todas as modificações
git add <nome-arquivo> # para adicionar somente as modificações realizadas em um arquivo específico

8º passo: Você pode verificar novamente o que foi enviado à área de stage:

9º passo: Crie o commit e adicione uma mensagem para identificar o commit:

10º passo: Envie as alterações ao repositório remoto utilizando “git push origin ”:

git push origin dev

Ao acessar o repositório pelo navegador, é possível ver uma mensagem dizendo que o branch dev enviou alterações, e a opção para comparar as modificações e criar o pull request.

Os passos a seguir variam bastante, de acordo com as configurações do repositório no próprio GitHub ou da ferramenta utilizada para hospedar o código remotamente, mas os conceitos básicos por trás são os mesmos.

O repositório deste tutorial é um repositório meu, da minha conta pessoal do GitHub. Em uma empresa, normalmente você precisa adicionar os reviwers ao fazer o pull request, que são pessoas que vão revisar o seu código e aprovar o merge ao branch principal de desenvolvimento.

Criando um Pull Request

Clique em “Compare & pull request”:

É possível adicionar comentários sobre o commit e alterar o nome do pull request. Para criar o pull request clique em “Create pull request”.

Aprovando o Pull Request

Caso você tenha permissões para aprovar o pull request e fazer o merge, irá aparecer uma nova tela com as informações do pull request.

Para verificar o que foi alterado, você pode clicar na aba “Files changed”. Nessa aba irá aparecer a comparação do código que você tinha antes, com o código atual para que você e quem vai revisar o código para aprovar o pull request possam visualizar o impacto das alterações no projeto. Se houverem conflitos, eles também irão aparecer. Nesse caso você precisará resolvê-los localmente e atualizar o código do seu branch novamente (mas isso é assunto para outra publicação).

Para aprovar o pull request, na aba “Conversation” clique na opção “Merge pull request”:

E clique em “Confirm merge”

Após a confirmação, você pode apagar o branch que realizou o pull request.

Ao atualizar a página do repositório, você verá que as mudanças serão aplicadas.

Espero que este tutorial tenha te ajudado!

Se ficou alguma dúvida, sinta-se à vontade para me contatar.

Introdução ao Git e GitHub — Parte II

Amanda — Wed, 06 Dec 2023 09:54:05 +0000

No primeiro post desta série, você aprendeu a enviar os arquivos do seu repositório local para um repositório remoto. Mas e se você quiser modificar um arquivo que está em um repositório remoto que você ainda não possui em sua máquina?

Git Clone

O git permite que façamos um clone de um repositório remoto. Ao fazer um clone, estamos criando uma cópia local que nos permite trabalhar no código sem afetar diretamente o repositório original, até que as alterações sejam enviadas ao repositório por meio do comando git push.

Quando queremos criar uma cópia local de um repositório que é nosso, podemos utilizar simplesmente o comando git clone . Mas às vezes queremos utilizar um repositório disponibilizado publicamente no GitHub, e não podemos deixar que as nossas alterações afetem o código original. Nesse caso, podemos também fazer um “fork”.

Usando Fork

Um “fork” é uma cópia independente de um repositório remoto. Quando você faz um fork de um repositório, você está criando uma cópia separada desse repositório em sua própria conta no GitHub.

Ele é muito utilizado quando queremos experimentar modificações sem interferir diretamente no repositório original.

Acesse a página do Github onde está o repositório que você deseja clonar e clique em “Fork”. Neste exemplo, estamos utilizando este repositório da Alura:

Irá aparecer uma página onde você tem a opção de personalizar o seu fork, alterando o título e descrição, assim como a opção de clonar apenas a branch master ou as outras branches do projeto também. Clique em “Create fork” para confirmar a criação do fork:

Observe que abaixo do nome do repositório aparece a mensagem “forked from …” . A partir de agora é como se o repositório fosse seu. Todas as alterações que você fizer serão refletidas somente no seu fork.

Clonando o repositório remoto

Para clonar o repositório em sua máquina local e poder alterar o projeto, você precisa do link para o repositório. Para isso, na página do seu repositório remoto, clique em “Code” e copie a url:

Na sua máquina, vá até o local onde você deseja que o repositório seja salvo, e abra o Git Bash:

Você também pode abrir o Git Bash e navegar até o diretório desejado usando o comando cd .

Insira o comando a seguir utilizando a url que você copiou:

# git clone <url do repositorio>
git clone https://github.com/<seu-usuario-github>/introducao-a-data-science.git

Ainda usando o Git Bash, acesse o repositório clonado.

cd introducao-a-data-science/

Observe que existe uma pasta “.git”.

A pasta .git é uma pasta oculta que fica no diretório raiz de um repositório Git, contém todo o controle de versão para aquele repositório e armazena as informações sobre o histórico de commits, branches, tags e outras configurações relacionadas ao repositório.

Ela possui em seu conteúdo:

objects: Esta pasta armazena os objetos do Git compactados, que representam as versões dos arquivos e diretórios ao longo do tempo.

refs: Aqui estão as referências para commits, branches, tags e outras entidades. As branches e tags são mantidas aqui como ponteiros para commits específicos.

logs: Essa pasta contém logs de referências, mantendo um registro de quando as referências (como branches) foram atualizadas.

HEAD: Este é um arquivo que aponta para o commit atual em que você está trabalhando. Geralmente, ele aponta para a branch que está ativa.

config: Este arquivo armazena as configurações específicas do repositório, como informações de usuário e opções de formatação.

index: Este arquivo é conhecido como “index” ou “staging area”. Ele contém informações sobre as mudanças que estão prontas para serem commitadas.

hooks: Nesta pasta, você pode adicionar scripts personalizados que serão executados automaticamente em certos eventos do Git, como antes de um commit ou após um merge.

É importante não mexer manualmente nos arquivos dentro desta pasta, a menos que você tenha um conhecimento profundo do funcionamento interno do Git.

Enviando as alterações para o repositório remoto

Após realizar as alterações desejadas, você pode atualizar o seu repositório. Por ainda se tratar de um tutorial básico, e o repositório ser apenas para fins didáticos e sem impacto no repositório original, ainda vamos fazer as alterações diretamente na branch master.

git status # verifique os arquivos que foram alterados

git add readme.md # adiciona ao commit apenas as alterações feitas no arquivo readme.md
# você pode adicionar ao commit todas as alterações usando git add .

git commit -m "add readme" # adiciona a mensagem de commit

git push origin master # envia o commit com as alterações para a branch master

Acesse/Atualize a página com o repositório remoto e observe que o arquivo adicionado já aparece, bem como a mensagem do último commit.

Espero que este tutorial tenha te ajudado!

Se ficou alguma dúvida, sinta-se à vontade para me contatar.

Introdução ao Git e Github — Parte I

Amanda — Wed, 06 Dec 2023 09:42:58 +0000

Seja no desenvolvimento de software ou no mundo dos dados, a colaboração entre os integrantes do time está sempre presente, sendo assim, o controle eficiente das alterações de código é essencial.

Neste post vamos explorar o que é o Git e o GitHub, configuração e principais comandos. Este é um tutorial introdutório para que você se familiarize com a ferramenta.

O que é Git e GitHub?

O Git é um sistema de controle de versão distribuído, projetado para rastrear as alterações realizadas em arquivos ao longo do tempo, permitindo controlar as alterações realizadas em scripts, conjuntos de dados e qualquer outro tipo de arquivo. Ele mantém um histórico completo de todas as modificações, o que ajuda a evitar conflitos e facilita a colaboração entre diferentes pessoas.

O GitHub, por sua vez é uma plataforma baseada na web que hospeda um repositório Git, também oferecendo diversos outros recursos adicionais, e se tornou uma das principais comunidades de desenvolvimento open source.

Ao utilizar o Git você pode se deparar com vários termos, como commit, stage e branches.

Um commit é como se fosse uma foto instatânea das mudanças feitas nos arquivos de um repositório. Cada commit tem uma descrição que ajuda a entender o que foi alterado e é utilizado para rastrear as alterações realizadas no projeto.

O stage é um espaço intermediário entre os arquivos modificados em seu repositório local e o repositório remoto. Quando você faz alterações em seus arquivos, precisa selecionar quais alterações deseja incluir em um commit, é como dizer ao Git quais mudanças você deseja incluir na próxima “foto”. A ação de selecionar essas alterações e prepará-las para adicionar ao commit é chamada de “staging”.

Branches(ou ramos) são cópias separadas do projeto e permitem que você trabalhe em diferentes partes do projeto sem afetar o código principal. É como uma linha de desenvolvimento independente. O ramo principal do projeto, normalmente chamado de “master” ou “main”, contém a versão estável e funcional do seu projeto, que seria a versão de “produção”. Você pode criar novos ramos para trabalhar em novos recursos (features) ou correções de bugs específicos, isolando as mudanças até que estejam prontas para serem incorporadas ao ramo principal, o que facilita o trabalho em equipe e a organização das alterações.

A forma como as branches são criadas varia de equipe a equipe. Uma prática muito comum é que a branch principal (master/main) contenha a versão de produção mais recente e por isso seja intocável até o lançamento da próxima versão. Então a partir da branch main, cria-se uma branch “dev”, que se torna a branch principal de desenvolvimento. Sendo assim, cada membro responsável por uma correção de bug ou adição de uma nova feature deve criar a sua branch individual a partir da branch “dev” e realizar as suas alterações no código apenas dentro de sua branch. Quando a alteração da branch individual é finalizada, é criado um pull request, que é a solicitação de que o código da sua branch individual seja incorporado(mergeado) à branch “dev”. Ao final do ciclo de desenvolvimento, a branch “dev” é incorporada à branch “main” para que seja disponibilizada a nova versão do produto.

Não se preocupe se você não conseguir entender todos esses conceitos em um primeiro momento, isso é algo que normalmente absorvemos com a prática. No tutorial desta publicação não vamos trabalhar com várias branches, porque o objetivo aqui é que você tenha um primeiro contato e se familiarize com a ferramenta. Branches e outros conceitos serão aplicados com maior profundidade em publicações futuras.

Configuração

Primeiramente, crie uma conta no GitHub, caso ainda não tenha.

O próximo passo é configurar o Git, para isso, é necessário fazer o download e instalação em sua máquina, acessando o site oficial do Git e seguindo as instruções específicas para o seu sistema operacional.

Após a instalação, é necessário realizar uma configuração inicial, definindo o nome de usuário e endereço de e-mail. Crie uma nova pasta na sua máquina e adicione um arquivo de texto qualquer para enviar para o repositório do GitHub (você pode também utilizar uma pasta já criada com os códigos que deseja enviar para o GitHub ao invés de criar uma nova), abra o terminal a partir da nova pasta criada (ou o Git Bash se você utiliza o Windows). Um jeito fácil de fazer isso se você utiliza o Windows é clicar com o botão direito do mouse (clicar em “Mostrar mais opções”, se utilizar Windows 11) e selecionar a opção “Git Bash Here”.

Execute os comandos a seguir substituindo o conteúdo dentro das aspas pelas suas informações utilizadas para criar a conta no GitHub:

git config --global user.name "Seu username"
git config --global user.email "seu-email@example.com"

Enviando o conteúdo local para o repositório remoto do GitHub

Crie um novo repositório no GitHub e copie a url do repositório:

Para conectar o repositório local (a pasta na sua máquina) com o repositório remoto (criado no GitHub) utilize os comandos a seguir:

git init # inicializa o repositório
# criando uma ligação entre o repositório local e repositório remoto
git remote add origin "a url que você copiou ao criar o repositório"

Agora que já foi criada essa conexão, você já pode enviar o conteúdo do seu repositório local (da pasta no seu computador) para o repositório remoto.

git status # compara os arquivos do repositorio local com o repositorio remoto
# observe que aparecem todos os arquivos/pastas que existem no repositório local
# porque eles ainda não estão disponiveis no GitHub

Para adicionar todos os arquivos ao commit utilize o comando a seguir:

git add .
# se você quiser enviar apenas um arquivo específico,
# especifique o nome do arquivo. Por exemplo:
# git add teste.txt

Você pode verificar o que foi enviado para o stage. Os arquivos presentes no stage aparecem após Changes to be commited: (use “git rm — cached …” to unstage) .

git status

Para criar o commit e adicionar uma mensagem para identificá-lo, utilize o comando a seguir:

git commit -m "mensagem descritiva"
# exemplo:
# git commit -m "first-commit"

Para simplificar, e como esse repositório não é utilizado por outra pessoa, vamos enviar as alterações para a branch master, que é a branch principal. Em projetos reais não devemos enviar diretamente à branch master.

Para enviar as alterações utilize o comando a seguir:

git push origin master

Após enviar os arquivos, você pode usar o comando “git status” para verificar se ainda há arquivos no repositório local que podem ser enviados ao repositório remoto. Nesse caso não há, pois aparece a mensagem “nothing to commit, working tree clean”.

Atualize a página no seu repositório e você poderá ver que o conteúdo foi enviado com sucesso para o repositório remoto.

Calculando o tempo de Execução de códigos em Python

Amanda — Wed, 08 Nov 2023 23:21:03 +0000

Você já teve curiosidade em saber o tempo de execução do seu código ou comparar qual método utilizado é mais rápido?

O objetivo deste post é compartilhar algumas formas de fazer isso usando Python.

Biblioteca time

Utilizando a biblioteca time, você pode capturar o início e o fim da execução de um trecho de código para saber o tempo que ela levou.

import time

tempo_inicio = time.time()

for i in range(3):
    print(i)

tempo_fim = time.time()

print(f('Tempo de execução do trecho de código {str(tempo_fim - tempo_inicio)}s')

Funções Mágicas do iPython

No iPython você pode usar %%timeit no início da célula para capturar o tempo de execução de toda a célula ou o %timeit para apenas uma única linha:

%timeit sum(range(5000))

O que essa função faz é automaticamente utilizar múltiplas execuções do código e retornar o tempo médio de execução.

Essa função também aceita alguns argumentos, como por exemplo -n que define o número de vezes que o código deve ser executado, e -r que define o número de repetições com a quantidade de loops passada no argumento “-n”.

%%timeit -r2 -n2
for i in range(3):
  print(i)`

Também é possível armazenar o resultado em uma variável (utilizando o argumento -o) para visualizar melhor os resultados:

tempo_exec = %timeit -o -r2 -n2 my_list = [i for i in range(3)]

Como por exemplo, ver todos os tempos de execução:

tempo_exec.timings

Outra opção é a função mágica %time, que verifica o tempo de execução uma única vez. Ela é preferível em alguns casos, como quando se quer descobrir o tempo de execução para uma função de ordenação. Nesse caso, como uma lista já ordenada demora um tempo menor do que uma lista não ordenada, usar %timeit pode distorcer os resultados.

import random
random_list = [random.random() for i in range(100000)]
%time random_list.sort()

Por outro lado, %timeit além de executar o cálculo várias vezes retornando a média para tentar contornar a influência de outras tarefas do sistema durante a execução, também realiza outras operações por baixo dos panos, como desabilitar o garbage collector (responsável pela limpeza de objetos não utilizados), retornando um tempo de execução menor e mais acurado.

Para saber mais:

Documentação iPython. Disponível em: https://ipython.readthedocs.io/en/stable/interactive/magics.html#magic-time

Jake VanderPlas. Python Data Science Handbook. Disponível em: https://jakevdp.github.io/PythonDataScienceHandbook/01.07-timing-and-profiling.html