6. RAG — conocimiento corporativo

1 · QUÉ ES — PARA PROFANOS

El modelo no sabe nada de tu empresa. Reentrenarlo con tus documentos cuesta una fortuna y

cada cambio tardaría semanas. Y no puedes pegarle todo en el prompt: no cabe, y pagas por cada

token.

RAG es la solución de cajón: Recupera, Aumenta, Genera.

1. Recupera — buscas en tus documentos los trozos que tienen que ver con la pregunta.

2. Aumenta — los metes en el prompt junto con la pregunta.

3. Genera — el modelo responde solo con eso delante.

La metáfora médica: el modelo es el especialista; RAG es el historial del paciente abierto

por la página correcta antes de opinar. Sin historial, habla de memoria; con él, habla del caso.

Y como el especialista debe poder decir de qué página sacó cada afirmación, el RAG serio exige

citas.

Las piezas, en orden: ingesta → troceado (chunking) → embeddings → índice → búsqueda →

prompt con contexto → respuesta con cita.

El matiz que lo cambia todo en un banco: el mismo sistema que busca debe no enseñar a cada

empleado los documentos que no le tocan. Eso es "control de acceso a fuentes" — y la JD lo pide

literal.

El pipeline estándar: LangChain o LlamaIndex para el armazón, un modelo de embeddings

(text-embedding-3, bge-m3), y un motor vectorial (Pinecone, Azure AI Search, pgvector). La búsqueda

es híbrida: vector (significado) + BM25 (palabra exacta), fusionados con RRF y un reranker

encima.

Por qué híbrida y no solo vectorial: cada técnica falla donde la otra acierta. "T-17" no tiene

parecido semántico con nada; "¿qué hago si me duele?" no contiene la palabra "dolor". Solo las dos

juntas son fiables — esto es conocimiento estándar del sector desde 2024.

Los tres controles que un RAG serio lleva:, Control, Qué es, Qué pasa sin él,, Grounding, la respuesta debe citar el fragmento, el modelo "decora" y nadie lo nota,, Abstención, decir "no lo sé" cuando no está, inventa normativa con aplomo,, Control de acceso, filtrar por permisos antes de buscar, filtra información entre áreas — en banca, un incidente, ## 3 · NUEVAS TENDENCIAS

- GraphRAG: además de trozos, un grafo de entidades y relaciones. Responde mejor a preguntas

globales ("¿qué dicen TODOS los contratos sobre X?") que un RAG de trozos sueltos.

- RAG agéntico: el agente corrige su propia búsqueda — reformula la consulta si no encuentra,

busca de nuevo con otros términos, decide cuándo parar. La recuperación deja de ser un paso y se

convierte en un bucle controlado.

- Contexto largo contra RAG: los modelos de 1M+ tokens pueden tragarse libros enteros. La

discusión del sector ya no es "¿RAG sí o no?" sino "¿qué es más barato: recuperar bien o meterlo

todo?". La respuesta en 2026: recuperar bien gana — porque el coste crece con el contexto.

- Embeddings mejorados: Matryoshka (un mismo vector sirve para varias dimensiones) y vectores

binarios (memoria y latencia a la décima parte).

- Contextual retrieval (Anthropic): se añade contexto del documento a cada trozo antes de

indexar — mejora la recuperación sin cambiar el modelo.

No tenemos un RAG: tenemos SEIS, y cada uno existe por una decisión de diseño distinta.

RAG 1 · %RAG.m — TF-IDF en 41 líneas. Sin embeddings: un nodo de 242 MB de RAM no admite

cargar un modelo. 2.255 documentos · 1,79 M caracteres · 302 ms por consulta. La lección: no

siempre hace falta IA dentro del RAG.

RAG 2 · corpusrag.m — la saga troceada estructuralmente. Todo el corpus literario con

identificadores LIBRO:cNN:pK (libro:capítulo:página). El troceado es estructural: cada fragmento

sabe de dónde viene, y por eso se puede citar.

RAG 3 · vocesrag.m — RAG por personaje. 1.278 líneas de citas con VOCES:<slug>:<k>, cada

una con su libro y capítulo. La pregunta "¿cómo habla Ada?" se responde con las frases de Ada. Es

control de acceso llevado al extremo: el alcance es el personaje.

RAG 4 · ebvecload.m — el jerárquico con MiniLM. Embeddings de 384 dimensiones cuyo índice

es la propia jerarquía de rutas. Cuando la estructura ya existe, no hace falta motor vectorial

aparte — lo que la industria compra como "FAISS local con metadatos".

RAG 5 · Zalo — el híbrido de producción en edge. Tres niveles en cascada: bge-m3 + Vectorize

(topK 30) → FTS5 (15 documentos) → LIKE (5.000 caracteres), con deduplicación por contenthash.

Un solo índice falla; tres niveles no devuelven vacío. El sistema no responde "no encontrado"

cuando el dato existe.

RAG 6 · El clínico — recuperación dirigida por el auditor. En imagen médica, la búsqueda no va

por similitud semántica: va dirigida por el auditor clínico, porque lo relevante no es lo que se

parece, es lo que importa clínicamente.

Y los tres controles del sector, implementados:

- Control de acceso: filtro alcance por documento, aplicado en la consulta, no en el

prompt. Si el control está en el prompt, un cambio de redacción lo tira; si está en la consulta,

no hay prompt que lo desactive.

- Cita obligatoria: si la respuesta no está en el contexto recuperado, el modelo tiene que

decirlo. Sin cita, el resultado se descarta.

- Higiene de ingesta: deduplicación por hash antes de insertar, commit por proyecto, purga del

índice por lotes.

> "He hecho seis RAG distintos, y ninguno se parece al anterior: TF-IDF donde no cabía un modelo,

> un corpus troceado estructuralmente, un RAG por personaje con su alcance, uno jerárquico sin motor

> vectorial, y un híbrido de tres niveles en producción. Cada uno tiene una decisión de diseño

> detrás. Y el control de acceso lo hago en la recuperación, no en el prompt — que es exactamente

> donde la JD lo pide."

> "Diseñar e implementar arquitecturas RAG para integrar conocimiento corporativo con modelos

> generativos." · "Trabajar con embeddings, búsqueda semántica y vector databases." ·

> "Control de acceso a fuentes utilizadas por soluciones RAG."

La lectura: de todo el bloque técnico, RAG es la responsabilidad más concreta — y la última

frase, el control de acceso, es la que casi ningún candidato puede marcar. Es nuestro punto más

fuerte: lo tenemos implementado y en producción.

"¿Cómo controlas que un RAG no enseñe documentos sin permiso?"

> "En la recuperación, no en el prompt. Cada documento lleva un campo de alcance y la consulta

> filtra por él antes de llegar al modelo. Un mismo índice sirve a perfiles distintos sin duplicar

> el corpus, y un usuario no puede recibir un fragmento que no le toca aunque la búsqueda lo

> encuentre. La razón de hacerlo ahí: si el control está en el prompt, un cambio de redacción o un

> modelo distinto lo tira; si está en la consulta, no hay prompt que lo desactive."

"¿Cómo troceas los documentos?"

> "Depende del corpus. Para los libros, troceado estructural — capítulo:página — porque el

> fragmento debe saber de dónde viene para poder citarlo. Para documentos operativos, trozos con

> solape controlado. La regla que aplico: el trozo es una promesa de cita, no una unidad arbitraria.

> Si no puedes decir de dónde salió un trozo, no deberías indexarlo."

"¿Qué haces cuando la búsqueda no encuentra nada?"

> "Mi híbrido de producción tiene tres niveles en cascada: vectorial, texto completo y literal. Si

> el primero no devuelve, entra el segundo; si falla, el tercero. Y solo entonces, si de verdad no

> está, el sistema dice 'no lo sé' — con la obligación de decirlo, porque en normativa abstenerse

> vale más que improvisar. Un RAG que devuelve 'no encontrado' cuando el dato existe es un RAG roto

> de una forma muy concreta: tiene un solo índice."

"¿Qué métricas usarías para medir la calidad del RAG?"

> "Un conjunto dorado de unas 200 preguntas reales con su documento correcto etiquetado. Y cuatro

> cosas: que el documento correcto esté entre los primeros (recall@k), que la cita exista en el

> texto, que sepa abstenerse cuando no está, y que no pueda devolver nada sin permiso. El umbral

> que aplicaría: 85 % en el top cinco para desplegar, y tolerancia cero en fuga de permisos — la

> fuga no es calidad, es un incidente. No tengo ese número medido hoy, y prefiero decirlo a

> inventarlo: tengo el método y el umbral."