Como a engenharia de contexto transforma uma LLM local fraca em um agente confiável

Um artigo publicado no Habr mostra que, para um modelo de linguagem local rodando em ambiente isolado e com hardware limitado, a confiabilidade do agente depende menos do tamanho do modelo e mais de como o contexto é estruturado.

Por que simplesmente «pegar um modelo maior» não funciona?

Quando o modelo roda localmente, dentro do perímetro da empresa e em hardware limitado, simplesmente não há como aumentá-lo: não existe a opção de usar um modelo de ponta na nuvem, com mais parâmetros. O autor afirma que, nessas condições, a principal alavanca de qualidade é o contexto, e não o modelo em si: o que exatamente é mostrado a ele, em que ordem e como o excesso é filtrado.

Do que é feito um contexto «correto»

Segundo o autor, o contexto vai além de um trecho de texto colado no prompt: ele é montado levando em conta três parâmetros — quem faz a pergunta, de onde ela veio e sobre o que exatamente trata. A isso se somam mais dois elementos:

• Um limiar de relevância honesto — o modelo recebe apenas o que de fato se relaciona com a pergunta, e não tudo «por via das dúvidas»
• Uma ordem de seções bem pensada — as informações importantes para a resposta são posicionadas de forma que o modelo não as «perca» no meio de detalhes secundários

Em outras palavras, para uma mesma pergunta, o contexto muda conforme o papel do usuário, o canal de atendimento e o tema: faz sentido mostrar trechos diferentes da base de conhecimento a um atendente de suporte e a um desenvolvedor, mesmo que, formalmente, os dois perguntem «a mesma coisa».

O que diferencia um modelo forte de um fraco nesse cenário?

A principal observação do artigo é que a tolerância do modelo a erros na organização do contexto depende do seu tamanho e da sua capacidade. Em um modelo forte na nuvem, um contexto montado de forma desleixada muitas vezes é compensado pela folga em reasoning — o próprio modelo descobre o que importa e o que não importa. Em um modelo local intermediário, essa folga não existe: o mesmo contexto desleixado compromete diretamente a qualidade das respostas.

Na prática, isso significa que prompts e o context-pipeline precisam ser testados justamente no modelo-alvo (o mais fraco), e não no modelo de ponta na nuvem — o que parece funcionar em um modelo forte pode desmoronar quando migrado para o local.

Onde isso é especialmente crítico

Modelos locais costumam ser escolhidos onde os dados não podem sair do perímetro: bancos, setor público, saúde e indústria. É justamente nesses ambientes que a equipe não tem a opção de «simplesmente usar um modelo mais forte»: o hardware e as licenças das APIs de ponta na nuvem ou estão indisponíveis, ou são proibidos pela política de segurança. Nessas condições, a engenharia de contexto é a única alavanca que pode ser controlada diretamente, ao contrário da arquitetura do próprio modelo.

O autor destaca ainda a diferença entre «contexto em geral» e «contexto para uma consulta específica»: se o sistema monta uma única vez um conjunto genérico de documentos e o entrega ao modelo sem critério, independentemente de quem pergunta e sobre o quê, as chances de obter uma resposta fragmentada ou errada em um modelo fraco são bem maiores do que com uma montagem pontual para cada caso.

O que isso significa

Para equipes obrigadas — por exigências de segurança, orçamento de hardware ou restrições de circulação de dados — a trabalhar com modelos locais e não tão potentes, a disciplina da engenharia de contexto deixa de ser uma melhoria opcional e passa a ser uma condição sem a qual o agente simplesmente não funciona de forma confiável.