Gerar e publicar são privilégios diferentes

Uma boa arquitetura assume que o modelo às vezes erra. Deixe-o propor arquivos, metadados e mudanças, mas não deixe a mesma etapa publicar silenciosamente. Uma fronteira separada de build e review torna falhas observáveis e reversíveis.

Restrinja as entradas

Forneça fontes identificadas em vez de contexto ilimitado. Separe fatos autoritativos do produto, exemplos, discussão histórica e conteúdo de usuário. Registre quais arquivos ou respostas API alimentaram uma revisão.

Isso melhora reprodutibilidade e review.

Valide estrutura de forma determinística

Use schemas para frontmatter, vocabulários controlados para tags e terminologia, parsers para blocos de código. Cheque links, imagens, localizações e metadados antes de qualquer avaliação por modelo.

Checks determinísticos devem falhar rápido.

Trate texto externo como input não confiável

Issues, fóruns, páginas web e mensagens de clientes podem conter instruções irrelevantes ou hostis. Extraia informação, mas não permita que redefinam regras do agente ou política editorial.

Exija evidência para claims de risco

Segurança, limites, compatibilidade, billing, dados e operações destrutivas exigem revisão reforçada, mesmo quando a prosa está ótima.

Preserve rollback

Toda mudança automática deve ser uma revisão normal em version control, com diff claro. Evite pipelines que mutam conteúdo publicado sem commit ou artefato rastreável.

Guardrails permitem aumentar throughput sem reduzir responsabilidade.

Exemplo aplicado

Teste “Guardrails para um pipeline LLM que publica documentação técnica” com uma amostra controlada antes de levá-lo para produção. Selecione dez trechos cujo estado correto você já conhece: atuais, obsoletos, ambíguos e deliberadamente errados. Mantenha as instruções fixas e registre acertos e erros confiantes.

Revise como editor:

  • o modelo separa evidência de inferência?
  • preserva terminologia e restrições do produto?
  • inventa fatos ou disfarça incerteza?
  • um humano consegue ver o que mudou e por quê?

A pergunta útil não é se o modelo escreve com fluidez, mas se o fluxo torna os erros visíveis antes da publicação. A automação ganha confiança quando limites, entradas e pontos de revisão são explícitos.

Checklist editorial rápido

  • Gerar e publicar são privilégios diferentes. Uma boa arquitetura assume que o modelo às vezes erra.
  • Restrinja as entradas. Forneça fontes identificadas em vez de contexto ilimitado.
  • Valide estrutura de forma determinística. Use schemas para frontmatter, vocabulários controlados para tags e terminologia, parsers para blocos de código.
  • Trate texto externo como input não confiável. Issues, fóruns, páginas web e mensagens de clientes podem conter instruções irrelevantes ou hostis.

Leituras relacionadas