Cómo Evaluar la Recuperación de Grafos en Sistemas Agénticos MCP

Cómo Evaluar la Recuperación de Grafos en Sistemas Agénticos MCP

El auge de los agentes de IA ha generado un interés significativo en extender las capacidades de los Modelos de Lenguaje Extensos (LLMs) más allá de la simple búsqueda de vectores, proporcionándoles acceso a diversas herramientas como la búsqueda web, APIs y bases de datos. Sin embargo, este crecimiento ha superado el desarrollo de métodos de evaluación rigurosos para estos sistemas.

Aunque es relativamente sencillo integrar un LLM con diversas herramientas, resulta crucial comprender cómo se comportará realmente el sistema en un entorno operativo. Por ello, es fundamental establecer un marco sólido para evaluar los servidores MCP (Model Context Protocol), tanto los disponibles en el mercado como los personalizados, especialmente aquellos que recuperan información de Neo4j.

Model Context Protocol (MCP)

El Model Context Protocol (MCP), desarrollado por Anthropic, es un estándar abierto que facilita la conexión de sistemas de IA a fuentes de datos externas. Funciona como un "puerto USB-C para aplicaciones de IA", estandarizando la forma en que los sistemas de IA acceden a datos a través de servidores ligeros que exponen capacidades específicas a los clientes. La reutilización es un aspecto clave: en lugar de crear integraciones personalizadas para cada fuente de datos, los desarrolladores construyen servidores MCP reutilizables que pueden compartirse entre múltiples aplicaciones de IA.

Un servidor MCP implementa el protocolo, exponiendo herramientas y datos a un cliente de IA a través de llamadas estructuradas JSON-RPC. Gestiona las solicitudes del cliente, las ejecuta contra APIs locales o remotas, y devuelve los resultados para enriquecer el contexto de la IA.

Creación de un Conjunto de Datos de Evaluación

Para evaluar los servidores MCP y sus métodos de recuperación, el primer paso es generar un conjunto de datos de evaluación. Para ello, se utiliza un LLM. El siguiente paso es probar un servidor mcp-neo4j-cypher con el conjunto de datos creado. El objetivo es establecer un conjunto de datos y un marco de trabajo sólidos para comparar de manera consistente diferentes recuperadores.

El código está disponible en GitHub.

Deficiencias en los Métodos de Evaluación Tradicionales

El dataset Text2Cypher (2024) de Neo4j fue diseñado en torno a un enfoque de un solo paso para la generación de Cypher. En este enfoque, el sistema recibe una pregunta en lenguaje natural y debe producir una consulta Cypher completa que responda directamente a esa pregunta.

Sin embargo, este enfoque no refleja cómo los agentes interactúan realmente con las bases de datos de grafos en la práctica. Los agentes operan a través de un razonamiento de múltiples pasos: pueden ejecutar múltiples herramientas iterativamente, generar varias sentencias Cypher en secuencia, analizar resultados intermedios y combinar hallazgos de diferentes consultas para construir una respuesta final. Este enfoque iterativo y exploratorio representa un paradigma fundamentalmente diferente del modelo prescrito de un solo paso.

El benchmark actual no captura esta diferencia en cómo los servidores MCP se utilizan realmente en flujos de trabajo agenticos. Por lo tanto, es importante actualizar el benchmark para evaluar las capacidades de razonamiento de múltiples pasos en lugar de solo la traducción de texto a Cypher de un solo paso.

Métricas de Evaluación Adaptadas al Razonamiento Multi-Paso

La principal diferencia al pasar de la evaluación de Text2Cypher de un solo paso a un enfoque agentico radica en cómo se mide la precisión. En las tareas tradicionales de Text2Query, la evaluación implica comparar la respuesta de la base de datos directamente con una respuesta predefinida, a menudo verificando coincidencias exactas o equivalencia.

Sin embargo, los enfoques agenticos introducen un cambio clave: el agente puede realizar múltiples pasos de recuperación, elegir diferentes rutas de consulta o incluso reformular la intención original en el camino. Como resultado, puede que no haya una única consulta correcta. En cambio, se centra la atención en evaluar la respuesta final generada por el agente, independientemente de las consultas intermedias que haya utilizado para llegar allí.

Para evaluar esto, se utiliza una configuración de LLM como juez, comparando la respuesta final del agente con la respuesta esperada. Esto permite evaluar la calidad semántica y la utilidad de la salida en lugar de la mecánica interna o los resultados de la consulta específica.

Introduciendo Ruido del Mundo Real

Para alinear aún más el benchmark con el uso agentico en el mundo real, también se introduce ruido controlado en los prompts de evaluación. Esto incluye elementos como:

• Errores tipográficos en entidades nombradas (por ejemplo, "Andrwe Carnegie" en lugar de "Andrew Carnegie").
• Frases coloquiales o lenguaje informal (por ejemplo, "muéstrame qué pasa con la junta de Tesla" en lugar de "lista los miembros de la junta directiva de Tesla").
• Intenciones demasiado amplias o poco especificadas que requieren razonamiento o aclaración de seguimiento.

Estas variaciones reflejan cómo los usuarios interactúan realmente con los agentes en la práctica. En las implementaciones reales, los agentes deben manejar entradas desordenadas, formulaciones incompletas y abreviaturas conversacionales, que son condiciones raramente capturadas por benchmarks limpios y canónicos.

Para reflejar mejor estas ideas sobre la evaluación de enfoques agenticos, se ha creado un nuevo benchmark utilizando Claude 4.0. A diferencia de los benchmarks tradicionales que se centran en la corrección de la consulta Cypher, este está diseñado para evaluar la calidad de las respuestas finales producidas por agentes de múltiples pasos.

Para explicar la contaminación de datos, imaginemos un estudiante que, antes de un examen importante, logra obtener acceso a una copia de las preguntas. Este acceso anticipado le da una ventaja injusta y distorsiona la verdadera medida de su conocimiento y habilidades. De manera similar, en los benchmarks de IA, la contaminación de datos ocurre cuando el modelo de IA ha sido entrenado o expuesto a los mismos datos que se utilizan para evaluarlo. Esto puede suceder de manera inadvertida, por ejemplo, si los datos de entrenamiento incluyen información muy similar a las preguntas de evaluación. Como resultado, el modelo puede dar respuestas correctas no porque realmente "entienda" o "razone" sobre la información, sino porque simplemente está recordando patrones que ya ha visto. Esto invalida la evaluación, ya que no refleja la capacidad del modelo para generalizar a datos nuevos o desconocidos.

Variedad de Bases de Datos

Para garantizar una variedad de evaluaciones, se utilizan un par de bases de datos diferentes que están disponibles en el servidor de demostración de Neo4j. Los ejemplos incluyen:

• Northwind: Con licencia bajo Microsoft Public License
• Network management: Generado por Michael Hunger
• Clinical Knowledge Graph: Con licencia bajo MIT

Servidor MCP-NEO4J-CYPHER

mcp-neo4j-cypher es una interfaz de herramienta MCP lista para usar que permite a los agentes interactuar con Neo4j a través del lenguaje natural. Admite tres funciones principales: ver el esquema del grafo, ejecutar consultas Cypher para leer datos y ejecutar operaciones de escritura para actualizar la base de datos. Los resultados se devuelven en un formato limpio y estructurado que los agentes pueden entender y utilizar fácilmente.

Funciona de forma predeterminada con cualquier framework que admita servidores MCP, lo que facilita su conexión a configuraciones de agentes existentes sin trabajo de integración adicional. Ya sea que esté construyendo un chatbot, un asistente de datos o un flujo de trabajo personalizado, esta herramienta permite a su agente trabajar de forma segura e inteligente con los datos del grafo.

Evaluación del Benchmark

El benchmark se ejecuta utilizando LangChain para alojar el agente y conectarlo al servidor mcp-neo4j-cypher, que es la única herramienta proporcionada al agente. Esta configuración hace que la evaluación sea simple y realista: el agente debe depender completamente de la interacción en lenguaje natural con la interfaz MCP para recuperar y manipular los datos del grafo.

Para la evaluación, se utilizó Claude 3.7 Sonnet como agente y GPT-4o Mini como juez.

El conjunto de datos de benchmark incluye aproximadamente 200 pares de pregunta-respuesta en lenguaje natural, categorizados por número de saltos (1-salto, 2-saltos, etc.) y si las consultas contienen información distractora o ruidosa. Esta estructura ayuda a evaluar la precisión del razonamiento del agente y la robustez tanto en contextos limpios como ruidosos. El código de evaluación está disponible en GitHub.

Resultados de la Evaluación

La evaluación muestra que un agente que utiliza solo la interfaz mcp-neo4j-cypher puede responder eficazmente a preguntas complejas en lenguaje natural sobre datos del grafo. En un benchmark de alrededor de 200 preguntas, el agente logró una puntuación promedio de 0,71, con un rendimiento que disminuye a medida que aumenta la complejidad de la pregunta. La presencia de ruido en la entrada redujo significativamente la precisión, revelando la sensibilidad del agente a los errores tipográficos en las entidades nombradas y similares.

En el lado del uso de la herramienta, el agente promedió 3,6 llamadas a herramientas por pregunta. Esto es coherente con el requisito actual de hacer al menos una llamada para obtener el esquema y otra para ejecutar la consulta Cypher principal. La mayoría de las consultas se situaron dentro de un rango de 2 a 4 llamadas, lo que demuestra la capacidad del agente para razonar y actuar de forma eficiente. En particular, un pequeño número de preguntas se respondieron con solo una o incluso cero llamadas a herramientas, anomalías que pueden sugerir una detención temprana, una planificación incorrecta o errores del agente, y que merecen un análisis más profundo. De cara al futuro, el recuento de herramientas podría reducirse aún más si el acceso al esquema se incorpora directamente a través de los recursos MCP, eliminando la necesidad de un paso explícito de obtención del esquema.

El verdadero valor de tener un benchmark es que abre la puerta a la iteración sistemática. Una vez que se establece el rendimiento de referencia, puede comenzar a ajustar los parámetros, observar su impacto y realizar mejoras específicas. Por ejemplo, si la ejecución del agente es costosa, es posible que desee probar si limitar el número de pasos permitidos a 10 mediante un límite de recursión de LangGraph tiene un efecto medible en la precisión. Con el benchmark en su lugar, estas compensaciones entre rendimiento y eficiencia se pueden explorar cuantitativamente en lugar de adivinar.

Para ilustrar los tres niveles de evaluación, pensemos en probar un coche de carreras:

• Nivel 1: Se trata de comparar diferentes pilotos (en este caso, diferentes frameworks de IA) utilizando exactamente el mismo coche (la misma configuración y datos). Aquí, estamos midiendo la habilidad del piloto para aprovechar al máximo el coche.
• Nivel 2: Imaginemos que ahora solo cambiamos los neumáticos del coche (las herramientas que usa el framework, como diferentes bibliotecas o APIs). El resto del coche (los datos y la configuración general) sigue siendo el mismo. En este nivel, estamos evaluando cómo un cambio específico en una herramienta afecta el rendimiento del framework.
• Nivel 3: Finalmente, probamos diferentes motores (diferentes modelos de IA) en el mismo chasis y con el mismo piloto. Esto nos permite ver cómo el motor en sí afecta el rendimiento general, manteniendo constantes otros factores.

De manera similar, FutureBench permite a los investigadores aislar y evaluar el impacto de diferentes componentes en un sistema de IA, desde el framework general hasta herramientas específicas y modelos de IA subyacentes.

Impacto de la Limitación de Pasos

Con un límite de 10 pasos, el rendimiento disminuyó notablemente. La puntuación media de la evaluación se redujo a 0,535. La precisión disminuyó bruscamente en las preguntas más complejas (3 saltos o más), lo que sugiere que el límite de pasos cortó las cadenas de razonamiento más profundas. El ruido siguió degradando el rendimiento, y las preguntas ruidosas promediaron puntuaciones más bajas que las limpias.

Conclusión

La evaluación rigurosa es esencial para el avance de los sistemas de IA, especialmente en el contexto de los agentes autónomos y los estándares emergentes como MCP. El proyecto GRAPE busca construir un benchmark práctico y en evolución para el question answering basado en grafos utilizando la interfaz MCP.

El objetivo es refinar el conjunto de datos, experimentar con diferentes estrategias de recuperación y explorar cómo extender o adaptar el MCP Cypher para una mejor precisión. Aunque queda mucho trabajo por hacer, tener un benchmark claro permite realizar un seguimiento significativo del progreso, probar ideas sistemáticamente y superar los límites de lo que estos agentes pueden hacer de manera confiable.

Referencias

• How to Evaluate Graph Retrieval in MCP Agentic Systems: https://towardsdatascience.com/evaluating-graph-retrieval-in-mcp-agentic-systems/