mirror of
https://github.com/trustgraph-ai/trustgraph.git
synced 2026-04-26 17:06:22 +02:00
Structure the tech specs directory (#836)
Tech spec some subdirectories for different languages
This commit is contained in:
parent
48da6c5f8b
commit
e7efb673ef
423 changed files with 0 additions and 0 deletions
113
docs/tech-specs/es/architecture-principles.es.md
Normal file
113
docs/tech-specs/es/architecture-principles.es.md
Normal file
|
|
@ -0,0 +1,113 @@
|
|||
---
|
||||
layout: default
|
||||
title: "Fundamentos de la Arquitectura del Gráfico de Conocimiento"
|
||||
parent: "Spanish (Beta)"
|
||||
---
|
||||
|
||||
# Fundamentos de la Arquitectura del Gráfico de Conocimiento
|
||||
|
||||
> **Beta Translation:** This document was translated via Machine Learning and as such may not be 100% accurate. All non-English languages are currently classified as Beta.
|
||||
|
||||
## Fundamento 1: Modelo de Gráfico Sujeto-Predicado-Objeto (SPO)
|
||||
**Decisión**: Adoptar SPO/RDF como el modelo de representación de conocimiento central.
|
||||
|
||||
**Justificación**:
|
||||
Proporciona la máxima flexibilidad e interoperabilidad con las tecnologías de gráficos existentes.
|
||||
Permite la traducción fluida a otros lenguajes de consulta de gráficos (por ejemplo, SPO → Cypher, pero no al revés).
|
||||
Crea una base que "desbloquea muchas" capacidades posteriores.
|
||||
Admite tanto relaciones de nodo a nodo (SPO) como relaciones de nodo a literal (RDF).
|
||||
|
||||
**Implementación**:
|
||||
Estructura de datos central: `node → edge → {node | literal}`
|
||||
Mantener la compatibilidad con los estándares RDF al tiempo que se admiten operaciones SPO extendidas.
|
||||
|
||||
## Fundamento 2: Integración Nativa del Gráfico de Conocimiento con LLM
|
||||
**Decisión**: Optimizar la estructura y las operaciones del gráfico de conocimiento para la interacción con LLM.
|
||||
|
||||
**Justificación**:
|
||||
El caso de uso principal implica que los LLM interactúen con los gráficos de conocimiento.
|
||||
Las opciones de tecnología de gráficos deben priorizar la compatibilidad con LLM por encima de otras consideraciones.
|
||||
Permite flujos de trabajo de procesamiento del lenguaje natural que aprovechan el conocimiento estructurado.
|
||||
|
||||
**Implementación**:
|
||||
Diseñar esquemas de gráficos que los LLM puedan comprender y razonar eficazmente.
|
||||
Optimizar para patrones de interacción comunes con LLM.
|
||||
|
||||
## Fundamento 3: Navegación del Gráfico Basada en Incrustaciones
|
||||
**Decisión**: Implementar un mapeo directo de las consultas de lenguaje natural a los nodos del gráfico a través de incrustaciones.
|
||||
|
||||
**Justificación**:
|
||||
Permite la ruta más sencilla posible desde la consulta de PNL hasta la navegación del gráfico.
|
||||
Evita pasos complejos de generación de consultas intermedias.
|
||||
Proporciona capacidades de búsqueda semántica eficientes dentro de la estructura del gráfico.
|
||||
|
||||
**Implementación**:
|
||||
`NLP Query → Graph Embeddings → Graph Nodes`
|
||||
Mantener representaciones de incrustación para todas las entidades del gráfico.
|
||||
Admitir la coincidencia de similitud semántica directa para la resolución de consultas.
|
||||
|
||||
## Fundamento 4: Resolución de Entidades Distribuidas con Identificadores Deterministas
|
||||
**Decisión**: Admitir la extracción de conocimiento en paralelo con la identificación determinista de entidades (regla del 80%).
|
||||
|
||||
**Justificación**:
|
||||
**Ideal**: La extracción en un solo proceso con visibilidad completa del estado permite una resolución de entidades perfecta.
|
||||
**Realidad**: Los requisitos de escalabilidad exigen capacidades de procesamiento en paralelo.
|
||||
**Compromiso**: Diseñar para la identificación determinista de entidades en procesos distribuidos.
|
||||
|
||||
**Implementación**:
|
||||
Desarrollar mecanismos para generar identificadores consistentes y únicos en diferentes extractores de conocimiento.
|
||||
La misma entidad mencionada en diferentes procesos debe resolverse en el mismo identificador.
|
||||
Reconocer que aproximadamente el 20% de los casos extremos pueden requerir modelos de procesamiento alternativos.
|
||||
Diseñar mecanismos de respaldo para escenarios complejos de resolución de entidades.
|
||||
|
||||
## Fundamento 5: Arquitectura Orientada a Eventos con Publicación-Suscripción
|
||||
**Decisión**: Implementar un sistema de mensajería de publicación-suscripción para la coordinación del sistema.
|
||||
|
||||
**Justificación**:
|
||||
Permite un acoplamiento débil entre los componentes de extracción, almacenamiento y consulta de conocimiento.
|
||||
Admite actualizaciones y notificaciones en tiempo real en todo el sistema.
|
||||
Facilita flujos de trabajo de procesamiento distribuidos y escalables.
|
||||
|
||||
**Implementación**:
|
||||
Coordinación basada en mensajes entre los componentes del sistema.
|
||||
Flujos de eventos para actualizaciones de conocimiento, finalización de la extracción y resultados de consultas.
|
||||
|
||||
## Fundamento 6: Comunicación de Agentes Reentrantes
|
||||
**Decisión**: Admitir operaciones de publicación-suscripción reentrantes para el procesamiento basado en agentes.
|
||||
|
||||
**Justificación**:
|
||||
Permite flujos de trabajo sofisticados de agentes donde los agentes pueden activar y responder entre sí.
|
||||
Admite canalizaciones complejas de procesamiento de conocimiento con varios pasos.
|
||||
Permite patrones de procesamiento recursivos e iterativos.
|
||||
|
||||
**Implementación**:
|
||||
El sistema de publicación-suscripción debe manejar las llamadas reentrantes de forma segura.
|
||||
Mecanismos de coordinación de agentes que previenen bucles infinitos.
|
||||
Soporte para la orquestación de flujos de trabajo de agentes.
|
||||
|
||||
## Fundamento 7: Integración con Almacenes de Datos Columnares
|
||||
**Decisión**: Asegurar la compatibilidad de las consultas con los sistemas de almacenamiento columnar.
|
||||
|
||||
**Justificación**:
|
||||
Permite consultas analíticas eficientes sobre grandes conjuntos de datos de conocimiento.
|
||||
Admite casos de uso de inteligencia empresarial e informes.
|
||||
Une la representación de conocimiento basada en gráficos con los flujos de trabajo analíticos tradicionales.
|
||||
|
||||
**Implementación**:
|
||||
Capa de traducción de consultas: Consultas de gráfico → Consultas de columna.
|
||||
Estrategia de almacenamiento híbrida que admite tanto operaciones de gráfico como cargas de trabajo analíticas.
|
||||
Mantener el rendimiento de las consultas en ambos paradigmas.
|
||||
|
||||
--
|
||||
|
||||
## Resumen de los Principios de la Arquitectura
|
||||
|
||||
1. **Flexibilidad Primero**: El modelo SPO/RDF proporciona la máxima adaptabilidad.
|
||||
2. **Optimización para LLM**: Todas las decisiones de diseño consideran los requisitos de interacción con LLM.
|
||||
3. **Eficiencia Semántica**: Mapeo directo de incrustaciones a nodos para un rendimiento de consulta óptimo.
|
||||
4. **Escalabilidad Pragmática**: Equilibrar la precisión perfecta con el procesamiento distribuido práctico.
|
||||
5. **Coordinación Orientada a Eventos**: La publicación-suscripción permite un acoplamiento débil y la escalabilidad.
|
||||
6. **Amigable para Agentes**: Admite flujos de trabajo complejos de procesamiento basados en agentes.
|
||||
7. **Compatibilidad Analítica**: Une los paradigmas de gráficos y columnas para consultas integrales.
|
||||
|
||||
Estos fundamentos establecen una arquitectura de gráfico de conocimiento que equilibra la rigurosidad teórica con los requisitos prácticos de escalabilidad, optimizada para la integración con LLM y el procesamiento distribuido.
|
||||
Loading…
Add table
Add a link
Reference in a new issue