Microsoft GraphRAG y Ollama: cómo se comportó el RAG con grafos en modelos locales

Ha aparecido un análisis detallado de Microsoft GraphRAG junto con Ollama y LLM locales. El autor comprobó si es posible montar un RAG con grafos sin infraestructura cara, y probó el sistema con el relato "Johnny Mnemonic", de William Gibson, para evaluar la calidad de las respuestas sobre un material ciberpunk conocido.

Cómo se montó la prueba

El experimento giró en torno a una pregunta práctica: ¿puede el enfoque con grafos sustituir de verdad a la búsqueda vectorial habitual en los sistemas RAG corporativos? El autor eligió Microsoft GraphRAG, ejecución local mediante Ollama y un texto de unas 38 mil palabras. El resultado no fue solo un índice de búsqueda, sino un grafo de conocimiento completo con entidades, relaciones y comunidades.

La visualización con Gephi mostró que el sistema puede construir una estructura bastante rica a partir de un único texto de ficción. Es relevante que GraphRAG no solo forma vínculos literales entre objetos, sino también clústeres temáticos. En los informes de comunidad, los grupos se organizaron en torno a la Yakuza, Johnny, Molly Millions y otros elementos clave de la trama.

También aparecieron limitaciones típicas: las entidades no siempre se fusionan si los nombres difieren en su forma, así que hay que tener en cuenta algunos duplicados por separado. Para las respuestas en ruso, el autor retocó los prompts del sistema, aunque aconseja formular las preguntas en inglés; de lo contrario, la precisión baja.

"En resumen, funciona más o menos incluso con modelos de 4b".

Cómo responde el sistema

La prueba comparó varios modos. La búsqueda global trabaja sobre las descripciones de las comunidades con lógica MapReduce y encaja mejor con preguntas sobre todo el corpus. La búsqueda local mezcla relaciones del grafo con fragmentos del texto original y resulta más útil cuando hay que analizar un personaje, un objeto o un episodio concretos. También existe BASIC, la búsqueda habitual por fragmentos, y DRIFT, un modo más pesado que recuerda a la expansión de consultas e intenta ampliar el contexto.

• La búsqueda global recogió los principales temas ciberpunk del relato: la fusión de tecnología y biología, una ciudad distópica, los conflictos corporativos y la desigualdad tecnológica.
• La búsqueda local dio una respuesta más concreta sobre el personaje Jones y sus vínculos con Johnny, Molly y Yakuza.
• La búsqueda DRIFT tardó unos cuarenta minutos con la misma pregunta y no mostró un salto de calidad apreciable frente al modo local.
• BASIC sigue siendo un punto de control útil, porque la búsqueda vectorial no desaparece dentro de GraphRAG.

De ahí el autor extrae una conclusión práctica importante: en un producto real hará falta un agente o enrutador aparte que elija el tipo de búsqueda según la formulación de la pregunta y el historial de consultas. De lo contrario, habrá que cambiar de modo a mano.

Otro detalle: las respuestas de GraphRAG citan human_readable_id de los archivos parquet, así que en una interfaz de usuario esas referencias deben resolverse y procesarse aparte. Esto convierte a GraphRAG de simple buscador en una capa que hay que adaptar a un escenario de uso real.

Dónde surgieron los problemas

Con los modelos locales el panorama fue desigual. De los ejemplos encontrados, Mistral 7B no pudo con la búsqueda global por problemas con la salida JSON estructurada: las consultas map simplemente fallan. Gemma 3, en versiones de 4B y 12B, conservó las entidades principales pero simplificó el grafo y en ocasiones distorsionó hechos, hasta el punto de que Jones pasó de delfín a persona. El autor señaló a Qwen3 14B como la opción más viable. Para los embeddings usó el modelo user-bge-m3, que se comporta bien tanto en ruso como en inglés.

Hay también muchos matices de infraestructura. GraphRAG se apoya en LiteLLM, y el autor advierte expresamente de no subir de la versión 1.82.

6, porque las 1.82.7 y 1.

82.8 fueron comprometidas. Con Ollama aparece un falso error 404 al solicitar los parámetros del modelo, y las llamadas largas pueden chocar con timeouts de la cola.

Los embeddings se comportan peor aún: bge-m3 a través de Ollama a veces falla por la serialización de Inf y NaN, así que hubo que sacar el embedding a un proxy aparte en HuggingFace. Además, hay que editar a mano settings.yaml, fijar api_base y un tamaño de vector de 1024, y activar graphml para la visualización.

Incluso en una máquina con 16 GB de GPU, indexar un texto de este tamaño lleva más de una hora.

Qué significa

La conclusión principal del artículo es que Microsoft GraphRAG no parece un sustituto directo del RAG vectorial clásico. Resulta más útil donde importa más la profundidad de los vínculos semánticos que la velocidad de respuesta: analítica, sistemas expertos y corpus documentales complejos. El enfoque ya cuenta con API, una aplicación de prueba y un camino claro hacia un MVP. Pero las respuestas más relevantes se pagan con tiempo de indexación, un pipeline frágil y una configuración notablemente más compleja que la de una base vectorial normal.