Três meses depois: ainda programando, ainda aprendendo, ainda travado (às vezes)

Atualização (2026): O projeto do chatbot financeiro S&P 500 foi eventualmente encerrado. Sydney voltou e agora foca em conteúdo de blog e produtos. Experimente Sydney →

---

Fiquei em dúvida se deveria sequer escrever esta atualização sobre minha jornada de programação. O progresso não foi vistoso ou externamente visível — então por que se dar ao trabalho?

Bem, talvez este post sirva como um bom lembrete para meu eu futuro de que o progresso pode desacelerar às vezes e o crescimento frequentemente acontece em surtos.

Desde meu último post sobre construção de um chatbot com auto-avaliação em meados de abril, mergulhei em alguns cursos:

• React Basics pela Meta no Coursera
• React Advanced pela Meta no Coursera
• Django web framework
• O Full Stack

Por que esses cursos?

Quero compartilhar minhas experiências pessoais e o processo de pensamento por trás da escolha desses cursos. Minha esperança é que isso possa ajudar aqueles de vocês que estão (ou estarão) em uma jornada semelhante.

Ficando melhor em instruir a máquina

Já se passaram cerca de 10 meses desde minha incursão na programação, enquanto tenho um emprego em tempo integral. (Você pode ler mais sobre Como construí meu próprio chatbot sem experiência em programação: lições aprendidas publicado em outubro de 2023 aqui.)

Definitivamente NÃO conseguiria sem a ajuda de IA Generativa (seja chatGPT, Anthropic Claude ou Microsoft CoPilot no Visual Studio Code). No entanto, quanto mais programo, mais percebo que, embora esses modelos fundamentais sejam poderosos, ainda são como estagiários. Eles ainda não são bons em planejar ou resolver tarefas ambíguas. Quanto mais específicas nossas instruções, melhor o output.

Isso significa que preciso ser cada vez mais específico com minhas instruções de programação. Mas como? Até agora, tenho descrito o que quero em linguagem natural. Embora isso funcione em um nível básico, é inadequado para tarefas mais complexas.

Então a próxima pergunta lógica é: o que aprender?

Foco nos problemas de negócios/usuário que estou tentando resolver

Meu chatbot (codinome Sydney) para este site era (talvez "é") lento. A lentidão acontece tanto:

• No tempo de inicialização
• Como durante a conversa

O streaming não está habilitado, então os usuários têm que esperar um tempo relativamente longo para ver a resposta completa.

Então meu objetivo era (é) simples: torná-lo rápido e responsivo.

Meu objetivo é simples: torná-lo rápido e responsivo. Mas sem mais conhecimento fundamental, é difícil dividir isso em problemas gerenciáveis para resolver. É por isso que decidi aprender mais sobre frameworks de frontend, backend e full stack escaláveis, seguros e rápidos (incluindo bancos de dados).

Minhas experiências com React e Django até agora

• React: React é relativamente mais fácil de aprender e fazer o deploy em comparação com Django. (Óbvio!) O frontend atual do chatbot usa React, e percebi que Claude e ChatGPT conseguem lidar com a maioria das tarefas de programação sem problemas. O deployment em um ambiente de produção com React também foi bastante simples, e a página do chatbot parece mais responsiva durante as conversas.
• Django: Django e Django Rest Framework (DRF) tiveram uma curva de aprendizado mais íngreme, particularmente com o deployment envolvendo um banco de dados Cloud SQL e garantindo segurança. A natureza abrangente do Django significa que o deployment com o nível certo de segurança levou algum tempo. No entanto, ainda NÃO CONSIGO fazer respostas HTML em streaming funcionar com DRF em um ambiente de produção! Embora eu pudesse fazê-lo funcionar usando WebSockets, essa abordagem diverge significativamente do DRF, então ainda não a adotei.

Então, se você souber de um framework ou resposta sobre como fazer o streaming do Langgraph funcionar com um frontend simples, me avise!

E o Chatbot Financeiro que mencionei em abril?

A boa notícia é que este projeto despertou o interesse de muitos de vocês — recebi inúmeras perguntas e comentários. A má notícia? Estou longe de completá-lo T.T Veja por quê:

1. Equilibrando qualidade de recuperação, custo mensal do vector store e custo de embedding

Como mencionado no post de abril, estou avaliando o Serverless Cloud Vector Store do Weaviate. Mas custa dinheiro real. Para este projeto, provavelmente estou olhando para:

• Volume de dados: Mais de 10 milhões, possivelmente 12,5 a 15 milhões de objetos de dados.
• Estimativa de custo: Com uma dimensão vetorial de 512, o custo mensal pode variar de $600 a $750.

Esse valor é administrável para uma empresa em ambiente de produção, mas pode ser alto demais para um projeto paralelo como este. Então preciso encontrar maneiras de reduzir o custo.

Com base em como o preço do Weaviate funciona, as duas alavancas são: reduzir o número de objetos de dados ou reduzir a dimensão vetorial. Ambas têm diferentes trade-offs.

Formas de reduzir objetos de dados

• Limpeza agressiva de texto: Reduzir o tamanho geral do texto nos documentos 10K e 10Q pode ajudar, considerando que estamos lidando com 500 empresas no S&P 500, cada uma com múltiplos documentos ao longo dos últimos 10 anos. Acho que esgotei essa opção.
• Aumentar o tamanho do chunk: Aumentando o tamanho do chunk de 256 para 512, 1.000, 2.000 ou 3.000, posso reduzir o número de objetos de dados em 2x, 4x ou 10x. No entanto, isso pode diminuir a qualidade de recuperação, pois chunks maiores tendem a ser menos precisos.

Formas de reduzir a dimensão vetorial

Reduzir a dimensão vetorial parece diretamente correlacionado com a qualidade de recuperação — quanto menor a dimensão, pior a qualidade de recuperação. Ainda estou experimentando com diferentes modelos de embedding como os modelos "text-embedding-3-small" e "text-embedding-3-large" da OpenAI com várias dimensões. Se você tiver boas recomendações, compartilhe!

Usar o modelo "text-embedding-3-large" da OpenAI também adiciona ao custo durante a fase de embedding. Por exemplo, me custou $4,50 gerar embeddings para os documentos 10K/10Q de 23 empresas nos últimos 10 anos com uma dimensão vetorial de 1024. Isso significa que poderia custar cerca de $100+ para o S&P 500 inteiro. (Sim, sou um pouco pão-duro. Você não sabia disso antes :P?)

2. Latência durante tradução de consultas, estruturação e recuperação

Quanto mais elaborada a tradução e estruturação de consultas, melhores os termos de busca/termos de busca de conteúdo que podemos gerar, levando a uma recuperação de maior qualidade. No entanto, isso também aumenta a latência.

• A tradução de consultas é a etapa em que pedimos ao modelo para traduzir a pergunta inicial do usuário em sub-questões que são melhores para recuperação. Por exemplo, com a pergunta original "Como a margem operacional da Airbnb mudou de 2020 a 2022?" o modelo pode gerar sub-questões como:

[
"What was Airbnb's operating margin in the 10-K filing for the year 2020?",
"What was Airbnb's operating margin in the 10-K filing for the year 2021?",
"What was Airbnb's operating margin in the 10-K filing for the year 2022?"
]

• A estruturação de consultas é a etapa em que pedimos ao modelo para transformar essas perguntas em consultas de busca ou consultas de busca de conteúdo para recuperação, juntamente com filtros relevantes. Usando o exemplo acima, para a pergunta 1, o modelo pode retornar

\{
    "content_search": "What was Airbnb's operating margin in the 10-K filing for the year 2021?",
    "company_conformed_name": "Airbnb, Inc.",
    "form_type": "10-K",
    "conformed_period_of_report": "2021-12-31"
\}

Para recuperação, quanto mais resultados retornamos, mais tempo levará para o modelo processar. Retornar menos resultados significa tempos de resposta mais rápidos, mas potencialmente respostas de menor qualidade devido à falta de contexto.

Concluindo

Há mais com que estou lidando, mas como este post já está mais longo do que o esperado, vou terminar por aqui.

Você também está aprendendo a programar enquanto trabalha em tempo integral? Como você decide o que aprender a seguir quando tudo parece igualmente importante?

Abraços,

Chandler