Conversation Analysis · Teste de paridade
Rodamos os dois pipelines lado a lado, na mesma conversa, no mesmo momento, sem alterar nenhum dado de cliente. Diff automático nos campos que têm resposta certa; juiz cego nos textos livres.
Os números foram colhidos antes das correções dos dois bugs de engenharia, que entraram no branch logo depois. As conclusões de qualidade não dependem deles; as de custo descrevem o estado pré-correção e precisam ser re-medidas.
O payload único não derruba a qualidade de forma geral — sentimento fica em paridade, o V4
alucina metade do que o V2 alucina e obedece muito mais às regras. Mas dois campos regridem
(heat_score e pending), e o levantamento achou três bugs — um deles fazia o V4 custar
mais caro que o V2, e já drenava dinheiro em produção pelo formFlow.
Dois desses bugs já foram corrigidos. O que ainda bloqueia o go/no-go é
uma decisão de produto: o que o heat_score deve significar.
Divergência real = 2 pontos ou mais. O piso de ruído medido é ±1: rodando o mesmo motor duas vezes na mesma conversa, ele já discorda de si mesmo em 1 ponto.
main_topic estourou o limite (o V2 estourou 5).heat_score: 17 de 30 conversas divergem de verdade. Não é ruído, não é compressão de contexto, e não se resolve mudando o prompt de lugar.pending: o V4 perde pendências. É o campo que dispara follow-up.30 conversas. O juiz cego avaliou cada par duas vezes, com as posições trocadas; vereditos que viraram ao inverter foram contados como empate.
| Campo | Igual | No ruído (±1) | Divergência real | Juiz cego |
|---|---|---|---|---|
| sentiment_score | 9 | 15 | 5 | Empate — 8 × 8 |
| heat_score | 5 | 7 | 17 | V2 vence — 13 × 3 |
| smart_tags | — | — | Jaccard 0,44 | Empate — 6 × 6 |
| dialogue_summary | — | — | — | V2 9 × V4 0 — mas 21 empates |
| main_topic | — | — | — | Empate em 25 de 30 |
| pending | — | — | — | V2 vence — 15 × 1 |
Custo médio de IA por conversa, medido dentro do processo — não lido do banco.
A análise consolidada custa US$ 0,00071 — exatamente o que o desenho prometia. O que estoura a conta é o resumo do smartContext caindo num modelo 30× mais caro.
O sumarizador pede gpt-5-nano mandando temperature: 0.3. Só que
gpt-5-nano é um modelo de reasoning e aceita apenas temperature: 1:
400 Unsupported value: 'temperature' does not support 0.3
with this model. Only the default (1) value is supported.
O sistema então caía, silenciosamente, para o gemini-3.5-flash —
US$ 1,50 por milhão de tokens contra US$ 0,05 do modelo pedido. Aconteceu em
100% das 14 conversas que dispararam resumo. O smartContext também alimenta o
formFlow, que já está em produção: essa conta já estava sendo paga.
✅ Corrigido durante o levantamento: o temperature saiu, entrou reasoning_effort.
O custo pós-correção ainda precisa ser confirmado numa nova rodada.
A resposta consolidada tinha teto de 2.048 tokens. Quando estoura, o JSON vem cortado e perde-se a análise toda — não um campo, todos. Aconteceu em 1 de 30 conversas (e em 3 de 30 quando mandamos o diálogo inteiro). O V2 não falhou nenhuma vez: lá, um estouro derruba só um grupo de campos.
✅ Mitigado por um orçamento de payload. Mas o raio de dano continua tudo-ou-nada — é a fragilidade estrutural do payload único, ele concentra o risco.
critical e user_authorization não existem como colunas na
tabela de conversas. Os dois motores pedem esses campos ao modelo, pagam pelos tokens, e o código
descarta o resultado na hora de gravar. O critical é o sinalizador de
ameaça, assédio e risco — hoje ele não chega a lugar nenhum.
Mesma conversa (cancelamento de plano por motivo financeiro), mesmo critério do gestor, entregue aos dois motores. As justificativas são deles próprios.
“a demanda é crítica e com alta probabilidade de resolução rápida”
Ancora em “resolução de demandas críticas”.
“não existe interesse em compra/upgrade/regularização; o potencial comercial é baixo”
Ancora em “potencial de conversão”.
O critério do host mistura duas coisas — potencial comercial e prioridade de atendimento. O V2 se apoia numa; o V4, na outra. Testamos as duas explicações alternativas e as duas caem: não é a compressão de contexto (o braço com o diálogo inteiro mostra o mesmo gap) e não é onde o critério está escrito (movê-lo para a instrução de sistema não resolveu). Isto é uma decisão de produto, não um bug.
heat_score Bloqueia o go/no-goDecisão de produto. Prioridade de atendimento ou potencial comercial? Enquanto o critério escrito abrigar as duas leituras, qualquer modelo vai oscilar entre elas — e então reescrever o critério do host à luz da decisão.
pendingÚnico campo com regressão consistente e sem causa identificada.
Confirma o custo pós-correção e a taxa de falha. O ferramental está versionado e é reprodutível.
Se heat e pending não fecharem, o desenho já prevê o plano B: dividir em
2 chamadas, a ~US$ 0,0004 a mais por rodada — ainda muito abaixo do teto acordado.
Os dois bugs de engenharia (temperature do sumarizador e teto de tokens)
já foram corrigidos durante o levantamento e saíram desta lista.
persist: false.
Um snapshot antes e depois provou que nenhuma coluna de análise e nenhuma tag mudou nas 30 conversas.pending, sentiment e main_topic são confiáveis; o de tip
foi descartado por inconsistência. O placar geral é indicativo, não sentença.