A função que todo mundo usa e poucos entendem direito
Você já tentou explicar algo para uma IA de chat e percebeu que ela simplesmente ignorava uma parte do que você pediu? Isso acontece porque o modelo não estava identificando corretamente quem era o interlocutor em cada segmento da conversa. O conceito de interlocutor é mais técnico do que parece quando você se depara com ele na prática de desenvolvimento de sistemas conversacionais.
o que é interlocutor
Interlocutor, no contexto de processamento de linguagem e sistemas de conversa, é a entidade — humana ou artificial — que participa ativamente de um turno discursivo. Não é apenas "quem fala". Um interlocutor pode ser o usuário final, o sistema que responde, ou até mesmo uma terceira parte citada no diálogo. A confusão comum é achar que o interlocutor sempre é a pessoa do outro lado da tela. Em fluxos multissessão, isso muda completamente. Eu trabalhei num projeto de integração de chatbot corporativo onde o cliente queria que o assistente respondesse como se fosse o setor de RH, mas também se referisse a si mesmo em terceira pessoa quando redirecionava a conversa. O problema era que o pipeline de roteamento de mensagens tratava todas as entradas como tendo o mesmo interlocutor fixo. Quando um usuário perguntava "Meu colega quer saber o benefício de saúde", o sistema respondia como se o próprio colega estivesse falando. A correção foi simples: adicionar um campo de metadata de interlocutor que distinguia entre usuário primário, usuário secundário citado, e o agente do sistema. Isso levou cerca de duas horas de ajuste no schema de entrada.
Por que a distinção importa na prática
A_IDENTIFICAÇÃO INCORRETA DO INTERLOCUTOR é uma das causas mais silenciosas de alucinação em modelos de linguagem. Quando o sistema não sabe quem está falando com quem, ele começa a atribuir intenções, tom e nível de formalidade errados. Já vi modelos responderem com tratamento excessivamente formal para um usuário que usava gírias, simplesmente porque o histórico de conversa continha mensagens de um gerente que havia intervindo antes. Em arquiteturas de multi-agentes, cada agente é tecnicamente um interlocutor, mas o modelo base precisa entender as fronteiras entre eles. Sem isso, a saída mescla vozes e o resultado fica incoerente. O framework LangChain, por exemplo, trata isso com mensagens do tipo "system", "user", "assistant" e "tool", mas mesmo assim a semântica de quem é o interlocutor real muitas vezes se perde quando você aninha chamadas de API.
Um detalhe que pouca gente considera: o interlocutor também carrega contexto pragmático. Na legislação brasileira, por exemplo, o termo "interlocutor" tem definição própria nos códigos de processo — é a parte que dialoga com o juiz ou com a outra parte no cours da ação. Se você estiver construindo um sistema jurídico automatizado, confundir o interlocutor processual com o interlocutor conversacional gera respostas legalmente imprecisas. Eu passei uma semana rastreando bugs em um prototype de análise de despachos judiciais até perceber que o modelo estava interpretando "autuado" como interlocutor quando na verdade era apenas o destinatário da intimação.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Como implementar a gestão correta de interlocutores
O primeiro passo é definir esquemas de mensagem que separaram claramente a identidade de quem fala de quem é o alvo da fala. Em vez de um campo genérico "role", use pelo menos três: speaker_id, addressee_id, e speaker_type (humano, agent, system). Isso parece excesso de verbosidade até você precisar debugar uma conversa de cinquenta turnos e descobrir que o turno 34 tinha o interlocutor errado. Se você está usando APIs de LLM diretamente, a maioria suporta parâmetros de sistema que permitem injetar instruções sobre o papel do interlocutor. No OpenAI, por exemplo, o parâmetro "system" define o comportamento do assistente, mas não necessariamente identifica quem é o interlocutor do usuário. A solução que eu adotei foi criar um intermediário que normaliza as mensagens antes de enviá-las, adicionando prompts implícitos como "Você está falando com o usuário João, que é um cliente enterprise, não um desenvolvedor." O tempo de latência cerca de 80ms por requisição, mas a qualidade da resposta melhorou drasticamente.
Para quem trabalha com RAG (retreival augmented generation), o problema do interlocutor aparece de forma ainda mais aguda. Se o sistema busca documentos e gera respostas sem considerar quem é o interlocutor, ele pode devolver informações técnicas para um usuário leigo ou simplificar demais para um especialista. Num projeto meu, a solução foi adicionar um layer de re-ranking que considerava o perfil do interlocutor — cargo, histórico de perguntas anteriores, nível de familiaridade com o domínio — antes de selecionar os chunks de contexto. Isso reduziu as taxas de insatisfação em aproximadamente 40%, segundo os logs de feedback dos usuários.
Armadilhas comuns e onde o modelo falha
O maior erro que vejo desenvolvedores cometendo é tratar o interlocutor como estático. Conversas reais têm mudanças de interlocutor. Um usuário pode delegar a pergunta para um colega. Um agente pode transferir para outro departamento. Se o sistema não atualiza o interlocutor ativo em tempo real, ele continua respondendo como se a pessoa original estivesse na conversa. Isso gera frustração imediata e perda de confiança no produto. Outro ponto cego: interlocutores anônimos ou mal definidos. Chatbots de atendimento geralmente não sabem se estão falando com um cliente existente, um lead novo ou um concorrente testando o sistema. Sem sinalizadores claros de interlocutor, o modelo tende a assumir o pior cenário — excesso de cautela e respostas genéricas. A workaround que funcionou para mim foi pedir uma triagem inicial de três campos: tipo de usuário, nível de acesso e histórico prévio. Pede demais no início? Talvez. Mas reduziu drasticamente as alucinações em comparação com deixar o modelo adivinhar.
Sistemas baseados em fine-tuning também sofrem quando o conjunto de treinamento não representa adequadamente a diversidade de interlocutores. Se o dataset é composto majoritariamente por diálogos entre assistente e usuário final, o modelo vai ter dificuldade com cenários B2B onde há múltiplos interlocutores corporativos. Eu vi fine-tunes que performavam bem em testes controlados e quebravam completamente em produção porque os interlocutores reais tinham dinâmicas muito diferentes do que foi ensinado. O custo de não lidar bem com interlocutores varia, mas em sistemas de alto volume pode representar uma perda de 15 a 30% na taxa de resolução na primeira interação. Não é um número pequeño quando você escala para milhões de conversas. A correção não é complicada, mas exige que você pare de ver o interlocutor como contexto implícito e comece a tratá-lo como dado explícito desde o primeiro turno.
