DeepSeek R1 en producción: cómo probar la plantilla de prompt sin romper la aplicación

Las recomendaciones son un punto de partida, no una garantía

Una plantilla de prompt puede mejorar la respuesta del modelo y, al mismo tiempo, empeorar la integración. Por ejemplo, una instrucción que aumenta la explicación puede resultar útil en una tarea de análisis, pero incumplir el contrato de una API que espera una respuesta breve en JSON. Por eso, al desplegar DeepSeek R1, la pregunta práctica no es solo qué configuración recomienda el proveedor, sino si esa configuración mejora las tareas reales sin introducir regresiones que afecten al producto.

El repositorio oficial de DeepSeek R1 ofrece recomendaciones de uso relacionadas con la ubicación de las instrucciones, el mensaje de sistema y el inicio de la respuesta del asistente. También aconseja realizar varias pruebas al evaluar. Estas indicaciones proporcionan una base para diseñar experimentos, pero no prueban por sí mismas que una pauta concreta sea superior en cualquier aplicación. La carga de validarla recae en el equipo que define las tareas, los criterios de aceptación y las consecuencias de cada error.

Este artículo propone una ablación controlada: cambiar un factor cada vez, conservar constantes los demás y registrar no solo si la respuesta parece correcta, sino también si respeta el contrato de salida. El objetivo es evaluar DeepSeek R1 dentro de una aplicación concreta. No es una comparación con otros modelos ni un estudio de si R1 razona mejor que DeepSeek V3.2. Tampoco se presupone que el texto generado entre etiquetas de razonamiento describa fielmente un proceso interno.

Fija primero qué versión y qué configuración estás probando

Antes de comparar prompts, registra qué modelo y qué ruta de inferencia utiliza cada ejecución. La ficha oficial del modelo en Hugging Face, el archivo de configuración de generación y la plantilla de chat del repositorio sirven como referencias para documentar esos elementos. En particular, el archivo de plantilla ayuda a determinar cómo se serializan los mensajes. Dos condiciones que parecen distintas en una interfaz pueden acabar convertidas en secuencias de tokens diferentes, o dos pruebas pueden dejar de ser comparables si la plantilla cambia entre ellas.

Anota el identificador o revisión exacta de los pesos, el runtime y su versión, la plantilla de chat, los parámetros de generación y cualquier mecanismo adicional de la aplicación: herramientas, validadores, reintentos o transformaciones posteriores. No cambies simultáneamente la plantilla, la temperatura y el runtime. Si varias variables cambian a la vez, el resultado no permite atribuir con claridad una mejora o un deterioro al factor que se quería evaluar.

Si se usa un servicio compatible en lugar de los pesos en un runtime propio, documenta qué parámetros acepta y cuáles quedan fuera del control del equipo. Una interfaz compatible no garantiza por sí sola que la serialización o todos los detalles de inferencia sean idénticos. Si algún dato no puede verificarse, déjalo indicado como incertidumbre en el informe, en vez de presentarlo como una condición conocida.

Convierte las recomendaciones en factores comparables

Diseña las condiciones de manera que cada comparación responda a una pregunta definida. Para estudiar la ubicación de las instrucciones, mantén su contenido equivalente y compara, por ejemplo, una condición que las coloca en el mensaje de sistema con otra que las incluye en el mensaje del usuario. Si también quieres comparar distintas posiciones dentro del mensaje del usuario, crea una condición aparte y conserva el texto de la instrucción. Así se evita atribuir a la ubicación un efecto que podría deberse a haber cambiado su redacción.

El prefijo «<think>» debe evaluarse como un factor separado. Compara una condición con el inicio no forzado de la respuesta del asistente con otra en la que se añade el prefijo indicado por la documentación, verificando cómo queda serializado en el prompt real. No lo combines en la misma comparación con el cambio de mensaje de sistema: si una condición altera ambas cosas, una diferencia observada no revela cuál de ellas la produjo.

La recomendación de usar un prefijo no demuestra que este mejore todas las tareas ni que sea necesario en todos los runtimes. Tampoco permite concluir que el texto visible de razonamiento sea una medición directa de cómo opera internamente el modelo. Evalúa lo que la aplicación recibe y puede verificar: respuesta final, estructura, latencia, errores y consistencia.

Incluye tareas que representen contratos distintos

Un conjunto de pruebas compuesto solo por problemas matemáticos no representa necesariamente una aplicación que también extrae datos, responde preguntas breves y procesa documentos. Construye un conjunto pequeño pero variado a partir de tareas propias del producto. La variedad no es decorativa: permite detectar que una configuración puede ayudar en un tipo de tarea y perjudicar otro.

Para una respuesta factual breve, define de antemano qué información debe aparecer y qué contenido adicional sería un incumplimiento. En extracción estructurada, especifica el esquema, los campos obligatorios y cómo tratar los datos ausentes. En una tarea matemática verificable, conserva la respuesta correcta y el procedimiento de comprobación. Para una tarea basada en documentos, proporciona la misma evidencia a todas las condiciones y evalúa si la respuesta se sustenta en ella, si distingue lo que no está documentado y si evita añadir datos ajenos.

Incluye además casos en los que la conducta correcta sea abstenerse o señalar que la evidencia disponible no basta. Sin esos casos, una evaluación podría premiar respuestas seguras pero infundadas. Conserva ejemplos de errores conocidos y casos límite, pero separa los datos usados para ajustar una plantilla de los empleados para la evaluación final. Si se revisan las instrucciones durante el experimento, registra el cambio y vuelve a ejecutar las condiciones comparables.

Mide calidad y compatibilidad por separado

La puntuación principal debería reflejar si la respuesta resuelve correctamente la tarea según criterios escritos antes de mirar los resultados. No reduzcas todo a una impresión general. Registra también el cumplimiento de instrucciones, la validez del formato, los campos ausentes o inesperados, las abstenciones apropiadas y las abstenciones indebidas. En aplicaciones con parsers, cuenta como métrica operativa si la respuesta puede procesarse sin reparación manual.

Mide latencia con un método constante y define qué tramo estás midiendo: generación, llamada completa o tiempo que observa el usuario. Registra también errores de ejecución y reintentos. Las respuestas repetitivas o vacías merecen una categoría propia, con reglas claras para identificarlas; no las ocultes dentro de un promedio de calidad. Una respuesta puede contener una parte correcta y aun así ser inutilizable si repite texto, omite el cierre de una estructura o rompe el formato exigido.

Haz varias ejecuciones por condición cuando el sistema introduzca variación. Conserva los resultados individuales además de cualquier promedio o resumen. Para entradas deterministas y condiciones de generación que lo permitan, la repetición puede seguir siendo útil para comprobar estabilidad del entorno; cuando haya aleatoriedad, informa del número de ejecuciones y de la dispersión observada. No presentes una diferencia pequeña como un efecto sólido sin mostrar cuántos casos la sostienen.

Interpreta resultados mixtos sin ocultar las regresiones

Supón que una condición mejora la puntuación de los problemas matemáticos, pero aumenta los fallos de formato en extracción. No es correcto describirla simplemente como «mejor». La decisión depende de qué tarea sea crítica, de cuánto cueste el fallo y de si la aplicación dispone de mecanismos fiables para detectarlo y recuperarse. Una mejora media puede ocultar una regresión grave en una función concreta.

Compara primero cada tarea por separado y después presenta un resumen global con el método de agregación explicado. Si se usan pesos, declara quién los eligió y qué importancia representan. Añade recuentos absolutos junto a porcentajes cuando el conjunto sea pequeño: pasar de cero a un fallo y pasar de diez a once no expresan la misma situación, aunque alguna tasa agregada parezca similar. No cambies los pesos después de ver qué condición sale favorecida.

La documentación de DeepSeek recomienda múltiples pruebas al evaluar. En la práctica, eso implica conservar la variación entre ejecuciones y no seleccionar solo una respuesta favorable. También implica no generalizar más allá del conjunto ensayado: un resultado con un grupo de tareas propio es evidencia para esa aplicación y esas condiciones, no una garantía universal sobre R1.

Evita confundir el texto de razonamiento con una explicación fiable

La etiqueta «<think>» forma parte de la interfaz textual de ciertos formatos de conversación de R1, pero observar texto bajo esa etiqueta no demuestra que se esté viendo una transcripción completa o literal de un proceso interno. La evaluación debe centrarse en resultados observables y verificables. Para una respuesta matemática, comprueba la respuesta; para una extracción, compara los campos con el documento; para una abstención, confirma si la evidencia disponible era insuficiente.

El trabajo publicado con el título DeepSeek-R1 Thoughtology analiza características del comportamiento de razonamiento de R1 y trata cuestiones como la longitud, la controlabilidad y la rumiación. Ese contexto ayuda a justificar que se observen respuestas repetitivas y longitud, pero no sustituye las mediciones de la aplicación ni demuestra de antemano qué ocurrirá al cambiar una plantilla. Una explicación larga no es, por sí sola, prueba de una respuesta mejor; una explicación breve tampoco prueba que la tarea se haya resuelto sin razonamiento.

Si el producto no debe mostrar o almacenar ese contenido, comprueba por separado lo que el runtime expone, lo que la aplicación guarda y lo que recibe el usuario. No des por supuesto que ocultar una cadena en la interfaz equivale a eliminarla de registros o trazas. Esas propiedades dependen de la integración y requieren verificaciones propias.

Documenta la decisión como un informe de regresión

Un informe útil permite repetir el experimento y entender por qué se eligió una condición. Incluye las revisiones exactas del modelo y la plantilla, la configuración de generación, los prompts completos, el conjunto de tareas y las reglas de puntuación. Resume resultados por tipo de tarea, no solo con una cifra agregada. Guarda ejemplos representativos de aciertos y errores, con datos sensibles tratados según las políticas del equipo.

Describe qué cambió entre las condiciones y qué permaneció constante. Anota también las limitaciones: por ejemplo, si el servicio no expone la revisión de los pesos o si no se pueden controlar ciertos parámetros. Si el resultado no es concluyente, esa es una conclusión válida; se puede ampliar el conjunto, repetir la prueba o mantener la configuración vigente mientras se investiga. Evita convertir una ausencia de evidencia de regresión en evidencia de ausencia de regresión.

La recomendación operativa final debe ser específica: qué plantilla se acepta, para qué tareas, con qué versión y bajo qué umbrales. Si una variante solo funciona bien para un flujo, limita su uso a ese flujo en vez de presentarla como una plantilla universal para DeepSeek R1.

Criterio práctico: conservar lo que supera la prueba de la aplicación

La pauta de prompting más útil para una aplicación de DeepSeek R1 es la que mejora sus tareas sin debilitar sus contratos de salida ni sus mecanismos de seguridad y recuperación. Para averiguarlo, fija una referencia, aísla los cambios, incluye tareas diversas, repite pruebas cuando corresponda y muestra resultados desglosados. Un prefijo, la posición de una instrucción o la ausencia de un mensaje de sistema no deberían aceptarse por costumbre ni descartarse por intuición: hay que comprobar sus efectos bajo condiciones registradas.

Cuando los resultados sean consistentes y cumplan los umbrales definidos, despliega la configuración con seguimiento de las métricas que motivaron la decisión. Si el entorno, los pesos, la plantilla o las tareas cambian, vuelve a evaluar las condiciones relevantes. Así, las recomendaciones oficiales siguen siendo útiles como hipótesis iniciales, mientras que la evidencia de la aplicación determina la configuración final.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.