Onde um modelo NLI ajuda em um assistente de reuniões: três testes, duas rejeições

Charoiteai, desenvolvedor do assistente local de reuniões Charoite, contou onde um modelo NLI funciona e onde ele incomoda. Testou em cinco pontos — dois sobreviveram.

Em julho, ele passou a mesma ata de reunião quatro vezes pelo modelo de resumo automático e obteve 39 afirmações diferentes, das quais 32 apareceram em apenas uma execução. Ele queria uma ferramenta que apontasse onde as execuções se contradizem. Escolheu o mDeBERTa-v3-base-xnli-multilingual-nli-2mil7: multilíngue, treinado com 2,7 milhões de pares, 1,1 GB em formato ONNX, carrega em um segundo e meio.

Primeiro ponto: repetições no feed em tempo real — funciona todos os dias

Em uma reunião longa, o modelo de resumo só vê 800 caracteres de texto recente, então repete o que já foi dito com outras palavras. O NLI detecta duplicatas por lógica bidirecional: é duplicata quando A decorre de B e B decorre de A simultaneamente. Um esclarecimento (só em uma direção: "orçamento aprovado" decorre de "orçamento aprovado até o fim do ano", mas não o contrário) permanece no feed. Uma contradição não passa em nenhuma direção.

O esquema é simples: uma nova afirmação é comparada com as 16 anteriores via difflib com limiar de 0,3 (deliberadamente baixo para não filtrar antes da hora). Os pares que passam vão para o modelo nas duas direções. Se ambas as probabilidades forem ≥ 0,8, a afirmação é descartada como duplicata; caso contrário, permanece. O limiar é 0,8, e não o padrão de 0,75, porque uma repetição é irritante, mas perder um fato novo é pior. Cada chamada leva dezenas de milissegundos, e a maioria dos pares nunca chega ao modelo graças ao pré-filtro.

Este é o único ponto em que o NLI funciona sem problemas há três meses consecutivos. Não é perfeito: numa reunião de 29 de setembro, o mesmo tema voltou cinco vezes em 8 minutos sem adicionar nada novo. O mecanismo já está anotado — é a próxima tarefa.

Segundo ponto: contradições em atas — rejeitado

Ele testou com o arquivo histórico: 14 reuniões, 51 itens de ata, 1.192 pares para análise. Dos 76 pares que passaram pelo pré-filtro, o modelo apontou 30 como contradições. Quase todos eram falsos. O motivo é o tamanho: o item médio de ata tem 138 caracteres, 69% passam de 120. Uma frase como "É necessário iniciar contato direto com o responsável para esclarecer os princípios gerais de conexão, sem passar pelas etapas intermediárias de aprovação" é, na verdade, três ideias em um só parágrafo. Em qualquer par de parágrafos assim sempre haverá uma palavra em comum e algo que pareça um conflito.

A solução é duas ordens de magnitude mais barata: afirmações curtas (até 60 caracteres) com um objeto nomeado, junto com números e datas, são verificadas diretamente na transcrição por busca. Na mesma execução, esse tipo de verificação encontrou uma invenção entre dez afirmações: um lançamento marcado para "17/08", quando 17 de agosto nunca foi mencionado, nem em números nem por extenso.

Terceiro ponto: revisão noturna de núcleos — desativada

Núcleos são temas que duram mais do que uma reunião. Cada núcleo tem uma essência, uma cronologia, pessoas e decisões. O problema: o mesmo tema é chamado de formas diferentes. Um exemplo do documento de arquitetura no repositório: configurar o acesso à API e obter o token são o mesmo trabalho, mas dois núcleos com duas cronologias incompletas.

A revisão funcionava em duas etapas: o bge-m3 reunia candidatos (similaridade de cosseno a partir de 0,55), e então o NLI julgava a essência deles nas duas direções com quatro resultados possíveis: duplicata (ambas as direções acima de 0,8 — candidata a fusão); possível duplicata (0,72–0,8 — marcada); aninhamento (uma direção acima de 0,85, a outra abaixo de 0,5 — um tema estreito dentro de um amplo); fronteira (ambas acima de 0,45 — temas vizinhos). Um núcleo com três aninhamentos era considerado um hub e não era tocado.

Em agosto estava indo bem: 284 núcleos ativos, 40.186 pares, 1.806 passaram pelo pré-filtro, revisão concluída em 6 minutos. Em outubro, havia mais de 1.000 núcleos. A revisão de 27 de setembro bateu no teto noturno após 3,5 horas e deixou 824 núcleos para as noites seguintes. Os dossiês (resumos por tema) não foram compilados em oito de doze noites.

Ele analisou dez pares aleatórios de alta confiança que a revisão estava prestes a fundir. Zero eram duplicatas reais. Um era discutível.

A confiança dos pares falsos: entre 0,93 e 1,00. A explicação: nem todos os núcleos têm uma essência própria. Quando não têm, a revisão recorre a um status genérico como "Discussão de requisitos e características".

Dois temas de trabalho diferentes com o mesmo status genérico — e o NLI diz: essas frases decorrem uma da outra. Sim, decorrem, porque é exatamente a mesma frase. O modelo funcionou corretamente, mas é um erro de dados, não do modelo.

As marcações de possível duplicata se acumularam até 239 no grafo, zero revisadas: ninguém abriu a nota de serviço com as marcações.

Em 5 de outubro, ele desativou com uma única linha na configuração. Nunca ativou a fusão automática, mas agora está claro que ela teria juntado temas de trabalho diferentes — uma sugestão durante uma reunião mostraria o status da tarefa de outra pessoa. O backup de fusão dura uma semana e ninguém o revisa — na prática, é irreversível.

Quarto ponto: filtro antes do raio — não ajudou

O botão ⚡ (resposta rápida) é ativado por uma pergunta recém-feita na chamada. Um filtro estrutural encontra um candidato no feed, e um modelo local escreve a resposta em segundos. Mas, às vezes, o candidato não é realmente uma pergunta: alguém repetiu algo, pensou em voz alta ou cortou a frase no meio. O modelo responde "não vejo uma pergunta", e o tempo é perdido.

Ele queria um juiz mais barato antes do modelo, sem ajuste fino: duas hipóteses afirmativas (hipóteses com negação funcionam piores no modelo): "O interlocutor está fazendo uma pergunta e espera uma resposta" e "O interlocutor está repetindo, pensando em voz alta ou cortando uma frase". Uma cascata: se há confiança, decide por conta própria; se não, passa para o modelo.

Em modo sombra: o juiz calculava em paralelo sem decidir nada, só registrando no log. Quatro reuniões, 117 falas. O modelo respondeu a 115, recusou em 2 — isso é 1,7%, o teto do que o filtro poderia economizar mesmo no melhor cenário.

Mas o NLI estava longe de ser perfeito. Precisão em relação ao gabarito: 55,6%, quase cara ou coroa. Má calibração — confiante com bem mais frequência do que estava certo. Tempo mediano de chamada: 99 ms. Ele testou diferentes limiares:

| Limiar | Filtrado | Vazias removidas | Perguntas perdidas | |--------|----------|---------------------|------------------------| | 0,60 | 31,6% | 1 de 2 | 31,3% | | 0,70 | 17,9% | 1 de 2 | 17,4% | | 0,80 | 9,4% | 0 | 9,6% | | 0,90 | 0 | 0 | 0 |

Com qualquer limiar que filtre algo, o sistema perde perguntas reais dezenas de vezes mais do que remove vazias. Ele havia escrito a regra de encerramento uma semana antes da medição: se as vazias forem menos de 15%, encerrar o tema. Deu 1,7%. Em 6 de outubro, desativou o modo sombra.

O que quebrou

O mais desagradável foi uma falha silenciosa. Na primeira vez: os modelos ficam na raiz de dados, mas o código procurava o modelo NLI ao lado de si mesmo, na raiz de código. No repositório do próprio desenvolvedor, as duas raízes coincidem, então o defeito era invisível. Em uma instalação em que os dados ficam separados, o modelo não estava naquele caminho. A regra vigente era: sem modelo no disco, a deduplicação é desativada. Sem erro, sem aviso, o feed simplesmente voltava a repetir. Perceberam não pelo feed, mas durante uma revisão. Aconteceu duas vezes. Agora o caminho é calculado no momento da chamada.

A segunda vez foi na revisão de núcleos, também duas vezes consecutivas. O juiz carregava, mas não conseguia julgar, e a revisão contava a execução como concluída: não encontrava pares, avançava a marcação, e os núcleos novos ficavam fora da revisão por completo. Um zero na revisão significava "semelhante" em vez de "nada para julgar". Agora, uma falha do juiz é uma exceção, não um zero.