A PredictX é um estudo de caso fictício de uma plataforma de prediction market com software transacional, streaming, modelos probabilísticos, LLM, experimentação e feedback loops. O objetivo é entender por que cada decisão existe.
Em um prediction market, o preço pode ser interpretado como probabilidade implícita. A hipótese da PredictX é que sinais externos + comportamento do mercado + ML podem produzir uma segunda estimativa útil. Isso precisa ser provado, não assumido.
Market 31% AI ?
Market Price é um sinal e um baseline. Não é automaticamente ground truth.
Sem requisitos e escala, escolher Kafka, Redis ou um Transformer vira preferência pessoal. Aqui cada tecnologia deve responder a um problema concreto.
Clique em qualquer componente. O painel inferior explica sua responsabilidade, por que ele foi escolhido e o principal trade-off.
O caminho de trading é crítico e não depende do LLM. Kafka distribui eventos para processamento assíncrono. O Online Feature Store alimenta inferência de baixa latência; o Offline Store alimenta treinamento histórico. O caminho de Retrieval/RAG é separado: documentos viram chunks, embeddings e evidências recuperadas antes de chegar ao LLM. Se esse caminho falhar, trading e AI Probability continuam disponíveis. Model Registry controla o ciclo de vida e feedback/observabilidade fecham o loop.
System Design não é uma lista de tecnologias. Uma boa decisão explica o que estamos protegendo e qual custo aceitamos.
Use os botões para acompanhar uma requisição de trade, uma inferência online, um treinamento offline e o feedback que retorna ao sistema.
O modelo deve corresponder ao tipo de dado, à restrição de latência e ao valor incremental que entrega.
Volume, liquidez, volatilidade, concentração, time-to-resolution. Excelente baseline para dados tabulares, rápido e barato para serving.
Notícias, documentos, classificação, event extraction e embeddings. Mais expressivo para texto, porém potencialmente mais caro.
Dinâmica temporal de preços, volatilidade e sinais históricos. O valor depende da estrutura temporal do problema.
Combinar modelos pode melhorar robustez. Média simples é um baseline; pesos aprendidos e stacking são alternativas. Divergência entre modelos pode virar uma feature de uncertainty.
Quando o produto mostra probabilidades, qualidade não é apenas acertar YES/NO. A confiança declarada precisa fazer sentido.
Entre muitos eventos previstos em 70%, aproximadamente 70% deveriam ocorrer. Um modelo pode rankear bem e ainda ser overconfident.
Para evento binário: (prediction − outcome)². Penaliza previsões probabilísticas ruins. Menor é melhor.
Também avalia probabilidades e pune fortemente previsões extremamente confiantes que estavam erradas.
Um trade de US$ 2 milhões pode representar informação genuína, manipulação ou apenas um participante assumindo risco. O sistema precisa reagir sem tratar “trade grande” como sinônimo de fraude.
Se temos milhares ou milhões de notícias, não enviamos todo o corpus ao modelo. Primeiro recuperamos um pequeno conjunto de evidências relevantes e só então geramos a explicação.
Documentos são limpos e divididos em trechos menores. Cada chunk preserva metadata como source, published_at, market_id, category e URL de origem.
Um embedding model transforma texto em vetor. Conteúdos semanticamente próximos tendem a ocupar regiões próximas do espaço vetorial.
Os vetores são persistidos com seus metadados. Na PredictX começamos com PostgreSQL + pgvector para reduzir complexidade operacional.
Vector Search entende significado; lexical search encontra nomes, siglas, datas e palavras específicas. Para notícias e eventos, os dois sinais são úteis.
Encontra documentos semanticamente próximos mesmo quando a query e o texto não usam as mesmas palavras. Normalmente usa cosine similarity, dot product ou distância equivalente.
É forte quando “NASA”, “Artemis III”, “2028” ou “Starship” precisam aparecer explicitamente. BM25 é um algoritmo clássico para esse tipo de ranking textual.
A PredictX já utiliza PostgreSQL. pgvector permite começar com similarity search e metadata filtering sem introduzir imediatamente outro banco. Se o corpus, QPS, filtros ou necessidades de indexação crescerem muito, podemos avaliar um mecanismo especializado. A decisão é evolutiva, não dogmática.
Trading, Market Service e a previsão probabilística principal continuam funcionando mesmo se o retrieval estiver indisponível.
Se pgvector, reranker ou LLM falharem, podemos ocultar a explicação ou mostrar uma versão anterior. Não derrubamos a operação financeira por causa de uma feature explicativa.
Compare qualidade, calibração, latência de cauda e custo. Produção otimiza um sistema inteiro, não uma única métrica.
| Métrica | v17 Champion | v18 Challenger | Leitura |
|---|---|---|---|
| Brier Score | .184 | .171 | v18 melhor |
| Calibration Error | .061 | .043 | v18 melhor |
| p95 | 32 ms | 71 ms | v17 mais rápido |
| p99 | 61 ms | 287 ms | v18 pior na cauda |
| Custo / 1M | US$40 | US$190 | v18 ~4,75× mais caro |
O candidato recebe tráfego real, gera prediction e logs, mas o usuário continua recebendo o Champion.
Uma pequena porcentagem real já recebe o novo modelo. Aumentamos o tráfego se os guardrails permanecerem saudáveis.
Se p99, erros, custo ou qualidade violarem limites, o Model Gateway volta para uma versão segura.
Não são substitutos perfeitos. A/B favorece comparação controlada; bandits tentam maximizar reward acumulado enquanto exploram alternativas.
ε-greedy é simples; UCB adiciona bônus por incerteza; Thompson Sampling usa distribuições probabilísticas para balancear exploração e exploração do melhor conhecido.
A pergunta muda de “qual modelo é melhor?” para “qual modelo é melhor neste contexto?”.
Market Price é uma feature. A previsão altera o comportamento, o comportamento altera o preço e o preço entra novamente no modelo. Agora o sistema pode estar medindo parte do efeito que ele mesmo causou.
Um pipeline pode estar 100% “verde” tecnicamente e ainda produzir features semanticamente erradas. Production ML observa software, dados e modelo.
P(X) mudou. Ex.: trade médio passou de US$120 para US$810. Isso não prova degradação.
P(Y|X) mudou. Uma feature que antes era preditiva deixou de representar a mesma relação com o target.
A distribuição dos outputs mudou. Pode ser mudança real, pipeline quebrado ou comportamento diferente.
Detectar → investigar → medir impacto → identificar causa → treinar Candidate → avaliar → Shadow → Canary → promover. Continuous Training não implica Continuous Deployment.
Abra os tópicos para revisar problemas que não aparecem claramente no diagrama, mas quebram sistemas reais.
O objetivo não é decorar nomes. Cada pergunta testa se você consegue escolher uma solução a partir do problema.
Use como revisão antes de entrevistas de System Design ou Production ML.
Dados alimentam modelos. Modelos geram decisões. Decisões alteram usuários e o mundo. O mundo produz novos dados. Projetar AI Systems é projetar esse ciclo inteiro — incluindo software, dados, infraestrutura, risco, custo e comportamento.