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

Sber explicó cómo intentó mejorar la calidad de la búsqueda interna utilizando grafos de conocimiento y RAG híbrido. El primer intento con un grafo universal listo para usar casi no tuvo efecto, pero el cambio a LightRAG y su propio corpus de documentos aumentó notablemente la precisión de las respuestas.

Por qué el grafo no despegó

Los servicios de Sber ya dependían de esquemas de búsqueda vectorial e híbrida, pero el equipo se topó con limitaciones típicas de este enfoque. Un único documento debe comprimirse en un vector, por lo que se pierden matices; la similaridad semántica no siempre significa que el documento realmente responda la pregunta; y las consultas multi-hop, donde necesitas atravesar múltiples entidades y documentos, son manejadas pobremente por la búsqueda vectorial ordinaria. Esto llevó a una hipótesis: si agregamos un grafo de conocimiento como fuente separada de contexto, las respuestas serían más precisas y robustas.

Para probarlo, tomaron SimpleQA de OpenAI (traducido al ruso) en 4.326 preguntas factuales y utilizaron llm-as-a-judge para evaluación automática. El primer prototipo se construyó en Yago 4.

5, uno de los grafos de conocimiento abiertos más grandes, que cargaron en Apache Jena Fuseki e implementaron una API y un agente sobre los datos. El pipeline era clásico: extracción de entidades de la consulta, consulta basada en plantilla a la base de datos gráfica, ranking de nodos y aristas encontradas, luego sumarización de respuesta vía LLM. En papel todo se veía convincente, pero las ganancias resultaron ser débiles.

13 experimentos seguidos

Tras las mediciones iniciales, el equipo configuró un banco de pruebas separado y ejecutó 13 experimentos con 184 mediciones. Primero probaron el grafo puro, luego una combinación del grafo con búsqueda ordinaria mediante un reranker, que recopilaba un único conjunto superior de candidatos de respuesta. La conclusión básica fue desagradable: en ruSimpleQA el grafo en aislamiento dio solo +3 puntos porcentuales, y combinado con la búsqueda existente, el resultado no superó el margen de error.

• Añadieron fuentes adicionales, incluyendo IMDB, pero sin agregación compleja de datos a nivel de base de datos
• Intentaron clasificar entidades por relevancia, por ejemplo por el número de conexiones en un nodo
• Cambiaron los límites de ranking para equilibrar completitud de contexto y su tamaño
• Probaron recorrido inteligente de grafos hasta una profundidad de tres niveles y búsqueda en amplitud en uno o dos hops
• Añadieron búsqueda vectorial vía embeddings de nodos y algoritmos gráficos como búsqueda de ruta entre entidades

Los problemas no estaban solo en la infraestructura, sino también en la naturaleza del grafo mismo. Para embeddings, tuvieron que usar descripciones de entidades cortas y escasas, lo que hizo que la búsqueda vectorial sobre el grafo fuera inestable. Yago resultó ser demasiado universal: cubre bien el mundo en general, pero refleja pobremente dominios específicos y relaciones importantes para consultas reales de usuarios. Además, cada paso en la cadena de agentes añadía nuevos errores—desde extracción de entidades hasta sumarización final.

El giro hacia LightRAG

Después de esto, el equipo cambió de estrategia: en lugar de un grafo universal mundial, decidieron construir un grafo directamente a partir de sus propios documentos. Para esto, eligieron LightRAG—un framework GraphRAG con búsqueda de dos niveles que combina relaciones locales entre entidades y una visión temática más amplia. El sistema primero extrae nodos y aristas del texto, luego los describe, vectoriza los valores y almacena el grafo junto con embeddings. Este enfoque ayuda a evitar perder contexto entre chunks y no obliga a la LLM a pegar ciegamente piezas aleatorias de diferentes documentos.

"Basura en la entrada muy probablemente da basura en la salida."

Sber indexó su corpus de documentos a través de LightRAG, seleccionando documentos que abordaban preguntas que la búsqueda de producto no podía responder, y ejecutó los benchmarks nuevamente. El efecto fue notable: LightRAG proporcionó respuestas correctas al 74% de varios cientos de preguntas previamente no cubiertas y añadió 12 puntos porcentuales a la precisión en el conjunto completo de 4.326 consultas. Un plus adicional—eficiencia: el artículo afirma que LightRAG es aproximadamente 30–40 veces más barato que Microsoft GraphRAG en la etapa de indexación con calidad comparable. El siguiente paso es probar en tráfico de producción y acelerar la indexación, que actualmente se estrangula en alrededor de 200 documentos por hora incluso en H100.

Qué significa esto

La historia de Sber demuestra una cosa simple: un gran grafo de conocimiento por sí solo no hace que la búsqueda sea más inteligente. Lo que importa mucho más es qué tan vinculado está el grafo a tu dominio, cómo está conectado a la búsqueda vectorial y en cuáles brechas reales lo mides. Para equipos que construyen búsqueda RAG, esta es una buena señal de no perseguir la demo bonita con un grafo público, sino invertir en corpus de calidad, retrieval híbrido y evaluación honesta en escenarios reales.