RAG escalable: chunking, índices y freshness

RAG resuelve el problema de contexto, no el de inteligencia. Cuando el conocimiento de la empresa cambia cada semana, la arquitectura de retrieval define si el asistente es confiable o si los usuarios dejan de usarlo.

No existe un chunk size universal. Contratos, tickets de soporte, manuales técnicos y políticas internas tienen estructuras distintas; cada tipo merece reglas de corte y metadatos propios (fecha, área, versión).

Separá índices por dominio o tenant cuando hay restricciones de acceso. Mezclar embeddings de documentos con permisos diferentes en un mismo índice es un vector de fuga de datos difícil de detectar en QA.

La freshness importa tanto como la precisión. Planificá pipelines de re-indexación incremental y marcá la vigencia en los metadatos. Los usuarios detectan respuestas obsoletas antes que cualquier dashboard de MLOps.

Evaluá búsqueda híbrida (semántica + BM25) cuando las consultas incluyen códigos de producto, SKUs, números de expediente o identificadores exactos. Solo embeddings suele fallar en esos casos.

Controlá el costo: cada consulta que trae veinte chunks enormes al prompt multiplica tokens sin mejorar calidad. Top-k, reranking y límites de tamaño por chunk son palancas de negocio, no detalles técnicos menores.

Medí recall@k y satisfacción en producción, no solo en el notebook del data scientist. La arquitectura RAG evoluciona con el negocio; sin métrica en loop, optimizás lo incorrecto.