Eliminando alucinações em agentes virtuais baseados em LLM

Saiba como o Vonage AI Studio elimina as “alucinações” dos modelos de linguagem de grande escala (LLM) por meio de campos de raciocínio estruturado e refinamentos na ordem dos esquemas.

Introdução

Vonage AI Studio é uma plataforma de baixo código para a criação e o gerenciamento de agentes virtuais em canais de Voice e digitais, com IA operando nos bastidores para compreender os usuários e conduzir conversas inteligentes. Há muitos anos, essa plataforma vem aprimorando continuamente seu mecanismo de NLU, passando de abordagens baseadas em palavras-chave para modelos baseados em embeddings e, atualmente, para a compreensão impulsionada por LLM, à medida que novas tecnologias foram sendo adotadas ao longo do tempo.

Nossa plataforma de agentes virtuais permite que as organizações configurem agentes conversacionais capazes de detectar intenções, extrair parâmetros, validar entradas do usuário e orientar as conversas. O LLM subjacente recebe o contexto da conversa juntamente com as intenções, os parâmetros e as regras de validação configuradas, e retorna uma saída JSON estruturada que determina a próxima etapa da conversa. À medida que o sistema crescia, nos deparávamos repetidamente com “alucinações” do LLM — saídas que não se baseavam na configuração nem nas entradas do usuário —, o que causava instabilidade e comportamento imprevisível.

Esta postagem no blog explica as melhorias introduzidas para aumentar a precisão, a estabilidade e a confiabilidade dos resultados do LLM. Ela descreve os desafios enfrentados, as alterações aplicadas e como esses ajustes melhoraram a qualidade geral das respostas do sistema.

Error rate comparison before and after introducing structured reasoning: 23.7% of responses were incorrect before changes, dropping to just 1.0% after.

Compreendendo o problema: como as “alucinações” dos LLMs prejudicam os agentes virtuais

Os LLMs podem gerar respostas fluentes que parecem corretas, mesmo quando não se baseiam na configuração do sistema ou nas entradas do usuário. Isso frequentemente leva a “alucinações” — situações em que o agente aceita com confiança dados inválidos ou inventa capacidades que não existem. Os exemplos a seguir ilustram essa questão.

Exemplo 1: Quando o agente aceita uma entrada inválida do usuário

Descrição do problema:

O ID da reserva é definido para seguir um formato rígido:

3 letras maiúsculas seguidas de 3 dígitos.

Nesse cenário, o agente não consegue fazer valer essa regra, enquanto o usuário fornece apenas duas letras do ID, em vez de três

Conversa:

Usuário: Cancelar minha reserva

Agente: Para dar andamento ao cancelamento, vou precisar do seu número de reserva. Você poderia me fornecê-lo, por favor?

Usuário: its ab1234

Agente: Vejo que o número da sua reserva é AB1234. Está correto?

Nesse caso, o agente normaliza incorretamente e confirma um valor inválido, em vez de fazer valer as regras de formatação definidas.

Exemplo 2: Intenções alucinatórias e parâmetros que não existem

Descrição do problema:

O sistema não inclui uma função para obter resultados de exames de sangue, nem define nenhum parâmetro chamado ID para tal fluxo, mas o LLM ainda assim imagina que essa funcionalidade e esse parâmetro existam.

Conversa:

Usuário: Gostaria de receber os resultados dos meus exames de sangue

Agente: Sim, posso localizar os resultados dos seus exames de sangue recentes. Por favor, apresente seu documento de identidade para que eu possa prosseguir.

O agente inventa tanto uma funcionalidade suportada quanto um parâmetro obrigatório, criando uma interação enganosa que pode afetar seriamente a confiança do usuário.

Os LLMs frequentemente precisam gerar respostas utilizando informações de diferentes partes do prompt, como instruções do sistema, entradas do usuário e regras específicas da tarefa. Quando esse contexto está disperso, é inconsistente ou depende de dados dinâmicos do usuário (como formatos de parâmetros que mudam), é mais provável que o modelo cometa erros.

Por que ocorrem alucinações: principais causas subjacentes

Para entender melhor por que essas falhas ocorrem, podemos dividi-las em várias causas subjacentes que surgiram repetidamente durante nossa análise.

Causa nº 1: Confusão decorrente de um contexto complexo ou misto

Os LLMs podem não conseguir conectar todas as peças necessárias corretamente. Entre os problemas mais comuns estão:

• Seleção da intenção errada do usuário.

• Aplicação incorreta da validação.

• Gerar resultados que contradizem análises anteriores ou imaginar instruções ou formatos de parâmetros que não existem.

Quanto mais complexa e fragmentada for a instrução, maior será a probabilidade de essas questões surgirem.

Causa nº 2: O raciocínio invisível leva a falhas ocultas

Os LLMs geram texto passo a passo, mas seu raciocínio permanece interno. Se eles fizerem uma suposição errada logo no início, o resultado final estará incorreto, sem qualquer explicação visível. O ajuste do prompt, por si só, não é suficiente para corrigir isso. A menos que o modelo seja forçado a mostrar seu raciocínio, as alucinações não podem ser rastreadas nem evitadas

Causa nº 3: Equilíbrio entre o controle e a capacidade de raciocínio do modelo

As aplicações do mundo real exigem saídas estruturadas e previsíveis que possam ser analisadas ou executadas. Ao mesmo tempo, pesquisas mostram que restrições rígidas de saída, como a imposição de consistência de formato, podem suprimir a capacidade de raciocínio do modelo e reduzir a precisão da tarefa. Encontrar o equilíbrio entre controle e flexibilidade é fundamental, mas ainda representa um desafio a ser superado. Esse equilíbrio é especialmente relevante em ambientes corporativos, onde a confiabilidade e a execução segura são tão importantes quanto a criatividade do modelo.

A solução: Estruturação e ordenação do raciocínio dos LLM para resultados confiáveis

1. Orientação de LLMs por meio de campos de raciocínio auxiliares

Para evitar que os LLMs se desviassem do rumo, foi necessário mais do que apenas ajustar os prompts. Tivemos que mudar a forma o modelo aborda a geração de uma resposta desde o início. Em vez de deixar o LLM pular direto para uma resposta, agora o orientamos a raciocinar sobre o problema passo a passo, usando campos estruturados, antes que ele produza qualquer saída que o sistema realmente utilize.

Originalmente, o esquema de resposta do LLM incluía apenas campos operacionais, que eram pós-processados pelo sistema ou devolvidos diretamente ao usuário. Para fortalecer o raciocínio do modelo e concentrar sua atenção nas instruções mais críticas do prompt do sistema, expandimos o esquema para incluir campos de raciocínio explícitos e estruturados que devem ser gerados primeiro.

Esses campos de raciocínio são internos ao mecanismo do agente e nunca são expostos aos usuários finais. Eles não são utilizados diretamente pelo sistema. No entanto, ao exigir sua presença, incentivamos o modelo a primeiro analisar o contexto, identificar restrições-chave e extrair sinais relevantes antes de produzir o resultado final acionável. Na prática, isso transforma o raciocínio antes oculto em dados estruturados e inspecionáveis, melhorando significativamente a confiabilidade do resultado.

A seguir, apresentamos exemplos de “antes e depois” que demonstram o impacto dessa mudança.

2. Ordenação do esquema: uma pequena mudança com grande impacto no comportamento dos LLMs

À primeira vista, reordenar campos JSON parece algo sem importância, já que o JSON não possui uma noção semântica de ordem. No entanto, os LLMs não interpretam o JSON estruturalmente. Eles o geram como texto simples, um token de cada vez, com base em tudo o que veio antes.

Por isso, a ordem dos campos é importante. Os campos iniciais moldam o contexto interno do modelo e sua trajetória de raciocínio, enquanto os campos gerados posteriormente são mais suscetíveis a desvios ou inconsistências. Ao colocar os campos de raciocínio logo no início do esquema e controlar cuidadosamente a ordem geral dos campos, orientamos o modelo a “pensar antes de agir”.

Essa pequena mudança estrutural tem um efeito surpreendentemente grande. O modelo é levado a analisar primeiro as entradas e as restrições e, só então, produzir os campos operacionais dos quais o sistema depende. Reorganizar o esquema e introduzir campos de raciocínio explícitos ajuda a alinhar o processo de geração do modelo com as expectativas reais do sistema, resultando em saídas mais consistentes e previsíveis.

Exemplo 1 aprimorado: Como aplicar formatos de parâmetros de maneira eficaz

Conversa:

Usuário: Cancelar minha reserva

Agente: Para dar andamento ao cancelamento, vou precisar do seu número de reserva. Você poderia me fornecê-lo, por favor?

Usuário: its ab1234

Agente: O ID da reserva deve conter 3 letras seguidas de 3 Numbers. Por favor, forneça um ID de reserva válido.

O que mudou:

• O agente não normaliza nem confirma mais dados inválidos

• As regras de formatação são rigorosamente aplicadas

• O usuário é orientado a corrigir a entrada antes que o fluxo continue

Exemplo 2 aprimorado: Bloqueio de intenções e parâmetros alucinados

Conversa:

Usuário: Gostaria de receber os resultados dos meus exames de sangue

Agente: Desculpe, não posso acessar resultados de exames médicos nem solicitar identificação para essa ação. Posso ajudá-lo a gerenciar suas consultas e, para quaisquer outras solicitações, posso encaminhá-lo diretamente para a clínica.

O que mudou:

• O agente não inventa mais recursos sem fundamento

• Não são solicitados parâmetros indefinidos (como “ID”)

• A resposta está alinhada com as capacidades reais do sistema

E se você está se perguntando como isso funciona nos bastidores:

Comparação: Esquema propenso a alucinações x Esquema consciente do raciocínio

Antes do esquema de resposta JSON (propenso a alucinações)

{
  "detected_intent": {
    "id": null,
    "name": null
    
  },
  "generated_answer": 
  {
    "answer": "Yes, I can locate your recent blood test results. Please provide your ID so I can proceed."
    
  }
}

Esquema de resposta JSON (com campos auxiliares de raciocínio)

{
  "detected_intent": {
    "id": null,
    "name": null
    
  },
  "generated_answer": {
    "evidence_from_prompt": "Supported intents: Book Appointment Reschedule Appointment, Cancel Appointment, Manage Appointments."
    "intents_i_am_familiar_with": [
      "Book Appointment",
      "Reschedule Appointment",
      "Cancel Appointment",
      "Manage Appointments"
    ],
    "out_of_scope_request": true,
    "answer": "Sorry, I’m not able to retrieve medical test results or request identification for this action. I can help you manage your appointments, and for any other requests, I can route you directly to the clinic."
  }
}

Ao adicionar os novos campos de raciocínio: evidence_from_prompt, intents_i_am_familiar_with, out_of_scope_request, o LLM é obrigado a analisar a entrada do usuário e a configuração antes de produzir a resposta final. Isso força o modelo a refletir sobre as restrições, compreender os limites do cenário e fundamentar sua resposta em evidências explícitas, resultando em respostas mais claras, precisas e controladas.

Validação de parâmetros: refinamento do esquema para garantir a precisão das entradas do usuário

Antes do esquema de resposta JSON (resposta primeiro, análise depois)

{
  "generated_answer": {
    "answer": "I see that your booking ID is AB1234. Is that correct?",
    "answer_refer_to_parameter_id": "Booking_id",
    
  },
  "message_content": "its ab1234",
  "parameters": [
    {
      "parameter_id": "Booking_id",
      "parameter_value": "AB1234",
      
    }
    ]
}

Após (Ordem de alteração e campos de justificativa)

{
  "user_messages_analysis": {
    "message_content": "its ab1234",
    "current_intent": "Cancel_Reservation",
    "parameters": [
      {
        "parameter_id": "Booking_id",
        "parameter_value_format": "3 letters followed by 3 numbers (e.g., ABC123)",
        "parameter_value_format_regex": "^[A-Z]{3}[0-9]{3}$",
        "parameter_extracted_part": "ab1234",
        “simulate_regex_execution”:false
        
      }
      ]
    
  },
  "generated_answer": {
    "evidence_from_prompt": "Booking_id format: 3 letters followed by 3 numbers (e.g., ABC123).",
    "answer": "The booking ID should contain 3 letters followed by 3 numbers. Please provide a valid booking ID.",
    "answer_refer_to_parameter_id": "Booking_id",
    
  }
}

Juntos, esses campos exigem que o modelo valide o parâmetro extraído, verifique se ele está de acordo com o formato esperado e declare explicitamente se o valor é aceitável antes de produzir a resposta final. Isso garante que a resposta esteja totalmente fundamentada nas etapas de raciocínio do modelo e evita casos em que o LLM confirme com segurança um parâmetro inválido ou dê continuidade à conversa com base em suposições incorretas.

Ficamos satisfeitos com os resultados dessas ações, mas continuamos preocupados com possíveis desvios na validação do formato dos parâmetros. Para resolver isso, introduzimos uma camada de validação mensurável que monitora as taxas de extração e identifica os casos em que o LLM ainda interpreta incorretamente as regras de formato da linguagem natural.

Aplicação de formatos precisos de parâmetros com validação por expressões regulares

A adição de parâmetros de raciocínio auxiliares e a reordenação do esquema trouxeram melhorias significativas. No entanto, buscávamos atingir mais dois objetivos:

1. alcançando uma precisão próxima a 100% na aplicação do formato dos parâmetros, e

2. obter um monitoramento eficaz da produção para detectar quando for necessário realizar ajustes adicionais.

Para apoiar esses objetivos, utilizamos um fluxo de validação em várias etapas.

Etapa 1: O LLM gera uma expressão regular a partir da descrição

Conforme explicado na seção anterior, parte dos campos de raciocínio auxiliar exige que o LLM produza:

• parameter_value_format: Uma descrição legível para pessoas

• parameter_value_format_regex: Um padrão de expressão regular gerado a partir da descrição em texto livre

• simulate_regex_execution: A avaliação do LLM sobre se o valor extraído atende ao padrão da expressão regular.

Isso obriga o LLM a traduzir a linguagem natural para um formato que possa ser verificado por máquina.

Etapa 2: O LLM valida sua própria expressão regular (simulação)

Como parte de seu raciocínio, o modelo responde "simulate_regex_execution": true | false, indicando se ele acredita que que a expressão regular funciona. Isso já aumentou significativamente a precisão.

Etapa 3: A verificação final da expressão regular no lado do sistema garante a precisão

Para garantir a precisão, após receber a resposta do LLM, foi adicionada outra camada de verificação: o sistema reexecuta de forma independente a expressão regular gerada a partir do campo `parameter_value_format_regex` (com medidas de segurança para evitar padrões inseguros). Se a expressão regular não corresponder, mesmo que o LLM tenha indicado que deveria, o agente rejeita o valor e orienta o usuário a corrigi-lo.

Essa abordagem híbrida, que combina o raciocínio de LLMs com a validação programática, resultou em uma precisão quase perfeita na imposição do formato dos parâmetros e resolveu as últimas inconsistências que observamos. 

Essa validação nos fornece uma métrica mensurável para acompanhar o desempenho do LLM ao longo do tempo. Sempre que o LLM prevê que a expressão regular deve corresponder (simulate_regex_execution = true), mas a execução da expressão regular pelo sistema falha, detectamos imediatamente a discrepância. Esperamos que esses casos continuem sendo extremamente raros e, caso surja uma tendência de aumento, isso servirá como um indicador precoce de um desvio ou degradação no comportamento do LLM.

Avaliação: até que ponto as mudanças ajudaram?

Para avaliar o efeito do novo esquema de raciocínio, criamos um agente virtual para uma clínica médica e geramos 97 frases intencionalmente fora do escopo. Para todas elas, o comportamento correto era:

• intent = null, e

• A resposta gerada deve recusar educadamente o pedido

• Minimizar os casos em que simulate_regex_execution = true mas a execução da expressão regular pelo sistema falha.

Realizamos uma comparação para avaliar o impacto da introdução de campos de raciocínio:

Sem prejuízo para os verdadeiros positivos

Também validamos casos em que o agente virtual deveria detectar uma intenção. A detecção de Verdadeiros Positivos (TP) permaneceu inalterada: sem queda, sem degradação. A nova camada de raciocínio reduz as alucinações sem prejudicar a detecção correta da intenção.

Antes x Depois

Não houve casos em que o LLM tenha previsto simulate_regex_execution = true enquanto a execução da expressão regular pelo sistema falhava. Em outras palavras, todas as melhorias foram alcançadas pelo próprio LLM.

Padrões semelhantes foram observados em outras tarefas que o LLM precisa gerar.

Resultados: O que aprendemos e o que mudou

A introdução de campos de raciocínio explícitos, a reestruturação do esquema de respostas e a adição da execução de expressões regulares pelo próprio sistema tiveram um efeito positivo significativo no comportamento geral do LLM. Essas mudanças reduziram substancialmente as alucinações e as respostas fora do escopo, ao mesmo tempo em que preservaram a capacidade do modelo de identificar corretamente entradas válidas. Como resultado, as saídas do LLM tornaram-se mais consistentes, previsíveis e mais alinhadas com a configuração e a lógica pretendidas.

À medida que esse trabalho avança, continuamos investigando maneiras de tornar o raciocínio e as decisões do nosso sistema mais explicáveis, tanto para dar suporte a casos de uso do mundo real quanto para garantir uma governança robusta da IA.

A high-level overview of the reasoning structure and validation pipeline added to improve LLM response reliability and reduce hallucinations.