Document controlled ingestion plan for GStreamer corpus

This commit is contained in:
Paco POR-CORREO 2026-04-09 13:14:28 +02:00
parent 16793ad4dc
commit 60d1b9679d
2 changed files with 201 additions and 0 deletions

View file

@ -50,3 +50,5 @@ Dar continuidad al RAG en `RAG/` a partir del estado actual documentado.
- Comparacion de auditorias del modelo (pre y post cleanup) documentada en `RAG/docs/TEMP_AUDITORIA_MODELO_PRE_CLEANUP.md`, confirmando una ganancia clara en nitidez y precision del RAG al evaluar el codigo. - Comparacion de auditorias del modelo (pre y post cleanup) documentada en `RAG/docs/TEMP_AUDITORIA_MODELO_PRE_CLEANUP.md`, confirmando una ganancia clara en nitidez y precision del RAG al evaluar el codigo.
- Implementacion de ingesta directa de carpetas locales desde el playground: el navegador empaqueta la carpeta en un `.zip` en memoria (filtrando `node_modules`, `dist`, `.git`, etc. con logica nativa) y el backend usa `adm-zip` para extraerla de forma segura en un directorio temporal antes de la ingesta. - Implementacion de ingesta directa de carpetas locales desde el playground: el navegador empaqueta la carpeta en un `.zip` en memoria (filtrando `node_modules`, `dist`, `.git`, etc. con logica nativa) y el backend usa `adm-zip` para extraerla de forma segura en un directorio temporal antes de la ingesta.
- Correccion en `IngestService` (`resolveInputFiles` y `normalizeDocumentKey`) para escanear archivos desde la ruta temporal extraída (`readPath`) en lugar del identificador lógico al subir carpetas completas, evitando error de `ENOENT`. - Correccion en `IngestService` (`resolveInputFiles` y `normalizeDocumentKey`) para escanear archivos desde la ruta temporal extraída (`readPath`) en lugar del identificador lógico al subir carpetas completas, evitando error de `ENOENT`.
- Revision inicial del corpus `/_imports/gstreamer-rag-text` como futura base documental especializada para GStreamer.
- Creacion de `RAG/docs/TASK_INGESTA_GSTREAMER.md` con el plan operativo para ingerirlo bajo un scope unico, validar retrieval y prepararlo para uso posterior con modelo local.

View file

@ -0,0 +1,199 @@
# Task: Ingesta controlada de corpus GStreamer
**Proyecto:** Workspace de tools IA para empresas
**Modulo:** RAG
**Ultima actualizacion:** 2026-04-09
**Ultima modificacion por:** Agente RAG 2
**Estado:** Planificado
---
## Proposito
Preparar una ingesta controlada y verificable de la documentacion oficial de GStreamer para usarla como corpus documental especializado dentro del RAG.
El objetivo final no es solo "cargar docs", sino dejar el corpus listo para:
- hacer `bootstrap` global del dominio GStreamer
- recuperar documentacion oficial de forma fiable
- apoyar a un modelo local en revision y correccion de codigo que use GStreamer
---
## Fuente elegida
Fuente principal confirmada:
```text
/home/pancho/Documentos/Empresa/Desarrollo/IA/_imports/gstreamer-rag-text
```
Motivos:
- la documentacion ya esta normalizada a `.txt`
- la estructura en carpetas y ficheros es mejor que un monolito para retrieval
- permite recuperar mejor por tema, plugin, elemento o manual
- evita mezclar demasiadas secciones distintas en el mismo chunk
---
## Objetivo de modelado del corpus
Todo el corpus debe quedar agrupado bajo un unico scope logico dedicado a GStreamer.
Eso permitira que en el playground aparezca como un scope identificable y seleccionable, en lugar de quedar repartido en multiples scopes pequenos.
### Scope recomendado
- `sourceRef`: `gstreamer-official`
- `sourceId`: `corpus:gstreamer:official:v1`
- `mode`: `mechanical`
- `chunk mode esperado`: `documental`
### Tags recomendados
- `gstreamer`
- `official-docs`
- `multimedia`
- `documental`
---
## Resultado esperado tras la ingesta
Al consultar `GET /sources`, deberiamos ver un scope similar a:
```text
gstreamer-official [documental]
```
Y ese scope deberia servir para:
1. hacer `bootstrap` general del dominio GStreamer
2. recuperar docs sobre plugins, pads, states, negotiation, bus, pipelines, caps, etc.
3. mantenerlo aislado de `docs`, `RAG/docs` y `RAG/src`
---
## Riesgos identificados
### 1. Volumen alto
La fuente contiene miles de ficheros.
Riesgos:
- tardanza alta en la vectorizacion
- errores parciales en una carga masiva
- fallos del playground en una subida tan grande
### 2. Ruido documental
Los ficheros incluyen restos de navegacion tipo:
- `Toggle navigation`
- `Edit on GitLab`
- breadcrumbs y subpages
Esto no impide la ingesta, pero puede introducir ruido semantico.
### 3. Recuperacion dispersa
Aunque todo quede en un mismo scope, el corpus cubre muchas capas:
- core
- libraries
- plugins
- tutorials
- app manual
- plugin development
Esto obliga a validar retrieval antes de usarlo para tareas reales de depuracion.
---
## Estrategia de ejecucion recomendada
### Fase 1. Validacion tecnica de la ingesta
Objetivo:
- confirmar que el flujo de ingesta soporta este volumen y formato sin romper
Pasos:
1. revisar y corregir el error actual de ingesta (`Cannot read properties of undefined (reading 'map')`) si sigue reproduciendose
2. elegir el metodo de ingesta mas fiable para esta carga
3. ejecutar una ingesta controlada con el corpus completo bajo el scope acordado
### Fase 2. Verificacion del scope
Objetivo:
- confirmar que el corpus quedo agrupado correctamente
Pasos:
1. comprobar `GET /sources`
2. verificar que aparece un unico scope de GStreamer
3. comprobar tags y `sourceId`
### Fase 3. Validacion funcional del retrieval
Objetivo:
- asegurar que el RAG devuelve documentacion oficial util, no solo chunks ruidosos
Consultas de prueba sugeridas:
1. "explica la diferencia entre pads static y request pads en GStreamer"
2. "como funciona caps negotiation en GStreamer"
3. "que estados principales tiene un pipeline y como se gestionan"
4. "como enlazar elementos dinamicos y manejar pads-added"
5. "que dice la documentacion oficial sobre bus messages y manejo de errores"
### Fase 4. Validacion del bootstrap
Objetivo:
- comprobar que el corpus sirve como mapa inicial del dominio completo
Consulta sugerida:
```text
dame un mapa inicial de la documentacion oficial de GStreamer, sus bloques principales, conceptos nucleares, areas tecnicas y que partes son mas utiles para depurar aplicaciones grandes
```
### Fase 5. Preparacion del flujo con modelo local
Objetivo:
- usar el corpus ya validado como base documental para revisar codigo real
Enfoque recomendado:
1. no pedir al modelo local que revise toda una aplicacion enorme de golpe
2. pasarle modulos o archivos concretos
3. acompañar siempre con:
- logs de error
- mensajes de GStreamer
- sintomas observados
4. usar el RAG como fuente documental oficial, no como sustituto del contexto tecnico del fallo
---
## Criterio de exito
La task se considerara bien cerrada cuando se cumplan estas condiciones:
1. la documentacion de GStreamer este ingerida bajo un unico scope reconocible
2. el playground permita seleccionarlo facilmente
3. el `bootstrap` global funcione sobre todo el corpus
4. el retrieval devuelva documentacion oficial util en consultas de prueba
5. el corpus quede listo para usarse con un modelo local en tareas de revision de codigo
---
## Siguiente ejecucion prevista
Si el usuario valida este plan, la siguiente fase sera:
1. diagnosticar y corregir definitivamente el fallo actual de ingesta
2. ejecutar la ingesta real del corpus GStreamer
3. validar retrieval y bootstrap
4. dejar preparado el terreno para la integracion con el modelo local