Monte LLMs na sua empresa: configuração passo a passo

Implantar um modelo de linguagem em produção não é baixar um ZIP e executar um comando. Já vi equipes gastarem meses em uma prova de conceito que funcionava no notebook de um engenheiro e caía na primeira segunda-feira com vinte usuários simultâneos. Este guia descreve o processo real de configuração, com as decisões que importam e os pontos onde quase todos tropeçam.

Antes de tocar em qualquer coisa: defina o caso de uso e o critério de sucesso

A configuração técnica depende do trabalho que o modelo vai realizar. Não é a mesma coisa um assistente interno que responde sobre documentação corporativa (recuperação aumentada sobre PDFs) e um classificador de tickets de suporte (uma tarefa delimitada onde um modelo pequeno bem ajustado supera um grande com prompt genérico).

Escreva uma frase concreta antes de escolher fornecedor: «o comercial escreve uma pergunta sobre preços e recebe uma resposta com o link para a seção do catálogo em menos de três segundos». Se você não consegue medir isso, não consegue configurar nada com critério.

Um erro comum: equipes que começam pedindo «um ChatGPT interno» sem delimitar domínio nem fontes. O resultado é um chat que alucina com a política de férias porque ninguém lhe deu acesso ao documento correto. Delimite as fontes antes do modelo.

Decisão 1: API gerenciada, modelo aberto auto-hospedado ou híbrido

Três rotas reais, com custos e atritos distintos:

• API de um provedor cloud: você coloca em funcionamento em horas. O custo é variável por token e a latência depende da rede. Adequado para quase tudo, exceto quando há dados que não podem sair do perímetro.
• Modelo aberto na sua infraestrutura: controle total do dado, custo fixo de GPU. Requer saber operar inferência: quantização, memória de vídeo, filas de requisições. Um modelo de 7-8 bilhões de parâmetros em quantização de 4 bits roda em uma GPU de 24 GB; um de 70B precisa de várias ou de quantizações agressivas que degradam a qualidade.
• Híbrido: modelo pequeno local para classificar e rotear, modelo grande via API apenas para as consultas complexas. Reduz custo e exposição de dados.

Segundo a documentação oficial dos principais frameworks de inferência (vLLM, TGI, Ollama), o desempenho em produção depende mais do batching e da gestão do cache KV do que do modelo escolhido. Um servidor mal configurado com um modelo excelente dá pior experiência do que um bem ajustado com um modelo mediano.

O fator que ninguém orça: a GPU

Se você optar por auto-hospedar, calcule a memória antes de comprar. Regra prática: parâmetros em bilhões × bytes por parâmetro conforme a quantização (≈0,5 bytes em 4 bits, ≈1 byte em 8 bits, ≈2 bytes em 16 bits) mais o espaço para o contexto. Um 7B em FP16 ocupa cerca de 14 GB só em pesos; com contexto longo você fica sem VRAM antes do que imagina.

Decisão 2: como você fornece o conhecimento da empresa

Aqui está 80% do trabalho real. Duas abordagens:

Recuperação aumentada (RAG)

Você fragmenta documentos, gera embeddings, armazena-os em um índice vetorial e, em cada consulta, recupera os fragmentos relevantes para injetá-los no prompt. Etapas de configuração:

1. Ingestão com controle de versão. Cada documento leva metadados: fonte, data, departamento, permissões. Sem permissões nos metadados, um estagiário pode ler atas do conselho.
2. Fragmentação consciente. Fragmentos de 300-800 tokens com sobreposição. Fragmentar por caracteres quebra tabelas e listas; fragmente por estrutura (cabeçalhos, parágrafos).
3. Embeddings e reindexação. Escolha um modelo de embeddings multilíngue se houver documentos em vários idiomas. Planeje reindexar quando o corpus mudar; um índice obsoleto responde com dados de dois anos atrás sem avisar.
4. Recuperação híbrida. Combine busca semântica com busca léxica (BM25). Códigos de produto e nomes próprios falham na busca puramente vetorial.
5. Reranking e limiar. Um reranker descarta fragmentos irrelevantes. Defina um limiar: se a similaridade for baixa, o assistente deve dizer «não sei» em vez de inventar.

Ajuste fino (fine-tuning)

Útil para estilo, formato de saída e tarefas repetitivas com muitos exemplos rotulados. Não é a ferramenta para injetar conhecimento mutável: um modelo ajustado com o catálogo de janeiro continuará respondendo com o de janeiro. Para dados que mudam, RAG.

Configuração do prompt de sistema e das salvaguardas

O prompt de sistema é configuração, não redação criativa. Defina: papel, tom, limites, formato de saída e o que fazer diante da dúvida. Seja explícito com o formato se você for fazer parsing da resposta (JSON com esquema fixo, por exemplo) e valide a saída com um parser antes de mostrá-la ao usuário.

Salvaguardas mínimas que você deve configurar:

• Filtro de entrada e saída para dados pessoais conforme a política interna.
• Limite de comprimento de contexto e de tokens de saída (evita custos descontrolados).
• Registro de conversas com retenção definida e acesso auditado.
• Rate limiting por usuário e por IP.
• Botão de «reportar resposta incorreta» que alimente uma fila de revisão.

Um detalhe que você descobre em produção: os usuários colam conversas completas de outros chats no prompt. Sem limite de comprimento, o custo por sessão se multiplica e o modelo se distrai com contexto irrelevante.

Integração com os sistemas da empresa

O assistente raramente vive isolado. Configuração típica:

1. Camada de orquestração (backend próprio ou framework de agentes) que recebe a requisição, decide se consulta o índice, chama uma ferramenta ou responde diretamente.
2. Conectores para sistemas internos via API com credenciais de serviço somente leitura e permissões mínimas. Nunca dê ao modelo credenciais de escrita sobre o ERP na primeira versão.
3. Autenticação e herança de permissões. O assistente deve responder apenas com o que o usuário pode ver. Isso se implementa na camada de recuperação, não no prompt: pedir ao modelo que «não revele dados confidenciais» não é um controle de acesso.
4. Observabilidade. Traces por requisição: tokens de entrada e saída, latência, fragmentos recuperados, custo estimado. Sem isso você não consegue otimizar nem justificar o gasto.

Teste com dados reais antes de abrir a porta

Monte um conjunto de avaliação com perguntas reais de usuários e respostas esperadas. Meça: precisão da resposta, taxa de «não sei» corretos, latência percentil 95 e custo médio por consulta. Segundo estudos do setor, uma parte significativa das falhas em assistentes corporativos vem da recuperação, não da geração: o modelo responde bem a um fragmento errado.

Teste também os casos-limite: perguntas ambíguas, requisições fora do domínio, tentativas de manipulação do prompt. E revise o comportamento com documentos digitalizados mal escaneados: o OCR sujo gera respostas com números corrompidos.

Implantação gradual e manutenção

Comece com um grupo piloto de dez ou vinte pessoas de um único departamento. Colete feedback durante duas semanas, ajuste o prompt e o corpus, e só então amplie. Tenha um plano de reversão: poder desativar o assistente sem quebrar o fluxo de trabalho da equipe.

Manutenção contínua imprescindível: reindexar quando os documentos mudarem, revisar custos semanais, monitorar latência e atualizar o modelo quando aparecer uma versão melhor apenas após passar pela avaliação. Trocar de modelo sem avaliar é a forma mais rápida de degradar um sistema que funcionava.

O que esta abordagem não resolve

Um LLM configurado assim não substitui um sistema de regras em processos onde a exatidão é obrigatória (cálculo de folha de pagamento, conformidade normativa com números). Também não é confiável para raciocínio matemático complexo sem ferramentas externas. E não elimina a necessidade de revisão humana em comunicações externas sensíveis.

A configuração passo a passo que funciona é a que começa delimitada, mede e amplia apenas o que demonstra valor. O resto é gasto em tokens.