Extended Context - memoria inteligente de relaciones con clientes

¿Qué es? Un servicio de backend potenciado por IA para crear y mantiene una "memoria" estructurada y siempre actualizada de la relación con cada uno de los clientes en Belong, una plataforma de gestión inmobiliaria.

El flujo de recursivo de IA ingiere el historial de comunicaciones y actividad en varios canales por parte del usuario (y otras entidades posibles), además del estado actual en otras fuentes de datos, y lo condensa en un resumen conciso y consultable. El documento estructurado de salida almacena, entre otras cosas, las promesas iniciales hechas a la persona, interacciones clave, cualquier problema que haya habido, características de personalidad del usuario, e hitos en el ciclo de vida de la relación. Esto habilita a que otros sistemas de la compañía puedan aprovechar la información procesada en sus herramientas, como por ejemplo otros agentes internos que necesiten mucho contexto disponible al instante.

Escala aproximada. Más de 80k entidades tienen hoy en día un resumen vivo, y el pipeline ha procesado más de 2 millones de resúmenes hasta la fecha (más de 5k por día). Dado que cada entidad se resume una vez y luego se vuelve a resumir de forma incremental a medida que llega nueva actividad, ese número de trabajos refleja un mantenimiento continuo a lo largo de la vida del servicio.

Características relevantes:

• Resumen incremental con checkpoints. En lugar de releer todo el historial de una entidad cada vez, rastrea una marca de agua (watermark) de lo ya analizado e incorpora únicamente la actividad nueva al resumen anterior. Los historiales largos se procesan en lotes conscientes del presupuesto de tokens, y cada lote se persiste como checkpoint, de modo que una ejecución fallida se reanuda donde quedó en vez de empezar de cero.
• Salida estructurada y autorreparable. El modelo devuelve resúmenes estructurados y fuertemente tipados, validados contra un esquema, con capas de parsers autocorrectivos que reparan automáticamente las salidas mal formadas — confiabilidad sin intervención humana.
• Optimización de costos. El pipeline se descompone en distintas etapas, que se enfocan en distintos aspectos de la tarea de resumir. Así, los modelos de IA son elegidos por niveles: un modelo económico para el grueso del trabajo, uno más potente solo para reintentos o etapas complejas. La arquitectura de los prompts fue ordenada deliberadamente para maximizar el prefix caching del proveedor. Además, armé batching adaptativo para respetar los límites de contexto, todo orientado a mantener bajo el costo por resumen a gran escala.
• Orientado a eventos y consistente de forma diferida. El trabajo se desacopla mediante una cola de mensajes, de forma que las lecturas respondan al instante desde caché, y si hace falta una actualización del resumen, es disparada en segundo plano cuando los datos, así el trabajo del LLM nunca queda en el camino crítico del usuario.
• Robustez en producción. Reintentos acotados, con clasificación de fallos, cierre ordenado, garbage collection de trabajos fallidos, dead-letter queue (DLQ) para mensajes con procesamiento fallido, métricas/observabilidad completas.

Algo que personalmente me gustó: diseñé la arquitectura de prompts basándome en los principios SOLID de programación orientada a objetos. Esto me permitió compartir código entre las distintas etapas del pipeline de resumen, y así minimizar la introducción de errores y simplificar el mantenimiento.

Stack: TypeScript, LangChain para abstraer el proveedor y modelo de LLM, MongoDB como DB NoSQL, RabbitMQ a través de AWS MQ, desplegado como servicio de AWS ECS desde un contenedor definido personalizadamente, con trazabilidad/métricas en todo el proceso.