Como Fazer um LLM Local Citar Apenas as Fontes Que Leu de Facto

Pedi a um modelo alojado na minha própria máquina — um modelo local de 12B — um resumo de investigação com fontes. Veio impecável: conclusões organizadas, uma lista de links no fim.

Depois comparei essa lista com as páginas que o modelo tinha realmente aberto.

Um terço delas nunca tinha sido lido.

O modelo retirou números dos resumos dos resultados de pesquisa e listou os links como se tivesse lido as páginas por trás deles. Os valores eram plausíveis. Os links eram reais e carregavam. Mas "o link carrega" não é "li esta página e o número está lá". É nesse intervalo que nascem as citações silenciosas, confiantes e erradas.

Eis exatamente como o resolvi — e porque a solução não é um prompt mais inteligente.

O verdadeiro modo de falha: resumo ≠ fonte

Quando um agente investiga, faz normalmente duas coisas: uma pesquisa (que devolve pequenos resumos e links) e depois abre alguns desses links para os ler.

A armadilha é que o resumo já contém números tentadores. Um modelo sob qualquer tipo de pressão de tempo retira o valor diretamente do resumo e anexa o link — sem nunca abrir a página. O resultado final parece igualmente bem citado nos dois casos. Olhando para a nota acabada, não há forma de saber que fontes foram lidas e quais foram apenas vistas num resultado de pesquisa.

Isto não é alucinação exótica. Cada facto individual pode até ser verdadeiro. O perigo está na proveniência: uma citação que afirma "li isto" quando o modelo só viu uma pré-visualização de uma linha.

Porque é que "basta mandá-lo portar-se bem" não chega

O meu primeiro instinto foi o óbvio. Acrescentei uma regra, em linguagem clara: um resumo de pesquisa é uma pista, não uma citação — cita apenas uma página que tenhas aberto de facto.

Melhorou. Não ficou resolvido.

Num modelo local pequeno, uma regra no prompt é uma sugestão forte, não uma restrição. Aguenta até ao momento em que o modelo é pressionado — digamos que tem cinco coisas para orçamentar mas só tem margem para abrir três páginas. Aí recorre discretamente aos números dos resumos para as outras duas e cita-as na mesma. A instrução estava certa; o modelo apenas não a cumpriu sob carga.

Se a sua fiabilidade depende de o modelo escolher seguir uma regra, não tem fiabilidade. Tem uma esperança.

A correção: uma verificação que o modelo não consegue contornar

O princípio: não avaliar o modelo pelo que ele próprio diz, mas pelo que aconteceu de facto. "O que aconteceu de facto" é observável, porque a ferramenta que abre páginas sabe exatamente que endereços carregou.

Três peças pequenas:

1. Registar cada página que a ferramenta abre de facto

Sempre que a ferramenta de leitura/navegação do agente devolve conteúdo real de uma página, acrescente esse endereço a um pequeno ficheiro de registo diário. Uma linha por leitura genuína. Ignore falhas, bloqueios e respostas vazias — registe apenas uma página que tenha mesmo obtido.

2026-06-19T11:42:07Z   https://www.dgav.pt/.../registo/
2026-06-19T11:43:15Z   https://files.dre.pt/.../67246729.pdf

Isto é a verdade no terreno. É escrito pela ferramenta, não afirmado pelo modelo.

2. Depois da nota escrita, confrontar cada citação com o registo

Um script curto extrai cada link da secção de fontes da nota e confirma que aparece no registo. Se um link citado nunca foi aberto, a nota falha a verificação. É só isto — cerca de dez linhas de shell. Nenhum modelo decide o resultado, por isso nenhum modelo o pode contestar.

3. Falhar a nota e encaminhar os factos não verificados com honestidade

Quando a verificação falha, os links citados mas não abertos não são simplesmente apagados (isso deixaria o número órfão no corpo, com ar de verificado). O facto passa para uma secção explícita de "a verificar", claramente marcada como não confirmada. O leitor vê com precisão o que foi lido e o que não foi.

A prova

A primeira vez que corri esta verificação num resumo que eu já tinha lido e aprovado a olho, falhou 4 de 6 fontes. Duas delas tinha-as eu próprio revisto e deixado passar — pareciam bem, os links funcionavam, e não reparei que o modelo nunca as abriu.

Uma verificação determinística de dez linhas apanhou duas citações de proveniência fabricada que uma revisão humana tinha deixado passar. É o argumento todo num único resultado.

Depois de integrar a verificação no fluxo, uma nova execução devolveu todas as fontes citadas genuinamente abertas — e os poucos números que não conseguiu confirmar numa página ficaram honestamente parqueados como "a verificar", em vez de disfarçados de factos.

Porque é que isto é mais fácil quando o modelo é seu

Esta é a vantagem discreta de correr IA na sua própria infraestrutura em vez de a alugar através de uma API fechada: pode acrescentar as garantias que o fornecedor não lhe dá. A ferramenta de navegação, o registo, a verificação — vivem na sua infraestrutura, sob as suas regras. Não fica à espera que um fornecedor lance uma funcionalidade de "confiança". A lógica do veredicto é sua.

Mantém também os dados locais. Todo o ciclo de investigação — pesquisar, ler, verificar — correu numa só máquina, num modelo que eu controlo. Para qualquer coisa que envolva material regulado ou sensível, essa combinação (local + verificável) vale mais do que uns pontos de qualidade bruta do modelo.

O limite honesto

Seja claro sobre o que esta verificação prova e o que não prova. Prova que o modelo abriu a página que citou. Não prova que o número nessa página está correto, nem que a página sustenta de facto a afirmação. Um link pode responder, ser lido, e mesmo assim estar mal citado.

Por isso, isto é uma camada, não a resposta toda. Elimina a falha mais comum e mais invisível — citar coisas que nunca se leu — e torna explícito o risco que resta: uma lista curta de valores específicos que merecem uma confirmação humana. É uma superfície dramaticamente menor e mais honesta do que "confiar na lista arrumada do fim".

A conclusão

Com modelos locais pequenos, o padrão repete-se em todo o lado: uma regra no prompt é uma sugestão; uma verificação determinística é uma garantia. A alavanca glamorosa (um prompt mais inteligente, um modelo maior, mais agentes) raramente resolve um problema de fiabilidade. A alavanca aborrecida — uma verificação que observa o que realmente aconteceu e se recusa a ser contestada — costuma resolver.

Se está a construir fluxos de investigação ou de agentes em modelos locais, comece por aí. Registe o que as ferramentas fazem de facto e verifique o resultado contra esse registo. É a fiabilidade mais barata que alguma vez vai acrescentar.

---

Todos os números deste artigo são de uma sessão documentada da ImparLabs (19 de junho de 2026): um modelo local de 12B da família Gemma a correr numa única GPU de consumo, via llama.cpp. O resultado "falhou 4 de 6 fontes" é o output real da verificação na nota de investigação desse dia.