El diagrama RAG estandar se ha convertido en liturgia. Incrustar. Fragmentar. Almacenar en base de datos vectorial. Recuperar por similitud coseno. Meter en contexto. Generar.

Un punto de partida razonable. Tambien, para la mayoria de los sistemas que la gente realmente construye, la arquitectura equivocada.

No equivocada en teoria -- equivocada en practica. Equivocada en lo que cuesta operar, equivocada en donde coloca la inteligencia, y equivocada en lo que te exige mantener.

Construimos un sistema de recuperacion de documentos para la gobernanza de una cooperativa de viviendas noruega. El corpus: 48 documentos, 3.800 fragmentos de texto, una referencia legal de 800 paginas, 86 decisiones de junta a lo largo de tres anos. La pila: SQLite FTS5, cinco herramientas MCP, cero embeddings, cero bases de datos vectoriales. Huella total: 50 MB. Arranque: menos de 100 milisegundos. Busqueda: menos de 10 milisegundos.

Supera la alternativa vectorial que evaluamos. No en benchmarks -- en lo que importa: respuestas correctas, citadas, a preguntas reales, cada vez que un usuario abre una sesion.

Esta es la arquitectura, el razonamiento y los limites.

I. La pila de costos RAG

El pipeline canonico:

Documentos --> Fragmentacion --> Modelo de Embedding --> Vector DB --> Top-K --> LLM --> Respuesta

Cada caja es una dependencia. Cada dependencia tiene un costo:

  • Modelo de embedding: 2-3 GB (PyTorch mas pesos), compatibilidad de drivers GPU, ruleta de versiones CUDA
  • Base de datos vectorial: 500 MB-2 GB, con sus propios modos de fallo -- corrupcion de indice, presion de memoria, arranque en frio
  • Estrategia de fragmentacion: Semanas de ajuste. Fragmentos demasiado pequenos matan el contexto, demasiado grandes diluyen la relevancia
  • Calidad de embedding: La mayoria de los modelos priorizan ingles. Noruego, danes y fines obtienen resultados sistematicamente peores
  • Carga operacional: Deriva de embeddings al actualizar modelos, costos de reindexacion, monitoreo de calidad vectorial

Para 50.000 documentos multilingues, estos costos se justifican. La base de datos vectorial se gana su lugar.

Pero la mayoria de los equipos no construyen eso. Construyen bases de conocimiento internas, herramientas de cumplimiento, archivos de gobernanza, asistentes de investigacion legal, busqueda de documentacion tecnica. Cientos o pocos miles de documentos. Dominios especificos.

Y el consumidor al final del pipeline es un LLM.

Ese ultimo punto lo cambia todo.

II. Cuando el consumidor es un LLM

La busqueda tradicional sirve a un humano. Una consulta, diez resultados, reformular si nada parece correcto. El sistema debe ser inteligente porque el usuario tiene paciencia limitada y ninguna capacidad de procesar cincuenta resultados simultaneamente.

Un LLM es un consumidor fundamentalmente diferente.

Reformula autonomamente. Si "varmtvannssituasjonen" no devuelve nada, prueba "varmvannsberedere", luego "varmtvann", luego "beredere" -- en el mismo turno, sin intervencion humana. Un humano necesita busqueda semantica para cerrar brechas de vocabulario. Un LLM lo hace nativamente.

Sintetiza ampliamente. Dale quince fragmentos de diferentes documentos y teje una respuesta coherente con citas. Un humano necesita ranking perfecto. Un LLM necesita recall amplio.

Razona sobre metadatos. Dale fechas, tipos de documento, numeros de decision, y filtra, cruza referencias e infiere relaciones que ningun embedding captura.

Tolera ruido. Un fragmento irrelevante en posicion tres confunde a un humano. Un LLM lee los diez resultados y descarta lo que no encaja. La tolerancia al error es fundamentalmente diferente.

Esto conduce a un principio de diseno contraintuitivo:

Cuando el consumidor es un LLM, optimiza para velocidad, confiabilidad y amplitud de recall -- no para precision de ranking.
El LLM se encarga de la precision. Tu te encargas de la fontaneria. Deja de hacer la fontaneria inteligente.

III. El Patron Bibliotecario

Lo llamamos el Patron Bibliotecario: una capa de recuperacion rapida, confiable e intencionalmente simple. Encuentra documentos rapidamente. No resume, no interpreta, no valida. El LLM hace todo eso.

[Ingesta]
  Documentos --> Extractores --> Fragmentos + Metadatos Estructurados --> SQLite FTS5


[Ejecucion]
  LLM --> Llamada MCP --> Consulta SQLite (<10ms) --> Fragmentos Citados --> Razonamiento LLM

SQLite FTS5 maneja busqueda de texto completo con ranking BM25. Incluido en la biblioteca estandar de Python. Sin base de datos externa, sin proceso servidor, sin pool de conexiones. Abre en milisegundos.

Tablas de metadatos estructurados filtran por tipo de documento, fecha, categoria, autor. Las actas de junta llevan frontmatter YAML rico: fechas de reunion, IDs de agenda, numeros de decision, listas de asistentes, estado del documento. A nuestro tamano de corpus, estos metadatos son mas valiosos para la recuperacion que la similitud vectorial.

Herramientas MCP proveen la interfaz entre el LLM y la busqueda. El modelo llama search(query="obligaciones de mantenimiento", doc_type="reference") y recibe JSON con pasajes citados.

Intenciones de busqueda separadas estan codificadas en las descripciones de herramientas. El libro de referencia legal responde preguntas prospectivas: "Que dice la ley sobre X?" Las actas responden retrospectivas: "Que decidimos sobre X?" El LLM alcanza la fuente correcta naturalmente.

Lo que no construimos:

  • Ningun modelo de embedding (ahorramos 2-3 GB de dependencias)
  • Ninguna base de datos vectorial (ahorramos complejidad operacional)
  • Ninguna capa de matching semantico
  • Ningun motor de validacion
  • Ningun sistema de recomendacion
  • Ningun scoring de confianza

Cada componente que no construimos es un componente que no puede fallar, no puede derivar, y no puede sorprendernos a las 2 AM.

IV. La pregunta sobre busqueda semantica

La objecion obvia: la busqueda por palabras clave pierde conexiones semanticas. "Problemas de calefaccion" no coincide con "varmvannsberedere" (calentador de agua). Cierto -- cuando un humano escribe una consulta y mira los resultados.

En el Patron Bibliotecario, el LLM cierra esta brecha naturalmente:

Turno 1: search("problemas de calefaccion")  --> 0 resultados
Turno 2: search("varmvannsberedere")          --> 3 resultados
Turno 3: search("varmtvann")                  --> 5 resultados
Turno 4: Sintetizar todos los resultados con citas

Un turno de conversacion. Cuarenta milisegundos para tres busquedas. Mejor cobertura que una unica busqueda semantica -- porque el LLM explora el vocabulario con conocimiento de dominio que ningun embedding de 384 dimensiones captura.

Agregamos una mejora: fallback automatico a OR. Cuando una consulta AND de multiples palabras retorna cero resultados, el motor reintenta con logica OR. Seis lineas de codigo. Consultas que antes no devolvian nada ahora muestran secciones relevantes.

Cuando realmente necesitas vectores: corpus mas alla de unos 10.000 documentos donde el ranking BM25 se degrada, desajuste de vocabulario sistematico que el LLM no puede cerrar, recuperacion multilingue donde los embeddings manejan el cambio de idioma nativamente, o resultados para humanos donde la precision de ranking es critica.

Para todo lo demas -- y eso es la mayoria de los sistemas internos de conocimiento -- gana el Bibliotecario.

V. Metadatos como arquitectura

La similitud vectorial trata todo el texto como geometria. Una decision de junta y un requisito legal son ambos puntos en el espacio de embedding. La relacion entre ellos -- que uno es una decision y el otro es su base legal -- es invisible para la similitud coseno.

Los metadatos estructurados hacen estas relaciones consultables:

-- "Que decidimos sobre mantenimiento en 2025?"
SELECT * FROM decisions
WHERE description LIKE '%vedlikehold%'
AND date BETWEEN '2025-01-01' AND '2025-12-31';


-- "Que dice la ley sobre obligaciones de mantenimiento?"
SELECT * FROM chunks_fts
WHERE chunks_fts MATCH 'vedlikeholdsplikt'
AND doc_type = 'reference';

Preciso, rapido, determinista. Sin ranking probabilistico, sin temperatura, sin "el modelo a veces recupera lo incorrecto." El LLM decide que consulta ejecutar. La base de datos ejecuta fielmente.

Nuestras actas de junta llevan frontmatter con fechas de reunion, listas de asistentes, IDs de decision, estado del documento. Esto es mas rico que cualquier embedding. El LLM puede responder "Lista todas las decisiones de 2025 que mencionan presupuesto" en diez milisegundos. Ninguna base de datos vectorial iguala esta precision en consultas estructuradas.

VI. Los numeros

Metrica Bibliotecario (FTS5) RAG Estandar
Dependencias ~50 MB 2-3 GB
Arranque en frio <100ms 5-15 segundos
Latencia de busqueda <10ms 50-200ms
Huella de memoria <50 MB 500 MB-1 GB
Servicios en background Ninguno Modelo embedding + vector DB
Reindexacion Segundos Minutos a horas
Modos de fallo Disco lleno + deriva de embedding, corrupcion de indice, OOM

La diferencia de arranque no es academica. Un servidor MCP que tarda quince segundos en iniciar es una herramienta que se desactiva. Uno que arranca en 100 milisegundos se usa cada sesion.

VII. El marco de decision

Corpus pequeno (<5K)  Corpus grande (>10K)
                   +--------------------+--------------------+
  Consumidor LLM  |   BIBLIOTECARIO    |   HIBRIDO          |
                   |   FTS5 + metadata  |   FTS5 + vectores  |
                   +--------------------+--------------------+
  Consumidor      |   BUSQUEDA         |   RAG COMPLETO     |
  humano          |   FACETADA + UI    |   Pipeline estandar |
                   +--------------------+--------------------+

La ruta de actualizacion del Patron Bibliotecario: agrega una columna de embedding al mismo esquema SQLite, fusiona scores BM25 y vectoriales. Una a dos horas de trabajo, no una reescritura.

Abandona este patron cuando tu corpus pase de 10K documentos y la busqueda por palabras devuelva demasiado ruido. Abandonalo cuando la recuperacion multilingue sea tu caso de uso primario. Abandonalo cuando humanos -- no modelos -- consuman los resultados directamente y necesiten ranking pulido al primer intento.

Para todo lo demas, empieza con el Bibliotecario. Siempre puedes agregar vectores despues. No puedes quitarlos facilmente.

VIII. Donde debe vivir la inteligencia

La industria RAG paso tres anos construyendo recuperacion cada vez mas sofisticada: re-rankers, embeddings de documentos hipoteticos, expansion de consultas, cadenas de multiples etapas. Cada capa agrega inteligencia al pipeline.

Pero el LLM al final ya es el motor de razonamiento mas capaz disponible. Cada capa de inteligencia que agregas aguas arriba compite con -- y generalmente pierde ante -- lo que consume los resultados.

El Patron Bibliotecario invierte esto. Haz el pipeline simple, rapido y confiable. Dale al LLM datos limpios, buenos metadatos y herramientas rapidas. Dejalo razonar.

Es la misma claridad arquitectonica que dice "coloca la logica de negocio en la capa de aplicacion, no en la base de datos" o "coloca el rendering en el cliente, no en el servidor." Cada componente hace lo que mejor sabe hacer. La base de datos almacena y recupera. El LLM razona y sintetiza.

Cuando dejas de hacer tu pipeline de recuperacion inteligente, obtienes algo mejor: un sistema rapido, predecible, depurable y barato de operar. Un sistema donde el componente mas inteligente tiene acceso completo a todo lo que necesita, entregado en milisegundos, sin intermediarios probabilisticos entre la pregunta y la respuesta.

Un bibliotecario. No un colega. Rapido, confiable, y exactamente tan inteligente como necesita ser.

Validado en produccion. 48 documentos, 3.800 fragmentos, 86 decisiones, una referencia legal de 800 paginas. Cero embeddings. 50 MB en total. Respuestas en menos de 100 milisegundos.