Tour de Algoritmos

Uma proposta nasce de três jeitos: o corretor salva o cliente no iList (o CRM da imobiliária), o corretor cria a proposta na clave em cinco perguntas, ou o comprador chega sozinho pelo site. Cada porta fala um dialeto diferente — campos, formatos e qualidade de dado.

Primeiro, normalizamos. CPF só com dígitos e com os dígitos verificadores conferidos, celular em formato internacional, endereço padronizado. O que não passa na validação não entra no processo: volta com o motivo.

Depois, resolvemos entidades. O mesmo comprador pode chegar por duas portas, e a mesma pessoa pode ser compradora e corretora. Comparamos atributo a atributo, com pesos, e decidimos: mesma pessoa, pessoa diferente ou dúvida para a Ops.

Por fim, a confirmação. O celular é confirmado com um código de seis dígitos; os dados do CPF são conferidos com as fontes de identidade uma vez por pessoa. Se não baterem, uma pessoa ajuda — o algoritmo não insiste.

Evita propostas duplicadas para a mesma pessoa e o mesmo imóvel.

O comprador fala com a assistente por texto ou por áudio: manda a foto de um documento, pergunta “e aí?”, reclama, pede para falar com alguém. Cada mensagem é transcrita, se for áudio, e vira texto com o contexto da proposta.

Um classificador estima a intenção: documento, status, dúvida, pedido de uma pessoa, fora do escopo. A saída não é uma resposta, é uma distribuição de probabilidade — e é isso que permite saber quando duvidar.

O roteamento usa a confiança. Se a maior probabilidade passa do limiar e a margem sobre a segunda é grande, a assistente responde. Se não, a conversa vai para a Ops, com o contexto. Pedir uma pessoa leva sempre à Ops, por regra.

O que a assistente envia também é classificado. Mensagens A e B saem sozinhas; C — má notícia, terceira cobrança, qualquer frase fora dos modelos — só sai com aprovação de uma pessoa da Ops; D nunca sai. A classe vem de uma regra determinística, não do modelo.

O comprador fotografa um documento e manda pela área web ou pelo WhatsApp. É o momento em que ele decide se confia na clave: ver o primeiro documento conferido em minutos, sem correr atrás de ninguém.

Primeiro, um modelo de visão reconhece o tipo de documento: holerite, extrato, comprovante de endereço. “Outro documento” é uma resposta legítima — melhor do que forçar um encaixe.

Depois, a leitura: OCR e modelos de visão e linguagem extraem os campos — nome, CPF, valores, datas, emissor. Cada campo vem com a sua própria confiança, porque um valor ilegível não deve contaminar um nome nítido.

A validação cruzada confronta o que foi lido com o que a proposta diz: o nome bate? o documento está dentro da validade? o valor é compatível? É aqui que um documento perfeitamente legível ainda pode ser recusado.

No fim, uma confiança combinada e um dos cinco desfechos: parece certo, ilegível, vencido, dado não bate ou outro documento. Acima do limiar o modelo confere sozinho; abaixo, o caso vai para a mesa da Ops.

O modelo é probabilístico; a política é determinística. O motor de decisão confronta a evidência com um limiar: acima dele o modelo confere sozinho, abaixo o documento vai para a mesa da Ops. É por isso que a mesa só vê o que ficou incerto — e que pode, um dia, ficar vazia.

Para o limiar valer, a probabilidade precisa estar calibrada: quando o modelo diz 90%, ele deve acertar cerca de 90% das vezes. Medimos isso comparando confiança e acerto por faixa.

E onde pôr o limiar? Revisar custa c_r; aceitar um erro custa c_f. Aceitar vale a pena enquanto o custo esperado do erro for menor que o da revisão. O mínimo da curva de custo total sai direto dessa conta.

O limiar não é um número eterno. Ele muda por tipo de documento, por banco e por versão do modelo — e a auditoria por amostragem, no capítulo 8, verifica se ele ainda se sustenta.

Mexa nos controles ao final deste capítulo e veja o limiar ótimo se deslocar.

Com o consentimento do comprador, a clave envia a proposta aos três bancos escolhidos ao mesmo tempo. Cada envio é uma tarefa independente, com estado próprio: criado, em análise, pediu documento, respondido, atrasado.

Integrações falham: o portal do banco cai, a resposta demora. A política é tentar de novo com espera crescente e um pouco de aleatoriedade, para que milhares de propostas não batam à porta do banco no mesmo segundo.

Reenviar não pode duplicar. Cada envio carrega uma chave de idempotência derivada da proposta e do banco: se o mesmo pedido chegar duas vezes, o banco enxerga um só.

Quando um banco pede um documento, só aquele envio para; os outros seguem. Cada banco tem um prazo típico de resposta: passado o prazo, o envio vira “atrasado” e a clave cobra o banco, de forma visível para quem espera.

Os bancos respondem em PDF, e-mail, portal ou telefone. A clave transforma cada resposta em campos comparáveis — valor financiado, prazo, taxa, parcela, CET, total pago — sempre como o banco mandou. Ela não inventa condição e não escolhe o banco pelo comprador.

Antes de mostrar qualquer oferta, uma validação aritmética: a parcela informada bate com a taxa e o prazo? Se diverge além da tolerância, a resposta vai para a Ops classificar em vez de chegar ao comprador.

No sistema Price, a parcela é constante, mas a composição muda: no começo, quase tudo é juro; com o tempo, a amortização cresce. O total pago e o CET — a taxa que iguala o valor líquido recebido ao fluxo de parcelas — saem dessa conta e são resolvidos numericamente.

O comprador compara as ofertas lado a lado e escolhe. A clave mostra o que cada banco mandou, retira os envios não escolhidos e, se a avaliação do imóvel vier abaixo, oferece voltar a outro banco.

Os valores exibidos são fictícios, como no restante do exemplo.

Escolhido o banco, começa a etapa Contrato: vistoria, assinatura pelo link do banco, ITBI, exigências do cartório, registro e entrega da chave. Quase nada disso acontece dentro da clave — o banco decide no portal dele, o cartório tem o próprio ritmo.

Cada passo é um estado numa máquina de estados, com dependências: a assinatura só vem depois da vistoria, e o registro só depois do ITBI e das exigências. Toda mudança de estado emite um evento, e é o evento que avisa cada ator.

O prazo da etapa é o caminho crítico: o caminho mais longo no grafo. Saber qual ramo está no caminho crítico diz onde gastar atenção — atrasar o ITBI dentro da folga não muda a data da chave; atrasar o cartório muda.

O que a clave faz fora da tela é transformar cada exigência do cartório em uma tarefa com dono e prazo, cobrar o banco de forma visível e deixar pronta, em cada lugar, a mensagem certa para quem precisa agir.

A Ops é um time pequeno de analistas, cada um com até 200 propostas. A mesa mostra só o que o modelo e a assistente não decidiram sozinhos. O analista vê o que o modelo leu, escolhe um de cinco rótulos e confirma. Sem texto livre.

Cada rótulo faz duas coisas: dispara a consequência — um pedido ao comprador, uma proposta parada — e vira exemplo de treino, depois de validado. Quando há mais casos que gente, os mais incertos vêm primeiro.

Acima do limiar o modelo decide sozinho — então, como saber se ele continua certo? Por amostragem: a Ops revê uma amostra do dia das decisões automáticas. Discordância vira rótulo, e a taxa de discordância é a métrica que precisa cair.

Tamanho da amostra para ver, com confiança C, ao menos um erro de taxa p.

No fim, o que importa é a economia da operação: quantas intervenções por 100 propostas, quantos falsos aceites, quanto custa cada contrato concluído. Medimos por banco, por tipo de documento, por versão do modelo e por faixa de confiança.

Referências de desenho, não resultados medidos: o ganho de produtividade ainda precisa ser demonstrado.

Cada mudança de estado de uma proposta emite um evento: documento.enviado, documento.conferido, proposta.documentos_conferidos, consentimento.registrado, envio.criado, envio.respondido, chave.entregue. Nenhuma tela sincroniza outra — é o evento que avisa corretor, comprador, Ops e imobiliária.

O coração do sistema é um motor de workflow durável, não o modelo de linguagem. Ele guarda o estado da proposta, controla o que pode acontecer e retoma de onde parou quando um serviço externo falha. Os agentes são trabalhadores especializados, com ferramentas e limites próprios.

Em volta, camadas: experiência, agentes, workflow, inteligência, integração, confiança e dados. A regra de quem vê o quê — o corretor e a imobiliária nunca veem o conteúdo dos documentos, o CPF completo nem as ofertas — vive em código, não em tela.

O estado de uma proposta é uma função dos seus eventos: reproduzir a história reconstrói qualquer momento. É isso que dá rastreabilidade de ponta a ponta — e permite, depois, auditar e aprender.