Como Engenharia de Contexto Torna um LLM Local Fraco em um Agente Confiável

O autor de um artigo no Habr demonstrou: para um modelo de linguagem local sendo executado em um circuito fechado em hardware limitado, a confiabilidade de um agente é determinada não pelo tamanho do modelo, mas por como seu contexto é organizado.

Por que simplesmente "pegar um modelo maior" não funciona

Quando um modelo é executado localmente — dentro do perímetro de uma empresa, em hardware limitado — aumentar seu tamanho simplesmente não é possível: não há como pegar um modelo em nuvem de nível superior com um grande número de parâmetros. O autor argumenta que nessas condições, a principal alavanca de qualidade não é o modelo em si, mas o contexto: exatamente o que é mostrado a ele, em que ordem e como informações desnecessárias são filtradas.

O que compõe o contexto "correto"

De acordo com a descrição do autor, o contexto não é apenas texto inserido, mas uma montagem que leva em conta três parâmetros: quem está fazendo a pergunta, de onde ela veio e o que exatamente está sendo perguntado. Dois elementos adicionais são adicionados a isto:

• Um limite de relevância honesto — o modelo só recebe o que realmente se relaciona com a pergunta, não tudo "só por precaução"
• Uma ordem de seção reflexiva — informações importantes para responder são colocadas para que o modelo não as "perca" entre detalhes secundários

Em outras palavras, para a mesma pergunta, o contexto será diferente dependendo do papel do usuário, do canal de comunicação e do tópico: um funcionário de suporte e um desenvolvedor devem ver fragmentos diferentes da base de conhecimento, mesmo que estejam formalmente perguntando "sobre a mesma coisa".

Como modelos fortes diferem de modelos fracos neste cenário

A observação chave do artigo — como um modelo perdoa erros na organização do contexto — depende de seu tamanho e poder. Em um modelo em nuvem forte, o contexto montado negligentemente é frequentemente perdoado por reservas de raciocínio — o modelo descobrirá por si só o que é importante e o que não é. Em um modelo local de médio porte, não há tal reserva: o mesmo contexto negligente quebra diretamente a qualidade da resposta.

Na prática, isso significa que prompts e context-pipeline devem ser testados no modelo alvo (fraco), não em um modelo em nuvem de nível superior — o que parece viável em um modelo forte pode desabar quando transferido para um local.

Onde isto é especialmente crítico

Modelos locais são mais frequentemente escolhidos onde dados não podem deixar o perímetro — bancos, setor público, medicina, manufatura. Em tais ambientes, a equipe não tem a opção de "simplesmente pegar um modelo mais poderoso": hardware e licenças para APIs em nuvem de nível superior não estão disponíveis ou são proibidos pela política de segurança. Nessas condições, engenharia de contexto — a única alavanca que pode ser gerenciada diretamente, ao contrário da arquitetura do modelo em si.

O autor enfatiza particularmente a diferença entre "contexto em geral" e "contexto para uma solicitação específica": se um sistema uma vez reuniu um conjunto universal de documentos e os alimenta ao modelo indiscriminadamente, independentemente de quem está perguntando e sobre o quê, as chances de obter uma resposta fragmentária ou incorreta em um modelo fraco são notavelmente maiores do que com montagem precisa para cada caso.

O que isso significa

Para equipes forçadas — por requisitos de segurança, limitações de orçamento de hardware ou escopo de dados — a trabalhar com modelos locais, não muito poderosos, a disciplina de engenharia de contexto se torna não uma melhoria opcional, mas uma condição sem a qual um agente simplesmente não funciona de forma confiável.