A Real Time Big Data registrou no TSE uma nova pesquisa de intenção de voto para governo e Senado no Rio e isso muda o jogo — não só por causa do “retratro” eleitoral, mas pelo método híbrido com entrevistas por telefone e digitais, com aplicação de questionário com apoio de inteligência artificial. Segundo o Abril.com.br, o levantamento será feito entre 18 e 22 de julho, com divulgação em 23 de julho, ouvindo 1.600 eleitores e apontando a liderança isolada de Eduardo Paes (PSD). Para devs e designers, o ponto crucial é entender o que esse tipo de pipeline significa em qualidade de dado, viés, rastreabilidade e como vocês podem (e devem) enxergar “big data” com mentalidade de engenharia.
O que a pesquisa registrada no TSE indica (e o que normalmente não aparece)
Segundo o Abril.com.br, a pesquisa está registrada sob o número RJ-06039/2026 e terá nível de confiança de 95% com margem de erro máxima de dois pontos percentuais. A amostra será construída em três etapas: sorteio de municípios, sorteio de localidades e seleção de entrevistados por cotas proporcionais (sexo, faixa etária, escolaridade e renda), tentando espelhar a composição do eleitorado fluminense.
O detalhe técnico que “engole” muita gente é o método de coleta: entrevistas via combinação de abordagem telefônica e digital, com participação de entrevistadores humanos e recursos de inteligência artificial na aplicação do questionário. Isso costuma significar pelo menos uma destas coisas (ou uma mistura):
- questionário guiado por tela/roteiro (reduz pulo de perguntas e incoerência);
- checagens automáticas de consistência (ex.: “você já votou” vs. “idade”);
- assistência ao entrevistador (sugestões, validações, atalhos);
- padronização de registros (reduz variação humana na digitação/observação).
Na prática, isso tende a melhorar “higiene” de dados. Mas também cria novas classes de risco: o modelo pode restringir respostas, a interface pode induzir caminhos, e o fluxo digital pode super-representar quem responde bem a canais digitais. O Abril.com.br menciona cotas e composição do eleitorado, mas não descreve a governança do pipeline (quem controla o AI, como audita, como trata divergências).
Por que isso importa para quem programa (e não para “quem só lê notícia”)
Quando vejo uma coleta com AI no questionário, eu penso como engenheiro:
- Observabilidade: dá para auditar por entrevistador, por canal (telefone vs. digital) e por sessão?
- Reprodutibilidade: o questionário é versionado? O “comportamento” do roteiro muda entre datas/locais?
- Validação: existe validação de entrada/saída do AI e fallback quando falha?
- Fairness prático: o fluxo digital privilegia certos perfis (idade, renda, escolaridade) e como a quota compensa isso?
Sem isso, “big data” vira uma caixa preta. Com isso, vira um pipeline auditável.
Metodologia e amostra: onde os devs costumam errar a leitura
Segundo o Abril.com.br, a pesquisa ouvirá 1.600 eleitores em diferentes municípios fluminenses, com metodologia quantitativa e margem de erro máxima de dois pontos percentuais (para mais ou para menos). Em engenharia, “dois pontos” parece pouco. Mas tem implicações:
- diferenças pequenas entre candidatos podem ser estatisticamente indistinguíveis;
- mudanças de canal (telefone vs. digital) podem deslocar estimativas dentro dessa banda;
- qualquer viés sistemático (cobertura, resposta, recusa) pode mascarar o sinal real.
Três etapas da amostra: o que é “sorteio de municípios” na vida real
O sorteio de municípios e localidades é o que dá base para reduzir concentração geográfica. Mas a qualidade depende de duas coisas que não ficam claras na fonte:
- como a estratificação é feita (proporções realistas vs. “aproximação”);
- como a seleção dentro de localidades respeita as cotas sem “forçar” recrutamento.
Uma armadilha comum em projetos de pesquisa (inclusive em startups que fazem surveys com IA) é achar que cotas resolvem tudo. Cotas mitigam distorção por perfil, mas não corrigem distorção por propensão a responder. Se o canal digital pega mais pessoas engajadas e o telefone fica com recusa maior em certos perfis, você tem viés residual — mesmo com cotas.
Pipeline híbrido (telefone + digital) com AI: arquitetura provável e riscos
O Abril.com.br aponta: “entrevistas por meio de uma combinação de abordagens telefônicas e digitais” e “aplicação do questionário” com “participação de entrevistadores humanos e recursos de inteligência artificial”. Eu costumo ver isso como um pipeline em duas camadas:
- Camada operacional: roteamento de contato, seleção de amostras, agendamento, execução com entrevistador.
- Camada analítica/IA: assistente de questionário (validação, sugestões), eventualmente classificação/normalização de respostas e checagens de consistência.
Quando a IA participa do questionário, os riscos técnicos que eu monitoraria seriam:
- Drift de roteiro: o modelo ou regras mudam sem versionamento claro.
- Validações agressivas: o sistema barra respostas “improváveis” e força o entrevistado a enquadrar.
- Diferença de canal: telefone e digital podem ter timing/linguagem diferentes; o AI talvez trate isso sem calibragem adequada.
- Falhas silenciosas: se a IA falha e cai em modo manual, isso precisa estar reportado.
Como eu tornaria isso auditável (do ponto de vista de engenharia)
Se eu estivesse no time, eu exigiria evidências técnicas mínimas: logs por versão de questionário, trilha de decisão da IA quando houver (mesmo que seja heurística), métricas de qualidade (taxa de conclusão, taxa de abandono, distribuição de “missing/invalid”), e monitoramento por estrato (sexo, faixa etária, escolaridade e renda) separado por canal.
Sem isso, a “inteligência artificial” vira só marketing do fluxo.
Na Prática: como desenhar um questionário “com AI” sem perder controle
Vou te mostrar um esqueleto funcional do que eu faria para um questionário com validação e fallback. A ideia é: a IA sugere/valida, mas o sistema mantém controle determinístico do que foi perguntado e do que pode ser aceito.
Passo a passo
- Versionar o questionário: cada pergunta e cada regra de fluxo precisam ter ID e versão.
- Validar entrada: antes de enviar para “IA” (ou depois), aplicar validações determinísticas (tipo, faixa, obrigatório).
- IA só como assistente: usar IA para classificar texto livre, sugerir opção provável, ou gerar checagem — mas sem bloquear resposta do usuário automaticamente.
- Fallback previsível: se a IA estiver indisponível ou confiança baixa, o entrevistador escolhe via interface.
- Logs completos: registrar pergunta atual, opção selecionada, confiança da IA, canal e versão.
- Auditar por estrato: medir qualidade e taxa de inconsistência por sexo/idade/escolaridade/renda e por telefone/digital.
Exemplo de código: validação + fallback com “IA” guardada atrás de confiança
Este exemplo é um pseudocódigo bem próximo do que dá para implementar em backend. Eu separo validação (determinística) de inferência (IA) e só aplico a inferência quando a confiança passa um limite.
const QUESTION_VERSION = "2026-07-17";
function validateAnswer(questionId, answer) {
// Validações determinísticas: evita que a IA “invente” ou force.
if (questionId === "governor_intent") {
const allowed = [
"Eduardo_Paes","Douglas_Ruas","Andre_Marinho","Anthony_Garotinho",
"Cyro_Garcia","Juliete_Pantoja","Luan_Monteiro","Rafael_Luz","William_Siri"
];
if (!allowed.includes(answer)) return { ok: false, error: "invalid_option" };
}
if (questionId === "age_years") {
const n = Number(answer);
if (!Number.isFinite(n) || n < 16 || n > 120) return { ok: false, error: "invalid_age" };
}
return { ok: true };
}
async function aiSuggestOption(questionId, rawText) {
// Aqui entraria seu provedor de LLM/serviço de classificação.
// Retornando { option, confidence }.
// Ex.: { option: "Eduardo_Paes", confidence: 0.86 }
return { option: null, confidence: 0.0 };
}
async function answerQuestion({ questionId, rawInput, selectedOption, channel }) {
// selectedOption: o entrevistador (ou usuário) escolheu explicitamente
// rawInput: texto livre (se houver)
const version = QUESTION_VERSION;
// 1) Se o usuário/entrevistador já escolheu, valida e segue.
if (selectedOption) {
const v = validateAnswer(questionId, selectedOption);
if (!v.ok) return { ok: false, reason: v.error, version, channel };
return { ok: true, value: selectedOption, usedAI: false, version, channel };
}
// 2) Se só há texto livre, roda validação/assistência.
const validationText = typeof rawInput === "string" && rawInput.trim().length > 0;
if (!validationText) return { ok: false, reason: "empty_input", version, channel };
const ai = await aiSuggestOption(questionId, rawInput);
// 3) Aplica IA só se confiança for alta; senão pede escolha manual.
const CONFIDENCE_THRESHOLD = 0.80;
if (ai.option && ai.confidence >= CONFIDENCE_THRESHOLD) {
const v = validateAnswer(questionId, ai.option);
if (!v.ok) return { ok: false, reason: v.error, version, channel };
return { ok: true, value: ai.option, usedAI: true, aiConfidence: ai.confidence, version, channel };
}
// Fallback: nunca “força” um resultado com confiança baixa.
return { ok: true, value: null, usedAI: true, aiConfidence: ai.confidence, fallbackToHuman: true, version, channel };
}
Por que eu gosto desse desenho? Porque evita o erro clássico: IA decidindo por você sem transparência. Você mantém rastreabilidade (versão/canal), reduz risco de coerção automática e consegue medir a taxa de fallback. Isso, para dados eleitorais, é ouro.
Comparações reais: o que seria uma alternativa e por que ela é pior/mais simples
Em vez de pipeline híbrido com AI, você pode ter alternativas:
- Só telefone: tradicional, mas mais caro por minuto e com variabilidade humana maior (digitação, roteiros diferentes).
- Só digital: mais escalável, mas tende a enviesar por acesso digital, alfabetização digital e perfil de resposta.
- Questionário sem AI: reduz caixa-preta, mas aumenta inconsistência humana e aumenta trabalho de limpeza posterior.
- AI “end-to-end” sem humano: geralmente pior para pesquisa séria, porque a taxa de “entrega” pode ser alta, mas a qualidade e o controle de amostragem ficam frágeis.
O híbrido com humanos e AI “assistindo” tende a ser o ponto de equilíbrio — desde que a implementação seja auditável. Se não for, você trocou um problema (erros humanos) por outro (caixa-preta).
Erros Comuns: o que evitar quando você vê “Big Data + IA” em pesquisa
Aqui vai a lista que eu mais vejo em times de produto e em engenharia de dados:
1) Tratar margem de erro como se fosse “precisão de verdade”
Margem de erro (do Abril.com.br) fala de aleatoriedade em amostra. Ela não cobre viés de cobertura, recusa, canal e má operacionalização. Dois pontos podem virar dez se o canal estiver “torto”.
2) Confundir “uso de IA” com “melhor qualidade automaticamente”
IA pode melhorar consistência, mas pode introduzir padrões. O que importa é: o modelo é determinístico o suficiente para não causar drift? Tem fallback? Tem métricas?
3) Não separar métricas por canal
Se telefone e digital são usados, você precisa de relatórios separados. Caso contrário, você “pune” o dado ao misturar ruídos diferentes.
4) Não versionar questionário e regras
Uma pequena mudança no fluxo entre dias (18 a 22 de julho) pode afetar distribuição de respostas. Sem versionamento, você perde a capacidade de comparar.
5) Não monitorar taxa de abandono e inconsistência
Se a taxa de abandono é maior em um estrato, a amostra efetiva muda. E se o AI aumenta taxa de validação/erro, a amostra muda de novo.
Quem está na disputa: implicações para o tipo de dado que você coleta
Segundo o Abril.com.br, para governo serão testados os candidatos Eduardo Paes (PSD), Douglas Ruas (PL), André Marinho (Novo), Anthony Garotinho (Republicanos), Cyro Garcia (PSTU), Juliete Pantoja (UP), Luan Monteiro (PCO), Rafael Luz (Missão) e William Siri (PSol). Em coletagem de intenção, pequenas diferenças de lista e ordem também importam.
Do ponto de vista de engenharia, eu olho para duas coisas:
- ordem e randomização: a ordem dos nomes pode afetar reconhecimento e resposta;
- normalização: o AI precisa lidar com variações de escrita (“Eduardo Paes”, “Paes”, “Eduardo”) se houver entrada livre.
FAQ — dúvidas que um dev provavelmente vai ter ao ler isso
1) Se a pesquisa usa AI no questionário, isso invalida a metodologia?
Não necessariamente. O que define é governança: versionamento, logs, auditoria, fallback e como a IA impacta a coleta. Sem isso, o risco não é “invalidar”, é reduzir confiança no dado.
2) A combinação telefone + digital aumenta viés?
Pode aumentar ou reduzir dependendo de como recrutam e compensam. Por isso a segmentação por canal e a medição por estrato são tão importantes. Cotas ajudam, mas não resolvem propensão a responder.
3) Como uma margem de erro de 2 pontos pode “sumir” na prática?
Quando há viés sistemático (cobertura, recusa, operacional). A margem de erro não cobre esses fatores; ela cobre apenas variabilidade amostral sob pressupostos.
4) Que tipo de métrica eu pediria para comprovar qualidade do pipeline com AI?
Taxa de conclusão, taxa de abandono, taxa de inconsistência, distribuição de respostas por canal e estrato, e percentual de fallback para decisão humana quando a confiança da IA for baixa.
5) O que eu faria para evitar “drift” no questionário de 18 a 22 de julho?
Congelar regras por versão, travar o comportamento do fluxo por release, e registrar versão/canal em cada entrevista. Drift é silêncio; log é prevenção.
Fechando: o retrato eleitoral chega, mas a engenharia define a confiabilidade
O Abril.com.br trouxe o registro, o cronograma e o método híbrido da Real Time Big Data no TSE. Para quem programa, a leitura certa não é só “quem lidera”, mas “como o dado é produzido”. Se o pipeline híbrido com AI for bem governado (versionado, auditável, com métricas por canal e fallback), ele pode aumentar consistência e reduzir ruído. Se for caixa-preta, você ganha velocidade e perde rastreabilidade.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.