EDVAL 1 · Generación de Activos de Conocimiento

1 · Resumen del proyecto

EDVAL 1 se enmarca en EDNEL — Espacio de Datos de la Nueva Economía de la Lengua —, infraestructura tecnológica que habilita el EDVAL (Espacio de Datos Valle de la Lengua), ecosistema federado, soberano e interoperable para compartir corpus, recursos léxicos, modelos de IA y servicios de datos en español. Está financiado por NextGenerationEU (PRTR), promovido por el Gobierno de La Rioja a través de FTR y CNIE, y ejecutado por la UTE EDNEL (Telefónica, Hiberus-Osaba, UNIR, GNOSS).

Actores del escenario

PROXX-REA

Proveedor

Organismo público que ingesta los repositorios abiertos y construye el Corpus como activo de datos publicado en EDVAL.

UXX-SCHOOL

Consumidor

Institución académica que solicita un activo de conocimiento. Ejemplo canónico: contenidos para un Máster en Ciberseguridad.

EDVAL

Catalizador

Espacio de datos federado · registro y publicación. Sobre SIMPL-Open 2.4.0 · Gaia-X · DSSC v2.0 · DCAT v3 · LanguageDCAT-AP v0.9.1 · ODRL 2.2.

2 · Arquitectura de sistemas (despliegue)

¿Cuántos servidores hacen falta? Hay dos escenarios planteados, ambos compatibles con el diseño funcional del README §3 y con el principio de evolución progresiva del B9.D01 §5.1.

Escenario A — Demostrador / MVP

Recomendado para arrancar 1 servidor

Un único VPS Arsys aloja todo el stack. Es el escenario que se está montando ahora mismo sobre este servidor (8 vCPU AMD EPYC, 15 GB RAM, 464 GB SSD).

┌──────────── VPS-EDVAL1-MONO (este servidor, 82.223.64.150) ────────────┐
│                                                                        │
│  nginx :443  ──┬─►  Documentación estática (esta web)                  │
│                └─►  /api  ──►  FastAPI (capa explotación RAG)          │
│                                 │                                      │
│                                 ├──►  Retriever  ──►  Qdrant           │
│                                 ├──►  PostgreSQL + pgvector            │
│                                 └──►  LLMProvider (OpenAI / Azure API) │
│                                                                        │
│  ETL workers (Docker)  ──►  ingesta · catalogación · chunking · embed. │
│  Datos: /var/lib/edval1/{corpus,vector,postgres}                       │
│  Cockpit :9090  ──►  panel administración                              │
└────────────────────────────────────────────────────────────────────────┘

Estimación de RAM

Componente	RAM
Nginx	~50 MB
FastAPI	~500 MB
PostgreSQL + pgvector	~1 GB
Qdrant (10k docs)	~3-4 GB
ETL en bursts	~2-4 GB
Total típico	~7-9 GB / 15 GB

Disco

Concepto	Tamaño
Sistema	~3 GB
10.000 PDFs	20-100 GB
Vectores	~2 GB
BD documental	~10 GB
Holgura	>300 GB / 464 GB

Conclusión: el servidor actual sobra para el demostrador siempre que el LLM se invoque por API. Correr el LLM en local saturaría la RAM y exigiría GPU.

Escenario B — Producción / fase evolutiva

Cuando el MVP funcione 3 servidores

Tres servidores con responsabilidades separadas. Encaja con el principio nº 6 del B9.D01 (evolución progresiva) y con el discurso de soberanía digital del proyecto EDNEL.

┌─ VPS-FRONT (2 vCPU / 4 GB) ──┐    ┌─ VPS-BACK (8 vCPU / 16 GB, este reseteado) ─┐
│                              │    │                                              │
│  nginx + TLS Let's Encrypt   │◄──►│  FastAPI · PostgreSQL · Qdrant · ETL workers │
│  Plesk (opcional, gestión    │    │  Volúmenes persistentes                      │
│   visual de dominios/SSL)    │    │                                              │
└──────────────────────────────┘    └──────────────────────────────────────────────┘
                                                       │
                                                       ▼  (sólo si se exige soberanía)
                                  ┌─ VPS-LLM (Cloud GPU Arsys / similar) ─┐
                                  │  Llama 3 / Mistral local              │
                                  │  Inferencia interna sin terceros      │
                                  └───────────────────────────────────────┘

VPS-FRONT

Servidor pequeño (Arsys VPS 120 GB ≈ 10 €/mes)
Aquí sí tiene sentido reaprovechar Plesk
Termina TLS y registra dominio (ej. edval1.cnie.es)
Reverse proxy hacia VPS-BACK

VPS-BACK

Este mismo servidor, reseteado y reprovisionado sin Plesk
Sólo lógica de aplicación + datos persistentes
Acceso restringido a la IP del FRONT (firewall)
Backups del corpus y de la BD de embeddings

VPS-LLM opcional

Solo si se sustituye OpenAI/Azure por modelo soberano
Encaja con el discurso de NextGenerationEU/PRTR
Arsys Cloud GPU o Hugging Face Endpoints

Recomendación: no saltes al escenario B hasta que el demostrador funcione end-to-end. Cuando llegue el momento, haz reset de este VPS y reprovisiona como VPS-BACK, y compra un VPS pequeño para FRONT con Plesk.

3 · Capas funcionales (lógicas)

Con independencia del despliegue físico, el código se organiza en cuatro capas más un dominio transversal. Reproduce la arquitectura del README §3 y §6.

Capa de adquisición

edval1.acquisition

IngestionModule, RepositorySource, OpenRepositoryConnector. Obtiene documentos de repositorios abiertos vía OAI-PMH, REST o scraping controlado. Hoy autónoma; mañana sustituible por un EDC connector.

Capa de procesamiento

edval1.processing

ETLPipeline, Cataloguer (LanguageDCAT-AP), Chunker, EmbeddingProvider, VectorStore.

Capa de explotación (RAG)

edval1.exploitation

UserRequest → QueryInterpreter → Retriever → RAGOrchestrator → LLMProvider → ContentValidator → KnowledgeAssetBuilder.

Capa de publicación

edval1.publication

LocalPublisher (MVP) ↔ EDCPublisher (stub para conector EDC futuro). Publica el KnowledgeAsset de vuelta a EDVAL como nuevo activo.

Dominio transversal — `edval1.domain`

Entidades alineadas con LanguageDCAT-AP v0.9.1 y ODRL 2.2: Participant, DataProvider, DataConsumer, Corpus, KnowledgeAsset, Document, Chunk, Embedding, LanguageDCATMetadata, ODRLPolicy, Credential, Provenance.

4 · Stack tecnológico

Capa	Tecnología	Por qué
Lenguaje	Python 3.12	Ecosistema RAG maduro, alineado con SDK B1.E08
Orquestación RAG	LangChain o LlamaIndex	Retrievers, prompts, chains
Embeddings	`sentence-transformers` · API	Configurable vía `EmbeddingProvider`
VectorStore	Qdrant · pgvector	Ambos disponibles vía Docker
DocumentStore	PostgreSQL 16 + JSONB	LanguageDCAT-AP como JSON-LD
ETL	Unstructured.io · pypdf · BeautifulSoup	PDF / HTML / texto plano
LLM	OpenAI · Azure OpenAI · Llama/Mistral local	Intercambiable vía `LLMProvider`
API	FastAPI	OpenAPI 3.0 (B1.E08)
Despliegue	Docker + Compose · Kubernetes/Helm prod	Alineado con B1.E03
Tests	pytest + pytest-asyncio	—

5 · Estado del servidor

Componente	Versión	Estado
OS	Ubuntu 24.04.4 LTS · kernel 6.8	activo
Docker Engine	29.4.1 · Compose v5.1.3	activo
Python	3.12.3	instalado
Nginx	1.24.0	activo · sirve esta web
Cockpit	v314	activo · :9090
fail2ban	—	activo
UFW	—	activo (22, 80, 443, 9090)
Plesk · Apache · MariaDB · correo	—	desinstalados
EDVAL1 src/	—	por implementar

6 · Roadmap

Servidor
Datalake 10k
ETL + Cat.
Embeddings
RAG
Validator
API + Pub.
Docker
EDC

Fase	Hito	Estado
02	Servidor Arsys aprovisionado y limpio	hecho
03	10.000 documentos descargados (datalake)	hecho
04	ETL + Cataloguer (JSON-LD + LanguageDCAT-AP)	pendiente
05	Chunking + Embeddings + VectorStore	pendiente
06	Retriever + RAGOrchestrator + LLMProvider	pendiente
07	ContentValidator + KnowledgeAssetBuilder	pendiente
08	LocalPublisher + API FastAPI	pendiente
09	Dockerización + docker-compose	pendiente
10	EDCPublisher (cuando SIMPL libere DCP/Wallet)	evolutivo

Panel de control del servidor

Gestión de servicios, contenedores Docker, almacenamiento, logs, terminal y red — vía Cockpit. Usuario root · contraseña del sistema. El navegador mostrará un aviso por TLS auto-firmado.

Abrir panel →