Tudo o que você precisa para criar um chatbot real movido por um modelo de linguagem de grande porte. O artigo aborda a escolha do modelo, a engenharia de system prompts, a memória da conversa, a integração com API em Python, os erros comuns que derrubam bots em produção e como testar e escalar sem estourar seu orçamento de API.
Criar um chatbot já exigiu anos de pesquisa em PLN e montanhas de dados de treinamento. Hoje, você consegue montar um bot conversacional funcional em uma tarde, chamando a API de um LLM. A parte difícil não é mais fazer o bot responder. A parte difícil é fazer com que ele responda bem, de forma consistente, sem fugir do assunto ou alucinar fatos. Este artigo percorre cada camada desse problema, desde a escolha do modelo certo até a criação de system prompts que se sustentam em produção.
A maioria das pessoas trata os LLMs como uma caixa-preta. Você envia texto, e o texto volta. Mas entender o que acontece por dentro muda a forma como você constrói e, principalmente, a forma como depura quando algo dá errado.
Um LLM não lê palavras. Ele lê tokens, que são pedaços de texto com cerca de 3 a 4 caracteres cada. Todo modelo tem uma janela de contexto: o número máximo de tokens que ele consegue processar em uma única requisição. O GPT-4o suporta 128.000 tokens. O Llama 2 7B Chat fica limitado a 4.096. Essa diferença pesa muito quando você está construindo uma conversa com vários turnos.
💡 Regra prática: 1.000 tokens equivalem a cerca de 750 palavras. Uma conversa longa atinge o limite de contexto mais rápido do que a maioria dos desenvolvedores espera.
Quando a janela de contexto se enche, o modelo não consegue lembrar do que veio antes. Isso não é um bug. É assim que os transformers funcionam. O código da sua aplicação precisa cuidar da memória, e não o modelo.
Há um detalhe que pega todo construtor de primeira viagem: os LLMs são sem estado. Cada chamada de API é completamente independente. O modelo não tem ideia do que foi dito cinco mensagens atrás, a menos que você inclua essas mensagens explicitamente na requisição atual.
Isso significa que a "memória" do seu chatbot é totalmente responsabilidade sua. Você mantém uma lista de mensagens. Envia a lista inteira em cada chamada. O modelo enxerga contexto, não histórico. Esse único fato de arquitetura muda tudo sobre a forma como você constrói uma aplicação de chatbot.
Se você esquecer disso e guardar o estado da conversa apenas no frontend, terá um chatbot que perde toda a memória ao recarregar a página. Se você armazenar histórico demais sem aparar, vai atingir os limites de contexto em sessões longas. A abordagem certa é um armazenamento de sessões no servidor que persiste a lista de mensagens, reduz o histórico de forma inteligente e envia o trecho certo ao modelo em cada chamada.
O modelo que você escolhe define o teto de capacidade do seu chatbot. Não existe uma resposta única e certa, mas há contrapartidas claras que vale entender antes de se comprometer com uma direção de infraestrutura.
| Código aberto | Proprietário | |
|---|---|---|
| Custo | Hospedagem gratuita ou barata | Pagamento por token |
| Privacidade | Os dados ficam nos seus servidores | Dados enviados ao provedor |
| Desempenho | Varia com o tamanho do modelo | Geralmente mais forte |
| Controle | Acesso total ao fine-tuning | Somente via API |
| Tempo de configuração | Exige infraestrutura | Pronto em minutos |
Para prototipagem, os modelos proprietários vencem em velocidade. O GPT-5 e o Claude 4 Sonnet levam você rapidamente a uma demo funcionando. Para produção com requisitos rígidos de privacidade ou volume muito alto, modelos como o Llama 4 Maverick Instruct ou o Mistral 7B v0.1 rodando na sua própria infraestrutura reduzem bastante os custos.
Um chatbot é três coisas trabalhando juntas: um armazenamento de mensagens, um system prompt e uma chamada de API. Acerte esses três e todo o resto é acabamento.
O system prompt é a personalidade do seu chatbot e as regras de operação dele. Ele é executado antes de cada conversa e define o enquadramento de todas as respostas. É aqui que a maioria dos projetos de chatbot tem sucesso ou fracassa.
Um system prompt fraco: "You are a helpful assistant."
Um system prompt forte:
You are a customer support agent for a SaaS product called Orbit.
You only answer questions about Orbit's features, pricing, and troubleshooting.
If a user asks about something outside Orbit, politely redirect them.
Keep responses under 150 words unless the user explicitly asks for more detail.
Never make up pricing figures. If you do not know the answer, say so clearly
and offer to escalate to a human agent.
A diferença está na especificidade. O modelo precisa de restrições, não apenas de um papel. Restrições produzem um comportamento consistente e previsível. Papéis vagos produzem saídas vagas.
💡 Teste seu system prompt pedindo ao bot que faça coisas que ele deveria recusar. Um prompt que se sustenta diante de entradas adversárias vai se sustentar em produção.
Escreva seu system prompt como a descrição de cargo de um funcionário muito literal, que faz exatamente o que você diz e nada além disso. Cada frase que acrescenta uma restrição é uma frase que reduz a imprevisibilidade.
O seu armazenamento de mensagens é uma lista de objetos, cada um com um papel (system, user ou assistant) e um conteúdo. Uma conversa típica fica assim:
messages = [
{"role": "system", "content": "You are a helpful support agent..."},
{"role": "user", "content": "How do I reset my password?"},
{"role": "assistant", "content": "To reset your password, click..."},
{"role": "user", "content": "I do not see that button anywhere."},
]
Você acrescenta cada nova mensagem do usuário e cada resposta do assistente a essa lista. Em cada chamada à API, envia a lista completa. O modelo lê a conversa inteira e gera a próxima resposta no contexto.
Estratégia de corte: quando a lista cresce demais, corte-a antes de enviar para evitar erros de janela de contexto. Três opções:
A janela deslizante é a mais simples de implementar e funciona para a maioria dos casos. O resumo preserva o máximo de contexto, ao custo de chamadas extras à API e de mais latência.
A temperatura controla a aleatoriedade. Em 0.0, as respostas são determinísticas e muitas vezes repetitivas. Em 1.0, elas ficam criativas e propensas a fugir do assunto. Para a maioria dos chatbots, a faixa certa vai de 0.3 a 0.7.
| Parâmetro | O que controla | Valor típico |
|---|---|---|
temperature | Aleatoriedade e criatividade | 0,3 a 0,7 |
max_tokens | Limite máximo do tamanho da resposta | 512 a 2048 |
top_p | Amplitude da amostragem de tokens | 0,9 |
frequency_penalty | Penaliza frases repetidas | 0,1 a 0,3 |
O código real é mais simples do que a maioria dos tutoriais sugere. Aqui está uma implementação mínima e funcional usando o cliente da OpenAI, que é compatível com a maioria dos provedores de LLM.
pip install openai
from openai import OpenAI
client = OpenAI(api_key="your-api-key-here")
Para modelos de código aberto servidos por uma API local (como o Ollama ou o LM Studio), você troca o parâmetro base_url. O restante do código continua idêntico, o que é um dos verdadeiros benefícios do padrão de API compatível com a OpenAI que a maioria dos provedores adotou.
class Chatbot:
def __init__(self, system_prompt: str, max_turns: int = 20):
self.system_prompt = system_prompt
self.max_turns = max_turns
self.history = []
def chat(self, user_message: str) -> str:
self.history.append({"role": "user", "content": user_message})
# Keep only the last N turns to avoid context overflow
recent = self.history[-(self.max_turns * 2):]
messages = [
{"role": "system", "content": self.system_prompt}
] + recent
response = client.chat.completions.create(
model="gpt-5",
messages=messages,
temperature=0.5,
max_tokens=1024,
)
reply = response.choices[0].message.content
self.history.append({"role": "assistant", "content": reply})
return reply
Este é o laço central. Todo chatbot de produção é uma variação desse padrão, com lógica adicional por cima.
Os usuários toleram muito melhor a espera pelas respostas quando veem o texto chegando em tempo real. O streaming está integrado a todas as principais APIs de LLM e vale a pena implementá-lo desde o primeiro dia:
stream = client.chat.completions.create(
model="gpt-5",
messages=messages,
stream=True,
)
for chunk in stream:
delta = chunk.choices[0].delta.content
if delta:
print(delta, end="", flush=True)
Envie a resposta em streaming para o frontend via Server-Sent Events (SSE) ou WebSockets. A latência percebida cai de vários segundos para quase instantânea, e os usuários relatam uma satisfação bem maior com respostas em streaming do que esperando uma resposta completa.
O PicassoIA hospeda mais de 65 modelos de linguagem de grande porte, disponíveis diretamente no navegador, sem configuração de API, sem configuração de cobrança e sem necessidade de infraestrutura. Isso torna prático testar seus system prompts e a lógica do chatbot antes de escrever uma única linha de código.
Acesse a seção Large Language Models no PicassoIA. Você vai encontrar todas as grandes famílias de modelos: o GPT-5 e o GPT-4o da OpenAI, o Claude 4 Sonnet da Anthropic, o Gemini 2.5 Flash do Google, o Llama 4 Maverick Instruct da Meta, e especialistas em raciocínio como o DeepSeek R1 e o Kimi K2 Instruct.
💡 Use o Kimi K2 Instruct quando seu chatbot precisar escrever ou revisar código. Use o DeepSeek R1 quando ele precisar raciocinar sobre problemas de várias etapas, passo a passo.
O principal modo de falha em chatbots de produção é atingir o limite da janela de contexto sem nenhum código de tratamento. Quando isso acontece, a API lança um erro context_length_exceeded e o seu chatbot trava ou devolve uma página de erro genérica. Sempre implemente uma estratégia de corte ou resumo antes de lançar.
Regra simples: se o histórico da conversa estiver se aproximando de 80% do limite de contexto do modelo, com base na contagem de tokens, comece a descartar as mensagens mais antigas que não são do sistema da lista de histórico.
Bibliotecas como o tiktoken (para modelos da OpenAI) permitem contar os tokens com precisão antes de cada chamada à API. Use-as.
Instruções vagas produzem comportamento vago. Três padrões a evitar:
"Be helpful and friendly." Isso não diz ao modelo nada sobre o que ele deve ou não deve fazer.Em escala, cada token desnecessário custa dinheiro. Um system prompt com 800 tokens a mais do que o necessário custa esses 800 tokens em cada chamada à API. Com 10.000 conversas diárias, isso são 8 milhões de tokens de entrada extras por dia, cobrados à taxa de entrada do modelo. Audite seu system prompt com rigor antes do lançamento e remova qualquer instrução redundante ou prolixa.
Toda API de LLM tem limites de taxa: requisições por minuto, tokens por minuto e, em alguns casos, tetos diários. Planeje isso antes do lançamento. Com pouco tráfego, as APIs proprietárias são a escolha certa em qualidade e velocidade. Com tráfego alto, hospedar por conta própria um modelo de código aberto como o Llama 4 Maverick Instruct costuma sair bem mais barato.
Comparação aproximada de custos para um chatbot com 10.000 conversas diárias, com média de 500 tokens de saída por conversa:
| Modelo | Custo aproximado por 1M de tokens de saída | Custo diário de saída |
|---|---|---|
| GPT-4o | ~US$ 15 | ~US$ 75 |
| GPT-4o Mini | ~US$ 0,60 | ~US$ 3 |
| Claude 4 Sonnet | ~US$ 15 | ~US$ 75 |
| Llama 4 (hospedagem própria) | Somente infraestrutura | Variável |
O GPT-4o Mini merece uma avaliação séria para casos de alto volume em que toda a capacidade do GPT-4o não é estritamente necessária. Muitas tarefas de chatbot, como responder perguntas frequentes ou fazer roteamento simples, não precisam de um modelo de fronteira.
Lançar não é o fim. Você precisa de visibilidade sobre o que o seu bot está de fato dizendo para usuários reais. No mínimo, registre cada turno da conversa com:
Revise diariamente uma amostra aleatória de conversas na primeira semana. Você vai identificar falhas de prompt, alucinações e casos extremos que não apareceram durante os testes.
💡 Configure gatilhos de revisão: se um usuário enviar uma frase como "isso está errado" ou "você inventou isso", marque essa conversa para revisão manual imediata.
Quando seu chatbot estiver funcionando e implantado, estes três acréscimos o levam de demo a produto:
1. Geração aumentada por recuperação (RAG): conecte seu bot a um banco de dados vetorial com os seus próprios documentos. Em vez de depender dos dados de treinamento do modelo, ele recupera trechos relevantes e os usa como contexto antes de gerar uma resposta. É assim que você constrói um chatbot que responde com precisão perguntas sobre o seu produto específico, políticas internas ou base de conhecimento, sem inventar detalhes.
2. Guardrails: adicione uma verificação secundária que valide tanto as entradas dos usuários quanto as saídas do bot antes que qualquer coisa chegue ao usuário. Isso captura tentativas de injeção de prompt, violações de política e respostas fora do assunto antes que se tornem visíveis para o seu público. Uma camada simples de regras ou uma segunda chamada a um modelo leve resolve a maioria dos casos.
3. Suíte de avaliação: escreva um conjunto de testes com 50 a 100 pares de entrada e saída esperada, cobrindo os principais casos de uso do seu chatbot. Execute-o automaticamente após cada mudança no system prompt. Essa é a única forma confiável de pegar regressões antes que os usuários as encontrem. Testes manuais nessa escala não são realistas depois da primeira semana.
A arquitetura está clara. O código não é complicado. O que separa um chatbot que impressiona em uma demo de um que funciona de forma confiável em produção é a iteração. Mais especificamente: iteração sobre o system prompt, a estratégia de corte, a escolha do modelo e a configuração de monitoramento, tudo guiado por dados reais de conversa.
Nada disso exige escrever código antes. Você pode fazer a parte mais valiosa, encontrar o modelo certo e um system prompt que de fato se sustente, em um navegador, antes de abrir sua IDE.
O PicassoIA dá acesso direto a mais de 65 modelos de linguagem de grande porte no seu navegador, incluindo o GPT-5, o Claude 4 Sonnet, o Llama 4 Maverick Instruct, o Kimi K2 Instruct, o DeepSeek R1 e o Gemini 2.5 Flash.
Escreva seu system prompt. Escolha um modelo. Veja como ele responde de fato. Teste os casos extremos. Quebre tudo de propósito. Depois refine. É nesse ciclo de iteração que a qualidade real de um chatbot é construída, e você pode rodar o processo inteiro no PicassoIA antes de se comprometer com uma única chamada de API ou linha de código.
Os modelos estão disponíveis. Seu chatbot não vai se construir sozinho.
Escolha seu idioma
