RAG (Retrieval-Augmented Generation)

Embeddings y similitud del coseno

En un RAG, cada fragmento de documento se convierte en un embedding, y la pregunta del usuario también. La similitud del coseno mide el ángulo entre dos vectores: cuanto más cerca de 1, más se parecen los significados. Así se encuentran los fragmentos más relevantes para una pregunta, aunque no compartan palabras.

El valor absoluto de la similitud engaña: depende del modelo, del idioma y de cómo se han redactado los textos. Lo útil es comparar la distancia entre los resultados buenos y los malos para preguntas reales. Por eso los umbrales de similitud se deben calibrar con datos, no fijar a ojo.

Bases de datos vectoriales

Una base de datos vectorial almacena embeddings y permite encontrar rápidamente los más cercanos a un vector dado, incluso entre millones de registros, gracias a índices aproximados (ANN). Algunos ejemplos son pgvector (una extensión de PostgreSQL), Qdrant, Pinecone, Weaviate o Chroma.

No siempre hace falta una dedicada. Con unos pocos miles de fragmentos, calcular la similitud contra todos (una búsqueda exhaustiva) es lo bastante rápido y ahorra infraestructura. La base vectorial empieza a compensar cuando el volumen crece o cuando necesitas filtros y latencias bajas a escala.

Chunking

El chunking es trocear los documentos en fragmentos (chunks) antes de generar sus embeddings. Un documento entero mezcla demasiados temas en un solo vector, y un fragmento demasiado pequeño pierde el contexto. El tamaño típico va de unos cientos a un par de miles de caracteres, con cierto solapamiento entre fragmentos consecutivos para que ninguna idea quede cortada por la mitad.

La mejor estrategia depende del contenido: por párrafos o secciones en la documentación, y por registro en los datos estructurados (un ticket, un pedido). Cuando indexas registros, conviene convertirlos en fichas legibles («Pedido 1042 de María, enviado el 3 de marzo, pendiente de devolución») en lugar de volcar sus columnas: el embedding captura significado, no estructura.

Búsqueda híbrida

La búsqueda híbrida combina la búsqueda semántica (por embeddings) con la búsqueda tradicional por palabras clave (como BM25). Cada una cubre los puntos débiles de la otra: la semántica entiende sinónimos y paráfrasis, pero falla con códigos, referencias y nombres propios exactos; la léxica funciona justo al revés.

En una aplicación de atención al cliente, «no me ha llegado el paquete» se resuelve bien por el significado, pero «pedido 1042» o un código de error concreto necesitan una coincidencia exacta. Los resultados de las dos búsquedas se fusionan, por ejemplo con Reciprocal Rank Fusion, que combina las posiciones de cada lista.

Reranking

El reranking es un segundo paso que reordena los candidatos recuperados con un modelo más preciso (a menudo un cross-encoder), que evalúa cada pareja pregunta-fragmento en conjunto en lugar de comparar vectores precalculados.

El patrón típico es recuperar muchos candidatos de forma barata (por ejemplo, 50) y hacer que el reranker elija los mejores (por ejemplo, 5), que son los que entran en el contexto. Mejora la precisión, pero añade latencia y coste, y solo tiene sentido cuando has comprobado que el problema es el orden de los resultados y no que la información no está.

Knowledge graphs

Un knowledge graph representa la información como entidades (clientes, productos, pedidos) y relaciones entre ellas («el cliente X ha comprado el producto Y», «el producto Y tiene la incidencia Z»). En el contexto del RAG (GraphRAG), permite responder preguntas que requieren seguir relaciones, no solo encontrar fragmentos parecidos.

Es útil cuando la pregunta es relacional («¿qué clientes que compraron este producto han abierto tickets este mes?»), donde la búsqueda por similitud no llega. El precio es alto, porque construir y mantener el grafo es complejo. En la mayoría de casos es más sensato empezar con un RAG vectorial y resolver las preguntas estructuradas con consultas SQL.