RAG em Produção em Escala: Lições de mais de 10.000 vagas diárias
Eu construí um pipeline de RAG para um portal de empregos. Funcionou em staging, mas teve dificuldades sob carga real. Processar milhares de vagas diariamente exige mais do que um bom vector store. Você precisa entender onde o sistema falha.
Aqui estão minhas lições sobre chunking, embeddings, custos e observabilidade.
- Não tente adivinhar sua estratégia de chunking
A maioria dos tutoriais trata o chunking como uma configuração simples. Em produção, sua estratégia dita a precisão e o custo.
Eu testei três métodos para anúncios de vagas:
- Chunks de tamanho fixo: Estes falharam. Eles dividiam seções como "requisitos" e "benefícios" em pontos aleatórios. Isso cria uma recuperação ruidosa (noisy retrieval).
- Semantic chunking: Foi melhor, mas inconsistente. Alguns chunks eram muito longos e outros muito curtos.
- Recursive character splitting com overlap: Este funcionou melhor. Eu dividi por quebras de linha e sentenças. Usei um tamanho de 400 tokens com um overlap de 50 tokens. Isso garante que sentenças que abrangem dois chunks permaneçam conectadas.
Dica de profissional: Normalize seus dados antes do chunking. Diferentes fontes como Greenhouse ou Lever retornam formatos diferentes. Limpe o texto primeiro para que seu chunker veja uma estrutura consistente.
- Embeddings: Custo vs. Precisão
Eu testei o Llama 3.1 via Ollama contra o OpenAI text-embedding-3-small. O modelo local era gratuito, mas tinha dificuldades com termos específicos do domínio, como "equity compensation". Ele produzia resultados ruidosos. A OpenAI custava mais, mas fornecia correspondências precisas. Escolhi a OpenAI porque uma recuperação ruim custa mais caro em chamadas de LLM posteriormente.
Para economizar tempo, eu faço o batch das minhas requisições. Envio até 100 chunks em uma única chamada. Isso reduz a latência e mantém o pipeline rápido.
- O Trade-off do Vector Store
Eu usei o Pinecone para prototipagem porque é rápido de configurar. No entanto, em escala, os custos ficaram muito altos.
Mudei para o pgvector dentro do PostgreSQL.
- Deu mais trabalho para configurar.
- Economizou uma quantidade massiva de dinheiro.
- Forneceu consistência transacional. Como os embeddings residem no mesmo banco de dados que os dados das vagas, você tem uma única fonte de verdade. Você não precisa sincronizar dois sistemas diferentes.
- Controlando os Custos de LLM
Pontuar cada vaga com o GPT-4o é caro. Usei três táticas para reduzir os custos:
- OpenAI Batch API: Eu processo os trabalhos de pontuação durante a noite. Isso oferece um grande desconto.
- Caching: Eu faço o cache dos resultados para perfis de candidatos recorrentes.
- Model tiering: Uso o GPT-4o-mini para cargos comuns como "Sales Representative". Só uso o GPT-4o para cargos de nicho onde a precisão é vital.
- Construa a Observabilidade Primeiro
Meu pipeline uma vez falhou silenciosamente. Dados malformados causaram chunks vazios, que o sistema ignorou sem erro.
Corrigi isso adicionando logs estruturados com um ID de correlação. Isso me permitiu rastrear um anúncio desde a ingestão até a pontuação. Finalmente consegui ver quais fontes de dados estavam causando falhas.
A maior lição: A maioria dos problemas vem de dados bagunçados, não da IA. Conserte seu encanamento de dados primeiro.
Comunidade de aprendizado opcional: https://t.me/GyaanSetuAi