DeepSeek R1 vs. DeepSeek V3.2: cómo decidir entre razonamiento explícito y eficiencia en un flujo revisable

La decisión no es qué modelo parece mejor, sino qué riesgo reduce el flujo

La comparación entre DeepSeek R1 y DeepSeek V3.2 debe partir de una decisión operativa concreta. Por ejemplo: analizar un expediente técnico, identificar requisitos aplicables en documentos entregados por el usuario, emitir una recomendación estructurada y preparar una acción posterior. Esa acción puede ser crear un borrador, abrir un caso o proponer una ruta de aprobación, pero no debe ejecutarse sin las validaciones humanas y de sistema que el proceso requiera.

En este tipo de flujo, una respuesta extensa o un razonamiento visible no son por sí mismos una ventaja. Lo relevante es si disminuyen un error material: una recomendación incompatible con la evidencia, una cita documental incorrecta, una herramienta invocada con parámetros erróneos, una falta de abstención ante datos insuficientes o una salida que no puede procesar el sistema receptor.

La pregunta de compra o despliegue puede formularse de manera falsable: ¿R1 reduce suficientemente los errores materiales y la carga de revisión humana en casos ambiguos y de varios pasos como para compensar su tiempo de respuesta, sus tokens y su complejidad? Si V3.2 alcanza el mismo umbral de corrección, evidencia, abstención y estructura con menos recursos, el razonamiento más largo no justifica por sí solo enrutarle la tarea.

Esta pieza no presupone que uno de los dos modelos sea un sustituto universal del otro. Propone una prueba para responsables de producto, plataforma e ingeniería que necesitan elegir una ruta por caso y conservar una aprobación humana para las decisiones con consecuencias operativas.

Identifique exactamente qué se compara antes de medir resultados

“DeepSeek V3.2” no basta como identificador experimental. La documentación de lanzamiento presenta DeepSeek-V3.2 como sucesora de V3.2-Exp, mientras que el registro de cambios indica una actualización de los alias deepseek-chat y deepseek-reasoner a DeepSeek-V3.2 el 1 de diciembre de 2025. Por tanto, un informe reproducible debe registrar el identificador solicitado, el alias realmente usado, la fecha y hora de la ejecución, el canal de acceso y la versión o revisión del artefacto local si se ejecuta un checkpoint.

La ficha publicada de DeepSeek-V3.2 permite fijar un artefacto para una evaluación local, pero una prueba local y una prueba mediante API no son intercambiables automáticamente. Pueden diferir en hardware, runtime, cuantización, servidor de inferencia, límites de contexto, colas, controles de seguridad, política de reintentos y tarifa. También puede cambiar la plantilla conversacional o el procesamiento de herramientas. La comparación debe declarar esas diferencias, no atribuirlas al modelo.

DeepSeek R1 también exige que se documente el procedimiento usado. El repositorio oficial describe un contexto de 128K y, para su evaluación publicada, indica una generación máxima de 32.768 tokens, temperatura de 0,6 y top_p de 0,95 en el muestreo. Esos valores no son una garantía de que sean óptimos para todas las tareas, pero constituyen una referencia importante. Si el ensayo se aparta de ellos, debe justificarlo y evaluar si el cambio favorece o perjudica a R1.

No conviene imponer una configuración idéntica cuando las interfaces documentadas tengan restricciones distintas. La igualdad relevante es la de oportunidad de resolver la tarea: mismo corpus, mismas herramientas disponibles, mismas reglas de éxito, mismo límite de tiempo de negocio y una política de reintentos definida antes de mirar los resultados. Las configuraciones específicas de cada modelo deben quedar registradas como parte del experimento.

Formule una hipótesis que pueda perder

La hipótesis no debe ser que R1 “razona mejor” ni que V3.2 “es más eficiente”. Ambas expresiones son demasiado imprecisas para una decisión de plataforma. Una hipótesis útil podría ser esta: en expedientes con evidencia contradictoria, dependencias entre documentos y necesidad de consultar herramientas simuladas, R1 obtiene una mayor tasa de decisiones correctas y de abstenciones correctas que reduce el número de revisiones humanas de forma operativamente relevante.

La hipótesis contraria también debe definirse: en solicitudes directas, con evidencia suficiente y un único paso de decisión, V3.2 alcanza el umbral de calidad acordado con menor latencia, menos tokens de salida o menor coste por resultado aceptado. En ese caso, V3.2 sería la ruta preferente para ese estrato, aunque R1 obtenga una puntuación media ligeramente superior.

Conviene establecer de antemano qué resultado invalida cada propuesta. Por ejemplo, R1 no justifica la ruta especializada si su mejora en errores materiales no supera el margen establecido, si la mejora desaparece al repetir casos, o si proviene de un formato de prompt, una recuperación documental o una infraestructura distintos. V3.2 no debe ser la ruta por defecto si conserva una tasa inaceptable de recomendaciones no sustentadas o si no se abstiene de forma adecuada.

Los umbrales deben ser propios del proceso. Un flujo que prepara respuestas internas de bajo impacto puede tolerar una revisión de muestreo. Un flujo que afecta a compromisos contractuales, operaciones o personas puede exigir evidencia obligatoria, bloqueo por reglas y aprobación humana en todos los casos. La evaluación mide rendimiento bajo condiciones dadas; no convierte al modelo en autoridad autónoma.

Diseñe el experimento para medir una tarea, no la capacidad de impresionar

Construya un corpus congelado antes de ejecutar el primer modelo. Cada caso debe contener los documentos y metadatos que recibirán ambos sistemas, una clave de evaluación elaborada independientemente y una etiqueta de estrato. El corpus puede incluir tareas directas, expedientes extensos, ambigüedades deliberadas, contradicciones, información incompleta y casos donde la respuesta correcta sea abstenerse o escalar a una persona.

La clave de evaluación debe separar hechos verificables de criterios expertos. Los hechos pueden incluir una decisión correcta, campos obligatorios, referencias a evidencia permitida, parámetros esperados de herramientas y condiciones de abstención. Los criterios expertos pueden puntuar claridad, priorización o calidad de la explicación. Estos últimos deben revisarse a ciegas respecto al modelo, con instrucciones y resolución de desacuerdos documentadas.

Entregue a ambos modelos exactamente el mismo contenido de negocio y el mismo esquema de salida. Si se habilitan herramientas, simule respuestas deterministas para que una diferencia no proceda de sistemas externos cambiantes. La guía de llamadas a herramientas documenta soporte para herramientas en modo thinking desde V3.2 y un modo estricto orientado a la conformidad con JSON Schema. Si se usa esa opción, aplíquela de forma coherente donde sea compatible y mida por separado la validez sintáctica de JSON y la validez semántica de los valores.

Registre temperatura, top_p, límite de salida, semilla cuando esté disponible, número máximo de llamadas, límite de tiempo y política de reintentos. Para R1, la documentación publicada recomienda una configuración concreta para su evaluación y aconseja múltiples ejecuciones en determinados escenarios. Por ello, no basta con una única respuesta por caso si se pretende estimar estabilidad: repita cada caso un número prefijado de veces y comunique la distribución de resultados, no únicamente el mejor intento.

No mezcle cambios de prompt con cambios de modelo. Si el formato falla, mantenga una ronda diagnóstica distinta de la comparación principal. Si se cambia el prompt o el parser tras observar un fallo, vuelva a ejecutar ambos modelos bajo la nueva configuración. De otro modo, el experimento deja de distinguir el efecto del modelo del efecto de la iteración del equipo.

Mida por separado corrección, evidencia, abstención y coste

La exactitud final es necesaria, pero no suficiente. Una recomendación puede coincidir por casualidad con la clave y, aun así, citar evidencia errónea o preparar una acción con parámetros inseguros. Mida la corrección de la decisión, la cobertura de los elementos obligatorios y la fidelidad de la evidencia: cada afirmación relevante debe poder vincularse a un fragmento permitido del corpus del caso.

La abstención requiere una métrica propia. Distinga la abstención correcta —el modelo identifica que no puede decidir con los datos disponibles— de la abstención excesiva —deriva casos resolubles— y de la falsa seguridad —decide cuando debía escalar. Esta última suele ser más relevante que una caída moderada de productividad en procesos con impacto. La rúbrica ha de indicar qué datos ausentes, conflictos o límites de autoridad requieren escalado.

Para herramientas, mida al menos cuatro aspectos: selección de la herramienta adecuada, parámetros válidos, interpretación correcta de la respuesta y decisión posterior coherente con esa respuesta. Una llamada con JSON válido no es necesariamente útil; de igual modo, una respuesta con formato imperfecto puede contener una decisión correcta que el sistema no puede aceptar. Mantenga las métricas de estructura y de contenido separadas.

La medición operativa debe incluir latencia de extremo a extremo por percentiles, tokens de salida, número de llamadas a herramientas, reintentos y coste por caso aceptado. El denominador importa: dividir el coste por todas las respuestas puede ocultar el coste de las que, tras validación, son realmente utilizables. Informe también el volumen de revisión humana requerido y el tiempo de corrección por tipo de fallo.

Diagnostique la causa de una diferencia antes de atribuírsela al razonamiento

Presente resultados por estrato, además de una media total. Un promedio puede ocultar que R1 sólo aporta valor en una minoría de expedientes ambiguos o que V3.2 resuelve de forma suficiente la mayor parte de las solicitudes simples. Cruce los resultados con longitud de contexto, número de documentos, necesidad de herramienta, contradicción de fuentes y condición de abstención.

Cuando haya una diferencia, clasifique el primer punto de fallo. Puede estar en recuperación de evidencia, comprensión de una instrucción, planificación de una llamada, generación de argumentos, parser, tiempo agotado, reintento o infraestructura. Revise trazas sin revelar al evaluador qué modelo las produjo cuando sea viable. La guía de modo thinking trata el contenido de razonamiento como un elemento con manejo específico y establece requisitos para determinados flujos con herramientas; el arnés debe respetar ese contrato en lugar de mezclar contenidos de razonamiento con el historial de forma improvisada.

No use el razonamiento expuesto como prueba de verdad. Puede ayudar al diagnóstico si el canal y la política de datos permiten registrarlo, pero la validación debe recaer en la salida final, la evidencia entregada y los eventos de herramientas. Además, retener trazas puede tener implicaciones de privacidad, seguridad y gobernanza que deben evaluarse separadamente.

Si la diferencia desaparece al igualar cuantización, servidor, longitud máxima o reintentos, el resultado no demuestra una superioridad general del modelo. Del mismo modo, si un modelo obtiene ventaja por recibir un prompt especializado, la conclusión válida es que la combinación modelo-configuración funciona mejor bajo ese arnés, no que el modelo aislado sea superior en cualquier entorno.

Convierta los resultados en una regla de enrutamiento y mantenga controles humanos

La salida del experimento debe ser una regla operativa, no una declaración genérica de ganador. Una posible política es enviar a V3.2 los casos directos que superen el umbral de corrección, evidencia y estructura con un presupuesto definido; enviar a R1 los expedientes con ambigüedad, múltiples dependencias o planificación de herramientas cuando haya demostrado una reducción material de errores; y escalar a una persona los conflictos de evidencia, las ausencias de datos críticas y los casos fuera de la autoridad delegada.

Antes del despliegue, pruebe la regla en modo sombra. El sistema puede producir una recomendación y una acción preparada sin que esta tenga efecto, mientras un revisor compara los resultados con el proceso existente. Establezca alertas para aumento de abstenciones omitidas, caída de evidencia válida, degradación de latencia y cambios de comportamiento después de una actualización de alias o infraestructura.

La aprobación final no debe delegarse sólo porque el modelo haya superado un ensayo. La evaluación no prueba conocimiento actualizado fuera del corpus, seguridad de herramientas reales, cumplimiento normativo, resistencia frente a entradas adversarias ni generalización a otro dominio. Tampoco elimina la necesidad de permisos mínimos, validación determinista de parámetros, registros auditables y mecanismos de reversión.

DeepSeek V3.2 ofrece disponibilidad documentada en App, Web y API, y la documentación de la API describe capacidades de thinking y herramientas. Esos hechos facilitan definir un ensayo, pero no prueban que un canal satisfaga por sí mismo requisitos de residencia de datos, retención, capacidad, precio o disponibilidad. Esas condiciones deben confirmarse para la cuenta, región y fecha de contratación concretas antes de una decisión de compra.

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.