La fragmentación y los embeddings deciden la calidad de un RAG, no el generador

Un cliente tenía un asistente que respondía de forma aceptable al 60 por ciento de las preguntas. El plan sobre la mesa era pasar a un modelo de generación más grande y más caro. Ejecutamos su conjunto de evaluación midiendo la recuperación por separado y encontramos que el fragmento correcto estaba entre los cinco primeros resultados solo el 64 por ciento de las veces. Ningún generador puede responder a partir de un documento que nunca le enseñaron. El modelo grande habría producido respuestas equivocadas más fluidas al triple de coste.

La recuperación fija el techo. El generador solo puede no alcanzarlo. Casi todo lo que determina la calidad de la recuperación ocurre antes de generar un solo token: cómo partes los documentos, qué adjuntas a cada trozo, qué modelo de embeddings usas y si reordenas.

Parte por la estructura del documento, no por número de caracteres

El troceador recursivo de caracteres a mil caracteres con doscientos de solape es el valor por defecto de todos los tutoriales y es incorrecto para casi cualquier corpus real. Corta tablas por la mitad, separa un encabezado del párrafo que introduce y parte un procedimiento numerado en el paso cuatro.

Parte por estructura. Para Markdown y HTML, corta por los encabezados y mantén las secciones enteras hasta un límite de tamaño, recurriendo a subdividir solo en las secciones genuinamente largas. Para contratos y políticas, corta por cláusula o artículo. Para código, por función o clase. La unidad debería ser aquello con lo que respondería una persona si le pidieras que citara la parte relevante.

El solape sigue importando, pero es un parche para un corte malo, no una estrategia. Cuando partes por estructura, entre un 10 y un 15 por ciento de solape basta. Cuando partes por número de caracteres necesitas mucho más, lo cual es señal de que estás indexando el mismo texto varias veces para compensar haber cortado donde no tocaba.

Tamaño: apunta a fragmentos que lleven una sola idea. En la práctica, entre 300 y 800 tokens funciona para prosa. Los fragmentos pequeños recuperan con más precisión y le dan menos material al generador; los grandes, al revés. Si no te decides, indexa pequeño y usa el contexto del padre.

Cada fragmento necesita saber de dónde viene

Un fragmento que dice "ponlo a 30 segundos" es irrecuperable e inservible. El arreglo es anteponer el título del documento y la ruta completa de encabezados al texto del fragmento antes de generar su embedding, de modo que el propio embedding lleve el tema. Es un cambio de dos líneas y vale con frecuencia varios puntos de exhaustividad.

Más allá de eso, el patrón del documento padre: genera embeddings y busca sobre fragmentos pequeños, pero devuelve al generador la sección mayor que los rodea. Obtienes la precisión de recuperar en pequeño y el contexto de generar en grande. Guarda el identificador del padre como metadato y recupéralo después de ordenar.

Y mantén la procedencia en cada fragmento: sistema origen, identificador de documento, sección, versión, última modificación. Sin eso no hay cita, y sin cita nadie se fía de la respuesta. Es el mismo requisito que empuja el filtrado por permisos en las cuatro decisiones que importan más que el modelo.

Las tablas y los PDF son donde los pipelines se rompen en silencio

Casi todos los corpus que importan contienen PDF, y un PDF no tiene estructura, solo glifos colocados en una posición. La extracción de texto ingenua convierte un diseño a dos columnas en un galimatías entrelazado y una tabla en un chorro de números sin cabeceras.

Lo que funciona, por esfuerzo creciente:

• Usa un extractor consciente del diseño que produzca orden de lectura e identifique las tablas como tablas. Todas las nubes grandes tienen un servicio de comprensión de documentos, y hay analizadores de diseño libres viables.
• Serializa cada tabla como Markdown o HTML, mantenla en un solo fragmento y antepón su leyenda y el encabezado que la rodea. Una tabla partida entre fragmentos es peor que no tener tabla.
• Los documentos escaneados necesitan reconocimiento óptico primero, y sus errores se propagan en silencio hasta el índice. Muestrea el texto extraído antes de indexar cuarenta mil páginas.

Gasta tu tiempo aquí. En nuestra experiencia, la calidad del análisis documental mueve la precisión de punta a punta más que cualquier cambio de prompt.

Elegir el modelo de embeddings sabiendo que te casas con él

Cambiar de modelo de embeddings significa reindexar el corpus entero. Modelos distintos producen dimensiones distintas y, más importante, espacios vectoriales incompatibles, así que no puedes mezclar vectores viejos y nuevos. En un corpus grande eso son horas de cómputo y un plan de migración con índices duplicados y un cambio de conmutación.

Así que elige a conciencia, sobre tus propios datos:

• Capacidad multilingüe si tus documentos o tus usuarios no están todos en inglés. Muchos modelos fuertes en inglés se degradan bruscamente en otras lenguas, y un corpus europeo rara vez es monolingüe.
• Ajuste al dominio. Prueba sobre tu conjunto de evaluación. Un modelo general gana a menudo a uno específico de dominio, y la única forma de saberlo es medir la exhaustividad de recuperación de cada candidato.
• Dimensionalidad. Mil quinientas o tres mil dimensiones cuestan más de almacenar y de buscar que setecientas. Algunos modelos recientes permiten truncar el vector con una pérdida de calidad modesta, y merece la pena probarlo: partir las dimensiones por la mitad reduce a la mitad la memoria del índice, y la memoria del índice es lo que determina el tamaño y el coste de tu base de datos vectorial.
• Alojamiento. Un modelo de embeddings tras una API añade un salto de red a cada consulta y a cada documento. Un modelo pequeño autoalojado es barato de ejecutar y elimina esa dependencia.

El reordenador es el cambio con mejor relación esfuerzo resultado

Recupera entre treinta y cincuenta candidatos con búsqueda híbrida, pasa un reordenador de codificación cruzada sobre ellos y quédate con los cinco mejores. A diferencia del codificador que produjo tu índice, un reordenador ve la consulta y el documento juntos, así que juzga la relevancia mucho mejor.

La ganancia suele ser grande: vemos con regularidad la precisión entre los cinco primeros moverse entre diez y veinte puntos en corpus que no cambiaron en nada más. Cuesta una llamada de modelo adicional de cien a trescientos milisegundos y ninguna reindexación, y se añade a un pipeline existente en un día. Hay reordenadores gestionados en el servicio de IA de cada nube, y los pequeños de pesos abiertos corren bien en CPU a volumen moderado.

Lo que se olvida

• Mide la recuperación por separado de las respuestas. La exhaustividad entre los cinco primeros no necesita generador, no cuesta nada y te dice dónde está el fallo de verdad.
• Los borrados. Cuando un documento origen se borra o se sustituye, sus fragmentos tienen que salir del índice. Los fragmentos rancios producen respuestas desactualizadas con total aplomo.
• Los casi duplicados. Cinco versiones de la misma política llenan tus cinco primeros con el mismo texto. Deduplica en la ingesta y prefiere la versión vigente.
• Genera el embedding de la consulta igual que el de los documentos. Algunos modelos esperan un prefijo asimétrico distinto para consultas y para pasajes. Equivocarse aquí cuesta exhaustividad en silencio.
• El número de fragmentos es un motor de coste. Fija la memoria del índice, el gasto de embeddings y el tiempo de reindexación. Partir el tamaño del fragmento por la mitad duplica las tres cosas.

Tratamos el análisis documental, la fragmentación y el reordenamiento como la primera semana de cualquier proyecto de IA aplicada, antes de que empiece la conversación sobre el modelo.

Qué hacer esta semana

Coge veinte preguntas que hayan hecho tus usuarios de verdad, pásalas por tu recuperación actual y anota si el fragmento correcto aparece entre los cinco primeros. Si estás por debajo del 85 por ciento, deja de afinar prompts. Añade un reordenador sobre treinta candidatos y vuelve a medir.