Saltearse al contenido

Contextual Text Splitter

Contextual Text Splitter corta tus documentos en fragmentos y pide a un modelo que escriba, para cada uno, una o dos frases que lo sitúan dentro del documento completo. Ese contexto se añade delante del fragmento antes de guardarlo en una base vectorial.

Los documentos largos se cortan en fragmentos para que cada búsqueda devuelva solo el trozo que responde, y no el documento entero. El problema es que muchos fragmentos, sueltos, no dicen de qué hablan. «Desconecta la sonda y mide la resistencia: debe dar 1.000 ohmios» no dice de qué máquina ni de qué avería. Con el contexto delante, «Del manual técnico de la cafetera Q90, apartado del error E07 (sonda de temperatura)», la búsqueda lo encuentra cuando alguien pregunta por el E07 de la Q90. A esta técnica se la conoce como recuperación contextual.

Cuándo usarlo

  • Tus documentos tienen apartados parecidos que solo se distinguen por el título: manuales de varias máquinas, condiciones de varios productos, informes de varios meses.
  • Hay fragmentos que pierden el sentido fuera de su documento, como una tabla de precios sin el nombre del producto o un paso de un procedimiento que solo dice «la pieza».
  • Vas a reordenar los resultados con Local Rerank: con contexto, la reordenación acierta más.
  • Las búsquedas fallan porque los fragmentos no mencionan el tema del que hablan.

Configuración

CampoQué hace
Data Inputs (obligatorio)Los documentos que se cortan, con su texto y sus datos. Por ejemplo, la salida de Storage Files leyendo un PDF.
Language Model (obligatorio)El modelo que escribe el contexto de cada fragmento. Un modelo rápido y económico es suficiente.
Chunk SizeEl tamaño máximo de cada fragmento, en caracteres (o en tokens con el método token_based). De 50 a 8.000. Por defecto, 1000.
Chunk OverlapCuánto texto comparten dos fragmentos seguidos, para que una idea cortada en dos esté completa en alguno. De 0 a 2.000. Por defecto, 200.

Opciones avanzadas

CampoQué hace
Split MethodCómo se corta. recursive (por defecto): por párrafos, luego por líneas y luego por frases, hasta que el fragmento cabe. token_based: igual, pero el tamaño se mide en tokens, las piezas de palabra con las que trabajan los modelos. sentence: solo frases enteras, nunca corta una frase por la mitad.
Preserve ParagraphsActivado (por defecto), prefiere cortar entre párrafos. Con sentence, además, un fragmento nunca junta dos párrafos.
SeparatorQué separa los párrafos en tus documentos. Por defecto, una línea en blanco.
Max Sentence LengthSolo con sentence: las frases más largas que esto se parten en trozos de este número de caracteres. Por defecto, 500.
Parallel RequestsCuántos fragmentos se contextualizan a la vez, de 1 a 20. Por defecto, 5. Más es más rápido, si tu proveedor de modelos lo permite.

Resultado

La salida Chunks trae un elemento por fragmento con estos datos:

DatoQué contiene
textEl contexto, una línea en blanco y el fragmento. Es lo que se guarda y se busca.
contextSolo el contexto escrito por el modelo.
chunkSolo el fragmento original, tal como estaba en el documento.
Los datos del documentoLo que traía el documento de origen, por ejemplo el nombre del archivo, se copia en cada fragmento.

Conecta Chunks a Ingest Data de una base vectorial, como Qdrant o Chroma DB, o antes a Metadata Tagger para etiquetar cada fragmento.

Si el modelo falla (por ejemplo, por una credencial sin saldo), la ejecución se detiene con el error. Nunca se guardan fragmentos con un mensaje de error en lugar del contexto.

Ejemplo

Un servicio técnico de cafeteras quiere que su asistente responda con los manuales de sus máquinas.

  1. Lee el manual en PDF con Storage Files y conecta su salida a Data Inputs.
  2. Conecta un modelo rápido, como DeepSeek, a Language Model. Pon Chunk Size en 700 y Chunk Overlap en 100.
  3. Conecta Chunks a Metadata Tagger y su salida a Ingest Data de Qdrant con Operation en Add.
  4. Ejecuta el flujo una vez. En la tabla de salida verás, para cada fragmento, el texto con su contexto delante, el contexto y el fragmento original por separado.

Qué mejora y cuánto cuesta: cifras medidas

Medido el 17 de octubre de 2026 sobre una base de conocimiento de prueba (9 documentos de un servicio técnico ficticio, 40 preguntas). Son cifras de un único conjunto sintético: muestran cómo se comporta la técnica, no una promesa para tus datos.

  • Más aciertos: con la búsqueda por significado, el fragmento correcto estaba entre los 5 primeros en el 93 % de las preguntas con contexto, frente al 83 % sin él.
  • La mejor combinación, con reordenación: este componente, búsqueda híbrida y Local Rerank fue la mejor configuración de la prueba: el fragmento correcto quedó primero en el 80 % de las preguntas y entre los 5 primeros en todas, frente al 60 % y el 83 % de la búsqueda por significado sola. Sin contexto, la misma búsqueda con reordenación lo dejó entre los 5 primeros en el 87 % (medido el 18 de octubre).
  • Coste: una llamada al modelo por fragmento, solo al guardar los documentos; las búsquedas no tienen coste añadido. En la prueba, 80 fragmentos tardaron unos 23 segundos con 5 a la vez. Cada llamada envía el documento entero junto al fragmento, unos 1.800 tokens de entrada por fragmento en esa prueba, así que el coste crece con el tamaño de los documentos.

Buenas prácticas

  • Usa un modelo rápido y económico: el contexto son una o dos frases y no necesita razonar.
  • Para documentos técnicos, fragmentos de 600 a 1.000 caracteres con un solapamiento de 100 a 200 funcionan bien.
  • El modelo lee hasta los primeros 60.000 caracteres de cada documento para escribir el contexto. Si tienes documentos mucho más largos, divídelos antes por capítulos.
  • Si cambias Chunk Size, el método o el modelo de embeddings, vuelve a guardar los documentos en una colección nueva.

Componentes relacionados

Para ver cómo encaja en un flujo de ingesta completo, consulta Preparar los documentos en la guía de RAG.