Popule um corpus de RAG em produção

Isto é operação, não construção

Construir um pipeline de RAG do zero — chunk → embed → vector store → busca — é
um trabalho diferente de operar um em produção. Este playbook assume que o
pipeline já existe na sua aplicação. Sua tarefa aqui é ligá-lo e populá-lo
com conteúdo real, de forma segura.

Quatro realidades operacionais guiam tudo o que vem abaixo:

1. A config vem do ambiente. A chave do provedor de embedding e o endpoint do
   vector store ficam em env/credentials, nunca no código. Erre isso e nada
   indexa; vaze isso e você paga a conta de outra pessoa.
2. Publicar é indexar. Um evento de publicação dispara um callback
   after_commit que enfileira um job de embedding. Você não indexa à mão na
   operação normal — você publica, e o conteúdo aparece na busca um instante
   depois. Esse "instante depois" só acontece se o worker de jobs estiver
   rodando (veja o playbook de jobs).
3. O acervo antigo precisa de backfill. Conteúdo que existia antes do RAG —
   ou que foi publicado enquanto o worker estava fora — nunca disparou um callback
   ao vivo. Um backfill único enfileira a indexação de todo item publicado para
   que o corpus reflita o catálogo inteiro, não só o que você mexeu desde o lançamento.
4. O gating de acesso é uma fronteira de segurança, não uma regra de exibição.
   Cada ponto indexado carrega uma flag de acesso (ex.: premium) no seu payload,
   e a busca filtra por ela dentro da query. Conteúdo restrito nunca pode
   aparecer na busca semântica para quem não tem acesso.

Ao final você terá um corpus que indexa automaticamente ao publicar, espelha seu
catálogo existente, se recusa a vazar conteúdo restrito, e que você consegue
verificar com uma contagem de chunks e uma query real.