Etiqueta
Un embedding vectorial es una lista de números reales que representa el significado semántico de un texto, imagen o cualquier otro dato. Dos frases con el mismo sentido producen vectores cercanos; dos sin relación, vectores lejanos. Sobre ese principio funcionan la búsqueda semántica, el RAG y los sistemas de recomendación modernos.
Postgres con pgvector es la opción por defecto para RAG en producción hasta diez millones de vectores: un índice HNSW, una base de datos y un plan de backup. Con reranking de dos etapas, búsqueda híbrida BM25 y SLOs medibles (p95 menor de 700 ms, recall@10 mayor de 0,85), la pila escala sin infraestructura adicional.
El RAG híbrido en 2026 combina búsqueda densa y léxica fusionadas con RRF, reranking cross-encoder sobre los top-50, chunking consciente de estructura y evaluación continua con Ragas o TruLens. Es el patrón que sobrevive en sistemas serios tres años después del boom inicial de embeddings.
Redis 8.2 incorpora la búsqueda vectorial como tipo de dato nativo. La duda real es si sustituye a un motor dedicado como Qdrant, Weaviate o pgvector en cargas con millones de vectores y latencias exigentes, o si solo sirve como complemento del caché que ya tienes.
El RAG de 2023 era búsqueda vectorial con un LLM detrás. El de 2025 es un sistema híbrido que combina vectores, búsqueda léxica y grafos de conocimiento. Qué ha cambiado, dónde funciona cada pieza y qué decisiones marcan la diferencia entre un RAG útil y uno decepcionante.
Durante una década, los grafos de conocimiento fueron una idea académica con pocos casos de uso reales, frenada por el coste de construir y mantener el esquema. Los LLM han cambiado esa ecuación: ahora extraen entidades automáticamente y sirven para anclar respuestas, auditar razonamiento y sostener agentes sin alucinar.
Un sistema RAG sin evaluación continua se degrada en silencio. Los índices cambian, los modelos se actualizan, los usuarios preguntan cosas nuevas. Este es un repaso práctico de qué métricas vigilar y cómo montar el cuadro de mando que avisa antes del incidente.
Desde que Microsoft abrió GraphRAG, el patrón de usar grafos sobre tus propios datos ha pasado de experimento académico a técnica con aplicaciones prácticas. Reflexión sobre cuándo compensa, cómo se monta y qué errores se repiten.
GraphRAG lleva más de un año en uso empresarial real: durante la indexación, un LLM construye un grafo de conocimiento que responde bien a preguntas globales sobre un corpus, justo donde el RAG clásico falla porque ningún fragmento aislado contiene la respuesta completa. Aquí comparo costes de indexación, casos donde compensa y el patrón híbrido que se ha impuesto entre equipos.
Medir la calidad de un sistema RAG con rigor exige más que revisar unas cuantas respuestas: hacen falta métricas objetivas (fidelidad, relevancia, precisión y cobertura de contexto), un conjunto dorado de cientos de preguntas curadas y validación humana periódica del juez LLM para evitar conclusiones engañosas.
La búsqueda híbrida combina BM25 y recuperación vectorial para cubrir lo que cada una no puede sola. El vector falla en identificadores exactos como SKUs o CVEs; BM25 falla cuando consulta y documento usan vocabulario distinto. La fusión mediante Reciprocal Rank Fusion (RRF) suma los dos rankings sin depender de sus escalas de puntuación.
Tras dos años de RAG en producción, los patrones que separan sistemas fiables de los fallidos son claros: el chunking semántico mejora el retrieval, hybrid search (BM25 + vectorial) recupera lo que lo vectorial puro pierde, el re-ranking eleva la precisión un 15-30%, y sin evaluación continua con un golden dataset cualquier mejora es un placebo.
La Assistants API de OpenAI ofrece threads persistentes, ejecución de código en sandbox y búsqueda documental gestionada, pero OpenAI la retira por completo el 26 de agosto de 2026 en favor de la Responses API. Analizamos cuándo compensaba frente a Chat Completions con infraestructura propia y qué hacer si tu proyecto todavía depende de ella.
Los embeddings recuperan rápido pero ordenan mal, porque codifican consulta y documento en vectores independientes sin cruzar tokens. Un reranker cross-encoder sobre el top-100 corrige esa señal y sube Precisión@10 entre un 15 y un 30 por ciento en corpus de más de 100k documentos. Cuándo compensa añadir uno y cuándo el límite de latencia hace que no sea viable.
nomic-embed-text-v1.5 de Nomic AI es un modelo de embeddings con pesos, código y datos de entrenamiento publicados en Apache 2.0: 137 millones de parámetros, hasta 8192 tokens de contexto y un MTEB de 62.4 puntos, casi igual al 62.3 de text-embedding-3-small de OpenAI, con 768 dimensiones en lugar de 1536.
Gemini 1.5 Pro irrumpió en febrero de 2024 con un contexto de un millón de tokens verificado. Recupera más del 95% de los datos hasta los 530.000 tokens en pruebas de recuperación, lo que transforma el diseño de sistemas RAG, hace viable el análisis de documentos completos y habilita nuevos patrones arquitectónicos con context caching.
OpenAI liberó text-embedding-3 el 25 de enero de 2024 en dos variantes: small y large. Mejora la calidad MTEB frente a ada-002, añade dimensiones variables (truncar sin reentrenar) y baja el precio en small. Migrar compensa en la mayoría de RAG serios, pero conviene medir el recall real con tu propio corpus antes de reindexar todo.
pgvector maduró en 2023-2024 con el tipo de índice HNSW y la construcción paralela que llegó en la versión 0.6. Para los proyectos que ya operan PostgreSQL, ya no hace falta una base vectorial dedicada en la mayoría de los casos: esta guía explica cuándo basta, cómo configurar el índice y dónde empieza a quedarse corto.
Cohere Embed v3 es un modelo de embeddings que distingue queries de documentos con el parámetro input_type y valora la calidad intrínseca del texto, con soporte multilingüe para más de 100 idiomas en 1024 dimensiones. Cuesta 0,10 dólares por millón de tokens, frente a 0,02 de OpenAI, y rinde mejor en RAG multilingüe.
Las bases de datos vectoriales han pasado de ser una curiosidad experimental a ser el componente central de la mayoría de productos basados en LLMs. Esta comparativa cubre Qdrant, Pinecone y Weaviate: arquitectura, fortalezas, limitaciones y un árbol de decisión para elegir según tus prioridades operativas y presupuesto.
pgvector convierte PostgreSQL en una base vectorial completamente funcional, sin necesidad de añadir un servicio separado al stack. Extiende Postgres con el tipo vector, índices IVFFlat para búsqueda aproximada (ANN) y la capacidad de combinar filtros SQL relacionales con ranking vectorial en la misma query. Para la mayoría de proyectos RAG y chatbots internos, esos límites nunca se alcanzan.
LangChain es un framework Python que unifica la construcción de aplicaciones con LLM: prompt templates, retrievers sobre bases vectoriales, agentes con function calling y memoria conversacional. Aporta valor real en prototipos rápidos y sistemas con varios modelos, pero en producción de un caso único bien definido el código directo suele ser más mantenible.
Chroma es la base de datos vectorial más sencilla para empezar con embeddings y búsqueda semántica: se instala con pip install chromadb, no exige infraestructura adicional y ofrece una API mínima (add, query, delete). Es ideal para prototipos y RAG de tamaño medio; por encima de unos pocos millones de vectores, conviene migrar a Qdrant o Milvus.
El fine-tuning de un LLM propio compensa en tres casos: necesitas un estilo o voz muy específicos, un formato de salida rígido y estructurado, o quieres reducir coste y latencia con un modelo pequeño especializado. LoRA y QLoRA han bajado el coste de GPU, pero preparar datos y operar el modelo en producción siguen siendo caros. Para el resto, RAG y prompt engineering bastan.
