Nadie se queda fuera por vocabulario.
Todo término técnico del sitio, organizado en apartados, con explicación didáctica y — cuando existe —enlace a la fuente oficial (Hugging Face de los modelos open, web del creador en el resto).64 entradas en 6 apartados.
Fundamentos del RAG
El vocabulario mínimo para entender cualquier conversación sobre RAGs.
rag
RAG (Retrieval-Augmented Generation): un LLM que responde apoyándose en tus documentos, recuperados en el momento de preguntar. En lugar de fiarlo todo a la memoria del modelo, buscas la información fresca y verificable en tu corpus y se la sirves al LLM como contexto para que responda con citas.
corpus
Conjunto de documentos que alimentan el RAG: la materia prima. Su calidad decide mucho más que el modelo: el 80% del éxito de un RAG ocurre antes del prompt, en cómo se selecciona, limpia y cura este material.
chunk
Porción de documento troceada: la unidad mínima que se recupera. El RAG no busca "documentos", busca chunks; su tamaño y coherencia determinan la calidad de cada respuesta.
píldora de información
Un chunk que se basta a sí mismo para responder algo, sin necesitar al resto de la página. Es el criterio de calidad del chunking: si al leer el chunk aislado no entiendes la respuesta, la píldora está mal troceada.
chunking
Trocear los documentos en chunks. El tamaño no se elige: se hereda del dominio (un convenio se trocea por artículos, un manual por secciones). Estrategias habituales: fijo, semántico, por estructura y jerárquico padre-hijo.
normalización de formato
Pasar todo el corpus a un formato común — normalmente Markdown — antes de curar. Un solo formato estructurado simplifica limpieza, chunking y trazabilidad: te pelea una sola vez con los PDFs, no cada día.
markdown
Formato de texto con estructura ligera (títulos #, listas, tablas) que se ha convertido en el estándar de facto para corpus de RAG: conserva la estructura del documento y es trivial de trocear por secciones.
más información ↗overlap
Solape entre chunks consecutivos para no perder ideas en el corte. Un overlap del 10-20% evita que la frase que cae justo en la frontera desaparezca de ambos lados.
tokens
Unidades de texto (≈¾ de palabra en español) que consumen los modelos. Limitan el tamaño de la píldora: cada modelo de embedding admite un máximo de tokens por texto de entrada.
contexto
Número máximo de tokens que un modelo (embedding o LLM) puede procesar de una vez: la píldora debe caber. En embeddings oscila entre 512 y 32k tokens según el modelo.
Embeddings
Cómo el texto se convierte en vectores y qué modelo conviene elegir: licencia, idiomas y límite de tokens.
embedding
Representar texto como vector de números para comparar significados por distancia. Dos textos parecidos acaban con vectores cercanos, aunque no compartan ni una palabra. Es el mecanismo que permite buscar por significado en vez de por palabra exacta.
vector
Lista de números que representa el significado de un texto. La "posición" de cada texto en ese espacio es lo que compara la búsqueda densa.
dimensión
Longitud del vector de embedding (384, 1024, 3072…). Más dimensiones capturan más matiz pero encarecen almacenamiento y cómputo. Algunos modelos permiten reducirlas con MRL sin reentrenar.
open vs propietario
Open: pesos descargables (Apache, MIT…), lo ejecutas tú sin coste por token y sin dependencia externa. Propietario: API de un proveedor, pagas por uso y dependes de su disponibilidad y política. Para comparar ambos mundos, el leaderboard MTEB es la referencia.
más información ↗openai embeddings
Familia text-embedding-3 (small/large) de OpenAI: propietaria, multilingüe, 8191 tokens de contexto, 1536 o 3072 dimensiones. El default de facto del mercado: buena calidad, precio contenido y documentación enorme.
más información ↗bge-m3
Modelo open source de BAAI: multilingüe (100+ idiomas), 8192 tokens de contexto y 1024 dimensiones. Se ejecuta en local y es de las mejores opciones open para español; su punto fuerte es combinar densa, sparse y multi-vectorial en un solo modelo.
más información ↗qwen3 embedding
Familia open (Apache 2.0) de Alibaba en tamaños 0.6B/4B/8B: multilingüe (100+ idiomas), 32k tokens de contexto y dimensiones ajustables vía MRL. Entre lo mejor del lado open en retrieval multilingüe; los tamaños grandes piden GPU.
más información ↗e5
Familia de embeddings de Microsoft Research. multilingual-e5-large es muy buena y ligera… pero solo admite 512 tokens por texto: obliga a píldoras pequeñas. Buen recordatorio de que el modelo de embedding condiciona el chunking.
más información ↗cohere embed
Familia de embeddings de Cohere, muy fuerte en multilingüe y con contextos larguísimos (embed v4 llega a 128k tokens). Propietaria, con API propia y buenos rerankers en la misma casa.
más información ↗gemini embedding
Modelo de embedding de Google (3072 dimensiones, 2048 tokens), integrado con Gemini API y Vertex AI. Fuerte en clasificación y retrieval multilingüe.
más información ↗voyage
Embeddings de Voyage AI especializados en RAG y código, con contextos de hasta 32k tokens. Suele aparecer en los puestos altos de los benchmarks de retrieval; proveedor menor que OpenAI o Cohere.
más información ↗nomic embed
Embedding open source eficiente (768d, 8192 tokens)… pero solo inglés: ojo con corpus en español. Perfecto ejemplo de que "open y bueno" no basta: hay que mirar idiomas.
más información ↗sentence-transformers
La biblioteca de referencia para embeddings locales: eliges el modelo según idioma, tamaño y límite de tokens, y lo sirves tú. La navaja suiza del que empieza sin API externa.
más información ↗mistral embed
Modelo de embedding de Mistral AI (1024d, 8192 tokens), competitivo en precio y fuerte en idiomas europeos, incluido el español.
más información ↗Búsqueda y recuperación
Cómo se busca dentro del RAG y cómo se mide que lo encontrado vale.
densa
Búsqueda por similitud de embeddings: encuentra significados parecidos aunque cambien las palabras. Es la búsqueda "semántica" por excelencia; sufre si compite contra todo el corpus sin prefiltros.
sparse
Búsqueda léxica (BM25): el vector es enorme y casi vacío, con pesos por palabra. Encuentra términos exactos (referencias, códigos, nombres propios) que la densa a veces difumina.
bm25
El algoritmo de búsqueda léxica clásica: puntúa documentos por coincidencia de términos con frecuencia e inversión documental. Sigue siendo insuperable para palabras exactas y es la mitad de cualquier sistema híbrido.
híbrida
Combinar búsqueda densa y sparse y fusionar sus rankings, normalmente con RRF. Lo mejor de los dos mundos: semántica + precisión léxica.
rrf
Reciprocal Rank Fusion: forma habitual de fusionar rankings de búsquedas distintas. A cada documento se le suma 1/(k+posición) en cada ranking; simple, sin calibrar pesos, y funciona sorprendentemente bien.
reranking
Reordenar los resultados recuperados con un modelo más fino (cross-encoder) antes de generar. La recuperación inicial es rápida y aproximada; el rerank es lento y preciso — y suele ser la mejora con mejor relación coste/beneficio de todo el RAG.
prefiltro determinista
Regla fija (metadatos) que reduce qué información puede competir en la búsqueda, antes de que actúe la semántica. La semántica encuentra lo parecido; el filtro decide qué tiene derecho a competir. Es también la base de la seguridad: nunca un elemento probabilístico (LLM) decide quién accede a qué.
recall
Fracción de respuestas correctas que el sistema consigue encontrar. Si el recall es bajo, da igual lo bien que genere el LLM: no le llegó la información. Por eso el umbral típico es "Recall ≥ 90% o cero: no-deployment".
precisión
Fracción de lo recuperado que realmente era relevante. Alta precisión = poco ruido en el contexto; bajo recall con alta precisión = respuestas incompletas pero limpias.
Seguridad y gobierno del corpus
Metadatos, permisos y calidad: lo que convierte una demo en un sistema serio.
auto-etiquetado
Asignar dominio y etiquetas en la ingesta sin intervención humana: por convención (carpetas, frontmatter, sidecar JSON) o por semántica (embeddings o un LLM tier-2 contra la lista de dominios). Regla de oro: la lista de dominios y etiquetas debe estar bien definida y ACOTADA antes de automatizar — primero el modelo de conocimiento, después el automatismo.
frontmatter
Bloque YAML en la cabecera de un documento (típico en Markdown) con sus metadatos: dominio, etiquetas, vigencia… El corpus se describe a sí mismo y los metadatos viajan con el contenido, versionados juntos.
sidecar
Fichero de metadatos con el mismo nombre que el documento (doc.pdf → doc.json): separa la descripción del contenido sin tocar el original. Fácil de generar y editar en batch; riesgo, que las parejas se desincronicen.
tenant
Cliente o entidad aislada dentro de un sistema multiempresa. Cada chunk debe saber a qué tenant pertenece para que nadie recupere información ajena: modelarlo después de ingestar es carísimo.
rbac
Role-Based Access Control: permisos según el rol del usuario (RRHH, jurídico, admin…). Simple de razonar, más rígido: no distingue casos dentro del mismo rol.
abac
Attribute-Based Access Control: permisos según atributos (país, clasificación, vigencia, departamento). Más expresivo que RBAC; combinado con metadatos por chunk, es el modelo natural para RAGs empresariales.
dataset áureo
Conjunto patrón de preguntas y respuestas correctas para medir el RAG con objetividad. La regla del proyecto: Recall ≥ 90% o cero, no-deployment. Sin él, cada cambio es un acto de fe.
idempotente
Ejecutar dos veces no rompe nada: la reingesta deja el mismo resultado. Es la propiedad que permite refrescar el corpus sin miedo, requisito de cualquier pipeline serio de ingesta.
medallón
Arquitectura Bronce (crudo tal cual llega) → Silver (curado y normalizado) → Gold (síntesis validada por expertos). Tomada del mundo del dato y aplicada al conocimiento no estructurado.
linaje
Rastro del origen de cada chunk: de qué documento, versión y página nace. Sin linaje no hay citas fiables ni auditoría posible.
doble campo
Guardas resumen y original: recuperas por el resumen (el embedding se calcula sobre él) y respondes con el texto completo. Chunks digestivos para la búsqueda, completos para la respuesta.
transversal
Documento que hilan chunks de varios dominios para responder conceptos multi-dominio (un concepto que vive a caballo entre laboral y fiscal, por ejemplo). En el rerank pesan más que los chunks sueltos.
mcp
Model Context Protocol: estándar abierto para exponer herramientas y datos a modelos de forma uniforme. Cada vez más orígenes de corpus se exponen como servidores MCP.
más información ↗one-shot
Prueba puntual: montas, preguntas una vez y aprendes. El RAG mínimo de este sitio es una receta one-shot pensada para validar una idea en una tarde.
Frameworks y conjuntos de bloques
Los frameworks más usados vistos como lo que son: varias fases del pipeline empaquetadas en un conjunto.
conjunto de bloques
Nuestro nombre para un framework visto como lo que es: varias fases del pipeline empaquetadas. En el editor se ancla en su fase, se expande en sus bloques (trazabilidad total) y trae variantes según cuántas fases te interesa que cubra.
llamaindex
Framework centrado en datos: más de cien readers de fuentes y formatos, node parsers para trocear, retrievers componibles y query engines que responden citando los nodos fuente. Ideal cuando el reto está en los datos más que en el agente.
más información ↗langchain
El framework de orquestación más adoptado: retrievers componibles, cadenas de prompt → LLM e integraciones con casi todo. Su capa LangGraph añade grafos con estado para agentes. Contrapartida conocida: abstracciones que cambian rápido entre versiones.
más información ↗langgraph
Capa de LangChain para construir agentes como grafos con ciclos, memoria y control fino del flujo. Cuando el RAG deja de ser "busca y responde" y necesita decidir pasos, LangGraph es el paso siguiente natural.
más información ↗haystack
Framework de deepset con pipelines declarativos de extremo a extremo (converters → splitters → retrievers → generators). Muy apreciado en producción por su estructura explícita; algo menos comunidad en español.
más información ↗ragkit
RAG agéntico llave en mano para .NET (MIT, paquetes NuGet) de Javier Frauca: ingesta idempotente por hash con extractores PDF/DOCX, clasificación automática por dominios (tier-2 con umbral de confianza), chunking por frontera, embedders ONNX locales (BGE-M3, E5, MiniLM) o API OpenAI-compatible, vector stores InMemory/Qdrant/pgvector/SQL Server 2025, recuperación híbrida densa+BM25 con RRF acotada por dominio y etiquetas, rerank (cross-encoder o LLM), guardarrailes y modo agéntico con 13 herramientas, MCP y streaming. Cubre de la ingesta a la generación; no hace curado de texto.
más información ↗nucleus
Núcleo de servicio del RAG de Javier Frauca: el rack validado (almacén con metadatos de dominio, seguridad y vigencia), búsqueda determinista con prefiltro identidad → reglas → filtro, y rerank con boost de transversales. Lo contrario de "un prompt y a correr": servir con seguridad.
más información ↗Bases de datos y almacenes
Dónde viven los vectores y los metadatos que los gobiernan.
chroma
Base de datos vectorial ligera y open source, ideal para prototipos y RAGs pequeños. Cero fricción para empezar; escala limitada cuando el corpus crece de verdad.
más información ↗qdrant
BD vectorial open source escrita en Rust, muy rápida filtrando por payload (metadatos) antes de la búsqueda semántica: exactamente el patrón prefiltro determinista que preconiza este sitio.
más información ↗weaviate
BD vectorial open source con módulos vectorizer: puede calcular el embedding ella misma en la ingesta. Buen punto medio entre flexibilidad y operación propia.
más información ↗pinecone
Vector DB totalmente gestionada (serverless) con inferencia de embeddings integrada. Cero operaciones a cambio de coste por uso y lock-in.
más información ↗pgvector
Extensión de PostgreSQL para vectores: SQL y similitud semántica en la misma base. El prefiltro determinista más potente del mercado (el WHERE va antes de la distancia) y sin añadir otra pieza a operar.
más información ↗milvus
BD vectorial open source distribuida para escala masiva. Cuando hablamos de cientos de millones de vectores, Milvus está en la conversación; la operación es su precio.
más información ↗mongodb atlas vector search
Búsqueda vectorial integrada en MongoDB Atlas: si tu aplicación ya vive en Mongo, tus vectores viven con tus documentos sin añadir otra base.
más información ↗faiss
Librería de Facebook AI Research para índices vectoriales rapidísimos. No es una base de datos: no trae metadatos ni persistencia de serie; tú montas el resto alrededor.
más información ↗elasticsearch
Motor de búsqueda con BM25 y kNN vectorial en el mismo índice: híbrido nativo sin pegar dos sistemas. Madurez enorme; operación no trivial.
más información ↗azure ai search
Servicio de búsqueda gestionado de Microsoft que trocea, embebe, indexa y busca en un solo pipeline (con skillsets e integrated embedding). Poderosísimo para entrar rápido; a cambio, lock-in y control fino limitado del chunking.
más información ↗