Prompt como Unidade Arquitetural
Pensando em blocos de construção
Mudança de Paradigma
Um prompt não é texto — é uma unidade arquitetural com interface, contrato de comportamento, dependências e responsabilidades definidas.
Visão Tradicional
- • Prompt = texto que gera resposta
- • Sucesso = resposta "boa"
- • Iteração = ajustar palavras
- • Escala = copiar e colar
Visão Arquitetural
- • Prompt = componente com contrato
- • Sucesso = comportamento previsível
- • Iteração = refinar interface
- • Escala = composição e reuso
Anatomia de um Prompt como Componente
┌─────────────────────────────────────────────────────┐ │ PROMPT COMPONENT: "order_analyzer" │ ├─────────────────────────────────────────────────────┤ │ INTERFACE │ │ ├─ Input: OrderData, CustomerHistory │ │ ├─ Output: AnalysisResult (structured) │ │ └─ Errors: InsufficientData, AmbiguousOrder │ ├─────────────────────────────────────────────────────┤ │ CONTRACT │ │ ├─ Preconditions: order.status == "pending" │ │ ├─ Postconditions: result.confidence > 0.8 │ │ └─ Invariants: no side effects │ ├─────────────────────────────────────────────────────┤ │ DEPENDENCIES │ │ ├─ Requires: product_catalog (context) │ │ ├─ Requires: pricing_rules (context) │ │ └─ Optional: customer_preferences │ ├─────────────────────────────────────────────────────┤ │ IMPLEMENTATION │ │ └─ [prompt template with slots] │ └─────────────────────────────────────────────────────┘
Benefícios da Visão Arquitetural
Arquiteturas Mono-Prompt vs Multi-Prompt
Decidindo a estrutura do sistema
Mono-Prompt
Um único prompt que lida com toda a complexidade. Contexto completo em uma chamada.
Multi-Prompt
Múltiplos prompts especializados que se comunicam. Decomposição de responsabilidades.
Matriz de Decisão
| Critério | Mono | Multi |
|---|---|---|
| Tarefa simples e bem definida | ✓ | — |
| Múltiplas etapas dependentes | — | ✓ |
| Latência crítica | ✓ | — |
| Reuso de componentes | — | ✓ |
| Rastreabilidade de decisões | — | ✓ |
Camadas Arquiteturais de Sistemas LLM
Separação de responsabilidades
Arquitetura em Camadas
┌─────────────────────────────────────────────────────┐ │ PRESENTATION LAYER │ │ • Interface com usuário │ │ • Formatação de entrada/saída │ │ • Validação de input │ ├─────────────────────────────────────────────────────┤ │ ORCHESTRATION LAYER │ │ • Roteamento de requests │ │ • Composição de prompts │ │ • Gestão de fluxo │ ├─────────────────────────────────────────────────────┤ │ BUSINESS LOGIC LAYER │ │ • Skills especializadas │ │ • Regras de negócio │ │ • Transformações de dados │ ├─────────────────────────────────────────────────────┤ │ CONTEXT LAYER │ │ • Gestão de contexto │ │ • RAG / Retrieval │ │ • Memory management │ ├─────────────────────────────────────────────────────┤ │ MODEL LAYER │ │ • Abstração de LLM │ │ • Fallbacks │ │ • Rate limiting │ └─────────────────────────────────────────────────────┘
Princípio: Separation of Concerns
Cada camada tem responsabilidade única. Mudanças em uma camada não afetam outras. Permite evolução independente.
Princípio: Dependency Inversion
Camadas superiores não dependem de implementações específicas. Abstrações permitem trocar LLMs ou fontes de dados.
Contratos de Comportamento entre Prompts
Garantias e expectativas
Contratos definem o que um prompt garante fazer e o que ele espera receber. Sem contratos, sistemas de prompt são frágeis.
Elementos de um Contrato
Preconditions
O que deve ser verdade ANTES de chamar o prompt.
input.length < 10000
Postconditions
O que será verdade DEPOIS da execução.
output.format == "json"
Invariants
O que NUNCA muda durante a execução.
no_external_calls
Error Conditions
Como falhas são sinalizadas.
throws: AmbiguousInput
Exemplo de Contrato Documentado
/** * @contract SentimentAnalyzer * * @precondition text.length > 0 && text.length < 5000 * @precondition language in ["pt", "en", "es"] * * @postcondition result.sentiment in ["positive", "negative", "neutral"] * @postcondition result.confidence >= 0.0 && result.confidence <= 1.0 * @postcondition result.reasoning.length > 0 * * @invariant deterministic for same input (temperature=0) * @invariant no PII in output * * @throws EmptyInputError if text is empty * @throws UnsupportedLanguageError if language not supported * @throws LowConfidenceError if confidence < 0.5 */
Padrões Arquiteturais Recorrentes
Soluções comprovadas
Chain of Responsibility
Prompts em cadeia onde cada um pode resolver ou passar adiante.
Pipeline
Transformações sequenciais onde output de um é input do próximo.
Supervisor
Um prompt coordena e valida trabalho de outros prompts.
Reflection
Prompt analisa e melhora seu próprio output iterativamente.
Quando Usar Cada Padrão
Análise de Arquiteturas Reais
Estudos de caso de produção
Case: Assistente de Suporte Técnico
USER QUERY
│
▼
┌─────────────────┐
│ INTENT ROUTER │ ← Classifica intenção
└────────┬────────┘
│
┌────┴────┬────────────┐
▼ ▼ ▼
┌───────┐ ┌───────┐ ┌──────────┐
│ FAQ │ │TROUBLE│ │ ESCALATE │
│ MATCH │ │ SHOOT │ │ TO HUMAN │
└───┬───┘ └───┬───┘ └────┬─────┘
│ │ │
└────┬────┴──────────┘
▼
┌─────────────────┐
│ FORMATTER │ ← Formata resposta
└────────┬────────┘
▼
┌─────────────────┐
│ SAFETY CHECK │ ← Valida antes de enviar
└─────────────────┘
Case: Sistema de Code Review
PR DIFF
│
▼
┌─────────────────────────────────────┐
│ SUPERVISOR │
│ "Coordinate review, aggregate" │
└────────────────┬────────────────────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│SECURITY│ │ STYLE │ │ LOGIC │
│ CHECK │ │ CHECK │ │ CHECK │
└───┬────┘ └───┬────┘ └───┬────┘
│ │ │
└─────┬─────┴───────────┘
▼
┌─────────────────────────────────────┐
│ AGGREGATOR │
│ "Consolidate, prioritize issues" │
└────────────────┬────────────────────┘
▼
┌─────────────────────────────────────┐
│ FORMATTER │
│ "Format as GitHub PR comment" │
└─────────────────────────────────────┘
Exercício: Analise a Arquitetura
Para cada case study, identifique:
- 1. Qual padrão arquitetural foi usado?
- 2. Quais são os contratos entre componentes?
- 3. Onde estão os pontos de falha?
- 4. Como você melhoraria a arquitetura?