RAG empresarial: el pipeline completo que realmente funciona

Cualquier empresa tiene conocimiento valioso atrapado en documentos: políticas internas, contratos, manuales técnicos, histórico de tickets de soporte, especificaciones de producto. RAG es el mecanismo que conecta ese conocimiento con un modelo de lenguaje para que pueda usarlo en tiempo real. La pregunta no es si implementar RAG — es cómo construirlo bien desde el principio para que ese conocimiento sea realmente accesible y preciso. En este post explico el pipeline completo con las decisiones que más importan, en el orden en que importan.

El pipeline completo de un vistazo

Antes de entrar en cada decisión, vale la pena tener la arquitectura completa clara. La mayoría de los equipos que he visto construir su primer RAG avanzan componente a componente sin ver el sistema entero, y eso lleva a optimizar lo que no necesita optimización mientras se ignora lo que realmente falla.

1.00

El diagrama deja claro dónde interviene cada decisión: el chunking ocurre en la ingesta, los embeddings transforman los chunks antes de almacenarlos, el hybrid search opera en el momento del retrieval, el reranking reordena los resultados antes de construir el contexto, y la evaluación observa cada etapa. Cada una de esas decisiones tiene un impacto diferente en el resultado final. Las dos primeras — chunking y embeddings — son la base del sistema y determinan el techo de calidad que cualquier optimización posterior puede alcanzar.

La base del sistema: chunking semántico

Lo primero que implementé fue el chunking semántico, y es donde más diferencia vi respecto a lo que había construido antes. La mayoría empieza partiendo documentos cada N caracteres porque es lo más simple de implementar. El problema es que eso destroza el contexto: una idea que ocupa tres párrafos queda fragmentada en trozos que por separado no significan nada.

Para que sea concreto: un manual técnico que describe un procedimiento de cuatro pasos puede quedar partido a la mitad del segundo paso. El chunk que contiene los pasos 1-2 (incompleto) y el chunk que contiene los pasos 3-4 (sin el contexto de los primeros) son inútiles para el retrieval. Cuando el usuario pregunta cómo ejecutar ese procedimiento, el sistema recupera fragmentos que no responden nada por sí solos.

El chunking semántico respeta la estructura del documento — secciones, párrafos, entidades completas — y produce fragmentos que tienen significado propio.

Para que se vea la diferencia sin código, toma el siguiente párrafo de una política interna real:

“El proceso de aprobación de órdenes de compra por encima de 50.000€ requiere validación del área técnica en un plazo máximo de 48 horas. Si transcurrido ese plazo no hay respuesta, la orden queda en estado bloqueado y debe ser escalada al director de operaciones para su resolución.”

Chunking por caracteres (chunk de 150 chars):

El proceso de aprobación de órdenes de compra por encima de 50.000€ requiere validació
n del área técnica en un plazo máximo de 48 horas. Si transcurrido ese plazo no hay re
spuesta, la orden queda en estado bloqueado y debe ser escalada al director de operacio
nes para su resolución.

Chunking semántico (párrafo completo como unidad):

El proceso de aprobación de órdenes de compra por encima de 50.000€ requiere validación del área técnica en un plazo máximo de 48 horas. Si transcurrido ese plazo no hay respuesta, la orden queda en estado bloqueado y debe ser escalada al director de operaciones para su resolución.

No hace falta explicación. Un fragmento tiene sentido. Los otros cuatro no.

Las tres estrategias y cuándo usar cada una

Estrategia	Casos de uso	Ventajas	Limitaciones
Por caracteres	Prototipado rápido, corpus homogéneo y denso	Simple, sin dependencias externas	Rompe el contexto, produce chunks sin significado semántico
Por tokens	Corpus donde importa respetar límites del LLM	Alineado con la ventana de contexto del modelo	No respeta estructura semántica del documento
Semántico	Documentos empresariales, técnicos, contratos, políticas	Preserva contexto, mejora precisión del retrieval de forma visible	Requiere más configuración inicial y conocimiento del corpus

La estrategia correcta depende del tipo de documentación. Para documentos con estructura clara — contratos, manuales, políticas con secciones definidas — el chunking por secciones o párrafos funciona bien porque la estructura ya delimita las unidades semánticas. Para documentos de texto libre — emails, notas, registros de conversaciones — se necesita un enfoque más cuidadoso que use señales contextuales (cambios de tema, puntos de inflexión en el argumento) para determinar los límites del chunk. Para documentos mixtos — políticas con tablas y párrafos narrativos — el mejor resultado viene de tratar cada tipo de contenido con su propia lógica de fragmentación.

El overlap: necesario, pero no arbitrario

El overlap — solapar parte del contenido entre chunks adyacentes — compensa el riesgo de que un límite de chunk corte justo en medio de una idea que se expande de un párrafo al siguiente. Sin overlap, si la información relevante cae entre dos chunks, el retrieval la pierde.

El tamaño correcto de overlap no es un número fijo. Depende del tipo de documento y de la longitud típica de las frases que conectan ideas adyacentes. En documentación técnica con párrafos densos, un overlap de 10-15% del tamaño del chunk suele funcionar bien. En documentos con secciones muy independientes (como un FAQ con preguntas separadas), el overlap puede ser mínimo o nulo.

Lo que hay que evitar es overlap tan grande que los chunks sean casi duplicados — eso no ayuda al retrieval, solo infla el vector store y añade ruido.

Estrategia de embeddings: la decisión con más impacto

El chunking determina la estructura de lo que almacenas. El modelo de embedding determina si el retrieval puede encontrarlo.

No todos los modelos de embedding capturan igual de bien todos los dominios. Un modelo genérico entrenado en texto general puede funcionar perfectamente para documentación en inglés sobre temas comunes y fallar sistemáticamente con terminología interna de una empresa — siglas propias, nombres de producto, jerga de negocio específica.

En un proyecto real me encontré con este problema de frente. El sistema recibía preguntas sobre “OC urgentes pendientes de validar por el área técnica”. El modelo de embedding genérico no asociaba “OC” (orden de compra, término interno del cliente) con el concepto de “purchase order” ni con “pedido” — los vectores caían en un espacio semántico diferente al de los documentos donde la información estaba almacenada como “órdenes de compra” o “pedidos de aprovisionamiento”. El retrieval devolvía cero resultados relevantes para una consulta que tenía respuesta directa en el corpus.

La solución no fue afinar el chunking ni ajustar el hybrid search. Fue cambiar el modelo de embedding por uno evaluado sobre una muestra real del vocabulario del cliente.

Cómo elegir el modelo correcto antes de construir todo encima

La prueba que uso siempre antes de comprometer un modelo de embedding: tomar 20-30 preguntas representativas del caso de uso real, junto con los documentos que contienen las respuestas, y medir si el modelo posiciona esos documentos en los primeros resultados del retrieval. No hace falta un framework de evaluación completo para esto — es una prueba manual que tarda una tarde y puede ahorrar semanas de trabajo construido sobre una base equivocada.

Si los documentos correctos no aparecen en los primeros 5 resultados en más del 70% de las preguntas, el modelo de embedding no es el adecuado para ese corpus. No hay optimización posterior que lo compense.

Open-source vs API, y los trade-offs reales

Los modelos open-source como los de la familia sentence-transformers, E5 o BGE tienen la ventaja de ejecutarse localmente y no depender de un proveedor externo — lo que importa si el corpus es confidencial. Los modelos de API como los de OpenAI o Cohere ofrecen embeddings de alta calidad sin gestión de infraestructura.

El factor que más cambia la ecuación no es la calidad abstracta del modelo sino el coste según en qué momento del pipeline se ejecuta. En tiempo de ingesta, los embeddings se generan una vez por documento y el coste de latencia no es crítico. En tiempo de retrieval, los embeddings se generan en cada consulta del usuario y la latencia sí importa. Un modelo que tarda 500ms en generar un embedding puede ser aceptable para ingesta y completamente inviable para retrieval en tiempo real.

Vector stores: la elección correcta según contexto

Vector store	Escenario ideal	Ventaja principal	Limitación
Chroma	Desarrollo, corpus mediano, setup local	Cero configuración, iterar rápido	No diseñado para escala de producción
Pinecone	Corpus grande, producción, equipo sin ops	SaaS managed, escala sin gestión de infraestructura	Coste en corpus muy grande, dependencia de proveedor
Weaviate	Control sobre infraestructura, hybrid search nativo	Open-source, módulo BM25 integrado	Más operaciones que Chroma
pgvector	Ya tienes PostgreSQL en producción	Añade capacidad vectorial sin nueva infraestructura	No optimizado para retrieval vectorial puro a gran escala

La elección correcta cruza tres dimensiones: tamaño del corpus, necesidad de escala y simplicidad de setup. Para la fase inicial, Chroma permite iterar sin fricción. Para producción con corpus grande, Pinecone o Weaviate son opciones más sólidas. Si el equipo ya gestiona PostgreSQL y el corpus no supera cierto umbral, pgvector es la opción con menor coste operativo.

Las optimizaciones que multiplican el retrieval

Con el chunking y los embeddings bien configurados, el sistema ya debería recuperar información relevante en la mayoría de los casos. Lo que falta es resolver los casos que la búsqueda semántica no puede manejar sola, y mejorar la calidad del contexto que llega al LLM.

Hybrid search: cuando la semántica sola no alcanza

La búsqueda semántica es excelente para encontrar información relacionada por significado. Falla cuando la consulta contiene términos técnicos específicos, nombres propios, códigos de producto o siglas internas que el modelo de embedding no asocia directamente con los documentos correctos.

El caso concreto que me hizo entender por qué necesitaba hybrid search: buscaba “RMA-2024-0392” — el número de un expediente de devolución — y el retrieval semántico devolvía documentos relacionados con devoluciones en general pero no el expediente concreto. Tiene todo el sentido: “RMA-2024-0392” no tiene vecinos semánticos obvios en el espacio vectorial. Es una cadena de texto exacta que existe o no existe en los documentos.

BM25 resuelve exactamente ese caso. La búsqueda por término exacto con BM25 encuentra el documento que contiene “RMA-2024-0392” con precisión quirúrgica.

Combinar ambos — semántico para preguntas conceptuales, BM25 para términos exactos — produce un retrieval que cubre los dos casos sin sacrificar ninguno. El resultado es un sistema que encuentra información tanto por significado como por términos exactos.

La implementación del retrieval híbrido en Python tiene esta estructura:

# Hybrid retrieval: semántico + BM25 con pesos configurables
from rank_bm25 import BM25Okapi
import numpy as np

def hybrid_retrieve(query: str, chunks: list[str], embedder, vector_store,
                    alpha: float = 0.5, top_k: int = 20) -> list[str]:
    """
    alpha: peso del retrieval semántico (0.0 = solo BM25, 1.0 = solo semántico)
    """
    # Retrieval semántico
    query_embedding = embedder.encode(query)
    semantic_results = vector_store.similarity_search_with_score(
        query_embedding, k=top_k
    )
    semantic_scores = {doc_id: score for doc_id, score in semantic_results}

    # Retrieval BM25
    tokenized_corpus = [chunk.lower().split() for chunk in chunks]
    bm25 = BM25Okapi(tokenized_corpus)
    bm25_scores_raw = bm25.get_scores(query.lower().split())

    # Normalizar scores a [0, 1]
    sem_max = max(semantic_scores.values(), default=1)
    bm25_max = bm25_scores_raw.max() or 1

    combined = {}
    for i, chunk in enumerate(chunks):
        sem = semantic_scores.get(i, 0) / sem_max
        bm25_score = bm25_scores_raw[i] / bm25_max
        combined[i] = alpha * sem + (1 - alpha) * bm25_score

    top_indices = sorted(combined, key=combined.get, reverse=True)[:top_k]
    return [chunks[i] for i in top_indices]

El parámetro alpha permite ajustar el peso de cada estrategia según el corpus. Para corpus con mucha terminología técnica exacta, bajar alpha hacia 0.3-0.4 da más peso al BM25. Para corpus de texto conceptual y libre, subirlo hacia 0.7-0.8 prioriza la semántica.

Reranking: mejorar la calidad del contexto antes del LLM

Después del hybrid search, los fragmentos recuperados están ordenados por una puntuación combinada de similitud. Ese orden no es necesariamente el que maximiza la calidad de la respuesta final — porque la similitud con el query no equivale a relevancia real para la pregunta concreta.

El reranking aplica un segundo modelo — más lento que el embedding pero más preciso en capturar relevancia — para reordenar esos fragmentos antes de construir el contexto que recibe el LLM. Hasta que añadí reranking no vi la diferencia real en preguntas complejas que requerían información de múltiples documentos. El modelo recibía contexto bien priorizado, y la calidad de las respuestas subió de forma visible.

El reranking aporta más valor cuando el corpus es grande (muchos candidatos para reordenar), las preguntas son complejas o multifacéticas, y el contexto que llega al LLM tiene un límite de tokens estricto. Cuando el corpus es pequeño y las preguntas son directas, puede omitirse en fases iniciales sin perder demasiado.

Modelos como Cohere Rerank o cross-encoders de sentence-transformers (por ejemplo cross-encoder/ms-marco-MiniLM-L-6-v2) son opciones comunes. Los cross-encoders open-source tienen la ventaja de no depender de APIs externas, lo que importa si el corpus es confidencial.

Evaluación continua: la capa que hace todo medible

Un RAG sin métricas opera a ciegas. No sabes si mejorar el chunking ayudó, si el nuevo modelo de embedding fue mejor opción, o si el reranking está haciendo algo. Las métricas son el mecanismo de feedback que convierte la construcción en un proceso iterativo.

Hay tres métricas que importan y que juntas dan una imagen completa de dónde falla el sistema:

Faithfulness: ¿la respuesta está fundamentada en los documentos recuperados o el modelo está inventando? Una respuesta puede ser correcta pero no estar respaldada por el contexto — eso es alucinación, aunque acierte. Esta métrica mide específicamente si el modelo inventa o si se apoya en lo que recuperó.

Answer relevancy: ¿la respuesta responde realmente la pregunta? No si es correcta en abstracto, sino si responde lo que el usuario preguntó. Un modelo puede generar una respuesta coherente y bien fundamentada que no responde la pregunta concreta.

Context precision: ¿los fragmentos recuperados son relevantes para la pregunta? Esta métrica diagnostica el retrieval independientemente de la generación — si context precision es baja, el problema está en el chunking, los embeddings o el hybrid search, no en el LLM.

La combinación de las tres permite diagnosticar en qué etapa del pipeline está el problema. Context precision baja apunta al retrieval. Faithfulness baja apunta a la generación o a un contexto insuficiente. Answer relevancy baja puede ser retrieval, generación, o cómo se construye el prompt final.

# Evaluación con RAGAS — las tres métricas principales
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision
from datasets import Dataset

def evaluar_pipeline_rag(preguntas, respuestas, contextos, respuestas_referencia):
    dataset = Dataset.from_dict({
        "question": preguntas,
        "answer": respuestas,
        "contexts": contextos,          # lista de listas: fragmentos recuperados por pregunta
        "ground_truth": respuestas_referencia
    })

    resultado = evaluate(
        dataset=dataset,
        metrics=[faithfulness, answer_relevancy, context_precision]
    )
    return resultado

# Umbrales de referencia para decidir si una iteración mejoró el sistema
UMBRALES = {
    "faithfulness": 0.85,       # por debajo: revisar generación o contexto insuficiente
    "answer_relevancy": 0.80,   # por debajo: revisar retrieval o construcción del prompt
    "context_precision": 0.75   # por debajo: revisar chunking o embeddings
}

Cuando una métrica cae, el orden de diagnóstico importa. Primero verificar context precision — si el retrieval no trae fragmentos relevantes, ningún ajuste posterior lo compensa. Si context precision está bien pero faithfulness cae, revisar si el contexto es suficiente para responder la pregunta o si el modelo está extrapolando. Si las dos primeras están bien y answer relevancy cae, el problema suele estar en cómo se construye el prompt final o en que el sistema recupera información relacionada pero no la específica que responde la pregunta.

Errores comunes al construir un RAG empresarial

Evaluar el modelo de embedding en un benchmark genérico, no en el corpus real

El error más frecuente que veo: elegir el modelo de embedding basándose en benchmarks públicos (MTEB, por ejemplo) sin validarlo sobre el vocabulario real del sistema. Los benchmarks miden rendimiento general — no capturan la terminología interna, siglas propias o patrones lingüísticos específicos de cada empresa. El modelo que lidera MTEB puede ser el peor para tu corpus particular. La validación manual con 20-30 preguntas representativas antes de comprometer el modelo es no negociable.

Chunk size fijo para todo el corpus

Aplicar el mismo tamaño de chunk a documentos con estructuras radicalmente diferentes — un contrato de 50 páginas, un email de 3 párrafos, una especificación técnica con tablas — produce resultados inconsistentes. Los documentos cortos quedan en un solo chunk gigante sin estructura; los documentos largos y complejos quedan fragmentados sin respetar sus unidades semánticas naturales. La solución es tener una estrategia de chunking por tipo de documento, no un parámetro global.

Ignorar la actualización del corpus

Un RAG empresarial trabaja con documentos que cambian: políticas que se actualizan, precios que varían, expedientes que se resuelven. Si el vector store no tiene una estrategia de re-ingesta, empieza a responder con versiones antiguas de la información y no hay forma de saberlo — el sistema responde con confianza pero con datos obsoletos.

La estrategia correcta es detectar documentos modificados (por hash, timestamp o señal explícita), eliminar sus chunks del vector store, re-procesar y reinsertar. Sin esto, el sistema se degrada silenciosamente con el tiempo.

Añadir reranking antes de validar el retrieval base

El reranking mejora el orden de fragmentos que ya recuperó el retrieval. Si el retrieval base no está trayendo los fragmentos correctos, el reranking no puede inventarlos. He visto equipos que añaden un cross-encoder esperando que resuelva problemas que en realidad están en el chunking o en el modelo de embedding. El diagnóstico correcto es siempre de abajo hacia arriba: chunking → embeddings → retrieval → reranking.

No tener un conjunto de test fijo antes de iterar

Sin un conjunto de preguntas de referencia con respuestas conocidas, cualquier cambio en el pipeline es un salto a ciegas. Puede parecer que mejora o empeora sin que haya forma de medirlo objetivamente. Construir ese conjunto de test — 50-100 preguntas representativas con sus respuestas esperadas — es la primera tarea antes de empezar a optimizar cualquier componente.

Framework de construcción por fases

El sistema completo no se construye de una vez. Las fases siguientes ordenan las decisiones de mayor a menor impacto, con criterios concretos para saber cuándo avanzar.

Fase 1 — Lo mínimo funcional

El objetivo de esta fase no es tener el mejor sistema posible, sino tener un sistema que funcione de forma medible y sobre el que se pueda iterar.

Chunking semántico adaptado al tipo de documentación del corpus
Modelo de embedding validado sobre una muestra de 20-30 preguntas representativas
Vector store local (Chroma) para iterar sin fricción operativa
Conjunto de test de 50-100 preguntas con respuestas de referencia
Evaluación básica de faithfulness y answer relevancy sobre ese conjunto

Criterio de avance: faithfulness > 0.80 y answer relevancy > 0.75 de forma estable en el conjunto de test. Si no se alcanzan esos umbrales, el problema está en el chunking o en los embeddings — no en lo que venga después.

Fase 2 — Optimizar el retrieval

Con la base validada, las optimizaciones de retrieval tienen un baseline claro para medir su impacto.

Hybrid search (semántico + BM25) con alpha ajustado al tipo de corpus
Reranking para preguntas complejas o cuando el contexto tiene límite estricto de tokens
Vector store con capacidad de producción si el corpus supera los 100K documentos
Métricas extendidas: añadir context precision al conjunto de evaluación

Criterio de avance: mejora medible en context precision (> 0.75) sin degradar faithfulness. Si context precision sube pero faithfulness cae, hay algo en el reranking o la construcción del contexto que está rompiendo la coherencia.

Fase 3 — Evaluación continua y escala

Esta fase no añade nuevas capacidades de retrieval — consolida el sistema para que mantenga la calidad con el tiempo y a escala.

Pipeline de evaluación automatizado que corre en CI con cada cambio al sistema
Monitoreo de métricas en producción (al menos una muestra diaria de consultas reales)
Estrategia de re-ingesta para documentos que se actualizan
Revisión de la estrategia de chunking y vector store si el corpus supera 1M de documentos

Criterio de avance: el sistema detecta regresiones en las métricas antes de que lleguen a usuarios. Si un cambio en el pipeline degrada faithfulness en 5 puntos, el pipeline de CI lo detecta antes del despliegue.

Checklist de implementación

El chunking respeta las unidades semánticas del documento (secciones, párrafos completos, entidades)
El modelo de embedding está validado sobre una muestra de preguntas representativas del dominio real
El vector store está configurado para el tamaño actual del corpus con plan de migración si escala
El overlap entre chunks está dimensionado según el tipo de documento, no con un valor fijo global
El hybrid search tiene parámetro alpha configurable y ajustado al tipo de consultas del sistema
El reranking se aplica antes de construir el contexto final que recibe el LLM
Existe un conjunto de test de 50-100 preguntas con respuestas de referencia antes de iterar
Las métricas de faithfulness, answer relevancy y context precision se miden con cada cambio
La estrategia de re-ingesta para documentos actualizados está definida y documentada

Preguntas Frecuentes

¿Cuándo usar RAG frente a fine-tuning?

Esta es la pregunta que más paraliza a los equipos y tiene una respuesta más precisa de lo que parece. La confusión viene de tratar RAG y fine-tuning como alternativas, cuando en realidad responden a preguntas distintas.

Fine-tuning modifica los pesos del modelo: cambia cómo piensa o habla, no qué sabe. RAG no toca el modelo — añade contexto en tiempo de inferencia con información que el modelo no tenía en entrenamiento. Esa diferencia de arquitectura determina cuándo usar cada uno.

RAG es la respuesta correcta cuando el conocimiento cambia con frecuencia (precios, políticas, expedientes que se actualizan), cuando el corpus es extenso y no cabe en el contexto del modelo, cuando la trazabilidad importa — necesitas saber qué fragmento específico fundamenta cada respuesta — o cuando el conocimiento es confidencial y no puedes enviarlo a un proveedor para fine-tuning.

Fine-tuning es la respuesta correcta cuando quieres cambiar el comportamiento, el tono o el formato de las respuestas de forma consistente, cuando el conocimiento es estable y bien delimitado (taxonomías internas, formato de salida específico), o cuando necesitas latencia muy baja y el contexto adicional de RAG es el cuello de botella.

El patrón más efectivo en producción combina los dos: fine-tuning para que el modelo hable el idioma de la empresa (terminología, formato de respuesta, tono), RAG para que sepa lo que la empresa sabe hoy. El criterio práctico: si la pregunta del equipo es “¿qué sabe el modelo?”, RAG. Si la pregunta es “¿cómo responde el modelo?”, fine-tuning. Si las dos preguntas tienen respuesta, las dos herramientas.

¿Por qué “¿qué tamaño de chunk es el correcto?” es una pregunta mal formulada?

Porque no hay un número correcto — hay un número correcto para cada combinación de tipo de documento, modelo de embedding y longitud típica de las consultas del sistema.

La pregunta útil no es “¿qué tamaño uso?” sino “¿cómo encuentro el tamaño correcto para mi corpus?” La respuesta: medir context precision con tres o cuatro tamaños de chunk candidatos sobre el conjunto de test. El tamaño que maximiza context precision sin producir chunks demasiado pequeños para tener significado propio es el correcto para ese corpus concreto. En documentación técnica empresarial, los rangos de 256-512 tokens suelen funcionar bien, pero son puntos de partida para la medición, no respuestas finales.

¿Cómo manejar documentos que se actualizan?

Sin una estrategia explícita de re-ingesta, el RAG empieza a responder con versiones antiguas de la información. El mecanismo es sencillo: mantener un registro de cada documento en el vector store con su hash o timestamp, detectar cuándo un documento fuente se modifica, eliminar todos sus chunks del vector store, y volver a procesarlo e insertarlo desde cero.

La parte crítica que se suele pasar por alto es la eliminación de los chunks antiguos antes de insertar los nuevos. Si no se eliminan, el vector store acaba con múltiples versiones del mismo documento, y el retrieval devuelve fragmentos mezclados de versiones distintas. La mayoría de los vector stores tienen operaciones de borrado por metadata (filtrar por doc_id o por source) que hacen esta operación directa.

¿Cómo escala el sistema cuando el corpus crece?

Las decisiones que escalan bien desde el principio y las que hay que revisar son diferentes. El chunking semántico y los embeddings escalan sin cambios — el proceso de ingesta es el mismo para 10K que para 1M de documentos, solo más lento.

Lo que cambia con el escala es el vector store y la estrategia de indexación. Chroma funciona bien hasta decenas de miles de documentos; a partir de ahí, la latencia de retrieval empieza a ser perceptible y conviene migrar a Pinecone, Weaviate o una solución con indexación HNSW optimizada para corpus grandes. El hybrid search con BM25 también necesita revisión a escala — BM25 sobre corpus de millones de documentos requiere un índice invertido eficiente (Elasticsearch o Weaviate con módulo BM25, no una implementación in-memory).

La métrica que hay que monitorizar al crecer el corpus no es solo la latencia de retrieval sino la calidad del retrieval: con más documentos, la probabilidad de traer fragmentos ruidosos en los primeros resultados sube, y el reranking pasa de ser una optimización a ser un componente necesario.