Si has seguido los artículos anteriores, ya tienes un sistema RAG (Retrieval-Augmented Generation) funcionando en tu ordenador. Has cogido tus PDFs corporativos, los has troceado, los has convertido en vectores con un «Bibliotecario» (ChromaDB) y has puesto a un «Escritor» (Llama 3) a redactar respuestas.
Has construido un «Hola Mundo» glorioso. Pero si subes esto a producción hoy mismo, te estrellarás contra la realidad de los usuarios.
El RAG básico (o Naive RAG) tiene dos problemas críticos: es amnésico (no recuerda nada) y es literal (busca exactamente lo que le pides, incluso si lo pides mal). Hoy vamos a ponernos la bata de Arquitectos de IA para resolver estos problemas usando las técnicas de orquestación más avanzadas de la industria.
1. El Problema de la Amnesia: Inyectando Memoria (Chat History)
Las APIs de los modelos de lenguaje (y los modelos locales como Ollama) son sistemas Stateless (sin estado). Esto significa que cada vez que le envías una pregunta, para el modelo es la primera vez que interactúa contigo en toda su vida.
Usuario: «¿Qué es LangChain?»
IA: «Es un framework para orquestar modelos de IA…»
Usuario: «¿Y cuáles son sus componentes principales?»
IA: «¿Los componentes principales de qué? No sé de qué me hablas.»
Para solucionar esto, no modificamos el modelo, modificamos la «tubería» (el pipeline).
La Solución: Ventanas de Memoria (Sliding Window) En LangChain, interceptamos la pregunta del usuario antes de enviarla a buscar a la base de datos, y le «pegamos» un bloque de texto oculto que contiene el historial de la conversación.
El prompt real que se envía por debajo tiene esta forma:
[HISTORIAL INTERNO: El usuario preguntó qué es LangChain. Tú respondiste que es un framework]. [NUEVA PREGUNTA]: «¿Y cuáles son sus componentes principales?»
Al ver el historial, la IA razona: «Ah, la nueva pregunta se refiere a LangChain». Sin embargo, no puedes inyectar un historial infinito, porque saturarías la RAM y el coste por tokens. En producción usamos técnicas como Conversational Summary Memory, donde un LLM secundario pequeñito va leyendo el chat en segundo plano y creando un resumen comprimido de la charla (ej: «El usuario y la IA están debatiendo sobre LangChain y RAG»), y eso es lo que inyectamos.
2. El Problema de la Ceguera del Usuario: Multi-Query
El mayor enemigo de tu base de datos vectorial es el propio usuario. Las búsquedas vectoriales son muy buenas relacionando conceptos similares, pero si el usuario es escueto o usa jerga, el sistema colapsa.
Lo que hay en tu PDF: «Procedimiento de reinicio del clúster de Kubernetes en caso de fallo de nodo.»
Lo que pregunta el usuario: «k8s se colgó, ayuda»
Si pasamos «k8s se colgó, ayuda» a formato vector, puede que matemáticamente quede muy lejos del párrafo oficial.
La Solución: Multi-Query (Expansión de Consultas) Antes de buscar en ChromaDB, hacemos una parada técnica. Le pasamos la pregunta mala del usuario a nuestro LLM rápido y le damos una instrucción secreta: «Eres un experto SEO. El usuario ha escrito esta búsqueda. Genera 3 preguntas alternativas que signifiquen lo mismo pero usen lenguaje técnico y profesional».
Internamente, el sistema transforma «k8s se colgó» en:
¿Cómo solucionar un fallo de nodo en Kubernetes?
Guía de recuperación y reinicio para clúster Kubernetes caído.
Troubleshooting para k8s unresponsive.
Luego, la tubería busca en ChromaDB usando estas tres frases a la vez. Al multiplicar la superficie de búsqueda, garantizamos que encontraremos el párrafo correcto del PDF corporativo.
3. El Truco del «Fake it till you make it»: HyDE
HyDE (Hypothetical Document Embeddings) es posiblemente la técnica más brillante e intuitiva que ha nacido en la ingeniería de IA moderna.
El Problema Matemático: Las bases de datos vectoriales buscan similitud. Si buscas la pregunta «¿Cuál es la política de bajas por enfermedad?», la base de datos buscará textos que se parezcan matemáticamente a una pregunta. ¡Pero tú no quieres otra pregunta, quieres un texto que tenga formato de respuesta!
La Solución HyDE: En lugar de convertir la pregunta del usuario a vector, le pedimos a Llama 3 que se invente la respuesta (que alucine de forma controlada).
Usuario: «¿Cuál es la política de bajas?»
LLM Alucina (Documento Hipotético): «La política de bajas indica que el empleado debe notificar a Recursos Humanos en las primeras 24 horas y presentar un justificante médico…» (El LLM no sabe si esto es verdad en tu empresa, se basa en lo que sabe del mundo).
Búsqueda Vectorial: Cogemos esa respuesta inventada y la convertimos en vector.
Magia: Como estamos buscando un vector que tiene la «forma, tono y palabras de una respuesta de recursos humanos», la base de datos nos devuelve mágicamente el párrafo real y exacto de nuestro PDF que encaja como un guante.
4. El Embudo Perfecto: Re-Ranking (Cross-Encoders)
Imagina que eres un reclutador (El Escritor / LLM) buscando a un candidato. Le pides a tu becario (El Bibliotecario / Base de Datos Vectorial) que te traiga los 3 mejores currículums (k=3). El becario es rápido, pero no muy inteligente, así que te trae 3 currículums que tienen la palabra «Python», pero resultan ser biólogos que estudian serpientes pitón, no programadores.
Si le pides al becario que te traiga 50 currículums y los lees tú todos para decidir (pasarle mucho contexto al LLM), tardarás una eternidad y te costará muchísimo dinero.
La Solución: Re-Ranking en dos fases Creamos un sistema de embudo utilizando un modelo intermedio especializado llamado Cross-Encoder.
Fase 1 (Búsqueda rápida): Le decimos a ChromaDB que no traiga 3 resultados, sino 20 (k=20). Es una búsqueda bruta y rápida. Entrará basura, pero nos aseguramos de que el oro también está ahí.
Fase 2 (Re-Ranking): Pasamos esos 20 fragmentos de texto y la pregunta del usuario por el Cross-Encoder (un modelo súper ligero y optimizado solo para puntuar, como
bge-reranker). Este modelo lee los 20 fragmentos y les pone una nota del 0 al 10 basándose en la relevancia real, no solo en la similitud de palabras.Fase 3 (Generación): El sistema descarta los 17 peores, toma los 3 currículums con mayor nota real (los programadores de verdad), y se los entrega a Llama 3 para que redacte la respuesta final.
Has construido un sistema a prueba de balas.
🚧 Road to Senior: Tareas AI para profundizar
Abre tu entorno de pruebas y usa estos prompts para investigar la implementación real:
TODO 1 (LangChain Memory): «Actúa como un desarrollador Senior en Python. Muéstrame un ejemplo de código usando LangChain (LCEL) donde implementes ‘ConversationSummaryMemory’. Explícame cómo se inyecta esa variable en un ChatPromptTemplate.»
TODO 2 (Cross-Encoders): «¿Cuál es la diferencia de arquitectura entre un modelo ‘Bi-Encoder’ (como los que usamos para generar los embeddings en ChromaDB) y un ‘Cross-Encoder’ (usado para Re-Ranking)? ¿Por qué el Cross-Encoder es mucho más preciso pero más lento?»