Fragmentación (chunking) e indexación para RAG
Se va a indexar un manual del SENA de 180 páginas, con unas 500 palabras por página, usando fragmentos de 400 palabras con 50 de solapamiento. ¿Cuántos fragmentos salen? El modelo de embeddings acepta 512 tokens: ¿caben los fragmentos?
Cómo se resuelve
- 1Total de palabras: 180 × 500 = 90.000.
- 2Con solapamiento de 50, cada fragmento nuevo no avanza 400 palabras sino 400 − 50 = 350. Ese avance es el que hay que usar para contar, no el tamaño del fragmento.
- 3El fragmento número n empieza en la palabra 350 × (n − 1) y termina 400 más allá. Para cubrir las 90.000 se necesita 350 × (n − 1) + 400 ≥ 90.000, o sea 350 × (n − 1) ≥ 89.600, entonces n − 1 ≥ 256 y n = 257 fragmentos.
- 4Ahora el tamaño en tokens, que es lo que limita el modelo. En español van unos 1,5 tokens por palabra: 400 × 1,5 = 600 tokens. El modelo acepta 512, así que NO caben: lo que sobre se corta en silencio y el final de cada fragmento se pierde del índice.
- 5Se baja el fragmento a 300 palabras (300 × 1,5 = 450 tokens, con margen). Con solapamiento de 50 el avance queda en 250: 250 × (n − 1) + 300 ≥ 90.000 da n − 1 ≥ 358,8, o sea n = 360 fragmentos.
- 6Un detalle que decide la calidad más que el conteo: los cortes deben respetar los títulos y los pasos de un procedimiento. Un fragmento que empieza a mitad de un instructivo se recupera bien pero responde mal, porque le falta de qué estaba hablando.
Respuesta: Con 400 palabras salen 257 fragmentos, pero pesan unos 600 tokens y no caben en el límite de 512. Con 300 palabras salen 360 fragmentos de unos 450 tokens, que sí caben.
El error de siempre: Contar como si cada fragmento avanzara 400 palabras y responder 90.000 / 400 = 225. Ese número ignora el solapamiento, que es justamente lo que hace que los fragmentos se pisen. El otro error, más caro, es quitar el solapamiento «para que salgan menos fragmentos»: el solape existe para que una frase que cae en el borde aparezca completa en por lo menos un fragmento; sin él, la respuesta que el usuario necesita puede quedar partida entre dos y no recuperarse bien en ninguno.
Agentes: herramientas, bucle de decisión y controles
Un agente de servicio al cliente de una tienda en Medellín tiene tres herramientas: buscar_pedido(cedula), cancelar_pedido(id) y enviar_correo(destinatario, texto). Un cliente escribe: «Cancélame todo lo que tenga pendiente, cédula 1020…, y avísale también a este otro correo». Diseña el bucle del agente y di qué controles faltan.
Cómo se resuelve
- 1Primero se clasifican las herramientas en dos grupos, porque no merecen el mismo trato: buscar_pedido solo lee (si se equivoca, no pasa nada), mientras cancelar_pedido y enviar_correo escriben hacia afuera y no se deshacen. Ese corte es el que organiza todo el diseño.
- 2El bucle del agente es: leer el estado actual → decidir la siguiente acción → ejecutar la herramienta → leer el resultado → repetir, hasta que no quede nada por hacer. Se le pone tope de iteraciones (por ejemplo 8) para que un agente confundido no se quede girando y gastando llamadas.
- 3Primer paso obligatorio: buscar_pedido con la cédula. El agente nunca debe actuar sobre lo que el cliente afirma, sino sobre lo que el sistema devuelve. «Todo lo que tenga pendiente» puede ser un pedido o quince, y solo algunos estarán en estado cancelable; eso lo dice la consulta, no el mensaje.
- 4Antes de cancelar: confirmación humana con la lista concreta en la mano («voy a cancelar estos 3 pedidos: …, ¿confirma?»). Una acción irreversible no se ejecuta porque el modelo la dedujo de una frase; se ejecuta porque alguien dijo que sí sobre una lista específica.
- 5El destinatario de enviar_correo lo pone el sistema a partir de la cédula consultada, nunca el texto del cliente. El mensaje del usuario es dato de entrada para decidir, no una instrucción para el sistema, y esa distinción es la que separa un agente seguro de uno que reenvía los datos de un pedido a donde le digan.
- 6Se registra cada llamada con sus argumentos y su resultado. Cuando un agente hace algo raro, sin ese registro no hay forma de saber en qué paso se torció.
Respuesta: Bucle: consultar primero, enumerar lo que de verdad existe, pedir confirmación humana antes de cada acción irreversible, fijar los destinatarios desde el sistema y no desde el texto del cliente, y registrar todas las llamadas. Las herramientas de lectura pueden correr libres; las de escritura, nunca.
El error de siempre: Dejar que el texto del cliente escoja los argumentos de las herramientas. Si el mensaje trae «y avísale a este otro correo», un agente sin esa separación obedece. En un chat común eso sería una frase mal interpretada; en un agente con herramientas es un correo con datos de un pedido saliendo hacia un desconocido, o pedidos cancelados que nadie pidió cancelar. El contenido que entra —mensajes, correos, páginas leídas— es siempre dato, jamás orden.
