Frontera probabilística

COADF P-1 enuncia el mínimo: un componente probabilístico devuelve un valor junto con una confianza y el método con el que se obtuvo el valor, nunca un valor desnudo, y nunca llega directamente a una salida. Este patrón trata de la segunda mitad, que es la que las implementaciones pierden. La respuesta de un modelo puede entrar en el sistema. Lo que no puede es convertirse, por ningún camino, en aquello que el sistema trata como establecido.

Tienen que cumplirse tres cosas a la vez:

• La salida tiene un tipo propio. Una propuesta y un registro autorizado son tipos distintos, tablas distintas o mensajes distintos. El código que tiene uno no puede pasarlo donde se espera el otro sin un paso explícito que alguien pueda revisar.
• La frontera valida en tiempo de ejecución. El contrato se comprueba cuando llega la respuesta, en el proceso que la recibe, diga lo que diga el emisor sobre lo que comprobó.
• La procedencia viaja con el valor. El método, el modelo y su versión, la versión del prompt y la ubicación en la fuente permanecen unidos a él en cada paso, serialización incluida. Sin ellos, P-4 no puede reconstruir y P-5 no puede declarar.

P-1 también exige que el componente informe una confianza. Cómo se expresa, se asigna y se usa la confianza corresponde a P-2, que COADF publica solo como principio. Este Companion no lo describe, y nada de lo que sigue depende de ello.

La salida de un modelo procede de un proceso que no puede reproducirse a partir de sus entradas como sí puede la salida de un parser: el muestreo, las actualizaciones del modelo y los cambios de prompt la desplazan. Eso es aceptable para una propuesta e inaceptable para un hecho. El riesgo no es que un modelo se equivoque a veces; todo se equivoca a veces. El riesgo es perder la capacidad de decir qué valores vinieron de dónde, porque todo control posterior depende de ello. Una barrera solo detiene lo que puede ver, una declaración solo nombra lo que está marcado y una persona revisora solo comprueba lo que todavía apunta a su fuente.

La pérdida rara vez es una decisión. Ocurre en una línea de código corriente: una entidad del ORM rellenada con el JSON del modelo porque los nombres de los campos coincidían, un modelo de respuesta que descarta la procedencia porque nadie la añadió, una importación por lotes que evita el formulario donde vivía la validación. El patrón existe para que esa línea no pueda escribirse sin que nadie lo note.

El aislamiento es arquitectónico, no necesariamente físico

No hacen falta microservicios. La propiedad se cumple cuando ningún camino de código permite al lado probabilístico producir un objeto autorizado, y un solo proceso puede mantenerla tan bien como una red. Conviene elegir la topología por sus propias razones (escalar por separado una carga de inferencia, aislar la biblioteca cliente de un proveedor, desplegar de forma independiente) y después construir la frontera en la forma elegida. Las cuatro figuras siguientes mantienen la misma propiedad en cuatro formas.

Los mismos cuatro elementos en cada topología

• Tipos distintos. El lado probabilístico puede construir una propuesta y nada más. El registro autorizado lo construye solo el código de dominio, a partir de una propuesta y de algo que el lado probabilístico no puede producir.
• Validación en tiempo de ejecución en cada lado receptor. Un esquema estricto: campos no declarados rechazados, sin conversión de tipos, vocabularios cerrados para los valores categóricos, longitudes acotadas. En una topología distribuida valida cada receptor, también el lado del dominio cuando el emisor es un servicio propio: “validamos antes de enviar” es una afirmación sobre otro desplegable, quizá sobre una versión anterior de él.
• La procedencia en el contrato. Declarada, obligatoria y preservada por cada mapeador y serializador en el camino de salida.
• Un paso de promoción explícito. La única vía de la propuesta al registro autorizado es una función, un endpoint o un comando que exige lo que el lado probabilístico no puede aportar. Para los valores derivados por un modelo de lenguaje, el fence público F-03 de COADF exige verificación humana antes de que lleguen a una salida publicada. La propia promoción queda registrada en la traza de auditoría.

Validación determinista en torno a una salida estocástica

Las comprobaciones que leen solo el valor (su forma, su vocabulario, su unidad, los rangos que define el propio dominio) se ejecutan antes de que ninguna persona lo mire. No hacen verdadero un valor. Hacen imposible un valor imposible, y lo hacen siempre de la misma manera, algo en lo que puede apoyarse la persona que revisa el valor.

Opciones de aplicación, de la más débil a la más fuerte

La mayoría de los sistemas quiere los tres primeros siempre, y los dos últimos cuando el componente probabilístico se despliega por separado. El perfil de Python y FastAPI implementa los tres primeros; el perfil cloud-native añade los dos últimos.

• Interfaces solo de sugerencia. La salida del modelo se muestra a una persona como sugerencia y nunca se almacena como valor. Sencillo y robusto; renuncia a la trazabilidad de lo sugerido salvo que también se registren las sugerencias.
• Un contrato compartido y neutral respecto del lenguaje (JSON Schema, Protocol Buffers) en lugar de modelos nativos de cada lenguaje. Mejor entre lenguajes; traslada la cuestión de la estrictez al esquema, donde las propiedades adicionales y los formatos tienen que decidirse de forma explícita.
• Modos de salida estructurada de las API de modelos. Reducen las respuestas mal formadas en el productor. No eximen al consumidor de validar, porque el consumidor no puede verificar cómo se configuró el productor.
• Almacenamiento separado para propuestas y registros, dos tablas o dos almacenes en lugar de una tabla con un estado. Más pesado, y hace visible la separación en cada consulta que cualquiera escriba.

• La frontera controla adónde puede ir la salida del modelo. No hace correcta la salida del modelo, y un valor erróneo bien formado supera todas las comprobaciones de este patrón.
• La separación de tipos detiene accidentes, no intenciones. Quien tiene acceso de escritura al dominio puede construir a mano un objeto autorizado; la revisión de código y la traza de auditoría son lo que lo hace visible.
• Este patrón no dice cuándo una propuesta necesita a una persona ni cómo se expresa la confianza. Eso corresponde a P-2 y P-3, que COADF publica solo como principios.
• La validación vale lo que vale el contrato. Un esquema permisivo, validado de forma estricta, sigue siendo permisivo.