Técnicas

Generación mejorada por recuperación (RAG por sus siglas en inglés) es el patrón preferido por nuestros equipos para mejorar la calidad de las respuestas generadas por un modelo lingüístico grande (LLM por sus siglas en inglés). Lo hemos utilizado con éxito en varios proyectos, incluyendo el popular Jugalbandi AI Platform. Con RAG, la información sobre documentos relevantes y fiables -en formatos como HTML y PDF- se almacena en una base de datos que admita un tipo de datos vectorial o una búsqueda eficiente de documentos, como pgvector, Qdrant o Elasticsearch Relevance Engine. Para una consulta determinada, la base de datos se consulta para recuperar documentos relevantes, que luego se combinan con la consulta para proporcionar un contexto más enriquecido al LLM. De este modo se obtienen resultados de mayor calidad y se reducen considerablemente las alucinaciones. La ventana de contexto -que determina el tamaño máximo de entrada del LLM- es limitada, lo que significa que seleccionar los documentos más relevantes es crucial. Mejoramos la relevancia del contenido que se añade a la consulta mediante re-ranking. Del mismo modo, los documentos suelen ser demasiado grandes para calcular una incrustación, lo que significa que deben dividirse en fragmentos más pequeños. Suele ser un problema difícil, y una solución es que los fragmentos se solapen hasta cierto punto.

Backstage de Spotify ha sido ampliamente adoptado por nuestra base de clientes como la plataforma preferida para alojar portales de experiencia de desarrolladores. Backstage, por sí solo, es un cascarón que permite almacenar plugins y que provee una interfaz para manejar el catálogo de recursos que conforman el ecosistema de una plataforma. Cualquier entidad expuesta o manejada por Backstage está configurada en el archivo de información del catálogo, el cual contiene información tal como estado, ciclo de vida, dependencias y APIs, entre otros detalles. Por defecto, los descriptores de entidades individuales son escritos a mano y usualmente mantenidos y versionados por el equipo responsable del componente en cuestión. Mantener los descriptores actualizados puede ser tedioso y crea una barrera a la adopción por parte de los desarrolladores. También, siempre está la posibilidad de que los cambios sean pasados por alto, o que algunos componentes sean completamente olvidados. Encontramos que generar automáticamente los descriptores de entidades de Backstage es más eficiente y menos propenso a errores. La mayoría de las organizaciones tienen fuentes existentes de información que pueden dar el primer empujón al proceso de generar las entradas del catálogo. Buenas prácticas de desarrollo, por ejemplo, usando tags apropiadas o agregando metadata a archivos fuente, pueden simplificar el descubrimiento de entidades y la generación de descriptores. Estos procesos automatizados pueden ejecutarse regularmente, por ejemplo una vez al día, para mantener el catálogo actualizado.

Los modelos de lenguaje grandes (LLMs: Large Language Models en inglés) son la navaja suiza del Procesamiento del Lenguaje Natural (PLN, del inglés NLP: Natural Language Processing). Sin embargo, también son bastante costosos y no siempre son la mejor herramienta para tus tareas — a veces es más efectivo usar simplemente un sacacorchos. De hecho, hay mucho potencial en combinar el NLP tradicional con los LLMs , o construir múltiples estrategias NLP en conjunto con LLMs para implementar casos de uso y aprovechar los LLMs para los pasos en los que realmente necesitamos sus capacidades. Es menos costoso, y puede ser más efectivo para solventar parte de tu caso de uso, usar métodos tradicionales de ciencias de datos y NLP para agrupar documentos (clustering), identificar temas y clasificar, e incluso resumir. Cuando necesitamos generar y resumir textos más largos, o combinar varios documentos grandes, es cuando usamos LLMs para aprovechar la capacidad de atención y memoria superiores de éstos. Por ejemplo, hemos usado exitosamente esta combinación de técnicas para generar un informe exhaustivo de tendencias de un dominio. En este caso, hemos partido de una recopilación de una enorme cantidad de documentos de tendencias individuales y hemos usado el clustering tradicional junto con el poder generativo de los LLMs.

Cumplimiento continuo es la práctica de garantizar que los procesos y tecnologías de desarrollo de software cumplan con las regulaciones de la industria y los estándares de seguridad de manera continua, aprovechando en gran medida la automatización. Verificación manual de las vulnerabilidades de seguridad y el cumplimiento de las regulaciones pueden ralentizar el desarrollo e introducir errores.

Como una alternativa, las organizaciones pueden automatizar las verificaciones y auditorías de cumplimiento. Pueden integrar herramientas en los pipelines de desarrollo de software, permitiendo a los equipos detectar y abordar los problemas de cumplimiento al inicio del proceso de desarrollo.

Codificar las reglas de cumplimiento y las mejores prácticas ayuda a reforzar las políticas y los estándares uniformente en los equipos. Esto permite analizar los cambios de código en busca de vulnerabilidades, aplicar estándares de codificación y rastrear los cambios en la configuración de la infraestructura para garantizar que cumplan con los requisitos de cumplimiento.

Por último, los informes automatizados de lo mencionado anteriormente simplifican las auditorías y proporcionan evidencia clara del cumplimiento. Hemos conversado acerca de técnicas como publicación SBOMs y aplicación de recomendaciones de SLSA - estos son muy buenos puntos de partida.

Los beneficios de esta técnica son múltiples. En primer lugar, la automatización promueve un software más seguro al identificar y mitigar las vulnerabilidades de manera temprana y, en segundo lugar, los ciclos de desarrollo se aceleran a medida que se eliminan las tareas manuales. Reducción de costos y mayor consistencia son ventajas adicionales.

Para industrias críticas como vehículos autónomos, el cumplimiento continuo automatizado puede mejorar la eficiencia y la confiabilidad del proceso de certificación, lo que en última instancia conduce a vehículos más seguros y confiables en las carreteras.

Aunque no es un concepto nuevo, hemos observado la creciente disponibilidad y uso de la ejecución descentralizada de código a través de redes de distribución de contenidos (CDNs). Servicios como Cloudflare Workers o Amazon CloudFront Edge Functions proveen mecanismos para ejecutar fragmentos de código serverless cerca de la ubicación geográfica del cliente. Las Edge functions no solo ofrecen una latencia más baja si se puede generar una respuesta en el borde, sino que también ofrecen la oportunidad de re-escribir peticiones y respuestas dependiendo de la ubicación del servidor regional. Por ejemplo, puede reescribir una URL de petición para dirigirla a un servidor específico que tenga datos locales relevantes para un campo encontrado en el cuerpo de la petición. Este enfoque es el más adecuado para procesos cortos, sin estado y de ejecución rápida debido a que el poder computacional en el borde es limitado.

Security champions son miembros del equipo que reflexionan de forma crítica sobre las repercusiones en la seguridad de las decisiones de entrega, tanto técnicas como no técnicas. Plantean estas preguntas y preocupaciones a los líderes de equipo y conocen a fondo las directrices y requisitos básicos de seguridad. Ayudan a los equipos de desarrollo a enfocar todas las actividades durante la entrega del software con una mentalidad de seguridad, reduciendo así los riesgos generales para la seguridad de los sistemas que desarrollan. Security champion no es un puesto aparte, sino una responsabilidad asignada a un miembro del equipo que recibe la formación adecuada de profesionales de la seguridad. Equipados con esta formación, los security champions mejoran la concienciación sobre seguridad del equipo difundiendo conocimientos y actuando como puente entre los equipos de desarrollo y seguridad. Un gran ejemplo de actividad de los security champions es que pueden ayudar a impulsar dentro del equipo el modelado de amenazas, que ayuda a los equipos a pensar en los riesgos de seguridad desde el principio. Designar y formar a un security champion en un equipo es un gran primer paso, pero confiar únicamente en los security champions sin el compromiso adecuado de los líderes puede acarrear problemas. Según nuestra experiencia, crear una mentalidad de seguridad requiere el compromiso de todo el equipo y de los directivos.

Texto a SQL es una técnica que convierte consultas escritas en lenguaje natural a consultas SQL que pueden ser ejecutadas en una base de datos. Aunque los grandes modelos de lenguaje (LLM, large language models) pueden entender y transformar el lenguaje natural, la creación de consultas SQL precisas para un esquema propio puede convertirse en una tarea desafiante. Aquí entra Vanna, un marco de trabajo de generación aumentada por recuperación (RAG, retrieval-augmented generation) escrito en Python, de código abierto, para la generación de SQL. Vanna opera en dos pasos: primero se debe crear embeddings usando sentencias del lenguaje de definición de datos (DDL) y consultas SQL de ejemplo para ese esquema, y luego se puede hacer preguntas en lenguaje natural. Aunque Vanna puede funcionar con cualquier LLM, recomendamos evaluar NSQL, un LLM específico de dominio para tareas de conversión de texto a SQL.

Seguimos observando las mejoras de los equipos en sus ecosistemas al tratar el índice de salud de la misma forma que los otros objetivos de nivel de servicio (SLOs) y priorizando mejoras en consecuencia, en vez de solamente enfocarse en hacer seguimiento de la deuda técnica. Al asignar recursos eficientemente para abordar los problemas con mayor impacto en la salud, equipos y organizaciones pueden reducir costos de mantenimiento a largo plazo y evolucionar productos de manera más eficiente. Este enfoque también mejora la comunicación entre stakeholders tanto técnicos como no técnicos, fomentando un entendimiento común del estado del sistema. A pesar de que las métricas pueden variar entre organizaciones (Ver este artículo para ejemplos) al final contribuyen a una sostenibilidad a largo plazo y se aseguran de que el software se mantenga adaptable y competitivo. En un panorama digital que cambia rápidamente, enfocarse en el seguimiento de la salud sobre la deuda técnica de los sistemas proporciona una estrategia estructurada y basada en evidencias para mantenerlos y mejorarlos.

Actualmente, se habla principalmente de herramientas de asistencia de codificación IA como GitHub Copilot en el contexto de ayudar y mejorar el trabajo individual. Sin embargo, la entrega de software es y seguirá siendo un trabajo en equipo, por lo que deberías buscar formas de crear asistentes de equipo con IA para ayudar a formar elequipo 10x, en lugar de un montón de silos de ingenieros 10x asistidos por IA. Hemos comenzado a utilizar un enfoque de asistencia en equipo que puede incrementar la amplificación del conocimiento, el perfeccionamiento de habilidades y la alineación mediante una combinación de prompts y fuentes de conocimiento. Los prompts estandarizados facilitan la aplicación de las mejores prácticas acordadas dentro del contexto de equipo, tales como técnicas y plantillas para la redacción de historias de usuario o la implementación de prácticas como el modelado de amenazas. Además de los prompts, las fuentes de conocimiento disponibilizadas a través de la generación aumentada por recuperación proporcionan información contextualmente relevante proveniente de directrices organizacionales o bases de conocimiento específicas de la industria. Este enfoque otorga a los miembros del equipo acceso al conocimiento y los recursos que necesitan justo a tiempo.

Chatbots producidos por large language models (LLMs) están obteniendo gran popularidad hoy en día, y estamos observando técnicas emergentes alrededor de su uso en producción. Uno de los desafíos para esto es entender cómo los usuarios están interactuando con un chatbot el cual es manejado por un ente genérico como un LLM, donde la conversación puede ir en distintas direcciones. Entender la realidad de los flujos de conversación es crucial para perfeccionar el producto y mejorar los rangos de conversión. Una técnica para superar este problema es utilizar análisis gráfico para LLM-Backed chats. Los agentes que mantienen un chat con un resultado específico - tales como una acción de compra o una resolución exitosa ante un problema de consumidor - usualmente son representados por un estado deseado de máquina. Al cargar todas los diálogos en una gráfica, se puede analizar patrones actuales y observar discrepancias para el estado esperado de la máquina. Esto ayuda a encontrar fallas y oportunidades para mejoras de producto.

ChatOps impulsada por LLMs (Modelos de Lenguaje Grandes, LLM por sus siglas en inglés) es una aplicación emergente de los modelos de lenguaje grandes mediante una plataforma de chat (principalmente Slack) que permite a los ingenieros construir, desplegar y operar software empleando el lenguaje natural. Tiene el potencial de optimizar los flujos de trabajo de ingeniería mejorando las posibilidades de descubrimiento de los servicios de la plataforma y haciendo que sean más amigables para el usuario. En el momento de escribir estas líneas, dos ejemplos tempranos son PromptOps y Kubiya. Sin embargo, considerando la delicadeza necesaria para los entornos de producción, las organizaciones deben evaluar exhaustivamente estas herramientas antes de permitirles acercarse a producción.

Los agentes autónomos impulsados por LLMs (Modelos de Lenguaje Grandes, LLM por sus siglas en inglés) están evolucionando más allá de sistemas de un solo agente y sistemas multiagente estáticos con la aparición de frameworks como Autogen y CrewAI . Estos frameworks permiten a los usuarios definir agentes con roles específicos, asignarles tareas y permiten que los agentes colaboren para completar esas tareas mediante la delegación o la conversación. De manera similar a los sistemas de un solo agente que surgieron antes, como AutoGPT , los agentes individuales pueden descomponer tareas, utilizar herramientas preconfiguradas y solicitar opinión humana. Aunque todavía se encuentra en sus primeras fases de desarrollo, este área se está desarrollando rápidamente y tiene un gran potencial para la exploración.

Las IA Generativas (GenAI) y modelos de lenguaje grandes (LLMs) pueden ayudar a los desarrolladores a escribir y entender código. Hasta ahora, en la aplicación práctica, esto ha sido limitado para extractos pequeños de código, pero más desarrollos de productos y tecnologías están emergiendo para usar GenAI para entender las bases de código heredado. Esto es particularmente útil en el caso de bases de código heredado que no están bien documentadas o donde la documentación está desactualizada o sea engañosa. Por ejemplo, Driver AI o bloop usan enfoques RAG que combinan inteligencia de lenguaje y búsqueda de código con LLMs para ayudar a los usuarios a encontrar su camino dentro de una base de código. Los modelos emergentes con ventanas de contexto cada vez más grandes también ayudan a hacer estas técnicas más viables para bases de código de tamaño considerable. Otra aplicación prometedora de GenAI para código heredado está en el espacio de la modernización de mainframes, allí los cuellos de botella comúnmente se dan en la ingeniería inversa, en donde está la necesidad de entender la base de código existente y convertir este entendimiento en requisitos para modernizar el proyecto. El uso de GenAI para asistir a los encargados del proceso de ingeniería inversa puede ayudarles a realizar su trabajo más rápidamente.

Recientemente, Zoom liberó como código abierto a su Sistema de Puntuación de Impacto de Vulnerabilidades o VISS (Vulnerability Impact Scoring System). Éste se enfoca en la puntuación de vulnerabilidades priorizando las medidas de seguridad verdaderamente demostradas. VISS se diferencia del Sistema Común de Puntuación de Vulnerabilidades (CVSS, Common Vulnerability Scoring System) al no enfocarse en los escenarios más pesimistas e intentar medir de forma más objetiva el impacto de las vulnerabilidades desde la perspectiva de la defensa. Para esto, VISS provee una interfaz web donde se puede calcular la puntuación de una vulnerabilidad basada en varios parámetros, categorizados en plataforma, infraestructura y grupos de datos, incluyendo el impacto sobre la plataforma, el número de tenants impactados, el impacto sobre los datos y más. Aunque no tenemos mucha experiencia práctica con esta herramienta en específico, basados en la industria y en el contexto, creemos que vale la pena poner en práctica este método de evaluación adaptado a prioridades.

Mientras aplaudimos el foco en las pruebas automatizadas, seguimos viendo numerosas organizaciones que invierten excesivamente en lo que creemos son ineficaces Amplias pruebas de integración. Como el término “prueba de integración” es ambiguo, tomamos la clasificación amplia de la entrada bliki de Martin Fowler sobre este tema, haciendo referencia a una prueba que requiere versiones en produccion de todas las dependencias en tiempo de ejecución. Tales pruebas son obviamente costosas, ya que requieren entornos de prueba con todas las funcionalidades, con la infraestructura necesaria, datos y servicios. Administrar las versiones correctas de dichas dependencias requiere de un trabajo de coordinación importante, que tiende a ralentizar los ciclos de lanzamiento. Para finalizar, las pruebas por sí mismas son comúnmente frágiles y de poca ayuda. Por ejemplo, necesitamos mucho esfuerzo para determinar si una prueba falló por el código nuevo, la versión incorrecta de dependencias o por el entorno, además, el mensaje de error rara vez ayuda a identificar la fuente del error. Estas críticas no significan que nos opongamos a las pruebas automatizadas de integración “caja negra” en general, más bien, encontramos que un enfoque más útil es aquel que balancea las necesidades de confianza con la frecuencia de lanzamiento. Esto se puede hacer en dos etapas: primero validando el comportamiento del sistema bajo prueba asumiendo cierto conjunto de respuestas de las dependencias en tiempo de ejecución y luego, validando dichas suposiciones. La primera etapa usa la virtualización de servicios para crear pruebas dobles de dependencias en tiempo de ejecución y validar el comportamiento del sistema bajo la prueba. Eso simplifica lo que afecta a la gestión de los datos de prueba y permite tests deterministas. La segunda etapa utiliza pruebas de contrato para validar las suposiciones del entorno con dependencias reales.

En la carrera por aprovechar lo último en IA, muchas organizaciones están adoptando rápidamente modelos de lenguaje de gran tamaño (LLMs) para una variedad de aplicaciones, desde la generación de contenido hasta procesos complejos de toma de decisiones. El atractivo de los LLMs es innegable; ofrecen una solución aparentemente sin esfuerzo a problemas complejos, y los desarrolladores a menudo pueden crear dicha solución rápidamente y sin necesidad de años de experiencia en aprendizaje automático profundo. Puede ser tentador implementar una solución basada en LLM tan pronto como esté más o menos funcionando y luego continuar. Aunque estas pruebas de valor basadas en LLM son útiles, recomendamos a los equipos que miren cuidadosamente para qué se está utilizando la tecnología y consideren si un LLM es realmente la solución final adecuada. Muchos problemas que un LLM puede resolver — como el análisis de sentimientos o la clasificación de contenido — se pueden resolver de manera más barata y sencilla usando procesamiento de lenguaje natural (NLP) tradicional. Analizar lo que el LLM está haciendo y luego analizar otras soluciones potenciales no sólo mitiga los riesgos asociados con el uso excesivamente entusiasta de LLM , sino que también promueve una comprensión y aplicación más matizada de las tecnologías de IA.

A medida que las organizaciones buscan formas de hacer que los modelos de lenguaje grandes (LLM por sus siglas en inglés) funcionen en el contexto de su producto, dominio o conocimiento organizativo, estamos viendo prisa por afinar LLMs. Aunque afinar un LLM puede ser una herramienta potente para ganar más especialización para un caso de uso, en muchos casos no es necesario. Uno de los casos más comunes de prisa por afinar mal encaminada es hacer a una aplicación respaldada por LLM consciente de conocimiento específico y hechos o de los códigos fuente de una organización. En la gran mayoría de los casos, usar una forma de retrieval-augmented generation (RAG) ofrece una mejor solución y mejor relación coste-beneficio. Afinar requiere de considerables recursos de cómputo y experiencia, e introduce incluso más desafíos en relación con datos sensibles y propietarios que RAG. También existe un riesgo de subajuste cuando no se dispone de suficientes datos para afinar, o, con menos frecuencia, de sobreajuste cuando se tienen demasiados datos y por lo tanto no se encuentra el balance correcto de especificidad de la tarea que se necesita. Esté atento a estos equilibrios y considere las alternativas antes de apresurarse a afinar un LLM para su caso de uso.

Con la adopción de marcos de trabajo como Next.js y htmx, vemos un mayor uso de la renderización en el servidor (SSR, server-side rendering). Como una tecnología natural para el navegador, no es trivial utilizar Componentes Web en el servidor. Han surgido marcos de trabajo para facilitar esta tarea, a veces incluso utilizando un motor de navegador, pero la complejidad sigue ahí. Nuestros equipos se encuentran con que necesitan de soluciones alternativas y de esfuerzos extra para ordenar los componentes para el front-end y para el servidor. Peor que la experiencia de desarrollo es la experiencia de usuario: el rendimiento de carga de la página se ve afectado cuando componentes web personalizados tienen que cargarse e hidratarse en el navegador, e incluso, inevitablemente, contenido sin estilo destella por unos momentos o se producen desplazamientos en el diseño, a pesar de que los componentes ya se han renderizado previamente y se les han realizado minuciosos ajustes. Como ya se mencionó en el Radar anterior, uno de nuestros equipos tuvo que cambiar su sistema de diseño basado en Componentes Web y dejar de usar Stencil debido a estos problemas. Recientemente recibimos informes de otro equipo que acabó sustituyendo los componentes renderizados en el servidor por componentes para el navegador debido a la complejidad de desarrollo. Sugerimos tener cuidado con el uso de componentes web para aplicaciones renderizadas en el servidor , incluso si los marcos de trabajo los soportan.