Chatea con 1000+ PDFs en local: RAG a escala más allá de los ejemplos de prueba

Por qué el RAG predeterminado falla con más de 1.000 documentos

• Índice fuera de RAM: LanceDB, ChromaDB y FAISS comienzan todos en memoria residente. Cuando el índice supera la RAM disponible (típicamente 5-8 GB de vectores en un portátil de 16 GB), caen a lecturas en disco y la latencia p95 de consulta salta de ~300 ms a 1-3 segundos.
• El coseno solo falla en términos poco frecuentes: los embeddings densos infraponderan nombres propios poco comunes, nombres de medicamentos, números de estatutos e identificadores de código. Una consulta por "Section 230(c)(1)" recupera chunks sobre "Section 9" porque el embedding no puede distinguir la especificidad numérica. BM25 los captura; la búsqueda pura por coseno los pierde.
• Top-K de 4 es demasiado estrecho a escala: con 1.000 chunks, top-4 tiene un recall decente. Con 50.000 chunks, el mejor chunk suele estar en el rango 12-30, fuera de la ventana top-4. La recuperación parece funcionar (las respuestas son plausibles) pero se basa en pasajes incorrectos.
• Sin filtrado de metadatos se desperdicia el índice: preguntar "¿qué dijo Smith sobre X?" sobre un corpus de 10.000 documentos busca en todos los chunks del índice, cuando el sistema debería pre-filtrar primero a "documentos escritos por Smith". El RAG básico no tiene concepto de pre-filtrado por metadatos.
• El tamaño de chunk predeterminado de 512/0 fragmenta contextos largos: los párrafos de PDF y las secciones legales raramente caben en 512 tokens. El solapamiento predeterminado de 0 pierde significado entre fragmentos. El ajuste 1.000/200 soluciona esto para corpus medianos; se necesita chunking jerárquico más allá de 5.000 documentos.
• Drift de embedding en la actualización: cuando añades 1.000 nuevos PDFs tres meses después del índice original, las versiones del modelo de sentence-transformer pueden haber cambiado. Mezclar embeddings de dos versiones de modelo en un mismo índice degrada silenciosamente la recuperación — todas las arquitecturas fuerzan una reindexación completa al cambiar el embedder.

Árbol de decisión de arquitectura: elige primero por tamaño del corpus

• Menos de 1.000 documentos (menos de ~5.000 chunks): AnythingLLM Desktop con chunk size 1.000 / solapamiento 200 y nomic-embed-text-v1.5 como embedder. Sin código personalizado. Consulta la guía paso a paso de 30 minutos para la configuración.
• 1.000-5.000 documentos (5k-25k chunks): LlamaIndex en modo local con índices jerárquicos (DocumentSummaryIndex + VectorStoreIndex), Ollama como proveedor LLM, nomic-embed-text-v1.5 como embedder, LanceDB o ChromaDB como vector store. ~150 líneas de Python, funciona como proceso de larga duración.
• 5.000-10.000 documentos (25k-50k chunks): Stack personalizado con Ollama, ChromaDB, búsqueda híbrida BM25 mediante Whoosh o Tantivy, y un reranker BGE-reranker-v2-m3 sobre los 50 mejores candidatos. ~300-400 líneas de Python. El reranker es imprescindible a esta escala.
• 10.000+ documentos (50k+ chunks): Ollama + Qdrant en modo single-node con filtrado de metadatos basado en payload, búsqueda híbrida usando vectores sparse nativos de Qdrant, BGE-reranker-v2-m3 e índice de resúmenes jerárquico por IDs de documento. Configuración de grado producción para usuario único.
• Multi-usuario (cualquier escala): Open WebUI delante de cualquiera de las anteriores, O un pequeño wrapper FastAPI alrededor del mismo backend Qdrant + Ollama. El multi-usuario cambia el enfoque operativo (auth, aislamiento, rate limiting) pero no la arquitectura de recuperación.

Tabla comparativa de arquitecturas

Opción 1: AnythingLLM ajustado (100-1.000 docs)

• LLM: Llama 3.3 8B Q4_K_M vía Ollama (5 GB RAM durante la inferencia). En sistemas con 24 GB+, Qwen 2.5 14B Q4 mejora notablemente la síntesis.
• Embedder: cambia del predeterminado de AnythingLLM a nomic-embed-text-v1.5 vía Ollama. El embedder predeterminado es la razón principal por la que existen informes de "AnythingLLM no escala".
• Chunking: 1.000 tokens con solapamiento de 200 tokens, configurado por workspace en los ajustes de Vector Database. El predeterminado 512/0 es incorrecto para cualquier corpus más grande que unas pocas decenas de documentos.
• Top-K: aumenta del predeterminado 4 a 6-8. Con 1.000 documentos, el mejor chunk suele estar en el rango 5-7, y el LLM puede ignorar chunks débiles mejor de lo que puede inventar los que faltan.
• Partición por workspace: crea un workspace por categoría de documento (artículos, contratos, notas). Cada workspace tiene un LanceDB indexado por separado; las consultas entre workspaces no están soportadas, pero el recall por workspace es mucho mayor que en un único pool grande.

Opción 2: LlamaIndex local (1.000-5.000 docs)

• Stack: Ollama + LlamaIndex + LanceDB (o ChromaDB) + nomic-embed-text-v1.5 vía el adaptador OllamaEmbedding. Persistido en disco; funciona como un proceso Python de larga duración con el que interactúas mediante CLI o un pequeño wrapper FastAPI.
• DocumentSummaryIndex sobre VectorStoreIndex: LlamaIndex construye un resumen por documento en tiempo de indexación, y luego la recuperación primero selecciona documentos relevantes (búsqueda de resúmenes) y solo entonces busca chunks dentro de esos documentos. Es el patrón de recuperación jerárquica más barato.
• Enrutamiento de consultas: RouterQueryEngine envía consultas de recuperación de hechos al índice de chunks y consultas de síntesis al índice de resúmenes. ~30 líneas de código; duplica la calidad de respuesta en corpus de documentos largos.
• Recuperación por ventana de oraciones: un segundo índice opcional que recupera una oración objetivo más N oraciones circundantes. Útil para corpus legales y académicos donde la respuesta es una oración pero su significado depende del párrafo alrededor.
• Persistencia: index.storage_context.persist(persist_dir=...) guarda todo. El tiempo de recarga en un índice de 5.000 documentos es de 10-30 segundos en NVMe SSD.

# Minimal LlamaIndex local RAG with hierarchical indices (~30 lines)
from llama_index.core import VectorStoreIndex, DocumentSummaryIndex, SimpleDirectoryReader
from llama_index.embeddings.ollama import OllamaEmbedding
from llama_index.llms.ollama import Ollama
from llama_index.core import Settings

Settings.llm = Ollama(model="llama3.3:8b-instruct-q4_K_M", request_timeout=120)
Settings.embed_model = OllamaEmbedding(model_name="nomic-embed-text:latest")
Settings.chunk_size = 1000
Settings.chunk_overlap = 200

docs = SimpleDirectoryReader("./pdfs").load_data()

# Summary index for routing + chunk index for retrieval
summary_index = DocumentSummaryIndex.from_documents(docs)
chunk_index = VectorStoreIndex.from_documents(docs)

summary_index.storage_context.persist("./storage/summary")
chunk_index.storage_context.persist("./storage/chunks")

# At query time, route by question type
response = chunk_index.as_query_engine(similarity_top_k=8).query(
    "What sample size did Smith et al. use?"
)
print(response)

Opción 3: Ollama + ChromaDB personalizado (5.000-10.000 docs)

• Stack: Ollama + ChromaDB (modo servidor) + Whoosh o Tantivy para BM25 + BGE-reranker-v2-m3 (~570 MB, funciona en CPU a 50-100 candidatos/seg). Hospedado como un único proceso Python o dividido en workers de ingest + consulta.
• Búsqueda híbrida en tiempo de recuperación: ejecuta BM25 y recuperación densa por vector en paralelo, toma los top-25 de cada uno, deduplica y luego reordena el top-50 combinado con el cross-encoder. El top-K final de 6-8 va al LLM.
• Campos de metadatos de ChromaDB: rellena source_filename, page_number, document_type, author, year en cada chunk en tiempo de indexación. El filtrado en tiempo de consulta (where={"document_type": "contract"}) reduce el espacio de búsqueda de recuperación entre 5 y 10 veces sin pérdida de calidad.
• Indexación por lotes: ChromaDB genera embeddings en lotes de 32-128 chunks. En una RTX 4070, el BGE-reranker es el cuello de botella (50-100 candidatos/seg en CPU; 400+/seg en GPU).
• Persistencia: ChromaDB escribe en un directorio SQLite + Parquet. Un índice de 50.000 chunks en disco es ~3-5 GB. La copia de seguridad es una copia del directorio.

Opción 4: Ollama + Qdrant (10.000+ docs)

• Stack: Ollama + Qdrant (Docker, single-node) + vectores sparse nativos (equivalente BM25 integrado en Qdrant 1.10+) + BGE-reranker-v2-m3 + una pequeña capa de orquestación Python.
• Híbrido nativo: Qdrant soporta vectores densos + sparse en una misma colección, con fusión ponderada en tiempo de consulta. Sin proceso BM25 separado que mantener.
• Ajuste HNSW: con 50.000+ vectores, aumenta ef_construct a 200 y m a 32 para la construcción del índice, y usa ef=128 en tiempo de consulta. Los valores predeterminados funcionan pero intercambian ~10% de recall por velocidad de construcción.
• Esquemas de payload para filtrado: Qdrant trata los payloads como ciudadanos de primera clase. Indexa author, document_type, year y tags como keyword payloads para habilitar pre-filtrado en submilisegundos.
• Recuperación jerárquica: mantén dos colecciones — summaries (un vector por documento) y chunks (los habituales). Enruta las consultas primero a través de la colección de resúmenes, luego busca chunks dentro de los IDs de documento coincidentes.
• Persistencia: Qdrant escribe en un único volumen montado. Una colección de 100.000 chunks ocupa ~6-12 GB en disco según el tamaño del payload y los ajustes HNSW.

# Qdrant collection with dense + sparse vectors and metadata filtering
from qdrant_client import QdrantClient
from qdrant_client.models import (
    Distance, VectorParams, SparseVectorParams, SparseIndexParams
)

client = QdrantClient(host="localhost", port=6333)

client.create_collection(
    collection_name="docs",
    vectors_config={
        "dense": VectorParams(size=768, distance=Distance.COSINE),  # nomic-embed-text-v1.5
    },
    sparse_vectors_config={
        "bm25": SparseVectorParams(index=SparseIndexParams(on_disk=False)),
    },
)

# Query: hybrid search + payload filter, no separate BM25 process needed
from qdrant_client.models import Filter, FieldCondition, MatchValue, Prefetch

results = client.query_points(
    collection_name="docs",
    query=dense_vec,
    using="dense",
    prefetch=[
        Prefetch(query=sparse_vec, using="bm25", limit=25),
        Prefetch(query=dense_vec, using="dense", limit=25),
    ],
    query_filter=Filter(
        must=[FieldCondition(key="document_type", match=MatchValue(value="contract"))]
    ),
    limit=50,  # before rerank
)

Búsqueda híbrida: BM25 + Vector supera a cualquiera de los dos por separado

• Por qué el denso por sí solo falla: los embeddings infraponderan tokens poco frecuentes. Consultas como "RFC 9110 sección 7.4" o "MNDA-2024-0143" se embeben cerca de chunks IETF/contrato genéricos. BM25 captura el identificador exacto; la búsqueda pura por coseno lo pierde.
• Por qué BM25 por sí solo falla: la coincidencia léxica pierde paráfrasis. Una consulta "¿Cómo cancelamos?" contra un chunk titulado "Procedimientos de rescisión" coincide en el espacio denso pero puntúa 0 en BM25.
• Reciprocal Rank Fusion (RRF) es el combinador estándar: para cada chunk que aparece en cualquiera de las listas de resultados, puntúalo como 1/(60+rank_dense) + 1/(60+rank_bm25). Ordena en forma descendente. El 60 es una constante de suavizado; valores entre 30-100 funcionan en la práctica.
• Receta práctica: recupera los top-25 de cada método, combina vía RRF, toma los top-50, envía a un reranker y luego los top-6-8 al LLM. Este es el pipeline estándar de producción a cualquier escala más allá de 1.000 documentos.
• Coste de almacenamiento: los índices BM25 son pequeños (~50-150 MB por 10.000 documentos) en comparación con los índices densos (~500 MB-2 GB a la misma escala). Añadir BM25 a un store denso existente es económico.

Reranking: El paso de refinamiento Top-N

• BGE-reranker-v2-m3 (~570 MB, multilingüe, Apache 2.0) es la elección predeterminada en mayo de 2026. Funciona a 50-100 candidatos/seg en una CPU moderna; 400+ /seg en GPU. El coste de latencia para reranking de top-50 es ~200-500 ms en CPU, ~80-150 ms en GPU.
• Por qué los cross-encoders ganan en recuperación: los embeddings densos codifican la consulta y el documento de forma independiente, por lo que el modelo nunca los ve juntos. Un cross-encoder lee `[CLS] consulta [SEP] candidato [SEP]` conjuntamente y puntúa el par directamente. Recall@5 típicamente salta 15-25 puntos.
• Dónde inyectar el reranker: después de la búsqueda híbrida, antes del LLM. Toma los top-50 del híbrido, reordena a top-6-8, y envía esos al LLM como contexto.
• Alternativa — Cohere Rerank API: mayor calidad pero requiere una llamada a la nube. Para stacks completamente locales, BGE-reranker-v2-m3 es el predeterminado práctico. mxbai-rerank-base-v2 es un fuerte candidato alternativo.
• Omitir el reranker está bien bajo 1.000 documentos: la ganancia de calidad no justifica el coste de latencia. Más allá de 5.000 documentos, omitirlo deja ~15-25% de las respuestas basadas en los chunks incorrectos.

Filtrado de metadatos: Pre-reduce el espacio de búsqueda

• Campos de payload universales a rellenar en tiempo de indexación: source_filename, page_number, document_type (artículo / contrato / nota / wiki), author, year, language, más etiquetas específicas del dominio (p.ej., case_number, project_id, client_id).
• Pre-filtro en tiempo de consulta: "¿Qué dijo el acta del consejo del Q3 2024 sobre precios?" → filtra document_type=board_minutes AND year=2024 AND quarter=3 primero, luego búsqueda vectorial dentro de ~12 documentos en lugar de los 10.000.
• Soporte del vector store: los payloads de Qdrant, las propiedades de Weaviate, los metadatos de ChromaDB y las columnas de esquema de LanceDB soportan todos el filtrado. El rendimiento varía — el filtrado de payload de Qdrant en campos indexados es de submilisegundos; el filtrado de metadatos de ChromaDB en >100k chunks puede añadir 50-150 ms.
• Auto-extracción de metadatos: para corpus legales, un pequeño paso de LLM en tiempo de indexación puede extraer números de caso, fechas y nombres de partes por documento. Cuesta ~30 segundos por documento en Llama 3.3 8B; se ejecuta una vez por ingest.
• Combina con búsqueda híbrida: el filtro de payload reduce el universo → recuperación BM25 + densa dentro del conjunto filtrado → rerank. El filtro de payload es la aceleración más barata de 5-10 veces en cualquier sistema RAG grande.

Recuperación jerárquica: resumen primero, chunks después

• Resúmenes por documento: en tiempo de indexación, pide al LLM que escriba un resumen de 100-200 tokens de cada documento. Genera embeddings de esos resúmenes en una colección summaries separada. El coste es ~30-90 segundos por documento en Llama 3.3 8B.
• Recuperación en dos etapas: (1) genera el embedding de la consulta, busca en summaries, toma los top-5 documentos; (2) dentro de esos 5 documentos, recupera los top-8 chunks vía búsqueda híbrida; (3) aplica reranking si es necesario; (4) envía al LLM.
• Cuándo ayuda más: consultas de síntesis y multi-documento ("compara cómo estos artículos abordan X"). La recuperación de hechos ("¿qué valor reportó Smith?") funciona bien solo con el índice de chunks — el desvío por el resumen añade latencia sin ganancia de calidad.
• Compensación de coste: duplica el almacenamiento del índice (los resúmenes son pequeños pero el índice en sí es infraestructura duplicada). Duplica la latencia para consultas no enrutadas. La ganancia está en la reducción de ruido a partir de 10.000+ documentos.
• LlamaIndex lo incorpora: DocumentSummaryIndex más RouterQueryEngine es una implementación de 30 líneas. Python personalizado con ChromaDB o Qdrant es ~80-120 líneas.

Benchmarks medidos a 100, 1.000 y 10.000 documentos

Dimensionamiento de almacenamiento y requisitos de hardware

• Texto bruto por 1.000 PDFs (~12 páginas cada uno): ~50-150 MB de texto extraído. Altamente variable según la densidad.
• Vectores a 1.000 docs: ~300-400 MB en disco incluyendo el overhead del índice HNSW. ~120-180 MB si omites el índice HNSW y usas búsqueda por fuerza bruta (aceptable por debajo de 5.000 docs).
• Vectores a 10.000 docs: ~3-5 GB en disco. La construcción HNSW lleva 10-30 minutos en una CPU moderna.
• Vectores a 50.000 docs: ~15-25 GB en disco. El tiempo de construcción del índice es el cuello de botella — planifica 2-4 horas de trabajo de CPU por única vez.
• RAM durante la consulta: la recuperación densa necesita ~30-50% del índice en memoria de trabajo para consultas de baja latencia. Un índice de 5 GB se consulta cómodamente con 8-16 GB de RAM con HNSW; la fuerza bruta necesita el índice completo en memoria.
• RAM durante la indexación: sube a 2-3 veces el tamaño del modelo de embedding (~600 MB para nomic-embed-text) más el texto por lote. 8 GB de RAM libre es suficiente para el paso de indexación.
• GPU vs CPU: el throughput de embedding es 4-8 veces más rápido en una GPU discreta o Apple Silicon. Para indexación de un solo paso con 10.000+ documentos, la GPU ahorra 1-3 horas. Para el embedding en tiempo de consulta (una consulta a la vez), la CPU es suficiente.
• El tipo de disco importa: NVMe SSD es el mínimo práctico a partir de 5.000+ documentos. SATA SSD añade 30-100% a la latencia de consultas en frío; el disco giratorio es inutilizable más allá de ~2.000 documentos.

Indexación incremental y deduplicación

• Dedup exacto basado en hash en ingest: SHA-256 de los bytes brutos del archivo. Omite archivos cuyo hash ya está en el índice. Barato, captura archivos idénticos pero pierde casi-duplicados (diferentes pasadas OCR del mismo escaneo, conversiones de formato).
• Dedup por hash de contenido: SHA-256 del texto plano extraído tras eliminar espacios en blanco. Captura el mismo documento en diferentes formatos de archivo. Añade ~5 ms por archivo en el ingest.
• MinHash para casi-duplicados: para corpus legales y académicos donde se acumulan múltiples borradores del mismo documento, calcula una firma MinHash (~128 bytes por documento) y omite archivos dentro de un umbral de similitud Jaccard de una entrada existente.
• Los IDs de documento son permanentes: nunca reutilices un ID de documento después de eliminarlo. Los vector stores a menudo retienen vectores huérfanos brevemente; reutilizar IDs causa confusión silenciosa. Usa UUIDs o IDs basados en hash.
• Re-embedding al cambiar el embedder: todas las arquitecturas fuerzan una reindexación completa cuando cambias el modelo de embedding. Planifica una elección de embedder a la que te comprometas durante al menos un año antes de indexar 10.000 documentos.
• Eliminaciones: ChromaDB y Qdrant soportan la eliminación de puntos por ID. LanceDB requiere un paso de compactación para recuperar espacio en disco — planifícalo semanalmente si eliminas más de ~5% del corpus por mes.

Supervisión de la calidad RAG a escala

• Construye un conjunto dorado pequeño: 30-50 consultas para las que conoces la respuesta correcta, extraídas de uso real. Incluye recuperación de hechos (5-10), síntesis (5-10), entre documentos (5-10), casos límite (5-10) y consultas de miss conocido (5-10) donde la respuesta no está en el corpus.
• Rastrea tres métricas por consulta: recall de recuperación (¿apareció el chunk correcto en el top-K?), fidelidad de generación (¿la respuesta coincide con el chunk?) y tasa de rechazo (¿el sistema dice correctamente "no está en el corpus" para consultas de miss conocido?).
• Vuelve a ejecutar en cada cambio significativo: nuevos lotes de ingest, cambios de embedder, cambios de tamaño de chunk, ajustes de prompt. Compara los resultados con la ejecución anterior; marca cualquier consulta cuyo recall de recuperación o respuesta haya cambiado.
• Trulens o RAGAS para frameworks de evaluación automatizada. Ambos se ejecutan localmente e integran con LlamaIndex. La puntuación manual de 30-50 consultas también es válida y a menudo más precisa.
• Presupuestos de latencia: rastrea la latencia de consulta p50 y p95 a lo largo del tiempo. Un salto del 50% en p95 típicamente significa que el índice ha superado la RAM — la señal temprana de que necesitas pasar al siguiente nivel de arquitectura.

Preguntas frecuentes

Lecturas relacionadas

• AnythingLLM vs PrivateGPT vs Open WebUI: El mejor RAG local en 2026 — contexto base para elegir la plataforma RAG de escritorio antes de escalar.
• Los mejores modelos de embedding para RAG local en 2026 — la elección del embedder es la decisión individual más importante antes de indexar 10.000 documentos.
• RAG local para datos empresariales privados — escalada natural cuando el RAG a escala personal se encuentra con requisitos de cumplimiento empresarial.
• Construye RAG local en tus PDFs en 30 minutos (Ollama + AnythingLLM) — la configuración de nivel básico antes de llegar al precipicio de escalado.
• RAG explicado: Cómo anclar las respuestas de la IA en datos reales (2026) — autoridad conceptual sobre qué es RAG y por qué importa cada componente de recuperación.
• Guía de hardware para LLM local 2026 — referencia de dimensionamiento de hardware para corpus de 10.000+ documentos.
• Hub Power Local LLM — biblioteca completa de guías del clúster.