¿Cuánta no-determinación tolera una feature?

Descripción

Ya tienes la forma de todo sistema AI-native: un núcleo probabilístico dentro de una cáscara determinista (lección 5). La pregunta que abre esta lección es la que decide cuánta arquitectura merece cada feature: ¿todas las features necesitan la misma cáscara? La respuesta es no, y la diferencia no es cuestión de gusto —se puede medir—. Cada feature de IA tolera una cantidad distinta de no-determinación. A la búsqueda semántica no le pasa gran cosa si un día ordena los resultados distinto; al agente que ejecuta reembolsos, un error le cuesta dinero real y confianza. De esa tolerancia se deriva, de forma directa, qué tan gruesa debe ser la cáscara: cuáles mecanismos de contención son obligatorios y cuáles son opcionales.

Esta lección convierte la intuición que asomaste en la lección 1 en un método. Vas a ver, ejecutada, la matriz feature × mecanismo: para cada feature de Mercado, la tolerancia calculada y —derivados de ella— los mecanismos de contención que se vuelven obligatorios. La búsqueda semántica, tolerante, pide una cáscara delgada (casi solo un eval y un lazo de datos); el agente de reembolsos, intolerante, pide todo, incluida la cáscara determinista completa porque toca dinero. El mismo patrón núcleo/cáscara, dimensionado a la medida del riesgo de cada feature.

Conexión con el módulo. La lección 5 te dio la cáscara; esta te dice cuánta cáscara. Es la lección que vuelve aplicable la metáfora: sin un criterio para dimensionarla, o sobre-diseñas features tolerantes o —peor— sub-diseñas las peligrosas. La lección 7 toma el resultado de esta —qué mecanismos necesita una feature— y lo formaliza en la hoja de propiedades; la 8 lo aplica a una feature real. La frontera con el resto de la guía: aquí decidimos cuáles mecanismos necesita cada feature, no cómo se construye cada uno —el eval a fondo es el módulo 3, los guardrails el 4, el fallback el 5, la cáscara el 6—. Y la frontera con AI Engineering se mantiene: la tolerancia se mide por el impacto de un error de la feature en el sistema (dinero, estado, confianza), no por qué tan "listo" sea el modelo por dentro.

Una analogía: los niveles de revisión en una empresa

En cualquier empresa sana, no todas las decisiones pasan por el mismo nivel de revisión. El nivel de escrutinio es proporcional a lo que está en juego.

Un empleado nuevo puede, sin que nadie lo apruebe, responder un correo de un cliente, redactar un borrador, proponer una idea en una reunión. Si se equivoca, el costo es bajo y reversible: se corrige el correo, se descarta el borrador. Su trabajo es tolerante al error, así que la empresa le da autonomía —revisarle cada correo sería absurdo y lo volvería inútil—.

Ese mismo empleado no puede, por su cuenta, firmar un contrato de un millón de pesos, transferir dinero de la empresa, o despedir a alguien. Esas decisiones son intolerantes al error: un error cuesta caro, es difícil de revertir, afecta a mucha gente. Por eso pasan por varios niveles de aprobación —un gerente, finanzas, a veces legal, a veces el consejo—. No porque el empleado sea tonto, sino porque lo que está en juego exige contención, sin importar qué tan bueno sea el empleado.

Y hay un punto intermedio: proponer un descuento a un cliente puede requerir el visto bueno de un supervisor, pero no del consejo. El nivel de revisión sube en escalones, a la medida del riesgo.

Aquí está el punto: la cáscara determinista de una feature de IA es su nivel de revisión, y se dimensiona igual que en la empresa —por lo que está en juego, no por lo bueno que sea el "empleado" (el modelo)—. La búsqueda semántica es el empleado nuevo respondiendo correos: tolerante, poca revisión, cáscara delgada. El agente de reembolsos es el que quiere firmar un cheque de la empresa: intolerante, máxima revisión, cáscara que lo abarca todo. Darle la misma cáscara a los dos es o asfixiar a la búsqueda con burocracia, o —el error caro— dejar que el agente firme cheques sin aprobación. Esta lección calcula, feature por feature, cuánto escrutinio merece cada una.

Ejemplo trabajado: de la tolerancia a los mecanismos obligatorios

Vamos a medir la tolerancia de cada feature de Mercado y a derivar de ella qué mecanismos de contención son obligatorios. La tolerancia es la misma de la lección 1 —lo inverso del riesgo, 18 - (touches + error_cost + blast)—, y la regla de derivación traduce ese riesgo en mecanismos: algunos son obligatorios siempre (todo LLM necesita una compuerta de eval y un lazo de datos), y otros se activan según cuánto toca el dinero, cuánto duele el error y cuánto se propaga.

# Lección 6: cuánta no-determinación tolera cada feature, y qué exige.
# La tolerancia NO es una opinión: la calculamos, y de ella se derivan los
# mecanismos de contención OBLIGATORIOS para cada feature de Mercado.

FEATURES = [
    # (name, touches_money_or_state, error_cost, blast_if_wrong)
    ("semantic_search",        1, 2, 2),
    ("recommendations",        1, 2, 3),
    ("describe_your_product",  1, 3, 2),
    ("support_agent_refunds",  5, 5, 5),
]


def nd_tolerance(touches, error_cost, blast):
    return 18 - (touches + error_cost + blast)  # 15 = muy tolerante, 3 = nada


def required_mechanisms(touches, error_cost, blast):
    tol = nd_tolerance(touches, error_cost, blast)
    # Menor tolerancia -> mas mecanismos obligatorios.
    req = {"eval_gate": True, "feedback_loop": True}  # siempre, para todo LLM
    req["guardrail"] = error_cost >= 3 or touches >= 3
    req["fallback"] = blast >= 3 or touches >= 3
    req["deterministic_shell"] = touches >= 3         # toca dinero/estado
    return tol, req


MECHS = ["eval_gate", "guardrail", "fallback", "deterministic_shell",
         "feedback_loop"]

ranked = sorted(FEATURES, key=lambda f: nd_tolerance(f[1], f[2], f[3]),
                reverse=True)

header = f"{'feature':<24}{'tol':>4}  " + "".join(f"{m[:9]:>11}" for m in MECHS)
print(header)
print("-" * len(header))
for name, touches, error_cost, blast in ranked:
    tol, req = required_mechanisms(touches, error_cost, blast)
    cells = "".join(f"{('req' if req[m] else '-'):>11}" for m in MECHS)
    print(f"{name:<24}{tol:>4}  {cells}")

print()
print("Lee la fila de arriba (semantic_search, tolerante): cascara delgada,")
print("solo eval_gate + feedback. La de abajo (refunds, intolerante): TODO,")
print("incluida la cascara determinista porque toca dinero.")

Qué esperar. Al correr el archivo, la salida es exactamente esta:

feature                  tol    eval_gate  guardrail   fallback  determini  feedback_
-------------------------------------------------------------------------------------
semantic_search           13          req          -          -          -        req
recommendations           12          req          -        req          -        req
describe_your_product     12          req        req          -          -        req
support_agent_refunds      3          req        req        req        req        req

Lee la fila de arriba (semantic_search, tolerante): cascara delgada,
solo eval_gate + feedback. La de abajo (refunds, intolerante): TODO,
incluida la cascara determinista porque toca dinero.

Lee la matriz de arriba hacia abajo, porque es un termómetro de tolerancia y, a la vez, un plano de contención.

Arriba, semantic_search con tolerancia 13. Su fila es casi toda guiones: solo eval_gate y feedback_loop marcados como obligatorios. Traducción: su cáscara es delgada. Necesita un eval (para saber si un cambio de modelo o prompt mejora o empeora la búsqueda) y un lazo de datos (los clicks y compras mejoran el sistema), pero no necesita un guardrail pesado, ni un fallback obligatorio, ni una cáscara determinista de validación de acciones —porque no toca dinero ni estado, y un resultado un poco distinto no le hace daño a nadie—. Contenerla más sería el error de revisarle cada correo al empleado nuevo.

Abajo, support_agent_refunds con tolerancia 3. Su fila está toda marcada req: eval, guardrail, fallback, cáscara determinista y lazo de datos. Traducción: su cáscara es gruesa, lo abarca todo. Toca dinero (por eso la deterministic_shell es obligatoria: la propuesta se valida contra la política antes de ejecutarse), un error le duele muchísimo (por eso el guardrail en entrada y salida), y su radio de impacto es enorme (por eso el fallback obligatorio para cuando el modelo falle). Es el empleado que quiere firmar un cheque: máxima revisión, sin excepción.

En medio, recommendations y describe_your_product, ambas con tolerancia 12 pero con cáscaras distintas, y esto es lo interesante. No basta la tolerancia total; importa de dónde viene el riesgo. Las recomendaciones activan el fallback (su blast_if_wrong es 3: si el modelo cae, muchas páginas quedan sin recomendaciones, así que necesitas una ruta degradada —por ejemplo, "los más vendidos"—). "Describe tu producto" activa en cambio el guardrail (su error_cost es 3: la descripción se publica, así que hay que prohibir claims falsos). Misma tolerancia, mecanismos obligatorios distintos, porque el riesgo entra por ejes distintos. La lección: la cáscara no se dimensiona con un solo número global, sino con el perfil de riesgo de la feature.

Profundización: el espectro de tolerancia y cómo se lee

Vale la pena entender bien el método, porque lo vas a aplicar a cualquier feature de IA, no solo a las cuatro de Mercado.

La tolerancia mide impacto, no calidad del modelo. Un error común es pensar "el agente de reembolsos necesita más cáscara porque el modelo es peor ahí". Falso: podría usar el mejor modelo del mundo y seguiría necesitando la cáscara más gruesa, porque lo que la determina es qué pasa si se equivoca (toca dinero), no qué tan seguido se equivoca. La tolerancia es una propiedad de la feature en el sistema, no del modelo. Por eso se calcula con touches_money_or_state, error_cost y blast_if_wrong —tres ejes de impacto— y ninguno mide la calidad del núcleo. Esto conecta directo con la lección 5: mejorar el núcleo (AI Eng) no cambia la tolerancia; solo cambia cuánta basura produce, no cuánto duele que se filtre.

El espectro tiene dos polos y un medio poblado.

  tolerante  ◄─────────────────────────────────────────►  intolerante
  (cáscara delgada)                                      (cáscara gruesa)

  semantic_search      recommendations                   support_agent_refunds
  describe_your_product
  ─────────────────    ─────────────────                 ─────────────────────
  eval + feedback      + fallback                         eval + guardrail +
                       + guardrail                        fallback + cáscara
                       (según el eje)                     determinista + feedback

En el polo tolerante, la cáscara es casi solo observación: mides la calidad (eval) y aprendes del uso (feedback), pero dejas al núcleo bastante suelto porque su error no hace daño. En el polo intolerante, la cáscara es una jaula: cada salida se valida, se contiene, se respalda con un fallback, y nada toca el dinero sin pasar por reglas deterministas. El medio es donde vive la mayoría de las features reales, y ahí el juicio importa: la misma tolerancia total puede pedir mecanismos distintos según por qué eje entra el riesgo.

Por qué eval y feedback son obligatorios siempre. Fíjate en que las dos primeras columnas están marcadas para todas las features, incluso la más tolerante. Es deliberado: todo componente de IA, por inocuo que parezca, necesita como mínimo una forma de medir su calidad (el eval, para saber si un cambio lo mejoró o lo rompió —módulo 3—) y una forma de aprender del uso (el feedback, el lazo de datos —módulo 7—). Sin eval, cambias el modelo a ciegas; sin feedback, el sistema nunca mejora. Son el piso de la cáscara, no un lujo de las features peligrosas. Los otros tres mecanismos —guardrail, fallback, cáscara determinista— se agregan según el riesgo.

El error simétrico de dimensionar mal. Como con las decisiones arquitectónicas en general, equivocarse tiene dos direcciones y no son iguales de graves. Sobre-dimensionar una feature tolerante (ponerle a la búsqueda semántica una cáscara determinista de validación de acciones que no toca ninguna acción) desperdicia esfuerzo y puede volver la feature lenta o rígida —un costo real pero acotado—. Sub-dimensionar una feature intolerante (dejar que el agente de reembolsos ejecute sin cáscara determinista) arriesga dinero, confianza y seguridad —un costo potencialmente catastrófico—. Por eso, ante la duda, el error más barato es dimensionar de más en las features que tocan dinero o estado, y de menos en las que no. La matriz de esta lección es justo la herramienta para no dimensionar a ojo.

Errores comunes

Darle a todas las features de IA la misma cáscara. Qué pasa: el equipo define un "framework de IA" interno con una cáscara fija —siempre guardrail, siempre validación pesada, siempre revisión— y lo aplica igual a la búsqueda que al agente. La búsqueda queda sobre-diseñada y lenta; o, en la versión opuesta, definen una cáscara ligera "para ir rápido" y la aplican también al agente de reembolsos, que queda peligrosamente desprotegido. Por qué pasa: una cáscara única es más fácil de estandarizar que una dimensionada por feature. Cómo detectarlo: tu proceso aplica el mismo nivel de contención a features con perfiles de riesgo muy distintos. Cómo corregirlo: dimensiona la cáscara por la tolerancia de cada feature. Calcula el impacto (los tres ejes), deriva los mecanismos obligatorios, y ajusta. Estandariza el método (cómo dimensionar), no la cáscara (el resultado).

Dimensionar por la calidad del modelo en vez de por el impacto. Qué pasa: "el modelo es buenísimo clasificando, casi no se equivoca, así que la clasificación no necesita cáscara". Se dimensiona la contención según qué tan bueno parece el modelo. Por qué pasa: es intuitivo pensar que un modelo mejor necesita menos protección. Cómo detectarlo: tu justificación para el grosor de la cáscara menciona la calidad del modelo, no el impacto de un error. Cómo corregirlo: separa las dos preguntas. "¿Qué tan seguido se equivoca?" (calidad, la baja AI Eng) es distinta de "¿cuánto duele que se equivoque?" (impacto, lo dimensiona la cáscara). Un modelo excelente que clasifica productos sigue necesitando la validación de pertenencia al catálogo (una regla barata que garantiza cero categorías inválidas), porque el impacto de una categoría inválida no depende de qué tan raro sea el error. Dimensiona por impacto, siempre.

Usar un solo número de tolerancia y perder el perfil de riesgo. Qué pasa: el equipo colapsa la tolerancia a un número ("esta feature es un 12, cáscara media") y aplica una cáscara "media" genérica, sin mirar por qué eje entra el riesgo. Termina poniendo un fallback donde hacía falta un guardrail, o al revés. Por qué pasa: un solo número es más cómodo que un perfil de tres ejes. Cómo detectarlo: dos features con la misma tolerancia total reciben la misma cáscara, aunque una tenga alto error_cost (pide guardrail) y la otra alto blast_if_wrong (pide fallback). Cómo corregirlo: usa la tolerancia total para la magnitud de la cáscara, pero mira los tres ejes por separado para saber qué mecanismos. Como en el ejemplo: recommendations y describe_your_product empatan en 12 pero necesitan mecanismos distintos, y solo el perfil por ejes lo revela. El número te dice cuánta cáscara; el perfil te dice de qué está hecha.

Ejercicios

Ejercicio 1 — Dimensiona una feature nueva. Mercado quiere agregar un detector de reseñas falsas: un LLM que lee cada reseña nueva y marca si parece spam o falsa; las marcadas se ocultan automáticamente del producto. Puntúa sus tres ejes (touches_money_or_state, error_cost, blast_if_wrong) de 1 a 5, calcula su tolerancia, y di qué mecanismos de contención serían obligatorios y por qué.

Ver solución

Una puntuación razonable (se puede argumentar variantes, lo importante es el razonamiento):

• touches_money_or_state = 3. No toca dinero, pero sí toca estado visible: ocultar una reseña automáticamente cambia lo que ven los clientes. No es un 5 (no mueve dinero) ni un 1 (no es solo lectura); es un 3 porque su salida tiene un efecto directo.
• error_cost = 4. Un falso positivo oculta una reseña legítima (injusto para el cliente y el vendedor, daña la confianza); un falso negativo deja spam visible. Duele bastante en ambas direcciones.
• blast_if_wrong = 3. Afecta a la reputación de productos y vendedores, un radio amplio pero no todo el sistema de pagos.

Tolerancia = 18 − (3 + 4 + 3) = 8 → cáscara media-tirando-a-gruesa. Mecanismos obligatorios según la regla:

• eval_gate y feedback_loop: siempre. Necesitas medir la precisión del detector y aprender de las correcciones (reseñas restauradas por soporte).
• guardrail: sí (error_cost ≥ 3). Validar la salida del modelo antes de ocultar.
• fallback: sí (blast_if_wrong ≥ 3). Si el modelo cae, no ocultar nada por defecto (degradar hacia mostrar, no hacia ocultar de más).
• deterministic_shell: sí (touches_money_or_state ≥ 3). Como oculta contenido automáticamente, conviene que el modelo proponga "ocultar" y una capa determinista decida —por ejemplo, no auto-ocultar reseñas de compradores verificados, o exigir revisión humana por encima de cierto volumen—. El modelo marca; la cáscara dispone.

Detalle de diseño que la solución debe notar: el sentido del fallback importa. Ante la caída del modelo, es más seguro no ocultar (dejar visible una reseña de más) que ocultar (silenciar reseñas legítimas sin revisión). El fallback honesto degrada hacia el lado menos dañino.

Ejercicio 2 — Mismo número, cáscara distinta. recommendations y describe_your_product tienen ambas tolerancia 12, pero la matriz les asigna mecanismos distintos: recomendaciones activa fallback y "describe tu producto" activa guardrail. Explica, para cada una, por qué ese mecanismo específico es el que su perfil de riesgo exige, y por qué el otro no es obligatorio.

Ver solución

Las dos empatan en tolerancia total (12), pero su riesgo entra por ejes distintos, y eso decide el mecanismo:

recommendations → fallback obligatorio (blast_if_wrong = 3). El riesgo dominante es de disponibilidad y alcance: las recomendaciones aparecen en muchísimas páginas a la vez. Si el modelo se cae, un montón de páginas quedan sin recomendaciones al mismo tiempo —radio de impacto alto—. Por eso necesita un fallback obligatorio: cuando el modelo no responda, mostrar algo determinista ("los más vendidos", "productos de la misma categoría") para que la página no quede vacía. En cambio, el guardrail no es obligatorio porque su error_cost es bajo (2): una recomendación mediocre no publica un claim falso ni hace daño real, solo es menos útil.

describe_your_product → guardrail obligatorio (error_cost = 3). El riesgo dominante es de contenido: la descripción se publica con la marca de Mercado, así que una salida mala (un claim falso, un dato inventado) es un daño visible y potencialmente legal. Por eso necesita un guardrail obligatorio que valide el contenido —prohibir claims prohibidos, acotar longitud— antes de que se pueda publicar. En cambio, el fallback no es obligatorio porque su blast_if_wrong es bajo (2): si el modelo se cae, un vendedor no puede generar su descripción en ese momento (molesto, pero acotado a él), no se cae media plataforma —no hay un radio de impacto amplio que exija una ruta degradada obligatoria—.

La lección: la magnitud de la cáscara la da la tolerancia total, pero qué mecanismos la componen lo da el perfil por ejes. Colapsar todo a "cáscara media" perdería justo esta distinción y pondría el mecanismo equivocado en cada una.

Ejercicio 3 — El costo de sub-dimensionar. Un gerente, presionado por tiempo, propone lanzar el agente de reembolsos con la cáscara de la búsqueda semántica ("solo eval y feedback, sin cáscara determinista, para salir rápido; total, el modelo es muy bueno"). Explica, usando el concepto de error simétrico, por qué esta es la dirección más peligrosa de equivocarse, y contrasta con el costo de haber sobre-dimensionado la búsqueda.

Ver solución

Los dos errores de dimensionamiento no cuestan lo mismo, y este es el caro.

Sub-dimensionar el agente de reembolsos (lo que propone el gerente) significa quitarle la deterministic_shell a una feature que toca dinero. Sin esa cáscara, la propuesta del modelo se ejecuta directo —y ya lo mediste en la lección 3—: un reembolso de $9999 alucinado, un reembolso sobre un pedido que no existe, o la respuesta a un prompt injection ("reembólsame todo") se convierten en pérdidas reales. El argumento "el modelo es muy bueno" es exactamente el error de dimensionar por calidad y no por impacto (lección 5 y esta): un modelo mejor alucina menos seguido, pero cada alucinación que se escape es dinero perdido, y a escala eso es catastrófico e irreversible. La dirección es peligrosa porque el costo del error no está acotado: es dinero, es confianza, es seguridad.

Sobre-dimensionar la búsqueda semántica (el error opuesto) sería ponerle a la búsqueda una cáscara determinista de validación de acciones y revisión humana que no necesita, porque no toca ninguna acción. El costo: esfuerzo de ingeniería desperdiciado, y quizás una búsqueda más lenta o rígida de lo necesario. Molesto, pero acotado y reversible —se quita la cáscara de más y listo—.

El error simétrico: sub-dimensionar lo intolerante arriesga un costo catastrófico e irreversible (dinero); sobre-dimensionar lo tolerante desperdicia un costo acotado y reversible (esfuerzo). Por eso, ante presión de tiempo, jamás se recorta la cáscara de una feature que toca dinero —es justo la que no admite atajos—. Si hay que salir rápido, se recorta alcance (menos tipos de ticket que el agente atiende), no contención. "Salir rápido" nunca justifica quitarle la jaula al que quiere firmar cheques.

Resumen y siguiente paso

En esta lección convertiste la metáfora núcleo/cáscara en un método de dimensionamiento: la tolerancia a la no-determinación de cada feature decide qué tan gruesa debe ser su cáscara. Lo mediste con la matriz feature × mecanismo: la búsqueda semántica (tolerancia 13) pide una cáscara delgada —casi solo eval y feedback—; el agente de reembolsos (tolerancia 3) pide todo, incluida la cáscara determinista porque toca dinero. Y viste dos sutilezas clave: la tolerancia mide impacto, no calidad del modelo (un modelo mejor no cambia cuánta cáscara necesita la feature); y dos features con la misma tolerancia total pueden necesitar mecanismos distintos según por qué eje entra su riesgo, así que la magnitud la da el número pero la composición la da el perfil. El error de sub-dimensionar lo que toca dinero es mucho más caro que el de sobre-dimensionar lo inocuo.

Antes de avanzar deberías poder: calcular la tolerancia de una feature con los tres ejes; derivar de ella los mecanismos de contención obligatorios; explicar por qué eval y feedback son el piso de toda cáscara; y argumentar por qué el error de dimensionamiento es asimétrico.

La lección 7 recoge todo lo que el módulo produjo —ubicación, tolerancia, y los mecanismos que cada feature necesita— y lo formaliza en un solo artefacto: la hoja de propiedades de un componente de IA. Vas a ver, ejecutada, la hoja de la búsqueda semántica de Mercado, con cada campo —ubicación, presupuesto, eval, guardrail, fallback, cáscara, lazo de datos— apuntando al módulo de la guía que lo trabaja a fondo. Es el puente directo a M2-M8: la hoja que llenas al terminar M1 es, literalmente, el índice del resto de la guía.

Recursos

• Martin Fowler y Bharani Subramaniam, "Emerging Patterns in Building GenAI Apps" — martinfowler.com/articles/gen-ai-patterns. El artículo distingue casos de uso por su tolerancia al error (de creativos a críticos) y ajusta los patrones según eso —la idea de esta lección aplicada a su catálogo—. En inglés.
• Anthropic, "Building Effective Agents" (2024) — anthropic.com/engineering/building-effective-agents. Su recomendación de igualar la complejidad de la solución al riesgo de la tarea —no usar un agente autónomo donde basta un flujo simple— es el mismo principio de dimensionar la cáscara por la tolerancia. En inglés.
• Chip Huyen, AI Engineering (O'Reilly, 2024). El tratamiento del riesgo de cada caso de uso y de cuándo poner humano-en-el-lazo se conecta directo con las features intolerantes de esta lección. En inglés.
• Jeff Bezos, Carta a los accionistas de Amazon (2015) — sec.gov/Archives/edgar/data/1018724/000119312516530910/d168744dex991.htm. Las "puertas de una vía y de dos vías" —decisiones irreversibles merecen más deliberación— son el mismo razonamiento de error asimétrico que dimensiona la cáscara: lo irreversible (tocar dinero) exige más contención. En inglés.