TL;DR: Tarefas genéricas como resumir, revisar e reescrever funcionam bem porque toda a informação necessária está dentro do pedido. Perguntas sobre cliente, margem, risco ou prioridade dependem de dado interno e de regra de negócio, e é aí que a qualidade cai. Três sinais separam falta de contexto de limitação do modelo: resposta genérica, regra interna ignorada e inconsistência entre consultas repetidas.
As tarefas que rodam bem desde o primeiro dia compartilham uma característica: toda a informação necessária está dentro do pedido. Um e-mail para revisar, uma ata para resumir, um texto para traduzir. O modelo recebe o material completo e trabalha sobre ele.
As tarefas que decepcionam compartilham a característica oposta. Perguntar quais contas priorizar, se vale aprovar um desconto ou onde está a maior perda de margem exige informação que não cabe no pedido e que está espalhada por sistemas diferentes.
A frustração aparece porque a mesma ferramenta mostra os dois comportamentos. Quem testou o assistente com um resumo e ficou impressionado não entende por que a pergunta sobre pipeline devolveu algo raso.
O dado. Faturamento, status de chamado, uso de produto e histórico de contrato estão em sistemas que a aplicação não consulta.
A definição. Cliente ativo, conta em risco, pedido cancelado e receita recorrente têm significado específico em cada empresa. Sem isso declarado, o modelo usa a definição mais comum do mercado.
A hierarquia. Quando duas fontes discordam, alguém precisa ter decidido qual prevalece para qual tipo de decisão. Essa regra costuma existir na cabeça de quem opera e em nenhum lugar legível por máquina.
O texto fala em acompanhar indicadores, priorizar clientes estratégicos e monitorar satisfação. Está correto e não é utilizável, porque não nomeia cliente, número ou decisão.
Isso acontece quando a aplicação não tem acesso às fontes internas relevantes. O modelo faz o que consegue com o que recebe, e o que recebe é a pergunta e pouco mais.
Como confirmar: peça a mesma análise mencionando um cliente específico pelo nome. Se a resposta não trouxer nenhum dado real daquela conta, o problema é acesso a fonte.
A resposta sugere uma ação que qualquer pessoa da área descartaria em um segundo, como ofertar para conta com crédito bloqueado ou aplicar desconto acima da alçada de quem pediu.
O dado pode até estar disponível. O que falta é a regra que diz o que fazer com ele, e ela costuma viver na memória de quem opera ou dentro de um relatório antigo.
Como confirmar: pergunte ao time qual critério eles teriam aplicado. Se o critério existe e nunca foi escrito em lugar legível pela aplicação, o problema é definição de negócio.
Feita duas vezes, a mesma pergunta traz conjuntos distintos de contas, números ou recomendações. Alguma variação de redação é esperada em geração de texto. Variação no conjunto de dados citado é outra coisa.
Isso indica que o recorte de informação recuperado muda entre as consultas, normalmente por estratégia de busca frágil ou por ordenação instável dos resultados.
Como confirmar: repita a mesma consulta cinco vezes e compare os dados citados, não o texto. Se os dados mudarem, o problema é recuperação de contexto.
| Sinal | Onde investir | O que não resolve |
|---|---|---|
| Resposta genérica | Conexão com as fontes relevantes | Modelo maior, prompt mais detalhado |
| Regra interna ignorada | Declaração das definições de negócio | Modelo maior |
| Inconsistência entre consultas | Estratégia de busca e modelagem | Ajuste de temperatura |
| Texto confuso ou mal estruturado | Prompt ou escolha de modelo | Conectar mais fontes |
Só a última linha justifica mexer no modelo. As três primeiras são trabalho de contexto, e o orçamento deveria ir para arquitetura de dados.
Uma operação de logística com 200 clientes pediu duas coisas ao assistente interno no mesmo dia. A primeira foi resumir as atas das reuniões de operação da semana, e o resultado foi bom, porque as atas estavam anexadas na pergunta. A segunda foi listar os clientes com maior risco de perda no trimestre, e a resposta veio genérica, sem nomear ninguém. Não havia como nomear: o volume estava no TMS, a reclamação estava no sistema de ocorrências e o assistente não falava com nenhum dos dois.
Uma operadora de saúde chegou mais longe no diagnóstico. Depois de seis meses de resultado abaixo do esperado, ela estava prestes a trocar de provedor de modelo. O time aplicou os três testes em uma tarde. Resposta genérica em toda pergunta sobre elegibilidade, porque a base de regras do plano não estava conectada. Regra ignorada em carência, documentada apenas em um PDF fora do índice. Inconsistência em rede credenciada, onde a busca devolvia prestadores diferentes a cada tentativa.
Nenhum dos três tinha relação com o modelo. A troca foi suspensa e o orçamento foi redirecionado para conectar as fontes e declarar as regras.
Escolha a pergunta de negócio que mais se repete nas reuniões da sua área e faça o caminho inverso: liste quais sistemas guardam cada pedaço da resposta, quais definições internas ela exige e quem decide quando duas fontes discordam. Esse mapa costuma ter entre três e seis itens, e é ele que determina se a IA vai conseguir responder.
Quando os três sinais aparecem juntos, o investimento que muda o resultado é o de contexto, que é exatamente o que um Company Brain estrutura.
Melhora a instrução e a forma da resposta. Não busca informação que a aplicação não tem acesso, então não corrige os três sinais.
É o cenário mais comum e indica que a aplicação foi construída sem camada de contexto. Vale tratar como problema de arquitetura, e não como sequência de correções pontuais.
Sim: texto mal estruturado, instrução complexa ignorada de forma consistente e erro de raciocínio com todo o material disponível na mão.
Alguém da área de negócio junto com alguém da técnica. O primeiro reconhece a regra ignorada, o segundo identifica a origem da inconsistência.
Fale com um especialista da Strattum e aplique os três sinais ao seu caso.