Más contenido sobre aplicaciones a medida, tendencias en inteligencia artificial y estrategias efectivas para proyectos tecnológicos exitosos.

Este artículo fue escrito en abril de 2023, por lo que algunas partes pueden estar algo desactualizadas, pero la mayoría de las ideas clave sobre modelos de lenguaje grandes siguen siendo igual de relevantes hoy.

¿Qué ocurre cuando un modelo de lenguaje regular se hace mucho más grande? Se convierte en un modelo de lenguaje grande o LLM. No podemos ampliarlos indefinidamente sin encontrar tres grandes limitaciones: datos de entrenamiento, algoritmos y potencia de cómputo. Resolver estos tres factores fue lo que permitió la transición del aprendizaje automático tradicional al deep learning y probablemente será lo que impulse el siguiente gran salto.

Datos de entrenamiento. Todo modelo necesita datos y cuanto más potente se quiere el modelo, más datos hacen falta. Tradicionalmente recolectar y etiquetar datos era caro y lento. Sin embargo los modelos de lenguaje tienen una ventaja clave: el aprendizaje auto supervisado. Con él se pueden generar etiquetas a partir del propio texto sin intervención humana, por ejemplo prediciendo la siguiente palabra en una frase. Mientras haya texto disponible se puede convertir en datos de entrenamiento masivos.

Escala web. En los primeros días los corpus eran pequeños: MB o pocos GB. Internet cambió eso. La web es esencialmente textual y a escala gigantesca. Proyectos como Common Crawl recogen terabytes de texto y muchas plataformas ofrecen conjuntos de datos depurados de mayor calidad. Combinar aprendizaje auto supervisado con datos a escala web produjo el combustible que permitió modelos como GPT, PaLM o LLaMA.

Algoritmos. Tener océanos de datos no basta: hacen falta algoritmos capaces de digerirlos. Aquí brilló el Transformer, presentado por Google en 2017, que se transformó en la arquitectura dominante de casi todos los LLM actuales. Conceptualmente el Transformer es un motor encoder decoder que procesa secuencias y aprende a transformar una secuencia en otra, por ejemplo en tareas de traducción, resumen o clasificación en formato texto.

Secuencia a secuencia. En NLP trabajamos con secuencias de palabras y muchas tareas encajan en el molde secuencia a secuencia. Un modelo aprende a codificar la entrada en una representación oculta y luego a decodificar esa representación en la salida deseada. Esa representación oculta no es lenguaje humano sino vectores latentes que capturan el significado de forma matemática.

Auto regresión y generación. Los decodificadores de Transformer suelen funcionar de forma autoregresiva: generan token a token y usan sus propias predicciones previas como entrada para el siguiente paso. Esa dinámica es la responsable de la sensación de que modelos como ChatGPT teclean palabra por palabra y permite controlar la probabilidad de cada siguiente token.

Cómputo. Escalar Transformers requiere grandes clústeres de GPUs o TPUs, memoria amplia y pipelines de entrenamiento eficientes. El coste de entrenamiento y el consumo energético son puntos críticos: modelos más grandes necesitan más datos y más cálculo, y entrenar sin la infraestructura adecuada es inviable.

Balance y aplicación empresarial. No siempre el más grande es mejor para una aplicación concreta. Dependiendo del caso conviene ajustar tamaño, datos y optimización para obtener rendimiento, latencia y coste adecuados. En Q2BSTUDIO aplicamos estos principios para crear soluciones útiles para empresas desde aplicaciones a medida hasta agentes IA especializados.

Q2BSTUDIO es una empresa de desarrollo de software que diseña aplicaciones y software a medida, integra soluciones de inteligencia artificial y ofrece servicios integrales de ciberseguridad. Nuestros equipos combinan experiencia en desarrollo y en modelos de lenguaje para implementar agentes IA adaptados a procesos empresariales, automatizaciones y soluciones de inteligencia de negocio con Power BI.

No me gustan las comparaciones entre librerias o frameworks porque la mayor parte de las veces son asimetricas y no comparan lo mismo. Prefiero pensar en el nivel de abstraccion que aporta cada solucion al problema de leer y escribir en el almacenamiento de datos.

Un ejemplo ilustrativo es la diferencia entre Eloquent y Doctrine. En Eloquent el nombre de campo esta acoplado directamente a la consulta y un nombre incorrecto desemboca en un error de base de datos. En Doctrine el nombre del campo esta abstraido por la entidad y el error se detecta en la capa ORM, antes de llegar a la base de datos. Esa diferencia de enfoque es importante porque altera donde se detectan fallos y como se razona sobre los datos.

Doctrine ofrece ademas DQL, que es un DSL muy cercano a SQL. Al usar un DSL en forma de cadena la expresion describe la accion que debe ocurrir durante la obtencion de datos, por lo que parte del procesamiento se realiza durante la consulta. En cambio, las soluciones basadas en builders o en objetos suelen devolver resultados que requieren procesado posterior y pueden disparar consultas adicionales de forma accidental, por ejemplo al navegar relaciones desde una entidad ya cargada.

En otras palabras los patrones de diseño suelen perseguir desacoplar componentes y facilitar razonamiento sobre la estructura del codigo. Un DSL persigue facilitar el razonamiento sobre las acciones que deben ejecutarse. Cuando la cadena del DSL se aproxima al lenguaje del dominio, el modelo mental es mas compacto que cuando se usan capas de patrones para reconstruir esas mismas acciones.

Sin embargo un DSL tiene inconvenientes. Crear una expresion en forma de cadena que soporte las acciones presentes y futuras requiere mayor proyecto inicial y mas engranaje interno, porque esa cadena habitualmente se traduce a codigo o consultas detras de escena. Es menos inmediato de iterar que escribir codigo procedural, aunque suele reducir errores y consultas inesperadas cuando el dominio de acceso a datos esta bien definido.

Mi conclusion practica es que hay dos caminos validos: si las acciones del dominio estan bien comprendidas desde el inicio, apostar por un DSL facilita claridad y reduccion de errores; si las acciones se estabilizan con el tiempo, estudiar introducir un DSL puede mejorar mantenimiento; y en otros casos los patrones de diseño ofrecen la flexibilidad necesaria para iterar rapido y mantener desacoplamiento.

Volver al inicio sin JS ofrece una alternativa ligera y práctica para añadir un boton de regreso al principio sin cargar recursos innecesarios. La idea es simple: usar un ancla nativa con desplazamiento suave gestionado por CSS, respetar la preferencia de reducir movimiento del usuario y mostrar el control solo en publicaciones largas para no molestar en artículos breves.

El resultado es un micro componente que no añade archivos JavaScript, no carga fuentes externas ni genera cambios de diseño que afecten al CLS. Por defecto solo aparece en entradas largas, con un umbral de 900 palabras, y se oculta en escritorio por encima de 900px, asumiendo que los usuarios de escritorio disponen de teclas de pagina y ruedas de desplazamiento eficientes.

Accesibilidad y UX van de la mano: se usa un enlace real con aria-label para ser accesible con lector de pantallas y teclado, se ofrece un anillo de foco visible y se desactiva el desplazamiento suave si el usuario ha activado la preferencia reducir movimiento. Todo ello con CSS e HTML, evitando listeners innecesarios y preservando presupuesto de JavaScript para funcionalidades que realmente lo requieren.

La personalizacion es sencilla mediante filtros en funciones de servidor, por ejemplo ajustar el numero minimo de palabras con vax_backtop_min_words o cambiar el punto de ruptura mobile con vax_backtop_mobile_breakpoint. Tambien es posible modificar colores con vax_backtop_bg y vax_backtop_fg. No hay paneles de administracion, ni configuracion almacenada en base de datos, ni upsells: activas y funcionan tal cual.

Echa un vistazo a este Pen que creé. Flores en Amarillo es una pieza visual que combina estética y funcionalidad para mostrar cómo una experiencia sencilla puede transmitir calidez y energía a través del color y el movimiento.

Detrás de este proyecto está Q2BSTUDIO, una empresa de desarrollo de software especializada en aplicaciones a medida y software a medida para clientes que buscan soluciones únicas y escalables. Aplicamos diseño centrado en el usuario y arquitecturas robustas para crear galerías interactivas, tiendas online y plataformas de gestión personalizadas.

Microsoft 365 Exchange, conocido comúnmente como Exchange Online, es el servicio de correo y calendario en la nube que forma parte de Microsoft 365. Exchange Online se aloja en la nube de Microsoft y funciona por suscripción. Por contraste Exchange Server se instala y gestiona en los servidores de la empresa.

Cómo detener, revisar y liberar correos en Microsoft 365 Exchange

1. Transport Rules o reglas de flujo de correo Puedes crear reglas para redirigir, retrasar o poner en cuarentena mensajes según condiciones como dominio o dirección del remitente, grupo de destinatarios, asunto o contenido. Ejemplo práctico: poner en retención todos los correos de remitentes externos para revisión previa a la entrega. Ruta en el centro de administración: Exchange Admin Center > Mail Flow > Rules.

2. Políticas de cuarentena Configura políticas anti spam o anti phishing para enviar correos sospechosos a cuarentena en lugar de a las bandejas de entrada. Caso de uso: retener correos marcados por Defender para que el equipo de seguridad los analice. Ruta: Microsoft 365 Defender > Email & Collaboration > Policies & Rules > Threat Policies.

3. Configuración de moderación Activa moderación para buzones concretos o grupos de distribución. Caso de uso: los mensajes dirigidos a un grupo quedan en espera hasta que un moderador los apruebe. Ruta: Exchange Admin Center > Recipients > Groups > Edit Group > Message Approval.

4. Retrasar entrega mediante regla de transporte Es posible aplicar un retraso de entrega por un número de minutos determinado. Caso de uso: mantener correos 30 minutos antes de la entrega para permitir revisión o cancelación. Nota: esta opción es limitada y no es adecuada para retenciones a largo plazo.

Resumen breve: las Transport Rules permiten personalizar la lógica de retención en función de remitente, destinatario o contenido; las Políticas de cuarentena añaden una capa de seguridad aislando correos sospechosos; la Moderación garantiza que la comunicación de grupos sensibles o directivos sea revisada; y el Retraso de entrega ofrece una ventana corta de revisión antes de que los mensajes lleguen a las bandejas de entrada. Los administradores deben equilibrar seguridad, cumplimiento y operativa para asegurar que solo los correos adecuados lleguen a los usuarios en el momento correcto.

Introducción En el artículo anterior MVC vs MVVM: what's the difference C# example presentamos mnemónicos que ayudan a pensar MVC y MVVM en términos de flujo de datos en lugar de solo componentes. Estas simplificaciones ilustran diferencias básicas entre Model View Controller y Model View ViewModel pero en aplicaciones reales la realidad es mucho más compleja. Si alguna vez has depurado una aplicación web a altas horas, lidiado con condiciones de carrera en una interfaz ligada a datos o explicado a un cliente por qué los datos deben fluir correctamente sabes que la arquitectura de producción supera con creces el esquema lineal Entrada ? Controlador ? Modelo ? Vista.

Resumen de la serie Esta entrega es la Parte 1 de una serie de cinco partes que exploran patrones de flujo en MVC y MVVM. En esta parte detallamos patrones de flujo en MVC incluyendo pipelines web, integración de capa de servicios, agregación de modelos, middleware y flujos asíncronos. Próximas partes cubrirán MVVM, análisis comparativo, patrones híbridos y una guía para elegir arquitectura.

Por qué importan los patrones de flujo Entender los patrones de flujo no es académico. Impacta directamente en eficiencia de depuración, optimización de rendimiento, decisiones arquitectónicas y comunicación de equipo. Saber si el problema proviene de la validación, del binding o de la agregación de servicios reduce el tiempo de resolución. Identificar si se necesita un flujo sincrónico traduce en distintas estrategias de escalado y caché. Compartir vocabulario sobre flujos facilita discusiones técnicas entre desarrolladores y stakeholders.

Qué cubrimos Secuencias que soportan millones de peticiones web diariamente Flujos reactivos que mantienen UIs sincronizados Patrones asíncronos que evitan bloqueos en UI y servidor Enfoques híbridos que usan lo mejor de ambos mundos Cada patrón se ilustra con consideraciones de rendimiento y recomendaciones de uso.

Expectativas Este artículo asume que conoces los conceptos básicos de MVC y MVVM. No repasaremos qué es un controlador o un ViewModel sino cómo orquestan flujos complejos. Usamos CNET y conceptos aplicables a otros lenguajes y frameworks. Ten en cuenta que las aplicaciones de producción adaptan y combinan patrones para requisitos reales.

La arquitectura es viva Los flujos evolucionan conforme crece la aplicación. Un pipeline simple Request ? Controller ? Model ? View puede transformarse en Request ? Middleware ? Controller ? Service ? Cache ? Model ? Transformer ? View ? Filter ? Response. Esa evolución no siempre indica mala arquitectura sino adaptación a requisitos reales. Los patrones que describimos son herramientas para combinar y evolucionar soluciones.

Parte 1 Patrones de flujo MVC en detalle Aunque la mnemotecnia sugiere un flujo lineal, las aplicaciones MVC de producción orquestan patrones sofisticados. Cada patrón surge para resolver problemas concretos y conocerlos ayuda a elegir la solución adecuada.

Flujos Web MVC Pipeline de petición respuesta Los frameworks modernos insertan middleware, filtros y binding en el pipeline. Componentes como manejo de excepciones, autenticación, limitación de tasa, logging, compresión y caché pueden preprocesar y postprocesar solicitudes y respuestas. Cada middleware puede acortar el pipeline o transformar mensajes y por eso entender el flujo completo es clave para depuración eficaz.

Integración con capa de servicios En aplicaciones reales los controladores delegan en servicios especializados que encapsulan lógica de negocio, transacciones y comunicación con sistemas externos. Ese patrón convierte Controller ? Model en una orquestación de servicios que reservan inventario, procesan pagos, crean entidades y manejan transacciones distribuidas, incluyendo recuperación ante fallo y notificaciones asíncronas.

Agregación de múltiples modelos Dashboards y APIs de reporte suelen agregar datos de distintas fuentes en paralelo. Esto implica consultar bases de datos, servicios de analítica y motores de cálculo de forma concurrente, fusionar resultados, transformar a view models y mantener caché con políticas TTL. Este tipo de flujos mejora latencia pero añade complejidad de consistencia y manejo de errores parciales.

Middleware y filtros La tubería de middleware y los filtros de acción generan flujos bidireccionales donde cada componente puede actuar sobre la petición antes de la acción y sobre la respuesta después de la acción. Ejemplos comunes son métricas de tiempo de procesamiento, validación global, enriquecimiento de respuestas y normalización de errores.

Flujos de validación La validación en MVC se realiza en varios niveles: validación de binding de modelos, validaciones de negocio en servicios, validación de dominio que puede lanzar excepciones específicas y validaciones de servicios externos. Cada nivel genera rutas de error distintas y requiere estrategias de presentación de errores coherentes.

MVC de escritorio y patrón observador En aplicaciones de escritorio el patrón observer permite que modelos notifiquen vistas directamente. Esto facilita actualizaciones en tiempo real entre múltiples vistas pero exige cuidado en hilos de interfaz y sincronización. Además, patrones como command permiten deshacer rehacer y encapsular acciones del usuario de forma reversible.

Interacción vista primero En algunos escenarios la vista maneja entrada inicial, por ejemplo debounce de búsqueda, antes de delegar al controlador. Este enfoque mejora experiencia de usuario y reduce llamadas innecesarias pero implica que la vista implemente cierta lógica de presentación.

APIs y generación de respuestas Las APIs RESTful transforman modelos a múltiples representaciones mediante content negotiation, serializadores y proyectores de campos. Los controladores de API suelen agregar datos desde servicios externos y aplicar cabeceras de caché y ETag para optimizar consumo y coherencia entre clientes.

Patrones asíncronos El uso de async await y tareas en background es habitual para evitar bloqueo de threads y responder rápidamente con tracking IDs para trabajos largos. También se usan colas, workers y notificaciones para completar procesos fuera del request inicial.

Integración en tiempo real WebSockets y hubs proporcionan flujos bidireccionales persistentes para enviar actualizaciones a clientes conectados. En aplicaciones financieras o dashboards en tiempo real la combinación de request response y canales persistentes permite notificar eventos y streamings de datos eficientemente.

Lecciones clave de los patrones MVC La complejidad es por capas: un flujo aparente simple encierra middleware, filtros, servicios y transformaciones. Procesamiento bidireccional: muchos componentes actúan sobre solicitud y respuesta. Flujos paralelos: la agregación concurrente mejora rendimiento pero complica coordinación. Elementos event driven: WebSockets y observadores introducen eventos en arquitecturas tradicionalmente dirigidas por peticiones. Límites de transacción: integrar servicios externos exige definir límites y estrategias de compensación. Entender estos patrones explica por qué MVC sigue siendo dominante en web y cómo proporciona hooks para extender pona arquitecturas modernas.

En esta segunda parte sobre patrones de flujo MVVM rehacemos y simplificamos los conceptos clave para que sean prácticos y aplicables a proyectos reales de desarrollo de software a medida. MVVM no orquesta ciclos secuenciales como MVC sino que crea una malla reactiva donde los cambios se propagan automáticamente mediante enlaces y notificaciones, lo que facilita interfaces interactivas pero exige disciplina en la gestión de estado, memoria y rendimiento.

Flujos directos de vista: gestión de estados visuales y actualizaciones en cascada. En MVVM las vistas pueden controlar sus propias transiciones visuales y animaciones sin necesidad de logicar presentación en el ViewModel. Esto permite que un cambio de propiedad provoque una animación o cambio de estilo íntegramente en la capa de vista, manteniendo limpio el ViewModel. Además, selectores maestros en la UI pueden disparar actualizaciones encadenadas en múltiples controles mediante enlaces declarativos, lo que evita código imperativo y facilita la sincronización entre paneles, pestañas y resúmenes.

Comandos y eventos: encapsulando acciones y estados. Los comandos en MVVM permiten encapsular ejecución, validación y re-evaluación automática de disponibilidad. Un comando asíncrono puede exponer progreso, gestionar bloqueo de UI durante la operación y propagar resultados hacia propiedades enlazadas que disparan a su vez nuevas actualizaciones. Esto es ideal para integrar servicios externos, notificar resultados y mostrar estados de carga sin acoplar la lógica de presentación a la lógica de negocio.

Comunicación entre ViewModels: mensajería y jerarquías. Para evitar referencias directas entre ViewModels se usan patrones de mensajería o mediadores que publican eventos que pueden escuchar múltiples suscriptores. También son frecuentes estructuras jerárquicas donde un ViewModel padre controla el ciclo de vida de hijos y coordina navegación, mientras los hijos comunican eventos al padre mediante eventos, delegados o referencias débiles para evitar fugas de memoria.

Flujos mediados por servicios: repositorios y capas de servicio. Los ViewModels deben interactuar con repositorios y servicios que abstraen caché, acceso a base de datos y llamadas remotas. Operaciones complejas combinan validación, cálculo de costes, reserva de recursos y confirmación de pago mediante orquestaciones que devuelven un flujo claro de estados para la UI. El uso de unidades de trabajo facilita el seguimiento de cambios y la gestión de conflictos de concurrencia.

Validación: inmediata y por reglas de negocio. MVVM admite validación en línea para retroalimentación instantánea y validación de reglas de negocio a través de servicios de dominio. Es habitual combinar validaciones sincrónicas y asíncronas con debounce para llamadas a APIs, mostrando errores y determinando si el formulario es presentable para envío.

Flujos asíncronos y operaciones en segundo plano. MVVM facilita la ejecución de tareas largas con reporte de progreso y cancelación cooperativa. Las actualizaciones parciales pueden consolidarse en la UI mediante invocaciones en el hilo de interfaz, y un gestor central de tareas puede monitorizar, cancelar y notificar progreso hacia los ViewModels.

Eventos externos y actualizaciones en tiempo real. Al integrar notificaciones push, hubs en tiempo real o servicios de streaming, las actualizaciones entran por un canal externo y se propagan al modelo y ViewModels para reflejar cambios inmediatos en la UI. Esto es fundamental en dashboards financieros, monitorización y aplicaciones que requieren latencia baja.

Conversores y transformadores. Los convertidores de valor y multi binding permiten adaptar formatos y combinar varias fuentes en una sola propiedad calculada en la vista. Las propiedades computadas en ViewModels deben suscribirse a cambios en las fuentes para mantener consistencia y evitar recálculos innecesarios.

Desafíos y prácticas recomendadas. MVVM ofrece ventajas reactivas pero implica retos: gestión de memoria por eventos y suscripciones que deben limpiarse; pruebas que requieren simulación de bindings y flujos asíncronos; y rendimiento cuando notificaciones excesivas causan sobrecarga. Técnicas como referencias débiles, disposal explícito, coalescencia de cambios y throttling de eventos ayudan a mitigar estos problemas.

Aplicación práctica y ejemplos de uso. MVVM brilla en aplicaciones de escritorio y multiplataforma con interfaces ricas, en apps móviles que necesitan sincronización y trabajo offline, en paneles de control complejos y en sistemas de monitorización en tiempo real. Para proyectos que demandan integración con servicios cloud y procesamiento de datos, MVVM facilita la separación de responsabilidades entre UI y lógica de negocio.

Snowflake es una de las plataformas de datos en la nube más potentes del mundo y aprender SQL en ella es una decisión inteligente para quien inicia en análisis de datos, ingeniería o inteligencia artificial. Lo mejor es que puedes empezar con una prueba gratuita de 120 días sin tarjeta de crédito, solo curiosidad y unos clics.

Por qué Snowflake: cloud native, escalable y segura. Soporta SQL, Python y flujos de trabajo de machine learning. Usada por empresas como Adobe, Netflix y Capital One. Ofrece una prueba generosa con 400 USD en créditos de uso.

Introducción: la convergencia entre MVC y MVVM en la práctica moderna

En la evolución de las arquitecturas de software la dicotomía entre MVC y MVVM se ha transformado en una convivencia práctica. Aplicaciones modernas requieren renderizado servidor para SEO y primer pintado rápido combinando reactividad cliente para experiencias ricas actualizaciones en tiempo real y capacidades offline. Ese entorno ha motivado patrones híbridos que mezclan la claridad de request response de MVC con el enlace reactivo y la sincronización de estado típica de MVVM.

Evolución hacia arquitecturas híbridas

A medida que las aplicaciones incorporan SSR SPA reactividad y WebSockets las fronteras entre patrones se difuminan. Los equipos optimizan rendimiento y experiencia adoptando servidores que entregan HTML inicial y capas cliente que hidratan y reaccionan ante eventos locales y remotos. Este enfoque permite cumplir requisitos de SEO accesibilidad y experiencia de usuario al mismo tiempo.

MVC con elementos reactivos

Una aplicación tradicional basada en controladores puede seguir encargándose del enrutamiento validaciones y renderizado inicial mientras añade canales de comunicación para actualizaciones en tiempo real suscripciones y una capa ligera de UI reactiva. Este modelo es ideal cuando SEO y rendimiento de carga inicial son críticos y se desea agregar interactividad progresiva sobre contenido ya funcional.

MVVM integrando request response

Por su parte aplicaciones MVVM como clientes de escritorio o móviles mantienen su modelo reactivo y vistas enlazadas pero incorporan llamadas REST y estrategias de sincronización optimista para interoperar con servicios. En este contexto los ViewModels orquestan peticiones reintentos cola offline y rollback en fallos de red manteniendo la UI responsiva y coherente.

Patrones en frameworks modernos

Frameworks contemporáneos muestran la convergencia de ideas: React con Redux impone un flujo unidireccional y estados predecibles combinados con componentes reactivos; Angular combina componentes servicios y RxJS para flujos reactivos y binding bidireccional; Vue ofrece reactividad nativa con stores ligeros; Blazor propone un enfoque híbrido .NET que une renderizado servidor e interactividad cliente. Estas plataformas facilitan implementar optimizaciones como virtual DOM lazy loading code splitting SSR e hidratación.

Estrategias de migración y mejora progresiva

Al modernizar una aplicación conviene migrar gradualmente: añadir endpoints API y canales en tiempo real a una app MVC existente, introducir binding reactivo en vistas clave y progresivamente trasladar lógica a capas de estado centralizado cuando sea necesario. La mejora progresiva garantiza que la aplicación sigue funcionando sin JavaScript y gana capacidades enriquecidas para usuarios con navegadores modernos.

Patrones comunes y buenas prácticas

Entre los patrones recurrentes destacan flujo de datos unidireccional componentes reutilizables gestión centralizada de estado propiedades computadas y hooks de ciclo de vida. En cuanto a rendimiento es habitual combinar SSR con hydratation lazy loading y renderizado incremental para minimizar tiempo hasta interacción y consumo de recursos.

Cómo aplicamos estos enfoques en Q2BSTUDIO