Bellacosa Mainframe e a base rate neglect

☕ Um Café no Bellacosa Mainframe

Base Rate Neglect: Doctor Who, COBOL e o Dia em que um Alerta Assustador Fez Todo Mundo Esquecer os Números

Uma viagem pela TARDIS dos incidentes para entender por que um caso convincente pode nos fazer ignorar a frequência real dos eventos

09:07.

War Room.

Um alerta aparece.

SECURITY ALERT

POSSIBLE FRAUD
CONFIDENCE: HIGH

Silêncio.

O gerente pergunta:

— Fraude?

O analista responde:

— Parece.

O especialista de segurança olha.

— Muito suspeito.

Nosso jovem programador COBOL pergunta:

— Quantas transações fraudulentas normalmente existem?

Silêncio.

— Como assim?

— Quantas dessas transações, no total, costumam realmente ser fraude?

O especialista responde:

— Pouquíssimas.

— E quantos alertas desse tipo o sistema gera?

Outro silêncio.

O Doctor, que naturalmente escolheu esse exato momento para estacionar uma cabine policial azul entre dois racks de produção, sai da TARDIS.

VWORP.

Ele olha para o alerta.

Depois para a equipe.

— Qual é a chance de uma transação qualquer ser fraudulenta antes desse alerta?

O gerente cruza os braços.

— Mas o sistema disse “high confidence”.

O Doctor sorri.

— Não foi isso que perguntei.

Pausa.

— Eu perguntei qual era a probabilidade antes de vocês verem esse sinal.

Nosso programador começa a sorrir.

Porque acabou de perceber que estamos diante de outro monstro.

Base Rate Neglect

Ou:

Negligência da Taxa Base

A tendência de dar peso demais a uma informação específica e chamativa e peso de menos à frequência básica com que aquele evento acontece no mundo real.

🌀 Onde estamos na nossa TARDIS dos incidentes?

Já encontramos muita coisa.

Swiss Cheese Model nos ensinou que várias barreiras imperfeitas podem falhar juntas.

Normalization of Deviance mostrou como desvios viram rotina.

Hindsight Bias explicou por que tudo parece óbvio depois.

Confirmation Bias mostrou como buscamos aquilo que confirma nossa teoria.

Anchoring Bias mostrou o peso exagerado da primeira informação.

Groupthink revelou como consenso pode sufocar análise.

Authority Gradient mostrou como hierarquia pode transformar dúvida em silêncio.

Plan Continuation Bias explicou por que continuamos planos que já perderam sentido.

Alarm Fatigue mostrou como excesso de sinais destrói atenção.

Automation Bias mostrou como confiamos demais nas máquinas.

Drift Into Failure mostrou como sistemas inteiros derivam lentamente para a borda.

Diffusion of Responsibility mostrou como todos podem ver e ninguém agir.

Normalcy Bias mostrou como esperamos que tudo volte ao normal.

Survivorship Bias ensinou a procurar quem desapareceu da amostra.

Agora precisamos olhar para outra coisa:

o denominador.

Porque números isolados contam histórias muito convincentes.

Mas sem contexto podem nos enganar completamente.

🧠 O que é Base Rate?

Antes de falar em negligência da taxa base, precisamos entender a taxa base.

Imagine:

em um banco, de cada 1 milhão de transações:

999.900 são legítimas
100 são fraude

Então a taxa base de fraude é:

100 / 1.000.000

Ou:

0,01%.

Muito baixa.

Agora aparece um sistema de detecção.

Ele identifica padrões suspeitos.

Excelente.

Mas mesmo um sistema muito bom pode gerar falsos positivos.

Se você esquece que fraude é extremamente rara, pode olhar para qualquer alerta positivo e concluir:

“Provavelmente é fraude.”

Talvez não.

A taxa base importa.

🎯 O clássico problema do teste

Vamos simplificar.

Imagine uma condição rara.

Só 1 pessoa em cada 1.000 possui.

Um teste detecta corretamente 99% dos casos.

Parece excelente.

Mas também acusa positivamente 1% das pessoas saudáveis.

Agora testamos 100.000 pessoas.

Aproximadamente:

DOENTES: 100
SAUDÁVEIS: 99.900

Dos 100 doentes:

99 testam positivo.

Dos 99.900 saudáveis:

aproximadamente 999 também testam positivo.

Então temos:

POSITIVOS REAIS:   99
FALSOS POSITIVOS: 999

Se seu teste deu positivo, a chance de realmente pertencer ao grupo raro não é 99%.

Esse é exatamente o tipo de erro produzido quando ignoramos a taxa base.

☕ Bellacosa Mainframe: “o monitor disse que é Db2”

Imagine uma ferramenta de RCA automática.

Ela diz:

POSSIBLE ROOT CAUSE:
DB2 CONTENTION

CONFIDENCE: 85%

A equipe entra em pânico.

Mas histórico mostra:

Últimos 1.000 incidentes semelhantes:

Aplicação: 510
MQ:        260
Rede:      120
Db2:        80
Outros:     30

A taxa base para Db2 é 8%.

Isso não significa que a ferramenta está errada.

Significa que sua saída precisa ser interpretada junto com o histórico.

Um sinal novo muda a probabilidade.

Mas não apaga a probabilidade anterior.

🧠 Antes e depois

Essa é a essência do pensamento bayesiano.

Antes do sinal:

temos uma probabilidade inicial.

Depois do sinal:

atualizamos.

Em linguagem simples:

não comece do zero só porque apareceu uma evidência impressionante.

O mundo já tinha uma distribuição antes.

👻 Easter Egg nº 1 — “Há um Dalek!”

Companion:

— Doctor! Um Dalek!

Doctor:

— Onde?

— Uma silhueta metálica no corredor!

Doctor olha.

— Quantas criaturas metálicas existem nessa estação?

— Muitas.

— Quantos Daleks?

— Nenhum conhecido.

— Então talvez devêssemos investigar antes de gritar “EXTERMINATE”.

É uma brincadeira, claro.

Mas é Base Rate Neglect puro.

Uma pista compatível com Dalek não significa automaticamente Dalek se Daleks forem raríssimos naquele contexto.

⚓ Anchoring Bias e Base Rate Neglect

A primeira hipótese aparece:

“Fraude.”

Isso vira âncora.

Agora a equipe esquece que 99,99% das transações são legítimas.

A evidência chamativa domina.

Base Rate Neglect frequentemente chega de mãos dadas com Anchoring Bias.

🔎 Confirmation Bias entra logo depois

A equipe acredita em fraude.

Começa a procurar:

IP diferente.

Horário incomum.

Valor alto.

Cada detalhe passa a parecer confirmação.

Mas talvez milhões de transações legítimas possuam algumas dessas características.

Sem taxa base:

um padrão comum pode parecer raro.

🤖 Automation Bias piora

A ferramenta diz:

HIGH RISK.

O usuário pensa:

então é alta probabilidade.

Mas “high risk” pode significar:

alta pontuação interna.

Não necessariamente:

alta probabilidade posterior real.

É preciso conhecer:

prevalência;
false positive;
false negative;
calibração.

Caso contrário:

interface vira oráculo.

🚨 Alarm Fatigue tem uma relação curiosa

Imagine um sistema que ignora taxa base e gera alerta para qualquer anomalia.

Resultado:

milhares de falsos positivos.

Depois:

Alarm Fatigue.

Então Base Rate Neglect pode contribuir indiretamente para o ruído.

Uma classificação ruim cria um monitoramento que grita demais.

🧀 Swiss Cheese e falsa confiança estatística

Uma barreira de detecção pode parecer excelente porque:

“99% de precisão.”

Mas 99% de quê?

Esse número precisa de contexto.

Imagine:

ataque real ocorre 1 vez em 10.000.

Detector gera 1% de falsos positivos.

Ele pode produzir muito mais falsos alarmes que detecções reais.

A barreira existe.

Mas sua efetividade operacional pode ser muito diferente da impressão inicial.

📊 Accuracy pode enganar

Imagine dataset:

99.900 transações legítimas
100 fraudulentas

Modelo burro:

“Tudo é legítimo.”

Accuracy:

99,9%.

Maravilhoso?

Não.

Fraudes detectadas:

zero.

Por isso métricas como:

precision;

recall;

specificity;

sensitivity;

existem.

Não basta um número bonito.

🧠 Base Rate Neglect em incidentes

War Room recebe um sintoma:

TIMEOUT

Primeira pergunta costuma ser:

“O que pode causar timeout?”

Muitas coisas.

Melhor pergunta:

“Nesse ambiente, o que historicamente costuma causar timeout?”

Agora temos priorização inteligente.

Não para eliminar hipóteses raras.

Mas para organizar investigação.

☕ Um exemplo prático

Últimos 500 timeouts:

Downstream lento: 250
Rede:            120
MQ:               70
Db2:              40
Outros:           20

Novo timeout.

Sem outras evidências:

downstream é um excelente ponto inicial.

Mas surge uma evidência:

PACKET LOSS: 35%

Agora probabilidade de rede sobe muito.

Isso é atualização racional.

Você usa taxa base + evidência.

🧠 O erro é escolher apenas um dos dois

Erro A:

“Historicamente sempre foi downstream, então é downstream.”

Isso pode ser Anchoring/Normalcy Bias.

Erro B:

“Tem packet loss, então esquece todo histórico.”

Isso pode ser Base Rate Neglect.

Bom raciocínio:

“Downstream era hipótese inicial mais provável, mas esse novo sinal aumenta fortemente a hipótese de rede.”

Esse é o pensamento que queremos ensinar.

🧮 Bayes sem assustar o COBOL iniciante

Você não precisa decorar fórmula para aplicar a ideia.

Pense assim:

PROBABILIDADE ANTES
+
FORÇA DA EVIDÊNCIA
=
PROBABILIDADE DEPOIS

Simples.

Se um evento é extremamente raro, uma evidência moderada talvez não seja suficiente para torná-lo provável.

Se é muito comum, uma evidência pequena pode reforçá-lo bastante.

📚 Exemplo médico

Uma doença é raríssima.

Pessoa possui um sintoma compatível.

Esse sintoma também aparece em doenças muito comuns.

Se alguém olha só para o sintoma:

pode superestimar doença rara.

Taxas base ajudam a manter proporção.

Mesma coisa em TI.

💻 O ABEND raro

Imagine:

S0C7

Normalmente em sua aplicação:

80% vêm de dados inválidos.

15% de mudança de copybook.

5% de outros motivos.

Surge novo S0C7.

Um iniciante pode começar imediatamente na hipótese mais exoticamente interessante:

corrupção de memória.

Possível.

Mas comece pela base.

Dados inválidos.

Depois evidências atualizam.

🧠 Occam não é Bayes, mas são amigos

Navalha de Occam:

não multiplique entidades sem necessidade.

Em debugging:

hipóteses simples e comuns merecem atenção.

Mas Base Rate é mais específico:

olhe para frequência histórica.

Não significa:

sempre escolha o mais comum.

Significa:

o mais raro precisa de evidência proporcionalmente forte.

👻 Easter Egg nº 2 — zebra e cavalo

Existe uma frase famosa na medicina:

Quando ouvir cascos, pense em cavalos antes de zebras.

Em mainframe:

quando ouvir:

S0C7

pense primeiro em dado inválido antes de imaginar radiação cósmica alterando um nibble no packed decimal.

Embora...

se o Doctor estiver por perto, nunca descarte completamente radiação cósmica.

🏦 Fraude bancária é um ótimo laboratório

Fraude normalmente possui baixa prevalência.

Então detecção precisa lidar com false positives.

Imagine:

10 milhões de transações.

Fraudes reais:

1.000.

Modelo marca 100.000 como suspeitas.

Detecta 900 fraudes.

Bom recall.

Mas analistas precisam verificar quase 100 mil casos.

Operationalmente:

caríssimo.

Taxa base determina a experiência real.

🔐 Segurança cibernética

Mesma coisa.

SIEM gera alerta.

EDR.

IDS.

UEBA.

Se atividades maliciosas são raras em relação ao volume total, falsos positivos podem dominar.

Por isso SOC precisa:

priorização;

correlação;

contexto;

base rate.

Sem isso:

Alarm Fatigue.

🧠 False Positive Paradox

É possível ter um detector tecnicamente muito bom e ainda assim receber mais falsos positivos que verdadeiros.

Especialmente quando evento real é raro.

Isso parece contraintuitivo.

Mas é fundamental para segurança, medicina, fraude e observabilidade.

📊 Precision responde pergunta útil

Pergunta:

“Entre os casos que o sistema marcou como positivos, quantos realmente eram positivos?”

Isso é precision.

Essa métrica é crucial quando taxa base é baixa.

📈 Recall responde outra

“Entre todos os casos realmente positivos, quantos encontramos?”

Esse é recall.

Em fraude:

você quer bom recall.

Mas se aumentar demais com muitos falsos positivos:

analistas afogam.

Trade-off.

🧠 Métricas precisam refletir custo

Um falso negativo pode ser muito caro.

Um falso positivo também.

Não existe melhor threshold universal.

Depende de:

impacto;

prevalência;

capacidade operacional;

risco.

É engenharia de decisão.

🌀 Survivorship Bias e Base Rate Neglect

Nosso capítulo anterior perguntou:

qual é o denominador?

Base Rate Neglect pergunta:

qual é a frequência real antes do caso observado?

São parentes próximos.

Survivorship Bias pode distorcer a taxa base se você só observa sobreviventes.

A taxa base que você calcula pode estar errada porque sua amostra já veio filtrada.

Excelente combinação.

🧠 Exemplo

Você calcula:

“Só 1% dos deploys falham.”

Mas banco de dados registra apenas deploys concluídos.

Rollbacks precoces não entram.

Taxa base está errada.

Agora Base Rate Neglect opera sobre base enviesada.

Nossos monstros estão formando sindicato.

🌀 Drift Into Failure e taxas-base antigas

Outro perigo.

Você usa histórico:

falha acontece 0,1%.

Mas sistema mudou:

volume 5x;

equipe menor;

arquitetura nova.

Taxa base antiga pode não valer mais.

Então:

taxas base também envelhecem.

Elas precisam ser recalibradas.

📅 Contextual Base Rate

Pergunta melhor:

não:

“Qual taxa de falha histórica?”

Mas:

“Qual taxa de falha em situações parecidas com esta?”

Exemplo:

deploy normal:

1%.

deploy na madrugada pós-migração:

8%.

Contexto muda tudo.

🧠 Segmentação

Você pode segmentar:

dia;

horário;

tipo de transação;

canal;

volume;

versão;

região.

Uma taxa agregada pode esconder comportamento.

🎯 Simpson’s Paradox no horizonte

Às vezes taxas agregadas e segmentadas contam histórias diferentes.

Isso nos leva ao famoso Paradoxo de Simpson.

Excelente tema futuro.

Mas por enquanto:

saiba que agregação pode enganar.

💻 Exemplo COBOL com files

Sistema processa dois tipos de arquivo.

Tipo A:

1 erro em 10.000.

Tipo B:

1 erro em 100.

Hoje o erro ocorreu no B.

Taxa global de erro pode parecer baixa.

Mas para B:

muito maior.

Base rate correta precisa ser específica.

🧠 “Rare but catastrophic”

Um evento pode ser raro e ainda exigir atenção enorme.

Base Rate Neglect não significa:

ignore coisas raras.

Muito importante.

Explosão de data center é rara.

Mesmo assim precisamos prevenção.

O cálculo de risco envolve:

probabilidade × impacto.

Evento raro + impacto devastador pode justificar fortes controles.

⚠️ Black Swan não é desculpa

Não diga:

“Era raro, então não precisamos considerar.”

Precisamos separar:

probabilidade;

impacto;

detectabilidade;

controlabilidade.

Segurança trabalha com tudo isso.

☕ Bellacosa Mainframe: o incidente improvável

Sysprog diz:

— Chance de dataset encher hoje é 0,01%.

Gerente:

— Então ignora.

Calma.

Se encher:

sistema para?

dados corrompem?

clientes afetados?

Quanto custa?

Taxa baixa não significa risco irrelevante.

🧠 Risk Matrix e Base Rate

Uma matriz simples:

Probabilidade baixa + impacto baixo
→ tolerável

Probabilidade baixa + impacto crítico
→ talvez controle forte

Probabilidade alta + impacto baixo
→ gestão operacional

Probabilidade alta + impacto crítico
→ prioridade máxima

Taxa base informa probabilidade.

Não decide sozinha.

🤖 IA e Base Rate Neglect

Imagine IA dizendo:

82% probability of cyberattack

Pergunte:

como foi calibrada?
qual prevalência na amostra?
qual base rate no seu ambiente?
esse 82% é probabilidade real ou score?

Score e probabilidade não são sinônimos.

🧠 Calibration

Um modelo calibrado deveria, idealmente, apresentar algo como:

de 100 casos classificados como 80%,

cerca de 80 ocorrerem.

Se não:

confidence score pode ser enganoso.

📊 Confusion Matrix

Para entender ferramenta de classificação:

TRUE POSITIVE
FALSE POSITIVE
TRUE NEGATIVE
FALSE NEGATIVE

Isso deveria ser alfabetização básica para quem usa IA, fraude, SOC ou alertas.

Não precisa ser cientista de dados.

Precisa entender o que a ferramenta pode errar.

🧠 Automation Bias novamente

Se ninguém entende confusion matrix:

“AI confidence 95%”

vira:

“95% de chance de estar certo.”

Talvez não seja isso.

Automation Bias adora estatística mal compreendida.

🪜 Authority Gradient e números

Consultor apresenta:

“Modelo tem 99,7% accuracy.”

Diretor impressionado.

Júnior pergunta:

— Qual base rate?

Sala olha.

Authority Gradient pode impedir a melhor pergunta da reunião.

Não deixe.

👥 Groupthink e números bonitos

99,7%.

Todos concordam.

Ninguém pergunta:

quantos falsos negativos?

Qual classe minoritária?

Qual dataset?

Número sofisticado pode gerar Groupthink técnico.

🎯 Pergunta Bellacosa nº 1

Quando alguém disser:

“O sistema detecta com 99%.”

Pergunte:

“99% de quê?”

Accuracy?

Precision?

Recall?

Specificity?

🎯 Pergunta Bellacosa nº 2

Quando alerta aparece:

“Quão comum é esse evento antes desse alerta?”

🎯 Pergunta Bellacosa nº 3

Quando hipótese rara domina:

“Que evidência temos forte o suficiente para superar a taxa base?”

🎯 Pergunta Bellacosa nº 4

Quando histórico é usado:

“Essa taxa ainda representa o sistema atual?”

🧪 Passo a passo contra Base Rate Neglect

Passo 1 — Defina a população

Qual universo estamos analisando?

Passo 2 — Descubra frequência histórica

Quantos eventos reais ocorrem?

Passo 3 — Segmente contexto

Mesma hora?

Mesmo serviço?

Mesmo tipo?

Passo 4 — Avalie qualidade do detector

False positive?

False negative?

Passo 5 — Atualize com evidência

Não ignore base.

Também não ignore sinal.

Passo 6 — Compare hipóteses

Qual é mais comum?

Qual é mais compatível com evidência?

Passo 7 — Considere impacto

Evento raro pode continuar crítico.

Passo 8 — Recalibre periodicamente

Sistema muda.

Passo 9 — Não trate score como probabilidade sem validar

Pergunte.

Passo 10 — Registre previsões

Depois compare com resultado real.

Isso melhora calibração humana.

📓 Incident History como ativo

Histórico de incidentes não serve só para auditoria.

Serve para criar base rates.

Exemplo:

Sintoma: Queue Growth

Últimos 200 casos:

Consumer failure: 110
Volume spike:      45
Network:           25
Db2:               12
Unknown:            8

Excelente material de triagem.

🧠 Mas não vire escravo do histórico

Taxa base é ponto de partida.

Não sentença.

Novo dado forte pode inverter completamente.

Essa é a beleza do raciocínio bayesiano.

🔎 Likelihood importa

Pergunta:

“Se fosse rede, qual a chance de vermos esse packet loss?”

Alta.

“Se não fosse rede, qual a chance de vermos?”

Baixa.

Então evidência discrimina.

Você atualiza.

💻 Debugging Bayesiano informal

Hipóteses:

A — input inválido.

B — copybook incompatível.

C — storage corruption.

Taxas históricas:

A alta.

B média.

C baixíssima.

Evidência:

erro ocorre apenas após nova versão do copybook.

Agora B sobe muito.

Perfeito.

Não precisamos fórmula.

Precisamos raciocínio.

🧠 Strong evidence beats base rate

Importante.

Evento raro + evidência muito específica = pode virar provável.

Exemplo:

corrupção de memória é rara.

Mas dump mostra alteração consistente em área específica exatamente após overwrite.

Agora temos evidência forte.

Não fique preso à base.

Base Rate Neglect é ignorar taxa base.

Não respeitá-la cegamente.

🔄 Base Rate + Evidence

Pense sempre:

O QUE ERA PROVÁVEL ANTES?
+
O QUE A NOVA EVIDÊNCIA MUDA?

Esse é o coração.

🕰️ Hindsight Bias depois

Depois que descobrimos a causa rara:

— Era óbvio!

Não.

Talvez antes fosse racional considerar causas comuns primeiro.

O fato de hipótese rara vencer não significa que era a melhor hipótese inicial.

Hindsight Bias tentará reescrever.

Não deixe.

🧠 Boa investigação pode começar errada

Você começa com hipótese mais provável.

Testa.

Descarta.

Vai para próxima.

Encontra causa rara.

Isso não significa que investigação foi ruim.

Foi racional.

O importante é:

não ficar preso.

📚 Curiosidade: estatística é uma vacina contra histórias

Seres humanos gostam de narrativas.

“Um hacker sofisticado.”

“Uma falha raríssima.”

“Um bug misterioso.”

São histórias interessantes.

“Foi input inválido de novo.”

Menos cinematográfico.

Mas frequência existe independentemente de entretenimento.

Estatística é um antídoto contra sedução narrativa.

👻 Easter Egg nº 3 — o monstro mais chato

Doctor:

— Pode ser uma entidade extradimensional.

Companion:

— E é?

Doctor:

— Não. É um cabo solto.

— Decepcionante.

— Sim.

Pausa.

— Mas produção voltou.

Às vezes o monstro mais provável é pouco interessante.

Ainda assim deve ser testado.

🧬 Regeneração organizacional

Uma organização madura contra Base Rate Neglect começa a:

registrar incidentes consistentemente;

manter denominadores;

medir false positives;

medir false negatives;

segmentar eventos;

recalibrar thresholds;

treinar leitura de métricas;

e incorporar histórico à triagem.

Ela muda:

“isso parece grave”

para:

“isso parece grave e, dado o histórico e a evidência atual, nossa hipótese principal é X.”

Muito mais forte.

📋 Checklist anti-Base Rate Neglect

Antes de concluir:

[ ] Qual é a taxa base desse evento?

[ ] Qual é a população total?

[ ] Minha amostra está completa?

[ ] O evento é raro ou comum?

[ ] Que evidência nova temos?

[ ] Essa evidência é realmente específica?

[ ] Qual é a taxa de falso positivo?

[ ] Qual é a taxa de falso negativo?

[ ] Estou confundindo score com probabilidade?

[ ] O histórico ainda representa o sistema atual?

[ ] Estou ignorando uma causa comum por uma história mais interessante?

[ ] Estou ignorando uma causa rara apesar de evidência muito forte?

As duas últimas precisam existir juntas.

📓 Diário do Doctor

Se guardar apenas algumas ideias desta viagem, guarde estas:

Base Rate Neglect acontece quando ignoramos a frequência básica de um evento e damos peso excessivo à evidência específica.

Probabilidade começa antes do alerta.

Um detector de 99% pode produzir muitos falsos positivos quando o evento real é raro.

Accuracy isolada pode enganar.

Precision e recall ajudam a entender classificadores.

Taxas históricas são pontos de partida, não sentenças.

Evidência forte pode superar uma taxa base baixa.

Contexto precisa segmentar a taxa base.

Taxas antigas podem ficar inválidas após Drift Into Failure ou mudanças arquiteturais.

Automation Bias torna scores automáticos mais perigosos quando ninguém entende seu significado.

E principalmente:

Antes de perguntar “o quanto essa evidência parece convincente?”, pergunte “o quão provável esse evento já era antes de eu vê-la?”.

🕰️ De volta à War Room

O alerta continua:

POSSIBLE FRAUD
CONFIDENCE: HIGH

Nosso programador pergunta:

— Quantas transações temos por dia?

— Dez milhões.

— Quantas fraudes reais?

— Cerca de mil.

— Quantos alertas desse modelo?

— Cem mil.

Ele pensa.

— Então precisamos olhar para precision.

O gerente pergunta:

— Você acha que não é fraude?

— Não.

— Então?

— Acho que ainda não sabemos.

Boa resposta.

Eles analisam o caso.

Valor alto.

IP novo.

Dispositivo desconhecido.

Mas existe algo mais.

O cliente acabou de trocar de aparelho.

Localização compatível.

Autenticação forte passou.

Outros sinais benignos.

O score cai após enriquecimento.

Não era fraude.

Horas depois aparece outro alerta.

Mesmo tipo.

Agora há:

IP de país incompatível;

device fingerprint estranho;

tentativa de bypass;

sequência incomum.

A hipótese muda rapidamente.

Fraude confirmada.

Nosso programador percebe.

Base Rate não impediu detectar caso raro.

Apenas impediu tratar todo alerta como certeza.

O Doctor sorri.

— Exatamente.

— Então taxa base serve para não exagerar?

— Também.

— E para quê mais?

— Para lembrar que a realidade começou antes do seu dashboard.

VWORP.

🥚 Easter Egg final

No dia seguinte aparece:

BELLACOSA.BIAS(BASE)

Dentro:

       IF ALERT = 'POSITIVE'
           PERFORM CHECK-BASE-RATE
       END-IF.

       IF EVENT = 'RARE'
          AND EVIDENCE = 'WEAK'
           MOVE 'CAUTION' TO CONCLUSION
       END-IF.

       IF EVIDENCE = 'STRONG'
           PERFORM UPDATE-BELIEF
       END-IF.

Comentário:

* START WITH THE PRIOR.
* THEN RESPECT THE EVIDENCE.

Outro:

* 99% OF WHAT?

E, naturalmente:

* BAD WOLF WAS STATISTICALLY UNLIKELY.

Nosso jovem programador ri.

Fecha o membro.

O telefone toca.

Operador:

— Temos um S0C7.

— Dados inválidos?

— Provavelmente.

— Por quê?

— Histórico.

— Excelente.

— Já fecho como dados?

— Não.

O programador abre o dump.

— Primeiro usamos a taxa base para escolher onde começar.

Pausa.

— Depois deixamos a evidência decidir onde terminar.

Em algum lugar do universo, a TARDIS desaparece.

VWORP.

No quadro fica escrita uma frase:

O caso mais chamativo não é necessariamente o mais provável — e o caso mais provável não está automaticamente certo.

Entre os dois existe investigação.

E é justamente ali que queremos morar.

☕🌀

Next stop: Availability Heuristic — quando lembramos facilmente de um desastre recente e começamos a acreditar que ele é muito mais provável do que realmente é.

Translate

quinta-feira, 10 de março de 2011