Key Takeaways
- Los modelos locales 7B necesitan más orientación explícita que GPT-4o. Prompts más largos, instrucciones más claras.
- El prompting por cadena de pensamiento ("Déjame pensar paso a paso") mejora la precisión del razonamiento un 10–20%.
- Siempre especifica el formato de salida (JSON, Markdown, texto plano). Las salidas sin estructura son impredecibles.
- Los ejemplos few-shot (1–3) funcionan mejor que zero-shot en modelos locales. Más ejemplos = mayor consistencia.
- La definición de roles ("Eres un experto en Python") mejora las respuestas específicas del dominio.
Datos rápidos
- Mejora de precisión con CoT: 10–20% de mejora en tareas de razonamiento
- Requisito few-shot: Los modelos 7B locales necesitan 3–5 ejemplos frente a 1–2 de las APIs en la nube
- Consumo de contexto: Cada ejemplo usa 50–200 tokens
- Impacto de la temperatura: Bajar de 0.8 a 0.3 mejora la precisión factual un 15–25%
- Diferencia de tamaño de modelo: Los modelos 7B necesitan más orientación explícita que los modelos 70B
- Consistencia del formato de salida: Las especificaciones JSON mejoran la fiabilidad un 30–40%
¿En qué se diferencian los modelos locales?
| Aspecto | GPT-5.2 (ChatGPT Plus) | Local 7B (Llama 3.1 8B) | Local 70B (Llama 3.3) |
|---|---|---|---|
| Ventana de contexto | 128K tokens | 4K–128K tokens | 128K tokens |
| Seguimiento de instrucciones | Excelente | Bueno con prompts explícitos | Muy bueno |
| Aprendizaje few-shot | 1–2 ejemplos | 3–5 ejemplos necesarios | 2–3 ejemplos |
| Razonamiento | Implícito en múltiples pasos | Paso a paso explícito requerido | Implícito moderado |
| System prompt | Gestionado por la API | Configurar por herramienta | Configurar por herramienta |
| Temperatura por defecto | 1.0 (API) | 0.8 (defecto Ollama) | 0.8 (defecto Ollama) |
¿Cómo mejora la precisión el prompting por cadena de pensamiento?
El prompting por cadena de pensamiento (CoT) pide al LLM que muestre su razonamiento paso a paso antes de responder. Esta técnica es especialmente efectiva para los modelos locales 7B–13B porque carecen de la capacidad de razonamiento implícito de los modelos cloud más grandes. Para un problema matemático como "17 × 24", los modelos locales sin CoT suelen responder incorrectamente. Con un razonamiento paso a paso explícito, descomponen el problema en partes y alcanzan una precisión un 10–20% mayor.
Sin CoT: "¿Cuánto es 17 × 24?" → El modelo responde directamente, a menudo de forma incorrecta.
Con CoT: "Resuelve esto paso a paso: 17 × 24" → El modelo muestra: 17 × 20 = 340, 17 × 4 = 68, total = 408. Más preciso.
Aprende cómo esta técnica se extiende a los agentes de IA locales que usan razonamiento internamente para seleccionar herramientas.
El prompting por cadena de pensamiento instruye al modelo para descomponer el razonamiento en pasos explícitos antes de responder, mejorando la precisión un 10–20% en tareas complejas.
# Prompt con CoT
prompt = """
You will answer a question by thinking step-by-step.
Let me think about this:
Question: Why do local LLMs require more explicit prompting than cloud APIs?
Thinking:
1. First, consider the differences in model size...
2. Then, think about training data and fine-tuning...
3. Finally, consider the architecture and inference optimization...
Answer:
"""
# This guides the model to reason through the problem•💡: Consejo Pro: CoT funciona mejor cuando inicias la salida con un razonamiento parcial. Ejemplo: "Déjame desglosar esto paso a paso: primero, noto..."
¿Por qué es crítico especificar el formato de salida en los modelos locales?
Especificar el formato de salida exacto (JSON, Markdown, texto plano) es crítico para los modelos locales porque producen salidas impredecibles sin instrucciones explícitas. Los modelos cloud como GPT-4o pueden inferir la intención de peticiones vagas; los modelos locales 7B–13B no pueden. Para los sistemas RAG locales que necesitan extracción de documentos estructurada, las especificaciones de formato JSON previenen errores de parseo y aumentan la precisión de extracción un 30–40%.
Ejemplo: "Extrae entidades del texto" podría devolver texto narrativo en lugar de una lista.
Mejor: "Extrae entidades como JSON con claves: persona, lugar, organización".
# Bad: ambiguous output
prompt = "Summarize this text"
# Good: explicit format
prompt = """
Summarize the text in EXACTLY 3 bullet points.
Format as a JSON list:
{
"summary": [
"- Point 1",
"- Point 2",
"- Point 3"
]
}
"""•⚠️: Problema común: Los modelos locales a veces se niegan a generar JSON puro. Añade "Genera SOLO JSON, sin bloques markdown" al prompt para evitarlo.
¿Cómo mejora la asignación de roles las respuestas de los modelos locales?
Asignar un rol específico ("Eres un experto en Python con 10 años de experiencia") mejora drásticamente las respuestas específicas del dominio en comparación con los prompts genéricos. Esta técnica, llamada prompting de persona, funciona anclando la generación de respuestas del modelo a un dominio de expertise específico. Los modelos locales responden un 15–25% mejor a la definición de roles que los modelos cloud, porque carecen de la alineación RLHF robusta que permite que los prompts genéricos funcionen. Ejemplos:
- "Eres un experto en Python" → mejores explicaciones de código
- "Eres un investigador médico" → respuestas biomédicas más detalladas
- "Eres un analista escéptico" → pensamiento más crítico
Combina la definición de roles con el fine-tuning para una alineación de dominio aún mayor si despiegas en muchos casos de uso.
En términos sencillos, el prompting de persona le dice al modelo qué "sombrero" ponerse al responder. Un sombrero de experto en Python produce código diferente (y mejor) que un sombrero de asistente genérico.
•🎯: Buena práctica: La especificidad importa. "Eres un experto" es débil; "Eres un experto en Python con 10 años de experiencia backend, enfocado en patrones async/await" es fuerte.
¿Cómo se configura el system prompt en Ollama, LM Studio y llama.cpp?
El system prompt define el rol y las restricciones del modelo antes del mensaje del usuario, y cada herramienta (Ollama, LM Studio, llama.cpp) requiere un formato diferente para configurarlo.
# Ollama (Modelfile)
FROM llama3.1:8b
SYSTEM """You are a Python expert with 10 years experience. Answer only Python questions. Provide code examples. Use type hints."""
PARAMETER temperature 0.7
PARAMETER top_p 0.9
PARAMETER repeat_penalty 1.1
# Ollama (API / OpenAI SDK)
response = client.chat.completions.create(
model="llama3.1:8b",
messages=[
{"role": "system", "content": "You are a Python expert..."},
{"role": "user", "content": "Write a FastAPI endpoint"}
],
temperature=0.7
)
# LM Studio (GUI)
# Settings → System Prompt field (paste your prompt)
# Or via API at localhost:1234 — identical format to Ollama
# llama.cpp (CLI)
./main -m llama-3.1-8b.gguf \
--system-prompt "You are a Python expert..." \
--temp 0.7 --top-p 0.9 --repeat-penalty 1.1 \
-p "Write a FastAPI endpoint"¿Cómo afectan la temperatura y los parámetros de muestreo a la calidad de salida?
Ajustar la temperatura, top_p y repeat_penalty tiene más impacto en la calidad de salida de los modelos 7B locales que la redacción del prompt, y los modelos locales requieren valores por defecto diferentes a los de las APIs cloud.
Clave para los modelos locales: La temperatura por defecto de Ollama (0.8) es mayor que el valor por defecto de la API de OpenAI (1.0 con muestreo nucleus). Bajar la temperatura a 0.3–0.5 mejora drásticamente la precisión factual en los modelos locales 7B. Para tareas de codificación, establece la temperatura en 0.1–0.2 y repeat_penalty en 1.0 (el código necesita patrones repetitivos como imports y llamadas a funciones).
| Parámetro | Qué controla | Por defecto (Ollama) | Recomendado |
|---|---|---|---|
| temperature | Aleatoriedad | 0.8 | 0.3–0.5 para factual, 0.7–0.9 para creativo |
| top_p | Diversidad de vocabulario | 0.9 | 0.8 para consistente, 0.95 para variado |
| repeat_penalty | Evitar repetición | 1.1 | 1.1–1.2 para chat, 1.0 para código |
•📌: Punto clave: La temperatura es un multiplicador sobre los logits. En 0.0, siempre se elige el token de mayor probabilidad. Por encima de 1.0, la aleatoriedad aumenta. Los modelos locales se saturan por encima de 1.5 de temperatura.
¿Por qué los modelos locales necesitan más ejemplos few-shot que las APIs cloud?
Proporcionar 3–5 ejemplos (aprendizaje few-shot) a los modelos locales mejora la consistencia de salida un 15–25% más que zero-shot, mientras que los modelos cloud solo necesitan 1–2 ejemplos.
Los modelos locales se benefician de más ejemplos porque tienen menos parámetros y datos de entrenamiento menos diversos. El aprendizaje few-shot es una técnica de aprendizaje en contexto que muestra al modelo el patrón de entrada/salida esperado antes de pedirle que resuelva la tarea real.
# Few-shot prompt
prompt = """
Classify sentiment. Examples:
"I love this product!" → positive
"Worst experience ever" → negative
"It's okay, nothing special" → neutral
Now classify: "This is amazing!"
Answer: """
# Model learns format and style from examples•🛠️: Consejo de implementación: Variar ejemplos (1 fácil, 1 medio, 1 difícil) funciona mejor que usar 3 similares. La diversidad mejora la generalización y evita el sobreajuste a patrones específicos.
Errores comunes en el prompt engineering
- Prompts extensos sin estructura. Las instrucciones dispersas confunden a los modelos locales. Sé conciso y explícito.
- No usar la cadena de pensamiento. CoT mejora la precisión un 10–20%. Úsala siempre en tareas de razonamiento.
- Asumir que un prompt sirve para todo. Itera y prueba. Pequeños cambios de redacción causan grandes variaciones en la salida.
- Ignorar el formato de salida. Sin una especificación explícita del formato, las salidas son impredecibles.
- Usar definiciones de roles vagas. "Eres un experto" es vago. "Eres un experto en Python con 10 años de experiencia" es mejor.
•📍: ¿Sabías que? Los prompts más efectivos iteran 3–5 versiones. El prompting de modelos locales no es "configurar y olvidar": pequeños refinamientos se acumulan en ganancias de precisión significativas.
Consideraciones regionales para el prompt engineering
UE (GDPR): Al desplegar prompt engineering para modelos locales en infraestructura de la UE, asegúrate de que todos los datos de entrenamiento usados para iterar prompts cumplan con los principios de minimización de datos del GDPR. No exportes consultas de usuarios a APIs externas para pruebas; itera localmente.
Japón (APPI): Las empresas japonesas que usan LLMs locales para datos de clientes deben implementar registro de auditoría explícito de todos los prompts y respuestas. La calidad del prompt impacta directamente la seguridad de los datos: prompts mal diseñados pueden exponer información sensible en las salidas.
China (Ley de Seguridad de Datos 2021): Los despliegues de LLMs locales en China continental deben mantener toda inferencia, prompting y ajuste de modelos en las instalaciones. Se prefieren Qwen y otros modelos domésticos para garantizar el cumplimiento de la residencia de datos.
Preguntas frecuentes sobre el prompting de LLMs locales
¿Por qué los LLMs locales necesitan prompts más explícitos que GPT-4o?
Los modelos locales 7B–13B tienen menos parámetros y datos de entrenamiento menos diversos que GPT-4o (se estima 1.8T parámetros). No pueden inferir la intención ambigua tan bien. Las instrucciones explícitas —formato, rol, razonamiento paso a paso— compensan esta diferencia. El prompting por cadena de pensamiento mejora la precisión de los modelos locales un 10–20% en tareas de razonamiento.
¿Cuántos ejemplos few-shot debo incluir en los prompts para LLMs locales?
3–5 ejemplos son óptimos para los modelos locales 7B. GPT-4o normalmente solo necesita 1–2 ejemplos. Más ejemplos mejoran la consistencia pero consumen tokens de la ventana de contexto (4K–32K tokens según el modelo). Para Llama 3.2 8B con una ventana de contexto de 4K, limita a 3 ejemplos más tu tarea. Para modelos con contexto de 32K+, 5 ejemplos son seguros.
¿Funciona el prompting por cadena de pensamiento con todos los modelos locales?
La cadena de pensamiento funciona con cualquier modelo ajustado por instrucciones (Llama 3.x, Qwen 2.5, Mistral 7B). Los modelos base (sin ajuste por instrucciones) no siguen instrucciones de "piensa paso a paso" de forma fiable. Para modelos locales, las frases CoT como "Resuelve esto paso a paso:" o "Razonamiento:" al inicio de la salida esperada funcionan mejor.
¿Qué formato de salida es más fiable para los LLMs locales?
JSON es el formato de salida estructurado más fiable para los LLMs locales. Especifica el esquema JSON exacto en el prompt: "Responde SOLO con un objeto JSON con claves: nombre, puntuación, razonamiento." Los encabezados Markdown (##) son fiables para secciones. Evita pedir XML o formatos personalizados: los modelos locales los manejan de forma inconsistente.
¿Cómo evito que un LLM local se salga del tema?
Añade una restricción explícita al system prompt o al prompt de instrucciones: "Responde SOLO sobre [tema]. Si te preguntan sobre otra cosa, di: Solo puedo ayudar con [tema]." Para Ollama, usa el campo de system prompt. Para llama.cpp, antepónlo como mensaje de sistema. Esta delimitación funciona significativamente mejor en modelos locales 7B que en modelos cloud con alineación RLHF más fuerte.
¿Cuál es la diferencia entre prompting zero-shot y few-shot para modelos locales?
Zero-shot no da ningún ejemplo: "Clasifica este email como spam o no spam." Few-shot proporciona 2–5 ejemplos etiquetados antes de la tarea. Para los modelos locales 7B, few-shot supera consistentemente a zero-shot en tareas de clasificación y extracción con una precisión 15–25% mayor. Zero-shot funciona bien para tareas de generación (resumen, traducción) donde el formato es menos crítico.
¿Cómo pruebo e itero prompts para modelos locales?
Prueba con 5–10 ejemplos diversos. Cambia una variable a la vez (rol, formato o instrucción CoT). Mide la precisión o consistencia antes/después. Usa un conjunto de pruebas simple: 2–3 ejemplos fáciles, 2–3 ejemplos difíciles. Registra qué versiones de prompt funcionan mejor. Itera en ciclos de 3–5 variaciones de prompt. Documenta los prompts que funcionan en una biblioteca de prompts para reutilizarlos.
¿Debo hacer prompt engineering o fine-tuning para una tarea específica?
Haz prompt engineering primero (rápido, gratuito, iterativo). Si la precisión se estanca tras 20+ variaciones de prompt, entonces haz fine-tuning. El fine-tuning requiere 500+ ejemplos específicos de la tarea y 1–4 horas de tiempo de entrenamiento, pero produce ganancias de precisión del 10–20%. Para tareas de propósito general, el prompt engineering suele ser suficiente. Para tareas específicas del dominio (médico, legal, codificación), el fine-tuning proporciona mejoras duraderas.
¿En qué se diferencian los system prompts de las instrucciones de usuario en los LLMs locales?
Los system prompts definen el rol y las restricciones del modelo antes del mensaje del usuario y forman parte de la estructura de la solicitud (en Ollama, LM Studio o vía API). Las instrucciones de usuario son parte de la conversación. Los system prompts establecen el comportamiento base y son más fiables que incrustar instrucciones en los mensajes de usuario. Para los modelos locales, un system prompt bien redactado mejora la consistencia un 15–25% porque el modelo prioriza las restricciones a nivel de sistema sobre el texto a nivel de usuario.
¿Puedo usar el mismo prompt en diferentes modelos locales?
Parcialmente. La estructura CoT básica y las definiciones de roles se transfieren entre modelos (Llama, Qwen, Mistral). Sin embargo, cada modelo requiere ajuste del prompt para resultados óptimos. Los modelos Llama responden a "Déjame pensar paso a paso", mientras que los modelos Qwen prefieren "Primero, necesito...". Prueba tu prompt en el modelo exacto que vas a desplegar. Los modelos más grandes (70B) son más tolerantes a las variaciones del prompt que los modelos más pequeños (7B).
Fuentes
- Chain-of-Thought Prompting Paper (Wei et al.) — Investigación seminal sobre el razonamiento mediante instrucciones paso a paso.
- Prompt Engineering Guide (DAIR-AI) — Colección integral de técnicas de prompting y mejores prácticas.
- Ollama Modelfile Reference — Documentación oficial para system prompts, parámetros (temperatura, top_p, repeat_penalty) y creación de modelos personalizados.