Preparación de Chunks para RAG: la Calidad del Vector se Decide Antes de Vectorizar
La suposición por defecto es que más volumen de chunks mejora la búsqueda. No es así: un fragmento sin contexto propio produce un vector que no significa nada, sin importar cuántos miles de esos fragmentos indexes en Qdrant. Estas son las 4 técnicas que aplicamos antes de vectorizar un corpus, no después, cuando el motor ya arrastra el problema.
El Problema Real
Un Chunk sin Contexto es un Vector sin Significado
El patrón más común al montar un RAG es cortar un documento largo en miles de fragmentos parejos y vectorizar cada uno tal cual quedó. Si un pedazo de texto dice, aislado, "y por lo tanto esta medida debe aplicarse de inmediato", su embedding no tiene con qué anclarse, no dice de qué medida se trata, ni en qué documento vive. Una consulta como "nuevas medidas de seguridad" nunca lo va a encontrar, aunque ese fragmento sea exactamente la respuesta.
La calidad de un vector depende por completo del contexto que tenía el texto antes de vectorizarse, no del modelo de embedding que se use después. Meter más volumen de chunks sin resolver esto no mejora el recall: agrega ruido y empeora el ranking, porque cada fragmento huérfano compite por espacio en los resultados sin aportar ninguna señal real.
El Método
4 Técnicas Antes de Guardar Nada en Qdrant
Ninguna reemplaza a las otras: se aplican juntas, en la etapa de preparación, antes de que el primer vector llegue a la colección.
Enriquecimiento de Chunks
Nunca se vectoriza un párrafo huérfano. Se le inyecta el contexto al texto mismo antes de generar el embedding (de qué documento viene, sobre qué tema, en qué categoría), no como metadata aparte que el vector nunca "lee".
Búsqueda Híbrida
Denso (embeddings) para significado y sparse/BM25 para coincidencia exacta de palabra, combinados. Un código o resolución con nomenclatura rara ("Resolución XZ-99") no significa nada para el vector denso, pero el componente disperso lo encuentra al instante.
Patrón Padre-Hijo
En vez de vectorizar el texto largo completo (que diluye el significado), se vectoriza un resumen conciso o una pregunta frecuente sobre ese texto — el "hijo". El match en Qdrant no devuelve el resumen: dispara una lectura a la base relacional que trae el documento completo, el "padre".
Payloads como Filtro Duro
No todo el trabajo es matemática de vector. Si existe una base estructurada homóloga, esa metadata se pasa al payload de Qdrant y se aplica como filtro tradicional (categoría, fecha, entidad) antes de correr la búsqueda vectorial, no después.
Implementación
El Padre-Hijo no es un Truco de Prompt: es una Separación de Capas
El patrón padre-hijo funciona porque respeta el mismo principio que aplicamos en toda arquitectura de datos que combina RDBMS, EAV y Qdrant: cada capa responde una pregunta distinta, y ninguna asume el trabajo de la otra.
RDBMS
Qué existe — el "Padre"
El documento completo, estructurado y joinable. Fuente de verdad. Nunca se vectoriza entero.
EAV
Qué se observó — el contexto
Contextualización versionada del dato: cuándo, quién, con qué motivo — lo que enriquece al chunk antes de vectorizarlo.
Qdrant
A qué se parece — el "Hijo"
Solo el resumen o la pregunta vectorizada, más la llave hacia el padre. Nunca es el sistema de registro.
Borrar la colección de Qdrant y reconstruirla desde RDBMS/EAV no debería perder ningún hecho — si se pierde, es señal de que el vector se volvió la fuente de verdad en algún punto del pipeline, y eso es exactamente lo que el patrón padre-hijo evita.
Regla de Decisión
Cuál Técnica Aplica Según tu Corpus
| Característica del Corpus | Técnica que Resuelve |
|---|---|
| Fragmentos que pierden sentido fuera de contexto (cláusulas, párrafos sueltos) | Enriquecimiento de chunks |
| Códigos, resoluciones, nomenclatura técnica exacta | Búsqueda híbrida (denso + BM25) |
| Documentos largos (contratos, manuales, informes) | Patrón padre-hijo |
| Ya existe una base relacional con categoría/fecha/entidad | Payloads como filtro duro |
Las 4 no son alternativas — la mayoría de los corpus empresariales reales combinan las 4 a la vez. La pregunta que decide cuánto esfuerzo poner en cada una es cuál de estos síntomas describe mejor lo que hoy no encuentra tu búsqueda.
Estado Real — Sin Inflar
Esto Prepara los Datos. No Decide Qué Motor Usar, ni Quién Puede Verlos.
Estas 4 técnicas resuelven la capa previa: que el vector que se guarda en Qdrant tenga significado real. No resuelven qué combinación de motores (léxico, denso, híbrido) rinde mejor sobre tu corpus específico — eso lo medimos aparte y está documentado con recall real en el reporte de hybrid search de esta misma serie. Tampoco resuelven que la búsqueda no devuelva a un usuario un resultado que no debería poder ver: ese es el problema de control de acceso que cubrimos en el reporte de RBAC, capa aparte de la preparación de datos.
Contenido relacionado
Estrategias de Búsqueda Documental Aumentada Empresarial
El panorama completo: sparse, denso e híbrido: esta preparación de chunks es la capa previa a las 3 estrategias del pilar.
Ver el pilar completo → 3 Estrategias de BúsquedaHybrid Search en RAG: Cuándo Suma y Cuándo Resta
Con los chunks ya bien preparados, la siguiente decisión es qué motor de búsqueda usar sobre ellos — medido con recall real, no con la ficha del proveedor.
Ver el benchmark → Cuándo Suma y Cuándo RestaRBAC como Medida de Seguridad Apropiada (Ley 21.719)
La preparación de datos y la estrategia de búsqueda no filtran por permisos: esa es una capa aparte, cubierta acá.
Ver el reporte - 6 Scopes de Ruta + Ley 21.719Esta preparación de chunks es la capa previa de la serie de estrategias de búsqueda en RAG: