Filtros de metadados RAG para chatbots de IA: separar idioma, versão e acesso

Um chatbot de IA pode encontrar passagens de texto semanticamente muito semelhantes e, ainda assim, preparar a resposta errada: o manual em inglês em vez do português, a documentação da versão anterior em vez da atual, ou notas internas destinadas a um visitante sem permissões. Nestes casos, a classificação de relevância não é necessariamente má. O problema é que o espaço de pesquisa estava errado.

Os filtros de metadados RAG resolvem exatamente este problema. Limitam, antes ou durante a pesquisa, quais os documentos e chunks que cumprem os requisitos para servir de contexto. A relevância responde depois à questão: “O que se adequa melhor em termos de conteúdo?”. Mas o filtro responde primeiro a: “O que pode e deve ser considerado nesta situação?”.

Por que razão a semelhança por si só não é um escopo fiável

A pesquisa vetorial e híbrida organiza o conteúdo por proximidade linguística ou semântica. Um manual para a versão 4 de um produto pode ser extremamente semelhante a uma pergunta sobre a versão 5. Uma lista de preços para outro mercado pode conter exatamente os mesmos nomes de produtos. E um documento de suporte interno pode fornecer uma resposta mais precisa do que a FAQ pública, embora nunca devesse aparecer num chat público.

Por isso, o recuperar de dados (retriever) deve separar claramente dois tipos de condições:

• Limites rígidos, como cliente (tenant), função, estado de publicação ou zona de dados permitida. Na presença de um valor desconhecido, a pesquisa deve permanecer fechada.
• Critérios de seleção do negócio, como idioma, família de produtos, versão, região ou período de validade. Estes aumentam a precisão e evitam contextos contraditórios.

A síntese atual do OWASP para aplicações de LLM atribui expressamente os riscos de vetores e embeddings à fronteira de confiança de uma aplicação de IA. Esta é uma perspetiva crucial: uma verificação de autenticação antes do chat não é suficiente se a pesquisa por semelhança subsequente for executada num índice demasiado abrangente.

Um esquema de metadados robusto para o dia a dia

Bons filtros não começam com uma query longa, mas sim com alguns campos canónicos. Para a maioria dos chatbots de sites, bastam seis grupos:

• Idioma e mercado: como locale e market, com valores rigidamente definidos em vez de texto livre.
• Produto e versão: ID do produto estável, intervalo de versões e, opcionalmente, plataforma ou plano.
• Validade: estado de aprovação, válido a partir de, válido até e uma versão de origem inequívoca.
• Público-alvo: público, cliente, parceiro ou equipa interna – separado da verificação de funções propriamente dita.
• Domínio de acesso: tenant, grupo ou principal, exclusivamente a partir de um contexto de servidor verificado.
• Origem: ID da fonte, URL, tipo de documento e área de conteúdo responsável para garantir a rastreabilidade.

Os metadados pertencem ao nível em que a pesquisa é efetuada. Se um documento for dividido em chunks, os campos de escopo determinantes têm de ser associados de forma fiável a cada chunk. Caso contrário, um documento pode estar corretamente classificado, enquanto resultados individuais da pesquisa perdem essa atribuição. A documentação da OpenAI sobre File Search mostra, por exemplo, como os atributos de ficheiros são utilizados para filtragem de metadados. A referência do Amazon Bedrock documenta operadores de comparação, lista e intervalo para a mesma ideia fundamental.

Nunca deixar o modelo de linguagem autorizar filtros

O modelo pode inferir pistas como idioma ou referência ao produto a partir da pergunta do utilizador. No entanto, não deve decidir a que tenant pertence uma pessoa ou que permissões possui. Estes valores têm de vir da sessão, do sistema de identidade e das regras de negócio do lado do servidor. Mesmo uma string de filtro gerada pelo modelo não deve ser repassada ao serviço de pesquisa sem ser inspecionada.

Um fluxo de trabalho robusto funciona assim:

1. O servidor autentica o pedido e determina a zona de dados permitida.
2. Regras determinísticas definem campos rígidos como tenant, função e estado de publicação.
3. Atributos identificados, como idioma ou produto, são validados contra valores permitidos.
4. O retriever executa apenas uma estrutura de filtro tipada e parametrizada.
5. A aplicação volta a verificar as fontes retornadas quanto ao escopo esperado.
6. Em caso de contexto em falta ou contraditório, o chatbot pede esclarecimentos ou fornece um fallback seguro.

A documentação da Microsoft sobre Security Filters faz uma distinção útil: um principal num filtro é inicialmente apenas um valor. A autenticação e a autorização têm de ocorrer de forma fiável fora da expressão de pesquisa. Para portais de clientes, o nosso artigo sobre a separação entre chatbots de IA públicos e autenticados aprofunda este limite.

Pré-filtragem ou pós-filtragem?

A posição do filtro afeta a qualidade e o tempo de execução. A pré-filtragem (pre-filter) restringe os candidatos durante a própria pesquisa vetorial. A pós-filtragem (post-filter) pesquisa primeiro de forma mais ampla e remove os resultados não autorizados em seguida. Segundo a documentação da Azure sobre filtros vetoriais, o post-filtering com filtros muito seletivos e um k pequeno pode ignorar resultados adequados; o pre-filtering favorece a revocação (recall) no subconjunto permitido, mas pode gerar maior esforço computacional com filtros extremamente estreitos.

Para limites rígidos de acesso, "pesquisar amplo primeiro e esconder depois" não é um padrão adequado. O escopo autorizado deve ser imposto dentro da consulta de pesquisa. Para filtros puramente funcionais, uma equipa pode medir variantes de pré e pós-filtragem. Aí, o que conta não é apenas o tempo médio de resposta, mas também a frequência com que um resultado existente e permitido é omitido devido à ordem escolhida.

Os filtros não substituem o ranking. Dentro do corpus permitido, a Hybrid Search e o Reranking continuam a poder priorizar as melhores fontes. A ordem é, portanto: definir o escopo, obter candidatos, avaliar a relevância, verificar fontes e gerar a resposta.

Quatro casos típicos de filtragem

Idioma com fallback consciente

Para uma pergunta em português, a primeira consulta deve selecionar conteúdos aprovados em português. Se não houver resultados, a aplicação não deve misturar silenciosamente vários idiomas. Um segundo caminho explícito pode recorrer a um idioma base aprovado e sinalizar esse facto na resposta. Uma Locale-QA para bases de conhecimento multilíngues verifica adicionalmente se as variantes são realmente equivalentes quanto ao conteúdo.

Versão do produto e validade temporal

Uma fonte não deve parecer atual apenas por ter sido analisada (crawled) recentemente. O decisivo é a versão funcional e a aprovação. Marque os conteúdos com ID do produto estável, intervalo de versões, valid_from, valid_until e estado. Em caso de aprovações sobrepostas, o pipeline deve reportar um conflito em vez de colocar ambos os textos no mesmo prompt. A forma como a cadência de crawl e a manutenção de fontes se articulam é descrita no guia sobre a atualização da base de conhecimento do chatbot de IA.

Tenant e função

Num índice partilhado, cada consulta deve conter o tenant e os principais válidos determinados do lado do servidor. A falta de metadados ACL significa "não recuperável", não "público". Após uma mudança de função ou revogação de permissões, um teste deve demonstrar que sessões antigas já não recebem chunks anteriormente permitidos.

Suporte público e instruções de trabalho internas

Uma instrução de escalamento interna pode ser perfeita, do ponto de vista técnico, para responder à dúvida de um cliente. Isso não a torna uma fonte permitida. Separe o escopo de publicação e o tipo de documento; marque por padrão os conteúdos não partilhados como excluídos. Um bot público deve, em caso de dúvida, mudar para um fluxo de contacto ou handoff em vez de tentar adivinhar detalhes internos.

Os erros de implementação mais comuns

• Taxonomia em texto livre: valores como pt, PT e pt-PT formam indesejadamente três grupos distintos.
• Aberto por padrão (Default-open): chunks sem função, estado ou tenant acabam em qualquer espaço de pesquisa.
• Lógica booleana incorreta: um operador OR entre tenant e idioma anula, na prática, o limite rígido de segurança.
• Desvio documento-chunk (Drift): ao reindexar, novos metadados não são propagados para todos os chunks.
• Apenas testes positivos: a equipa testa se um documento permitido aparece, mas não se um documento proibido muito semelhante é devidamente bloqueado.
• Resultados vazios vistos como problema do modelo: um filtro restrito não devolve nada e a aplicação deixa o modelo responder sem fontes.

Garantia da qualidade dos filtros: testar limites, não apenas correspondências

Um conjunto de testes adequado inclui, para cada resposta esperada, pelo menos um contra-candidato próximo: idioma errado, versão antiga, aprovação expirada, outro tenant ou público-alvo interno. Assim, o teste demonstra se o filtro realmente separa ou se apenas colocou o resultado correto no topo por acaso.

Métricas importantes incluem a taxa de violação de escopo, revocação (recall) no subconjunto permitido, proporção de recuperações vazias, quantidade de valores de metadados desconhecidos, latência do filtro no percentil 95, e a proporção de fallbacks e perguntas de esclarecimento. Para conteúdos restritos, a taxa de violação de escopo tolerada deve ser zero. O NIST AI RMF Core recomenda testar os sistemas de IA antes da implementação e regularmente em produção, documentando os limites de segurança, fiabilidade e contexto.

Não registe em log conteúdos desnecessários nem as perguntas completas dos utilizadores. Na maioria dos casos, bastam a versão do filtro, escopo abstrato, número de candidatos, IDs das fontes selecionadas, motivo da rejeição e resultado da pós-verificação. Isto permite diagnosticar erros sem criar uma segunda fuga de dados no sistema de observabilidade.

Lista de verificação prática antes do lançamento

1. Documentar campos de metadados canónicos, tipos de dados, valores permitidos e responsáveis.
2. Separar limites rígidos de acesso de campos funcionais de seleção.
3. Tratar sistematicamente a ausência de valores relevantes para a segurança como não autorizado.
4. Construir filtros a partir do contexto verificado do servidor e parametrizar entradas.
5. Fazer amostragem de metadados após ingestão e chunking para validação.
6. Testar casos positivos, negativos, limite e de revogação contra o índice real.
7. Medir o comportamento de pré e pós-filtragem com um k realista e escopos seletivos.
8. Encaminhar resultados vazios para perguntas de esclarecimento, fallback seguro ou transição humana (Human Handoff).
9. Versionar alterações de filtros e implementá-las em conjunto com testes de regressão do retrieval.

Os filtros de metadados RAG são, portanto, mais do que uma funcionalidade de conveniência na pesquisa. São a ligação entre o modelo de conteúdo, identidade, atualização e qualidade de recuperação. Quem define primeiro o escopo de forma determinística fornece ao ranking e ao modelo de linguagem uma base de trabalho menor, mais limpa e auditável.

Próximo passo: Escolha uma pergunta de suporte real e crie cinco fontes quase correspondentes com idioma, versão ou permissão errados. Apenas quando nenhuma delas ultrapassar o escopo de recuperação permitido é que o filtro deve avançar para o fluxo de chat em produção.

Fontes

• OpenAI: File Search e Filtragem de Metadados
• Microsoft: Filtros em Consultas Vetoriais
• Microsoft: Padrão de Filtro de Segurança
• Amazon Bedrock: API RetrievalFilter
• NIST: Estrutura de Gestão de Riscos de IA (Core)
• OWASP: Top 10 para LLM em GenAI 2026