La fragmentación es la decisión de recuperación que todos toman por accidente

Hay un momento al comienzo de cada proyecto de recuperación en el que alguien escribe un número. Quinientas fichas. Mil. Cualquiera que sea el tutorial utilizado. El proceso funciona, la demostración responde preguntas y ese número nunca se vuelve a examinar.

Merece más atención de la que recibe, porque la fragmentación no es un detalle de preprocesamiento. Es la decisión la que determina qué hechos pueden recuperarse juntos, y ninguna clasificación inteligente posterior puede recuperar una relación que la fragmentación destruyó.

¿Qué sale mal concretamente?

Los fragmentos que son demasiado pequeños fragmentan una sola idea en varias partes. La respuesta existe en su corpus, pero ningún fragmento individual contiene suficiente cantidad como para parecer relevante, por lo que nada tiene una puntuación alta y el agente responde a partir de sus propias suposiciones.

Los trozos que son demasiado grandes arrastran material no relacionado junto con la pieza que coincide. La recuperación parece exitosa, la ventana de contexto se llena de ruido y el agente produce algo sutil sobre el párrafo equivocado. Este fracaso es peor que el primero, porque produce una producción segura en lugar de una brecha obvia.

Ambos fracasos parecen idénticos desde fuera: el agente da una respuesta errónea de una manera que nadie puede explicar inmediatamente.

La estructura supera al tamaño

El cambio más útil que vemos que hacen los equipos es dejar de pensar en el recuento de tokens y empezar a pensar en la estructura de los documentos.

Un documento de política tiene secciones. Un archivo de soporte tiene un problema por ticket. Una referencia de API tiene un punto final por entrada. Esos límites los puso una persona por la misma razón por la que tú los necesitas: marcan dónde termina una idea y comienza otra. La división según ellos, con un límite de tamaño como alternativa en lugar de la regla principal, supera consistentemente la división únicamente por longitud.

Cuando los documentos no tienen una estructura utilizable, la superposición es la mitigación barata. Llevar una oración o dos a través del límite cuesta almacenamiento y muy poco más, y rescata el caso específico en el que la oración clave coloca una ficha más allá de una división.

Los metadatos están subestimados

Un fragmento no es sólo texto. Es texto más todo lo que sabes sobre su origen: el documento al que pertenece, el título de la sección que está encima, la fecha en que fue escrito, el equipo al que pertenece, si ha sido reemplazado.

Esos metadatos son los que permiten a un agente filtrar antes de clasificar, lo que suele suponer una mayor precisión que cualquier cambio de incorporación. "Buscar en la versión actual del manual de cumplimiento" es un problema fundamentalmente más fácil que "buscar en todo y esperar que la versión actual obtenga la puntuación más alta".

También le brinda una respuesta a la pregunta que sigue a cada resultado incorrecto: ¿de dónde vino esto? Un trozo que lleva su procedencia convierte la depuración de la arqueología en una búsqueda.

Evalúalo, no discutas sobre ello.

La estrategia de fragmentación es el tipo de tema que genera opiniones largas y evidencia corta. La salida es la misma que en cualquier otro lugar del trabajo como agente: escribir primero la evaluación.

Reúna treinta o cuarenta preguntas reales que la gente realmente le hace a su sistema, con el pasaje que debe responder a cada una. Luego mida si ese pasaje se recupera. No si la respuesta final se lee bien, lo que confunde recuperación y generación, sino si el material correcto llegó al modelo.

Una vez implementado esto, la fragmentación se convierte en un experimento más que en un debate. Cambie la estrategia, vuelva a ejecutar el conjunto, conserve la versión que recupere más. Los equipos que construyen este arnés temprano tienden a dejar de tener discusiones fragmentadas por completo, porque ahora hay una manera barata de resolverlas.

Cómo se conecta esto con los agentes en ejecución

La calidad de la recuperación no es una preocupación separada de la operación del agente. Un cambio de recuperación que agrega doscientos tokens a cada llamada es un cambio de costo, y un cambio de recuperación que mejora la recuperación es un cambio de calidad. Ambos pertenecen al mismo ciclo de evaluación que todo lo demás que hace el agente.

Es por eso que las evaluaciones en Orán califican los criterios de comportamiento, estructurales, de latencia y de costo juntos, y por qué el Optimizador mide sus propios cambios con respecto a esas mismas evaluaciones. Recortar el contexto para ahorrar dinero sólo supone un ahorro si la recuperación aún encuentra lo que necesita.

Por donde empezar

Si ya tiene un sistema de recuperación en producción y no tiene un conjunto de evaluación, construya primero el conjunto de evaluación, aunque sea uno tosco. Te dirá más en una tarde que en un mes de puesta a punto. La documentación del desarrollador cubre la mecánica y las páginas del Sistema de orquestación de agentes cubren cómo encajan las capas de evaluación y costos.