186 lines
5.1 KiB
Markdown
186 lines
5.1 KiB
Markdown
# Playground del RAG
|
|
|
|
**Proyecto:** Workspace de tools IA para empresas
|
|
**Modulo:** RAG
|
|
**Ultima actualizacion:** 2026-04-06
|
|
**Ultima modificacion por:** Agente tools IA para potenciar servicios empresariales
|
|
**Estado:** Implementado en codigo, pendiente de redeploy
|
|
|
|
---
|
|
|
|
## Tecnologia elegida
|
|
|
|
Se ha elegido una interfaz web estatica simple, servida por el propio backend `Express` del RAG.
|
|
|
|
### Por que esta opcion
|
|
|
|
- evita crear un segundo servicio independiente solo para pruebas
|
|
- no añade otro framework de frontend ni otro pipeline de build innecesario
|
|
- permite iterar rapido sobre el RAG real usando su propia API
|
|
- es suficiente para una herramienta interna de evaluacion y ajuste
|
|
|
|
---
|
|
|
|
## Ubicacion dentro del modulo
|
|
|
|
El playground queda dentro de:
|
|
|
|
```text
|
|
RAG/public/playground/
|
|
```
|
|
|
|
Archivos creados:
|
|
|
|
- `RAG/public/playground/index.html`
|
|
- `RAG/public/playground/app.js`
|
|
- `RAG/public/playground/styles.css`
|
|
|
|
El backend lo sirve desde:
|
|
|
|
```text
|
|
/playground
|
|
```
|
|
|
|
---
|
|
|
|
## Que permite probar
|
|
|
|
1. `health`
|
|
2. `ingest`
|
|
3. `bootstrap`
|
|
4. `chat` con contexto precargado
|
|
5. `retrieve`
|
|
6. `answer`
|
|
7. `answer` sin RAG para comparar impacto del contexto
|
|
8. seleccion explicita del modelo de `answer`
|
|
|
|
Tambien permite:
|
|
|
|
- cambiar `mode`
|
|
- cambiar `intent`
|
|
- ajustar `scope`
|
|
- seleccionar el modelo de respuesta
|
|
- usar presets para docs, docs del modulo y codigo del RAG
|
|
- ver un contador visible de logs recientes
|
|
- mostrar branding visual del servicio en la cabecera
|
|
|
|
---
|
|
|
|
## Mecanica actual del playground
|
|
|
|
El playground ya no funciona como una sola caja de consulta tecnica. Ahora se organiza en tres pestañas:
|
|
|
|
1. `Ingesta`
|
|
- lanzar ingesta documental o de codigo
|
|
- subir archivos directamente desde el navegador
|
|
- definir un `sourceId` propio para aislar una carga concreta
|
|
|
|
2. `Bootstrap`
|
|
- elegir scope
|
|
- elegir modo
|
|
- cargar un mapa inicial del dominio
|
|
- opcionalmente pedir a un modelo que sintetice ese bootstrap
|
|
- reemplazar o vaciar el contexto de sesion
|
|
|
|
3. `Chat`
|
|
- conversar con el modelo
|
|
- ver visualmente si hay contexto cargado o no
|
|
- reutilizar el ultimo bootstrap como contexto base
|
|
- permitir que el modelo haga consultas adicionales al RAG durante la conversacion
|
|
|
|
### Indicador visual de contexto
|
|
|
|
En la pestaña `Chat` hay un indicador visual:
|
|
|
|
- rojo: no hay bootstrap cargado
|
|
- verde: hay contexto bootstrap activo
|
|
|
|
Tambien se muestra el `scope` actualmente cargado.
|
|
|
|
### Aislamiento de scopes en ingesta
|
|
|
|
En la pestaña `Ingesta` ya se puede:
|
|
|
|
- indicar un `sourceId` propio
|
|
- subir un archivo local directamente
|
|
|
|
Esto permite probar documentos o PDFs que no tengan nada que ver con el RAG sin mezclarlos con el resto de scopes si eliges un identificador especifico para esa carga.
|
|
|
|
### Chat con consultas adicionales al RAG
|
|
|
|
El chat ya soporta dos niveles:
|
|
|
|
1. respuesta usando solo el bootstrap cargado
|
|
2. respuesta usando bootstrap y, si se activa la opcion correspondiente, una consulta adicional al RAG durante la conversacion
|
|
|
|
Esto permite aproximar mejor el comportamiento esperado de una app o agente conectado al servicio.
|
|
|
|
### Memoria operativa actual
|
|
|
|
El playground no usa una memoria persistente completa.
|
|
|
|
Su memoria actual es limitada y se compone de:
|
|
|
|
- el ultimo `bootstrap` cargado
|
|
- el historial reciente de mensajes de la sesion actual
|
|
- el contexto adicional recuperado si se activa esa opcion en el chat
|
|
|
|
El objetivo de esta memoria no es simular un asistente generalista, sino permitir probar de forma controlada como cambia el comportamiento del modelo al apoyarse en el RAG.
|
|
|
|
### Regla de comportamiento del modelo en el playground
|
|
|
|
El modelo del playground debe comportarse como evaluador del RAG.
|
|
|
|
Eso significa:
|
|
|
|
- usar solo el contexto que proviene del RAG y del bootstrap cargado
|
|
- no completar respuestas con conocimiento general externo del modelo
|
|
- indicar con claridad cuando el RAG no aporta suficiente informacion
|
|
- servir para detectar limites, carencias y calidad del sistema
|
|
|
|
---
|
|
|
|
## Logs de evaluacion
|
|
|
|
El playground ya soporta dos vias de logging:
|
|
|
|
1. `log automatico`
|
|
- cuando la respuesta o el contexto indican insuficiencia relevante
|
|
|
|
2. `log manual`
|
|
- cuando el usuario pulsa el boton para registrar la consulta actual
|
|
- puede añadir una nota explicativa propia
|
|
|
|
Los logs quedan guardados en `Qdrant`, por lo que no dependen del filesystem efimero del contenedor.
|
|
|
|
Aunque de momento el playground no tiene una pestaña dedicada solo a logs, si puede:
|
|
|
|
- registrar logs manuales
|
|
- mostrar logs recientes
|
|
- mostrar un contador visible de logs en cabecera para saber de un vistazo si el sistema esta generando incidencias o revisiones
|
|
|
|
Y estos logs ya quedan preparados para ser revisados despues por el usuario junto con este agente u otros agentes.
|
|
|
|
---
|
|
|
|
## Idea de uso
|
|
|
|
Este playground no sustituye a clientes finales ni al futuro MCP.
|
|
|
|
Su papel es:
|
|
|
|
- probar rapido el comportamiento del RAG
|
|
- comparar respuesta con y sin RAG
|
|
- validar cambios en ingesta y retrieval
|
|
- detectar donde el sistema necesita ajustes
|
|
|
|
---
|
|
|
|
## Relacion con MCP
|
|
|
|
En esta primera fase el playground usa la API HTTP del propio servicio.
|
|
|
|
Mas adelante se podra:
|
|
|
|
- mantener como herramienta interna de evaluacion
|
|
- o ampliarlo para probar tambien la capa MCP cuando exista
|