Coding for AI em 2025: Guia prático de programação para IA

Todo mundo quer lançar algo com IA, mas o que separa demos de produtos é simples: qualidade consistente, custo sob controle e confiança do usuário. Se você está olhando para “Coding for AI” esperando atalhos mágicos, vai se frustrar. A boa notícia: dá para entregar valor rápido com uma base enxuta, decisões certas e métricas claras. Vou te mostrar como montar do zero um fluxo de trabalho de IA que funciona hoje, no mundo real, sem queimar orçamento nem reputação.

TL;DR: o que mudou ao codar para IA em 2025

• Comece simples: API de modelo forte + RAG bem feito. Fine-tuning entra quando o comportamento precisa ser consistente e específico.
• Métricas primeiro: defina sucesso (qualidade, latência, custo) antes de escrever código. Automatize avaliações desde o protótipo.
• Stack prática: Python para backend/ML, TypeScript para app/serviços, um vetor DB confiável e observabilidade de ponta a ponta.
• Controle de risco: guias do NIST AI RMF e ISO/IEC 42001 ajudam a organizar segurança, privacidade e auditoria sem travar a entrega.
• Otimize tokens, não só GPU: cache, compressão, streaming, batch e fallbacks reduzem conta e tempo de resposta.

Se eu tivesse que resumir tudo em uma frase: foque em programação para IA orientada por métricas e feedback do usuário, não em hype de modelo.

Passo a passo: stack, dados, prompts, avaliação, deploy e custo

Primeiro, alinhe meta de produto com capacidade técnica. Você não está treinando do zero um modelo gigante; está combinando modelos, dados, prompts e infraestrutura para resolver um problema específico de usuário.

1. Defina o problema e as métricas

   • Problema: tarefa, contexto, restrições (privacidade, compliance).
   • Métrica de sucesso: combine qualidade (ex.: precisão/groundedness), latência p95 e custo por requisição.
   • Heurística simples: Score = 0.5×Qualidade + 0.3×(1/Latência normalizada) + 0.2×(1/Custo normalizado). Vai te forçar a equilibrar.

2. Escolha de stack

   • Linguagens: Python para ML e pipelines; TypeScript para UI/APIs; Rust/Go quando latência/concorrência apertar.
   • Modelos: LLM (texto), multimodal (texto+imagem/áudio), embeddings (busca/vetores). Tenha um plano A (API) e um plano B (modelo aberto) para resiliência.
   • Infra: vetor DB (FAISS, pgvector, Milvus), cache (Redis), tracing (OpenTelemetry), feature flags para prompts/modelos.
   • Regra de bolso: comece com a melhor API que couber no orçamento para validar UX; migre parte para open-source quando padrões estiverem claros.

3. Dados e RAG (Retrieval-Augmented Generation)

   • Ingestão: limpe, remova duplicatas, extraia texto com metadados (fonte, data, permissões).
   • Chunking: 200-400 tokens com 10-20% de overlap funciona bem para a maioria dos casos de Q&A. Ajuste com base nas consultas reais.
   • Embeddings: use o modelo de embedding recomendado pelo provedor do LLM ou o top do MTEB para seu idioma/tarefa. Atualize periodicamente.
   • Busca: top-k entre 3-8 e reranking se necessário; híbrido (BM25 + vetorial) aumenta robustez.
   • Grounding: sempre inclua fonte e trechos citados no prompt; peça que o modelo responda “não encontrado” quando não houver suporte nos documentos.

4. Prompts e ferramentas

   • Template: role claro, passos curtos, formato de saída definido (JSON quando possível), limite de especulação.
   • Poucos exemplos bons > muitos medianos. Prefira exemplos do seu domínio.
   • Structured output: valide com JSON Schema; re-chame o modelo quando o schema falhar.
   • Ferramentas (function calling): descreva bem o contrato, inclua unidades e limites. Logue cada chamada.
   • Temperatura: 0-0.3 para tarefas determinísticas; 0.7+ só quando criatividade é desejável.

5. Avaliação (evals) desde o protótipo

   • Conjunto “dourado”: 50-200 casos reais, com gabarito. Mantenha versionado.
   • Métricas: exata/semântica (BLEU/ROUGE são fracas para LLMs; prefira similitude + julgamento), groundedness (checa se cita fonte), segurança (toxidade/PII), estabilidade entre versões.
   • LLM-as-judge com mitigação: dupla avaliação e desempate humano em 10-20% das amostras reduz viés.
   • Relatórios: p50/p95 de latência, custo por chamada, taxa de erro de schema, percentual de “não encontrado”.
   • Fontes: Stanford AI Index 2024 mostra a importância de medir impacto real; NIST AI RMF orienta testes contínuos de risco.

6. Produto e deploy (LLMOps)

   • Versionamento: trate modelos e prompts como código (semver e changelog). Flag por usuário/grupo.
   • Confiabilidade: retries com jitter, timeouts, circuit breaker, fallback de modelo (A→B→C).
   • Cache: por input normalizado e por trechos recuperados; invalide quando dados mudarem.
   • Observabilidade: trace cada passo (retrieval, prompt, tokens, modelo, ferramenta). Reproduzir erro importa mais que beleza do log.
   • Segurança/compliance: mascaramento de PII, avaliação de saída, auditoria. Referências: NIST AI Risk Management Framework (2023), ISO/IEC 42001:2023, acordo político do EU AI Act (2024).

7. Custo e latência

   • Corte tokens: instruções enxutas, few-shot só quando provado, compressão de contexto, títulos em vez de parágrafos quando viável.
   • Batch e streaming: agregue tarefas e entregue respostas parciais quando melhora UX.
   • Modelo certo para o job: tarefa simples? Modelo menor local/edge. Tarefa complexa? Modelo grande com retries controlados.
   • Quando treinar/fazer fine-tuning: comportamento específico e repetitivo? Vale. Conhecimento mutável? Prefira RAG.

Esses passos formam um ciclo único: dados → prompt → avaliação → produto → telemetria → melhoria. Mantenha o loop apertado.

Exemplos práticos, templates e checklists

Um protótipo útil vale mais do que 20 reuniões. Abaixo, blocos que você pode colar e adaptar hoje.

RAG mínimo em Python com embeddings + FAISS

# pip install sentence-transformers faiss-cpu unstructured pymupdf
from sentence_transformers import SentenceTransformer
import faiss, numpy as np

# 1) Carregue seus documentos e gere chunks (exemplo simplificado)
docs = [
    {"id": "pol_001", "text": "Política de reembolso: até 30 dias com nota fiscal..."},
    {"id": "pol_002", "text": "Suporte 24/7 via chat para clientes premium..."},
]

chunks = []
CHUNK_SIZE = 350  # tokens aproximados como chars para simplificar
for d in docs:
    t = d["text"]
    chunks.append({"id": d["id"], "chunk": t[:CHUNK_SIZE]})

# 2) Embeddings
model = SentenceTransformer("sentence-transformers/all-MiniLM-L6-v2")
embs = model.encode([c["chunk"] for c in chunks])

# 3) Índice vetorial
index = faiss.IndexFlatL2(embs.shape[1])
index.add(np.array(embs).astype("float32"))

# 4) Busca
q = "Como funciona o reembolso?"
q_emb = model.encode([q]).astype("float32")
D, I = index.search(q_emb, k=3)
context = "\n\n".join(chunks[i]["chunk"] for i in I[0])

# 5) Prompt simples (substitua por sua API de LLM)
prompt = f"""
Você é um assistente que responde com base APENAS no contexto.
Se não houver resposta no contexto, diga: 'não sei com base nos documentos'.

Contexto:\n{context}

Pergunta: {q}
Resposta:
"""
print(prompt)

Saída estruturada com JSON Schema (pseudo TypeScript)

type Resposta = {
  resposta: string;
  confianca: number; // 0 a 1
  fontes: { id: string; trecho: string }[];
};

const schema = {
  type: "object",
  properties: {
    resposta: { type: "string" },
    confianca: { type: "number", minimum: 0, maximum: 1 },
    fontes: {
      type: "array",
      items: {
        type: "object",
        properties: {
          id: { type: "string" },
          trecho: { type: "string" }
        },
        required: ["id", "trecho"]
      }
    }
  },
  required: ["resposta", "confianca", "fontes"]
};

// Dica: se o JSON falhar no schema, reenvie pedindo somente o campo quebrado.

Funções (tool calling) com contrato claro

// Exemplo de ferramenta para calcular frete
const tools = [
  {
    name: "calcular_frete",
    description: "Calcula frete dado CEP de origem/destino e peso em kg",
    parameters: {
      type: "object",
      properties: {
        origem: { type: "string", pattern: "^[0-9]{8}$" },
        destino: { type: "string", pattern: "^[0-9]{8}$" },
        peso_kg: { type: "number", minimum: 0.01, maximum: 50 }
      },
      required: ["origem", "destino", "peso_kg"]
    }
  }
];

// No prompt ao LLM, diga: "Use a ferramenta APENAS se tiver todos os parâmetros válidos".

Checklist de pré-produção

• Métricas definidas e baseline medido (qualidade, latência p95, custo).
• Conjunto de teste “dourado” versionado e automação de evals no CI.
• Prompts e modelos versionados com feature flags.
• Guardrails: PII masking, toxidade, blocklist de termos e domínios.
• Observabilidade: tracing completo, logs de ferramenta, auditoria de dados sensíveis.
• Planos de fallback, limites de taxa e política de erro (retries com backoff).

Cheat sheet de parâmetros

• temperature: 0-0.3 precisão; 0.7+ criatividade.
• top_p: baixe quando quiser menos outliers; não ajuste junto de temperature sem motivo.
• max_tokens: limite saída para reduzir custo e divagação.
• presence_penalty/frequency_penalty: suba para evitar repetição, mas teste contra qualidade.

Árvore de decisão rápida

• Seu conhecimento é proprietário e muda? → RAG.
• Seu comportamento precisa ser muito específico e repetível? → Fine-tuning ou instruções rígidas + exemplos.
• Latência é crítica (sub-300ms)? → Modelo menor local/edge ou pipeline híbrido.
• Risco regulatório alto? → Saídas estruturadas, validações e aprovação humana.

Comparativo simples de opções de modelo

Referências úteis: Stanford AI Index 2024 (tendências e custos), NIST AI RMF 1.0 (gestão de risco), ISO/IEC 42001:2023 (sistema de gestão de IA), HELM/CRFM (avaliação de modelos), MTEB (benchmark de embeddings).

FAQ, próximos passos e troubleshooting

FAQ

• RAG ou fine-tuning? RAG quando a verdade vem de documentos e muda; fine-tuning quando você quer comportamento estável ou estilo fixo. Combine os dois se precisar.
• Preciso de GPU? Para prototipar com API, não. Para hospedar modelo aberto grande, sim. Muitas tarefas rodam bem em CPU com modelos menores.
• Como reduzir alucinações? Contexto com fontes, instruções para “não sei”, checagens de groundedness e validação de fatos (ferramentas/buscadores) antes de responder.
• Como medir ROI? Compare custo por tarefa e tempo de entrega antes/depois + métricas de qualidade e satisfação do usuário. Registre ganhos de produtividade e resolução no primeiro contato.
• Privacidade e compliance? Mascarar PII, armazenar só o necessário, retenção curta, revisão humana em casos sensíveis e auditoria. Siga NIST AI RMF e ISO/IEC 42001.

Próximos passos por perfil

• Dev solo: pegue o exemplo de RAG, conecte a uma API de LLM e rode evals no CI. Publique um beta para 50 usuários e colete feedback real.
• Líder técnico: padronize templates de prompts, logging unificado e um repositório de evals. Crie um comitê leve de risco para revisões quinzenais.
• PM/Produto: defina tarefas onde “bom o suficiente” traz impacto rápido, crie métricas de sucesso no onboarding e teste A/B com grupos pequenos.

Troubleshooting

• Respostas lentas: reduza contexto, ative streaming, use modelo menor para pré-resumo, cacheie, faça batch, revise timeout e retrievers.
• Custo explodindo: corte few-shot, resuma documentos, normalize/compacte prompts, limite max_tokens, cache de entrada/saída e reranking.
• Baixa relevância: ajuste chunking, melhore metadados, suba top-k ou use híbrido, adicione rerank, corrija consultas (query rewriting).
• Saída inconsistente: temperatura baixa, JSON Schema, validação e reamostra. Se persistir, treine pequeno modelo ou refine instruções.
• Falhas intermitentes de API: implementa retries com backoff, circuit breaker, fallback de provedor e alerta por taxa de erro p95.

Um lembrete final: os relatórios do Stanford AI Index e o NIST AI RMF reforçam: o diferencial não é só “qual modelo você usa”, e sim como você avalia, monitora e aprende com cada interação. Em 2025, sucesso em IA é processo, não sorte.