Showing Posts From

Data engineering

NVIDIA Physical AI Data Factory Blueprint: o repo open-source que muda como você gera dados de treinamento para robótica

A NVIDIA fez algo raro em 16 de março: anunciou que vai abrir no GitHub a pipeline completa de geração de dados sintéticos para Physical AI. Não é um paper. Não é um blog post com diagramas bonitos e zero código. É o blueprint inteiro — geração, augmentation, curadoria e avaliação de dados de treinamento para robôs, veículos autônomos e vision agents. O Cosmos Evaluator já está no GitHub. O repo completo está prometido para este mês. Se você trabalha com robótica, sim-to-real transfer ou qualquer coisa que precisa de dados de treinamento que não existem no mundo real, isso muda a equação. Aqui está o que você precisa saber antes de clonar. A arquitetura: quatro estágios, um pipeline O Data Factory Blueprint é uma pipeline de quatro estágios construída sobre os Cosmos foundation models. Cada estágio resolve um problema específico na cadeia de dados para Physical AI. Estágio 1 — Geração via Cosmos World Models. Os Cosmos models são world models: dados um prompt de cena (posição de objetos, iluminação, física do ambiente), eles geram sequências de vídeo sintético fisicamente plausíveis. Não estamos falando de renders estáticos. São sequências temporais com gravidade, colisões, deformações — o tipo de dado que um robô precisa para aprender a interagir com o mundo real. A NVIDIA treinou esses models em datasets massivos de vídeo real, e o output é bom o suficiente para substituir horas de captura em ambiente controlado. Na prática, o fluxo começa com uma descrição de cena no Omniverse: from cosmos_data_factory import SceneGeneratorscene = SceneGenerator( environment="warehouse", objects=["pallet", "box_cardboard", "forklift"], physics_engine="PhysX", camera_config="multi_view_4x" )# Gera 1000 sequências de 5 segundos cada dataset = scene.generate( num_sequences=1000, duration_sec=5, variations=["lighting", "object_pose", "texture"] )Cada sequência vem com ground truth automático: bounding boxes, segmentation masks, depth maps, poses 6DoF dos objetos. É o tipo de anotação que custaria centenas de horas de trabalho manual. Estágio 2 — Augmentation com domain randomization. Dados sintéticos puros sofrem de um problema conhecido: o sim-to-real gap. O modelo aprende features que existem na simulação mas não no mundo real (iluminação perfeita demais, texturas uniformes demais, ausência de sujeira). O blueprint ataca isso com domain randomization agressiva — variação sistemática de texturas, iluminação, ruído de câmera, poses de objetos e condições ambientais. O pipeline aplica augmentation em camadas: augmentation: texture_randomization: true lighting_variations: ["dawn", "noon", "overcast", "fluorescent"] camera_noise: gaussian_std: 0.02 motion_blur_prob: 0.3 object_pose_jitter: translation_cm: 2.0 rotation_deg: 15.0 background_randomization: trueA ideia é que se o modelo funciona com todas essas variações, ele vai funcionar no mundo real. Na minha experiência com sim-to-real, isso é 80% verdade — os 20% restantes você resolve com fine-tuning em dados reais limitados. Estágio 3 — Curadoria automatizada. Nem todo dado sintético é útil. Sequências onde objetos atravessam paredes, colisões fisicamente impossíveis, cenas com oclusão total — tudo isso é lixo de treinamento. O pipeline inclui um módulo de curadoria que filtra automaticamente sequências com anomalias físicas e balanceia a distribuição do dataset por cenário, iluminação e complexidade de cena. Estágio 4 — Avaliação com Cosmos Evaluator. Esse é o componente que já está no GitHub (github.com/NVIDIA/cosmos-evaluator). O Evaluator mede a qualidade dos dados gerados em três dimensões: fidelidade física (os objetos se comportam como deveriam?), diversidade (o dataset cobre variação suficiente?) e utilidade downstream (treinar com esses dados melhora performance em tarefas reais?). # Já disponível no GitHub git clone https://github.com/NVIDIA/cosmos-evaluator.git cd cosmos-evaluator pip install -e .# Avaliar um dataset gerado cosmos-eval --dataset ./my_synthetic_data \ --metrics physical_fidelity diversity downstream_utility \ --report ./eval_report.jsonO report gera scores por métrica e um breakdown por cena. Na documentação atual, physical fidelity acima de 0.85 e diversity acima de 0.70 são os thresholds recomendados antes de usar o dataset para treinamento. Quem já está usando — e para quê A NVIDIA não está lançando isso no vácuo. Quatro empresas já operam com versões internas do pipeline:FieldAI — dados sintéticos para navegação autônoma em ambientes não estruturados (canteiros de obra, áreas de desastre) Uber — geração de cenários de edge case para veículos autônomos. O tipo de situação que acontece uma vez a cada 100 mil km e que você não pode esperar capturar em dados reais Skild AI — treinamento de foundation models para controle robótico generalista. Com o valuation de US$14B e foco em robot brains, dados sintéticos em escala são a base da tese Teradyne — robótica industrial, com foco em manipulação de objetos variados em linhas de montagemO padrão é claro: empresas que precisam de volumes massivos de dados anotados para robótica e não podem (ou não querem) coletá-los exclusivamente no mundo real. Os trade-offs que a NVIDIA não vai destacar no keynote Vamos ao que importa: onde isso não funciona tão bem quanto o marketing sugere. Custo de GPU. Gerar dados sintéticos com Cosmos world models não é grátis. Cada sequência de 5 segundos em resolução 1080p exige ~4 minutos em uma A100. Para um dataset de 100 mil sequências, são ~6.700 horas de GPU. A US$1,50/hora na AWS, isso dá ~US$10K só em compute de geração. Augmentation e avaliação adicionam mais 20-30%. O custo total de um dataset robusto fica na faixa de US$12-15K. É mais barato que coleta real em muitos cenários, mas não é trivial. Sim-to-real gap não desaparece. Domain randomization ajuda, mas não resolve 100% do problema. Na minha experiência, modelos treinados exclusivamente em dados sintéticos perdem 15-25% de performance quando transferidos para o mundo real sem fine-tuning adicional. O blueprint trata dados sintéticos como complemento de dados reais, não substituto completo — e essa é a abordagem correta. Dependência do Omniverse. O estágio de geração roda sobre o NVIDIA Omniverse. É uma plataforma poderosa, mas é lock-in. Se amanhã você quiser migrar a geração para outra engine (Unity, Unreal, ou um renderer custom), o pipeline vai precisar de adaptação significativa nos estágios 1 e 2. Os estágios 3 e 4 são mais agnósticos. Qualidade vs quantidade. Existe uma tentação de gerar milhões de sequências e jogar tudo no treinamento. O paper do Cosmos Evaluator mostra que datasets curados de 50K sequências consistentemente superam datasets brutos de 500K. Mais dados não é melhor dados. Como começar a testar hoje O Cosmos Evaluator já está disponível. Para o resto do pipeline, a NVIDIA prometeu abril — o que significa que pode aparecer a qualquer momento. Enquanto o repo completo não sai, o caminho pragmático:Clone o Cosmos Evaluator e rode com um dataset existente para entender as métricas Instale o Omniverse (versão gratuita para desenvolvedores) e familiarize-se com a geração de cenas sintéticas via Replicator Monitore o repo github.com/NVIDIA/physical-ai-data-factory — a naming convention segue o padrão dos outros repos da NVIDIA# Setup básico do Evaluator git clone https://github.com/NVIDIA/cosmos-evaluator.git cd cosmos-evaluator python -m venv .venv && source .venv/bin/activate pip install -e ".[dev]"# Rodar com dataset de exemplo cosmos-eval --dataset examples/sample_warehouse \ --metrics all \ --output-format jsonVeredito O Physical AI Data Factory Blueprint é o tipo de release que importa mais do que parece no dia do anúncio. Não é um modelo novo com benchmark recorde. É infraestrutura — a parte chata e essencial que determina se Physical AI sai do demo e entra na produção. A decisão de abrir o código é estratégica: a NVIDIA quer que o ecossistema inteiro gere dados no formato Cosmos, treine no stack NVIDIA e rode em hardware NVIDIA. Open-source aqui é growth strategy, não altruísmo. Mas isso não diminui a utilidade. Se você precisa de dados de treinamento para robótica, o custo de gerar internamente caiu de "projeto de pesquisa de 6 meses" para "pipeline configurável em semanas". Clone o Evaluator. Teste as métricas com seus dados. E quando o repo completo aparecer neste mês, você já vai saber o que medir.

pgvector 0.8 e o fim dos vector databases dedicados? Benchmark com Qdrant, Weaviate e Milvus

O pgvector 0.8.0 saiu e o changelog tem um número que muda a conversa: 5.7x de melhoria em performance. Latência de query filtrada caiu de 120ms para 70ms em dataset de 10M vetores. Quem já rodou vector search em produção sabe o que isso significa — é a diferença entre "preciso de um Qdrant" e "meu Postgres resolve". Faz um ano que escuto a mesma pergunta em toda call de arquitetura: "qual vector database a gente usa?". A resposta padrão era Qdrant, Weaviate ou Milvus. A nova resposta pode ser: o que você já tem rodando. Resolvi parar de especular e rodar os números. Montei benchmark com pgvector 0.8, Qdrant, Weaviate e Milvus em três cenários que cobrem 90% do que vejo em produção. Aqui estão os resultados. Setup do benchmark Antes dos números, o setup — porque benchmark sem contexto é marketing.Dataset: 1M vetores, 1536 dimensões (tamanho padrão de embedding OpenAI text-embedding-3-small) Hardware: 8 vCPUs, 32GB RAM, SSD NVMe, Ubuntu 22.04 pgvector: 0.8.0 sobre PostgreSQL 16, HNSW index com m=16, ef_construction=200 Qdrant: 1.13, configuração padrão com HNSW Weaviate: 1.28, flat + HNSW hybrid Milvus: 2.5, IVF_FLAT com nlist=1024 Cenários: RAG app, e-commerce search, document retrieval Métrica: latência p50 e p99, throughput (queries/sec), uso de memória em steady stateCada cenário rodou 10 mil queries após warmup de 1 mil. Nada de cherry-picking. Os números Cenário 1: RAG App (busca semântica simples) Query típica: embedding de pergunta do usuário → top-10 chunks mais similares. Sem filtro de metadata.Métrica pgvector 0.8 Qdrant Weaviate Milvusp50 latência 8ms 4ms 12ms 9msp99 latência 22ms 11ms 38ms 27msThroughput 420 q/s 890 q/s 310 q/s 380 q/sRAM (steady) 4.2 GB 5.8 GB 7.1 GB 6.3 GBQdrant domina. Não é surpresa — o engine inteiro foi desenhado para isso. Mas 8ms no pgvector é perfeitamente aceitável para um RAG app. Nenhum usuário percebe a diferença entre 4ms e 8ms na busca quando a chamada ao LLM depois vai levar 800ms. Cenário 2: E-commerce Search (busca com filtros) Query típica: embedding do produto → top-20 similares com filtro por categoria, faixa de preço e disponibilidade. Aqui é onde vector DBs dedicados costumavam massacrar o pgvector.Métrica pgvector 0.8 Qdrant Weaviate Milvusp50 latência 15ms 6ms 18ms 14msp99 latência 45ms 18ms 72ms 41msThroughput 280 q/s 620 q/s 210 q/s 300 q/sRAM (steady) 4.8 GB 6.2 GB 7.8 GB 6.9 GBO pgvector 0.8 melhorou absurdamente aqui. Na versão 0.7, essa query filtrada batia 120ms fácil. Cair para 15ms no p50 é o upgrade que fecha a porta para muitas migrações. Qdrant ainda ganha em throughput puro — se você processa milhares de buscas por segundo, a diferença importa. Se são dezenas ou centenas, não. Cenário 3: Document Retrieval (dataset com metadata pesada) Query típica: embedding de documento → top-5 similares com filtro por data, departamento, idioma, tipo de documento e nível de acesso. Cinco filtros simultâneos.Métrica pgvector 0.8 Qdrant Weaviate Milvusp50 latência 23ms 8ms 25ms 19msp99 latência 68ms 24ms 91ms 58msThroughput 190 q/s 480 q/s 160 q/s 220 q/sRAM (steady) 5.1 GB 6.5 GB 8.2 GB 7.1 GBMais filtros, mais gap. O Qdrant foi projetado para esse tipo de filtragem complexa — ele faz pre-filtering nativo no índice HNSW, enquanto o pgvector filtra no PostgreSQL e depois ranqueia. Ainda assim, 23ms no p50 é operável para qualquer aplicação enterprise que não seja real-time. O que os números dizem (e o que não dizem) Três observações: 1. O pgvector come memória significativamente menos. Em todos os cenários, usou 25-40% menos RAM que os concorrentes. Se você já tem um PostgreSQL com 32GB alocados e sobra headroom, vector search vem "de graça" em termos de infra. Se precisa subir um Qdrant separado, são mais 6GB de base + overhead operacional. 2. Qdrant ganha em tudo, mas a margem importa menos do que parece. 4ms vs 8ms é 2x em porcentagem. Em experiência de usuário, é irrelevante. A diferença real aparece em throughput — se você serve milhares de queries simultâneas, Qdrant escala melhor. Se serve centenas, tanto faz. 3. Weaviate e Milvus ficaram atrás nos três cenários. Weaviate tem features interessantes (módulos de reranking, integração com modelos), mas em performance bruta perdeu para todo mundo. Milvus se saiu ok mas não justifica a complexidade operacional — rodar Milvus em produção exige etcd, MinIO e um cluster inteiro. O paradigma mudou: "vector" é data type, não categoria de banco O que torna o pgvector 0.8 significativo não é só a performance. É o que ele representa. "Vector" está virando um data type, não uma categoria de banco de dados. PostgreSQL, Oracle e MongoDB adicionaram suporte nativo a vetores. O movimento é claro: busca vetorial é uma feature, não um produto. Isso é o mesmo padrão que vimos com JSON. Em 2012, todo mundo falava em document databases. MongoDB era obrigatório. Depois o PostgreSQL adicionou jsonb, e 80% das empresas que "precisavam" de MongoDB descobriram que não precisavam. O pgvector está fazendo o mesmo trajeto. Quando o pgvector NÃO resolve Vou ser direto sobre as limitações porque esconder isso seria desonesto:Billion-scale (>100M vetores): o HNSW do pgvector começa a sofrer. Qdrant e Milvus têm estratégias de sharding e quantização que escalam melhor nessa faixa. Latência sub-2ms: se seu SLA exige p99 abaixo de 5ms, pgvector não chega lá. Qdrant sim. Real-time updates com alta concorrência: inserir e buscar simultaneamente em alta frequência ainda causa lock contention no PostgreSQL. Vector DBs dedicados foram desenhados para isso. Filtros complexos em escala: com 5+ filtros e dataset acima de 50M, o gap de performance entre pgvector e Qdrant cresce de 2x para 5x+.Se você tem algum desses requisitos, vector DB dedicado continua sendo a resposta certa. Veredito Minha conclusão vai ser impopular entre quem vende vector database: para a maioria das empresas, pgvector 0.8 sobre PostgreSQL cobre 80% dos casos de uso de busca vetorial. Se você está construindo um RAG app, search semântico em catálogo ou retrieval de documentos com dataset abaixo de 50M vetores — pgvector resolve. Sem novo banco para operar, sem novo vendor para gerenciar, sem nova infra para monitorar. É uma extensão do banco que você já tem. Vector DB dedicado faz sentido em dois cenários: acima de 100M vetores ou com requisitos de latência abaixo de 2ms no p99. Fora disso, é complexidade operacional sem retorno proporcional. O pgvector 0.8 não matou os vector databases dedicados. Mas reduziu drasticamente o número de empresas que precisam de um. Para testar você mesmo: CREATE EXTENSION vector; CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops); — e rode seus próprios benchmarks. Os meus estão aí. Agora mostre os seus.