Resumir hilos de WhatsApp de 5.000+ mensajes | ThreadRecap
Un hilo de WhatsApp de 5.000 mensajes no es solo un chat largo. Son meses de decisiones enterradas bajo cientos de saludos, cambios de tema que suceden en medio de la conversación, notas de voz dispersas entre textos, y el mismo nombre de proyecto escrito de tres formas diferentes por tres personas distintas. Pedirle a una IA que lo resuma en un solo pase es como pedirle a alguien que lea una novela a través de una cerradura. El resultado será confiado, fluido, y equivocado de maneras difíciles de detectar. Este artículo explica qué sucede realmente bajo el capó cuando ThreadRecap procesa un hilo de este tamaño: cómo se mide el texto, dónde se divide, cómo se mantiene la coherencia entre divisiones, y qué el pipeline mantiene deliberadamente versus lo que comprime.
Qué "5.000+ mensajes" realmente significa en tokens
Antes de que pueda suceder cualquier resumen, la exportación sin procesar debe medirse en la unidad que realmente importa para los modelos de lenguaje: tokens. Los tokens no son palabras. Una palabra inglesa única es aproximadamente 1 a 1,5 tokens en promedio, pero la puntuación, marcas de tiempo, nombres de remitentes, y caracteres no latinos se suman al conteo.
Una línea de exportación típica de WhatsApp se ve así:
```
12/04/2024, 09:47 - Maria: ¿Podemos mover la fecha límite al viernes?
```
Ese único mensaje, incluyendo la marca de tiempo y el prefijo del remitente que WhatsApp añade a cada línea, son alrededor de 15 a 20 tokens. Multiplica eso por 5.000 mensajes y estás viendo aproximadamente 75.000 a 100.000 tokens para un hilo de longitud promedio de mensaje. Los hilos con mensajes más largos, múltiples idiomas, o contenido técnico denso pueden superar fácilmente 150.000 tokens.
La mayoría de los modelos de lenguaje de producción tienen ventanas de contexto prácticas que se sitúan en algún lugar entre 8.000 y 200.000 tokens. Incluso en el extremo superior, una exportación muy grande no cabe en un solo pase, y caber no significa desempeñarse bien. La investigación sobre resumen de contexto largo muestra consistentemente que los modelos se degradan en coherencia a medida que crece la longitud de entrada, particularmente para contenido que aparece en el medio de una secuencia larga. El conteo de tokens no es solo un problema de capacidad. Es un problema de calidad.
ThreadRecap maneja exportaciones de 60.000+ mensajes, así que el pipeline debe funcionar correctamente en tamaños que están muy lejos de lo que cualquier llamada de modelo único puede procesar confiablemente.
Chunking ingenuo y por qué pierde coherencia
La solución más simple al problema del token es dividir el chat en bloques de tamaño fijo y resumir cada uno independientemente. Esto se llama chunking ingenuo, y produce resúmenes que son localmente precisos pero globalmente incoherentes.
Aquí está el porqué. Las conversaciones no respetan límites arbitrarios. Una decisión que comienza en el mensaje 1.200 podría no ser confirmada hasta el mensaje 1.450. Un nombre de proyecto introducido al principio del hilo podría ser abreviado diferentemente para el mensaje 3.000. Un elemento de acción asignado en un bloque podría ser actualizado, cancelado, o reasignado en el siguiente. Si cada fragmento se resume sin conocimiento de los demás, esas conexiones se sever.
El paso de fusión es donde el chunking ingenuo falla más visiblemente. Si resumes 10 fragmentos independientemente y luego concatenas los resúmenes, obtienes 10 mini-resúmenes que no saben el uno del otro. El documento final repetirá entidades, se contradecirá a sí mismo sobre preguntas resueltas, y perderá el arco de cómo una decisión evolucionó. El resultado se ve como un resumen pero funciona como una lista de notas desconectadas.
Un modo de fallo relacionado es cortes de límites duros. Si un fragmento termina a mitad de tema, el resumidor para ese fragmento truncará el tema o inventará una resolución. Ninguno es aceptable para un hilo que podría usarse más tarde como registro de lo que fue acordado.
Cómo ThreadRecap divide y fusiona para preservar el contexto en todo el hilo
ThreadRecap usa un pipeline de múltiples etapas que aborda tanto el problema de límites como el problema de fusión.
Etapa 1: Parsing estructurado antes de chunking
Antes de que se establezca cualquier límite de fragmento, la exportación se analiza en registros estructurados. Cada mensaje obtiene su marca de tiempo, nombre de remitente, tipo de mensaje (texto, transcripción de nota de voz, evento del sistema), y una puntuación de señal preliminar. Este pase de puntuación marca mensajes que contienen patrones de alta señal: compromisos explícitos, preguntas con destinatarios nombrados, referencias monetarias o de fecha, y frases de apertura de tema. Los mensajes de alta señal se tratan como puntos de anclaje que los límites del fragmento no cortarán.
Las notas de voz se transcriben usando OpenAI Whisper antes de esta etapa. La transcripción se inserta en el registro de mensaje en la posición cronológica correcta, así que el pipeline la trata idénticamente a un mensaje de texto. Whisper Large-v3 logra una Tasa de Error de Palabras (WER) del 2,7% en audio limpio, lo que significa que el contenido transcrito es generalmente confiable lo suficiente para incluirse en extracción de entidades y detección de decisiones.
Etapa 2: Chunking con ventana de solapamiento
Los fragmentos no se crean simplemente contando tokens y cortando. Cada fragmento se construye con una cola superpuesta del fragmento anterior, típicamente cubriendo la última porción del segmento anterior. Este solapamiento significa que un tema introducido cerca del final del fragmento N es visible al comienzo del fragmento N+1. El resumidor para el fragmento N+1 por lo tanto tiene el contexto que necesita para continuar el tema correctamente en lugar de tratarlo como un nuevo hilo.
Este enfoque de ventana deslizante es una técnica bien establecida en procesamiento de documentos largos. El solapamiento añade costo de token, pero previene los cortes duros que hacen al chunking ingenuo no confiable.
Etapa 3: Fusión recursiva con un registro de entidades en ejecución
Cada fragmento produce un resumen intermedio más una extracción estructurada: una lista de entidades nombradas (personas, empresas, fechas, cantidades, nombres de proyectos), elementos de acción abiertos, y decisiones tomadas dentro de ese fragmento. Estas extracciones estructuradas no son prosa. Son registros legibles por máquina que se pasan adelante a cada fragmento subsecuente y al paso de fusión final.
El paso de fusión no es una simple concatenación de resúmenes intermedios. Es una nueva llamada de modelo que recibe todos los resúmenes intermedios junto con el registro de entidades acumuladas y la lista de elementos abiertos. El prompt de fusión instruye al modelo para resolver contradicciones, cerrar elementos de acción completados, y producir una narrativa única coherente que abarque el hilo completo. Esto a veces se describe como un enfoque estilo MapReduce: mapear cada fragmento a un resumen parcial, luego reducir todos los resúmenes parciales a un resultado final con conciencia total de fragmentos cruzados.
El resultado es resultado estructurado: una sección Meeting Recap, una lista de Action Items con propietarios y fechas de vencimiento donde se indiquen, un log de Decisions, y una sección Conflict Resolution donde sea relevante. Estos se mapean directamente a los formatos de salida disponibles en la página de funciones del resumidor de chats de WhatsApp de ThreadRecap.
No todo el contenido se trata de la misma manera. El pipeline está diseñado para proteger categorías específicas de información de la compresión en cada etapa.
Decisiones
Cualquier mensaje que contenga una decisión confirmada se marca en la extracción estructurada y se lleva adelante textualmente en el registro de entidades. El paso de fusión final está instruido para incluir cada decisión en el log de Decisions independientemente de dónde en el hilo haya aparecido. Una decisión hecha en el fragmento 2 aparecerá en el resumen final incluso si nunca se menciona de nuevo en los fragmentos 3 al 10.
Elementos de acción
Los elementos de acción se extraen con tres campos: la descripción de la tarea, la persona asignada (si está nombrada), y la fecha de vencimiento (si se indica). Los elementos de acción abiertos se llevan adelante a cada fragmento subsecuente así el paso de fusión puede verificar si fueron completados, actualizados, o abandonados. Un elemento de acción asignado en el fragmento 1 y completado en el fragmento 7 aparecerá en el resultado final como completado, no como una tarea abierta pendiente.
Entidades nombradas
Personas, organizaciones, nombres de proyectos, ubicaciones, fechas, y cantidades monetarias se rastrean en el registro de entidades desde el primer fragmento en adelante. Esto previene que el resumen final se refiera a la misma persona por dos nombres diferentes, o trate el mismo proyecto como dos temas separados porque la abreviación cambió a mitad del hilo.
Continuidad de tema
Los mensajes de anclaje de alta señal identificados en la Etapa 1 se incluyen en la ventana de solapamiento y en el prompt de fusión. Esto significa que incluso si un tema abarca múltiples fragmentos, el modelo que procesa los fragmentos posteriores tiene acceso a cómo el tema fue introducido, no solo su estado actual.
Dónde se comprime
Preservar todo produciría un resumen tan largo como el hilo original. El pipeline aplica compresión deliberada al contenido que añade volumen sin añadir valor informacional.
Saludos y reconocimientos
"Buenos días", "anotado", "ok gracias", "lo haré", "suena bien" y reconocimientos sociales similares se colapsan. En un hilo de 5.000 mensajes, estos pueden representar cientos de mensajes. Ninguno de ellos cambia el registro de qué fue decidido o acordado.
Check-ins repetidos
Un grupo que se reúne semanalmente en WhatsApp frecuentemente tendrá secuencias recurrentes de check-in: "¿Hay novedades?", "Nada de mi parte", "Igual aquí". Estos patrones se detectan y se representan una sola vez en el resumen como una nota de que los check-ins regulares ocurrieron, en lugar de ser transcritos en su totalidad.
Reacciones emoji
Las exportaciones de WhatsApp incluyen eventos de reacción como líneas separadas. Una reacción de pulgar hacia arriba a un mensaje añade una línea a la exportación pero no lleva contenido informacional independiente. Estos se eliminan antes de la etapa de chunking.
Contenido duplicado
Mensajes reenviados, enlaces compartidos nuevamente, y contenido copiado y pegado que aparece más de una vez en el hilo se desduplican. La primera ocurrencia se retiene; las ocurrencias subsecuentes se notan como referencias si aparecen en un contexto diferente.
Relleno social de baja señal
El relleno conversacional que es social en función pero no informacional, como intercambios extendidos de emoji, descripciones de GIF, y eventos de sticker, se elimina antes de que el conteo de tokens sea calculado para chunking. Esto reduce la carga de token efectiva y concentra la atención del modelo en contenido sustancial.
La lógica de compresión es por qué el resultado es legible. Un hilo de 5.000 mensajes sin procesar podría tomar dos horas para desplazarse. El resumen estructurado debería tomar de cinco a diez minutos de lectura y contener cada pieza de información que importa para el registro.
Una nota sobre privacidad
El flujo de trabajo de exportación y carga significa que mantienes el archivo antes de que algo sea enviado. Fotos, videos, y documentos adjuntos al chat nunca salen de tu dispositivo. Solo el texto del chat y cualquier audio de nota de voz se cargan para procesamiento. Ese contenido se almacena cifrado en tu cuenta, y controlas la eliminación en cualquier momento desde el panel.
Esto importa para hilos largos en particular. Un chat de grupo de WhatsApp de 5.000 mensajes de un proyecto de trabajo o una disputa familiar puede contener información sensible. Saber exactamente qué sale de tu dispositivo y qué no es no un detalle menor.
El pipeline descrito aquí maneja el problema de coherencia significativamente mejor que el chunking ingenuo. No elimina todo error de resumen. Unas pocas restricciones honestas merecen ser enumeradas.
Primero, la calidad del resumen final depende de la calidad de los resúmenes intermedios. Si un fragmento contiene contenido altamente ambiguo, la extracción estructurada para ese fragmento puede perder una decisión o atribuir incorrectamente un elemento de acción. El paso de fusión no puede recuperar información que no fue capturada en la etapa intermedia.
Segundo, hilos muy largos con muchos temas superpuestos, elencos grandes de participantes, y cambios de tema frecuentes son más difíciles de resumir que hilos de proyectos lineales. El registro de entidades ayuda, pero un hilo donde 20 personas discuten 15 corrientes de trabajo simultáneas producirá un resultado más denso y complejo que un hilo donde 4 personas rastrean un único proyecto.
Tercero, la calidad de la nota de voz afecta la precisión de transcripción. Whisper funciona bien en audio limpio, pero ruido de fondo, acentos fuertes, o discurso superpuesto reducirá la precisión. El pipeline marca transcripciones de confianza baja así puedes revisarlas antes de confiar en el resultado.
Estos no son razones para evitar resumir hilos largos. Son razones para tratar el resultado como un punto de partida estructurado para revisión en lugar de un documento final que no requiere verificación, particularmente para casos de uso legal o de cumplimiento.
Si estás trabajando con un hilo largo por primera vez y quieres entender el rango completo de resultados disponibles, resumiendo chats de WhatsApp usando AI cubre el flujo de trabajo de extremo a extremo en más detalle.
