Qué revisar cuando cambia un modelo: dependencias con SQLite

La pregunta que resuelve este grafo

Una automatización utiliza una versión de un modelo. Hay una guía que explica cómo instalarla y una ficha que recoge sus condiciones. Cuando llega una nueva versión, necesitas saber qué revisar antes de dar por vigente lo que habías publicado.

Un grafo pequeño puede conservar esas relaciones. En este tutorial trabajamos con tres elementos ficticios: una guía de CRM, un workflow y la versión de un modelo. La guía documenta el workflow; el workflow usa el modelo. Recorrer las relaciones en sentido inverso permite partir del modelo y localizar los elementos que dependen de él.

El resultado es una lista para preparar la revisión. Que una guía dependa del modelo no demuestra que esté equivocada, y que un workflow use esa versión no demuestra que la actualización lo rompa. Esa segunda pregunta necesita pruebas de regresión.

Descarga y ejecuta la práctica

Descarga el código, las pruebas y la salida observada. Descomprime el archivo y abre una terminal en dependencias-sql-v1. Requiere Python 3.10 o posterior con SQLite y no instala dependencias. Todo funciona en memoria y con datos sintéticos.

python3 graph_sql_lab.py --output salida-sql.json
python3 -m unittest -v test_graph_sql_lab.py

El paquete contiene agentic_lab.py, que define las relaciones del ejemplo; graph_sql_lab.py, que carga las tablas y ejecuta la consulta; y las pruebas del contrato. No necesitas un modelo ni un servicio de base de datos.

En la verificación del 19 de septiembre de 2026, con Python 3.14.4 y SQLite 3.51.3 en Linux, la consulta devolvió:

Las seis pruebas de software pasaron. Comprueban el recorrido transitivo, el filtro de conocimiento temporal, el límite de profundidad, un identificador tratado como dato, la integridad referencial y el rechazo de profundidad negativa. No miden escalabilidad ni calidad de un modelo.

Representa relaciones que puedas explicar

La tabla nodes contiene las identidades. La tabla edges incluye origen, tipo de relación, destino, referencia y fechas. Son decisiones del diseño de esta práctica:

Las referencias doc1 a doc5 son ficticias. En una herramienta real deberían apuntar a manifiestos, pruebas o fuentes comprobables. Un índice o una clave foránea no valida la verdad de una afirmación.

El código activa PRAGMA foreign_keys = ON para esa conexión y evita aristas hacia nodos inexistentes. Consulta la documentación de claves foráneas de SQLite al trasladar el diseño a tu aplicación.

Consulta en dirección inversa

La práctica utiliza una expresión de tabla común recursiva, o CTE: una consulta que vuelve a aplicar un paso sobre los resultados del anterior. SQLite documenta este mecanismo para jerarquías y grafos.

Este es el núcleo del recorrido en el archivo descargable:

SELECT e.source, i.depth + 1, i.path || e.source || ','
FROM edges e
JOIN impacted i ON e.target = i.node
WHERE e.relation IN ('DOCUMENTA', 'USA')
  AND e.valid_from <= :valid_at
  AND (e.valid_to IS NULL OR :valid_at < e.valid_to)
  AND e.recorded_at <= :known_at
  AND i.depth < :max_depth
  AND instr(i.path, ',' || e.source || ',') = 0

La unión encuentra aristas cuyo destino es el nodo que estamos revisando y devuelve su origen. El filtro de relación evita expandir cualquier enlace meramente asociado al modelo. La consulta final agrupa por nodo y conserva la distancia mínima.

Los valores de búsqueda se pasan como parámetros. El camino visitado evita volver a un nodo dentro del mismo recorrido; en este ejemplo, los identificadores no pueden contener comas. Es una restricción deliberada de la representación, no una regla general de los grafos.

Cambia profundidad y fecha

Prueba estas consultas desde una terminal dentro del directorio descargado:

python3 - <<'PY'
from graph_sql_lab import connect, impact
db = connect()
print(impact(db, max_depth=1))
print(impact(db, valid_at='2026-08-02', known_at='2026-08-02'))
db.close()
PY

Con profundidad uno aparece el workflow, pero la guía queda fuera. Con el segundo corte temporal solo aparece el modelo: la relación que conecta esa versión con el workflow tiene fecha de incorporación del 5 de agosto, posterior al corte consultado.

Esto sirve para distinguir la vigencia indicada de la fecha en que conocimos una relación. El conjunto es estático: no conserva todas las ediciones históricas de sus afirmaciones. Si cambias valid_to sobre una fila antigua, necesitarás un modelo de historial adicional para reconstruir fielmente lo que se sabía antes de esa corrección.

Conviértelo en una cola de revisión

Una aplicación posible para un Atlas de automatizaciones es enlazar versión del modelo, configuración probada, informe y guía. Una novedad detectada podría generar una lista de candidatos a revisión con la ruta que explica cada dependencia.

La persona editora decidiría qué volver a ejecutar, qué actualizar y qué mantener. Un cambio de versión no debería reescribir las conclusiones anteriores ni convertir una configuración nueva en probada. Los resultados pertenecen a la versión y al entorno que los produjeron.

Esta integración todavía es una propuesta: el laboratorio utiliza cinco aristas sintéticas y no lee ni actualiza automáticamente el Atlas de IA en Uso. Antes de conectarlo, hay que definir identidades, procedencia y política de actualización.

Límites que importan al crecer

Un límite de profundidad no limita por sí solo el número de caminos. Un grafo con muchas bifurcaciones puede generar mucho trabajo en pocos niveles. Para un conjunto real, mide tiempo, volumen y cantidad de resultados; añade límites de trabajo y un tratamiento explícito de consultas incompletas.

Tampoco necesitas recuperar todas las relaciones para cada pregunta. La consulta de impacto de este tutorial solo sigue dos tipos. Una búsqueda de fuentes, una consulta de compatibilidad o una investigación de causas requerirían contratos distintos.

Empieza por la pregunta que quieres resolver y comprueba que los datos la sostienen. El ejemplo permite aprender y repetir una consulta concreta; elegir otro motor o introducir GraphRAG exigiría una necesidad y una evaluación adicionales.