Machine Learning Mastery muestra cómo montar un RAG con scikit-learn sin base de datos vectorial

Machine Learning Mastery publicó el 13 de octubre de 2026 una guía práctica para construir un pipeline RAG de extremo a extremo con un stack mínimo. La búsqueda vectorial recae en scikit-learn, mientras que los embeddings y el procesamiento de texto se apoyan en modelos abiertos. En la fase de prototipo no se necesitan servidores con base de datos vectorial, infraestructura aparte ni API de pago. El material es didáctico, no un lanzamiento, pero muestra bien lo poco que hace falta para poner en marcha un esquema funcional de «encuentra el contexto y luego responde».

El anuncio describe solo los rasgos generales del esquema, así que a continuación se desglosa siguiendo los pasos típicos de un RAG. Los parámetros concretos del texto completo de la guía no se reproducen aquí.

De qué se compone el pipeline

Un RAG clásico consta de cuatro operaciones. Los documentos se dividen en fragmentos, los fragmentos se convierten en vectores, ante una consulta se buscan los más cercanos y el texto recuperado se inserta en el prompt del modelo de lenguaje. Todo ello cabe en un solo archivo.

En la guía, la vectorización corre a cargo de modelos de embeddings abiertos y la búsqueda de vecinos más cercanos, de scikit-learn. Para este caso la biblioteca ofrece herramientas listas para usar: la similitud del coseno y la clase NearestNeighbors. La matriz de vectores reside en memoria, la consulta se convierte en un vector de la misma dimensionalidad y después se selecciona el top-k.

Perfil aproximado de este stack:

• Búsqueda: scikit-learn, similitud del coseno o NearestNeighbors, con fuerza bruta exacta, sin aproximaciones.
• Embeddings: un modelo abierto. El popular all-MiniLM-L6-v2, por ejemplo, genera vectores de 384 dimensiones.
• Almacenamiento: un array de NumPy en la memoria RAM.
• Volumen: 100 mil fragmentos con 384 dimensiones en float32 ocupan alrededor de 150 MB.
• Dependencias: Python, scikit-learn y una biblioteca para cargar el modelo de embeddings.

Las cifras de volumen se han calculado a partir de la dimensionalidad del vector y no proceden del artículo. Sirven para ver el orden de magnitud: 384 números de 4 bytes equivalen a 1,5 KB por fragmento.

Por qué prescindir de una base de datos vectorial

La primera ventaja es la transparencia. Cuando la búsqueda se reduce a multiplicar matrices y ordenar, se ve qué ocurre en cada paso. Se puede imprimir la similitud, comprobar qué fragmento ha ganado y por qué, y detectar de inmediato que los chunks están mal cortados. En los sistemas especializados, parte de esa mecánica queda oculta tras una API.

La segunda es el bajo coste de entrada. El prototipo no requiere cuentas, claves ni llamadas de red. Para una base de conocimiento interna de unos pocos miles de páginas, o para formar a un equipo, es suficiente. La fuerza bruta exacta responde en fracciones de segundo con esos volúmenes, de modo que los índices aproximados como HNSW no aportan nada.

La tercera es la reproducibilidad. Si se fijan las versiones de las bibliotecas y del modelo, el resultado de un compañero coincidirá con el suyo.

Dónde choca este esquema con su techo

La fuerza bruta escala de forma lineal. Cuando el corpus alcance millones de fragmentos, el tiempo de respuesta y la memoria empezarán a ser un problema y habrá que pasar a FAISS, pgvector, Qdrant o alternativas similares. Los requisitos adicionales también recaen sobre el desarrollador: filtros por metadatos, permisos de acceso, actualización incremental del índice. En scikit-learn todo eso hay que programarlo a mano.

La calidad de la respuesta, por otra parte, no depende de la biblioteca de búsqueda, sino de tres factores: cómo se ha dividido el texto, qué modelo de embeddings se ha elegido y cómo está construido el prompt. Cambiar el almacenamiento por uno más potente no resolverá esos problemas.

Cómo aplicarlo en la práctica

Empiece con un corpus pequeño, por ejemplo su documentación o sus FAQ, y monte el pipeline en un solo script. Prepare entre 20 y 30 preguntas de control con respuestas conocidas y calcule la proporción de casos en que el fragmento correcto aparece en el top-3. Esa métrica, el hit rate, mostrará la calidad de la búsqueda antes de conectar la generación.

Después cambie una variable cada vez: el tamaño del chunk, el modelo de embeddings, el valor de k. Si la métrica sube, el esquema funciona. Cuando el corpus o la carga superen la memoria de una sola máquina, sustituya el bloque de búsqueda por una base de datos vectorial de nivel industrial. El resto del código seguirá igual, porque la interfaz «vector de consulta como entrada, lista de fragmentos como salida» es la misma en ambos casos.