Uma grande parte do que faz o gpu_prices ser útil é o tratamento empregado nos dados que são ingeridos. É importante garantir a qualidade dos dados para que as informações mostradas sejam confiáveis. Além disso, antes de fazer visualizações e recomendações, é necessário que eles passem por transformações que os tornem "próprios para consumo". Nesta página, vamos entrar em detalhes sobre como isso é feito aqui no Indicador de Preços das GPUs.

Infelizmente, não há como ter todos os dados necessários para o seu projeto de dados em um só lugar (normalmente). Para o indicador de preços, nós precisamos de dados de preços e, também, um pouco menos óbvio, de dados de demanda. Já para fazer comparativos de desempenho do hardware nas mais diversas aplicações que uma placa de vídeo pode ter, precisamos de uma medida de desempenho em todos os casos de uso possíveis e, para cada um deles, uma fonte de dados diferente.

Um dos maiores desafios deste projeto é a integração desses dados. É preciso que o programa não tenha dúvidas de que o score de desempenho em uma tarefa está ligado à placa de vídeo Y e que o dado de preço, em um momento específico, também está relacionado à mesma. Só assim será possível comparar todas as placas de vídeo umas com as outras em sua relação custo-benefício para aquela tarefa específica.

Outra grande dificuldade está em garantir a qualidade dos dados, é importante que os dados de desempenho estejam corretos e atualizados para evitar que análise de custo-benefício gere resultados imprecisos. Outra coisa que afeta bastante a qualidade dos dados é garantir que os preços estão sempre bem representativos da real precificação destes produtos, ou seja, são preços recentes e estão corretos.

A partir daqui, vamos discutir cada origem de dado de acordo com o tipo, entrando em detalhes sobre seu método de coleta e tratamento:

Os dados de preços são provenientes de um banco de dados local, que é atualizado diariamente com a tecnologia do meu outro projeto Price Indexr. Antes de renderizar a página web do Indicador de Preços das GPUs, , é preciso fornecer o caminho para o banco de dados SQLite que o Price Indexr criou, utilizando o seguinte comando:

rscript render.R C:\caminho\para\o\banco\de\dados\price_indexr.db

Este comando cria um arquivo frontend/assets/dbpath.rds que é ignorado pelo git. Depois de fazer isso pela primeira vez, só será necessário usar rscript render.R, pois o arquivo criado será utilizado para lembrar onde procurar pelo banco de dados. Será necessário executar este comando novamente apenas se o caminho para o arquivo mudar.

Antes de começar a renderizar o documento, o script backend/scripts/update_prices.R coleta dados dos últimos 6 meses de preços, realiza algumas manipulações, e armazena em backend/data/prices.rds. Como sempre serão apenas os seis últimos meses, o tamanho deste arquivo não deve crescer significativamente com o tempo. Este arquivo binário está no formato RDS e é acompanhado pelo Git. Você pode fazer o download e obter uma boa amostra dos dados que tenho no meu banco de dados.

O tratamento envolvido na manipulação dos dados originais de preços pode ser conferido diretamente no arquivo update_prices.R por quem tiver algum conhecimento em programação (está escrito em R, mas a linguagem que você conhece não importa). Em resumo, o tratamento inicial desses dados envolve:

1. Coleta das tabelas prices e products
2. Junção das tabelas pelas chaves primária de products e estrangeira de prices
3. Ajuste no nome de algumas colunas
4. Transformação dos tipos de dados em colunas de datas
5. Remoção de linhas redundantes (duplicatas)

Placas de vídeo podem ser adquiridas para acelerar diversos tipos de demandas computacionais, entre elas estão:

1. Jogos eletrônicos
2. Codificação de vídeo (ex.: para editores de vídeo e livestreams)
3. Modelagem 3D
4. IA generativa

Uma pessoa pode tomar a decisão de adquirir uma placa de vídeo para qualquer uma destas finalidades, ou até uma combinação delas, como o Indicador de Preços das GPUs tem o objetivo de ajudar pessoas em sua decisão, seja qual for a sua necessidade, é necessário que tenhamos dados de desempenho em todos estes casos de uso.

A principal medida de desempenho em jogos eletrônicos é o FPS médio1. Essa métrica é obtida quando uma placa de vídeo é testada em uma seleção de jogos de alta demanda gráfica, resultando num FPS médio para cada jogo e, em seguida, numa "média das médias". O resultado é um número que serve como indicador de desempenho da placa de vídeo.

Praticamente todos os jogos que possuem algum nível relevante de demanda gráfica incluem opções de efeitos visuais. O jogador pode escolher uma configuração que garante mais efeitos visuais quando o desempenho de sua placa de vídeo permite oferecer uma experiência fluida com bons visuais. Em um hardware mais limitado, pode ser necessário remover alguns efeitos visuais para atingir a fluidez desejada. O nível mínimo considerado jogável são 30 FPS, mas o ideal é que sua placa de vídeo consiga fazer 60 FPS ou mais.

O conjunto de dados usado para essa métrica vem de produtores de conteúdos relacionados a hardware, infelizmente a maioria deles não facilita a coleta de seus conjuntos de dados. Listando (não exaustivamente) alguns que disponibilizam seus dados publicamente, ordenados pela maior facilidade de coletar são:

1. Tom's Hardware
2. TechPowerUp
3. Gamers Nexus
4. Adrenaline
5. Notebookcheck

O Indicador de Preços das GPUs atualmente usa dados do Tom's Hardware, justamente por causa das tabelas embutidas nesta página, que torna os dados mais fáceis de serem coletados. Os demais portais costumam colocar esses dados em imagens em vez de texto e/ou espalhados por muitas páginas diferentes, o que complica a coleta e manutenção do conjunto de dados.

A coleta desses dados é feita no Python com o update_benchmarks.py. Essa rotina é executada manualmente e coleta os dados da tabela incorporada na página, armazenando-os em dois arquivos CSV: tomshardware_raster_avg_fps.csv para o desempenho sem Ray Tracing, e tomshardware_rt_avg_fps.csv para o desempenho com Ray Tracing habilitado. Sempre que o script é executado, o conteúdo dos arquivos CSV é completamente substituído.

Acessando a tabela do Tom's Hardware, você poderá perceber que nem todos os espaços estão preenchidos com dados, e que alguns modelos de placas de vídeo podem não estar presentes. Esta falha pode ser "emendada" ao adicionar dados de outras fontes, mas infelizmente isso pode introduzir imprecisões nas comparações entre o desempenho das placas de vídeo, devido a diferenças nas metodologias e nos componentes dos computadores usados nos testes.

Este é um dos pontos onde é mais difícil de se obter dados, atualmente usamos apenas os dados do Cinebench, que a partir da versão de 2024 passou a incluir teste de GPU usando a engine de Renderização de 3D e vídeo do Redshift, que são ambos da mesma empresa.

Ainda parece um pouco nebuloso para mim o que tem mais impacto nesse benchmark do Cinebench, se tem mais impacto a capacidade de processar shaders 3D ou se tem mais impacto a capacidade de codificar vídeo, porque aparentemente este software Redshift é capaz de acelerar ambos, também não consegui encontrar nenhuma documentação especificando isso, mas como os dados de desempenho são mais escassos na parte de codificação de vídeo, eu decidi deixar esses dados nesta categoria.

Até um certo tempo, não existia um site dedicado à divulgar os dados de benchmarks, então eu usei dados "garimpados" pelo CG Director. A coleta desses foi mais simples ainda, percebi que conseguia copiá-los e colar em uma planilha sem ter que fazer muitos ajustes depois disso, os dados estão na planilha prods.xslx, na tabela "videos".

Os dados na fonte estão em "tempo de renderização", esta é uma medida que quanto menor, melhor, mas é mais desejável que seja uma medida maior é melhor para se encaixar no modelo de recomendação, para isso eu usei uma fórmula simples, em que o score ($S$) é simplesmente 100 mil dividido pelo tempo ($T$) em segundos:

$$ S = \frac{100000}{T} $$

Felizmente, o maior software de criação e animação de modelos 3D é o Blender, trata-se de um software livre e open-source mantido pela Blender Foundation. Além do Blender, esta organização também oferece um programa de benchmarks, e disponibiliza publicamente os dados de desenpenho coletados pelos seus usuários. Podemos simplesmente fazer uma consulta, e teremos um link de download em formato CSV direto no site, sem necessidade de web scraping.

Os dados que podem ser baixados são anonimizados de certa maneira, já que não podemos ter as informações especfíficas de todo o Hardware em que o benchmark foi executado, ou de o quem fez, mas podemos ter uma estatística da mediana de desempenho ao longo dos testes realizados, e isso é exatamente o que procuramos.

Outra coisa para se levar em consideração é a variável compute type que podemos especificar na consulta. O Compute Type é uma API que permite o Blender acessar toda a capacidade de uma GPU, e sua escolha depende do fabricante do chip, sendo:

• CUDA e OPTIX para GeForce GTX e GeForce RTX da Nvidia, respectivamente
• HIP para placas Radeon da AMD
• OPEN API para placas Arc da Intel
• METAL para chips gráficos integrados da Apple

Outro software conhecido para criação 3D é o V-Ray, felizmente, a empresa responsável por ele também oferece uma página com dados de Benchmarks coletados pelos seus usuários, não existe esta distinção de compute types em seu conjunto de dados, mas existem benchmarks com múltiplas GPUs, como o intuito do Indicador de Preços das GPUs é de oferecer comparações 1 a 1, não usamos estes dados.

No caso do V-Ray, não conseguimos fazer o download dos dados convenientemente como no site do Blender, então recorremos ao web scraping com o script de python update_benchmarks.py para automatizar esta coleta. Infelizmente não é possível coletar todos os dados necessarios de uma vez, então o processo de coleta envolve uma pesquisa diferente para cada linha a ser inserida no conjunto de dados em um processo iterativo.

Este é outro caso em que é muito difícil encontrar dados, eu preenchi manualmente a tabela gen_ai do conjunto de dados prods.xlsx com os dados presentes nos gráficos desta publicação do Tom's Hardware. A unidade de medida usada por eles é "imagens geradas por minuto", em vez de "tempo para renderizar uma imagem", o que ajuda no algoritmo de recomendação.

Existe a possibilidade de que a performance medida não seja totalmente coerente com a capacidade das placas de vídeo, atualmente o suporte à aceleração de GPUs do TensorFlow se dá apenas à placas de vídeo da Nvidia. Infelizmente não conheço nenhum banco dados aberto que tenha este tipo de informação, além da publicação mencionada, talvez tenhamos que esperar mais até que estas coisas comecem a aparecer, ou já existe apenas não encontrei.

Não faz sentido usar o Indicador de Preços das GPUs se os dados não forem confiáveis. Os dados de preço devem ser bem representativos dos preços atuais desses produtos, os dados de demanda devem representar adequadamente a procura por essas GPUs e os dados de desempenho... Acho que já deu para entender.

O maior desafio está em manter a qualidade dos dados que mudam ao longo do tempo. Felizmente, o desempenho das placas de vídeo tende a se manter igual ao longo do tempo, salvo algumas exceções, como a linha Alchemist das Intel Arc, que apresenta ganhos de performance a cada lançamento de drivers.

Normalmente, a maior preocupação relacionada à qualidade se dá principalmente em relação aos dados de preços, mas também um pouco aos dados de consumo (curiosamente, os mais importantes para a construção do índice de preços).

Existem duas etapas empregadas que contribuem para a qualidade dos dados de preços. A primeira se dá diretamente na coleta dos dados, e a outra está presente na preparação do conjunto de dados, no script setup_data.R. Vamos descobrir como isso é feito a seguir.

Os preços são coletados a partir do meu outro projeto de Python, Price Indexr, que coleta dados do Google Shopping e do Bing Compras. Em sua construção, inclui filtros para garantir que os preços coletados apontem corretamente para o produto indicado. Por exemplo, você pode procurar por um modelo específico de uma "Radeon 7600" no Google Shopping e receber uma "Radeon 7600 XT" nos resultados. Ao configurar a coleta de preços da "Radeon 7600", podemos incluir o filtro "XT" para impedir que se atribua o preço de uma "Radeon 7600 XT" ao modelo mais simples.

O mesmo vale no caminho contrário, quando se faz a pesquisa por uma "Radeon 7600 XT", o Price Indexr exige que cada "palavra" individualmente esteja presente no título do anúncio (neste caso, "7600" também é uma palavra), antes de inserir um resultado no banco de dados. Isto é chamado de filtro postivo, uma vez que exige a presença de uma palavra, enquanto que no caso anterior, o filtro negativo exige a sua ausência.

Quando os dados do Price Indexr são ingeridos através do script update_prices.R, algumas pequenas correções são feitas no conjunto de dados:

1. Remoção de linhas duplicadas: Não são muitas vezes, mas pode acontecer de o Price Indexr pegar o mesmo preço na mesma loja e no mesmo dia, isto é considerado uma informação redundante, então simplesmente removemos estas linhas duplicadas sem sentir remorso;
2. Colunas de data e horário: O banco de dados usado pelo Price Indexr é SQLite, ele é muito confiável, leve e fácil de mexer, mas não consegue guardar datas em um formato de dedicado para datas, apenas texto formatado como data. Isto nos faz ter que converter estas colunas de data no formato apropriado para ser usado adequadamente nas próximas etapas de tratamento de dados;

Após receber este leve tratamento, nós criamos o prices.rds, que contém todos os dados de preços que serão usados posteriormente no Indicador de preços das GPUs, mas isto não é tudo o que fazemos com ele.

O prices.rds intencionalmente inclui dados de lojas nacionais e de importação, de produtos novos e usados, mas atualmente só usamos dados de produtos novos vendidos em lojas nacionais, por isso, fazemos a remoção de lojas que não se encaixam nesse critério. Ainda não há nenhum algoritmo para identificar isto automaticamente, fazemos esta distinção listando explicitamente os nomes das lojas diretamente no código em setup_data.R, seria mais fácil simplesmente listar as lojas "fazedoras de preço" no mercado nacional, porque seria uma lista bem menor de se escrever, mas isto traria algumas más consequências:

• Diminuiria a quantidade e variedade de lojas e preços que poderíamos listar no Indicador de Preços das GPUs;
• Esta ferramenta agiria em favor dos varejistas estabelecidos, descartando possíveis boas ofertas de seus concorrentes e desfavorecendo a competição que já não é favorável;

Infelizmente esta abordagem não é isenta de pontos negativos, o maior deles é o fato de demandar mais atenção, pois o atraso na atualização da lista de lojas pode deixar o Indicador de Preços das GPUs mostrando algum preço incorreto por algum tempo.

...