Taller Práctico #2 — Sistema RAG para Atención al Cliente de EcoMarket

Estudiante: Eduardo José Avendaño Caicedo Curso: Generative AI

Este repositorio implementa un sistema RAG (Retrieval-Augmented Generation) que extiende la propuesta del Taller 1: dar al "Eco Asistente" acceso a la base de conocimiento interna de EcoMarket (políticas, catálogo de pedidos, FAQ) para responder con precisión sin alucinar y, cuando no tenga información suficiente, escalar honestamente a un agente humano.

Estructura del repositorio

.
├── README.md                       # Este archivo
├── requirements.txt                # Dependencias de Python
├── .gitignore
├── docs/
│   ├── Fase1_Componentes.md        # Selección y justificación de embedding + vector DB
│   └── Fase2_BaseConocimiento.md   # Documentos, chunking e indexación
├── data/
│   ├── politica_devoluciones.md    # Documento 1: política en Markdown
│   ├── catalogo_pedidos.csv        # Documento 2: pedidos en CSV
│   └── faq_ecomarket.json          # Documento 3: FAQ en JSON
├── src/
│   ├── ingest.py                   # Pipeline de ingesta → ChromaDB
│   └── rag_ecomarket.py            # Aplicación RAG interactiva (CLI)
└── chroma_db/                      # (Generado al ejecutar ingest.py) Base vectorial persistente

Arquitectura

                                     ┌──────────────────┐
                                     │  Documentos      │
                                     │  (md, csv, json) │
                                     └────────┬─────────┘
                                              │ ingest.py
                                              ▼
                                     ┌──────────────────┐
                                     │ Chunking por tipo│
                                     └────────┬─────────┘
                                              ▼
                                     ┌──────────────────┐
                                     │ Embeddings bge-m3│ (Ollama)
                                     └────────┬─────────┘
                                              ▼
                                     ┌──────────────────┐
                                     │   ChromaDB       │ (persistente local)
                                     └────────┬─────────┘
                                              │
   Cliente ──► Pregunta ──► Embed ──► Retriever (top-k=4)
                                              │
                                              ▼
                                  ┌────────────────────┐
                                  │ Prompt Eco Asist.  │
                                  │ + contexto         │
                                  └─────────┬──────────┘
                                            ▼
                                  ┌────────────────────┐
                                  │ Llama 3.1 8B       │ (Ollama)
                                  └─────────┬──────────┘
                                            ▼
                                       Respuesta

Requisitos previos

1. Python 3.10+
2. Ollama instalado y corriendo: https://ollama.com/download
3. Modelos descargados:

   ollama pull bge-m3
   ollama pull llama3.1:8b

Instalación

# Clonar el repositorio
git clone https://github.com/<usuario>/Taller2_RAG_EcoMarket.git
cd Taller2_RAG_EcoMarket

# Crear entorno virtual
python -m venv .venv
source .venv/bin/activate    # macOS / Linux
# .venv\Scripts\activate     # Windows

# Instalar dependencias
pip install -r requirements.txt

Uso

1. Indexar la base de conocimiento (una sola vez)

python src/ingest.py

El script carga los tres documentos, los fragmenta según la estrategia descrita en docs/Fase2_BaseConocimiento.md, los embebe con bge-m3 y los persiste en chroma_db/. Toma aproximadamente 30-60 segundos en una máquina con CPU moderna.

2. Conversar con el Eco Asistente

python src/rag_ecomarket.py

Ejemplos de consultas para probar el comportamiento del sistema:

• ¿Cuál es el estado de mi pedido ECO-10004? — debe leer del catálogo y reportar transportadora + guía + estado actual.
• Compré un jabón artesanal y lo abrí, no me gustó. ¿Puedo devolverlo? — debe razonar sobre la política (perecedero abierto = no procede) y ofrecer alternativa con empatía.
• ¿Hacen envíos a Pasto? — debe responder desde el FAQ.
• ¿Quién ganó el mundial de fútbol de 2018? — debe responder honestamente que no tiene esa información y ofrecer escalar a humano.

Comandos especiales del CLI:

• debug → activa/desactiva la impresión de los fragmentos recuperados antes de cada respuesta (útil para entender qué está leyendo el retriever).
• salir → termina la sesión.

Mapa de respuesta a la rúbrica

Rúbrica	Cumplimiento
Fase 1 — Selección y justificación de componentes (1.25 pt)	docs/Fase1_Componentes.md — embedding bge-m3 + ChromaDB con comparativa contra alternativas y trade-offs por costo, español, escalabilidad y privacidad
Fase 2 — Creación de la base de conocimiento (2 pt)	docs/Fase2_BaseConocimiento.md + carpeta data/ — 3 documentos heterogéneos (md, csv, json) y estrategia de chunking justificada por tipo de formato
Fase 3 — Comprensión del código y la integración (2.5 pt)	src/ingest.py y src/rag_ecomarket.py — código modular y comentado; el prompt incorpora el rol "Eco Asistente" del Taller 1 y el contrato de no-alucinación con escalamiento honesto

Limitaciones y suposiciones

Esta sección cumple con el punto 3 de la Fase 3 del enunciado: declarar explícitamente las limitaciones de recursos y las suposiciones que sustentan la arquitectura presentada.

Limitaciones de recursos

1. Ejecución local con Ollama. El sistema corre 100% en local (alineado con la decisión de privacidad del Taller 1). Esto requiere ~7-8 GB de RAM libres durante la ejecución: bge-m3 ocupa ~2.3 GB y Llama 3.1 8B en cuantización Q4 ~5 GB. En máquinas con menos memoria, se puede sustituir el LLM por llama3.2:3b editando la constante LLM_MODEL en src/rag_ecomarket.py (a costa de calidad de respuesta).

2. No hay capa de servicio HTTP. El demo es un CLI. Para un despliegue real, envolver el chain con FastAPI y exponer un endpoint /chat es directo (~30 líneas adicionales), pero queda fuera del alcance del taller.

3. Sin clasificador de intención (Capa 2 del Taller 1). El sistema actual responde todo desde la Capa 1 RAG. La instrucción del prompt incluye "escala a humano" si no hay información suficiente, pero no hay enrutamiento programático a GPT-4o como propuso el Taller 1. Implementar el clasificador requeriría un modelo adicional o un primer paso de prompting con Llama 3.1; queda como evolución natural del sistema.

4. Catálogo de pedidos como CSV estático. En producción, el catálogo no se indexaría estáticamente: un Tool de LangChain consultaría la base de datos transaccional en tiempo real para garantizar frescura (un pedido cambia de estado cada hora). El CSV indexado es una simulación didáctica que cumple con la consigna de "tres tipos de documentos".

5. Sin re-ranking. El retrieval directo por similitud coseno top-k es funcional pero subóptimo. En producción se añadiría un re-ranker (ej. bge-reranker-v2-m3) que reordene los k=10-20 candidatos iniciales y devuelva los 4 mejores. Se omite por simplicidad.

6. Sin evaluación cuantitativa del retrieval. No se incluyen métricas tipo recall@k o MRR. Validarlas requeriría un dataset etiquetado de pares (pregunta, chunk relevante) que se construye típicamente en la fase de validación posterior al piloto.

Suposiciones

1. La empresa puede operar Ollama en infraestructura propia (alineado con la Capa 1 del Taller 1 y con la Ley 1581 de 2012).
2. Los documentos cambian con baja frecuencia (políticas, FAQ) o de forma controlada (catálogo). Re-indexar manualmente es aceptable en esta etapa; en producción, un job nocturno o un trigger por evento de cambio dispararía ingest.py.
3. El idioma de operación es español. El prompt y los documentos están en español; bge-m3 los procesa correctamente sin pre-procesamiento adicional.
4. El uso es interno (servicio al cliente) — no se exponen los embeddings ni la base vectorial al cliente final.
5. La calidad de Llama 3.1 8B en español es suficiente para el caso de uso. Si se observara degradación significativa, una opción es usar Llama 3.1 70B en una máquina con GPU dedicada, o caer a la Capa 2 (GPT-4o / Claude) para esos casos.

Referencias

• Taller 1 — Optimización de la Atención al Cliente en EcoMarket (entregado previamente).
• LangChain — https://python.langchain.com/
• Ollama — https://ollama.com/
• ChromaDB — https://www.trychroma.com/
• BGE-M3 — Chen et al. (2024), https://arxiv.org/abs/2402.03216