Sber: el grafo de conocimiento Yago apenas ayudó a la búsqueda, mientras que LightRAG sumó 12 p. p. de precisión

Sber contó cómo intentó mejorar la calidad de su búsqueda interna con un grafo de conocimiento y un RAG híbrido. El primer intento, con un grafo universal ya hecho, casi no tuvo efecto. En cambio, el paso a LightRAG y a un corpus propio de documentos elevó de forma notable la precisión de las respuestas.

Por qué el grafo no despegó

La búsqueda de parte de los servicios de Sber ya se basaba en esquemas vectoriales e híbridos, pero el equipo chocó con las limitaciones típicas de ese enfoque. Un documento debe comprimirse en un solo vector, así que se pierden matices; la cercanía semántica no siempre significa que el documento responda realmente a la pregunta; y las consultas multi-hop, que exigen pasar por varias entidades y documentos, se resuelven mal con la búsqueda vectorial común. De ahí surgió la hipótesis: si se añade un grafo de conocimiento como fuente de contexto independiente, las respuestas serán más precisas y estables.

Para comprobarlo, tomaron SimpleQA de OpenAI traducido al ruso, con 4326 preguntas factuales, y usaron un esquema llm-as-a-judge para la evaluación automática. El primer prototipo se construyó sobre Yago 4.5, uno de los mayores grafos de conocimiento abiertos, cargado en Apache Jena Fuseki, con una API y un agente montados sobre los datos. El pipeline era clásico: extracción de entidades de la consulta, consulta con plantilla a la base de grafos, ranking de los nodos y relaciones encontrados y, por último, resumen de la respuesta mediante un LLM. Sobre el papel resultaba convincente, pero en las cifras la mejora fue débil.

13 experimentos seguidos

Tras las primeras mediciones, el equipo montó un banco de pruebas aparte y ejecutó 13 experimentos con 184 mediciones. Primero probó el grafo puro y luego la combinación del grafo con la búsqueda habitual mediante un reranker que reunía un único top de candidatos para la respuesta. La conclusión básica fue incómoda: en ruSimpleQA el grafo aislado dio solo +3 p. p., y junto con la búsqueda actual el resultado no salió del margen de error estadístico.

• Conectaron fuentes adicionales, entre ellas IMDB, pero sin agregación compleja de datos a nivel de base
• Probaron a ordenar las entidades por relevancia, por ejemplo según el número de enlaces de cada nodo
• Cambiaron los límites tras el ranking para equilibrar la completitud del contexto y su tamaño
• Probaron un recorrido inteligente del grafo hasta tres niveles de profundidad y una búsqueda en anchura de uno o dos saltos
• Añadieron búsqueda vectorial sobre embeddings de nodos y algoritmos de grafos, como la búsqueda de rutas entre entidades

Los problemas no estaban solo en la infraestructura, sino en la naturaleza del propio grafo. Para los embeddings había que usar descripciones de entidades cortas y pobres, por lo que la búsqueda vectorial sobre el grafo era inestable. Yago resultó demasiado universal: cubre bien el mundo en general, pero refleja mal la temática concreta y las relaciones que importan en las consultas reales de los usuarios. Además, cada paso de la cadena del agente añadía un nuevo error, desde la extracción de la entidad hasta el resumen final.

El giro hacia LightRAG

Después, el equipo cambió de estrategia: en lugar de un grafo universal del mundo, decidió construir el grafo directamente a partir de sus propios documentos. Eligió LightRAG, un framework GraphRAG con búsqueda en dos niveles que combina las relaciones locales entre entidades con una visión temática más amplia. El sistema primero extrae nodos y relaciones del texto, luego los describe, vectoriza los valores y almacena el grafo junto con los embeddings. Este enfoque ayuda a no perder contexto entre chunks y evita que el LLM tenga que pegar a ciegas fragmentos aleatorios de distintos documentos.

«Basura de entrada, con alta probabilidad, dará basura de salida.»

Sber indexó con LightRAG un corpus de documentos elegido para las preguntas que la búsqueda en producción no respondía, y volvió a ejecutar los benchmarks. Esta vez el efecto fue claro: LightRAG dio respuestas correctas al 74% de varios cientos de preguntas antes no cubiertas y sumó 12 p. p. de precisión en el conjunto completo de 4326 consultas. Otra ventaja es el coste: el artículo señala que LightRAG es unas 30–40 veces más barato que Microsoft GraphRAG en la fase de indexación, con una calidad comparable.

El siguiente paso es probar con tráfico de producción y acelerar la indexación, que por ahora se queda en unos 200 documentos por hora incluso en una H100.

Qué significa

La historia de Sber muestra algo sencillo: un gran grafo de conocimiento, por sí solo, no vuelve más inteligente a la búsqueda. Importa mucho más cuánto se ajusta el grafo a tu dominio, cómo se conecta con la búsqueda vectorial y con qué fallos reales lo mides.

Para los equipos que construyen búsqueda RAG, es una buena señal para no perseguir una demo vistosa con un grafo público, sino invertir en un corpus de calidad, en retrieval híbrido y en una evaluación honesta sobre escenarios reales.