Embeddings para RAG: cómo elegir modelo, dimensiones y métrica sin decidir a ciegas

La keyword principal es embeddings para RAG; la intención es de implementación: un equipo necesita convertir texto en vectores y decidir modelo, dimensiones, métrica e índice sin asumir que el que encabeza un leaderboard resolverá su corpus en español.

Tampoco uses un embedding para codificar metadatos que ya son filtros deterministas. tenant_id, clasificación, idioma forzado, fecha de vigencia y ACL son columnas y políticas; concatenarlos como texto solo hace que el modelo intente adivinar una regla que el backend sí puede aplicar con precisión.

Métrica: cosine, producto interno y L2 solo funcionan con el contrato correcto

Cosine compara el ángulo entre vectores; producto interno y distancia L2 tienen otras geometrías. No son botones intercambiables: el operador del índice debe coincidir con la métrica con la que entrenó o documenta el modelo. En embeddings normalizados a longitud 1, OpenAI indica que cosine y distancia euclídea producen el mismo ranking, y el producto punto calcula cosine de forma directa.

CREATE EXTENSION IF NOT EXISTS vector; CREATE TABLE rag_chunk (id uuid PRIMARY KEY, model_id text NOT NULL, content text NOT NULL, embedding vector(1536) NOT NULL, CHECK (model_id = 'embed-v1')); CREATE INDEX rag_chunk_embedding_hnsw ON rag_chunk USING hnsw (embedding vector_cosine_ops); -- query y documento deben usar embed-v1 SELECT id, content, 1 - (embedding <=> $1::vector) AS cosine_similarity FROM rag_chunk WHERE model_id = 'embed-v1' ORDER BY embedding <=> $1::vector LIMIT 12;

Índice: empieza exacto y compra aproximación con evidencia

Sin índice aproximado, pgvector devuelve vecinos exactos: es el mejor baseline de calidad. HNSW suele dar buen compromiso de latencia y recall, pero tarda más en construir y usa más memoria que IVFFlat. Es una decisión de capacidad, no una mejora semántica: un HNSW rápido solo recupera con velocidad lo que el embedding ya colocó cerca.

Al activar HNSW, mide recall contra la consulta exacta en la misma muestra. pgvector expone hnsw.ef_search; aumentarlo explora más candidatos y puede mejorar recall a cambio de latencia. Con filtros selectivos, los índices aproximados pueden devolver menos resultados si filtran después del recorrido; usa sus iterative index scans, particiones o una estrategia acorde a la selectividad y vuelve a probar.

Separa la elección de índice de autorización. Si el corpus es multi-tenant, que un filtro no encuentre suficientes vecinos es un problema de recall; que devuelva un chunk ajeno es un incidente. La guía de RAG multi-tenant explica cómo derivar ACL desde identidad antes de construir contexto.

Fallos que bloquearía en revisión

• Cambiar el modelo de query sin una reindexación versionada del corpus.
• Seleccionar un embedding por su media MTEB sin separar idioma y tarea de retrieval.
• Usar la métrica por defecto del vector store aunque el proveedor documente otra geometría.
• Medir solo latencia de HNSW y no recall contra búsqueda exacta.
• Meter tenant_id o permisos en el texto y esperar que la similitud aplique una ACL.
• Bajar dimensiones o cuantizar sin ejecutar el mismo benchmark y sin registrar la versión.
• Guardar chunks sin model_id, dimensión, hash de contenido ni fecha de indexación.