73 lines
2.8 KiB
Markdown
73 lines
2.8 KiB
Markdown
# TASK
|
|
|
|
**Proyecto:** Workspace de tools IA para empresas
|
|
**Ultima actualizacion:** 2026-04-02
|
|
**Ultima modificacion por:** Agente tools IA para potenciar servicios empresariales
|
|
|
|
---
|
|
|
|
## Proposito
|
|
|
|
Este documento sirve para partir lineas de trabajo amplias en bloques de analisis y acuerdos, de forma que podamos avanzar sin dejarnos puntos importantes por el camino.
|
|
|
|
No sustituye a `docs/PENDIENTES_GENERALES.md`.
|
|
|
|
- `PENDIENTES_GENERALES.md` mantiene el panorama rapido de ideas y lineas pendientes.
|
|
- `TASK.md` descompone una linea concreta cuando requiere varias conversaciones, decisiones o pasos.
|
|
|
|
---
|
|
|
|
## Task principal
|
|
|
|
### Diseño y planeacion del tipo de RAG a crear
|
|
|
|
**Objetivo de esta task:**
|
|
Definir con claridad que tipo de sistema RAG queremos construir para que sea util, reutilizable, robusto desde una primera version sencilla y preparado para crecer hacia proyectos de clientes.
|
|
|
|
**Puntos a analizar y convenir:**
|
|
|
|
1. Diseño de fuentes
|
|
- Que tipos de fuentes debe soportar el sistema.
|
|
- Si empezamos solo con documentos o dejamos preparada entrada para APIs, bases de datos u otras fuentes.
|
|
- Como desacoplar conectores para que el sistema se adapte a distintos clientes.
|
|
|
|
2. Modelo de conocimiento
|
|
- Como representar la informacion de forma util para recuperacion.
|
|
- Que metadatos minimos conviene guardar desde el inicio.
|
|
- Como preparar el sistema para distintas clases de contenido.
|
|
|
|
3. Estrategia de chunking
|
|
- Como dividir la informacion en fragmentos utiles.
|
|
- Que nivel de contexto debe conservar cada fragmento.
|
|
- Como evitar fragmentos demasiado pequenos, demasiado grandes o sin sentido aislado.
|
|
|
|
4. Recuperacion
|
|
- Como encontrar el contexto mas relevante para una consulta.
|
|
- Que enfoque minimo usar en la primera version.
|
|
- Como dejar abierta la puerta a mejoras posteriores.
|
|
|
|
5. Multi-tenant y reutilizacion por cliente
|
|
- Como dar servicio a distintos clientes o proyectos con una misma base RAG.
|
|
- Como aislar informacion por cliente, app o entorno.
|
|
- Como preparar el sistema para que mejoras internas beneficien a todos los consumidores del servicio.
|
|
|
|
6. Interfaz de integracion
|
|
- Como consumiran el RAG otros agentes, tools o servicios.
|
|
- Si la primera interfaz sera API, libreria, CLI, MCP o una combinacion.
|
|
- Como evitar acoplar el RAG a un unico tipo de consumidor.
|
|
|
|
7. Observabilidad
|
|
- Que informacion necesitaremos para entender que esta recuperando el sistema.
|
|
- Como sabremos de donde sale el contexto devuelto.
|
|
- Que datos son utiles para depurar y mejorar el RAG.
|
|
|
|
8. Evaluacion
|
|
- Como validar si recupera bien.
|
|
- Como medir si la respuesta mejora con el contexto recuperado.
|
|
- Como detectar errores, ruido o falta de cobertura.
|
|
|
|
**Criterio de trabajo para esta task:**
|
|
- Empezar simple.
|
|
- Diseñar con vision de crecimiento.
|
|
- Evitar complejidad innecesaria en la primera version.
|
|
- Dejar preparadas las decisiones que condicionan una evolucion futura sana.
|