Autor defende decidir antes o que gerar de imagem para não perder controle

De uma geração impressionante a uma operação repetível

Darko Trpevski descreve a evolução de um pipeline de geração de imagens que usa IA por trás do KeepPost, uma ferramenta que produz conteúdo para diferentes marcas, fotos, formatos e campanhas. A primeira versão era simples: fornecer ao modelo uma imagem de origem, um logotipo, textos e instruções de composição, e deixar que ele gerasse o resultado. Funcionava bem para uma imagem única, mas se mostrava insuficiente quando a exigência passou a ser repetibilidade: o logotipo precisava ficar onde a marca determina, o produto da foto original não podia mudar, textos obrigatórios precisavam sobreviver à geração e regras de marca tinham que se manter consistentes entre publicações.

A tentativa inicial de resolver tudo com prompts mais detalhados falhou. O diagnóstico do autor: o problema não era falta de detalhe, mas pedir a um modelo probabilístico decisões que não precisavam ser probabilísticas.

Separar o que o modelo decide do que o código impõe

A mudança central foi classificar cada decisão do pipeline entre o que deve ser fixado por configuração e o que é legítimo deixar sob o julgamento criativo do modelo.

Fixado por configuração, não pelo modelo: proporção de saída (ditada pelo canal de uso, não por gosto), ativos obrigatórios, posicionamento do logotipo (posição e tamanho exatos definidos pela marca, como coordenadas em um JSON estruturado), regiões protegidas do canvas e texto obrigatório, que deve aparecer exatamente como escrito.

Deixado ao modelo: adaptação de cena, iluminação, extensão de fundo, integração de objetos e direção criativa geral - exatamente onde a criatividade agrega valor.

O autor nota uma consequência contraintuitiva: quando os modelos de imagem melhoraram em seguir instruções, a reação natural foi delegar mais responsabilidades a eles; em partes do pipeline ele fez o oposto, porque melhorias na geração não tornam requisitos determinísticos menos determinísticos.

Decisões híbridas e a armadilha do prompt

Alguns casos ficam no meio. Composição é um deles: o modelo é bom em entender semanticamente que o sujeito ocupa um lado da imagem e que texto ali cobriria o produto - algo que coordenadas fixas não resolvem bem. O padrão adotado é fazer o modelo propor um plano de composição como dados estruturados (região do sujeito, área de texto preferida, direção criativa) e validar esse plano em código antes da geração. O autor considera esse modelo-propõe-código-valida um limite melhor que os dois extremos: codificar tudo manualmente ou dar controle total ao modelo.

Ele também alerta contra tratar toda saída ruim como problema de prompt - melhorar o texto, adicionar instruções, criar mais parágrafos. Às vezes funciona, mas o prompt cresce, as restrições interagem e a aplicação poderia simplesmente impor o comportamento diretamente. A pergunta de depuração mais útil passou a ser: o modelo realmente precisa decidir isso?

Preservação da fonte, contexto de marca e validação

A imagem de origem é tratada como dado de entrada que carrega verdade, não apenas inspiração: se um restaurante envia a foto de um prato específico, gerar uma versão mais atraente que mude o prato produz um resultado tecnicamente impressionante e inútil para o cliente. O modelo tem liberdade em torno do sujeito, mas pouca liberdade sobre o sujeito - instruções como "mantenha o produto inalterado" continuam sendo interpretações de um modelo generativo.

Outra separação: contexto de marca (mood, tipografia, paleta, estilo fotográfico) é sinal útil para geração, mas "o logotipo vai aqui" é uma regra, e misturar as duas coisas em um único prompt esconde tipos de informação diferentes em linguagem natural.

Com a geração automatizada, a validação por inspeção manual não escala. O pipeline passou a verificar formato, presença de elementos obrigatórios, preservação de ativos protegidos e restrições de composição - nem toda checagem é determinística, mas geração e aceitação são problemas distintos. O modelo dizendo "pronto" não é o mesmo que a aplicação decidir que o resultado é aceitável.

Um problema de controle, não de imagem

No fim, o autor reenquadra o trabalho: depois que a qualidade ficou boa, o problema central virou controlar variância. Variância é valiosa na iluminação e na integração de objetos; é modo de falha quando se trata de uma "interpretação criativa" de uma coordenada de logotipo.

A lição se estende a outros sistemas com LLM: um agente não precisa decidir algo só porque pode; um pipeline RAG não precisa de LLM para transformações que código determinístico resolve melhor; um esquema de saída estruturado não deveria ser substituído por instruções pedindo campos; regras de negócio não deveriam migrar silenciosamente para prompts. A pergunta arquitetural correta não é "quanto posso fazer o modelo fazer?", e sim "onde o raciocínio probabilístico realmente melhora o sistema?". O pipeline resultante é menos mágico - e, segundo o autor, provavelmente por isso ele confia mais nele.