Capítulo 2 — Modelos base e ingeniería de prompts
Segunda entrega del recorrido capítulo por capítulo de LLM Primer V: Building Real-World LLM Applications. El capítulo que trata la ingeniería de prompts como ingeniería — plantillas versionadas, delimitadores defensivos y salidas estructuradas — y no como un arte que se juzga por intuición.
Por qué existe este capítulo
El Capítulo 1 sostenía que el modelo es un componente dentro de un envoltorio determinista. El Capítulo 2 mira ese componente con lupa. El catálogo de modelos en 2026 es una taxonomía con distinciones nítidas, no una lista de equivalentes. Los parámetros de muestreo convierten los mismos pesos en un clasificador determinista o en un escritor creativo. Los prompts son artefactos estructurados cuya anatomía marca la diferencia entre sobrevivir a una entrada adversarial y no. Existen mecanismos para forzar la salida a una forma que el envoltorio pueda validar, y elegir mal el mecanismo para la tarea cuesta más en reintentos de validación de lo que el mecanismo ahorra. Un equipo que trata "el modelo" como un recurso anónimo único, usa los defaults por todas partes, escribe los prompts como cadenas desechables y valida la salida rezando — ese equipo ha dejado sobre la mesa la mayor parte del control de ingeniería disponible.
2.1 Selección de modelo como decisión de ingeniería de primer nivel
El catálogo se divide en cuatro familias: modelos de lenguaje pequeños afinados para velocidad y coste en tareas acotadas; modelos generalistas de gama media que resuelven la mayoría de las cargas de producción; modelos frontera para el razonamiento más duro y los contextos más largos; y modelos de razonamiento que gastan cómputo de inferencia extra en un paso de deliberación oculto. La multimodalidad atraviesa las cuatro. La selección es una decisión de enrutado por petición, no un default global: consultas cortas al SLM, tareas no triviales bien acotadas al gama media, el razonamiento más duro al frontera, los modelos de razonamiento allí donde la latencia es aceptable y la ganancia de precisión es real. El router registra su decisión junto a la respuesta, de modo que una regresión se puede filtrar por tramo. La selección tampoco es una decisión de una vez para siempre — el paisaje de modelos se mueve más rápido que cualquier otra infraestructura de la que dependa el equipo, y la disciplina es reejecutar el conjunto de evaluación cada trimestre y migrar cuando la evidencia lo respalda.
2.2 El muestreo como perfil deliberado
La temperatura escala la distribución de tokens antes de muestrear; top-p la trunca al núcleo por encima de un umbral de probabilidad; min-p filtra los tokens muy por debajo del top; el seed ofrece repetibilidad de mejor esfuerzo. Los dos perfiles que merece la pena nombrar de forma explícita son el perfil determinista — temperatura cero, top-p 1.0, seed fijado — para clasificación, extracción y enrutado donde el contrato es "misma entrada, misma salida"; y el perfil creativo — temperatura en torno a 0.8, top-p 0.95 — para generación donde la variación es el producto. Mezclar ambos por accidente, usando el default de temperatura 0.7 en una tarea de clasificación, produce la clase de tests inestables y fallos intermitentes que los equipos culpan al modelo cuando la responsabilidad es la elección de parámetros. El streaming es ortogonal al muestreo: los mismos parámetros aplican, cambia el transporte, y el tiempo hasta el primer token reemplaza a la latencia total como métrica de velocidad percibida.
2.3 Prompts defensivos y salidas estructuradas
Un prompt de producción tiene una anatomía de cinco partes — rol, tarea, restricciones, ejemplos, entrada delimitada — y el orden importa porque la atención del modelo a cada componente está condicionada por lo que viene antes. La entrada delimitada, anclada por ambos lados con el recordatorio de que el contenido entre los marcadores es dato y no instrucción, es el suelo por debajo del cual un prompt no debería caer. Los prompts son artefactos de código versionados; un nombre como prompts/classify_support_v3, registrado en cada traza, es cómo se rastrea una regresión hasta el cambio que la causó. Las salidas estructuradas — Pydantic en Python, Zod en TypeScript, pasadas al proveedor como un esquema de respuesta — imponen la forma de la salida en tiempo de decodificación. La imposición de JSON Schema en el lado del proveedor elimina una clase entera de fallos de validación. Donde JSON Schema no basta — SQL, formatos con forma de regex, argumentos de herramienta contra un catálogo cerrado — la decodificación restringida por gramática vía Outlines da la misma garantía a nivel de token.
Lo que prepara el Capítulo 2
El Capítulo 2 dio por supuesto que lo que el prompt contiene basta para la tarea. Para muchas tareas — clasificación, extracción, transformación — el supuesto se sostiene. Para la mayoría de los sistemas de producción de cara al usuario no, porque el usuario pregunta por hechos que el equipo posee y el modelo nunca ha visto: documentos internos, la política de esta semana, el historial de pedidos del cliente. El movimiento de ingeniería que cierra esa brecha es la generación aumentada por recuperación. El Capítulo 3 recorre el pipeline RAG de extremo a extremo — carga, chunking, embedding, recuperación, generación — y luego las técnicas que separan un pipeline de demo de uno de producción: recuperación híbrida, chunking consciente de la estructura y transformaciones de consulta como HyDE y step-back.
Próximamente — Capítulo 3: Generación aumentada por recuperación. El pipeline que da al modelo el contexto que sus datos de entrenamiento nunca cubrieron — de extremo a extremo, del cargador al generador.
