atareao con Linux

Conecta tus notas con IA, el fin de las búsquedas que fallan

Vistas: 1
atareaoComenta
0:00 / 0:00
Conecta tus notas con IA, el fin de las búsquedas que fallan

Llevo años apuntando todo. Cada comando que me salva la vida, cada configuración que me ha costado media tarde, cada error del que salgo por los pelos. Tengo miles de notas en Markdown, con sus títulos bonitos, sus etiquetas, sus fechas de creación y hasta su lista de notas relacionadas. Y aun así hay días en los que no sé dónde hablo de qué. Busco particiones y la nota que necesito se llama Redimensionar LVM. Busco monitorización de red y mis notas dicen ntopng e iftop. Y cuando busco alta disponibilidad aparecen keepalived y Nginx, pero sueltos, sin que se vea que forman parte del mismo sistema. No es que tenga pocas notas, es que las tengo y no las encuentro. Hoy te voy a contar cómo he resuelto ese problema con una herramienta que he escrito en Rust, y por el camino vas a entender qué es eso del GraphRAG y por qué va a cambiar la forma en que exploro mi cerebro digital.

Tienes el conocimiento, pero no el mapa

Empecemos por lo básico, porque estoy convencido de que compartimos el mismo síntoma. Tienes lo que yo llamo un cerebro digital. Puede ser Obsidian, puede ser Joplin, puede ser simplemente una carpeta ~/notas llena de ficheros .md. Lo has organizado como has podido y como has querido, por temas, por etiquetas, por proyectos, por carpetas. Y durante una buena temporada eso funciona de maravilla.

Cuando quieres recuperar algo, ¿qué haces? Lo de siempre, grep. O el buscador de Obsidian. O un Ctrl+F dentro de la carpeta. Y funciona, claro que funciona. Funciona mientras tú, el del presente, y tu yo del pasado usasteis la misma palabra para hablar de lo mismo. En el momento en que ese acuerdo tácito se rompe, la búsqueda deja de servir.

Y deja de servir por una razón muy concreta, que es el corazón de todo lo que te voy a contar hoy. La búsqueda clásica busca palabras. Coincidencia literal, letra a letra, y además diferenciando mayúsculas de minúsculas, porque es case sensitive. No busca significados. Compara cadenas de texto como si fueran cadenas de texto, sin entender nada de lo que hay detrás.

Tienes el conocimiento, pero no tienes el mapa. Es como saber que el tesoro está en algún sitio de la isla, pero no tener el plano para llegar hasta él.

Esa frase, la de que tienes el conocimiento pero no tienes el mapa, es exactamente el problema que atacamos en este episodio. Y no es un problema de cantidad. Es un problema de estructura. Vamos a verlo con los tres ejemplos que me pasan a mí de verdad, no con casos de laboratorio.

Ejemplo uno, las particiones que no se llaman particiones

Quiero montar un RAID y necesito recordar cómo ajusté el tamaño de un volumen. Busco particiones y aparecen las notas de siempre, la de particionado con fdisk, la de gparted. Perfectas, pero no es lo que busco. La nota donde de verdad explico cómo redimensionar en caliente se llama Redimensionar LVM. Y dentro de esa nota aparecen lvm, pvresize, extend, volumen lógico. La palabra partición brilla por su ausencia. Para grep, esa nota no existe. Para mí, sí, porque está en mi cabeza. Ese es el desajuste.

Ejemplo dos, cuando la consulta y el título hablan idiomas distintos

Quiero revisar cómo veía yo el tráfico de la red hace un tiempo. Busco monitorización de red. Nada razonable. Pero yo tengo una nota titulada ntopng: ver el tráfico en el navegador y otra que se llama iftop, el top de la red. Son exactamente lo que buscaba, solo que mi consulta habla en abstracto y mis títulos hablan en nombres propios de herramientas. Misma idea, idiomas distintos, cero coincidencias.

Ejemplo tres, las tres piezas que van juntas y nunca se ven juntas

Este es el que más me molesta, porque aquí no hay solo un problema de vocabulario, hay un problema de relación. Busco alta disponibilidad. Encuentro la nota de keepalived, y hasta ahí bien. Lo que no encuentra es que esa nota conecta con la de balanceo de carga con Nginx, que a su vez conecta con la de certificados y renovación automática. Tengo tres piezas de un mismo sistema y la búsqueda me devuelve una sola, aislada, sin ninguna pista de que las otras dos existen y de que van de la mano.

Lo peor de todo es que el conocimiento está en mis notas. No me falta información, me sobra. Lo que me falta es saber cómo se conecta. He escrito sobre particiones, sobre LVM, sobre RAID, y esos conceptos viven en la misma cabeza y muchas veces en las mismas notas, pero cada búsqueda me los devuelve desconectados. Y esa desconexión es justo lo que vamos a arreglar.

Del RAG clásico y sus tres límites

Antes de hablar de grafos necesito recordar cómo funciona lo que ya conocemos, porque si vienes de los episodios anteriores ya te suena y si no, te pongo en situación en dos minutos. Sabes que existe algo mejor que grep, y ese algo es el RAG, Retrieval Augmented Generation. Hablamos de ello en el episodio 817, el de los embeddings, y en el 819, donde montamos un RAG de los de siempre. Hoy lo vamos a superar, pero merece la pena entender por qué se queda corto.

La cadena del RAG clásico es esta. Coges tus notas, las troceas en fragmentos, conviertes cada fragmento en un embedding, comparas tu consulta con esos embeddings, te quedas con los top-k más parecidos, los cinco o diez mejores, y se los das a un modelo de lenguaje para que redacte una respuesta. Trocear, embeber, comparar, quedarse con lo mejor, entregárselo al modelo. Simple y eficaz.

Los embeddings como flechas, sin fórmulas

Y como esto de los embeddings se cuenta fatal casi siempre, vamos a hacer un repaso visual, sin fórmulas, minuto y medio y prometido. Imagina que cada fragmento de texto se convierte en una flecha dentro de un espacio de muchas dimensiones. No dos ni tres, cientos o miles. En la práctica, dependiendo del modelo, hablamos de 1024 dimensiones, o de 1300 y pico. Y esa flecha apunta desde el vector cero, el origen, hasta el punto que representa a ese fragmento.

Dos textos que hablan de lo mismo apuntan casi en la misma dirección, esas dos flechas se van acercando. Dos textos que no tienen nada que ver apuntan a direcciones opuestas o perpendiculares. Y la similitud entre ellos es una forma de medir el ángulo que forman esas flechas. Cuanto más pequeño sea el ángulo, más se parecen. Cuando el ángulo es cero, el coseno es uno, y ahí tienes la máxima similitud. Eso es lo que se llama similitud coseno, y es la cuenta que hace el motor por debajo.

¿Y qué hay en cada dimensión? Pues cada una captura un matiz. Una puede estar discriminando si hablo de redes o de almacenamiento, otra si es un problema o una solución, otra si es antiguo o moderno. Nadie las interpreta a mano, no tienen nombre, pero están ahí, y por eso los embeddings funcionan tan bien.

Y aquí llega la clave del episodio, la idea con la que quiero que te quedes. La flecha solo dice parecido. Nunca dice conexión. Dos flechas pueden estar casi pegadas porque hablan de lo mismo, y mirando solo el ángulo no tengo forma de saber si una de esas cosas sirve para resolver la otra, o si van juntas en un mismo sistema. La cercanía vectorial es una sensación de similitud, no un mapa de relaciones.

Límite uno, el fragmento pierde el contexto

Con eso claro, los tres límites del RAG clásico. El primero, el fragmento pierde el contexto. Cuando troceo una nota, ese trozo deja de saber a qué nota pertenece, qué venía antes y qué venía después. Puedo recuperar un fragmento impecable, que describe perfectamente un comando, y no enterarme de para qué sirve ni en qué problema se usa. El trozo está huérfano.

Límite dos, no entiende relaciones

Este es el grande. El sistema sabe que el fragmento de Docker y el fragmento de Nginx se parecen un poco. Pero no sabe que en tu conocimiento Nginx corre delante de tus servicios como proxy inverso, ni que Docker contiene esa aplicación. La relación, esa flecha que va de un concepto a otro con un significado, no está en ningún sitio del espacio vectorial. El espacio vectorial no tiene aristas, solo puntos y distancias.

Límite tres, no tiene visión global

Y el tercero, no tiene visión global. El RAG clásico responde a la consulta que le haces. Si le preguntas por seguridad en contenedores, te devuelve cinco fragmentos donde sale esa frase. No sabe que tu corpus tiene una zona entera de hardening, otra de redes y otra de copias de seguridad. Le falta el mapa, le falta esa vista de pájaro que tú tienes cuando llevas años escribiendo sobre lo mismo.

Esto se ve clarísimo con un ejemplo de los que me pasan. Buscas seguridad en contenedores y el RAG clásico te devuelve cinco trozos, los más parecidos, y punto. Si entre esos cinco trozos no aparece el que habla de AppArmor, porque tu nota de AppArmor no usa la palabra contenedores por ningún lado, no hay manera de que salga. Tú sabes que existe. El sistema, no. Y por eso me gusta resumirlo así, el RAG clásico te da trozos, pero no te da el mapa. Lo que necesitamos para encontrar conexiones es, precisamente, un mapa.

Grafos de conocimiento: nodos, aristas y pesos

Y aquí llega la idea nueva, que te prometo que es más sencilla de lo que parece. Un grafo de conocimiento no es nada más que un mapa de cosas y de cómo se tocan entre sí. Tres piezas, y con esas tres piezas ya tienes todo el juego.

La primera es el nodo. Un nodo es una cosa. En nuestro caso, un nodo puede ser una nota, una entidad (Docker, SQLite, Nginx, Rust, Python) o una etiqueta. La segunda es la arista, que yo prefiero llamar relación o línea, porque es eso, la línea que une dos nodos. Y la tercera es el peso, porque no todas las relaciones son igual de fuertes. No es lo mismo una conexión entre dos conceptos que el sistema reconoce con total seguridad, que una entre dos menciones dudosas que apenas si están claras. El peso mide esa fuerza del vínculo.

Y ahora la parte que a mí me parece mágica, entre comillas. Esa estructura no la escribes tú. No vas etiquetando a mano, nota por nota, diciendo que esta se relaciona con aquella. El sistema la genera solo, leyendo tus .md. Tú aportas las notas y el motor saca de ellas las entidades y las conexiones.

Te lo dibujo mentalmente. Imagina que tengo una nota donde hablo de Docker y de Nginx. Y otra donde hablo de Nginx como proxy inverso. Y otra donde aparece certbot para los certificados. El sistema detecta que Docker y Nginx aparecen en el mismo fragmento, y los conecta. Detecta que Nginx y proxy inverso aparecen juntos, y los conecta. Y así va tejiendo una red en la que, sin que yo lo haya decidido, Docker acaba relacionado con el balanceo de carga pasando por Nginx, por proxy inverso y por certbot.

Fíjate en el nombre de la relación que usa por defecto, co_occurs_with, aparece junto a. Nada más elegante y nada más potente. Dos entidades que salen en el mismo fragmento de texto se conectan entre sí. No necesito entender qué relación semántica exacta hay entre ellas, basta con que compartan espacio en una nota para que queden enlazadas. Y de esa simplicidad sale la potencia.

La gracia está en lo que no aparece junto

Aquí está el detalle que a mí me hizo levantar las cejas. Con el grafo delante, resulta que Docker y SQLite nunca aparecen juntos en ninguna nota. Ni una sola. Y a primera vista no tienen nada que ver, uno orquesta contenedores y el otro es una base de datos embebida. Y sin embargo, el grafo te dice que están a un par de saltos, porque has montado un contenedor de Docker que dentro lleva un SQLite, o porque has hablado de volúmenes. Esa información, la de que dos conceptos están conectados por un camino aunque nunca compartan una nota, es exactamente lo que la búsqueda por palabras jamás te habría dado.

¿Te acuerdas de la frase de antes, la de que tienes el conocimiento pero no el mapa? Pues ahora tiene su versión definitiva. Los vectores te dicen qué se parece; el grafo te dice cómo se conecta. Esas dos cosas juntas, la similitud semántica y la estructura de relaciones, son el GraphRAG. Ni vectores solos, ni grafo solo, los dos a la vez.

Un apunte de honestidad técnica, porque no quiero que salgas de aquí con una idea incompleta. Un grafo de conocimiento real tiene más tipos de arista, notas que mencionan entidades, notas que llevan etiquetas, notas que pertenecen a un tema. Todo eso lo dejamos para el segundo episodio, porque merece su propio rato. Hoy me quedo con nodo, arista y peso, y con co_occurs_with ya tienes el 80% de la potencia.

Un único binario en Rust, con Ollama por debajo

Vale, suficiente teoría. Vamos a tocarlo, porque de nada sirve entender la idea si no la ves funcionar. Y lo primero que quiero que sepas es que esto no es Python. No hay que crear un entorno virtual, ni instalar dependencias, ni levantar ningún servidor web, ni pelearse con versiones. Es un único binario en Rust llamado graphrag.

La instalación es una línea, porque el proyecto está publicado en crates.io.

cargo install graphrag-search

Fíjate en el detalle, el paquete se llama graphrag-search porque el nombre graphrag ya estaba pillado en crates.io, pero el binario que te queda instalado se llama, cómo no, graphrag. Ahora mismo va por la versión 0.2.12. Y pesa unos 12 MB en total, con SQLite compilado estáticamente dentro, así que no necesita ninguna librería del sistema. Lo copias a un equipo, lo ejecutas y funciona.

Lo segundo que necesitas es Ollama, porque toda la inteligencia del proyecto pasa por ahí, tanto los embeddings como la extracción de entidades. Y aquí hay una decisión de diseño que a mí me parece la correcta, aunque no guste a todo el mundo. No hay plan B. No hay embeddings sintéticos, no hay modo sin IA. Si no hay modelo, no hay magia. Todo local, todo en tu máquina, eso sí, que es lo que de verdad importa.

ollama serve
ollama pull nomic-embed-text
ollama pull llama3.2:3b

Con nomic-embed-text para embeber y llama3.2:3b para extraer entidades tienes la configuración mínima, la que funciona hasta en un portátil modesto, sin GPU, tirando de CPU. Si tienes una gráfica decente, puedes subir a bge-m3 para los embeddings y a gemma4:e2b para las entidades, y te dará más calidad a cambio de más VRAM. En mi caso particular, tengo una combinación montada con bge-m3 y llama3.2:3b. Y si quieres ahorrarte el trabajo de instalar Ollama y descargar los modelos a mano, he dejado un pequeño script de preparación que lo hace todo, lo tienes en el gist que enlazo al final del artículo.

La configuración vive en un fichero TOML, ~/.config/graphrag/config.toml, y todos los campos son opcionales. Los flags de línea de comandos siempre tienen prioridad sobre el fichero, así que el config te sirve para fijar tus valores por defecto y luego los vas sobreescribiendo cuando te apetece.

db = "demo.db"
ollama_url = "http://localhost:11434"
embed_model = "bge-m3:latest"
ner_model = "llama3.2:3b"
summary_model = "llama3.2:3b"
k = 5
depth = 2
alpha = 0.7
notes_dir = ""
num_threads = 4

Hay un detalle del config que conviene conocer para no volverse loco, y es lo que en la documentación llamamos el sentinel de la base de datos. Si tú no indicas la base de datos, o escribes literalmente graphrag.db, la herramienta usa el valor del campo db de tu configuración. O sea, que un graphrag search a secas no busca necesariamente en un archivo graphrag.db del directorio actual, sino en el que tengas configurado. Para forzar una ruta, la pasas explícita y listo.

La demo en menos de dos minutos

Y ahora sí, la demo. Un solo comando y tienes un grafo con datos delante de tus narices.

graphrag seed demo.db

Esto te crea una base de datos SQLite de demostración, el archivo demo.db, con 44 nodos repartidos en 24 entidades y 20 notas, y unas 113 aristas. Y un detalle importante, la demo ya nace buscable, porque cada nota se guarda con su embedding. Ah, y si Ollama no está levantado, seed falla y no te deja ni un fichero a medias. Es atómico, o sale todo o no sale nada.

Vamos a mirar qué hay dentro. Primero las estadísticas.

graphrag stats demo.db

Y la salida real es esta.

📊 Estadísticas del grafo:
├── Nodos totales:     44
├── Notas:             20
├── Entidades:         24
├── Tags:              0
├── Aristas:           113
├── Chunks:            20
└── Con embeddings:    20

Aquí quiero señalar algo honesto y útil. stats no necesita Ollama, trabaja sobre datos que ya están en la base de datos. Lo mismo pasa con fts, con graph, con path y con map. Es decir, una vez construido el grafo, puedes explorarlo entero aunque tengas Ollama apagado. Solo search y ask necesitan el modelo vivo, porque tienen que embeber tu consulta. Ese matiz es importante para entender dónde está el coste real de la herramienta.

Búsqueda textual de toda la vida

Empecemos por lo de siempre, la búsqueda textual, por si sabes exactamente qué palabra buscas.

graphrag fts "Python" demo.db
📄 BÚSQUEDA FTS5: 'Python'
──────────────────────────────────────────────────
       -1.390  [note    ] Python para scripting (Python para scripting)  (vecinos: 0)
       -1.390  [note    ] SQLite con Python (SQLite con Python)  (vecinos: 0)
       -1.390  [note    ] Rust vs Python (Rust vs Python)  (vecinos: 0)
       -1.021  [note    ] FastAPI: APIs modernas (FastAPI: APIs modernas)  (vecinos: 0)
       -0.907  [note    ] Redis como caché (Redis como caché)  (vecinos: 0)

Fíjate que devuelve solo las notas donde aparece la palabra, y que la puntuación es negativa porque es el rank BM25 que expone SQLite FTS5, su motor de búsqueda de texto completo. Y fíjate también en el vecinos: 0, porque aquí no hay expansión por grafo, es coincidencia literal y punto.

Búsqueda híbrida, donde entra la magia

Y ahora la búsqueda que combina vectores y grafo, la que hace honor al nombre del invento.

graphrag search "Python" demo.db -k 5
🔍 Consulta: 'Python'
   k=5, depth=2, alpha=0.7

🧠 HYBRID SEARCH (depth=2)
──────────────────────────────────────────────────
        1.000  [note    ] Python para scripting (Python para scripting)  (vecinos: 20)
   └── Python para scripting: Python es ideal para automatización. Con SQLAlchemy y pandas puedes procesar datos y persistir en PostgreSQL o SQLite.
        0.939  [note    ] Rust vs Python (Rust vs Python)  (vecinos: 19)
        0.925  [note    ] SQLite con Python (SQLite con Python)  (vecinos: 20)
        0.611  [note    ] FastAPI: APIs modernas (FastAPI: APIs modernas)  (vecinos: 20)
        0.602  [note    ] PostgreSQL avanzado (PostgreSQL avanzado)  (vecinos: 19)

Aquí necesitas Ollama, porque tiene que embeber tu consulta para poder compararla. Pero mira la diferencia con el fts. No te devuelve solo las notas donde sale la palabra Python. Te devuelve notas conectadas por el grafo, a las que jamás habrías llegado buscando esa palabra. Y además, debajo de las notas, te lista las entidades que ha encontrado por el camino y los vecinos a uno y a dos saltos. En esta consulta concreta salen vecinos de todo tipo, desde SQLAlchemy y pandas a un primer salto, hasta Docker y Embeddings a dos saltos. Eso es el grafo tirando de los hilos.

La prueba del algodón, fastapi junto y separado

Hay una prueba que me encanta porque deja muy claro qué está pasando por debajo. En la búsqueda textual, fts "fastapi" escrito junto encuentra la nota, pero fts "fast api" escrito separado no encuentra nada, porque es coincidencia literal. En cambio con search da igual cómo lo escribas, junto o separado, porque no busca la cadena de texto, busca el significado. Embebe tu consulta, calcula su vector y trae las notas conectadas. Esa es la diferencia entre buscar letras y buscar ideas.

Rutas y relaciones, el momento de las cejas levantadas

Llegamos a la parte que a mí me hizo levantar las cejas la primera vez que la vi. El comando path te dice cómo se conectan dos conceptos, cuál es el camino más corto entre ellos dentro de tu grafo de conocimiento.

graphrag path "Docker" "SQLite" demo.db

Y la respuesta real es esta ruta.

🛤️  Camino más corto: 'Docker' → 'SQLite'
   Docker → FastAPI: APIs modernas → Python → SQLite

Para un segundo, porque esto merece que lo mires con calma. Docker y SQLite no aparecen juntos en ninguna nota de la demo, y a primera vista no tienen nada que ver, uno orquesta contenedores y el otro es una base de datos embebida. Y sin embargo, el grafo te da la vuelta completa pasando por la nota FastAPI: APIs modernas, que precisamente se despliega con Docker, y por Python, que es el lenguaje que ata ambos mundos. Eso es exactamente lo que grep no te va a dar nunca. Ni en un millón de búsquedas.

Y otro ejemplo que me gusta enseñar, porque encadena aún más piezas.

graphrag path "Prometheus" "SQLite" demo.db
🛤️  Camino más corto: 'Prometheus' → 'SQLite'
   Prometheus → Traefik → FastAPI: APIs modernas → Python → SQLite

Prometheus, que es monitorización, acaba relacionado con SQLite pasando por Traefik como proxy, por FastAPI y por Python. Ese camino no lo has escrito tú en ningún sitio, lo ha descubierto el sistema leyendo tus notas.

Ojo con un detalle práctico que me preguntáis siempre. En path la opción de profundidad es -m, no -d. Es una de esas pequeñas trampas del CLI que te hacen rascarte la cabeza un rato si no lo sabes. Y ya que estamos, el comando mcp recibe la base de datos con --db, no como argumento posicional, por si lo integras con asistentes externos. Son detalles, pero ahorran disgustos.

El vecindario de un concepto

Sigamos. Quiero ver qué hay alrededor de un concepto, su vecindario, la estructura local del grafo.

graphrag graph "Docker" demo.db -d 2

Y aquí -d sí es la profundidad, como era de esperar. Dos saltos desde Docker te devuelven vecinos de todo tipo. Conceptos como Namespaces, Cgroups, Embeddings, Linux, AppArmor o Seccomp. Y notas como Kubernetes: orquestación, Nginx como proxy o Traefik como reverse proxy. Ahí ves cómo se organiza tu conocimiento sin que tú lo hayas decidido conscientemente. Y si quieres ver la distancia en acción, con otro nodo que tenga más saltos, un graph "Python" demo.db -d 1 te muestra vecinos a un solo salto, y ahí ya ves la diferencia entre estar pegado y estar cerca.

El mapa en la terminal

Y para rematar la demo, el mapa conceptual interactivo, directamente en tu terminal, sin salir del shell.

graphrag map demo.db

Es una interfaz TUI, una terminal user interface, donde puedes navegar entre los nodos con las flechas o con hjkl si eres de los míos, pulsar Enter para ver los detalles de un nodo en el panel derecho, pulsar t para ir filtrando entre notas, entidades y etiquetas, y usar / para buscar por nombre. Y si quieres abrirlo centrado en un nodo concreto, con graphrag map --from Docker --depth 3 demo.db te planta el subgrafo de ese concepto directamente.

Y aquí te tengo que ser sincero, porque no todo va a ser perfección. La TUI todavía se ve bastante liosa, demasiado mezclada, con mucho nodo junto y las relaciones difíciles de seguir a simple vista. Reconozco que tengo que trabajarla un poco más para que se vea de una manera sencilla. Aun así, sirve perfectamente para mostrar el potencial del invento, para darte cuenta de cómo has organizado tu conocimiento sin saberlo. Y como herramienta de exploración, engancha. Dos minutos de demo y ya has visto el grafo nacer, buscarlo, recorrerlo y dibujarlo.

Un binario, todo local, y la segunda parte

Déjame que te cuente por qué esta arquitectura me importa tanto, porque no es un detalle de ingeniería, es una postura. Es un único binario en Rust, de unos 12 MB. SQLite va compilado estáticamente dentro, así que no necesitas librerías del sistema, ni Python, ni npm, ni contenedores, ni nada parecido. Lo copias a un equipo, lo ejecutas y funciona.

Y es 100% local y privado. Tus notas no salen de tu casa. La IA tampoco, porque Ollama corre en tu propia máquina. Si estás en un avión sin conexión, los comandos que trabajan sobre datos ya construidos funcionan igual, que era una de las cosas que más me pedíais. Eso sí, con la honestidad que ya te he dado más arriba, la parte de IA necesita Ollama vivo. No hay magia sin modelo.

Y la base de datos es un fichero SQLite portátil. Menos de lo que ocupa un MP3, decía la documentación. En mi caso particular, el grafo de mis notas reales pesa unos 500 MB y tiene alrededor de 6.000 artículos indexados. Estamos hablando de menos de un giga que te llevas en un pendrive, lo copias a otra máquina y sigues buscando. Tus notas y su mapa, en un solo archivo.

Recapitulando, porque quiero dejarte las tres ideas clavadas. Una, la búsqueda por palabras te falla justo cuando tu conocimiento crece, porque busca letras, no significado, y encima distingue mayúsculas. Dos, el RAG clásico es una evolución, te da trozos, pero no el mapa, le falta la estructura de relaciones. Y tres, un grafo de conocimiento es nodos, aristas y pesos, y esa estructura se genera sola a partir de tus notas. Y vuelvo, una última vez, a la frase que resume el episodio entero. Los vectores te dicen qué se parece; el grafo te dice cómo se conecta.

La demo es de juguete, y eso es buena señal

Antes de cerrar, una cosa que quiero que te quede clara. La demo que acabo de contarte es de juguete. Veinte notas. Sirve para entender el concepto, no para vivir en ella. Porque lo que de verdad cambia las cosas es construir tu propio grafo, con tus notas, tus siglas, tus nombres raros, tus manías. Y ahí es donde aparecen las preguntas buenas, las que de verdad importan.

¿Cómo troceo mis notas para que los fragmentos tengan sentido y no corten una idea por la mitad? ¿Cómo extraigo entidades de textos que hablan de lo mío, con mis siglas y mis nombres raros, y no de un dominio genérico? ¿Cómo decido qué conexiones merecen la pena y cuáles son simplemente ruido? Todas esas preguntas, y sus respuestas, son el segundo episodio de esta serie, donde construiremos el grafo con tus notas de verdad. Hoy el objetivo era entender qué es el GraphRAG y verlo funcionar. Y eso, te lo puedo asegurar, ya lo hemos hecho.

Y no me quiero despedir sin contarte por qué estoy tan metido en todo esto. Porque no es un experimento suelto, estoy utilizando este motor para ese asistente personal que estoy implementando y del que te he hablado en episodios anteriores. Ver cómo tus propias notas se conectan solas, sin que tú hayas hecho el trabajo de etiquetarlas a mano, es una de esas cosas que te reconcilian con la informática. Y si me apuras, es un pequeño paso más para dejar de perder tiempo buscando y empezar a encontrarlo todo.

Así que la llamada a la acción de hoy es sencilla y no te cuesta nada. Ve a las notas del episodio, monta tu carpeta de notas Markdown, prepara Ollama con los modelos mínimos y prueba la demo. El lunes que viene la llenamos de verdad, con tus notas. Y si te ha gustado, comparte el episodio, déjame un comentario con la conexión más rara que esconde tu cerebro digital, y suscríbete para no perderte la segunda parte. Porque la vida son dos días y uno ya ha pasado, así que disfrútala, y si puede ser con Linux y con un buen grafo de conocimiento, mejor que mejor. 🐧

Más información

Deja una respuesta