Metadados, filtros e roteamento

Quando você indexa um chunk, você está guardando dois tipos de informação: o conteúdo semântico (capturado pelo embedding) e o contexto do documento (capturado pelos metadados). O embedding responde o que o texto significa. Os metadados respondem de onde veio, quando, para quem e com que permissão.

Exemplos práticos de campos úteis:

| Campo | Exemplo | Uso |

|---|---|---|

| tenant_id | cliente-acme | Isolar dados por cliente |

| doc_type | contrato, faq, manual | Rotear para coleção certa |

| created_at | 2024-11-01 | Filtrar por janela temporal |

| author | juridico@empresa.com | Auditoria e proveniência |

| permission_level | public, internal, confidential | Controle de acesso |

| language | pt-BR | Evitar mistura de idiomas |

| source_uri | s3://bucket/doc.pdf | Citações e rastreabilidade |

Esses campos são anexados no momento da ingestão — junto com o vetor — e ficam armazenados no índice (OpenSearch, Pinecone, pgvector). Na busca, eles viram cláusulas de filtro que reduzem o espaço de busca antes do ranqueamento por similaridade. Isso melhora precisão e velocidade ao mesmo tempo.

Multi-tenant em RAG tem dois padrões principais, e a escolha afeta segurança, custo e complexidade operacional:

Índice compartilhado com filtro por tenant_id: todos os clientes no mesmo índice OpenSearch, mas toda query inclui obrigatoriamente filter: { term: { tenant_id: "acme" } }. É mais barato e simples de operar, mas exige disciplina absoluta — uma query sem o filtro vaza dados entre tenants. Use quando o volume por tenant é pequeno e você confia na camada de aplicação.

Índice separado por tenant: cada cliente tem seu próprio índice (ou namespace, no Pinecone). O isolamento é físico — impossível vazar por bug de filtro. Custo maior, mas o modelo de segurança é muito mais robusto. Use quando os dados são sensíveis ou regulados (saúde, financeiro, jurídico).

Além do tenant_id, o controle de acesso por permission_level segue a mesma lógica: o token JWT do usuário carrega seus roles, a camada de aplicação traduz isso em filtros de metadados, e o índice nunca retorna chunks que o usuário não pode ver. Isso não substitui IAM e políticas de bucket no S3 — é uma camada adicional. Na Lição 11 (guardrails) e no Módulo 3 vamos aprofundar o modelo de segurança completo.

Um erro clássico: confiar que o LLM vai 'ignorar' contexto que ele não deveria ver. Ele não ignora. Se o chunk chegou no contexto, o modelo pode usá-lo. O filtro tem que acontecer antes da recuperação.

Nem toda pergunta deve ir para o mesmo índice. Um sistema com documentos técnicos, FAQs de suporte e contratos jurídicos se beneficia de um router que decide, antes da busca vetorial, qual coleção consultar.

O router pode ser tão simples quanto uma classificação por palavras-chave ou tão sofisticado quanto um LLM pequeno que classifica a intenção da query. Na prática, começo com um classificador leve (regex ou um modelo de classificação de texto) e só subo para LLM se a precisão for insuficiente.

A saída do router é um conjunto de filtros de metadados: { doc_type: "contrato", tenant_id: "acme", created_at: { gte: "2023-01-01" } }. Esses filtros são passados diretamente para a query do OpenSearch ou para o filter do Knowledge Bases.

Um padrão útil é o roteamento por confiança: se o classificador tem alta confiança, vai direto para um índice específico; se a confiança é baixa, faz busca em múltiplos índices e usa reranking (Lição 05) para consolidar. Isso evita respostas vazias quando a query é ambígua.

Detalhe importante: o roteamento não substitui a busca híbrida — ele acontece antes dela. Você roteia para a coleção certa, depois executa busca híbrida + reranking dentro dessa coleção.