Todo lo que necesitas para crear un chatbot real impulsado por un modelo de lenguaje (LLM). Este artículo cubre la elección del modelo, la ingeniería de prompts de sistema, la memoria de conversación, la integración de la API en Python, los errores habituales que hacen caer los bots en producción y cómo probar y escalar sin agotar tu presupuesto de API.
Antes, crear un chatbot significaba años de investigación en PLN y montañas de datos de entrenamiento. Hoy, puedes montar un bot conversacional funcional en una tarde llamando a la API de un LLM. La parte difícil ya no es lograr que responda. La parte difícil es que responda bien, de forma constante, sin desviarse del tema ni inventarse datos. Este artículo recorre cada capa de ese problema, desde elegir el modelo adecuado hasta diseñar prompts de sistema que aguanten en producción.
Mucha gente trata a los LLM como una caja negra. Envías texto y sale texto. Pero entender lo que ocurre por dentro cambia la forma de construir y, sobre todo, la forma de depurar cuando algo sale mal.
Un LLM no lee palabras. Lee tokens, fragmentos de texto de unos 3-4 caracteres cada uno. Cada modelo tiene una ventana de contexto: el número máximo de tokens que puede procesar en una sola solicitud. GPT-4o maneja 128.000 tokens. Llama 2 7B Chat se queda en 4.096. Esa diferencia importa muchísimo cuando estás construyendo una conversación de varios turnos.
💡 Regla práctica: 1.000 tokens equivalen aproximadamente a 750 palabras. Una conversación larga alcanza el límite de contexto antes de lo que la mayoría de los desarrolladores espera.
Cuando la ventana de contexto se llena, el modelo no puede recordar lo que vino antes. No es un error. Así funcionan los transformers. Tu código de aplicación debe gestionar la memoria, no el modelo.
Hay algo con lo que tropieza todo el que construye por primera vez: los LLM no tienen estado. Cada llamada a la API es completamente independiente. El modelo no sabe qué se dijo cinco mensajes atrás, a menos que incluyas explícitamente esos mensajes en la solicitud actual.
Esto significa que la "memoria" de tu chatbot es responsabilidad exclusiva tuya. Mantienes una lista de mensajes. Envías la lista completa en cada llamada. El modelo ve contexto, no historial. Este hecho arquitectónico cambia por completo la forma de construir una aplicación de chatbot.
Si ignoras esto y guardas el estado de la conversación solo en el frontend, tendrás un chatbot que pierde toda su memoria al recargar la página. Si guardas demasiado historial sin recortarlo, alcanzarás los límites de contexto en sesiones largas. El enfoque correcto es un almacén de sesiones en el servidor que conserve la lista de mensajes, la recorte de forma inteligente y envíe el fragmento adecuado al modelo en cada llamada.
El modelo que elijas determina el techo de capacidad de tu chatbot. No hay una única respuesta correcta, pero sí hay contrapartidas claras que conviene entender antes de comprometerte con una dirección de infraestructura.
| Código abierto | Propietarios | |
|---|---|---|
| Costo | Alojamiento gratuito o barato | Pago por token |
| Privacidad | Los datos se quedan en tus servidores | Los datos se envían al proveedor |
| Rendimiento | Varía según el tamaño del modelo | Generalmente más sólido |
| Control | Acceso completo al ajuste fino | Solo API |
| Tiempo de puesta en marcha | Necesita infraestructura | Listo en minutos |
Para prototipar, los modelos propietarios ganan en rapidez. GPT-5 y Claude 4 Sonnet te llevan a una demo funcional enseguida. Para producción con requisitos estrictos de privacidad o un volumen muy alto, modelos como Llama 4 Maverick Instruct o Mistral 7B v0.1 ejecutados en tu propia infraestructura reducen los costos de forma notable.
Un chatbot son tres cosas que trabajan juntas: un almacén de mensajes, un prompt de sistema y una llamada a la API. Si dominas esas tres, todo lo demás es pulido.
El prompt de sistema es la personalidad de tu chatbot y sus reglas de funcionamiento. Se ejecuta antes de cada conversación y fija el marco de todas las respuestas. Aquí es donde la mayoría de los proyectos de chatbot tienen éxito o fracasan.
Un prompt de sistema débil: "You are a helpful assistant."
Un prompt de sistema sólido:
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.
La diferencia está en la precisión. El modelo necesita restricciones, no solo un rol. Las restricciones producen un comportamiento constante y predecible. Los roles vagos producen resultados vagos.
💡 Prueba tu prompt de sistema pidiendo al bot que haga cosas que debería rechazar. Un prompt que resiste entradas adversarias también resistirá en producción.
Escribe tu prompt de sistema como una descripción de puesto para un empleado muy literal que hace exactamente lo que dices y nada más. Cada frase que añade una restricción es una frase que reduce la imprevisibilidad.
Tu almacén de mensajes es una lista de objetos, cada uno con un rol (system, user o assistant) y contenido. Una conversación típica tiene este aspecto:
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."},
]
Añades cada mensaje nuevo del usuario y cada respuesta del asistente a esta lista. En cada llamada a la API envías la lista completa. El modelo lee toda la conversación y genera la siguiente respuesta en contexto.
Estrategia de recorte: cuando la lista crece mucho, recórtala antes de enviarla para evitar errores de ventana de contexto. Hay tres opciones:
La ventana deslizante es la más sencilla de implementar y funciona en la mayoría de los casos. El resumen conserva más contexto, a costa de llamadas adicionales a la API y de más latencia.
La temperatura controla la aleatoriedad. Con 0.0, las respuestas son deterministas y a menudo repetitivas. Con 1.0, son creativas y propensas a desviarse del tema. En la mayoría de los chatbots, el rango adecuado va de 0.3 a 0.7.
| Parámetro | Qué controla | Valor típico |
|---|---|---|
temperature | Aleatoriedad y creatividad | 0,3 a 0,7 |
max_tokens | Límite máximo de longitud de la respuesta | 512 a 2048 |
top_p | Amplitud del muestreo de tokens | 0,9 |
frequency_penalty | Penaliza las frases repetidas | 0,1 a 0,3 |
El código real es más simple de lo que sugieren la mayoría de los tutoriales. Aquí tienes una implementación mínima y funcional que usa el cliente de OpenAI, compatible con la mayoría de los proveedores de LLM.
pip install openai
from openai import OpenAI
client = OpenAI(api_key="your-api-key-here")
Para modelos de código abierto servidos mediante una API local (como Ollama o LM Studio), cambias el parámetro base_url. El resto del código se mantiene idéntico, y esa es una de las ventajas reales del estándar de API compatible con OpenAI que han adoptado la mayoría de los proveedores.
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 es el bucle central. Todos los chatbots de producción son una variación de este patrón, con lógica adicional encima.
Los usuarios toleran mucho mejor la espera de las respuestas cuando ven el texto llegar en tiempo real. El streaming está integrado en todas las API de LLM importantes y merece la pena implementarlo desde el primer día:
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)
Envía la respuesta a tu frontend mediante Server-Sent Events (SSE) o WebSockets. La latencia percibida baja de varios segundos a casi instantánea, y los usuarios reportan una satisfacción significativamente mayor con las respuestas en streaming que esperando una respuesta completa.
PicassoIA aloja más de 65 modelos de lenguaje (LLM) disponibles directamente en el navegador, sin configuración de API, sin configuración de facturación y sin necesidad de infraestructura. Esto lo hace práctico para probar tus prompts de sistema y la lógica de tu chatbot antes de escribir una sola línea de código.
Ve a la sección Large Language Models de PicassoIA. Encontrarás todas las grandes familias de modelos: GPT-5 y GPT-4o de OpenAI, Claude 4 Sonnet de Anthropic, Gemini 2.5 Flash de Google, Llama 4 Maverick Instruct de Meta, y especialistas en razonamiento como DeepSeek R1 y Kimi K2 Instruct.
💡 Usa Kimi K2 Instruct cuando tu chatbot necesite escribir o revisar código. Usa DeepSeek R1 cuando necesite razonar paso a paso sobre problemas de varias etapas.
El principal modo de fallo en los chatbots de producción es alcanzar el límite de la ventana de contexto sin código que lo gestione. Cuando eso ocurre, la API lanza un error context_length_exceeded y tu chatbot se cae o devuelve una página de error genérica. Implementa siempre una estrategia de recorte o resumen antes de publicar.
Regla simple: si el historial de tu conversación se acerca al 80 % del límite de contexto del modelo, según el recuento de tokens, empieza a eliminar los mensajes más antiguos que no sean del sistema de la lista de historial.
Bibliotecas como tiktoken (para modelos de OpenAI) te permiten contar los tokens con precisión antes de cada llamada a la API. Úsalas.
Las instrucciones vagas producen un comportamiento vago. Hay tres patrones que conviene evitar:
"Be helpful and friendly." Esto no le dice al modelo nada sobre lo que debe o no debe hacer.A gran escala, cada token innecesario cuesta dinero. Un prompt de sistema que tenga 800 tokens más de los necesarios cuesta esos 800 tokens en cada llamada a la API. Con 10.000 conversaciones diarias, son 8 millones de tokens de entrada extra al día, facturados a la tarifa de entrada del modelo. Revisa tu prompt de sistema a fondo antes del lanzamiento y elimina cualquier instrucción redundante o prolija.
Todas las API de LLM tienen límites de tasa: solicitudes por minuto, tokens por minuto y, en algunos casos, topes diarios. Planifícalos antes del lanzamiento. Con poco tráfico, las API propietarias son la opción adecuada por calidad y velocidad. Con mucho tráfico, autoalojar un modelo de código abierto como Llama 4 Maverick Instruct suele salir bastante más barato.
Comparación aproximada de costos para un chatbot con 10.000 conversaciones diarias que generan de media 500 tokens de salida cada una:
| Modelo | Costo aproximado por 1M de tokens de salida | Costo diario de salida |
|---|---|---|
| GPT-4o | ~$15 | ~$75 |
| GPT-4o Mini | ~$0,60 | ~$3 |
| Claude 4 Sonnet | ~$15 | ~$75 |
| Llama 4 (autoalojado) | Solo infraestructura | Variable |
GPT-4o Mini merece una evaluación seria para casos de uso de alto volumen en los que no hace falta estrictamente toda la capacidad de GPT-4o. Muchas tareas de chatbot, como responder preguntas frecuentes o enrutar consultas sencillas, no necesitan un modelo de vanguardia.
Publicar no es el final. Necesitas visibilidad sobre lo que tu bot dice realmente a los usuarios. Como mínimo, registra cada turno de la conversación con:
Revisa una muestra aleatoria de conversaciones cada día durante la primera semana. Detectarás fallos de los prompts, alucinaciones y casos límite que no aparecieron durante las pruebas.
💡 Configura disparadores de revisión: si un usuario envía una frase como "eso está mal" o "te lo has inventado", marca esa conversación para revisión manual inmediata.
Una vez que tu chatbot esté operativo y desplegado, estas tres incorporaciones lo llevan de demo a producto:
1. Generación aumentada por recuperación (RAG): conecta tu bot a una base de datos vectorial con tus propios documentos. En lugar de depender de los datos de entrenamiento del modelo, recupera los pasajes relevantes y los usa como contexto antes de generar una respuesta. Así se construye un chatbot que responde con precisión preguntas sobre tu producto específico, tus políticas internas o tu base de conocimiento, sin inventar detalles.
2. Barreras de seguridad (guardrails): añade una comprobación secundaria que valide tanto las entradas del usuario como las salidas del bot antes de que algo llegue al usuario. Esto detecta intentos de inyección de prompts, infracciones de políticas y respuestas fuera de tema antes de que sean visibles para tu audiencia. Una capa de reglas sencilla o una segunda llamada a un modelo ligero resuelve la mayoría de los casos.
3. Conjunto de evaluación: escribe un conjunto de prueba de 50 a 100 pares de entrada y salida esperada que cubran los casos de uso principales de tu chatbot. Ejecútalo automáticamente después de cada cambio en el prompt de sistema. Es la única forma fiable de detectar regresiones antes de que los usuarios las encuentren. Las pruebas manuales a esa escala dejan de ser realistas después de la primera semana.
La arquitectura está clara. El código no es complicado. Lo que separa a un chatbot que impresiona en una demo de uno que funciona de forma fiable en producción es la iteración. Más concretamente: iterar sobre el prompt de sistema, la estrategia de recorte, la elección del modelo y la configuración de monitorización, todo guiado por datos reales de conversación.
Nada de esa iteración exige escribir código primero. Puedes hacer la parte más valiosa, encontrar el modelo adecuado y un prompt de sistema que realmente aguante, en un navegador antes de abrir tu IDE.
PicassoIA te da acceso directo a más de 65 modelos de lenguaje (LLM) en tu navegador, incluidos GPT-5, Claude 4 Sonnet, Llama 4 Maverick Instruct, Kimi K2 Instruct, DeepSeek R1 y Gemini 2.5 Flash.
Escribe tu prompt de sistema. Elige un modelo. Mira cómo responde de verdad. Prueba los casos límite. Rómpelo a propósito. Luego perfecciona. Ese bucle de iteración es donde se construye la calidad real de un chatbot, y puedes ejecutar todo el proceso en PicassoIA antes de comprometerte con una sola llamada a la API o una línea de código.
Los modelos están disponibles. Tu chatbot no se va a construir solo.
Elige tu idioma
