Forma de la ontología vs tamaño del modelo: cuánto cuesta el diseño de un grafo a un agente de IA

Cuando un agente no rinde como debería, la solución a la que recurren la mayoría de los equipos es utilizar un modelo más grande. Eso también funciona, pero a un costo aproximadamente catorce veces mayor que solucionar el problema mediante el grafo. Esta cifra proviene de un experimento en el que los mismos datos se modelaron de tres maneras diferentes, y un único agente en Microsoft Foundry contó con cuatro herramientas de recorrido sin ninguna otra vía para encontrar la respuesta. Lo que se midió fue el costo de la estructura del conocimiento, por pregunta.

Above se muestran tres diseños de una misma base de datos, con un total de 2,435 hechos. Cada panel es un subgrafo real extraído de los datos del experimento, que ilustra cómo cada ontología representa el entorno de esas mismas tres reclamaciones de seguro. En el diseño plano, la estructura está incluida dentro de las propiedades, por lo que apenas hay conexiones entre elementos. El diseño normalizado convierte cada hecho en un vértice independiente: no falta nada, pero tampoco tiene nombre. En el diseño con forma, se asigna un tipo a cada entidad y se nombra cada arista. El agente, el modelo y la base de datos permanecen idénticos en los tres diseños, y solo la forma es lo que varía.

Primero, unas palabras sobre los datos. Todo en ellos es inventado: las personas, las empresas, los lugares y la compañía de seguros provienen de listas de palabras creadas artificialmente con un semilla fija, por lo que nada de ello se refiere a algo real. Las mediciones provienen de pruebas en tiempo real en Sweden Central. El razonamiento se realizó en una implementación dedicada de Microsoft Foundry, los conocimientos se almacenaron en una cuenta de Azure Cosmos DB para Apache Gremlin, y cada llamada a la herramienta era una consulta Gremlin que accedía a un grafo en tiempo real. En total, se obtuvieron 480 episodios de agentes, 4,3 millones de tokens y 8,09 dólares. Una primera pasada por la misma estructura, en la que las herramientas leían los archivos del generador en lugar de la base de datos, costó 7,74 dólares; a esto se le denomina prueba de verificación cruzada. Todas las cifras reportadas provienen de las campañas de Cosmos, y la verificación cruzada solo se realiza cuando dos pruebas juntas muestran algo que una sola prueba no pudo revelar.

La capa que nadie actualiza

Los equipos que lanzan agentes suelen repetir un pequeño ritual. El agente falla en preguntas que debería poder resolver. Alguien sugiere un modelo más complejo. La factura se duplica, los fallos se trasladan a otras preguntas, y el análisis posterior concluye que los agentes aún no están listos.

Casi nadie pone sobre la mesa el material real: la estructura del conocimiento que se le ha dado al agente. Olvídense por un momento de los hechos. Pregúntense si el ajustador es un nodo o una cadena enterrada en un bloque JSON, si el enlace indica assessed_by o simplemente related, y si pasar de una reclamación a un titular de póliza requiere un paso o cinco.

Los trabajos de medición anteriores abarcaron un sistema que toma decisiones y una herramienta que las fija. En otros estudios, una serie pública de tres partes creó una capa de conocimiento persistente, ejecutó agentes sobre ella con datos de seguros sintéticos y defendió la idea de tratar el conocimiento como un artefacto diseñado en lugar de un simple repositorio de información. Lo que faltaba en ese planteamiento era una medición, y este experimento la proporciona. Se añade una capa al sustrato sobre el cual razonan los agentes y se plantea una pregunta para la cual rara vez se obtienen cifras: con el modelo, las herramientas, las instrucciones y los hechos inmutables, y solo cambiando la estructura de la ontología, ¿cómo responden la precisión, el esfuerzo y el costo?

Esa primera respuesta suscita una objeción, por lo que se volvió a ejecutar toda la matriz en un modelo mucho más grande para ver si el dinero puede simplemente superar a un gráfico de forma deficiente. Puede hacerlo. Lo interesante es el precio, así como lo que este revela sobre la forma que merece ser desarrollada. Como antes, toda afirmación necesita una prueba.

Tres formas de una misma verdad

El dominio de prueba es un libro de negocios de seguros que incluye a asegurados, pólizas, coberturas, reclamaciones, ajustadores, proveedores de reparaciones, pagos y regiones. Un script inicial generó todo esto una sola vez, obteniendo 2,435 hechos canónicos distribuidos en 507 entidades, todas ellas ficticias.

Tres ontologías surgen de esa misma base de datos. Llamarlas tres conjuntos de datos sería incorrecto; se trata de tres formas de los mismos datos, bajo una única regla rectora: cada variante debe reexpresar los hechos sin ganancias ni pérdidas. Para hacerla cumplir, un script recorre cada grafo generado, reconstruye los hechos y verifica que el resultado sea idéntico al original. Una variante que conociera un hecho más o menos que otra convertiría la competencia en una prueba de cobertura de datos. El repositorio CI ejecuta esta verificación en cada push al branch principal y en cada pull request, junto con una comprobación de que los datos comprometidos coincidan byte a byte con lo que genera la semilla; el experimento es inválido a menos que ambas pruebas den resultado positivo. Existe una advertencia sobre la equidad: los constructores planos y estructurados se desarrollaron sin hacer referencia al conjunto de datos, lo que hace que sus verificaciones sean sustantivas, mientras que el grafo normalizado se codifica directamente a partir de los datos reales, por lo que, por su propia naturaleza, está más cerca de ellos sin pérdidas que mediante pruebas.

Lo plano es lo que muchos equipos terminan lanzando primero, y utiliza solo dos tipos de nodos complejos. Cada nodo de asegurado almacena sus pólizas y sus coberturas como un bloque JSON en una propiedad. Cada nodo de reclamo incluye a su ajustador, proveedor y pagos de la misma manera. Un único tipo de arista genérico, related, conecta a los asegurados con los reclamos, y eso constituye todo el esquema. Toda la información existe, pero está oculta.

La normalización falla en la dirección opuesta y no constituye un argumento simplificado, ya que un libro de texto la aprobaría. Ella materializa todo. Las entidades se convierten en nodos Resource simples que solo contienen su tipo, cada atributo se vuelve un nodo Attribute al que se accede a través de un enlace genérico has, y cada relación se transforma en un nodo Relation con enlaces subject y object. Sobre el papel parece impecable, pero aprender cualquier cosa requiere cuatro pasos.

Shaped está diseñado pensando en el consumidor que realmente lo utilizará. Los tipos de nodos se definen con una granularidad deliberada, y cada arista tiene una dirección, un tipo y un nombre que tiene un significado concreto, como filed_against, assessed_by o settles. Las políticas apuntan a los titulares de póliza mediante held_by, y se reutiliza el mismo nombre con un propósito adicional: noventa aristas held_by derivadas que van directamente desde una reclamación hasta su titular de póliza, lo que reduce la ruta reclamación-titular de póliza a un solo paso. La reutilización del nombre es intencionada, ya que la relación se interpreta de la misma manera desde ambos extremos y el agente no necesita un vocabulario adicional. Estas noventa aristas llevan la marca derived, no aportan conocimiento alguno y se excluyen de la prueba de ausencia de pérdidas, ya que se basan en cálculos aritméticos sobre datos que ya existen.

La Figura 1 esboza una única relación, una reclamación y su perito evaluador, en las tres formas. En el formato plano, el perito se incluye como una propiedad JSON dentro de la reclamación y apenas hay conexiones adicionales. En el formato normalizado, la relación cuenta con un nodo propio, dos aristas y un nodo de atributos separado para cada hecho. En el formato estructurado, simplemente se nombra la arista y eso es todo; su panel también ilustra por qué existe ese atajo derivado único. Un script de reconstrucción confirma que los tres formatos contienen exactamente los mismos 2,435 hechos.

El recuento de nodos da una idea preliminar del enfoque. Un conjunto de datos corresponde a 130 nodos en el formato plano, 507 en el formato estructurado y 2,942 en el formato normalizado; cada nodo adicional representa un punto al que el agente podría necesitar acceder.

Una entidad concreta muestra la diferencia mejor que una descripción. Tomemos la póliza que hará famosos los resultados: cada variante la almacena de manera distinta:

La Figura 2 obtiene directamente la política P-7009 de los archivos de ontología ya guardados mediante el script de renderizado de figuras, los mismos archivos que se cargaron en Cosmos, por lo que muestra con exactitud por dónde se desplazó el agente. Flat almacena la política como una cadena de texto dentro de una propiedad del titular de la póliza: está allí, pero no es un vértice y no puede ser accedida. Normalized la guarda como un vértice Resource simple cuyos atributos se encuentran en vértices separados a dos pasos de distancia. Shaped contiene un vértice tipado con sus propiedades adjuntas y aristas nombradas que salen de él. La prima es la misma en los tres casos, pero se encuentra a tres distancias diferentes del punto de consulta.

Cada forma se encuentra en su propio contenedor de gráfico dentro de Azure Cosmos DB para Apache Gremlin, y eso es lo que recorre el agente; cada llamada a la herramienta se convierte en recorridos Gremlin en un gráfico en tiempo real. El generador emite la base de hechos, un cargador la escribe en Cosmos, y el sistema de carga se audita a sí mismo: el número de vértices y aristas debe ser igual al del origen; de lo contrario, se informa una discrepancia en lugar de encontrar un gráfico incompleto más tarde.

Un único banco de datos, una capa de herramientas y valores predeterminados idénticos de indexación son lo que hace que los diseños sean comparables, y también los hacen visibles. Un gráfico de propiedades no oculta nada. Pregúntale qué sabe y la respuesta es el propio diseño.

La Tabla 1 cuenta con los mismos 2,435 datos bajo cada esquema, extraídos de los archivos de grafo. El formato plano tiene más vértices que aristas y cinco vértices a los que nada está conectado. El formato normalizado es uniforme y carece de texto. El formato estructurado es el mejor conectado y el único cuyas etiquetas utilizan el vocabulario del dominio.

Volvamos a la columna plana. Las aristas son menos numerosas que los vértices, y cinco nodos no están conectados a nada; se trata de titulares de póliza sin reclamaciones, y bajo este diseño nada más en el sistema los relaciona. Se trata de una base de datos de grafo que almacena algo que apenas puede considerarse un grafo. La estructura sigue existiendo, pero se ha transformado en 8.2 propiedades por vértice, por lo que se comporta como texto y no como topología. Los resultados dependen de esa elección de diseño, y el almacenamiento de grafos lo presenta como un hecho, no como una opinión.

La columna normalizada lo refleja. Este es el más uniforme de los tres gráficos: aproximadamente un arista por vértice, nada aislado, 1.6 propiedades por nodo, ya que la reificación convierte cada hecho en los mismos tres componentes básicos, repetidos 2.942 veces. La estructura abunda y falta vocabulario, con tres etiquetas de vértice y tres etiquetas de arista que abarcan todo un negocio de seguros.

Con 1.36 aristas por vértice, el gráfico con forma es el mejor conectado, con ocho etiquetas de vértice y nueve tipos de aristas. La diferencia se hace evidente de inmediato cuando se pregunta a cada gráfico qué tipos de elementos contiene:

g.V().groupCount().by(label)

• La ficha solo contiene la reclamación (90) y el titular de la póliza (40).
• Los informes normalizados incluyen Recurso (507), Atributo (1834) y Relación (601).
• Las listas estructuradas presentan ocho etiquetas de dominio: 216 cobertura, 90 reclamación, 75 póliza, 59 pago, 40 titular de la póliza, 12 proveedor, 10 ajustador y 5 región.

Una segunda consulta cuenta las pólizas por etiqueta:

g.V().hasLabel('policy').count()

La Tabla 2 muestra una consulta junto a tres respuestas. Ambos ceros representan fallos de tipos diferentes. En el gráfico plano simplemente no existe política que pueda encontrarse. En el gráfico normalizado sí existe una política, pero no se manifiesta por sí sola. El gráfico plano perdió la entidad; el gráfico normalizado conservó la entidad pero perdió el vocabulario, por lo que a una política solo se puede acceder caminando hacia ella, nunca nombrándola. Nada de esto depende de cómo se almacenaron los datos: tres esquemas, una base de datos, una consulta.

El mismo desequilibrio aparece al calcular el precio de una pregunta realista. ¿En qué ciudad vive el titular de la póliza, para la póliza correspondiente a la reclamación C-31020? Cada gráfico responde Larkfield, porque todos contienen los mismos datos. Lo que varía es el camino para llegar allí. En el gráfico estructurado, el arco derivado lo acorta:

# shaped - the derived shortcut collapses the path
g.V().has('number','C-31020').out('held_by').values('city')

Los gráficos planos y normalizados necesitan esto en su lugar:

# flat - one hop, but only because claims and holders are the only two things
g.V().has('number','C-31020').in('related').values('city')# normalized - the same answer, five steps and two unwrappings later
g.V().has('value','C-31020').in('has')
     .in('subject').has('kind','filed_against').out('object')
     .in('subject').has('kind','held_by').out('object')
     .out('has').has('attr','city').values('value')

Flat lo gestiona en un solo paso porque una reclamación y un titular son casualmente los únicos dos tipos de elementos en ese esquema. Normalized requiere cinco pasos y dos procesos de desempaquetado. Un agente nunca compone estas consultas por sí mismo; encuentra el camino llamando a una herramienta a la vez, y ese es el objetivo del experimento. Aun así, las consultas revelan qué se está descubriendo y cuánto hay de ello.

La Figura 3 muestra que la misma consulta se ejecuta en los tres gráficos dentro del Cosmos DB Data Explorer. Independientemente de si un gráfico ofrece dos etiquetas, tres metae etiquetas o el dominio descrito en sus propias palabras, los esquemas no almacenan datos diferentes; albergan un mismo conjunto de datos en formas distintas.

La Figura 4 selecciona la reclamación C-31020 en cada gráfico y permite que el Data Explorer muestre sus vecinos. En el gráfico plano solo se puede acceder a un vértice, un titular de póliza, a través de un arco etiquetado simplemente como related. El ajustador AJ-09 y la póliza PL-043 son visibles en el panel de propiedades, pero como texto, por lo que el agente no puede acceder a ellos. En el gráfico normalizado aparecen ocho vértices, seis atributos y dos relaciones, ninguno de los cuales lleva nombre en el lenguaje del dominio. En el gráfico estructurado sí lo tienen, a saber filed_against, assessed_by y held_by. Una reclamación, una base de datos, tres distancias.

El instrumento: cuatro herramientas y un recibo

El agente se mantiene al mínimo intencionadamente, ya que no es el sujeto de prueba. Se trata de un simple bucle de llamadas a funciones que se ejecuta contra una implementación de modelo de Microsoft Foundry, configurado según la forma en que la documentación de Foundry describe el uso de herramientas a través de la API Chat Completions. Un prompt del sistema fijo, un límite de dieciséis giros del modelo por pregunta (después de lo cual se finaliza la sesión) y cuatro herramientas completan el proceso, con firmas idénticas en las tres ontologías.

La Figura 5 muestra la huella computacional completa: un único recurso de Microsoft Foundry que alberga dos implementaciones de modelo, agent-small que ejecuta gpt-5.4-nano y agent-large que ejecuta gpt-5.5, ambos de tipo Global Standard. Los nombres y versiones provienen del template de infraestructura del repositorio, por lo que no hay flotas ocultas detrás de estas cifras.

Las cuatro herramientas son:

• find_nodes busca las propiedades y IDs de los nodos por subcadena, con un límite de veinte coincidencias
• get_node lee el tipo y las propiedades de un nodo
• traverse devuelve hasta treinta nodos vecinos de un nodo, filtrables por tipo de arista y por dirección
• describe_edges resume qué aristas salen o entran en un nodo y cuántas de cada tipo

Dentro de sus mecanismos, cada herramienta se convierte en Gremlin en Cosmos. get_node y find_nodes requieren una travesía cada una, es decir, una lectura puntual y un escaneo, mientras que traverse y describe_edges necesitan tres, ya que primero verifican que el nodo existe y luego recorren las aristas salientes e entrantes una tras otra. El agente no escribe nada de esto; simplemente solicita un nodo o un vecino y recibe una respuesta en JSON compacta, que corresponde a la forma habitual de las herramientas de producción que interactúan con un almacén de grafos, lo que también mantiene el lenguaje de consultas separado del modelo.

Caminar por el grafo es la única vía para obtener una respuesta. El agente nunca consulta el esquema ni escribe código Gremlin, y cuenta con instrucciones para responder con el texto literal NOT_MODELED cada vez que el grafo carece de lo que requiere una pregunta. Las mayúsculas son importantes: un grafo con estructura deficiente debe pagar el costo de sus llamadas a herramientas adicionales en lugar de generar una única respuesta extensa, tal como ocurre en los presupuestos reales de herramientas. El límite de dieciséis turnos se refiere a los intercambios de conversación y no a las llamadas a herramientas; además, un mismo turno puede incluir solicitudes a varias herramientas al mismo tiempo, por lo que el episodio más intenso logró realizar sesenta llamadas dentro de sus dieciséis turnos.

Tres lecciones prácticas obtenidas al trabajar con una base de datos de grafos real que obligaba a una reconstrucción constante. Cosmos rechaza los scripts con múltiples instrucciones, por lo que cargar datos implica un recorrido por el grafo por cada solicitud, y el rendimiento proviene de ejecutar muchas solicitudes en paralelo en lugar de agruparlas. Un tiempo de espera estricto de sesenta segundos hace que g.V().drop() no pueda eliminar unos pocos miles de vértices: se interrumpe a mitad de proceso y deja un grafo parcialmente eliminado, por lo que la limpieza se realiza en partes. La capa sin servidor también tiene un límite de rendimiento que convierte un aumento repentino de cuarenta escrituras simultáneas en tiempos de espera, razón por la cual tanto el cargador como la herramienta de agente intentan nuevamente con retrasos progresivos. Nada de esto es excepcional, pero marca la diferencia entre un almacén de grafos en estado de reposo y uno bajo carga.

Evaluación sin juez

La evaluación de los agentes tiende a relajarse en la fase de calificación, por lo que este caso recibió la mayor atención, y no aparece ningún juez basado en LLM. Cuarenta preguntas forman cuatro categorías de diez cada una: búsquedas de un solo hecho, recorridos cortos de dos o tres pasos, preguntas que requieren un camino largo o una agregación sobre un subgrafo, y preguntas que no pueden responderse. Un script las genera a partir de la base de hechos y deriva cada respuesta correcta de los hechos brutos. La calificación es mecánica: un número debe ser igual al valor calculado, una cadena debe contenerlo, y una pregunta sin respuesta solo se considera correcta cuando el agente declara abiertamente que no puede responderla. Ninguna ontología se califica a sí misma, ningún modelo juzga a otro modelo, y la corrección proviene de la comparación en lugar de de la opinión.

Dado que el agente solo puede actuar a través de sus cuatro herramientas, cada respuesta incluye la lista completa de llamadas que la generaron. En las mediciones anteriores del enrutador, el campo model servía como comprobante; aquí, ese papel lo desempeña la ruta seguida. Se puede rastrear paso a paso una respuesta correcta, y un fallo muestra con exactitud dónde el agente perdió el control sobre la situación.

La Figura 6 muestra la configuración. Una base de datos con datos iniciales alimenta tres estructuras sin pérdidas de información, las cuales se convierten en tres contenedores de gráficos en Azure Cosmos DB para Apache Gremlin; además, un ramal separado suministra al oráculo que deriva cada respuesta correcta a partir de los mismos datos. El agente accede a los gráficos únicamente mediante las cuatro herramientas, realizando una consulta Gremlin por cada llamada. Las herramientas, los bucles y las preguntas permanecen fijos mientras varían las estructuras, y cada ejecución genera comprobantes que incluyen las llamadas a las herramientas, los tokens utilizados, el tiempo de latencia y el veredicto del oráculo.

El conjunto de preguntas sin respuesta merece un análisis aparte. Sus diez preguntas solicitan información que la base de datos nunca modela: números de teléfono, direcciones de correo electrónico, condiciones climáticas, números de identificación de vehículos. La respuesta adecuada es indicar que el grafo no puede proporcionar esa información. Un agente que inventa una conexión en lugar de admitir que el grafo no cuenta con ellas muestra el fallo más peligroso en esta familia de sistemas, y apenas alguien lo mide.

El costo de la travesía

La campaña principal se ejecutó en los gráficos en tiempo real de Cosmos DB, utilizando un despliegue dedicado de Microsoft Foundry en Sweden Central. Incluyó tres ontologías, cuarenta preguntas y tres pasadas completas con un único modelo pequeño mantenido constante, lo que resultó en 360 episodios de agentes, 3,1 millones de tokens y setenta centavos. Cada llamada a la herramienta correspondía a una consulta Gremlin. Una segunda campaña, descrita más adelante, vuelve a ejecutar la estructura con un modelo más grande, generando otros 120 episodios y un costo de 7,39 dólares. Un script de repositorio calcula todos los valores anteriores a partir de los comprobantes registrados, y ninguno fue ingresado a mano.

La Tabla 3 resume la campaña medida: modelo pequeño, tres pasadas, 360 episodios, y una consulta Gremlin detrás de cada llamada a la herramienta. El color verde marca el mejor resultado en cada fila. Las filas relacionadas con los recursos se dejan sin color intencionadamente, ya que su valor es el más bajo en los cuatro indicadores, y como se muestra en secciones posteriores, parte de ese ahorro sirve para cubrir respuestas que nunca se proporcionaron.

Comience descuentando la primera fila, que contiene el número menos informativo de la tabla. “Shaped” respondió correctamente el 84,2% de las preguntas, “flat” el 78,3% y “normalized” el 59,2%. Sin embargo, en tres pruebas prácticamente idénticas, la precisión de las variantes varió respectivamente en 0,075, 0,150 y 0,075, por lo que la diferencia de seis puntos entre “shaped” y “flat” se encuentra dentro de su propio ruido. Con tres pruebas, nada indica cuál de los dos es más preciso en general. La ventaja de veinticinco puntos sobre “normalized” elimina fácilmente ese ruido.

Eso suena más débil de lo que es. La cifra general es vaga porque promedia rangos que difieren significativamente, y esa discrepancia es precisamente el hallazgo:

La tabla 4 explica el problema del promedio general. Las formas no difieren ligeramente en todas partes; se separan claramente grupo por grupo, y cada grupo requiere algo diferente del gráfico.

Primero, observe las búsquedas basadas en un único dato. Las puntuaciones obtenidas son 0.967 para el método con forma definida y 0.533 para el método plano, lo que representa una diferencia de cuarenta y tres puntos, frente a un ruido de 0.100 en el primer caso y 0.200 en el segundo, lo que confirma que la señal es real. En los casos de recorridos de dos o tres pasos, ambas metodologías alcanzan la puntuación de 0.967. En la banda más difícil, con un ruido de 0.300 y 0.400 respectivamente, no hay forma de determinar un ganador.

Por lo tanto, estas dos formas no son ni mejores ni peores. Se rompen en diferentes puntos, y combinarlas en un único número oculta la información útil. Cuando es necesario encontrar algo, el método plano falla una y otra vez. Cuando el agente ya tiene un punto de apoyo y solo necesita avanzar, el método plano rinde tan bien como el grafo diseñado originalmente.

El método normalizado refleja esta situación, como lo demuestran sus valores: 0.867 en las búsquedas, superando al método plano ya que cada entidad constituye un vértice real; luego 0.467 y 0.133 a medida que los recorridos se alargan. Este método logra encontrar cualquier cosa, pero no termina ninguna tarea.

Cómo falla cada método

Las formas difieren en la forma en que fallan y también en dónde. Cada una abordó treinta preguntas respondibles tres veces, un total de noventa episodios, y agrupar los fallos por tipo de error revela el mecanismo subyacente.

La Tabla 5 agrupa los fallos en esos noventa episodios respondibles. Normalized agota su presupuesto de turnos; Flat se detiene temprano y con confianza ante preguntas que la base de datos podría haber respondido.

Veintidós de los noventa episodios respondibles de Normalized, aproximadamente una cuarta parte, terminaron con el presupuesto agotado y el agente aún en movimiento. Flat rara vez lo hacía; se detenía temprano y con seguridad, rechazando dieciocho preguntas cuyas respuestas estaban en la base de datos. Una forma se agota y la otra se retira.

La falla total es la más grave, y las huellas revelan un mecanismo que nadie esperaba. Aquí hay dos episodios reales. Ambos solicitan la prima de la póliza P-7009, y solo difieren en qué esquema se encuentra detrás de las herramientas:

flat                                       shaped
find_nodes "P-7009"          -> 1 hit:     find_nodes "P-7009" type=policy
   policyholder:PH-05 "Ivo Renner"            -> 1 hit: policy:PL-009 "P-7009"
find_nodes "7009"            -> 1 hit      get_node policy:PL-009
find_nodes "P-7009" type=policy       -> 0     -> premium 750
find_nodes "P-7009" type=policyholder -> 1 hit
ANSWER: NOT_MODELED                        ANSWER: 750

En el gráfico estructurado bastan dos búsquedas. Se solicita la póliza por número, se obtiene un vértice correspondiente, se lee la prima de él y listo.

El gráfico plano cuenta una historia diferente. La primera búsqueda devolvió un vértice, al igual que la segunda. La tercera solicitó type=policy pero no encontró nada, ya que esa etiqueta no existe en este esquema. La cuarta solicitó type=policyholder y obtuvo un resultado. Por lo tanto, por tipo, el agente había encontrado el vértice exacto que contenía la respuesta, y aun así declaró que los datos faltaban.

La póliza premium se encontraba dentro de ese vértice, en una propiedad, a solo una llamada a get_node de distancia. Durante los diez episodios fallidos relacionados con las pólizas premium, la búsqueda sin filtrado mostró el vértice que la contenía quince veces, pero get_node no se ejecutó sobre él ni una sola vez. Ese vértice llevaba la etiqueta “Ivo Renner”, que corresponde a una persona. En los episodios fallidos restantes, la etiqueta pertenecía a uno de los otros dos titulares de póliza, nunca a la póliza en sí, y el nombre de una persona no ofrece ninguna pista de que la póliza solicitada se encuentre allí dentro.

Ese es el peligro específico de ocultar una entidad, y una base de datos gráfica permite localizarla. Los datos son accesibles pero irreconocibles. Están indexados, se devuelven mediante la consulta y forman parte del contexto del agente, sin embargo no corresponden a ningún nombre utilizado en la consulta.

La normalización falla abiertamente y de forma costosa. Leer un atributo implica recorrer un nodo Attribute, y seguir una relación implica tomar un desvío a través de un nodo Relation. La columna de tokens muestra el costo: 13,701 por pregunta frente a 7,176 para los formatos estructurados, y 12.15 llamadas a herramientas frente a 7.24. Veinticinco de sus 120 episodios alcanzaron el límite de dieciséis giros, frente a tres para los formatos estructurados y dos para los planos; además, el grupo más difícil obtuvo una puntuación de 0.133. El grafo no carecía de nada. El agente simplemente se quedó sin aliento antes de terminar la oración.

La opción más económica es realmente la más barata, aunque eso no es un cumplido. La opción plana cuesta $0.109 por cien preguntas, frente a $0.165 para la opción con formato específico; además, al calcularla según la precisión, sigue siendo la más económica, con $0.14 por cien respuestas correctas, contra $0.20. Según este modelo, la opción plana es realmente más económica de utilizar. Lo que ningún precio puede comprar son las dieciocho respuestas que rechazó. Salir rápidamente no cuesta mucho, y una cuenta baja no representa un ahorro, algo que una columna de costos por sí sola nunca revela.

El paradoja del rechazo

Lo mejor y lo peor intercambian lugares en la categoría de preguntas sin respuesta una vez que se analizan las preguntas respondibles. La opción plana rechazó correctamente las treinta preguntas sin respuesta, logrando la única puntuación perfecta en la tabla. La opción con formato específico obtuvo una puntuación de 0.933 y una normalizada de 0.900; sus errores se debieron a que se agotaron las turnos, no a invenciones.

Si se analiza por separado, esa fila muestra un resultado plano. Al lado de la cuenta de rechazos falsos, el orden se invierte: la forma con la puntuación de rechazo perfecta omitió dieciocho preguntas a las que podría haber respondido, mientras que la forma con la peor puntuación de rechazo omitió trece. El resultado plano no es mejor para detectar la ausencia de respuestas; tiende a indicarla, y esa tendencia que funciona en preguntas sin respuesta falla en las que sí se pueden responder. Una métrica de rechazo sin una métrica de contestabilidad al lado invita a crear el gráfico más poco útil posible.

Un hallazgo en contra del diseño

Un resultado va en contra del diseño estructurado que favorece el experimento, y la segunda campaña lo acentuó aún más. En el diseño estructurado solo existe un atajo derivado: held_by, que vincula directamente una reclamación con su titular. En la pregunta sobre la relación entre reclamación, titular y ciudad, obtuvo una puntuación de 0.83, mientras que el método normalizado alcanzó 0.33; en cambio, el método plano logró 0.92 sin ningún atajo, ya que en ese esquema solo existen una reclamación y un titular. Un resultado en el que el diseño sin bordes supera al diseño con bordes no puede atribuirse a estos últimos.

Peor aún, la falta de atajos tuvo consecuencias donde se esperaba. Al contar los distintos tipos de cobertura en las pólizas de un titular, se obtuvo un valor de 0.17 en el gráfico supuestamente bien diseñado y de 0.67 en el plano, lo que los mantiene en una sola propiedad legible. La suma de los pagos relacionados con las reclamaciones de un titular fue de 0.33. Para la agregación en un subgráfico, el diseño defendido pierde frente al diseño denominado “roto”. La denormalización no es un compromiso frente a un buen diseño, sino parte de él; además, el gráfico estructurado aplicó sus propios principios de forma insuficiente justo donde el trabajo requería más de ellos.

Salir del apuro con un modelo más grande

La red completa se ejecutó una segunda vez en un modelo mucho más grande, y la respuesta a la pregunta principal surgió de su comportamiento inesperado. Inicialmente, se suponía que el modelo pequeño en un grafo bien estructurado superaría al modelo grande en uno mal estructurado. Pero no fue así. Solo las preguntas respondibles entran en esta comparación, por lo que los rechazos de las que no se pueden responder no pueden mejorar la apariencia de ninguna estructura. Cada fila correspondiente al modelo pequeño tiene noventa episodios distribuidos en tres pasadas, mientras que cada fila correspondiente al modelo grande tiene treinta episodios provenientes de una sola pasada.

La Tabla 6 se limita a las preguntas respondibles, por lo que los rechazos correctos no pueden hacer que una estructura propensa a rechazar parezca mejor.

El modelo grande lee las propiedades ocultas sin problemas. Respondió a las treinta preguntas del grafo plano, incluidas aquellas sobre entidades que el esquema había convertido en texto, y desaparecieron las dieciocho negativas falsas que dificultaban al modelo pequeño. El titular honesto no es el que todos querían.

Una ontología de forma deficiente puede compensarse económicamente. La tasa es de aproximadamente catorce veces el costo por pregunta: el modelo grande en el grafo plano cuesta 1,90 dólares por cien preguntas, mientras que el modelo pequeño en el grafo estructurado cuesta trece centavos. Mantén el grafo plano, actualiza solo el modelo que está bajo él, y la factura será veinte veces mayor que el costo del mismo modelo pequeño en ese mismo entorno.

Ese resultado es más útil que el predicho por lo que implica. Con un modelo de frontera y preguntas respondibles, la forma dejó de ser un problema de corrección y se convirtió en un problema de costo: tanto el modelo plano como el modelado respondieron a las treinta preguntas, y solo la facturación los separó. Con un modelo pequeño, la forma era la corrección misma. Por lo tanto, una ontología bien diseñada aporta menos calidad que la capacidad de ejecutar un modelo económico. Un grafo plano vincula la capa de conocimiento con el presupuesto del modelo, funcionando solo mientras continúe el pago por un modelo lo suficientemente grande como para procesarlo en cada pregunta, de forma indefinida.

En las cuatro categorías, el orden es más ordenado de lo que sugiere la visión basada únicamente en preguntas respondibles. Con el modelo grande, el enfoque modelado alcanzó un 1.000 perfecto en todas las categorías, incluida la de preguntas no respondibles. El modelo plano llegó al 0.950 y su valor normalizado fue de 0.825. El dinero solo corrige la corrección en gran medida, y la facturación permanece sin cambios.

Qué enseñó la verificación cruzada sobre la prudencia

La ejecución de la verificación cruzada (misma cuadrícula, mismas preguntas, herramientas que leían archivos en lugar de Cosmos) arrojó el resultado más alarmante del proyecto, y provino del gráfico estructurado. Al preguntársele cuál era el clima el día de un incidente, algo que la ontología deliberadamente no modela, el agente respondió “daños por granizo”. Había encontrado la propiedad cause de la reclamación y la presentó como clima. En ese momento se registró esto como el diseño preferido que causaba el fallo más peligroso, con la advertencia de que se trataba de un episodio de una sola ejecución, una observación y no una medición, sin base para una ley.

Ejecutarlo nuevamente en infraestructura real fue la decisión correcta. En la campaña medida, el gráfico con forma correspondiente rechazó correctamente las diez preguntas imposibles de responder con el modelo grande, mientras que la confabulación apareció en el gráfico plano, que respondió “granizo” a la misma pregunta. El modelo, la pregunta y la trampa eran idénticos; solo la forma que caía en la trampa era diferente.

Por lo tanto, la conclusión no es que los gráficos complejos incentiven la confabulación. Una propiedad causa con el valor “daños por granizo” tentará a cualquier modelo al que se le haga una pregunta sobre el clima, independientemente de dónde esté almacenado, y la forma que cae en la trampa varía entre ejecuciones. Esa es una afirmación más limitada que la que casi se hizo, y es lo que respaldan las pruebas. También significa que el riesgo no depende de la forma: si un gráfico contiene un campo que parece ser la respuesta a algo que en realidad no responde, algún modelo en algún lugar lo entregará.

La forma normalizada en ambos modelos

La pérdida normalizada disminuyó en general en ambos modelos. Con el modelo pequeño ocupó el último lugar, y con el modelo grande siguió quedando atrás con un valor de 0.867 en las preguntas respondibles, mientras costaba 9.31 dólares por cien preguntas, casi cinco veces más que el gráfico plano del mismo modelo, y se quedó sin turnos siete veces. La reificación no mejora con un modelo más grande, ya que su problema nunca fue la comprensión, sino la distancia: quince llamadas a herramientas por pregunta frente a 8.3 en el modelo con forma normalizada, un modelo que nunca interpretó nada incorrectamente.

La forma normalizada no perdió en todos los casos, y esa excepción es la que más enseña. En búsquedas basadas en un único dato, la forma normalizada obtuvo una puntuación de 0.867 frente a 0.533 de la forma plana; en las dos preguntas que superaron a la forma plana, resultó claramente superior: 0.83 frente a 0.17 para la prima de póliza y 0.83 frente a 0.33 para la especialidad del proveedor. La reificación es extremadamente costosa pero no oculta nada. Cada entidad es un vértice, por lo que todas pueden ser encontradas.

Eso resume el argumento: cada forma defectuosa conservó la mitad del problema y descartó la otra. La forma plana mantuvo la distancia pero perdió la capacidad de localización. La forma normalizada mantuvo la capacidad de localización pero perdió la distancia. Cada una compite en la mitad que conservó y es inútil en la otra.

Shaped no representa un compromiso entre los dos enfoques. Obtiene una puntuación de 0.967 en la escala de valores superiores a plano y 0.967 en la escala de valores normalizados, por lo que rechaza ese equilibrio. Allí radica su ventaja, y un único número de precisión combinada la oculta por completo.

Latencia frente a una base de datos real

La latencia es una medida que la verificación cruzada no pudo evaluar. Con los archivos, los tiempos por llamada variaban enormemente entre ejecuciones idénticas: la misma variante podía tardar 1.17 segundos por llamada en una ejecución y 4.21 segundos en otra, por lo que no se informó nada, ya que la variabilidad del servicio superaba a la de la ontología. Con Cosmos, la situación es más ordenada, por una razón ligeramente relacionada con la deflación de datos.

La Tabla 7 muestra el tiempo por pregunta, que se distingue claramente entre los diferentes formatos y permanece constante dentro de cada uno de ellos; sin embargo, el tiempo por llamada a la herramienta es idéntico en los tres casos, lo que hace que la tabla represente el número de llamadas a la herramienta expresado en segundos.

Dentro de cualquier variante, la mayor diferencia de tiempo es de siete segundos, frente a una brecha de casi cincuenta segundos entre el formato plano y el normalizado. Una pregunta en formato normalizado tarda dos veces y media más que una en formato plano. La última columna reduce el valor obtenido: por llamada, las tres formas tardan aproximadamente lo mismo, entre 6.2 y 7.4 segundos, independientemente del esquema. Por lo tanto, esto no constituye un hallazgo independiente. La base de datos aporta consistencia, ya que un viaje de ida y vuelta en Cosmos es predecible, a diferencia de lo que ocurría con un diccionario local, y eso es lo que permite reportar esos números.

De esto se deriva una consecuencia práctica. Dado que la latencia por llamada es más o menos constante, los conjuntos de formas ontológicas determinan el tiempo de respuesta de manera similar a como determinan el costo en tokens, y se puede estimar este valor antes de la construcción contando los saltos necesarios.

Principios, cada uno con su justificación

Al escribir sobre el diseño de ontologías, generalmente se presentan principios como cuestiones de gusto. La mayoría de los que se mencionan a continuación van acompañados del número que les asignó, y aquellos que no lo tienen lo indican claramente.

Cualquier cosa sobre la que se pueda hacer una pregunta debe ser un vértice. Si hay un principio que debe grabarse encima de la puerta, que sea este. El gráfico plano almacena cada prima de póliza y especialidad del proveedor, indexadas, en la misma base de datos que todo lo demás, y el modelo simplificado apenas logró recuperarlas. Las primas se encontraron en el 17% de los casos y las especialidades en el 33%, mientras que los casos gestionados de forma estructurada arrojaron un 100% y un 83%. Todo el rango coincide, entre 0.533 y 0.967. Ocultar una entidad dentro de la propiedad de otra entidad no la hace más difícil de encontrar; simplemente hace que una pregunta legítima sobre ella aparezca bajo otro nombre, lo cual el agente interpreta como evidencia de que dicha entidad está ausente. La intersección añade una condición, ya que el modelo de frontera las recuperó todas. Enterrarla no constituye una barrera absoluta, sino más bien un costo a pagar según el nivel del modelo.

La granularidad es un presupuesto, y su uso excesivo lo agota rápidamente. Cada nodo añadido por razones de pureza del esquema genera costos en cada consulta. En comparación con el formato estructurado, el formato normalizado requirió 3.7 veces más llamadas a la herramienta para búsquedas de un solo dato, 2.3 veces más para recorridos cortos y cuatro veces más tokens en recorridos largos; además, alcanzó el límite de giros en veinticinco de los 120 episodios, frente a tres en el formato estructurado. Un modelo cuyo precio era veinticinco veces mayor por token de entrada mejoró sus resultados en preguntas respondibles de 0.489 a 0.867. Se trata de una mejora real, pero se logró a un costo de 9.31 dólares por cien consultas, casi cinco veces más que el precio del mismo modelo en el formato estructurado. La distancia nunca es económica, sea cual sea el presupuesto.

Los puntos de entrada son la arquitectura, y dependen en gran medida del modelo. Cada pregunta comienza con algún nombre o número, y lo que devuelve la primera llamada a la herramienta determina si el agente procede a trabajar o comienza a adivinar. En el modelo pequeño, esa llamada devolvió resultados vacíos en el 10% de los episodios con estructura definida, el 26% de los sin estructura y el 53% de los normalizados, en los casos en que la búsqueda se dirigía a un vértice Attribute y no a la entidad. En el modelo de vanguardia, nunca devolvió resultados vacíos, independientemente de la estructura. Por lo tanto, un movimiento inicial desperdiciado no es solo una propiedad del grafo; es lo que ocurre cuando un modelo más débil se enfrenta a un punto de entrada que no esperaba. Construya las puertas para el modelo que se ejecutará en producción, no para el que se usa en pruebas.

Denormalice deliberadamente y admítalo cuando el comprobante no coincida. Un atajo derivado, held_by, se utilizó con la expectativa de funcionar en el camino de reclamo al titular. Obtuvo un puntaje de 0.83 en ese caso frente a 0.33 en la versión normalizada, pero con el enfoque plano obtuvo 0.92 en la misma pregunta sin atajo, por lo que no se puede otorgar crédito, y no se ejecutó la prueba limpia (con bordes versus sin ellos). El atajo que faltaba enseña más. Al contar los tipos de cobertura a lo largo de las pólizas de los titulares, se obtuvo un puntaje de 0.17 en el grafo bien diseñado y 0.67 en el plano, lo que los mantiene en una única propiedad legible. Para la agregación a lo largo de un subgrafo, el diseño propuesto perdió frente al etiquetado como defectuoso. Elegir atajos es parte del diseño; la carga de trabajo muestra cuáles son necesarios, y en este caso se eligió el incorrecto, como lo indicaron los datos.

Se limitó la propagación. El hecho de que la búsqueda tuviera un límite de veinte resultados y el recorrido de treinta significó que un nodo sobreconectado generaba costos visibles y cuantificables en llamadas adicionales, en lugar de una única respuesta enorme. No se ejecutó ninguna operación sin límites, por lo que los ahorros son desconocidos. Lo que sí se sabe es que, sin esos límites, el costo se oculta en el tamaño de la respuesta, donde no existe una métrica de conteo de llamadas.

Haga que la ausencia sea visible y cántela con honestidad. Trate la banda de preguntas imposibles de responder como un requisito de diseño y no como un truco en la prueba, pero léala junto a la banda de preguntas respondibles. Flat obtuvo una puntuación perfecta de 1.000 en las respuestas negativas, al rechazar dieciocho preguntas que podría haber respondido. Shaped rechazó las menos, y sus dos episodios imposibles de responder terminaron con que renunciara en lugar de inventar algo. Una buena ontología permite que la afirmación “no modelamos esto” sea tanto alcanzable como verdadera, y una evaluación necesita ambas partes para diferenciar un grafo consciente de sus limitaciones de uno que no puede localizar sus propios contenidos.

Los nombres son la API. El agente lee los nombres de los bordes de la misma manera que un desarrollador lee la firma de una función, y en este experimento se combinan deliberadamente el nombre y la estructura en una sola variable llamada diseño. Ningún número respalda por sí solo este principio. Separarlos es la siguiente abstracción obvia, y decirlo es mejor que afirmar algo más allá de lo medido.

Qué no es esto

Esto no es una prueba de rendimiento para bases de datos gráficas. Las tres formas comparten una misma cuenta de Cosmos DB, una misma capa de herramientas y los mismos valores predeterminados de indexación, por lo que el almacén es una constante y no una variable; además, nada compara a Cosmos con otras bases de datos gráficas ni lo ajusta. Tampoco afirma que la travesía por sí sola sea la forma en que los agentes de producción deben recuperar toda la información, ya que las consultas vagas sin un punto de entrada claro requieren búsquedas; los resultados muestran dónde la travesía simple tiene sentido y dónde no. No presenta argumentos en contra de la normalización en sistemas transaccionales, porque la forma normalizada es inadecuada aquí para este tipo de usuario, un agente que paga por cada paso, y no necesariamente incorrecta en general. Tampoco se trata de una comparación entre proveedores: Microsoft Foundry es la constante, no la variable, y este método podría aplicarse a cualquier plataforma que permita la llamada a funciones.

¿Cambiaría un banco de datos en el ciclo el resultado? Eso requiere una respuesta, no una garantía. Antes de las campañas medidas, se implementaron dos veces las mismas cuatro herramientas, tanto sobre Cosmos como sobre los archivos que emite el generador, y se reproducieron las llamadas a las herramientas registradas en ambos entornos: 3,056 llamadas distintas, correspondientes a cada combinación única de herramienta y argumento que generaron las campañas. Ambas implementaciones dieron respuestas idénticas en todos los casos. El banco de datos sigue teniendo un papel importante: añade latencia y unidades de solicitud, y Cosmos requiere aproximadamente un 4% más de pasos del agente que las versiones basadas en archivos, siendo casi todo ese incremento debido al grafo normalizado. Pero las respuestas que recibió el agente provinieron de la estructura ontológica y no del motor subyacente, y eso es todo lo que se necesita para la comparación. La reproducción se encuentra en el repositorio como un script.

Límites del instrumento

Varias reservas provienen del trabajo con los routers. Cuarenta preguntas sintéticas en un único dominio sintético constituyen un instrumento de escaso alcance. Los contrastes son marcados ya que las formas son arquetipos, y existe una ontología de producción intermedia, por lo que lo que se midió fueron los puntos finales. La campaña con el modelo pequeño se realizó en tres pasadas completas y su nivel de ruido se menciona constantemente. La rejilla con el modelo grande se ejecutó solo una vez, por lo que solo sus resultados saturados, treinta aciertos de treinta en dos formas, son fáciles de considerar fiables. Un espacio de dos preguntas dentro de esa rejilla se considera un caso aislado, y nada aquí se deduce a partir de él. También se compararon solo un modelo pequeño y uno grande, por lo que la curva entre ellos permanece sin medir.

La auditoría del código antes del lanzamiento reveló dos defectos en el instrumento. Primero: cuando el tipo de arista solicitado no está presente en el grafo, traverse devuelve una lista de vecinos vacía, lo cual es indistinguible de un nodo que realmente no tiene vecinos. El agente realizó 112 llamadas de este tipo en todas las campañas, y nueve de las veintidós negativas falsas en el grafo normalizado contienen una de ellas; la secuencia de análisis cuenta ambas. La diferencia principal persiste, ya que shaped realizó la mayor cantidad de tales llamadas pero rechazó la menor cantidad de consultas. No obstante, que una herramienta responda “no hay nada aquí” por “no existe dicho tipo de arista” constituye una confusión, y la alternativa honesta sería un error al nombrar los tipos disponibles. Segundo: la prueba de ausencia de pérdidas compara hechos reconstruidos, por lo que no puede detectar aristas que no contengan ningún hecho en sí mismas, es decir, las aristas de conexión en flat y los atajos derivados en shaped. Un segundo control verifica ahora esas aristas en relación con los hechos que reafirman, y detecta eliminaciones y direcciones incorrectas en cada una de ellas. Las campañas preceden a ese control, por lo que no existía garantía cuando se ejecutaron.

La estructura es el prompt del sistema

Se invierte mucho esfuerzo en las palabras que se colocan antes de un modelo, pero casi ninguno en la estructura del conocimiento que lo sustenta. Para un agente que utiliza herramientas, la ontología funciona como un prompt: indica los movimientos que el mundo permite, expresados en tipos de nodos y nombres de aristas, y se lee una llamada a herramienta a la vez. Hay que diseñarla para el lector que realmente existe.

El material de apoyo se encuentra en el repositorio de código del experimento: base de datos de hechos, tres ontologías, prueba de ausencia de pérdidas, preguntas, oráculo, agente y cada comprobante de campaña. Cualquiera que modele la misma verdad de una cuarta manera y supere a estas estructuras en las preguntas que las derrotaron aportaría algo real a la comparación.

Para obtener información de contexto sobre las piezas utilizadas, la documentación de referencia relevante abarca Azure Cosmos DB para Apache Gremlin, la llamada a funciones con modelos de Microsoft Foundry y la API REST de precios minoristas de Azure, la cual proporcionó los precios por token que sustentan las cifras de costo.