Trocear el archivo: la decisión menos vistosa de un RAG y la que más lo condiciona

Cuando una redacción se plantea montar un sistema de recuperación aumentada, la conversación se va casi siempre al mismo sitio: qué modelo usar. Es la parte vistosa. También es, con diferencia, la que menos determina el resultado.

Lo que de verdad decide si el sistema responde bien es una operación que no luce en ninguna presentación: cómo se parte el archivo en pedazos antes de indexarlo. El troceado, o chunking. Y en un medio digital tiene particularidades que conviene entender antes de firmar nada.

Por qué hay que trocear

Un sistema RAG no busca artículos, busca fragmentos. Convierte cada pedazo de texto en un vector que representa su significado y, cuando llega una pregunta, recupera los pedazos más cercanos a ella.

Si el pedazo es el artículo entero, su vector es un promedio de todo lo que contiene: un reportaje de cuatro mil palabras que toca vivienda, empleo y demografía acaba representado por una nube difusa que no está cerca de ninguna pregunta concreta. Si el pedazo es demasiado pequeño —una frase suelta—, se recupera con precisión pero llega sin contexto, y el modelo redacta sobre el vacío.

El punto óptimo está en algún lugar intermedio, y ese lugar depende del tipo de texto.

Lo que falla al aplicar la receta genérica a un medio

La mayoría de tutoriales proponen cortar cada 500 o 1000 caracteres con un solapamiento del 10 o el 20%. Es un punto de partida razonable para documentación técnica. Para periodismo, produce resultados mediocres por tres motivos concretos.

El titular y la entradilla concentran el significado. En una pieza periodística, las primeras líneas resumen todo. Un corte ciego deja la mitad del archivo en fragmentos que han perdido esa cabecera y ya no se sabe de qué hablan. La solución es barata: anteponer a cada fragmento el titular y la fecha de la pieza a la que pertenece.

La fecha es parte del significado. «El paro baja al 11%» significa cosas distintas en 2014 y en 2025. Un fragmento sin fecha es una afirmación flotante, y el modelo la presentará como si fuera actual. En un medio esto no es un fallo técnico, es un error de publicación.

Las declaraciones no se pueden partir. Cortar una cita textual por la mitad genera fragmentos que atribuyen a alguien media frase. Es la clase de error que un lector detecta al instante y que destruye la confianza en el sistema entero.

Trocear por estructura, no por longitud

La alternativa que mejor funciona en archivos periodísticos es respetar la estructura que el propio texto ya tiene. Los artículos vienen con ladillos, párrafos y bloques de cita: son fronteras naturales que alguien puso ahí precisamente porque separan ideas.

Un troceado por secciones, con un tope de longitud para los bloques que se pasen, conserva unidades de sentido completas. Cuesta más de implementar que cortar cada mil caracteres, pero se nota en la primera prueba.

A esto se añade una capa que en medios rinde mucho: guardar junto a cada fragmento sus metadatos —sección, autor, fecha, etiquetas— para poder filtrar antes de buscar. Una pregunta que dice «el año pasado» debería restringir la búsqueda a ese rango en lugar de confiar en que la similitud semántica lo resuelva sola. No lo resuelve.

Cómo saber si el troceado está bien

Hay una prueba casera que no requiere ninguna herramienta: coger treinta fragmentos al azar del índice y leerlos sin ver de dónde salen. Si se entiende de qué hablan, de cuándo son y quién dice qué, el troceado está bien. Si hay que ir al artículo original para situarlos, el sistema tampoco los va a entender.

Es una prueba de diez minutos que ahorra semanas de ajustes a ciegas sobre el modelo, que es donde suele irse el tiempo cuando las respuestas salen raras.

El orden correcto

Si hubiera que ordenar por impacto real las decisiones de un proyecto RAG en un medio, el modelo de lenguaje estaría bastante abajo. Arriba estarían la limpieza del archivo, el troceado y los metadatos.

Es una mala noticia para quien esperaba comprar una solución y enchufarla, y una buena para quien ya tiene un archivo bien mantenido: buena parte del trabajo está hecho.