Backend – Servicio RAG con IA

Arquitectura y Flujo de Datos Completo

El backend implementa un sistema RAG optimizado con una capa de caché inteligente (Redis) para maximizar el rendimiento. El ciclo de vida de una petición es el siguiente:

1. Inicialización (Singleton Pattern): Al arrancar la aplicación, se cargan en memoria una única instancia de ChromaDB y del Generador de Embeddings. Esto evita la recarga costosa de recursos en cada petición.
2. Recepción de Consulta: La API (views.py) recibe la pregunta del usuario.
3. Verificación de Caché (Nivel 1 - Respuesta Completa):
   • Se consulta a Redis si existe una respuesta previa para esta pregunta (o una pregunta semánticamente similar).
   • Hit: Si existe, se devuelve inmediatamente (latencia: ~100ms).
4. Procesamiento RAG (Miss de Caché):

   • Verificación de Caché (Nivel 2 - Embedding): Si no hay respuesta, se busca si ya existe el embedding de la pregunta en Redis. Si no, se genera con Gemini y se guarda.

   • Búsqueda Vectorial: Con el embedding, se buscan los fragmentos de documentos más relevantes en ChromaDB.

     💡 Te explico la magia de este proceso (Conceptos Clave):

     1. ¿Qué es un Fragmento (Chunk)? Es simplemente un pedazo de texto. El "cerebro" de la IA tiene un límite de memoria, así que no puedo pasarle un libro de 500 páginas entero. Lo que hago es "picar" el documento en trocitos pequeños y manejables. Ejemplo: Fragmento 1: "Para encender la máquina, presione el botón rojo..."

     2. ¿Qué es un Embedding? Aquí viene lo interesante: las computadoras solo entienden números. Un embedding es traducir texto a una lista de números (vector) que captura el significado. Imagínatelo como coordenadas en un mapa gigante de conceptos: "Perro" y "Gato" estarán cerca por ser animales domésticos, mientras que "Coche" estará muy lejos. No traduzco letras, traduzco ideas.

     3. ¿Qué es la Búsqueda Vectorial? Es encontrar qué ideas están cerca de otras. En lugar de buscar palabras exactas (como Ctrl+F), busco por similitud de significado.

     • Flujo: Si preguntas "¿Cómo prendo el equipo?", lo convierto a números y ChromaDB busca los fragmentos que estén "cerca" matemáticamente. Me dirá: "El fragmento del botón rojo es el más parecido a tu idea de encendido".

   • Generación de Respuesta: Se construye un prompt con el contexto recuperado y se envía a Gemini para generar la respuesta final.

5. Actualización de Caché: La nueva respuesta y su embedding se guardan en Redis para futuras consultas.
6. Respuesta: Se envía el resultado al frontend.

---

Componentes y Archivos Clave

Módulo RAG (backend/chatbot_app/rag/)

• cache_manager.py: NUEVO. Gestiona la interacción con Redis. Implementa la lógica de hashes MD5 para las claves y la búsqueda por similitud de coseno para encontrar respuestas a preguntas parecidas.
• singleton.py: NUEVO. Garantiza que solo exista una instancia de la base de datos vectorial y los modelos, optimizando el uso de memoria y tiempo de arranque.
• embeddings.py: Wrapper para la API de Google Gemini (generación de vectores).
• retriever.py: Orquesta la búsqueda de documentos, integrando la verificación de caché de embeddings antes de consultar Chroma.
• prompt_builder.py: Construye los prompts enriquecidos con contexto para el LLM.
• vector_store.py: Maneja las operaciones de bajo nivel con ChromaDB.

API y Configuración

• backend/chatbot_app/views.py: Controlador principal. Integra el detector de idioma, el gestor de caché y el flujo RAG.
• backend/Dockerfile: Define el entorno de ejecución con Python 3.12 y gestión de paquetes con uv.

---

Stack Tecnológico

Tecnología	Propósito	Implementación
Django & DRF	Framework Web y API REST	Núcleo del backend
Redis	Caché de Alto Rendimiento	Almacena embeddings y respuestas completas (TTL 24h)
ChromaDB	Base de Datos Vectorial	Almacena y busca fragmentos de conocimiento indexados
Google Gemini	LLM & Embeddings	Motor de inteligencia artificial para generación y vectorización
uv	Gestor de Paquetes	Reemplazo ultra-rápido de pip para instalaciones en Docker
pypdf	Procesamiento de Documentos	Extracción de texto durante la fase de ingesta

Despliegue en Producción (Render.com)

El backend de esta aplicación se despliega en Render.com siguiendo un flujo de CI/CD automatizado, que difiere del entorno de desarrollo local con Docker Compose.

Estrategia de Contenedorización

A diferencia del entorno local donde el código se monta mediante volúmenes para permitir cambios en tiempo real, en producción se utiliza una imagen de Docker inmutable. Esto garantiza que el artefacto desplegado sea idéntico al probado, eliminando inconsistencias.

Flujo de CI/CD

El proceso de despliegue se orquesta de la siguiente manera:

1. GitHub Actions: Al realizar cambios en el repositorio, un workflow (main.yml) construye automáticamente la imagen del backend.
2. Docker Hub: La imagen construida se sube a un registro público/privado en Docker Hub, versionada con un tag específico.
3. Render: La plataforma Render monitorea o es notificada de la nueva imagen, descargándola y desplegando el nuevo contenedor automáticamente. Render actúa como el orquestador, gestionando la ejecución, variables de entorno y red del servicio.

Este enfoque desacopla la construcción (CI) del despliegue (CD), asegurando un entorno de producción robusto y reproducible.