Introdução

Em AI Internals - Como LLMs Funcionam ficamos dentro da stack do modelo: tokens entram, next-token prediction roda, sampling sai.

Esta parte sobe uma camada. Prompt não é snippet mágico de texto. É uma estratégia de montagem de contexto: quais instruções o modelo vê primeiro, quais fatos entram no request e qual formato de saída é válido para o seu app consumir.

Quando essa camada é bagunçada, o comportamento parece aleatório e a culpa cai no modelo. Quando essa camada é disciplinada, o mesmo modelo fica muito mais controlável.

Prompting é engenharia de contexto

Um request de chat é uma lista de mensagens com role. A stack de serving achata essas mensagens com um chat template, tokeniza, e então roda prefill e decode.

Então "prompt engineering" é principalmente responder três perguntas concretas:

1. Quais instruções são estáveis entre requests?
2. Quais fatos específicos deste request devem ser injetados?
3. Como forçar um formato de saída que o código downstream consiga confiar?

O modelo não vê seu banco, seu estado interno ou suas regras de negócio a menos que você serialize isso explicitamente no contexto. Se uma regra importa, ela precisa virar tokens.

Roles e precedência de instruções

A maioria das APIs de chat expõe roles system, user e assistant (além de mensagens de tool/function quando necessário). Na prática:

• system é onde comportamento estável deve ficar: voz, restrições, contrato de resposta, limites de segurança.
• user carrega a tarefa ativa.
• assistant no histórico é saída anterior do modelo e pode influenciar turnos futuros sem você perceber quando o histórico cresce demais.

Pense em precedência, não em feeling:

1. Coloque restrições duras no system.
2. Coloque detalhes da tarefa no user.
3. Mantenha histórico só quando ele adiciona estado necessário.

Se você espalha regras centrais em dez turnos de user, fica mais fácil diluir, contradizer ou truncar essas regras quando a janela de contexto aperta.

Um contrato de mensagens que funciona

Você não precisa de prompts gigantes. Precisa de um contrato estável com seções claras e regras explícitas de saída.

Esse formato funciona bem para tarefas de controle:

System:
- Role: o que o modelo está representando
- Constraints: regras inegociáveis
- Output contract: schema ou formato exato

User:
- Objective: o que fazer agora
- Input data: payload bruto
- Success criteria: o que significa "bom" neste request

A mesma chamada em Go, Python e TypeScript retornando JSON estrito:

package main

import (
"bytes"
"encoding/json"
"fmt"
"io"
"net/http"
"os"
)

func main() {
body, _ := json.Marshal(map[string]any{
  "model": "gpt-4.1-mini",
  "response_format": map[string]any{
    "type": "json_object",
  },
  "messages": []map[string]string{
    {
      "role": "system",
      "content": "You classify support tickets. Return JSON with fields: priority, category, reason.",
    },
    {
      "role": "user",
      "content": "Ticket: Checkout fails with 500 after payment authorization.",
    },
  },
})

req, _ := http.NewRequest(
  "POST",
  "https://api.openai.com/v1/chat/completions",
  bytes.NewReader(body),
)
req.Header.Set("Authorization", "Bearer "+os.Getenv("OPENAI_API_KEY"))
req.Header.Set("Content-Type", "application/json")

res, err := http.DefaultClient.Do(req)
if err != nil {
  panic(err)
}
defer res.Body.Close()

raw, _ := io.ReadAll(res.Body)
fmt.Println(string(raw))
}

O ponto não é a frase específica. O ponto é que a mensagem de system define formato de saída e seu app valida o resultado antes de confiar nele.

Montagem de contexto: o que entra e o que sai

Contexto maior não é automaticamente contexto melhor. Cada token extra traz custo, latência e competição na attention.

Um pipeline de montagem útil é:

1. Começar pelas regras estáveis de system.
2. Adicionar só o turno de user necessário para essa tarefa.
3. Injetar snippets curtos e relevantes de retrieval (não documentos inteiros).
4. Incluir resultados de tools apenas quando eles importam para a resposta atual.
5. Podar histórico antigo de forma agressiva.

Esse check de orçamento de tokens deve ser explícito no código. Reserve tokens de saída primeiro, depois encaixe os tokens de entrada no orçamento restante. Se fizer o contrário, aparece finish_reason: "length" e resposta cortada.

Padrões que costumam funcionar

Três padrões melhoram confiabilidade de forma consistente:

1) System prompts com restrições primeiro

Comece pelo que é inegociável e pelo contrato de formato antes de preferências de estilo.

You are an incident triage assistant.
Rules:
1) Use only provided evidence.
2) If evidence is missing, say "insufficient_evidence".
3) Output JSON with keys: severity, hypothesis, next_action.

2) Blocos de entrada com delimitadores

Envolva entradas brutas com delimitadores claros para reduzir mistura acidental com instruções.

Analyze this payload:
<ticket>
...
</ticket>

3) Few-shot só quando o comportamento é ambíguo

Exemplos são poderosos, mas caros em tokens. Use um ou dois exemplos direcionados para formatação difícil ou fronteiras de classificação, não uma biblioteca enorme de demonstrações.

Comparação: prompts curtos vs prompts estruturados

A maioria dos sistemas de produção fica no meio: contrato estruturado com exemplos mínimos.

Modos de falha que você depura na camada de prompt

Antes de trocar de modelo, cheque:

• Saída não é JSON válido: contrato vago demais ou sem schema/validação no app.
• Modelo ignora regra: regra enterrada no texto de user em vez de estar no system.
• Respostas derivam em chats longos: turnos antigos de assistant poluindo contexto.
• Detalhes inventados: retrieval ausente ou snippets irrelevantes dominando.
• Truncamento repentino: sem reserva de tokens de saída ou poda ruim de histórico.

Qualidade de prompt é principalmente um problema de sistema. Montagem melhor de contexto e validação explícita batem reescrever infinitamente o mesmo parágrafo de instruções.

Conclusão

Prompts são um pipeline de montagem de contexto, não um concurso de frase bonita. Restrições estáveis no system, seleção enxuta de entrada e contratos explícitos de saída deixam o comportamento mais previsível com o mesmo modelo por baixo.

No próximo vamos para Embeddings & Retrieval — como buscar os fatos certos antes da geração, em vez de encher a janela de contexto com documentos inteiros.