Restricciones en tiempo de decodificación
Las restricciones de tiempo de decodificación, como técnica, son reglas estructurales
que un runtime aplica en el momento en que el modelo emite cada token, no después de que
la respuesta esté terminada. Cuando la regla dice "sin vocabulario prohibido" o "debe
producir JSON válido", el runtime hace que el token infractor sea matemáticamente
imposible — el modelo elige del conjunto de tokens válidos restantes. Esta técnica se
conoce como decodificación restringida, generación estructurada o generación guiada por
gramática, y está bien establecida en la literatura: la biblioteca [llguidance] de
Microsoft Research, [xgrammar] de Carnegie Mellon, las salidas estructuradas de vLLM
[vllm-multi-lora], y un cuerpo creciente de literatura sobre [llm-structured-output-2026].
Lo que está en producción hoy
La aplicación del vocabulario editorial en esta plataforma no usa restricciones de tiempo de decodificación. El mecanismo actual es una lista de palabras asesora verificada por un linter que se ejecuta después de la generación, no durante ella; ningún commit se bloquea jamás por una coincidencia, y las infracciones se registran como advertencias para revisión editorial.
La inferencia de producción en el Nivel A rechaza la decodificación restringida por
gramática y escala al Nivel B en su lugar — el runtime local no la admite. llguidance
se usa en otro punto de la plataforma, en el límite de la solicitud HTTP del Doorman, para
validar la sintaxis de gramática arbitraria proporcionada por quien llama — un paso de
validación de entrada, sin relación con la aplicación de vocabulario prohibido.
El mecanismo completo, planificado
Todo lo que sigue describe un diseño — coherente y factible, consistente con la técnica general anterior — no un sistema ya implementado. Cada verbo en tiempo presente en esta sección describe algo planificado o intencionado, no una capacidad actual.
El mecanismo previsto. Una gramática declararía qué vocabulario está prohibido; el runtime haría que el token infractor fuera inalcanzable en lugar de detectarlo después del hecho. La gramática se compondría en tres capas. Una gramática base cubriría las reglas de vocabulario prohibido universales para todo inquilino y género. Una gramática de inquilino cubriría extensiones específicas por cliente — palabras propias de marca en la lista de No-Usar, reglas de densidad de citas, patrones de afirmación prohibidos — redactadas localmente por el propio inquilino. Una gramática de género cubriría reglas estructurales por género: un TOPIC necesitaría un párrafo introductorio, una GUIDE necesitaría pasos numerados, una divulgación regulatoria necesitaría campos de cita específicos. En el momento de la solicitud, el Doorman compondría las tres capas y ejecutaría la decodificación con la restricción compuesta activa.
Por qué importaría si se construyera. La ruta editorial se volvería estructuralmente auditable en lugar de depender de revisión posterior: un TOPIC no podría contener un término prohibido porque la gramática se negaría a emitirlo; los términos prohibidos de un inquilino no podrían aparecer en la salida de ese inquilino; un patrón de cita requerido no podría omitirse silenciosamente. Esta es la forma de aplicación de la que eventualmente dependería la propiedad de composición federada del Sustrato Compuesto — pero esa dependencia es en sí misma prospectiva, no una descripción de cómo funciona hoy el entrenamiento federado.
Por qué este diseño, si se construyera, sería estructuralmente difícil de igualar para la IA gestionada por hiperescaladores
Tres razones, cada una condicionada a que el diseño anterior realmente se construya — no una afirmación sobre una capacidad vigente:
1. La gramática necesitaría redactarse localmente. Una restricción en tiempo de decodificación se ejecuta dentro del bucle de inferencia; redactar una gramática específica para los estándares editoriales de un inquilino requeriría acceso de escritura al archivo de gramática que carga el runtime. Los productos de IA gestionados por hiperescaladores tratan la gramática como parte del despliegue cerrado del modelo — los inquilinos obtienen modos de salida estructurada, no una gramática propia cargada en tiempo de inferencia.
2. La restricción necesitaría componerse con el enrutamiento de adaptadores. El Doorman ya enruta entre tres niveles de cómputo (véase Protocolo Doorman); una restricción de tiempo de decodificación necesitaría viajar con la composición de adaptadores que sirve una solicitud dada. La IA gestionada por hiperescaladores no expone primitivos de composición de adaptadores, y mucho menos de composición de restricciones — esta razón se sostiene independientemente de si la capa de gramática ya está construida.
3. La restricción necesitaría ser auditable. Por la postura de divulgación continua
de la BCSC ([ni-51-102]), toda salida editorial debería ser trazable a las reglas bajo
las cuales fue generada. El libro mayor de auditoría actual (véase Protocolo Doorman)
no lleva un campo de versión de gramática ni de hash de respuesta.
Trabajo planificado
Por la postura de divulgación continua de la BCSC ([ni-51-102]), esta plataforma
describe el mecanismo basado en gramática como planificado e intencionado, no
construido. En orden aproximado de dependencia:
- Una gramática base real (reglas de vocabulario prohibido universales), que reemplace al linter asesor actual.
- Fragmentos de gramática por género — todavía no existe ningún directorio de plantillas de género al cual adjuntarlos.
- Extensiones de vocabulario prohibido por inquilino (palabras específicas de marca de un cliente que estén en su lista de No-Usar).
- Composición de adaptadores en vivo con composición de gramática a través del Doorman.
- Entradas en el libro mayor de auditoría que registren
grammar_version+adapter_composition+response_hashpor solicitud — el esquema actual del libro mayor no tiene ninguno de estos campos (véase Protocolo Doorman).
Véase también
Cite this record: /wiki/decode-time-constraints — revision cb3da75f, last updated 17 August 2026.