Corrigiendo RAG con una ontología y un grafo de conocimiento en documentos de semiconductores
Los documentos de EDA para semiconductores cuentan con una ontología RDF/OWL, un grafo de conocimiento Neo4j y una recuperación restringida por ontologías, lo que reduce en un 30 por ciento las preguntas adicionales en el sistema RAG.
Fuentes: How I Built a Semantic Layer to Ground Our RAG System…And Why Ontology Was the Missing Piece
Dónde falla el RAG tradicional
Un prototipo inicial de generación mejorada mediante recuperación de información sobre documentación de productos suele parecer prometedor. Se utiliza un almacén de vectores, los documentos se dividen en fragmentos, se ejecutan algunas consultas y las respuestas parecen plausibles. Luego, un ingeniero de verificación pregunta qué metodología utilizar para realizar una verificación consciente del consumo energético en un bloque determinado, y el sistema responde, con total confianza, sobre la metodología de verificación funcional. El contenido es preciso según sus propios criterios, pero incorrecto para la pregunta planteada.
La causa radica en el vocabulario. En la verificación de semiconductores, “metodología” no es una palabra cotidiana. Se refiere a enfoques específicos de verificación, cada uno vinculado a herramientas, etapas y artefactos de ejecución particulares. El sistema recuperó texto, pero no conocimiento. Eso lo convierte en un problema de significado y no en uno de recuperación, y un modelo de embedding mejor no lo solucionaría. Una capa semántica sí lo hace. A continuación se explica cómo se diseña y construye tal capa para un conjunto de documentación EDA: la ontología, el grafo de conocimiento, la conexión con RAG y los resultados medidos.
La documentación como un desierto de conocimiento
El escenario es un software de verificación empresarial que cuenta con miles de temas en formato DITA XML distribuidos en varias líneas de productos, abarcando la configuración de herramientas, flujos de trabajo de ejecución y orientación metodológica. El material existe, pero en formato de texto plano en lugar de conocimiento estructurado. Las etapas de verificación, las metodologías y las herramientas se encuentran en documentos separados y solo están vinculadas por lo que ya sabe el lector. Un ingeniero experimentado con diez años de experiencia en el área puede manejarlo, mientras que un modelo de lenguaje grande que busca la información adecuada se enfrenta a un verdadero campo minado.
El objetivo era encontrar una solución que satisficiera varias necesidades al mismo tiempo: RAG, búsqueda empresarial, descubrimiento de contenido y gobernanza a largo plazo del contenido.
Enmarcar primero el problema
Antes de escribir cualquier código de ontología, se llevaron a cabo semanas de conversaciones con los gerentes de producto, expertos en verificación, responsables de documentación, ingenieros de búsqueda y el equipo de ciencia de datos detrás del asistente GenAI. Tres preguntas guiaron esas conversaciones.
Primero, ¿qué resultados empresariales son importantes? Las respuestas fueron una mayor precisión en las búsquedas, una capa de referencia canónica para los asistentes LLM y datos unificados entre las líneas de producto. Segundo, ¿cómo se manifiesta el fracaso actualmente? Las búsquedas por palabras clave devuelven resultados irrelevantes, los usuarios envían consultas adicionales porque la primera respuesta no captó el contexto, y el enlace manual de contenido no es suficiente. Tercero, ¿cómo sería el éxito? El sistema de recuperación debería entender que una consulta sobre verificación dinámica de diseños gestionados eléctricamente requiere contenido vinculado a una metodología específica, en una etapa de verificación concreta, que utilice herramientas particulares, y no simplemente cualquier documento que contenga esas palabras clave.
Esta base previene la sobrecarga ontológica, es decir, la costumbre de modelar todo lo que parece interesante desde el punto de vista intelectual en lugar de lo que realmente necesita la empresa.
Descubriendo conceptos y diseñando la ontología
El diseño de la ontología comienza con el descubrimiento de conocimientos, no con Protégé ni con un archivo Turtle. Cuatro fuentes aportaron información al proceso:
- Entrevistas con ingenieros de verificación, quienes describieron cómo piensan acerca de las relaciones entre las herramientas, el orden de ejecución y los puntos de decisión, lo cual difiere de la forma en que funcionan las herramientas en realidad
- Documentación existente e interfaces de herramientas, cuyos términos recurrentes revelaron conceptos que habían permanecido estables durante años
- Registros, archivos de configuración y definiciones de pipelines, que mostraron los verdaderos vínculos entre herramientas, etapas y resultados, y a menudo contradecían la documentación
El resultado fue un conjunto básico de conceptos del dominio estables, en esencia una taxonomía, que se registró primero en Excel a propósito. El trabajo de ontología es colaborativo, y las personas que deben revisar el modelo, los expertos en el dominio y los gerentes de producto, no leen Turtle. Una hoja de cálculo les permite validarlo y perfeccionarlo, y crear un entendimiento compartido, mucho antes de que comience la codificación formal.
Una vez que el modelo se consolidó tras varias rondas de revisión, se formalizó con estándares de la web semántica:
- RDF expresa cada entidad y relación como triples
- OWL proporciona jerarquías de clases, restricciones de propiedades y reglas lógicas
- SKOS estandariza la terminología en todas las líneas de productos a través de vocabularios controlados
- Schematron verifica el uso correcto de la ontología durante la creación en Oxygen XML
La propia ontología se encuentra en archivos TTL, mientras que las reglas de Schematron se integran directamente en el entorno de creación. Por lo tanto, los autores no pueden introducir conceptos que alteren la ontología, de modo que la gobernanza forma parte del flujo de trabajo y no es algo que se considere posteriormente. Cada mapeo se aplica mediante metadatos en formato Prolog en archivos XML DITA y vocabularios controlados, sin etiquetas libres ni un enfoque de “más o menos suficiente”.
La arquitectura del grafo de conocimiento
La ontología necesita un lugar donde residir, un grafo que pueda consultarse y recorrerse. El diseño se divide en capas:
- Capa de esquema: definiciones de la ontología en archivos TTL
- Capa de terminología: vocabulario basado en SKOS
- Capa de instancias: triples RDF generados a partir de los metadatos del contenido
- Capa de infraestructura: Neo4j para el almacenamiento y las consultas
Alrededor de esas capas se encuentran pipelines de ingestión semántica que convierten el contenido creado en triples listos para el grafo y los cargan en Neo4j, así como APIs de consulta y recuperación que exponen el grafo a los usuarios, como el pipeline RAG, además de la infraestructura en la nube de Azure para escalar y integrarse con los servicios de la plataforma existente.
El pipeline que va desde la creación del contenido hasta el grafo es lo que eleva este enfoque más allá de ser simplemente un ejercicio de ontología. Los autores escriben en DITA utilizando Oxygen XML. Schematron garantiza que los metadatos cumplan con las normas de la ontología mientras escriben. El contenido se publica a través de Adobe Experience Manager. Los metadatos semánticos permanecen intactos durante todo este proceso y son ingeridos en Neo4j, donde los sistemas de búsqueda, análisis e inteligencia artificial pueden consultarlos. Se trata de un control arquitectónico completo sobre todo el flujo de datos, desde la herramienta de creación hasta el grafo y, finalmente, la capa de API.
Conectar la capa semántica con RAG
Aquí es donde el esfuerzo da sus frutos. El RAG estándar fragmenta los documentos, incrusta esos fragmentos, los almacena en una base de datos vectorial, los recupera por similitud y envía los resultados a un LLM. Funciona, pero no comprende el significado, y tres modos de fallo se repiten constantemente:
- Confusión de contexto, en la que la recuperación encuentra el concepto correcto en el contexto equivocado, como la discrepancia en la fase de verificación descrita anteriormente
- Discrepancia de vocabulario, donde los ingenieros utilizan abreviaturas mientras que la documentación emplea términos formales, lo que hace que se pierda contenido relevante
- Alucinaciones por ambigüedad, en las que términos poco claros en un fragmento permiten que el LLM llene los vacíos con conocimientos del dominio plausibles pero incorrectos
Con el grafo de conocimiento como capa de anclaje, la recuperación cambia de cuatro maneras.
Las reglas de la ontología limitan qué se obtiene al realizar la búsqueda. Cuando una consulta menciona una metodología de verificación, primero se resuelve el término con respecto a la ontología y luego la búsqueda se limita al contenido etiquetado con esa metodología y sus relaciones válidas. La búsqueda vectorial sigue ejecutándose, pero sobre un subconjunto filtrado semánticamente.
Se aplica un vocabulario canónico. Las consultas de los usuarios se traducen a términos controlados antes de la búsqueda, de modo que “power-aware sim” se convierte en el término formal para simulación consciente de la energía, y el contenido adecuado se muestra independientemente de cómo formule la pregunta el ingeniero.
Los fragmentos siguen los límites de la ontología en lugar de tener un tamaño fijo. Un pasaje sobre el papel de una herramienta en una etapa de verificación se mantiene completo y no se interrumpe a mitad de concepto.
Se filtran las combinaciones inválidas. La ontología indica qué combinaciones de herramientas, metodologías y etapas son legítimas, por lo que los fragmentos que implican una combinación inválida son degradados o descartados antes de que el LLM los vea.
Los beneficios se manifestaron de inmediato. Las respuestas se basan en contenido verificado y etiquetado con ontología, en lugar de en las conjeturas del modelo sobre la verificación de semiconductores. Al restringir lo que puede ver el modelo, se eliminó un tipo de alucinaciones causadas por búsquedas ambiguas o sin contexto. Cada fragmento recuperado lleva metadatos de ontología, por lo que el sistema puede explicar su elección: qué entidad, qué relación, qué restricción. Además, los flujos de trabajo basados en agentes pueden recorrer el grafo para planificar tareas de verificación de múltiples pasos a partir de relaciones reales entre entidades y no solo de la similitud textual.
La pila tecnológica
- Creación de contenido: Oxygen XML con DITA
- Validación y gobernanza: Schematron y Schematron Quick Fix
- Codificación de ontologías: RDF, OWL y SKOS en archivos Turtle
- Gráfico de conocimiento: Neo4j
- Publicación: Adobe Experience Manager
- Nube: Microsoft Azure
- Integración RAG: APIs personalizadas de recuperación que combinan Neo4j y búsqueda vectorial
- Capa de LLM: un asistente GenAI empresarial propietario
Resultados
Después de la implementación, cuatro métricas reflejaron los resultados:
- Las consultas de seguimiento disminuyeron un 30 %. La documentación ahora funciona como una fuente de verdad de alta fidelidad para los asistentes de IA, lo que permite a los usuarios obtener la respuesta correcta desde la primera vez con mucha mayor frecuencia. Esta fue la métrica clave, ya que refleja directamente la calidad de la recuperación de información.
- La reutilización de contenido aumentó un 25 %. Gracias a las etiquetas semánticas y al conocimiento de las relaciones, el mismo contenido puede aparecer en varias líneas de productos sin necesidad de copias manuales.
- El tiempo necesario para crear enlaces manualmente disminuyó en un 60 %. Las funciones de Contenido Relacionado de AEM ahora funcionan mediante grafos, por lo que los enlaces que antes se creaban a mano se generan a partir de relaciones ontológicas. El autoservicio para los usuarios también mejoró en un 25 %.
- Los ciclos de auditoría de contenido manual se redujeron en un 40 %. Las reglas Schematron derivadas de la ontología detectan problemas en Oxygen mientras los autores trabajan, lo que permite mejorar la calidad desde la fase inicial.
Lecciones para proyectos similares
Modela el dominio antes de elegir la tecnología. Los equipos a menudo recurren a Neo4j o a una base de datos vectorial antes incluso de definir cuáles son sus entidades y relaciones. Eso es como construir una casa sin antes dibujar el plano. Dedica tiempo en las fases iniciales a trabajar con hojas de cálculo junto a expertos en el dominio. Aunque no parece tan atractivo, ahí es donde se genera el valor real.
Trate la gobernanza como una estructura. Una ontología sin gobernanza se deteriora rápidamente, ya que cada nuevo autor, producto o caso límite socava la consistencia. Integre la validación en el flujo de trabajo de creación para que se realice de forma automática, en lugar de mediante auditorías periódicas que siempre llegan tarde.
RAG sin semántica es una búsqueda con pasos adicionales. La similitud vectorial es necesaria, pero resulta insuficiente para la recuperación de información a nivel empresarial. Cuando un dominio cuenta con relaciones estructuradas, jerarquías y restricciones, como ocurre en la mayoría de los dominios empresariales, una capa semántica permite pasar de buscar texto similar a encontrar conocimiento relevante.
Mida lo que realmente importa para el negocio. “Construimos un grafo de conocimiento” no es un resultado empresarial. “Las consultas de seguimiento disminuyeron un 30% porque la recuperación de información se volvió más precisa” sí lo es. Cada elección arquitectónica debe estar vinculada a una métrica que las personas fuera del equipo consideren importante.
Qué viene a continuación
La capa semántica es la base y no el límite máximo. La ontología sigue evolucionando, con nuevos conceptos que se prueban, validan y se integran sin alterar la semántica existente, y los avances en herramientas de LLM, la convergencia entre grafos e inteligencia artificial y la arquitectura agente pueden desarrollarse sobre ella. La lección general es que, en la prisa por adoptar la GenAI, la inversión más subestimada no es un modelo mejor ni una ventana de contexto más amplia, sino una base semántica más sólida. Los modelos van y vienen, pero el significado persiste.
Leer más
- Por qué los agentes de análisis de IA necesitan una capa semántica en lugar de SQL en bruto — La conversión de texto a SQL en tablas de almacén en bruto inventa métricas e ignora las reglas de acceso. Vea cómo una capa semántica como Cube, junto con MCP, proporciona a los agentes un significado empresarial estructurado.
- De un enfoque ingenuo a un pipeline RAG en producción para declaraciones 10-K de la SEC: fragmentación, búsqueda híbrida — Por qué un pipeline RAG convencional falló con declaraciones de 10-K de 300 páginas, y las soluciones: fragmentación según secciones, recuperación híbrida, reclasificación con codificador cruzado, validación y citas de metadatos.