A Tecnologia Sozinha Não Garante A adoção: Lições da Construção de um Chatbot de IA Interno

À medida que a adoção de IA se acelerou em várias indústrias, implantar um chatbot para apoiar um aplicativo interno recentemente lançado parecia uma decisão lógica. No entanto, o próprio aplicativo desafiou as expectativas convencionais dos usuários. Ele introduziu novos fluxos de trabalho baseados em tecnologia emergente, desconhecida para a maioria dos usuários.

Para reduzir a fricção e melhorar a adoção, o chatbot foi projetado para responder a perguntas sobre o aplicativo e a tecnologia subjacente. O objetivo era ajudar os usuários a entender não apenas o que fazer, mas também por que o sistema se comportava de uma determinada maneira. Acreditávamos que fornecer explicações contextuais aceleraria o aprendizado e reduziria a confusão.

Desde o início, o agente de IA foi concebido como uma solução de escopo limitado. Ele foi projetado estritamente para apoiar a documentação e fornecer assistência ao usuário. Conceitualmente, o chatbot foi destinado a servir como um substituto dinâmico para um documento de Perguntas Frequentes tradicional, oferecendo uma interface conversacional, pesquisável e continuamente disponível com funcionalidades estendidas além do conteúdo estático.

Para integrar o agente ao ambiente de bate-papo interno da organização, precisávamos entender como as mensagens estruturadas eram renderizadas, como o histórico de conversa era armazenado e como o sistema identificava os participantes dentro das threads. Isso nos permitiu determinar as variáveis principais necessárias para começar a processar as perguntas dos usuários.

Baseando o Modelo: De Alucinação para Contexto Confiável

Os grandes modelos de linguagem são poderosos, mas sem ancoragem contextual, eles são propensos a alucinações. Para abordar isso, implementamos uma técnica de embedding de vetores.

Guias de usuário, documentação interna e a visão do produto foram transformados em representações numéricas de vetores de texto. Esses embeddings capturaram o significado semântico, permitindo que o sistema combinasse conceitos em vez de confiar apenas no simples matching de palavras-chave.

Quando um usuário fazia uma pergunta, o sistema convertia a consulta em uma representação de vetor e a comparava com os embeddings armazenados. Ele recuperava os documentos mais semanticamente relevantes e os injetava no prompt do modelo. O modelo então gerava uma resposta baseada nesses documentos específicos, frequentemente resumindo as informações relevantes.

Essa abordagem melhorou significativamente a precisão das respostas. Em vez de gerar respostas baseadas apenas no conhecimento geral, o modelo respondia usando a própria documentação da nossa organização como contexto.

A Complexidade Oculta do Gerenciamento de Contexto

Foi essencial incluir o histórico de conversa no prompt para que o bot pudesse interpretar perguntas de follow-up e manter a continuidade. Sem histórico, as interações se tornavam fragmentadas e repetitivas. Os usuários frequentemente refinavam suas perguntas incrementalmente, e sem contexto, o bot não podia interpretar referências como “essa opção” ou “o passo anterior”.

No entanto, incluir muito histórico criou um problema diferente: limites de tokens. Isso ocorre quando os modelos de linguagem truncam entradas que excedem sua janela de contexto máxima. Se uma pergunta ou conversa se tornasse muito longa, informações importantes poderiam ser perdidas. Isso não produziu um erro explícito, mas sim degradou a qualidade da resposta ou afetou a precisão de recuperação.

Para mitigar isso, implementamos estratégias para controlar o tamanho do prompt, priorizar conteúdo relevante e monitorar o comprimento da pergunta. Experimentamos resumir mensagens mais antigas e incluir apenas as partes mais relevantes da conversa. O contexto era crítico, mas precisava ser gerenciado com cuidado.

Ampliando Capacidades e Criando Confusão

Além de responder a perguntas baseadas em documentação, estendemos as capacidades do bot adicionando funções de backend que podiam extrair certas informações públicas diretamente do aplicativo. Isso permitiu que os usuários recuperassem dados do chat sem precisar fazer login no aplicativo em si. A ideia era reduzir a fricção e reforçar o chatbot como uma interface útil, não apenas uma camada de conhecimento estática.

No entanto, essa extensão criou confusão para alguns usuários. Uma vez que o bot começou a recuperar dados ao vivo, os usuários começaram a pedir que ele executasse ações que requeriam interação direta dentro da plataforma. Eles supunham que o chatbot pudesse substituir etapas operacionais, incluindo aquelas que exigiam autenticação ou execução deliberada dentro da plataforma.

O bot nunca foi projetado para realizar essas ações, mas a distinção entre assistência informativa e execução operacional não era sempre clara.

Integrar dados ao vivo também introduziu novas considerações técnicas. Precisávamos definir quando uma pergunta deveria passar pela recuperação baseada em embeddings e quando deveria acionar uma chamada de backend. Essa lógica de decisão exigia um design cuidadoso. Além disso, tivemos que ajustar as respostas para lidar com exceções técnicas de forma elegante e evitar expor erros de sistema brutos aos usuários.

Capacidade Multilíngue Não é Automática

Durante os testes, percebemos que o bot consistentemente se saía melhor em inglês do que em outros idiomas usados dentro da Jalasoft. O motivo principal era estrutural: a maioria da documentação usada para gerar embeddings foi escrita em inglês, e o modelo de embedding que escolhemos foi otimizado para semelhança semântica em inglês.

Ele não suportava recuperação cross-lingual ou comparação semântica entre idiomas. Como resultado, consultas não em inglês frequentemente recuperavam documentação menos relevante, levando a respostas mais fracas.

Isso destacou uma percepção importante: a capacidade multilíngue não é automática.

Quando as Expectativas Excedem o Escopo

Para controlar os custos de uso, implementamos um limite diário no número de perguntas que os usuários podiam fazer. No entanto, não restringimos explicitamente o escopo dessas perguntas. Os usuários estavam livres para perguntar qualquer coisa.

Essa abertura levou a padrões de uso inesperados. Alguns usuários começaram a interagir com o bot para fins pessoais ou exploratórios não relacionados ao aplicativo. Com o tempo, as expectativas ultrapassaram o papel pretendido do bot, criando uma lacuna entre o que os usuários esperavam que ele pudesse fazer e o que ele foi projetado para apoiar.

Essa desalinhamento gradualmente reduziu sua utilidade percebida. O uso declinou, e o chatbot foi eventualmente descontinuado, com esforços redirecionados para redesenhar o aplicativo em si para torná-lo mais intuitivo e fácil de usar.

A Lição Real: Design de Interação.

Do ponto de vista da engenharia, o sistema funcionou razoavelmente bem. Ele recuperou documentação, incorporou o histórico de conversa, reduziu alucinações por meio de embeddings, lidou com chamadas de backend e gerenciou o tamanho do prompt. A arquitetura funcionou como pretendida.

No entanto, faltava um design de interação intencional.

O bot não moldou claramente as conversas. Ele não reforçou consistentemente seu escopo. Ele não guiou os usuários com exemplos estruturados do que ele podia e não podia fazer. Ele respondeu a perguntas, mas não estabeleceu expectativas.

Aprendemos que os sistemas de IA conversacional exigem mais do que modelos fortes e dados estruturados. Eles exigem expectativas cuidadosamente projetadas. Os usuários precisam de clareza sobre o papel do agente, seus limites e suas forças. O sistema deve fornecer proativamente exemplos de prompts, esclarecer limitações e redirecionar perguntas fora do escopo de forma consistente.

sem essa estruturação intencional, mesmo uma implementação tecnicamente sólida pode lutar para manter o valor. Os usuários podem superestimar as capacidades ou se desengajar quando expectativas não declaradas não são atendidas.

A percepção central é simples, mas poderosa.

Construir IA conversacional não é apenas um desafio técnico. É também um desafio de design de interação.

Contexto forte, recuperação precisa e arquitetura robusta são necessários, mas não suficientes. A eficácia do sistema depende igualmente de como ele define seu papel, comunica seus limites e molda as expectativas do usuário.

A tecnologia sozinha não garante a adoção. O design de interação claro é.