| No lo construí porque creyera que el mundo necesitaba otro framework de RAG. Lo construí porque no confiaba en las respuestas que obtenía — y no confiaba en mi propio entendimiento de por qué existían esas respuestas. |
Leer sobre grafos de conocimiento y generación aumentada por recuperación es fácil. Asentir ante los diagramas de arquitectura es fácil. Creer que ‘esto reduce las alucinaciones’ es fácil.
Entender de dónde viene realmente la confianza, no lo es.
Por eso construí KnowGraphRAG — no como un producto, sino como un experimento: ¿qué pasa si dejas de tratar al LLM como el centro de la inteligencia y en cambio lo obligas a hablar únicamente desde una estructura que puedes inspeccionar?
Por qué el RAG basado en fragmentos falla en el trabajo real
Los sistemas RAG tradicionales suelen lucir así:
- Dividir documentos en fragmentos (chunks)
- Generar embeddings de esos fragmentos
- Recuperar fragmentos ‘similares’ en el momento de la consulta
- Pasárselos al LLM y esperar que se comporte bien
Esto funciona sorprendentemente bien — hasta que no funciona.
Los modos de falla aparecen rápido cuando:
- usas modelos locales más pequeños
- tus datos no son texto limpio (logs, configuraciones, volcados de datos, CSVs)
- te importa por qué existe una respuesta, no solo qué dice
La búsqueda por similitud sola no entiende estructura, relaciones ni procedencia. Dos fragmentos pueden ser ‘similares’ y aun así resultar engañosos cuando se toman juntos. Y una vez que el LLM empieza a tender puentes por su cuenta, las alucinaciones se cuelan — especialmente en hardware con recursos limitados.
| No me interesaba hacer el modelo más inteligente. Me interesaba hacerlo más restringido. |
Invertir el modelo: el grafo va primero
El cambio arquitectónico clave en KnowGraphRAG es simple de enunciar y difícil de internalizar:
| El grafo de conocimiento
es el sistema de registro. |
El LLM
es solo el renderizador. |
Bajo el capó, el proceso de ingestión luce aproximadamente así:
- Los documentos se ingestan completos, sin importar el formato — PDFs, DOCX, CSV, JSON, XML, configuraciones de red, logs
- Se dividen en fragmentos, pero los fragmentos no se tratan como hechos aislados
- Se extraen entidades: IPs, organizaciones, personas, hosts, fechas, etc.
- Se crean relaciones: documento → fragmento, fragmento → fragmento (secuencia), documento → entidad, entidad → entidad (cuando se pueden inferir relaciones)
- Todo se almacena en un grafo, no en un índice vectorial. Los embeddings siguen existiendo — pero son solo una señal, no el principio organizador.
El resultado es un grafo donde:
- los documentos saben qué contienen
- los fragmentos saben de dónde vienen
- las entidades saben quién las menciona
- las relaciones son explícitas, no inferidas sobre la marcha
| Por qué eso importa
Esa estructura resulta importar mucho. Cuando la procedencia está codificada en el grafo antes de que el LLM entre en escena, el modelo no tiene que ‘adivinar’ las conexiones. Las conexiones ya existen. Esto es exactamente lo que HALLEY VKI implementa a escala enterprise con trazabilidad criptográfica. |
Qué significa ‘recuperación’ en un RAG basado en grafos
Cuando haces una pregunta, KnowGraphRAG no hace simplemente una búsqueda de similitud top-k. En cambio, sigue aproximadamente este flujo:
| 1. Extraer entidades de la consulta
→ No embeddings todavía — conceptos reales
2. Anclar la búsqueda en el grafo → Encontrar documentos, fragmentos y entidades ya conectadas
3. Traversar hacia afuera → Seguir relaciones para construir un subgrafo conectado
4. Usar embeddings para ordenar, no para inventar → La similitud ayuda a ordenar candidatos, no a definir verdad
5. Expandir el contexto deliberadamente → Fragmentos adyacentes, entidades relacionadas, vecinos estructurales |
Solo después de que ese contexto está ensamblado interviene el LLM. Y cuando lo hace, recibe un prompt muy restringido:
| Aquí está el contexto.
Aquí están las citas. No respondas fuera de esto. |
| Así es como se matan de hambre las alucinaciones — no se eliminan, pero se asfixian. |
Por qué esto funciona especialmente bien con LLMs locales
Una de mis restricciones fuertes era que esto necesitaba correr localmente — lentamente si era necesario — en hardware limitado. Incluso en algo como una Raspberry Pi.
Esa restricción forzó una verificación de honestidad arquitectónica.
Los modelos pequeños y sin capacidad de razonamiento avanzado son en realidad muy buenos en:
- resumir hechos conocidos
- reformular entradas estructuradas
- correlacionar información ya adyacente
Son terribles para inventar eslabones perdidos de forma responsable.
Al mover la correlación, el recorrido del grafo y la selección a la capa del grafo, el LLM ya no tiene que ‘descifrar las cosas’. Solo tiene que hablar.
| La implicación para hardware real
Ese cambio hizo que los modelos locales fueran dramáticamente más útiles — y mucho más predecibles. Un modelo de 3B parámetros que solo ‘habla’ desde un grafo estructurado supera a un modelo de 70B que tiene que ‘pensar’ sin estructura. HALLEY VKI opera con 3 mil millones de parámetros activos a costo cero por consulta precisamente por este principio. |
La parte que no esperaba: la auditabilidad se convierte en la característica
La mayor sorpresa no fue la calidad de la recuperación.
Fue la auditabilidad.
Porque cada respuesta se deriva de:
- nodos específicos del grafo
- relaciones específicas
- documentos y fragmentos específicos
…se vuelve posible ver cómo se construyó una respuesta incluso cuando el modelo en sí mismo no expone el razonamiento.
Eso resulta ser increíblemente valioso para:
- trabajo de cumplimiento regulatorio
- análisis de riesgos
- explicar decisiones a humanos que no les importan los embeddings
En lugar de decir ‘el modelo piensa’, puedes decir:
| estas entidades estaban involucradas
estos documentos contribuyeron este es el camino de recuperación |
| Eso no es IA explicable en el sentido académico — pero es operacionalmente defendible. |
Qué es KnowGraphRAG (y qué no es)
KnowGraphRAG terminó siendo un sistema completo, no una demo:
- Almacenamiento respaldado por grafos (en memoria + persistente)
- Extracción de entidades y relaciones
- Recuperación híbrida (grafo primero, embeddings segundo)
- Versionado de documentos y seguimiento de cambios
- Historial de consultas y rastros de auditoría
- Ingestión por lotes con salvaguardas
- Visualización para que puedas ver el grafo
- Soporte para backends LLM locales y remotos
- Una interfaz MCP para que otras herramientas lo puedan controlar
Pero no es una bala de plata.
| Lo que SÍ hace | Lo que NO hace |
| ✔ Mover la responsabilidad fuera del modelo y de vuelta al sistema que controlas | ✗ Convertir datos malos en buenos |
| ✔ Hacer que los modelos locales pequeños sean útiles para trabajo serio | ✗ Eliminar todas las alucinaciones |
| ✔ Proveer auditabilidad operacional de cada respuesta | ✗ Reemplazar el juicio humano |
| ✔ Crear fronteras que hacen la confianza inevitable | ✗ Responder preguntas fuera del corpus |
El cambio de mentalidad que importa
| No le pidas a los LLMs que sean confiables. Diseña sistemas donde la confianza sea inevitable. |
Los grafos de conocimiento y el RAG no son una panacea — pero juntos crean fronteras. Y las fronteras son lo que hace que los LLMs locales sean útiles para trabajo serio.
No lo entendí completamente hasta que lo construí.
Y ahora que lo hice, no creo que pueda volver atrás.
| Nota del autor sobre HALLEY VKI
Al final de su artículo, Brent Huston escribe: «Shout-out to my friend and brother, Riangelo, for talking with me about the approach and for helping me make sense of it. He is building an enterprise version with much more capability.» Riangelo es miembro del equipo fundador de HALLEY VKI. Los principios que Brent describe en este artículo — grafo primero, LLM como renderizador, trazabilidad de procedencia, auditabilidad operacional — son exactamente los que HALLEY VKI implementa a escala enterprise con capacidades adicionales: extracción determinista, offsets de carácter, validación SHACL, procesamiento multiidioma 100% on-premise, y cero dependencia de cloud o APIs externas. Si este artículo le generó preguntas sobre cómo aplicar estos principios en su organización, le invitamos a solicitar una demostración. |
| Sobre el autor original
Brent L. Huston es fundador de MicroSolved, Inc. y lleva más de 30 años trabajando en ciberseguridad, machine learning y arquitectura de sistemas. Es investigador, speaker y escritor prolífico en su blog personal Not Quite Random (notquiterandom.com), donde comparte experimentos técnicos sin ataduras corporativas. En este artículo describe su experiencia construyendo KnowGraphRAG — el mismo enfoque arquitectónico sobre el que conversó con Riangelo, del equipo fundador de HALLEY VKI. Artículo original: «Building a Graph-First RAG Taught Me Where Trust Actually Lives With LLMs» · Not Quite Random · 14 enero 2026 |