O cliente moderno tem apenas uma necessidade importante: conseguir a coisa eles querem quando eles querem. O antigo modelo RAG padrão incorporar+recuperar+LLM entende mal a intenção, sobrecarrega o contexto e perde o frescor, direcionando repetidamente os clientes para caminhos errados.
Em vez disso, a arquitetura de intenção primeiro usa um modelo de linguagem leve para analisar a consulta quanto à intenção e ao contexto, antes de entregar às fontes de conteúdo mais relevantes (documentos, APIs, pessoas).
A Enterprise AI é um trem em alta velocidade rumo a um penhasco. As organizações estão implantando aplicativos de pesquisa baseados em LLM em um ritmo recorde, enquanto uma questão arquitetônica basic está fadando ao fracasso.
Um estudo recente da Coveo revelou que 72% das consultas de pesquisa corporativa falham para fornecer resultados significativos na primeira tentativa, enquanto o Gartner também prevê que a maioria das implantações de IA conversacional tem ficado aquém das expectativas das empresas.
O problema não são os modelos subjacentes. É a arquitetura ao seu redor.
Depois de projetar e executar em grande escala plataformas de interação com clientes baseadas em IA, atendendo milhões de clientes e usuários cidadãos em algumas das maiores organizações de telecomunicações e saúde do mundo, percebi um padrão. É a diferença entre implantações bem-sucedidas de interação alimentadas por IA e falhas multimilionárias.
É nativo da nuvem arquitetura padrão que eu chamo Intenção em primeiro lugar. E está remodelando a forma como as empresas criam experiências baseadas em IA.
O problema do bilhão de dólares
O Gartner projeta que o mercado international de IA conversacional crescerá para US$ 36 bilhões até 2032. As empresas estão lutando para conseguir uma fatia. As demonstrações são irresistíveis. Conecte seu LLM à sua base de conhecimento e, de repente, ele poderá responder às perguntas dos clientes em linguagem pure.
Então a produção acontece.
Um grande provedor de telecomunicações com quem trabalho lançou um sistema RAG com a expectativa de reduzir a taxa de chamadas de suporte. Em vez disso, a taxa aumentou. Os chamadores tentaram a pesquisa com tecnologia de IA, receberam respostas incorretas com alto grau de confiança e ligaram para o suporte ao cliente com mais raiva do que antes.
Esse padrão é repetido indefinidamente. Na área da saúde, os assistentes de IA voltados para o cliente fornecem aos pacientes informações de formulários que estão desatualizadas há semanas ou meses. Os chatbots de serviços financeiros estão divulgando respostas de conteúdo de produtos institucionais e de varejo. Os varejistas estão vendo produtos descontinuados surgindo nas pesquisas de produtos.
O problema não é uma falha da tecnologia de IA. É uma falha da arquitetura
Por que as arquiteturas RAG padrão falham
O padrão RAG padrão – incorporação da consulta, recuperação de conteúdo semanticamente semelhante, passagem para um LLM – funciona perfeitamente em demonstrações e provas de conceitos. Mas isso desmorona em casos de uso de produção por três razões sistemáticas:
1. A lacuna de intenção
A intenção não é contexto. Mas as arquiteturas RAG padrão não levam em conta isso.
Digamos que um cliente digite “Quero cancelar”. O que isso significa? Cancelar um serviço? Cancelar um pedido? Cancelar um compromisso? Durante a nossa implantação de telecomunicações, descobrimos que 65% das consultas para “cancelar” eram, na verdade, sobre pedidos ou compromissos, e não sobre cancelamento de serviços. O sistema RAG não tinha como entender essa intenção, por isso retornava consistentemente documentos de cancelamento de serviço.
A intenção é importante. Na área da saúde, se um paciente digita “Preciso cancelar” porque está tentando cancelar uma consulta, uma recarga de receita ou um procedimento, encaminhá-lo para o conteúdo da medicação no agendamento não é apenas frustrante, mas também perigoso.
2. Inundação de contexto
O conhecimento e a experiência empresarial são vastos, abrangendo dezenas de fontes, como catálogos de produtos, faturamento, artigos de suporte, políticas, promoções e dados de contas. Os modelos RAG padrão tratam tudo da mesma forma, pesquisando tudo para cada consulta.
Quando um cliente pergunta “Como ativo meu novo telefone”, ele não se importa com perguntas frequentes sobre cobrança, locais de lojas ou atualizações de standing da rede. Mas um modelo RAG padrão recupera conteúdo semanticamente semelhante de todas as fontes, retornando resultados de pesquisa que estão meio passo errados.
3. Ponto cego de frescor
O espaço vetorial é cego ao tempo. Semanticamente, a promoção do último trimestre é idêntica à deste trimestre. Mas apresentar aos clientes ofertas desatualizadas destrói a confiança. Vinculamos uma porcentagem significativa de reclamações de clientes a resultados de pesquisa que revelavam produtos, ofertas ou recursos expirados.
O padrão de arquitetura Intent-First
O padrão de arquitetura Intent-First é a imagem espelhada da implantação RAG padrão. No modelo RAG, você recupera e depois roteia. No modelo Intent-First, você classifica antes de rotear ou recuperar.
As arquiteturas Intent-First usam um modelo de linguagem leve para analisar uma consulta quanto à intenção e ao contexto, antes de despachá-la para as fontes de conteúdo mais relevantes (documentos, APIs, agentes).
Comparação: intenção primeiro versus RAG padrão
Implementação nativa da nuvem
O padrão Intent-First foi projetado para implantação nativa em nuvem, aproveitando microsserviços, conteinerização e escalabilidade elástica para lidar com padrões de tráfego corporativo.
Serviço de classificação de intenções
O classificador determina a intenção do usuário antes que ocorra qualquer recuperação:
ALGORITMO: Classificação de Intenção
ENTRADA: user_query (string)
SAÍDA: intent_result (objeto)
1. Consulta PREPROCESS (normalizar, expandir contrações)
2. CLASSIFIQUE usando o modelo do transformador:
– intenção_primária ← mannequin.predict(consulta)
– confiança ← mannequin.confidence_score()
3. SE confiança < 0,70 ENTÃO
– RETORNAR {
requer_clarificação: verdadeiro,
pergunta_sugerida: gerar_esclarecimento_pergunta(consulta)
}
4. EXTRAIR sub_intent com base em primária_intent:
– IF primário = “ACCOUNT” → verifique ORDER_STATUS, PROFILE, and so forth.
– IF primário = “SUPPORT” → verifique DEVICE_ISSUE, NETWORK, and so forth.
– SE primário = “FATURAMENTO” → verifique PAGAMENTO, DISPUTA, and so forth.
5. DETERMINAR target_sources com base no mapeamento de intenções:
– ORDER_STATUS → [orders_db, order_faq]
– DEVICE_ISSUE → [troubleshooting_kb, device_guides]
– MEDICAÇÃO → [formulary, clinical_docs] (assistência médica)
6. VOLTAR {
intenção_primária,
sub_intenção,
confiança,
fontes_alvo,
requer_personalização: verdadeiro/falso
}
Serviço de recuperação baseado no contexto
Depois que a intenção é classificada, a recuperação se torna direcionada:
ALGORITMO: Recuperação sensível ao contexto
ENTRADA: consulta, intent_result, user_context
SAÍDA: documentos_classificados
1. GET source_config para intent_result.sub_intent:
– Primary_sources ← fontes para pesquisar
– exclude_sources ← fontes a serem ignoradas
-freshness_days ← idade máxima do conteúdo
2. SE a intenção exigir personalização E o usuário for autenticado:
– BUSCAR account_context do serviço de conta
– SE intenção = ORDER_STATUS:
– FETCH recent_orders (últimos 60 dias)
– ADICIONAR aos resultados
3. CONSTRUA filtros de pesquisa:
– content_types ← somente fontes_primárias
– max_age ← frescor_dias
– user_context ← account_context (se disponível)
4. PARA CADA fonte EM Primary_sources:
– documentos ← vector_search(consulta, fonte, filtros)
– ADICIONAR documentos aos resultados
5. PONTUAÇÃO de cada documento:
– pontuação_relevância ← similaridade_vetorial × 0,40
– pontuação_de recência ← peso_frescura × 0,20
– pontuação_de_personalização ← correspondência_do_usuário × 0,25
– intent_match_score ← tipo_match × 0,15
– total_score ← SOMA acima
6. RANK por total_score decrescente
7. RETORNE os 10 principais documentos
Considerações específicas de saúde
Nas implantações de saúde, o padrão Intent-First inclui salvaguardas adicionais:
Categorias de intenção de saúde:
-
Clínico: Perguntas sobre medicação, sintomas, instruções de cuidados
-
Cobertura: Benefícios, autorização prévia, formulário
-
Agendamento: Compromissos, disponibilidade do fornecedor
-
Cobrança: Reclamações, pagamentos, extratos
-
Conta: Perfil, dependentes, carteiras de identidade
Salvaguarda crítica: As consultas clínicas sempre incluem isenções de responsabilidade e nunca substituem o aconselhamento médico profissional. O sistema encaminha questões clínicas complexas para suporte humano.
Lidando com casos extremos
Os casos extremos são onde os sistemas falham. O padrão Intent-First inclui manipuladores específicos:
Palavras-chave de detecção de frustração:
-
Raiva: “terrível”, “pior”, “ódio”, “ridículo”
-
Tempo: “horas”, “dias”, “ainda esperando”
-
Falha: “inútil”, “não ajuda”, “não funciona”
-
Escalação: “fale com humano”, “pessoa actual”, “gerente”
Quando a frustração for detectada, pule totalmente a pesquisa e encaminhe para o suporte humano.
Aplicações intersetoriais
O padrão Intent-First se aplica sempre que as empresas implantam IA conversacional em conteúdo heterogêneo:
|
Indústria |
Categorias de intenção |
Principal benefício |
|
Telecomunicações |
Vendas, suporte, faturamento, conta, retenção |
Evita classificação incorreta de “cancelamento” |
|
Assistência médica |
Clínica, Cobertura, Agendamento, Faturamento |
Separa o clínico do administrativo |
|
Serviços financeiros |
Varejo, institucional, empréstimos, seguros |
Impede a mistura de contexto |
|
Varejo |
Produto, Pedidos, Devoluções, Fidelização |
Garante frescor promocional |
Resultados
Depois de implementar a arquitetura Intent-First em plataformas de telecomunicações e saúde:
|
Métrica |
Impacto |
|
Taxa de sucesso de consulta |
Quase dobrou |
|
Escalações de suporte |
Reduzido em mais da metade |
|
Hora de resolução |
Reduzido aproximadamente 70% |
|
Satisfação do usuário |
Melhorou cerca de 50% |
|
Taxa de retorno do usuário |
Mais que dobrou |
A taxa de retorno de usuários mostrou-se mais significativa. Quando a pesquisa funciona, os usuários voltam. Quando falha, eles abandonam totalmente o canal, aumentando os custos em todos os outros canais de suporte.
O imperativo estratégico
O mercado de IA conversacional continuará a experimentar um hipercrescimento.
Mas as empresas que criam e implementam arquiteturas RAG típicas continuarão a falhar…repetidamente.
A IA dará respostas erradas com segurança, os usuários abandonarão os canais digitais por frustração e os custos de suporte aumentarão em vez de diminuir.
Intent-First é uma mudança basic na forma como as empresas precisam arquitetar e construir conversas com os clientes baseadas em IA. Não se trata de modelos melhores ou de mais dados. Trata-se de entender o que um usuário deseja antes de tentar ajudá-lo.
Quanto mais cedo uma organização perceber isto como um imperativo arquitetónico, mais cedo será capaz de capturar os ganhos de eficiência que esta tecnologia supostamente permite. Aqueles que não o fizerem irão depurar por que seus investimentos em IA não produziram os resultados de negócios esperados nos próximos anos.
A demonstração é fácil. A produção é difícil. Mas o padrão para o sucesso da produção é claro: Intenção primeiro.
Sreenivasa Reddy Hulebeedu Reddy é engenheiro de software program líder e arquiteto corporativo
Bem-vindo à comunidade VentureBeat!
Nosso programa de visitor posts é onde especialistas técnicos compartilham insights e fornecem análises profundas, neutras e não adquiridas, sobre IA, infraestrutura de dados, segurança cibernética e outras tecnologias de ponta que moldam o futuro das empresas.
Leia mais do nosso programa de visitor submit – e confira nosso diretrizes se você estiver interessado em contribuir com um artigo de sua autoria!
