Un asistente RAG puede recuperar el párrafo correcto y aun así responder mal si ese párrafo perdió una condición esencial al dividir el documento. El problema no siempre está en el modelo: puede haberse introducido antes de generar los embeddings.
El chunking consiste en dividir contenido en unidades que se puedan indexar y recuperar. El objetivo es que cada fragmento resulte útil para una pregunta concreta y conserve suficiente contexto para interpretarlo. Un tamaño uniforme facilita el procesamiento, pero no garantiza esa utilidad.
Ejemplo: una excepción queda en el fragmento siguiente
Imagina este procedimiento ficticio de devolución de equipos:
Los equipos recibidos se revisan antes de autorizar la devolución. Si el precinto está roto, se deriva el caso a revisión técnica. Esta condición no se aplica a unidades abiertas por el servicio autorizado, siempre que exista un parte asociado.
Si el primer fragmento termina después de “revisión técnica” y el siguiente contiene únicamente la excepción, una consulta sobre un equipo abierto por el servicio autorizado puede recuperar solo la regla general.
Ampliar el solapamiento podría mantener la excepción junto a la regla en este ejemplo. Sin embargo, una solución más consistente para documentos de este tipo es reconocer la unidad del procedimiento y conservar la condición, la excepción y su referencia dentro de una misma unidad recuperable, siempre que quepa en los límites del sistema.
El texto anterior es un ejemplo creado para explicar el diseño, no una política de Nexeus Big Data ni de un cliente.
Compara tres alternativas sobre el mismo documento
| Estrategia | Qué facilita | Fallo que debe buscar la evaluación |
|---|---|---|
| Fragmentos de longitud fija | Un procesamiento predecible | Cortes entre reglas y excepciones |
| División por títulos y párrafos | Conservar la estructura del documento | Secciones muy largas o encabezados poco informativos |
| Combinación de estructura y tamaño máximo | Respetar unidades con límites operativos | Contexto repetido o división incorrecta de unidades especiales |
La documentación de Azure AI Search sobre fragmentación describe estrategias de tamaño fijo, estructura y significado, además del uso de solapamiento. Sus parámetros iniciales son puntos de partida para probar; no constituyen un tamaño óptimo universal.
Para el procedimiento ficticio, comienza por las secciones y examina las que sobrepasan el límite. Divide esas secciones por pasos completos e incorpora el título del procedimiento. Después comprueba preguntas cuya respuesta dependa de una excepción situada al final.
Las tablas no son párrafos largos
Una tabla puede contener el nombre de una variable en el encabezado, su unidad en otra fila y los valores en varias páginas. Convertirla a una cadena de texto sin estructura puede dejar una cifra sin significado.
Supongamos una tabla ilustrativa con columnas “tipo de equipo”, “plazo de revisión” y “condición adicional”. Un fragmento que solo contiene “equipo reacondicionado, cinco días” no explica desde cuándo se cuentan ni si una nota modifica el plazo.
Al dividir una tabla, conserva los encabezados relevantes y las notas que afectan a las filas incluidas. Una representación por grupos de filas puede repetir contexto de forma deliberada. Si la respuesta exige comparar todos los equipos, también hará falta una forma de recuperar la tabla completa o ejecutar una consulta estructurada.
No todos los contenidos deben resolverse con búsqueda vectorial sobre texto. Una tabla extensa de importes y categorías puede necesitar un tratamiento diferente al de un manual de procedimientos.
Metadatos que deben acompañar a cada fragmento
Guarda una identidad del documento, su versión, la sección de origen y una referencia que permita abrir la evidencia. Si el documento tiene páginas, conserva la ubicación cuando el extractor la proporcione de forma fiable.
Los permisos merecen un tratamiento específico. Si distintas partes del documento tienen restricciones diferentes, la división no debe mezclar contenido de niveles incompatibles. Cada unidad recuperable necesita los atributos de acceso correspondientes y el sistema debe aplicarlos antes de exponer el texto.
Al actualizar un archivo, evita que convivan fragmentos antiguos y nuevos sin una política explícita. Una cita a una versión retirada puede ser técnicamente recuperable y operativamente incorrecta. Define cómo se sustituyen las unidades, cómo se invalidan las anteriores y cómo se verifica que la versión publicada está completa.
Una prueba pequeña que discrimina resultados
Prepara preguntas para cuatro situaciones: respuesta contenida en un párrafo, respuesta repartida entre regla y excepción, respuesta dentro de una tabla y pregunta que exige reconocer que el documento no ofrece información suficiente.
Para cada pregunta, señala qué evidencia es necesaria antes de ejecutar la búsqueda. Compara las alternativas manteniendo constantes el corpus, el modelo de embeddings y la configuración de recuperación, salvo el parámetro que estás investigando.
Revisa si aparece la evidencia completa entre los resultados, cuánto contenido irrelevante la acompaña y si hay fragmentos casi duplicados que ocupan espacio. Después prueba la generación: recuperar una referencia útil no garantiza que el modelo la utilice correctamente. Incorpora estos casos a la evaluación completa del sistema RAG para distinguir fallos de recuperación y de respuesta.
Mide también el efecto operativo. Más fragmentos pueden aumentar el trabajo de indexación; un solapamiento excesivo puede repetir información en el contexto. Decide sobre el conjunto de resultados y sus costes medidos, sin elegir la configuración solo porque maximiza una métrica aislada.
El entregable útil es una política de división por tipo documental, acompañada de preguntas de prueba y fallos conocidos. Si necesitas diseñar esa evaluación en un proyecto de inteligencia artificial y machine learning, comparte con Nexeus Big Data documentos representativos y las preguntas que el asistente debe responder.