[{"data":1,"prerenderedAt":808},["ShallowReactive",2],{"casos-landing":3},[4,216,412,612],{"id":5,"title":6,"body":7,"cardIndustry":126,"cardOrder":127,"category":128,"deliveredDate":129,"description":118,"diagram":130,"extension":133,"meta":134,"metadata":135,"metrics":151,"navigation":150,"path":167,"seo":168,"status":169,"stem":170,"tagline":171,"tags":172,"techStack":178,"toc":204,"__hash__":215},"proyectos\u002Fproyectos\u002Fleuctra.md","Leuctra",{"type":8,"value":9,"toc":117},"minimark",[10,33,60,80,97],[11,12,15,20,24,27,30],"project-section",{"id":13,"label":14},"problema","01 · EL PROBLEMA",[16,17,19],"h2",{"id":18},"la-voz-es-el-dato-más-rico-y-el-menos-aprovechado","La voz es el dato más rico — y el menos aprovechado",[21,22,23],"p",{},"Las organizaciones enterprise generan volúmenes masivos de contenido de audio que permanecen completamente inaccesibles para sus sistemas de análisis e inteligencia de negocio. Reuniones de directorio, llamadas de atención al cliente, dictados médicos, audiencias legales, entrevistas de recursos humanos: todo ese conocimiento se graba, se archiva, y muere en un servidor sin que nadie lo procese. La estimación conservadora para una institución financiera mediana es que el 60% de la información estratégica generada internamente nunca llega a un sistema estructurado.",[21,25,26],{},"Las soluciones comerciales de reconocimiento de voz presentan un problema estructural que las hace inutilizables en sectores regulados: los datos de audio salen de la infraestructura corporativa para ser procesados en servidores externos. Para la banca, la salud, o cualquier entidad bajo regulación de privacidad de datos —GDPR, HIPAA, Ley Fintech— esto no es una limitación técnica, sino una prohibición legal y una exposición de riesgo que ningún CISO aprueba. Los modelos en la nube, por precisos que sean, simplemente no son una opción.",[21,28,29],{},"El segundo problema es la especificidad del dominio. Un modelo de propósito general transcribe 'Basel III' como 'Basil Three', 'SOFR' como 'sofa', y el nombre de un fondo de inversión como un error de ortografía. En un contexto donde una transcripción incorrecta puede derivar en una decisión de inversión errónea o en un incumplimiento regulatorio documentado, la precisión sobre vocabulario especializado no es una característica deseable: es el requisito central.",[31,32],"diagram-block",{},[11,34,37,41,44,47,50,57],{"id":35,"label":36},"enfoque","02 · ENFOQUE TÉCNICO",[16,38,40],{"id":39},"fine-tuning-por-cliente-inferencia-dentro-del-perímetro","Fine-tuning por cliente, inferencia dentro del perímetro",[21,42,43],{},"Leuctra parte de Whisper Large v3 como modelo base, pero la arquitectura de producción es sustancialmente diferente al modelo que OpenAI publica. El sistema implementa adaptadores LoRA (Low-Rank Adaptation) específicos por cliente, entrenados exclusivamente sobre corpus propietario que nunca abandona la infraestructura del cliente. Esto permite que cada instancia de Leuctra desarrolle un vocabulario especializado, una sensibilidad acústica adaptada al entorno de grabación real, y tolerancia a los patrones de habla de los usuarios específicos de esa organización.",[21,45,46],{},"El pipeline de preprocesamiento incluye detección de actividad de voz con Silero VAD para eliminar silencios y ruido de fondo antes de la inferencia, normalización de audio con librosa para estandarizar niveles de ganancia entre diferentes dispositivos de grabación, y separación de hablantes mediante diarización cuando el audio proviene de conversaciones con múltiples participantes. Cada uno de estos pasos opera localmente, sin dependencias externas.",[21,48,49],{},"El postprocesamiento es donde Leuctra hace su mayor diferenciación sobre Whisper base. Un modelo de lenguaje ligero ONNX —aproximadamente 80M de parámetros— toma la transcripción cruda y aplica puntuación contextual, capitalización de entidades nombradas específicas del dominio, y corrección de terminología especializada mediante un diccionario actualizable sin reentrenamiento del modelo principal. La latencia añadida por este paso es de aproximadamente 12ms por cada 30 segundos de audio.",[51,52,54],"quote-block",{"cite":53},"— EQUIPO DE ARQUITECTURA · TESHALIA",[21,55,56],{},"\"La restricción de privacidad no fue un obstáculo técnico — fue el principio de diseño que definió toda la arquitectura. Construir dentro de ese límite fue lo que hizo el sistema valioso.\"",[21,58,59],{},"El modo de operación en tiempo real utiliza WebSockets para streaming de audio PCM desde el cliente, con transcripción incremental que emite resultados parciales cada 200ms y resultados confirmados cuando el modelo detecta el final de un segmento de habla. La latencia de primer token —el tiempo desde que el usuario termina de hablar hasta que aparece la primera palabra transcrita— es consistentemente inferior a los 100ms en hardware de producción estándar (NVIDIA T4 o superior).",[11,61,64,68,71,74,77],{"id":62,"label":63},"metricas","03 · MÉTRICAS DE PRODUCCIÓN",[16,65,67],{"id":66},"noventa-días-en-producción-con-tres-instituciones","Noventa días en producción con tres instituciones",[21,69,70],{},"El despliegue en producción comenzó con una institución bancaria de primer nivel en México, con expansión posterior a dos firmas de gestión de activos en Colombia y Chile. Los tres entornos presentan características de audio, vocabulario y carga diferentes, lo que permite una evaluación comparativa robusta del modelo base frente a las instancias fine-tuneadas por cliente.",[72,73],"metrics-block",{},[21,75,76],{},"La tasa de error de palabras del 4.2% en vocabulario especializado representa una mejora del 61% sobre Whisper Large v3 base en el mismo corpus de evaluación. El benchmark se ejecuta semanalmente sobre un conjunto de 120 horas de audio anotado manualmente por lingüistas especializados en terminología financiera en español rioplatense, mexicano y andino.",[21,78,79],{},"La disponibilidad del 99.97% equivale a menos de 2.6 horas de inactividad en un año. El sistema implementa un mecanismo de fallback automático a un modelo de menor tamaño (Whisper Medium fine-tuneado) cuando el hardware principal detecta sobrecarga, garantizando continuidad de servicio con degradación controlada de precisión en lugar de indisponibilidad total.",[11,81,84,88,91,94],{"id":82,"label":83},"arquitectura","04 · ARQUITECTURA DEL SISTEMA",[16,85,87],{"id":86},"un-pipeline-diseñado-para-sobrevivir-a-la-infraestructura-del-cliente","Un pipeline diseñado para sobrevivir a la infraestructura del cliente",[21,89,90],{},"El diseño arquitectónico de Leuctra parte de una premisa operacional que la mayoría de los proyectos de IA ignoran: la infraestructura del cliente no será ideal. Habrá hardware heterogéneo, versiones de CUDA desactualizadas, restricciones de red internas, y procesos de change management que hacen imposible una actualización de sistema operativo en menos de seis meses. El sistema debe funcionar correctamente dentro de esas restricciones, no a pesar de ellas.",[21,92,93],{},"La distribución es un contenedor Docker con soporte certificado para NVIDIA CUDA 11.8, 12.0 y 12.1, con fallback a CPU para organizaciones sin GPU disponible. En modo CPU, el sistema utiliza cuantización INT8 del modelo para mantener latencias aceptables (aproximadamente 3x mayor que en GPU) sin cambios en la interfaz de la API. El despliegue en Kubernetes incluye manifiestos de Helm preconfigurados para autoscaling basado en longitud de cola de transcripción.",[21,95,96],{},"La API expone tres modos de operación: transcripción síncrona para fragmentos cortos (hasta 30 segundos, respuesta en la misma request), transcripción asíncrona con webhook para archivos extensos (hasta 4 horas de audio por job), y streaming bidireccional vía WebSocket para casos de uso en tiempo real. Los tres modos comparten el mismo modelo subyacente y producen resultados idénticos para el mismo audio de entrada.",[11,98,101,105,108,111,114],{"id":99,"label":100},"stack","05 · STACK Y DEPENDENCIAS",[16,102,104],{"id":103},"tecnología-elegida-por-su-madurez-no-por-su-novedad","Tecnología elegida por su madurez, no por su novedad",[21,106,107],{},"El criterio central de selección tecnológica en Leuctra fue la estabilidad del ecosistema. Cada componente del stack tiene más de tres años de madurez en producción, documentación exhaustiva, y comunidades activas de soporte. En un sistema que va a operar en infraestructura enterprise sin acceso directo a internet, la capacidad de resolver problemas con documentación local y sin dependencias de servicios externos de soporte no es un nice-to-have: es un requisito de operación.",[21,109,110],{},"El modelo base Whisper Large v3 pesa aproximadamente 3GB en precisión FP16. Los adaptadores LoRA por cliente añaden entre 40MB y 120MB dependiendo del rango de adaptación configurado. El modelo de postprocesamiento ONNX añade 320MB adicionales. El contenedor completo en modo producción ocupa 8.4GB, incluyendo el runtime de CUDA y todas las dependencias del sistema.",[21,112,113],{},"El proceso de fine-tuning de un nuevo cliente requiere entre 8 y 40 horas de audio anotado para producir una mejora estadísticamente significativa sobre el modelo base. El training se ejecuta localmente en la infraestructura del cliente con un script de configuración que Teshalia entrega documentado. La curva de aprendizaje es logarítmica: las primeras 10 horas de datos producen el 80% de la mejora total; las 30 horas adicionales refinan los casos extremos del vocabulario específico.",[115,116],"stack-block",{},{"title":118,"searchDepth":119,"depth":119,"links":120},"",2,[121,122,123,124,125],{"id":18,"depth":119,"text":19},{"id":39,"depth":119,"text":40},{"id":66,"depth":119,"text":67},{"id":86,"depth":119,"text":87},{"id":103,"depth":119,"text":104},"Banca · Servicios financieros",1,"§03 · PROYECTO DESTACADO · PROCESAMIENTO DE LENGUAJE NATURAL","Entregado · Q2 2025",{"component":131,"caption":132},"VoiceTypogram","Fig. 01 — Espectrograma fonético del nombre Leuctra · Representación de la energía por frecuencia de cada fonema","md",{},[136,139,141,144,147],{"label":137,"value":138},"Cliente","Institución financiera (confidencial)",{"label":140,"value":126},"Industria",{"label":142,"value":143},"Duración","8 meses",{"label":145,"value":146},"Equipo","4 ingenieros · 1 arquitecto",{"label":148,"value":149,"accent":150},"Estado","· En producción",true,[152,156,160,164],{"value":153,"label":154,"suffix":155},"4.2","WER en vocabulario financiero especializado","%",{"value":157,"label":158,"suffix":159},"98","Latencia de primer token (P95)","ms",{"value":161,"label":162,"suffix":163},"800","Horas de audio procesadas mensualmente","h",{"value":165,"label":166,"suffix":155},"99.97","Disponibilidad en producción (30 días)","\u002Fproyectos\u002Fleuctra",{"title":6,"description":118},"· EN PRODUCCIÓN","proyectos\u002Fleuctra","Un modelo de reconocimiento de voz de alta precisión diseñado íntegramente para entornos enterprise — sin telemetría, sin datos que salgan del perímetro corporativo.",[173,174,175,176,177],"SPEECH-TO-TEXT","ON-PREMISE","MULTIIDIOMA","FINE-TUNING","API REST",[179,191],{"category":180,"items":181},"MODELO Y PROCESAMIENTO DE AUDIO",[182,183,184,185,186,187,188,189,190],"Python 3.11","PyTorch 2.2","Whisper Large v3","PEFT \u002F LoRA","Silero VAD","librosa","ONNX Runtime","faster-whisper","ctranslate2",{"category":192,"items":193},"INFRAESTRUCTURA Y API",[194,195,196,197,198,199,200,201,202,203],"FastAPI","WebSockets","Docker","NVIDIA CUDA 12.x","Kubernetes","Helm","Redis","PostgreSQL","Prometheus","Grafana",[205,207,209,211,213],{"id":13,"label":206},"01 · El problema",{"id":35,"label":208},"02 · Enfoque técnico",{"id":62,"label":210},"03 · Métricas de producción",{"id":82,"label":212},"04 · Arquitectura",{"id":99,"label":214},"05 · Stack y dependencias","ldx2sa-3Rb7S4601IC6RugM-azrLoZlPyMOd_F9f7JQ",{"id":217,"title":218,"body":219,"cardIndustry":360,"cardOrder":119,"category":361,"deliveredDate":362,"description":118,"diagram":363,"extension":133,"meta":366,"metadata":367,"metrics":376,"navigation":150,"path":392,"seo":393,"status":169,"stem":394,"tagline":395,"tags":396,"techStack":402,"toc":403,"__hash__":411},"proyectos\u002Fproyectos\u002Fcorinto.md","Corinto",{"type":8,"value":220,"toc":347},[221,239,291,310,329],[11,222,224,228,231,234,237],{"id":223,"label":14},"s-problema",[16,225,227],{"id":226},"tres-mil-doscientos-clientes-y-un-archivo-de-excel","Tres mil doscientos clientes y un archivo de Excel",[21,229,230],{},"Toda operación de distribución de energía a escala residencial enfrenta, tarde o temprano, el mismo cuello de botella: la reconciliación de pagos. Para una empresa distribuidora de gas LP que atiende edificios residenciales en zona metropolitana, ese momento llegó cuando la cartera superó los tres mil clientes activos y el volumen de pagos diarios alcanzó los doscientos movimientos. El proceso que había funcionado con ochocientos clientes comenzó a colapsar bajo su propio peso. No porque los operadores trabajaran mal —trabajaban bien, con el único sistema que tenían— sino porque el sistema era fundamentalmente incapaz de escalar.",[21,232,233],{},"El flujo operativo heredado consistía en descargar manualmente cada mañana el archivo de movimientos bancarios del portal del banco, abrirlo en Excel, y contrastar uno a uno cada pago recibido contra una base de clientes mantenida en otra hoja de cálculo. La identificación dependía de la memoria del operador, de convenciones de nomenclatura no siempre respetadas en las referencias de transferencia, y de la disponibilidad de historial físico cuando el monto no correspondía exactamente al consumo del periodo. En días con volumen alto, el proceso consumía entre cuatro y cinco horas de trabajo de una persona. Todos los días, sin excepción.",[21,235,236],{},"Los errores de asignación —pagos aplicados al cliente incorrecto, pagos no identificados que se quedaban en un limbo contable semanas, referencias bancarias ambiguas que requerían llamadas de verificación al residente— generaban un segundo ciclo de correcciones que añadía tiempo y degradaba la confianza del departamento contable en la información que recibía. La estimación interna era que entre el 8% y el 12% de los pagos diarios requerían algún tipo de intervención manual adicional más allá de la asignación inicial. Con doscientos pagos al día, eso son entre dieciséis y veinticuatro excepciones que alguien tiene que resolver.",[31,238],{},[11,240,243,247,250,255,258,262,265,268,272,275,279,282,285],{"id":241,"label":242},"s-modulos","02 · LOS MÓDULOS",[16,244,246],{"id":245},"cuatro-sistemas-que-reemplazan-un-proceso-único-y-frágil","Cuatro sistemas que reemplazan un proceso único y frágil",[21,248,249],{},"El diseño de Corinto parte de una decisión arquitectónica deliberada: no construir un sistema monolítico que haga todo, sino cuatro módulos con responsabilidades claras y bien delimitadas que operan en secuencia y pueden mantenerse o actualizarse de forma independiente. Esta separación no es burocrática —es la diferencia entre un sistema que un equipo de dos personas puede operar y evolucionar, y uno que requiere intervención del equipo de desarrollo para cualquier ajuste operativo.",[251,252,254],"h3",{"id":253},"módulo-de-carga-de-pagos","Módulo de carga de pagos",[21,256,257],{},"El primer punto de entrada del sistema es la carga del archivo de movimientos bancarios. Cada mañana, el operador descarga desde el portal del banco el archivo Excel acumulativo del mes en curso y lo sube al sistema. El módulo de carga ejecuta una validación en tres pasos: primero verifica que el archivo corresponde a la cuenta bancaria configurada, descartando movimientos de otras cuentas o conceptos distintos a pagos de clientes; segundo, filtra únicamente los movimientos del día actual, ignorando los registros ya procesados en cargas anteriores; tercero, verifica contra la base de datos de pagos ya conciliados que ninguno de los movimientos nuevos haya sido cargado previamente, garantizando idempotencia incluso si el operador carga el mismo archivo dos veces por error. El resultado es una lista limpia de pagos pendientes de conciliación, lista para el módulo core.",[251,259,261],{"id":260},"módulo-core-de-conciliación","Módulo core de conciliación",[21,263,264],{},"El corazón operativo del sistema ofrece cuatro métodos de asignación que se aplican en orden de confiabilidad descendente. El primero y más potente es el procesamiento masivo por referencia bancaria: el sistema compara automáticamente cada pago descargado contra la base de clientes buscando coincidencias exactas en el campo de referencia de transferencia. Cuando encuentra un match —que en condiciones normales ocurre para entre el 72% y el 80% de los pagos diarios— lo asigna y lo marca como conciliado sin intervención humana.",[21,266,267],{},"Los pagos que no encuentran match por referencia pasan a la revisión asistida, donde el operador dispone de tres herramientas adicionales. El historial de consumo presenta, para un pago seleccionado, los clientes cuyo consumo del periodo activo coincide exactamente o aproximadamente con el monto recibido, ordenados por probabilidad de correspondencia. El historial de pagos permite buscar a cualquier cliente manualmente y revisar sus movimientos históricos —montos habituales, frecuencia de pago, banco de origen— para determinar si el pago anómalo corresponde a ese cliente por su comportamiento pasado. El registro de efectivo habilita la entrada manual de pagos cobrados en el momento de entrega de recibos mensuales, manteniendo todos los canales de pago dentro del mismo sistema de conciliación.",[251,269,271],{"id":270},"módulo-de-exportación","Módulo de exportación",[21,273,274],{},"Una vez concluida la jornada de conciliación, el módulo de exportación toma todos los pagos asignados durante el día y produce un archivo Excel con la misma estructura del archivo bancario original, enriquecido con la columna de asignación de cliente. Este archivo es el insumo directo que el departamento contable utiliza para su procesamiento posterior. La decisión de mantener el formato del archivo bancario original como base de la exportación fue deliberada: elimina cualquier curva de aprendizaje en contabilidad y garantiza compatibilidad con los procesos contables existentes sin requerir cambios en los flujos del departamento receptor.",[251,276,278],{"id":277},"módulo-de-visualización-y-análisis","Módulo de visualización y análisis",[21,280,281],{},"El módulo de datos resuelve una necesidad que el proceso anterior dejaba completamente sin atender: la visibilidad del estado financiero de cada cliente de forma individual. El operador puede seleccionar cualquier cliente de la cartera y acceder a su historial completo de consumos —metros cúbicos por periodo, importe generado, fecha de entrega del recibo— cruzado con su historial de pagos: monto, fecha, banco de origen y estado de conciliación. Esta vista combinada es la que permite resolver los casos ambiguos en el módulo de conciliación y es también la base para el segundo producto del módulo.",[21,283,284],{},"El reporte de adeudos consolida en un solo documento exportable el estado financiero actualizado de la cartera completa: consumo del periodo activo, pagos registrados, saldo pendiente, y clasificación de cada cliente como al corriente, con adeudo parcial, o sin pago registrado en el periodo. Este reporte, que antes requería construcción manual en Excel cruzando dos archivos distintos, se genera ahora con un solo clic y refleja el estado al momento exacto de la exportación.",[51,286,288],{"cite":287},"— EQUIPO DE PRODUCTO · TESHALIA",[21,289,290],{},"\"El sistema no reemplazó el criterio del operador — lo amplificó. Las decisiones difíciles siguen siendo humanas. Lo que desapareció fue el trabajo mecánico de preparar la información para tomarlas.\"",[11,292,295,299,302,304,307],{"id":293,"label":294},"s-metricas","03 · MÉTRICAS DE IMPACTO",[16,296,298],{"id":297},"medio-día-laboral-recuperado-todos-los-días","Medio día laboral recuperado, todos los días",[21,300,301],{},"El indicador principal de éxito del proyecto se definió desde el diagnóstico inicial: reducir el tiempo diario dedicado al proceso de conciliación de pagos. La medición pre-implementación documentó un promedio de 4.3 horas diarias invertidas por un operador dedicado exclusivamente a esta tarea, con picos de hasta 5.5 horas en días de inicio de mes cuando los pagos acumulados de fin de semana llegaban juntos el lunes por la mañana.",[72,303],{},[21,305,306],{},"El 78% de asignación automática por match de referencia bancaria corresponde al promedio de los primeros 90 días en producción. Este porcentaje varía entre el 68% en días con alto volumen de pagos en efectivo —que por definición no tienen referencia bancaria— y el 89% en días donde la mayoría de los pagos son transferencias electrónicas con referencia bien formateada. El 22% restante se resuelve mediante los tres métodos asistidos del módulo de conciliación, con un tiempo promedio de resolución por pago de aproximadamente 45 segundos frente a los 4-6 minutos del proceso manual anterior.",[21,308,309],{},"El impacto en errores de asignación fue igualmente significativo. En el primer mes de producción, los pagos que requirieron corrección posterior a su asignación inicial representaron el 1.3% del total, frente al 8-12% documentado en el proceso heredado. La diferencia se explica principalmente por la eliminación del factor de fatiga cognitiva: en el proceso manual, los errores se concentraban estadísticamente en los pagos procesados después de la tercera hora de trabajo. En el sistema actual, la precisión del matching automático es constante independientemente del volumen o la hora del día.",[11,311,313,317,320,323,326],{"id":312,"label":83},"s-arquitectura",[16,314,316],{"id":315},"un-sistema-diseñado-para-operar-sin-ingenieros-presentes","Un sistema diseñado para operar sin ingenieros presentes",[21,318,319],{},"El criterio de diseño arquitectónico de Corinto fue que el sistema debía ser completamente operable por el equipo administrativo de la empresa, sin requerir conocimiento técnico más allá del que ya tienen para usar Excel y el portal bancario. Esto tiene implicaciones concretas en cada decisión: el módulo de carga acepta el archivo Excel tal como lo produce el banco, sin transformaciones previas; el módulo de exportación produce un archivo en el mismo formato que el departamento contable ya procesa; y el módulo de conciliación presenta la información en el orden exacto en que el operador la necesita para tomar decisiones, no en el orden en que es conveniente para el sistema generarla.",[21,321,322],{},"El backend en .NET expone una API REST con autenticación por token que sirve los cuatro módulos desde el mismo servidor. La separación entre módulos es conceptual y de interfaz, no de infraestructura: todos comparten la misma base de datos PostgreSQL y el mismo motor de negocio. Esta decisión reduce la superficie de operación considerablemente —un solo servidor, un solo proceso, un solo punto de monitoreo— a costa de un acoplamiento interno que se justifica por el tamaño del equipo que va a mantener el sistema a largo plazo.",[21,324,325],{},"El procesamiento de archivos Excel —tanto la lectura del archivo bancario en la carga como la escritura del archivo enriquecido en la exportación— está completamente delegado a Python mediante un microservicio interno invocado desde el backend .NET vía HTTP local. Esta separación no es arbitraria: el ecosistema de Python para manipulación de archivos Excel (openpyxl, pandas) es sustancialmente más maduro que sus equivalentes en .NET, y la lógica de formato del archivo bancario —que varía según el banco e incluye celdas fusionadas, rangos con nombre y estilos condicionales— requiere control fino del archivo a nivel de celda que Python maneja con mayor naturalidad.",[21,327,328],{},"El frontend en Vue 3 con Composition API se estructura en cuatro vistas principales, una por módulo, con un componente de búsqueda de clientes compartido que aparece contextualmente en la conciliación asistida y en la visualización de datos. El estado de la sesión de conciliación —qué pagos han sido revisados, cuáles han sido asignados, cuáles están pendientes— se mantiene en el servidor entre sesiones, permitiendo que el operador cierre el navegador, regrese horas después, y continúe exactamente donde dejó la jornada de conciliación.",[11,330,332,336,339,342,345],{"id":331,"label":100},"s-stack",[16,333,335],{"id":334},"tecnología-que-el-equipo-de-mantenimiento-puede-sostener","Tecnología que el equipo de mantenimiento puede sostener",[21,337,338],{},"La selección de tecnologías en Corinto estuvo condicionada por un factor que los proyectos internos de software frecuentemente ignoran: ¿quién va a mantener esto en dos años? La respuesta en este caso era clara desde el inicio —el equipo de TI interno de la empresa, de tamaño reducido, con experiencia consolidada en el ecosistema .NET y sin capacidad de incorporar nuevas plataformas a su stack de operaciones. Las elecciones de backend, base de datos e infraestructura de servidor siguieron estrictamente este criterio.",[21,340,341],{},"Vue 3 en el frontend fue una elección del equipo de desarrollo basada en velocidad de implementación y la naturaleza del sistema: cuatro vistas con interacción moderada, sin necesidad de renderizado del lado del servidor ni SEO, con un único perfil de usuario autenticado. La curva de aprendizaje del framework para futuras modificaciones de interfaz es suficientemente accesible para que el equipo de TI interno pueda realizar ajustes menores de layout o de comportamiento sin requerir apoyo externo.",[21,343,344],{},"La decisión más discutida del proyecto fue separar el procesamiento de Excel en un microservicio Python en lugar de usar las librerías disponibles en .NET. El argumento técnico fue concluyente cuando se evaluó el archivo de exportación real del banco: 47 columnas, combinación de estilos por celda, rangos con nombre utilizados por fórmulas del departamento contable, y un esquema de colores condicional que el área financiera usa para clasificar movimientos visualmente. Replicar esa estructura con fidelidad suficiente para que contabilidad pudiera continuar su flujo sin cambios requería openpyxl con acceso directo a la especificación OOXML del archivo. Fue la elección correcta.",[115,346],{},{"title":118,"searchDepth":119,"depth":119,"links":348},[349,350,357,358,359],{"id":226,"depth":119,"text":227},{"id":245,"depth":119,"text":246,"children":351},[352,354,355,356],{"id":253,"depth":353,"text":254},3,{"id":260,"depth":353,"text":261},{"id":270,"depth":353,"text":271},{"id":277,"depth":353,"text":278},{"id":297,"depth":119,"text":298},{"id":315,"depth":119,"text":316},{"id":334,"depth":119,"text":335},"Energía · Distribución residencial","§04 · CASO DE ÉXITO · AUTOMATIZACIÓN DE PROCESOS FINANCIEROS","Entregado · Q4 2024",{"component":364,"caption":365},"ComparisonDiagram","Fig. 01 — Comparativa de flujo operativo · Proceso heredado vs sistema Corinto en producción",{},[368,370,371,373,375],{"label":137,"value":369},"Distribuidora de Gas LP (confidencial)",{"label":140,"value":360},{"label":142,"value":372},"5 meses",{"label":145,"value":374},"2 ingenieros · 1 analista de procesos",{"label":148,"value":149,"accent":150},[377,380,384,388],{"value":378,"label":379,"suffix":155},"78","Pagos conciliados automáticamente sin intervención humana",{"value":381,"label":382,"suffix":383},"3.2","Clientes activos en la cartera al momento del despliegue","K",{"value":385,"label":386,"suffix":387},"~200","Pagos bancarios procesados diariamente en temporada alta","~",{"value":389,"label":390,"suffix":391},"-4h","Reducción diaria en tiempo de operación del proceso de conciliación","-","\u002Fproyectos\u002Fcorinto",{"title":218,"description":118},"proyectos\u002Fcorinto","Un sistema de conciliación de pagos diseñado para transformar un proceso manual de identificación por Excel —lento, propenso al error y dependiente de criterio humano— en un flujo automatizado capaz de procesar 200 pagos diarios en una fracción del tiempo anterior.",[397,398,399,400,401],"CONCILIACIÓN DE PAGOS","AUTOMATIZACIÓN","GAS LP","RESIDENCIAL","PROCESAMIENTO MASIVO",null,[404,405,407,409,410],{"id":223,"label":206},{"id":241,"label":406},"02 · Los módulos",{"id":293,"label":408},"03 · Métricas de impacto",{"id":312,"label":212},{"id":331,"label":214},"yi6ZQ0WpaGcIX4CkJsItv07BXsjbsx4SNaUooDfZFVk",{"id":413,"title":414,"body":415,"cardIndustry":360,"cardOrder":353,"category":544,"deliveredDate":545,"description":118,"diagram":546,"extension":133,"meta":549,"metadata":550,"metrics":558,"navigation":150,"path":572,"seo":573,"status":169,"stem":574,"tagline":575,"tags":576,"techStack":582,"toc":604,"__hash__":611},"proyectos\u002Fproyectos\u002Fargos.md","Argos",{"type":8,"value":416,"toc":533},[417,434,478,495,516],[11,418,419,423,426,429,432],{"id":223,"label":14},[16,420,422],{"id":421},"un-minuto-por-foto-miles-de-fotos-al-mes","Un minuto por foto, miles de fotos al mes",[21,424,425],{},"La facturación de gas LP a edificios residenciales depende de un dato aparentemente trivial: la lectura del medidor. Cada mes, un operador de campo recorre los inmuebles, fotografía cada medidor, y esas fotografías deben convertirse en dos cosas distintas. Primero, una imagen limpia y bien encuadrada del medidor que se incluye en el recibo de consumo como evidencia para el residente. Segundo, el número de la lectura, que alimenta el cálculo de consumo del periodo. En el proceso heredado, ambas tareas eran completamente manuales.",[21,427,428],{},"El trabajo consistía en abrir cada fotografía una por una, recortarla para que el medidor quedara centrado y legible eliminando el fondo irrelevante —tuberías, paredes, sombras, el pulgar ocasional del fotógrafo—, leer manualmente el número del display, y transcribirlo a la base de datos relacionándolo con el cliente correspondiente. El tiempo promedio documentado por fotografía era de aproximadamente un minuto. Con una cartera que supera los tres mil clientes, eso se traduce en decenas de horas de trabajo mensual dedicadas exclusivamente a una tarea mecánica de recorte y transcripción.",[21,430,431],{},"El problema no era solo el tiempo: era la naturaleza del error. La lectura manual de medidores es sorprendentemente propensa a la equivocación. Los displays analógicos de tipo odómetro presentan dígitos parcialmente girados entre dos números; los displays digitales sufren reflejos y sobreexposición; la fatiga acumulada tras revisar cien fotografías degrada la precisión justo cuando más fotografías quedan por procesar. Cada lectura incorrecta se propaga directamente al recibo del cliente, generando disputas, reprocesos y erosión de confianza en la facturación.",[31,433],{},[11,435,438,442,445,449,452,456,459,463,466,469,472],{"id":436,"label":437},"s-pipeline","02 · LA PIPELINE",[16,439,441],{"id":440},"cuatro-modelos-una-decisión-cada-uno","Cuatro modelos, una decisión cada uno",[21,443,444],{},"El núcleo técnico de Argos es una pipeline de cuatro modelos de visión encadenados, donde cada modelo resuelve un único problema bien definido y entrega su salida como entrada del siguiente. Esta arquitectura en cascada es una decisión deliberada frente a la alternativa de un modelo único de extremo a extremo. Un solo modelo que intentara ir de la fotografía cruda a la lectura final tendría que aprender simultáneamente a ignorar fondos, localizar el medidor, encontrar el display, distinguir su tipo y leer dígitos de morfología variable. Dividir el problema en etapas especializadas produce cada componente más simple, más preciso, y —fundamentalmente— más fácil de diagnosticar cuando algo falla.",[251,446,448],{"id":447},"etapa-1-encuadre-del-medidor-yolo","Etapa 1 — Encuadre del medidor (YOLO)",[21,450,451],{},"La primera etapa es un detector YOLO entrenado para una única clase: el medidor completo. Las fotografías de campo llegan con encuadres impredecibles —el medidor puede estar en cualquier región de la imagen, a distintas distancias, rodeado de elementos irrelevantes. El modelo de encuadre localiza el medidor con su caja de mayor confianza, y el sistema recorta la imagen alrededor de esa detección con un margen del 3% para garantizar que toda la información destacada quede contenida. El resultado es una imagen normalizada: el medidor centrado, ocupando la mayor parte del cuadro, con el ruido de fondo eliminado. Esta es la imagen que se incluye en el recibo del residente.",[251,453,455],{"id":454},"etapa-2-localización-y-clasificación-del-display-yolo","Etapa 2 — Localización y clasificación del display (YOLO)",[21,457,458],{},"Sobre el recorte del medidor opera el segundo detector YOLO, cuya tarea es doble: localizar la región específica del display numérico dentro del medidor, y clasificar de qué tipo de display se trata. Esta clasificación es la bifurcación más importante de toda la pipeline. Los medidores de la cartera incluyen dos tecnologías de visualización radicalmente distintas: displays digitales —dígitos de siete segmentos, LED o LCD— y displays analógicos de tipo odómetro mecánico, donde los números están impresos en ruedas giratorias. El modelo recorta el display con un margen del 2% y devuelve su clase, determinando qué modelo de OCR debe procesar la lectura a continuación.",[251,460,462],{"id":461},"etapa-3-reconocimiento-de-la-lectura-crnn-dual","Etapa 3 — Reconocimiento de la lectura (CRNN dual)",[21,464,465],{},"La extracción del número es responsabilidad de dos modelos CRNN independientes —uno especializado en displays digitales, otro en analógicos— seleccionados dinámicamente según la clasificación de la etapa anterior. La decisión de mantener dos modelos separados en lugar de uno general responde a la diferencia morfológica fundamental entre ambos tipos: un dígito de siete segmentos y un dígito impreso en una rueda mecánica parcialmente girada son problemas visuales tan distintos que un modelo único comprometería la precisión en ambos. La especialización permite que cada CRNN aprenda exactamente las particularidades de su dominio: el modelo analógico, por ejemplo, aprende a interpretar el dígito dominante cuando la rueda está en transición entre dos números.",[21,467,468],{},"La arquitectura CRNN combina tres componentes en secuencia. Una red convolucional profunda —seis bloques de convolución con normalización por lotes y activación ReLU, escalando de 64 a 512 canales— extrae características visuales del recorte del display. El pooling final asimétrico preserva la dimensión horizontal, convirtiendo el mapa de características en una secuencia ordenada de izquierda a derecha. Esa secuencia alimenta un LSTM bidireccional de dos capas que modela el contexto: la identidad de cada dígito depende de sus vecinos, y la bidireccionalidad permite que el modelo considere tanto los dígitos anteriores como los posteriores al decidir. Finalmente, una capa lineal proyecta cada paso de la secuencia sobre el vocabulario de caracteres posibles.",[21,470,471],{},"La pieza que conecta todo es la decodificación CTC (Connectionist Temporal Classification). El reto central del OCR de secuencias es que no existe una correspondencia uno a uno entre las columnas de píxeles del display y los dígitos de la lectura: un dígito puede ocupar varias columnas, y los espacios entre dígitos varían. CTC resuelve este problema de alineamiento sin requerir segmentación manual de cada dígito, permitiendo entrenar el modelo con solo la imagen y su transcripción de texto, sin anotar la posición de cada carácter. La decodificación greedy sobre la salida del modelo produce la lectura final, que un paso de postprocesamiento formatea según las convenciones de cada tipo de medidor.",[51,473,475],{"cite":474},"— EQUIPO DE MACHINE LEARNING · TESHALIA",[21,476,477],{},"\"La cascada no fue elegida por elegancia teórica. Fue elegida porque cuando una lectura sale mal, podemos abrir cada etapa y ver exactamente dónde se rompió. Un modelo de caja negra no nos daría eso.\"",[11,479,480,484,487,489,492],{"id":293,"label":294},[16,481,483],{"id":482},"de-un-minuto-a-un-segundo-y-medio","De un minuto a un segundo y medio",[21,485,486],{},"El indicador central del proyecto fue el tiempo de procesamiento por fotografía, y la mejora es del orden de magnitud. El proceso manual promediaba aproximadamente sesenta segundos por imagen entre recorte, lectura y transcripción. La pipeline Argos en producción procesa la misma fotografía —encuadre, recorte de display, clasificación y extracción de lectura— en alrededor de un segundo y medio de inferencia de extremo a extremo. La fotografía recortada y la lectura estructurada aparecen automáticamente al operador, que pasa de transcribir a únicamente verificar.",[72,488],{},[21,490,491],{},"La reducción de 40x en tiempo de procesamiento transformó la economía de la operación: lo que antes ocupaba a una persona durante días enteros del ciclo de facturación se resuelve ahora en una sesión de revisión de unas pocas horas, donde el operador valida las lecturas de baja confianza en lugar de procesar manualmente la totalidad de las imágenes. El sistema expone el nivel de confianza de cada etapa de la pipeline —encuadre, display y OCR— permitiendo al operador concentrar su atención únicamente en las fotografías donde algún modelo reportó incertidumbre.",[21,493,494],{},"El diseño de la pipeline incluye un mecanismo de degradación explícita: cuando una etapa no alcanza el umbral de confianza configurado —un medidor no detectado, un display no localizado— el sistema no inventa un resultado, sino que marca la fotografía con un estado específico ('no_medidor', 'no_display') y la deriva a revisión manual. Esta honestidad del sistema sobre sus propios límites es lo que permite confiar en las lecturas que sí produce automáticamente, y fue clave para la adopción del proceso por parte del equipo de facturación.",[11,496,497,501,504,507,510,513],{"id":312,"label":83},[16,498,500],{"id":499},"una-herramienta-sobre-una-pipeline","Una herramienta sobre una pipeline",[21,502,503],{},"Argos es, en realidad, dos cosas: una pipeline de inferencia y una herramienta que la hace usable. La pipeline —los cuatro modelos y la lógica de orquestación entre ellos— resuelve el problema técnico. Pero una pipeline por sí sola no es un producto; es un script que requiere un ingeniero para ejecutarse. El valor para el cliente está en la capa de aplicación que envuelve esa pipeline y la convierte en un flujo de trabajo que el equipo de facturación puede operar sin conocimiento de machine learning.",[21,505,506],{},"El flujo de trabajo se estructura en cuatro funcionalidades secuenciales. La carga masiva permite subir mediante un único archivo ZIP la totalidad de fotografías de un ciclo de facturación, que el sistema descomprime y encola para procesamiento. El procesamiento individual ejecuta la pipeline sobre cada fotografía cargada y presenta al operador la imagen recortada junto a la lectura extraída, lista para verificación. El ajuste de identificación permite relacionar cada fotografía con su cliente correspondiente, completando el vínculo entre la imagen y el registro de facturación. Y la exportación produce un archivo ZIP con todas las imágenes recortadas por la pipeline, listas para incorporarse a los recibos de consumo.",[21,508,509],{},"El backend en .NET orquesta el flujo de la aplicación, gestiona la cola de procesamiento, y persiste el estado de cada fotografía a lo largo de su ciclo de vida: cargada, procesada, identificada, exportada. La pipeline de visión vive en un servicio Python independiente, invocado por el backend para cada fotografía. Esta separación es arquitectónicamente natural: el ecosistema de Python es el hábitat nativo de PyTorch, Ultralytics YOLO y el resto del stack de visión, mientras que .NET aporta la robustez transaccional y la integración con el resto de los sistemas internos de la empresa que el backend necesita.",[21,511,512],{},"El servicio de inferencia mantiene los cuatro modelos cargados en memoria de forma persistente —dos detectores YOLO y dos CRNN— evitando el costo de inicialización en cada petición. La inferencia se ejecuta bajo torch.no_grad para eliminar la sobrecarga de cálculo de gradientes, y cada etapa registra su tiempo de ejecución y nivel de confianza, exponiendo a la capa de aplicación una traza completa de cómo se produjo cada lectura. Cuando está habilitado, el sistema guarda los recortes intermedios de cada etapa, proporcionando material para auditar errores y para reentrenar los modelos con casos difíciles del mundo real.",[21,514,515],{},"El frontend en Vue presenta cada funcionalidad como una vista dedicada, con la pantalla de procesamiento individual como centro de la experiencia: la fotografía original, el recorte resultante de la pipeline, la lectura extraída, y los indicadores de confianza de cada etapa, todo en una sola vista que el operador recorre fotografía por fotografía hasta completar el ciclo. El estado de procesamiento se mantiene en el servidor, permitiendo pausar y retomar el trabajo de un ciclo de facturación completo sin pérdida de progreso.",[11,517,518,522,525,528,531],{"id":331,"label":100},[16,519,521],{"id":520},"cada-lenguaje-en-su-dominio","Cada lenguaje en su dominio",[21,523,524],{},"La distribución del stack en Argos sigue un principio simple: cada lenguaje hace aquello para lo que es mejor. Python posee el ecosistema de visión por computadora más maduro y completo que existe, y forzar ese trabajo en otra plataforma habría significado reimplementar o adaptar herramientas que en Python funcionan de manera nativa. .NET aporta la solidez transaccional, el manejo de estado y la integración con la infraestructura interna que la capa de aplicación requiere. Vue ofrece la velocidad de desarrollo de interfaz que un producto de uso interno con flujos bien definidos necesita.",[21,526,527],{},"La pipeline de visión se construye sobre PyTorch como motor de inferencia, con Ultralytics YOLO para las dos etapas de detección y una implementación propia de CRNN con decodificación CTC para el OCR. El preprocesamiento y manipulación de imágenes se maneja con OpenCV, que gestiona la decodificación de las fotografías cargadas, los recortes entre etapas, y la normalización de los tensores de entrada para cada modelo. Los pesos de los cuatro modelos se distribuyen como archivos independientes organizados por función, permitiendo actualizar o reentrenar cualquier etapa sin afectar al resto de la cascada.",[21,529,530],{},"La decisión de entrenar modelos propios en lugar de utilizar OCR de propósito general fue determinante para el resultado. Los servicios de OCR comerciales fallan sistemáticamente con displays de medidores: no están entrenados para dígitos de siete segmentos ni para las ruedas parcialmente giradas de los medidores analógicos, y su precisión en este dominio específico es inaceptablemente baja. Entrenar dos CRNN especializados sobre fotografías reales de los medidores de la cartera del cliente produjo modelos que entienden exactamente la morfología que van a encontrar en producción.",[115,532],{},{"title":118,"searchDepth":119,"depth":119,"links":534},[535,536,541,542,543],{"id":421,"depth":119,"text":422},{"id":440,"depth":119,"text":441,"children":537},[538,539,540],{"id":447,"depth":353,"text":448},{"id":454,"depth":353,"text":455},{"id":461,"depth":353,"text":462},{"id":482,"depth":119,"text":483},{"id":499,"depth":119,"text":500},{"id":520,"depth":119,"text":521},"§05 · CASO DE ÉXITO · VISIÓN POR COMPUTADORA","Entregado · Q1 2025",{"component":547,"caption":548},"PipelineDiagram","Fig. 01 — Pipeline de inferencia Argos · Cascada de cuatro modelos de visión desde la fotografía cruda hasta la lectura estructurada",{},[551,552,553,555,557],{"label":137,"value":369},{"label":140,"value":360},{"label":142,"value":554},"4 meses",{"label":145,"value":556},"2 ingenieros de ML · 1 desarrollador full-stack",{"label":148,"value":149,"accent":150},[559,563,567,570],{"value":560,"label":561,"suffix":562},"40","Reducción en tiempo de procesamiento por fotografía","x",{"value":564,"label":565,"suffix":566},"1.5","Latencia promedio de la pipeline completa por imagen","s",{"value":568,"label":569},"4","Modelos de visión encadenados en la cascada de inferencia",{"value":381,"label":571,"suffix":383},"Fotografías procesadas por ciclo mensual de facturación","\u002Fproyectos\u002Fargos",{"title":414,"description":118},"proyectos\u002Fargos","Una pipeline de cuatro modelos de visión que recorta, encuadra y extrae la lectura de fotografías de medidores de gas — convirtiendo un minuto de trabajo manual por imagen en un segundo y medio de inferencia automatizada.",[577,578,579,580,581],"COMPUTER VISION","YOLO","OCR","CRNN","PROCESAMIENTO POR LOTES",[583,593],{"category":584,"items":585},"PIPELINE DE VISIÓN (PYTHON)",[182,586,587,588,589,590,591,592],"PyTorch","Ultralytics YOLO","CRNN + CTC","OpenCV","NumPy","Pillow","CUDA",{"category":594,"items":595},"APLICACIÓN E INFRAESTRUCTURA",[596,597,598,599,600,601,602,201,603],".NET 8","ASP.NET Core","Entity Framework Core","Vue 3","Composition API","Pinia","Axios","Docker (servicio de inferencia)",[605,606,608,609,610],{"id":223,"label":206},{"id":436,"label":607},"02 · La pipeline",{"id":293,"label":408},{"id":312,"label":212},{"id":331,"label":214},"SJCHMgkZEHqMn7wlltxluuKOhiVKTa-DrZUAEYJeaow",{"id":613,"title":614,"body":615,"cardIndustry":360,"cardOrder":751,"category":752,"deliveredDate":129,"description":118,"diagram":753,"extension":133,"meta":756,"metadata":757,"metrics":765,"navigation":150,"path":778,"seo":779,"status":169,"stem":780,"tagline":781,"tags":782,"techStack":787,"toc":801,"__hash__":807},"proyectos\u002Fproyectos\u002Fhermes.md","Hermes",{"type":8,"value":616,"toc":738},[617,634,683,700,721],[11,618,619,623,626,629,632],{"id":223,"label":14},[16,620,622],{"id":621},"una-semana-de-excel-para-facturar-la-cartera-completa","Una semana de Excel para facturar la cartera completa",[21,624,625],{},"La generación de recibos es el momento donde toda la operación de una distribuidora de gas converge en un documento. Cada mes, los datos de consumo de cada cliente —lecturas de medidor, cálculos de importe, pagos registrados— deben transformarse en un recibo individual, agruparse por condominio para su entrega física, y dejar constancia contable del periodo facturado. Para esta empresa, ese proceso era enteramente manual: el registro de datos en hojas de cálculo y el armado de cada recibo sobre una plantilla de Excel, documento por documento.",[21,627,628],{},"El costo del proceso heredado no se medía en horas, sino en días. Generar la totalidad de los recibos de la cartera —más de tres mil clientes distribuidos en decenas de condominios— consumía hasta una semana completa de trabajo en el cierre de cada ciclo de facturación. Una semana en la que un operador transcribía lecturas, aplicaba fórmulas de cálculo de consumo a mano, copiaba resultados a la plantilla de recibo, cruzaba manualmente los pagos recibidos para reflejar el saldo, y repetía el ciclo cliente por cliente. Cualquier error en una fórmula o una transcripción se propagaba silenciosamente al recibo del residente.",[21,630,631],{},"El problema se agravaba por la fragmentación de la información. Los datos de consumo vivían en un archivo, los pagos en otro, los registros de clientes en un tercero, y las fotografías de los medidores en carpetas sueltas sin vínculo estructurado con el recibo correspondiente. Consolidar todo eso en un documento coherente para cada cliente era un trabajo de reconciliación manual que dependía por completo de la disciplina y la memoria del operador, sin ningún sistema que garantizara que ningún cliente quedara sin facturar o facturado dos veces.",[31,633],{},[11,635,636,640,643,647,650,654,657,661,664,668,671,675,678],{"id":241,"label":242},[16,637,639],{"id":638},"cinco-módulos-que-cierran-el-ciclo-de-facturación","Cinco módulos que cierran el ciclo de facturación",[21,641,642],{},"Hermes se estructura en cinco módulos que cubren el ciclo completo de facturación, desde la entrada de datos crudos hasta la entrega del documento final al cliente. Cada módulo resuelve una etapa específica del proceso y se apoya en los datos producidos por el anterior, pero mantiene una responsabilidad acotada que permite operarlo, auditarlo y evolucionarlo de forma independiente. El sistema no reemplaza el criterio del equipo de facturación; reemplaza el trabajo mecánico que ese criterio antes tenía que ejecutar a mano.",[251,644,646],{"id":645},"módulo-de-carga","Módulo de carga",[21,648,649],{},"El punto de entrada del sistema es la carga general de datos, que admite dos tipos de información. La carga de consumos y lecturas se realiza de forma masiva mediante un archivo ZIP que contiene un Excel con los registros del periodo junto a las fotografías correspondientes de cada medidor, vinculando desde el primer momento cada dato numérico con su evidencia visual. La carga de clientes se realiza mediante archivos Excel para el registro de nuevos clientes en el sistema. Esta separación reconoce que ambos flujos tienen cadencias distintas: los consumos llegan cada ciclo, mientras que el alta de clientes es esporádica.",[251,651,653],{"id":652},"módulo-de-generación-de-recibos","Módulo de generación de recibos",[21,655,656],{},"El módulo central es el que da nombre al propósito del sistema. A partir de los consumos y lecturas cargados, calcula el importe de cada cliente —aplicando las fórmulas de consumo cuando la entrada son lecturas de medidor— y genera los recibos individuales. El cálculo y la generación producen tres artefactos simultáneos: los recibos individuales de cada cliente, las listas de entrega organizadas por condominio para el reparto físico, y un paquete ZIP descargable que agrupa recibos y listas de entrega listos para su distribución. Lo que antes era una semana de armado documento por documento se convierte en una operación de generación por lote a nivel de condominio.",[251,658,660],{"id":659},"módulo-de-estados-de-cuenta","Módulo de estados de cuenta",[21,662,663],{},"El tercer módulo produce estados de cuenta individuales por cliente, integrando la información de pagos registrada en el sistema de conciliación. El producto final es un documento PDF que consolida los consumos y pagos de los últimos seis meses, ofreciendo al cliente —y al equipo de atención— una visión histórica de su situación financiera con la distribuidora. Esta integración con el sistema de conciliación es lo que permite que el estado de cuenta refleje no solo lo facturado, sino lo efectivamente pagado, cerrando el círculo entre la generación del recibo y el cobro.",[251,665,667],{"id":666},"módulo-de-datos-de-tanques-y-predicción","Módulo de datos de tanques y predicción",[21,669,670],{},"El cuarto módulo registra información que va más allá del consumo individual: lecturas de tanques y cargas de tanques a nivel de condominio. A partir de estos datos, el sistema genera un reporte de consumo orientado a la planificación logística, con el objetivo de predecir la carga de gas que requerirá cada condominio en el mes próximo. Este módulo transforma el sistema de facturación de una herramienta puramente retrospectiva —qué consumió cada cliente— en una herramienta también prospectiva: cuánto gas habrá que entregar y cuándo, permitiendo a la distribuidora optimizar su logística de reabastecimiento.",[251,672,674],{"id":673},"módulo-de-administración","Módulo de administración",[21,676,677],{},"El quinto módulo gestiona la estructura organizativa del negocio: la información de los condominios, las torres que los componen, y los clientes asociados a cada uno. Permite la visualización de los clientes existentes y la modificación de su información, manteniendo coherente la jerarquía geográfica —condominio, torre, cliente— sobre la que se apoyan todos los demás módulos. Es la capa de datos maestros que garantiza que cuando el módulo de generación agrupa recibos por condominio, o el módulo de tanques predice cargas por inmueble, ambos operan sobre la misma estructura consistente y actualizada.",[51,679,680],{"cite":287},[21,681,682],{},"\"El recibo es el único punto donde el cliente ve toda la operación. Si ese documento llega tarde o llega mal, no importa cuán eficiente sea el resto del negocio. Hermes existe para que ese punto nunca falle.\"",[11,684,685,689,692,694,697],{"id":293,"label":294},[16,686,688],{"id":687},"de-una-semana-a-tres-días","De una semana a tres días",[21,690,691],{},"El indicador principal del proyecto fue el tiempo total del ciclo de facturación: el periodo que transcurre desde que los datos de consumo están disponibles hasta que la totalidad de los recibos de la cartera está generada y lista para entrega. El proceso manual heredado consumía hasta una semana laboral completa. Con Hermes en producción, ese mismo ciclo se cierra en aproximadamente tres días, una reducción cercana al sesenta por ciento que libera al equipo de facturación de la fase más tediosa y propensa a error de su trabajo mensual.",[72,693],{},[21,695,696],{},"La reducción de tiempo es solo la mitad del beneficio. El impacto menos visible pero igualmente significativo está en la integridad de los datos. En el proceso manual, la consolidación de consumos, pagos y registros de cliente dependía de operaciones de copiado entre archivos donde cada paso introducía la posibilidad de un error. Hermes elimina esa fragmentación: los recibos se generan directamente desde una fuente de datos única y consistente, los pagos se integran automáticamente desde el sistema de conciliación, y el sistema garantiza que cada cliente de cada condominio recibe exactamente un recibo por periodo.",[21,698,699],{},"El módulo de predicción de cargas de tanque añadió un valor que el proceso anterior no contemplaba en absoluto. Al convertir los datos históricos de consumo por condominio en una estimación de la carga requerida para el mes siguiente, la distribuidora pasó de reabastecer de forma reactiva —cuando un tanque se acercaba al límite— a una planificación logística informada que reduce tanto los viajes de reabastecimiento innecesarios como el riesgo de desabasto en los inmuebles atendidos.",[11,701,702,706,709,712,715,718],{"id":312,"label":83},[16,703,705],{"id":704},"cada-herramienta-donde-rinde-mejor","Cada herramienta donde rinde mejor",[21,707,708],{},"La arquitectura de Hermes refleja una decisión pragmática sobre dónde ejecutar cada tipo de trabajo. La generación documental masiva, el procesamiento de archivos y el armado de los recibos involucran tres naturalezas técnicas distintas, y forzar todo en una sola plataforma habría significado renunciar a las fortalezas específicas de cada ecosistema. El sistema distribuye estas responsabilidades entre el backend transaccional, el procesamiento de archivos y la generación de documentos, coordinados bajo un único flujo de trabajo coherente.",[21,710,711],{},"El backend en .NET es el orquestador del ciclo de facturación. Gestiona el estado de cada etapa del proceso, persiste los datos de consumos, clientes y la estructura de condominios, y coordina la secuencia de operaciones: carga de información, ejecución del cálculo cuando la entrada son lecturas, integración de los pagos provenientes del sistema de conciliación, generación de recibos agrupados por condominio, y empaquetado final para descarga. Es también el punto de integración con los demás sistemas de la distribuidora, garantizando que los pagos conciliados y las lecturas procesadas fluyan hacia Hermes de forma consistente.",[21,713,714],{},"El procesamiento de archivos —la lectura de los Excel de consumos y clientes, la descompresión de los ZIP de carga con sus fotografías, y el empaquetado de los recibos y listas de entrega en el ZIP de descarga— se delega a scripts de Python invocados desde el backend. Esta elección sigue el mismo principio que el resto del ecosistema de la distribuidora: el manejo programático de archivos Excel y la manipulación de archivos comprimidos encuentran en Python las librerías más maduras y el control más fino sobre el formato de salida, especialmente cuando ese formato debe ser consistente con los procesos del departamento contable.",[21,716,717],{},"La generación de los recibos en sí se ejecuta mediante scripts de JavaScript especializados en el armado del documento. Esta separación de la generación documental respecto del resto del backend permite iterar sobre el diseño y la estructura del recibo —el artefacto que el cliente final efectivamente ve— sin tocar la lógica de negocio del cálculo ni la orquestación del flujo. El estado de cuenta, por su parte, se produce como documento PDF que consolida la información de consumos y pagos de los últimos seis meses en un formato pensado para la lectura del cliente y del equipo de atención.",[21,719,720],{},"El frontend en Vue presenta cada uno de los cinco módulos como un área de trabajo dedicada, con el módulo de generación como centro de la experiencia operativa. El flujo guía al operador a través de la secuencia natural del ciclo —cargar, calcular, conciliar, generar, descargar— manteniendo el estado del proceso en el servidor para que un ciclo de facturación completo pueda pausarse y retomarse sin pérdida de progreso. El módulo de administración expone la estructura de condominios y clientes en vistas editables que mantienen sincronizados los datos maestros sobre los que opera todo el sistema.",[11,722,723,727,730,733,736],{"id":331,"label":100},[16,724,726],{"id":725},"un-stack-heterogéneo-por-diseño-no-por-accidente","Un stack heterogéneo por diseño, no por accidente",[21,728,729],{},"Hermes utiliza cuatro tecnologías distintas, y esa heterogeneidad es una decisión de diseño deliberada antes que el resultado de la inercia. El criterio fue asignar a cada lenguaje el dominio donde es demostrablemente superior: .NET para la lógica de negocio transaccional y la integración con la infraestructura interna de la empresa; Python para el procesamiento de archivos Excel y comprimidos; JavaScript para la generación del documento de recibo; y Vue para la capa de interacción con el operador. Cada frontera entre tecnologías corresponde a una frontera real de responsabilidad.",[21,731,732],{},"La integración con el sistema de conciliación de pagos fue un requisito arquitectónico central. El estado de cuenta y la correcta representación del saldo en cada recibo dependen de que los pagos efectivamente registrados fluyan hacia Hermes de forma confiable y oportuna. Esta integración convierte a Hermes en parte de un ecosistema mayor de sistemas de la distribuidora, donde la conciliación de pagos, el procesamiento de lecturas de medidor y la generación documental operan de forma coordinada sobre la misma base de clientes.",[21,734,735],{},"La generación de documentos en formato consistente fue el reto técnico más exigente del proyecto. El recibo no es solo un contenedor de datos: es un documento con una estructura, un diseño y un formato que el cliente reconoce y que debe mantenerse estable ciclo tras ciclo. Resolver la generación de miles de estos documentos de forma programática, agrupados por condominio y empaquetados para entrega, exigió un control fino sobre el armado del documento que los scripts de JavaScript especializados y la generación de PDF para los estados de cuenta proporcionan.",[115,737],{},{"title":118,"searchDepth":119,"depth":119,"links":739},[740,741,748,749,750],{"id":621,"depth":119,"text":622},{"id":638,"depth":119,"text":639,"children":742},[743,744,745,746,747],{"id":645,"depth":353,"text":646},{"id":652,"depth":353,"text":653},{"id":659,"depth":353,"text":660},{"id":666,"depth":353,"text":667},{"id":673,"depth":353,"text":674},{"id":687,"depth":119,"text":688},{"id":704,"depth":119,"text":705},{"id":725,"depth":119,"text":726},4,"§06 · CASO DE ÉXITO · AUTOMATIZACIÓN DOCUMENTAL",{"component":754,"caption":755},"FlowDiagram","Fig. 01 — Flujo de generación de recibos en Hermes · Desde la carga de consumos hasta la descarga por condominio, integrando los pagos del sistema de conciliación",{},[758,759,760,762,764],{"label":137,"value":369},{"label":140,"value":360},{"label":142,"value":761},"6 meses",{"label":145,"value":763},"2 ingenieros · 1 desarrollador full-stack",{"label":148,"value":149,"accent":150},[766,769,771,774],{"value":767,"label":768,"suffix":387},"~60%","Reducción en el tiempo del ciclo completo de facturación",{"value":381,"label":770,"suffix":383},"Recibos generados por ciclo mensual de facturación",{"value":772,"label":773},"5","Módulos integrados en el ciclo documental completo",{"value":775,"label":776,"suffix":777},"6","Historial consolidado en cada estado de cuenta generado","mo","\u002Fproyectos\u002Fhermes",{"title":614,"description":118},"proyectos\u002Fhermes","Un sistema de generación de recibos que reemplazó el armado manual en plantillas de Excel — reduciendo el ciclo de facturación de toda la cartera de una semana de trabajo a tres días.",[783,784,399,785,786],"GENERACIÓN DOCUMENTAL","FACTURACIÓN","PDF","PIPELINE DE DATOS",[788,794],{"category":789,"items":790},"BACKEND Y PROCESAMIENTO",[596,597,598,201,182,791,792,793],"pandas","openpyxl","zipfile",{"category":795,"items":796},"GENERACIÓN DOCUMENTAL Y FRONTEND",[797,798,799,599,600,601,602,800],"Node.js","JavaScript (generación de recibos)","PDF (estados de cuenta)","Chart.js",[802,803,804,805,806],{"id":223,"label":206},{"id":241,"label":406},{"id":293,"label":408},{"id":312,"label":212},{"id":331,"label":214},"i7EdquhlACRahjsfCwepEnGRCyiXSracniqLqEu0PP4",1781764174605]