Los sistemas GraphRAG locales necesitan presupuestos de contexto y guardas de frescura, no solo mas vecinos
Los sistemas locales de notas con grafos prometen mejorar la generacion al recuperar semillas, vecinos, comunidades y fragmentos compactos. Este articulo pregunta que evidencia hace falta antes de afirmar que esa expansion mejora respuestas y no solo aumenta el numero de piezas en el prompt. La semilla de workspace fue FileGraph, una aplicacion local-first de notas markdown que construye contexto desde noteId o consulta, expande por aristas de grafo y por pertenencia al mismo espacio de origen, limita vecinos y corta cuerpos de nota. Esa implementacion prueba contexto acotado y source-aware, pero no prueba por si misma relevancia, fidelidad, frescura, orden ni soporte de citas. La sintesis combina busquedas AlexandrAI, fuentes locales y articulos sobre RAG, GraphRAG, G-Retriever, LightRAG, Lost-in-the-Middle, Self-RAG, CRAG, RAGAS, ARES, ALCE, KILT, FreshLLMs y MemoRAG. El resultado es un ledger de calidad de contexto con estados separados para semilla, puntuacion, borde, comunidad, frescura, presupuesto, posicion, evaluacion y soporte de cita. La conclusion es proporcional: un endpoint local puede afirmar que ensambla contexto acotado; solo puede afirmar mejora de respuesta cuando publica evidencia de relevancia, fidelidad, actualidad y soporte claim-to-context.
Introduccion
Los sistemas locales de notas con grafos prometen una forma atractiva de recuperar contexto: buscar una semilla textual, expandir a vecinos, resumir comunidades y entregar al modelo un bloque compacto. Esa promesa es razonable, pero incompleta. Un contexto mas grande, con mas vecinos o con mas comunidades, no prueba que la respuesta sea mas fiel, actual o verificable [[cite:liu2023,es2024]].
El espacio de trabajo que motivo este estudio contiene FileGraph, una aplicacion local-first de notas markdown con metadatos de grafo, rutas de ingestion, artefactos derivados y un endpoint de contexto de recuperacion [[cite:fgReadme]]. La implementacion inspeccionada toma un noteId opcional o una consulta, usa MiniSearch para semillas, expande por aristas del grafo y por pertenencia al mismo espacio de origen, limita los vecinos a 12 y corta el cuerpo de cada nota a 800 caracteres [[cite:fgService,alexRetrievalGuide]].
Ese diseno demuestra una propiedad importante: el contexto esta acotado y no es una concatenacion ilimitada de la boveda. Pero no demuestra por si mismo precision de recuperacion, frescura, utilidad de la arista, calidad de resumen comunitario, posicion optima dentro del prompt ni fidelidad de la respuesta. La pregunta de este articulo es: que evidencia debe publicar un sistema GraphRAG local antes de afirmar que su expansion de contexto mejora la respuesta?
La respuesta propuesta es un ledger de calidad de contexto. El ledger separa ocho estados: semilla, puntuacion, borde, comunidad, frescura, presupuesto, posicion y soporte de cita. La tesis es simple: un sistema local puede afirmar 'ensamble contexto acotado' con evidencia de implementacion; solo puede afirmar 'mejore respuestas' cuando ademas mide relevancia, fidelidad, actualidad y soporte de citas [[cite:es2024,saad2024,gaoAlce2023]].
Metodo
El metodo fue una sintesis conceptual semilla-por-workspace. Primero inspeccione las fuentes locales relevantes: README, tipos y servicio FileGraph. Despues busque en el grafo AlexandrAI para detectar duplicados: aparecieron un articulo de procedencia de FileGraph, una guia de contexto de recuperacion y un articulo de claim-edge. Por eso este trabajo no repite la tesis de procedencia; estudia calidad de contexto.
La fase externa uso articulos de investigacion sobre RAG, GraphRAG, recuperacion en grafos textuales, contexto largo, recuperacion adaptativa, recuperacion correctiva, evaluacion RAG, citas y frescura. La muestra final conserva 20 fuentes leidas a fondo y mas de 50 fuentes sopesadas o descartadas. La revision no pretende ser sistematica; su objetivo es construir un modelo de evidencia proporcional para sistemas locales.
Las fuentes fueron codificadas por el estado que ayudan a demostrar. RAG y KILT prueban la importancia de memoria no parametrica y procedencia [[cite:lewis2020,petroni2021]]. GraphRAG, LightRAG y G-Retriever prueban que el grafo puede ser parte de la recuperacion, no solo una visualizacion [[cite:edge2024,guo2025,he2024]]. Lost-in-the-Middle, Self-RAG, CRAG y FreshLLMs prueban que el contexto puede fallar por posicion, necesidad, calidad u obsolescencia [[cite:liu2023,asai2023,yan2024,vu2023]]. RAGAS, ARES y ALCE prueban que la evaluacion debe separar contexto, fidelidad, respuesta y cita [[cite:es2024,saad2024,gaoAlce2023]].
Semilla local: que prueba FileGraph y que no
FileGraph prueba un diseno local claro. Las notas viven como markdown; los artefactos de grafo se reconstruyen; la respuesta de contexto incluye semillas, vecinos, comunidades y markdown compacto [[cite:fgReadme,fgService]]. El codigo inspeccionado tambien evita una expansion ilimitada: los resultados de busqueda se limitan antes de expandir, las notas vecinas se cortan a 12 y cada cuerpo se reduce a un segmento breve [[cite:fgService]].
La misma evidencia local tambien marca el limite. La respuesta de contexto no publica, dentro del bloque markdown, una puntuacion de relevancia para cada vecino, una razon de borde, la fecha de frescura como criterio de seleccion, una medida de posicion en prompt, ni una evaluacion posterior de fidelidad de respuesta. Eso no es un defecto fatal; es una frontera de reclamo. La implementacion soporta 'contexto acotado y source-aware', no 'contexto optimo'.
La guia AlexandrAI de recuperacion ya enfatizaba reglas sanas: admitir noteId, consulta o ambos; limitar semillas; evitar duplicados; mantener expansion same-origin sin exponer rutas privadas; y actualizar tipos si cambia la salida [[cite:alexRetrievalGuide]]. Este articulo convierte esas reglas en un problema de evaluacion: como saber cuando una regla produce evidencia util y no solo evidencia disponible.
Evidencia externa: por que mas contexto no basta
RAG nace para conectar modelos generativos con memoria no parametrica y fuentes actualizables [[cite:lewis2020]]. La encuesta de Gao y colegas muestra que RAG se ha vuelto modular: recuperacion, generacion, aumento y evaluacion son piezas distintas [[cite:gaoSurvey2024]]. Para un sistema local, esto implica que la ruta de contexto no debe absorber todo el reclamo; solo cubre la fase de recuperacion y empaquetado.
GraphRAG agrega una idea fuerte: algunas preguntas globales sobre un corpus no se resuelven con top-k fragmentos; requieren grafos de entidades, comunidades y resumen query-focused [[cite:edge2024]]. LightRAG y G-Retriever refuerzan la misma direccion desde otros angulos: relaciones, subgrafos, representaciones duales y actualizaciones incrementales pueden mejorar la recuperacion, pero cada una introduce una nueva evidencia que debe medirse [[cite:guo2025,he2024]].
La evidencia limitante es igual de importante. Lost-in-the-Middle muestra que los modelos pueden usar mal la informacion situada en medio de contextos largos [[cite:liu2023]]. Self-RAG advierte que recuperar un numero fijo de pasajes puede perjudicar cuando no hace falta recuperar o cuando los pasajes son debiles [[cite:asai2023]]. CRAG trata la recuperacion incorrecta como un estado que debe evaluarse y corregirse [[cite:yan2024]]. FreshLLMs muestra que actualidad, orden de evidencias y conocimiento cambiante afectan la exactitud [[cite:vu2023]].
Resultado: ledger de calidad de contexto
El resultado principal es el ledger de calidad de contexto. No es una metrica unica; es una tabla de estados que impide que el sistema llame 'respuesta mejorada' a un simple aumento de vecinos. Cada estado tiene un artefacto verificable y un reclamo maximo permitido.
El ledger aclara la relacion entre diseno local e investigacion externa. FileGraph ya cubre varias bases: seed, expansion, limite y procedencia. La literatura RAG explica por que esas bases no son suficientes. RAGAS y ARES convierten el problema en dimensiones evaluables; ALCE y claim-edge accountability agregan soporte de citas; FreshLLMs y LightRAG agregan frescura e incremento; Lost-in-the-Middle agrega posicion [[cite:es2024,saad2024,gaoAlce2023,vu2023,guo2025,liu2023]].
La consecuencia practica es que las interfaces no deben mostrar solo '12 vecinos agregados'. Deben mostrar por que esos vecinos entraron, que parte se corto, cuando se actualizo cada fuente, que comunidad representa, donde quedo en el prompt y que metrica posterior confirmo su utilidad. Sin eso, el sistema puede estar entregando ruido de alta confianza.
Discusion
Una lectura conservadora del workspace es la mas defensible: FileGraph tiene un buen primer control porque el contexto se acota y se deriva de metadatos estructurados. Esa acotacion reduce riesgo operativo, pero no equivale a evaluacion de calidad. La literatura externa empuja el siguiente paso: medir el contexto como componente, no como decoracion de prompt.
El ledger tambien evita una falsa oposicion entre busqueda textual y grafo. MiniSearch, aristas, comunidades, same-origin expansion y summaries pueden convivir. El problema no es elegir una familia; el problema es publicar el artefacto que justifica cada inclusion. Una coincidencia textual, una arista relacionada y una comunidad resumida no tienen el mismo tipo de evidencia.
La frescura merece un lugar propio. En notas locales, una fuente puede estar versionada, reanalizada o pendiente. FreshLLMs muestra que el conocimiento cambiante y el orden de evidencias influyen en la exactitud [[cite:vu2023]]. LightRAG enfatiza actualizacion incremental [[cite:guo2025]]. Un endpoint local deberia poder responder: esta nota entro por relevancia actual, por relacion historica o por simple vecindad antigua?
Limitaciones
Este articulo no ejecuta un benchmark de FileGraph ni mide precision real de busqueda en una boveda grande. La evidencia local se limita a lectura de codigo y artefactos existentes. Por tanto, el reclamo empirico se mantiene bajo: la implementacion observada es compatible con un ledger de calidad, pero el ledger no esta implementado ni validado en este estudio.
Las fuentes externas tampoco se transfieren sin ajuste. GraphRAG trabaja con corpus privados y preguntas globales; G-Retriever usa grafos textuales y benchmarks especificos; RAGAS y ARES evaluan pipelines RAG, no necesariamente notas markdown locales. Por eso el resultado se formula como modelo de evidencia y no como afirmacion de rendimiento.
Una evaluacion futura deberia construir un corpus controlado de notas, variar el numero de vecinos, el orden del contexto, la frescura y las comunidades, y medir relevancia de contexto, fidelidad de respuesta, soporte de citas y costo de prompt. Esa prueba distinguiria si la expansion del grafo aporta informacion o solo densidad.
Conclusion
Los sistemas GraphRAG locales necesitan presupuestos de contexto y guardas de frescura, no solo mas vecinos. FileGraph ya demuestra una base util: contexto acotado, expansion por grafo, same-origin awareness y artefactos derivados. Pero la literatura RAG muestra que esas propiedades no bastan para afirmar mejora de respuesta.
El reclamo proporcional es: sin evaluacion, el sistema ensambla contexto; con razones de borde y frescura, ensambla contexto auditable; con relevancia, fidelidad y soporte de citas, puede empezar a afirmar mejora. El ledger propuesto mantiene esas frases separadas para que un numero de vecinos no sustituya la evidencia.