Pipeline de Markdown a Grafo de Conocimiento

Experimento personal, no un proyecto de producción para un cliente.

Qué hace

Un documento ya tiene una estructura: un tema principal, secciones y el texto dentro de ellas. Este experimento hace explícitas esas conexiones en Neo4j, una base de datos que almacena información conectada.

Convierte los encabezados de Markdown en un mapa conectado de temas y secciones. Así se puede seguir una conexión desde un tema hasta sus secciones, o desde una sección hasta su tema.

La pregunta detrás de este trabajo es sencilla: ¿cómo puede el software aprovechar la estructura que ya tiene la documentación? Es una pequeña exploración de esa pregunta, no un asistente de IA terminado.

Un ejemplo pequeño

Este documento de soporte es inventado y fue procesado por el parser real, el código que lee y separa su contenido. No es material de un cliente y la política solo sirve como ejemplo. Se muestra en inglés para que coincida con el archivo de entrada y su resultado.

# Customer support
Information for the support team.

## Returns policy
Customers can request a return within 30 days.

## Shipping questions
The support team checks delivery updates.

Del documento al mapa conectado

Customer support
├── Returns policy
└── Shipping questions

Ilustración de la estructura esperada del grafo, no una captura de una base de datos en ejecución. El importador define conexiones del tema a cada sección y de vuelta al tema. No descubre relaciones nuevas más allá de esta estructura del documento.

Al ejecutar el parser con este ejemplo, el resultado fue un tema y dos secciones, conservando el texto bajo cada encabezado:

• Tema: Customer support (soporte al cliente), con la descripción “Information for the support team.”
• Sección: Returns policy (política de devoluciones), con el texto “Customers can request a return within 30 days.”
• Sección: Shipping questions (preguntas sobre envíos), con el texto “The support team checks delivery updates.”

Puedes revisar el archivo Markdown de entrada y la salida real del parser (JSON). Son los archivos de este ejemplo; el JSON es la salida del parser, no una exportación de la base de datos.

Qué demuestra y cuáles son sus límites

Lo demostrado: el parser separa el tema principal, las secciones y su texto. El código de importación a Neo4j define cómo guardarlos y conectar cada sección con su tema.

Lo que no se demuestra: un asistente terminado, mejores resultados de búsqueda, ahorro de tiempo para una empresa ni resultados de una implementación para un cliente. Este ejemplo comprueba el procesamiento del documento; no prueba una base de datos Neo4j en ejecución.

También hay límites prácticos:

• El parser espera un formato sencillo: un encabezado principal (#) y encabezados de sección (##). No es un parser de Markdown de uso general.
• Los identificadores se obtienen de los encabezados. Secciones con el mismo nombre en documentos distintos pueden compartir una entrada en Neo4j. Habría que resolverlo antes de usar documentos variados de una empresa.
• Las referencias a archivos se guardan como propiedades de las secciones, no como conexiones independientes del grafo.
• Crear una búsqueda útil o un asistente sobre esta base requiere más trabajo y evaluación. Un grafo no es automáticamente mejor que una búsqueda más sencilla.

Detalles técnicos

El pipeline utiliza Node.js, TypeScript y Neo4j:

1. Lee archivos Markdown y extrae el tema principal y las secciones.
2. Guarda el contenido procesado como JSON.
3. Envía ese contenido al importador de Neo4j.

En el modelo de la base de datos, un tema se llama Concept y una sección se llama Chunk. El código de importación define estas relaciones:

(Concept)-[:HAS]->(Chunk)
(Chunk)-[:PART_OF]->(Concept)

El ejemplo se comprobó con el parser y el importador de Neo4j en la revisión dc2ffa5.

Código fuente de ds-parse en GitHub.

¿Podría relacionarse con tu empresa?

¿Estás explorando cómo usar IA con la documentación de tu empresa?

Puedo ayudarte a evaluar el problema y decidir si tiene sentido una búsqueda sencilla, un grafo u otra solución. El punto de partida es lo que tu equipo necesita, no elegir primero una base de datos.

Hablemos de tu caso →

También puedes ver mis servicios de consultoría o conocer mi trabajo en Ketzai, un ejemplo separado de mi trabajo en producción.