Construye un sistema de preguntas y respuestas sobre tu base de conocimiento con RAG
Los LLM no conocen tu material privado y actualizado, y son propensos a alucinar. El RAG (generación aumentada por recuperación) hace que el modelo responda a partir de una base de conocimiento fiable con la lógica de "recuperar primero, generar después": uno de los enfoques de producción más prácticos hoy.
PorAI Resource Hub
Por qué hace falta RAG
Inyectar conocimiento afinando el modelo directamente es caro y lento de actualizar. El RAG mantiene el conocimiento en una base de datos externa y recupera los fragmentos relevantes bajo demanda para dárselos al modelo: barato y siempre al día.
Visión general del pipeline
Un sistema RAG típico tiene dos fases: una "fase de indexación" offline que procesa los documentos hasta convertirlos en vectores recuperables, y una "fase de consulta" online que recupera y genera una respuesta a partir de la pregunta del usuario.
Troceado de documentos y embeddings
Primero divide los documentos en fragmentos de tamaño adecuado. Demasiado grandes, la recuperación pierde precisión; demasiado pequeños, se pierde el contexto. Un enfoque habitual son unos pocos cientos de tokens con algo de solapamiento.
Después usa un modelo de embeddings para convertir cada fragmento en un vector y guardarlo en una base de datos vectorial (como pgvector, Milvus o Qdrant).
Recuperación vectorial y Top-K
Cuando un usuario hace una pregunta, conviértela también en vector, ejecuta una búsqueda por similitud en la base de datos y recupera los fragmentos más relevantes (Top-K).
Puedes combinar la búsqueda por palabras clave para una "recuperación híbrida" y aplicar reranking para mejorar aún más la calidad del recall.
Monta el contexto y genera la respuesta
Inserta los fragmentos recuperados en el prompt e indícale al modelo que "responda solo a partir del material proporcionado y diga con claridad si el material no contiene la respuesta": esto reduce mucho las alucinaciones.
Entre las optimizaciones avanzadas están la reescritura de la consulta, citar las fuentes, controlar la longitud del contexto, y deduplicar y filtrar los resultados de la recuperación.
Elegir una base de datos vectorial
La base de datos vectorial está en el corazón del RAG. Para prototipos, Chroma funciona en memoria sin configuración. Para cargas de producción, Qdrant (basado en Rust) y Pinecone (totalmente gestionado) están diseñados para despliegues en producción; consulta sus límites y opciones de escalado actuales en la documentación. Si ya usas PostgreSQL, pgvector evita añadir infraestructura nueva. Weaviate destaca cuando necesitas módulos de vectorización integrados y una API GraphQL.
Evaluar la calidad del RAG
Un sistema RAG es tan bueno como su recuperación y su generación. Mide la recuperación con Recall@K (¿el fragmento correcto aparece en los resultados Top-K?) y la generación con fidelidad (¿la respuesta se basa en el contexto recuperado?) y relevancia (¿responde realmente a la pregunta?). Frameworks como RAGAS automatizan estas métricas para que puedas seguir la calidad mientras iteras sobre estrategias de troceado, modelos de embedding y plantillas de prompts.
Antes de empezar: requisitos previos
Necesitas un conjunto de documentos pequeño pero representativo, permiso para usarlo y un analizador que extraiga texto limpio (los PDF y los escaneos suelen requerir OCR). Elige un modelo de embeddings y un almacén vectorial que puedas ejecutar en tu entorno, y confirma su dimensión y soporte de idiomas. Prepara entre 20 y 50 preguntas reales con el documento o pasaje que debería responder cada una. Por último, decide cómo se actualizan los documentos y quién puede leer cada colección, porque los permisos deben aplicarse en la recuperación, no solo en la interfaz.
No necesitas un corpus enorme para empezar. Unos cientos de páginas bien estructuradas bastan para validar el pipeline antes de escalar.
Verificación: revisa la recuperación antes que las respuestas
Prueba primero la recuperación. Para cada pregunta etiquetada, ejecuta la búsqueda e inspecciona los mejores resultados: el pasaje esperado debería aparecer en el Top-K y los fragmentos irrelevantes no deberían dominar. Si no ocurre, ajusta el tamaño de fragmento, el solapamiento, los filtros de metadatos o el modelo de embeddings antes de tocar el prompt de generación. Después revisa las respuestas: el modelo debería citar o extraer textualmente el pasaje recuperado, y decir que el material no contiene la respuesta cuando sea cierto. Mantén un conjunto de evaluación fijo y vuelve a ejecutarlo tras cada cambio para detectar regresiones. Prueba también una pregunta cuya respuesta no exista, una con dos documentos parecidos y una en cada idioma que admitas.
Solución de fallos habituales en RAG
Depura en este orden. Si la recuperación no devuelve nada, comprueba que los documentos estén indexados, que la consulta y los documentos usen el mismo modelo y dimensión de embeddings, y que los filtros no excluyan la colección. Si el fragmento correcto existe pero queda bajo, revisa los límites de los fragmentos y prueba búsqueda híbrida por palabras clave o reranking. Si la respuesta ignora el contexto recuperado, confirma que los fragmentos llegaron al prompt y no se truncaron; luego endurece la instrucción de responder solo con el material proporcionado y citar fuentes. Si las respuestas están desactualizadas, verifica que la reindexación se ejecutó tras actualizar el documento. Si los duplicados llenan el Top-K, deduplica por ID de documento o hash del contenido antes de insertar. Por último, confirma que los filtros de control de acceso se aplican durante la recuperación, no después de generar.
Cuándo RAG no es la herramienta adecuada
RAG encaja mal cuando toda la base de conocimiento cabe cómodamente en la ventana de contexto y cambia poco; pasar los documentos directamente es más simple. También es débil cuando el material de origen no es fiable, se contradice o es sobre todo imágenes sin texto utilizable. Si la tarea exige cálculo, transacciones o estado en vivo, llama a una base de datos o API en lugar de recuperar texto sobre ello. Para preguntas que necesitan una única consulta autoritativa, un índice de búsqueda o una consulta estructurada pueden ser más precisos. Y si nadie puede mantener el índice, el sistema de recuperación se degradará rápido; un documento más pequeño y curado puede servir mejor a los usuarios.
Un paso de troceado
Esta función resuelve el paso de indexación que parte el documento antes de embedirlo. Es un borrador de partida, no un resultado medido. Fallo: si overlap es 0, un dato que cae en el corte no queda en ningún fragmento y la recuperación no puede devolverlo.
def chunk_text(text, size=400, overlap=50):
chunks = []
start = 0
while start < len(text):
chunks.append(text[start:start + size])
if start + size >= len(text):
break
start += size - overlap
return chunks