← Blog

Puntos de acceso, texto completo y RAG

  • JaniumCollect
  • Janium
  • IA

Un modelo de lenguaje admite, sobre el papel, cientos de miles o millones de tokens. En la práctica aprovecha muchos menos. Norman Paulsen lo midió de forma sistemática: define una ventana de contexto máxima efectiva (MECW, por las siglas en inglés) —el tramo de entrada a partir del cual añadir tokens ya no mejora la respuesta, y a menudo la empeora— y la compara con la ventana que anuncian los proveedores. En su muestra, la mayoría de los modelos degradan con claridad hacia los mil tokens de contexto; algunos fallan con cientos. La distancia respecto al máximo arquitectónico llega a ser de más del 99 por ciento. El tipo de problema desplaza ese umbral: no hay un número único (Paulsen, 2025).

Eso no es un argumento contra el RAG. Es un dato sobre cuánto contexto conviene ponerle al modelo, y cuándo.

Qué resuelve el RAG, y dónde se queda corto

El RAG (generación aumentada por recuperación) parte de una idea sana: el modelo no tiene que memorizar el acervo. Se recupera un puñado de fragmentos cercanos a la consulta y se los entrega para que redacte una respuesta. Bien acotado —pocos fragmentos, relevantes, por debajo de la ventana efectiva— el mismo estudio encuentra que la exactitud puede acercarse al ciento por ciento. Ese es el uso que vale la pena defender: una pregunta en lenguaje natural sobre un conjunto de documentos, con una respuesta sintetizada.

El límite aparece cuando se trata el RAG como el índice del acervo. Recuperar más para «no perderse nada» empuja el prompt más allá de la ventana efectiva: Paulsen observa que un RAG que inyecta conteos altos de tokens baja el rendimiento en lugar de subirlo. A eso se suma lo que ya se sabía: el modelo atiende peor lo que queda en el medio del contexto (Liu et al., 2023), y el troceo del documento decide qué se puede recuperar. Un fragmento demasiado grande diluye; uno demasiado chico corta la frase que importaba.

Para preguntar «¿qué dice este expediente sobre la cláusula X?» eso se mitiga. Para encontrar en un catálogo —el autor, la materia, el título exacto, todas las obras de una persona, el volumen que empieza por una letra— el cuello de botella no es la redacción de una respuesta. Es tener puntos de acceso estables sobre los que buscar y hojear.

Lo que Collect deja listo para buscar

Collect usa el modelo en el momento de describir, no en el de cada consulta. Lee el material —un PDF, una imagen, una hoja, una grabación— e identifica la obra. Del documento aflora los puntos de acceso: los encabezamientos por los que se va a encontrar el registro —nombres, materias, títulos, fechas— y, cuando hay coincidencia, los deja en forma autorizada. No son un párrafo para el modelo: son las entradas que Janium carga en sus índices.

Eso es lo que el catálogo ya sabe buscar, en tres vías que la ficha comercial de Janium distingue:

  • Por palabra clave en los índices especializados que esos encabezamientos alimentan.
  • Alfabética en autoridades: todas las obras de un autor, todas las materias que empiezan por una letra, el título en su forma normalizada.
  • Texto completo en los objetos digitales vinculados, cuando hay un cuerpo que indexar.

Extensiones corporativas

En un libro, los puntos de acceso bastan con autor, título y materia. En un contrato, un acta o un informe de gestión, lo que hay que encontrar no cabe en esos tres. Collect, cuando el formato de salida lleva extensiones corporativas (Dublin Core o ISAD-G), extrae del documento un bloque aparte de encabezamientos:

  • personas con su rol (firmante, representante, acreditado)
  • organizaciones y el papel que juegan
  • montos, con concepto y moneda
  • fechas críticas (vencimiento, firma, vigencia) y su criticidad
  • garantías y colaterales
  • cláusulas citadas, obligaciones de hacer y restricciones
  • relaciones entre entidades que el texto declara
  • lugares y materias

No son un análisis jurídico ni una segunda lectura del modelo en el momento de la consulta. Son campos: Collect los aflora una vez, Janium los carga como índices especializados. La consulta «contratos con esta persona, esta empresa y montos por encima de un umbral, firmados en tal año» se resuelve contra esos índices, no recorriendo el texto ni inyectándolo otra vez al modelo.

Lo que el documento no declara no se rellena. Una cláusula se cita si está; una relación societaria, si el texto la dice. El mismo criterio de siempre: completar lo identificable, marcar procedencia, dejar hueco lo que no se sostiene.

El modelo interviene una vez, al catalogar. La consulta del lector no vuelve a pasar por un LLM ni por un tope de tokens. El resultado es el mismo aunque el acervo crezca: el coste de describir no se paga otra vez en cada búsqueda.

Ese enriquecimiento tiene el riesgo que ya hemos dicho: un dato plausible puede ser falso. Por eso el registro marca procedencia cuando hay autoridad, califica cada ficha y señala las que conviene revisar. El punto de acceso queda inspeccionable. Un fragmento recuperado en un RAG, no.

El markdown, si se necesita el texto

Collect puede entregar, además del registro, el texto extraído en markdown: lo que el documento decía, ya en una forma que se puede indexar. Eso no sustituye los puntos de acceso; cubre otra pregunta: «¿en qué página aparece esta frase?».

Ese markdown se indexa en texto completo en Janium (u otro motor léxico). La búsqueda por palabra clave deja de limitarse a los campos del registro y alcanza el cuerpo. Sigue siendo un índice, no una generación: no hay ventana de contexto que se sature cuando el fondo pasa de miles a cientos de miles de páginas.

El mismo markdown sirve, si la institución lo quiere, para embeddings. Ahí el RAG vuelve a tener sentido —como capa opcional, sobre un texto ya limpio y ya anclado a un registro— no como único camino para encontrar una obra. Quien necesita una respuesta redactada («compara estas tres cláusulas») recupera pocos pasajes y se queda bajo la ventana efectiva. Quien necesita el autor o la signatura no tiene por qué pasar por ahí.

Tres capas, un solo acervo

No es Collect o RAG. Es un orden:

  1. Puntos de acceso en el catálogo — lo que Collect aflora y Janium busca en alfabético, por palabra clave y, si hay extensiones corporativas, por monto, vencimiento, cláusula u obligación. Es la capa que un acervo tiene que sostener aunque nadie haga una pregunta en lenguaje natural.
  2. Texto completo del markdown — cuando hace falta localizar una frase, no solo la ficha.
  3. Embeddings / RAG — cuando hace falta sintetizar o comparar, con pocos fragmentos y a sabiendas del umbral efectivo del modelo.

El estudio de Paulsen no dice que el RAG esté agotado. Dice que el modelo deja de aprovechar el contexto mucho antes de lo que anuncia la ficha técnica, y que un RAG que ignora ese techo se perjudica solo. Collect usa el modelo donde rinde —identificar y completar un registro, una vez— y deja en Janium un catálogo que no depende de volver a caber en esa ventana.

Si tu institución está evaluando si «poner el acervo en un RAG» sustituye a catalogarlo, la pregunta útil es otra: qué consultas tienes que resolver todos los días. Las que se contestan con un punto de acceso o con una frase del documento no necesitan generar un párrafo. Las que sí, pueden apoyarse en el markdown que Collect ya dejó listo. Si quieres verlo con una muestra de tu propio material, escríbenos a info@janium.com.