AI & Desenvolvimento··9 min de leitura·Fabiano Simm

Como integrar LLMs num SaaS existente sem reescrever a stack

Um guia técnico e pragmático para founders e CTOs que querem adicionar capacidades de LLM a um produto já em produção — sem big-bang rewrites nem promessas de vendor.

LLMSaaSintegraçãoVercel AI SDKOpenAIAnthropic

O problema com a abordagem 'big-bang'

Quando um SaaS decide adoptar LLMs, a primeira tentação é redesenhar tudo: nova base de dados vetorial, nova infra, novo backend. Seis meses depois, o produto ainda não saiu e o roadmap original acumulou dívida técnica.

Há uma alternativa mais sã: integração incremental. Identificar uma funcionalidade de alto impacto, adicionar o LLM como camada de serviço isolada, medir, e só então expandir. É o princípio de strangler fig aplicado a AI.

Este guia assume que tens um SaaS em produção — Node.js, Python, ou Rails, pouco importa — e que queres adicionar inteligência sem parar o produto.

Passo 1: Mapear os casos de uso por complexidade

Antes de tocar em código, mapeia os casos de uso num eixo de complexidade/valor. Os de baixa complexidade e alto valor são os primeiros a implementar:

  • Geração de texto estruturado a partir de dados existentes (relatórios, resumos, emails automáticos)
  • Classificação e enriquecimento de dados (categorizar tickets, extrair entidades de formulários livres)
  • Assistente de pesquisa interna com RAG sobre a vossa documentação ou base de clientes
  • Sugestões contextuais dentro de um editor ou dashboard existente

Passo 2: Isolar o LLM como serviço interno

A arquitectura recomendada para começar: um módulo dedicado (ou microserviço leve) que encapsula toda a lógica de prompting, parsing de output, e fallback. O resto da aplicação chama-o como chamaria qualquer outro serviço.

Isto garante que o código de negócio não fica acoplado ao vendor do modelo. Amanhã mudas de OpenAI para Anthropic — só alterações num único módulo.

Em TypeScript, o Vercel AI SDK é a escolha mais prática: abstrai os providers, oferece streaming out-of-the-box, e tem suporte nativo para tool calling e structured output com Zod.

Leitura relacionada

Passo 3: Structured output antes de qualquer lógica

O maior erro que vemos em integrações LLM em produção: confiar em texto livre do modelo e tentar fazer parse artesanal com regex. Funciona em demos, falha com utilizadores reais.

A solução: definir o schema de output com Zod (TypeScript) ou Pydantic (Python) desde o primeiro dia. Os providers principais suportam JSON mode e function calling para garantir conformidade.

Exemplo prático: se o LLM vai classificar um ticket de suporte, o output deve ser `{ category: 'billing' | 'technical' | 'other', confidence: number, summary: string }` — validado pelo schema, nunca string livre.

Passo 4: RAG só quando o contexto dinâmico é mesmo necessário

Retrieval-Augmented Generation (RAG) é poderoso mas adiciona complexidade: embeddings, vector store, retrieval pipeline, relevância a calibrar. Só o implementas quando o caso de uso requer contexto que muda frequentemente e é demasiado grande para caber no context window.

Para muitos SaaS B2B, o prompt com contexto estático (produto, políticas, FAQ) chega para os primeiros 80% dos casos. Começa simples.

Quando o RAG é necessário, pgvector no Postgres existente é o caminho com menos overhead para equipas pequenas. Só migra para Pinecone, Qdrant ou Weaviate quando tens razões concretas (escala, latência, filtros avançados).

Passo 5: Observabilidade desde o primeiro deploy

LLMs em produção sem observabilidade são uma caixa negra cara. O mínimo viável: logar tokens usados por request, latência, e uma amostra dos prompts + outputs para auditoria manual.

Para equipas que querem ir além: Langfuse e Langsmith são as ferramentas mais adoptadas para tracing de pipelines LLM. Ambas têm planos gratuitos suficientes para começar.

Sem este piso de visibilidade, é impossível perceber se o modelo está a regredir, onde estão os custos a crescer, ou o que está a falhar nas respostas.

Leitura relacionada

O que não fazer

Evita estes padrões que vemos frequentemente e que criam dívida técnica:

  • Prompts inline no meio de handlers de API — centraliza-os em ficheiros de template versionados
  • Zero gestão de erros para chamadas ao LLM — os modelos falham, têm rate limits, e têm latências imprevisíveis; trata-os como serviços externos que podem falhar
  • Fine-tuning como primeira solução — na maioria dos casos, prompt engineering e RAG resolvem sem o custo e a manutenção do fine-tuning
  • Guardar output do LLM em BD sem validação — sempre valida o schema antes de persistir

Perguntas frequentes

›Tenho de mudar de base de dados para usar LLMs?

Não necessariamente. A maioria dos casos começa com a BD existente. Só adiciona pgvector (Postgres) ou um vector store separado (Pinecone, Qdrant) quando o contexto dinâmico é mesmo necessário. Não optimizes prematuramente.

›OpenAI vs Anthropic vs modelo open-source — qual escolher?

Para a maioria dos SaaS B2B europeus: OpenAI GPT-4o para qualidade geral, Anthropic Claude 3.5 Sonnet para tarefas com textos longos e raciocínio estruturado, modelos open-source (Llama, Mistral) se precisas de dados on-premise ou custo zero por token em volume. Começa com API hosted e só migra para self-hosted quando tens dados reais de uso.

›Como evitar que o modelo invente informação (hallucinations)?

RAG (Retrieval-Augmented Generation) com fontes citáveis é a resposta mais robusta. O modelo só responde com base em documentos que tu controlas. Para flows críticos, adiciona verificação de output com Zod ou um segundo modelo a validar estrutura.

›Quanto custa por mês com volume real de utilização?

Depende muito do modelo e dos tokens por request. GPT-4o Mini custa ~0,15€ por milhão de input tokens — para a maioria dos SaaS B2B, os custos são inferiores a 200€/mês nos primeiros 6 meses. O artigo sobre custos reais de AI em PMEs aprofunda os cálculos.

Próximo passo

A integrar LLMs num produto existente? Ajudamos a avaliar a abordagem certa para a vossa stack — sem vender hype.

Falar com a Simmple →