Duas empresas usam o mesmo modelo, do mesmo fornecedor, para o mesmo tipo de tarefa. Uma reporta resultado medíocre; a outra, resultado excelente. A diferença quase nunca está no modelo — está no que cada uma entrega ao modelo junto com a pergunta. A tese deste artigo: a maior parte do ganho de qualidade em aplicação corporativa vem de decidir o que entra em cada chamada, não de trocar de modelo. Enquanto o artigo sobre conectar IA à base trata da arquitetura, este trata do que se entrega ao modelo em cada chamada individual.
Quatro camadas de contexto
Instrução: o que o sistema deve fazer e, tão importante, o que não deve. Instrução que diz "responda sobre política comercial" é vaga; instrução que define escopo, tom, proibições e comportamento diante de dúvida é engenharia.
Dado recuperado: os trechos relevantes da base, selecionados para aquela pergunta. Estado: o que já aconteceu na conversa ou no processo — quem é o usuário, o que já foi decidido, em que etapa o caso está. Formato: como a saída precisa sair para o passo seguinte consumir, seja um humano, seja outra aplicação.
Mais contexto não é melhor contexto
Enviar o documento inteiro em vez do trecho relevante aumenta custo, aumenta latência e piora a resposta, porque dilui o sinal: o modelo passa a distribuir atenção entre o que importa e o que é ruído.
Selecionar é trabalho de engenharia, não economia. A decisão sobre o que entra na chamada determina qualidade, custo e velocidade ao mesmo tempo — e é uma decisão por aplicação, revisitada sempre que o comportamento degrada.
Onde a empresa erra com mais frequência
Instrução vaga que assume conhecimento do processo: o modelo não participou da reunião em que a regra foi decidida, e a instrução precisa conter o que a reunião decidiu.
Ausência de regra para o caso em que a informação não existe na base: sem instrução explícita, o comportamento padrão é inventar uma resposta plausível em vez de admitir a lacuna. Falta de definição do formato de saída: a resposta livre quebra a integração seguinte, e o erro aparece no sistema vizinho, longe da causa.
O terceiro erro é tratar o contexto como detalhe técnico delegado por inteiro ao time de implementação. As decisões sobre instrução, seleção de dados e formato de saída são decisões de negócio vestidas de configuração: definem o que o sistema pode dizer, com que embasamento e para quem. Quando a área responsável pelo processo não participa dessas definições, o resultado é um sistema tecnicamente correto e operacionalmente alheio à regra que a empresa diz seguir.
Versionar o contexto como se versiona código
Mudança na instrução altera o comportamento do sistema inteiro — para todos os usuários, a partir do momento da publicação. Tratar essa mudança com o mesmo rigor de uma alteração de código não é preciosismo: é o mínimo de rastreabilidade.
Sem versão registrada e sem teste antes de publicar, a empresa não consegue explicar por que a resposta de hoje é diferente da de ontem. Quando um cliente reclama de uma resposta de terça-feira, a pergunta "qual instrução estava ativa na terça?" precisa ter resposta.
O versionamento disciplina também a conversa com o fornecedor e com a auditoria. Quando cada alteração de instrução tem data, autor e motivo registrados, a empresa consegue reconstruir o histórico de comportamento do sistema — e consegue demonstrar, se questionada, qual versão estava ativa em qual período.
Quatro camadas a definir por aplicação
- Instrução: escopo, proibições e comportamento diante de dúvida
- Dado recuperado: quais trechos entram, e de onde
- Estado: o que o sistema sabe sobre a conversa e o processo
- Formato de saída: como o passo seguinte consome a resposta
Case relacionado
Projeto Horizonte 180Fontes e referências
NIST AI Risk Management Framework 1.0 (2023)
Acessar a fonteISO/IEC 42001:2023 — Sistema de gestão de IA
Acessar a fonte
Solução ÍON relacionada
Estratégia & Gestão Empresarial
Dúvidas frequentes
- O que é engenharia de contexto?
- É o trabalho de decidir o que entra em cada chamada ao modelo: qual instrução, quais trechos recuperados da base, qual estado da conversa e qual formato de saída. Em aplicação corporativa, essa decisão explica a maior parte da diferença de qualidade entre sistemas que usam o mesmo modelo.
- Mais contexto melhora a resposta?
- Não — contexto certo melhora. Enviar documento inteiro em vez do trecho relevante aumenta custo e latência e piora a resposta, porque dilui a informação que importa no meio do ruído. Seleção de contexto é trabalho de engenharia, não de volume.
- Como tratar o caso de informação ausente na base?
- Com regra explícita na instrução: o que o sistema deve fazer quando a base não contém a resposta — admitir a lacuna, encaminhar a um humano ou responder com ressalva. Sem essa regra, o comportamento padrão do modelo é produzir uma resposta plausível inventada.
- Preciso versionar prompt e instruções?
- Sim, como se versiona código. Mudança na instrução altera o comportamento de todo o sistema para todos os usuários. Sem registro de versão e teste antes de publicar, não há como explicar mudanças de comportamento nem reverter uma alteração que degradou a qualidade.
- Trocar de modelo resolve problema de qualidade?
- Raramente, quando o problema é de contexto. Se a instrução é vaga, o trecho recuperado é errado ou o formato de saída é indefinido, o modelo novo herda os mesmos defeitos. Antes de trocar de modelo, verifique as quatro camadas: instrução, dado recuperado, estado e formato.
Autor
Leandro Bryk
Consultor responsável pela ÍON Soluções, atuando em inteligência comercial, estratégia, gestão financeira, marketing e imagem corporativa.
LinkedIn