DeepSeek V4.1 Flash habria reducido sus rechazos del 81,6% al 4,3% en 838 prompts

Imagine que compra una caja fuerte y descubre que su cerradura de combinacion puede retirarse con un destornillador en una sola tarde. Esa es, aproximadamente, la imagen que dibuja una publicacion viral en X sobre DeepSeek V4.1 Flash. El autor afirma que alguien elimino la mayoria de los rechazos del modelo mediante OBLITERATUS, una herramienta gratuita y de codigo abierto publicada por Pliny.

Que se afirma exactamente

La publicacion aporta apenas unos cuantos datos. Segun su autor, el modelo original se negaba a responder al 81,6% de 838 prompts de prueba. Tras la modificacion, la tasa de rechazo cayo al 4,3%. La herramienta se presenta como gratuita y abierta, pero la publicacion no ofrece mas detalles tecnicos.

Lo que no sabemos es igualmente importante. Se desconoce que prompts concretos formaban el conjunto de 838 elementos, como se definio un rechazo y quien realizo la medicion. Tampoco hay datos sobre como cambio la calidad del modelo en tareas habituales, como programacion, razonamiento y trabajo con contextos largos. La publicacion no enlaza a un experimento reproducible y su alcance es modesto, con unas 4.600 visualizaciones. Por tanto, las cifras deben considerarse una afirmacion, no un resultado verificado.

Por que esto es posible en principio

El rechazo de un modelo de lenguaje no depende de un "boton" separado. Se forma durante el entrenamiento y queda codificado en los pesos. Hace tiempo que los investigadores demostraron que, en muchos modelos, el comportamiento de rechazo se reduce a una direccion relativamente estrecha dentro de sus representaciones internas. Si se identifica esa direccion y se "resta" de las activaciones o los pesos, el modelo deja de responder con rechazos ante temas prohibidos. Esto se conoce como ablacion de rechazos y, dentro de la comunidad, tambien como "abliteration." El nombre OBLITERATUS alude a esta clase de metodos, aunque la publicacion no confirma la implementacion concreta.

La propiedad clave de este enfoque es que exige acceso a los pesos, pero no un costoso entrenamiento adicional. Por eso, ante cualquier modelo abierto, la pregunta habitual es cuando aparecera una version sin rechazos, no si llegara a existir.

Que deben hacer los desarrolladores y los equipos de producto

Primero: no considere la alineacion integrada como la unica linea de defensa. Si su producto utiliza un modelo abierto, los rechazos de la version base no garantizan la seguridad. Hacen falta filtros propios de entrada y salida, moderacion independiente y registro de actividad. Una configuracion habitual incluye un clasificador de solicitudes, comprobaciones de las respuestas y limites para las acciones peligrosas que puede ejecutar un agente.

Segundo: si utiliza checkpoints ajustados por terceros desde Hugging Face o plataformas similares, compruebe su procedencia. Un modelo con un nombre parecido puede comportarse de manera completamente distinta al oficial. Ejecute su propio conjunto de pruebas de red team antes de desplegarlo en produccion, especialmente en el caso de agentes con acceso a herramientas y datos.

Tercero: para los equipos que publican pesos abiertos, esto es un recordatorio sobre el modelo de amenazas. La alineacion incorporada en los pesos protege frente al uso indebido accidental, pero no frente a modificaciones deliberadas. Se necesitan medidas adicionales: licencias, supervision del uso mediante una version API y versiones separadas para distintos niveles de riesgo.

Limitaciones y conclusion

Solo existe una fuente: una publicacion en una red social con un titular emocional. Para los desarrolladores, no es motivo para entrar en panico, sino para revisar sus supuestos. Si desarrolla sobre una API cerrada, su situacion es distinta: los pesos no estan disponibles y esta tecnica no funcionara. Si trabaja con modelos abiertos, agregue una pregunta a su lista de comprobacion: que ocurrira cuando desaparezcan los rechazos? La respuesta debe incluir una capa de seguridad bajo su propio control, no solo la del desarrollador del modelo.

Es poco probable que la historia de DeepSeek V4.1 Flash sea la ultima de este tipo. Cuanto mas potente sea un modelo abierto, antes apareceran herramientas para eliminar sus restricciones y mas importante sera la arquitectura de seguridad que lo rodea.