Os grandes modelos de linguagem estão a transformar o software empresarial — mas integrá-los em sistemas de produção exige mais do que uma chamada a uma API. Este guia cobre os padrões de arquitetura, os mecanismos de segurança e as práticas operacionais que separam as demos de protótipo dos sistemas de produção fiáveis.
RAG: o padrão fundamental
Retrieval-Augmented Generation (RAG) é o padrão de LLM mais comum nas empresas. Em vez de depender apenas dos dados de treino do modelo, o RAG recupera documentos relevantes das tuas próprias fontes de dados e inclui-os no contexto do prompt.
Porque é que o RAG funciona: ancora as respostas do LLM nos teus dados reais, reduz as alucinações, mantém a informação atualizada sem retreino e respeita os controlos de acesso aos dados.
Arquitetura: os documentos são divididos em fragmentos (chunks), convertidos em vetores através de embeddings e guardados numa base de dados vetorial (Pinecone, Weaviate, pgvector). No momento da consulta, a pergunta do utilizador é convertida num embedding, os fragmentos semelhantes são recuperados e tanto a pergunta como o contexto recuperado são enviados para o LLM.
Decisões-chave: - Tamanho dos fragmentos (512-1024 tokens é um bom ponto de partida) - Modelo de embeddings (OpenAI ada-002, Cohere ou alternativas open source) - Estratégia de recuperação (semelhança semântica, híbrida com pesquisa por palavras-chave, reranking) - Gestão da janela de contexto (quantos fragmentos incluir)
Prompt engineering para produção
Os prompts de produção são diferentes das experiências no playground:
- Os system prompts definem o papel do assistente, as suas restrições e o formato de saída
- Os exemplos few-shot melhoram a consistência das saídas estruturadas
- Os esquemas de saída (modo JSON) tornam as respostas processáveis por máquina
- As instruções chain-of-thought melhoram o raciocínio nas consultas complexas
Coloca os teus prompts sob controlo de versões junto ao teu código. Regista as alterações aos prompts da mesma forma que registas as alterações ao código — com mensagens de commit, revisões e capacidade de rollback.
Guardrails e segurança
As aplicações empresariais de LLM precisam de várias camadas de segurança:
Filtragem de entrada — Bloqueia tentativas de prompt injection, dados pessoais (PII) nas consultas e pedidos fora do tema antes de chegarem ao modelo.
Validação de saída — Verifica as respostas quanto a factos alucinados, fugas de PII, conteúdo nocivo e conformidade com o formato antes de as devolver aos utilizadores.
Citações e atribuição — Quando usas RAG, inclui referências às fontes para que os utilizadores possam confirmar as afirmações nos documentos originais.
Limitação de pedidos e controlo de custos — Define orçamentos de tokens por utilizador e por equipa para evitar custos descontrolados.
Gestão de custos
Os custos das APIs de LLM crescem com a utilização. As estratégias de produção incluem:
- Cache de prompts para consultas repetidas
- Modelos mais pequenos para tarefas simples (usa o GPT-4 para raciocínio complexo e o GPT-3.5/Haiku para classificação)
- Respostas em streaming para melhorar a latência percebida sem alterar o custo
- Processamento em lote para cargas de trabalho não interativas, com tarifas por token mais baixas
Monitorização e avaliação
Acompanha estas métricas nos sistemas de LLM em produção:
- Latência (p50, p95, p99) — os utilizadores esperam respostas em menos de 2 segundos
- Utilização de tokens por pedido e por utilizador
- Relevância da recuperação — estão a ser devolvidos os documentos certos?
- Feedback dos utilizadores — polegar para cima/para baixo nas respostas
- Taxa de alucinações — recolhe amostras e revê manualmente as respostas todas as semanas
Por onde começar
- 1Começa com um caso de uso restrito e bem definido (perguntas e respostas internas são o ideal)
- 2Constrói um pipeline RAG com a tua documentação existente
- 3Adiciona guardrails antes de o expores aos utilizadores
- 4Coloca-o em produção com monitorização e recolha de feedback
- 5Itera com base em dados de utilização reais
A ideia-chave: a integração de LLM é um problema de engenharia de software, não um problema de ciência de dados. O modelo é um componente — o valor está no sistema que constróis à volta dele.