Uma resposta com instruções à mostra

A ferramenta respondia perguntas sobre documentos oficiais. Para cada pergunta, o assistente recebia trechos de fontes diferentes, organizados por prioridade, e precisava explicar o assunto ao leitor. Na tela, porém, parte da resposta passou a falar em camadas de autoridade, como se o leitor precisasse conhecer a organização interna do sistema.

Não era só uma questão de estilo. Quando a resposta repete os rótulos usados para organizar os trechos, fica mais difícil separar o que veio do documento do que veio da forma como o preparamos para o modelo. O texto pode soar metódico e, ainda assim, explicar menos sobre o assunto que a pessoa perguntou.

A ordem das fontes fazia sentido. O problema estava nos nomes que demos aos blocos apresentados ao modelo.

O cabeçalho também entra na conversa

Em um sistema que reúne documentos para compor uma resposta, os cabeçalhos também fazem parte do texto recebido pelo modelo. Ele lê os separadores junto com os trechos recuperados. Se uma seção se chama “fonte de autoridade máxima”, essa expressão pode reaparecer na resposta, mesmo sem ter sido pedida pelo usuário.

Uma opção seria acrescentar a instrução “não fale em camadas”. Mas o modelo continuaria recebendo esse termo no próprio material de entrada. Parecia mais seguro mudar o cabeçalho do que depender de uma proibição em cada resposta.

Isso não exigia abrir mão da prioridade. A ordem dos blocos continuava a mesma; só os cabeçalhos passaram a nomear as fontes, em vez de descrever o mecanismo interno que as ordenava.

Duas linguagens para dois públicos

Havia uma distinção importante. O sistema ainda precisava de identificadores de camada para encaminhar as fontes pela API e manter a ordem de prioridade. Esses identificadores eram úteis para o código. O leitor, por sua vez, precisava ver o nome do documento e saber qual trecho sustentava a resposta.

O texto enviado ao modelo passou a usar os títulos das fontes, enquanto os identificadores técnicos ficaram na estrutura de dados. Quando a busca devolvia uma lista vazia, o contexto registrava essa ausência explicitamente, para não deixar um espaço que o modelo pudesse preencher por conta própria. Mas havia um limite: uma falha na busca também podia produzir uma lista vazia. O texto só podia afirmar ausência de conteúdo quando a consulta terminasse sem erro.

É uma separação pequena no código e grande na leitura: metadados para a máquina, nomes de fontes para a pessoa.

O que o teste realmente mostrou

Os testes cobriram a montagem do contexto: a prioridade continuava preservada, os cabeçalhos internos antigos não apareciam no texto entregue ao modelo e as listas vazias eram sinalizadas. Os identificadores usados pela API permaneceram estáveis. Esses testes não distinguiam uma busca sem resultado de uma busca que falhou antes de consultar a fonte.

Isso não prova que o modelo nunca mais repetirá termos internos. Mostra algo mais específico: aqueles rótulos deixaram de aparecer no texto que ele recebia. Para saber o efeito na resposta inteira, ainda seria preciso observar respostas reais, não apenas o texto usado para prepará-las.