.jpg)
Propósito de este documento: este texto registra el contexto histórico, las motivaciones arquitectónicas y la justificación detrás de las decisiones de diseño de FACET. Su objetivo es responder a una pregunta recurrente en el futuro: por qué FACET se diseñó de esta manera y no de otra. No es un registro de cambios ni una hoja de ruta, sino un documento de razones dirigido a futuros mantenedores, revisores estándar, arquitectos empresariales e historiadores de infraestructura de IA.
Era previa a FACET 2018–2022: en los primeros sistemas con modelos de lenguaje grande los prompts se trataron como cadenas opacas y artefactos mutables en tiempo de ejecución. La ingeniería de prompts evolucionó hacia plantillas por copiar y pegar, reintentos ad hoc y extracciones con expresiones regulares, lo que dejó las fallas para procesarlas después de la generación en lugar de prevenirlas. Surgió la falsa suposición de que la poca fiabilidad de los LLM era inherente e inevitable.
Salida estructurada no resolvió el problema: se introdujeron esquemas JSON en prompts, APIs de llamada a funciones y validadores al estilo Pydantic, pero esas especificaciones eran orientativas y no ejecutables: los proveedores interpretaban restricciones de forma diferente, seguían produciéndose estados inválidos y la validación ocurría tras la respuesta del modelo, permitiendo estados intermedios inválidos.
FACET v1.x 2022–2024: FACET nació como sistema de plantillas deterministas. Introdujo bloques estructurados, lógica condicional, pipelines de lentes tempranas y salida canonizada en JSON. Lo acertado fue que la determinismo permitió cachés y diffs, la salida JSON canónica facilitó comparación y la composición sustituyó a prompts monolíticos. Sin embargo, faltaron un sistema de tipos, un modelo de ejecución formal y una noción operativa de estado inválido, por lo que no se prevenían fallas en llamadas a herramientas ni se eliminaba la posibilidad de estados inconsistentes.
Punto de quiebre 2024–2025: a escala aparecieron fallos sistémicos inevitables, como agentes multi-herramienta que fallaban de forma no determinista, reglas específicas de proveedores que provocaban roturas silenciosas, divergencias entre streaming y no streaming, truncamiento de contexto que corrompía la lógica y reintentos que enmascaraban errores de corrección. Estas fallas se volvieron costosas, no reproducibles e imposibles de auditar. Las respuestas reactivas de la industria —añadir reintentos, validadores y guardrails— no convergieron en una solución robusta.
Insight central: FACET v2.0 nace de una sola realización fundacional: no se pueden construir sistemas fiables sobre contratos no deterministas. El problema no eran los modelos en sí, sino la ausencia de una capa de contratos que haga explícitas las garantías y restricciones antes de la ejecución.
FACET v2.0 2025: un reinicio estructural. FACET se rediseñó intencionalmente como un compilador, no como un motor de plantillas; como un sistema de contratos, no como una librería auxiliar; y como un modelo de ejecución, no como un parche en tiempo de ejecución. La determinismo se logra como propiedad arquitectónica: los estados inválidos se previenen antes de ejecutar, los contratos se aplican upstream y las salidas se canonizan.
JSON canónico como representación intermedia: FACET adopta JSON canónico como IR neutral respecto al proveedor, estable en hash, amigable para diffs y reproducible. Esto desacopla autoría, ejecución y renderizado, evitando vendor lock-in y permitiendo auditoría y reejecución fiables.
Fases de ejecución y R DAG: FACET formaliza la ejecución en cinco fases: resolución, comprobación de tipos, cómputo reactivo mediante un grafo dirigido acíclico reactivo R DAG, disposición con un modelo de cajas de tokens y renderizado. Esta estructura elimina órdenes de ejecución implícitas, efectos secundarios ocultos y conjeturas en tiempo de ejecución.
Modelo de caja de tokens: el manejo de contexto se redefine como un problema de asignación de recursos con prioridades explícitas y reglas de compresión deterministas. Esto sustituye heurísticas de truncamiento y empaquetado de mejor esfuerzo que provocaban pérdida silenciosa de datos críticos.
Adaptadores como traductores puros: los adaptadores se limitan a traducir sin lógica, inferencia o recuperación. Esa restricción preserva la auditabilidad, la reproducibilidad y la estabilidad a largo plazo del sistema.
Alternativas rechazadas: FACET descarta por diseño reintentos probabilistas, auto-reparación de prompts, reescritura adaptativa de prompts y reparación de esquemas en tiempo de ejecución. Estas técnicas tienden a ocultar fallos en lugar de eliminarlos y perjudican la trazabilidad.
Posicionamiento a largo plazo: FACET está pensado para envejecer como LLVM, SQL o JSON Schema: aburrido, estricto y predecible durante décadas. No pretende ser un framework de agentes, un SDK de proveedor o una simple caja de herramientas para prompts.
Atribución histórica: FACET Deterministic Contract Layer desde 2025. Autor original Emil Rokossovskiy. La idea central precede al consenso de la industria y cuando la necesidad de determinismo se volvió urgente, la arquitectura ya existía.
Sobre Q2BSTUDIO: somos una empresa de desarrollo de software y aplicaciones a medida especializada en inteligencia artificial, ciberseguridad y servicios cloud. Ofrecemos soluciones personalizadas de software a medida y aplicaciones a medida que incorporan agentes IA y capacidades de IA para empresas, además de servicios de ciberseguridad y pentesting y consultoría en servicios cloud aws y azure. Si busca potenciar sus proyectos con modelos confiables y contratos explícitos, descubra nuestras soluciones de inteligencia artificial en servicios de inteligencia artificial para empresas y conozca cómo desarrollamos aplicaciones robustas en software a medida y aplicaciones a medida. También ofrecemos servicios de inteligencia de negocio y Power BI, automatización de procesos y consultoría integral en seguridad y cloud para garantizar implementaciones escalables y auditables.
Palabras clave integradas: aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA y power bi.
Estado del documento: informativo. No define nuevos requisitos, solo explica por qué existen las decisiones y requisitos actuales.
