aicert.study
Trayecto de Estudio/Haga observable el contexto extenso

Haga observable el contexto extenso

75 min

Recomendamos ver antes: Ubique cada hecho en el tipo correcto de contexto

Objetivos de la lección

  • Rastrear procedencia, conflictos y marcas de tiempo en bases de código demasiado grandes para leerlas por completo
  • Usar scratchpads, manifiestos y compactación en lugar de aumentar el contexto
  • Calibrar cuándo escalar la ambigüedad en lugar de decidir por cuenta propia

El problema

Un agente autónomo recibe la tarea de actualizar un parámetro de configuración que aparece en cuatro ubicaciones distintas de un monorepositorio de 400.000 líneas. Localiza los cuatro puntos en el código, pero descubre valores contradictorios: un archivo indica que el timeout es de 30 segundos, mientras que otro define 90 segundos. El agente elige uno de ellos de forma arbitraria y silenciosa, sin advertir sobre la contradicción, y completa la tarea. El cambio supera las pruebas de integración continua (ya que ningún test cubría esa divergencia específica) y traslada a producción un comportamiento inconsistente que solo se manifiesta bajo picos de carga.

El agente no alucinó. Tomó una decisión razonable bajo información insuficiente — y el fallo arquitectónico real fue no haber señalado que la decisión se tomó bajo incertidumbre no resuelta. Esta es la premisa central de esta lección: en contextos extremadamente extensos donde la revisión humana exhaustiva línea por línea es inviable, la pregunta no es solo "qué hago con lo que observo", sino "¿debe el agente decidir de forma autónoma o escalar a revisión humana?".

Proveniencia de datos: cada hecho conserva su origen y fecha

En tareas que involucran múltiples archivos, servicios externos o revisiones de esquemas, cada hecho relevante debe registrar su origen y fecha de observación, no solo el valor escalar:

{
  "fact": "timeout = 90s",
  "source": "config/prod.yaml",
  "observed_at": "2026-08-15",
  "conflicts_with": ["config/staging.yaml: timeout = 30s"]
}

Registrar la proveniencia transforma un conflicto en un elemento visible y citable en lugar de resolverlo silenciosamente. La diferencia entre un sistema con trazabilidad de proveniencia y uno sin ella es la diferencia entre "detecté una discrepancia, aquí están las dos fuentes" y "elegí un valor arbitrariamente y nadie sabrá que existía una alternativa".

Las marcas de tiempo de observación son igualmente críticas: un dato extraído hace tres meses puede haber quedado obsoleto. Sin registrar cuándo se observó cada hecho, resulta imposible distinguir información vigente de estados históricos descartados.

Haz que el contexto sea navegable en lugar de inflar su tamaño

El reflejo habitual frente a bases de código masivas es intentar volcar directorios completos en la ventana de contexto. Esto rara vez funciona: incluso cuando los tokens caben dentro de los límites técnicos, la atención del modelo se degrada ante información ubicada en el medio de secuencias muy extensas (el efecto "lost in the middle"). Las soluciones arquitectónicas efectivas son estructurales:

  • Scratchpads: espacios de trabajo externos persistentes donde el agente anota descubrimientos intermedios, evitando recalcular los mismos hechos dentro del turno conversacional.
  • Índices y manifiestos: catálogos estructurados de metadatos (mapas de archivos, dominios y ubicaciones de configuración) que sustituyen las lecturas completas por consultas dirigidas.
  • Poda y compactación: resumir y descartar deliberadamente contexto intermedio a medida que se completan hitos.
  • Subagentes con contexto aislado: delegar investigaciones profundas a subagentes que devuelven resúmenes estructurados sin saturar la sesión principal.

El principio de diseño esencial: los retos de contextos extensos no se resuelven ampliando el límite de tokens, sino estructurando la información para que solo lo indispensable ingrese al contexto activo, manteniendo el resto consultable bajo demanda.

Calibrar la resolución autónoma frente al escalamiento

No toda ambigüedad justifica detener el sistema a la espera de un humano, ni toda ambigüedad debe resolverse silenciosamente. El criterio práctico:

  • Resolver autónomamente: cuando el costo de error es insignificante y fácil de revertir (por ejemplo, decisiones de formateo de código o nombres de variables internas sin impacto funcional).
  • Escalar a revisión humana: cuando hechos contradictorios impactan el comportamiento en producción, cuando la decisión tiene alta irreversibilidad o cuando la certeza es baja en rutas críticas.

El fallo del escenario inicial ocurrió porque el agente resolvió de forma autónoma una discrepancia en la configuración de producción — una decisión de alto impacto que debió activar una compuerta de escalamiento.

Ponlo en práctica

En el laboratorio de esta lección construirás un motor de proveniencia en Python: procesará hechos de múltiples fuentes contradictorias, detectará discrepancias automáticamente y enrutará cada caso entre la resolución automática o el escalamiento a operadores humanos basándose en matrices de impacto y reversibilidad.

Laboratorio práctico

Clona el repositorio y ejecútalo localmente:

git clone https://github.com/aicertstudy/labs
cd labs/ccar-f/lessons/21-long-context-reliability-provenance-and-escalation
Ver carpeta en GitHub

¿Listo para ponerlo a prueba de verdad?

Haz el simulacro completo del CCAR-F, con el mismo formato del examen oficial.

Ver simulacros

Checkpoint de la lección

Cargando quiz...