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.

AI coding assistance tools like GitHub Copilot are currently mostly talked about in the context of assisting and enhancing an individual's work. However, software delivery is and will remain team work, so you should be looking for ways to create AI team assistants to help create the "10x team," as opposed to a bunch of siloed AI-assisted 10x engineers. We've started using a team assistance approach that can increase knowledge amplification, upskilling and alignment through a combination of prompts and knowledge sources. Standardized prompts facilitate the use of agreed-upon best practices in the team context, such as techniques and templates for user story writing or the implementation of practices like threat modeling. In addition to prompts, knowledge sources made available through retrieval-augmented generation provide contextually relevant information from organizational guidelines or industry-specific knowledge bases. This approach gives team members access to the knowledge and resources they need just in time.

Chatbots backed by large language models (LLMs) are gaining a lot of popularity right now, and we’re seeing emerging techniques around productionizing and productizing them. One such productization challenge is understanding how users are conversing with a chatbot that is driven by something as generic as an LLM, where the conversation can go in many directions. Understanding the reality of conversation flows is crucial to improving the product and improving conversion rates. One technique to tackle this problem is to use graph analysis for LLM-backed chats. The agents that support a chat with a specific desired outcome — such as a shopping action or a successful resolution of a customer's problem — can usually be represented as a desired state machine. By loading all conversations into a graph, you can analyze actual patterns and look for discrepancies to the expected state machine. This helps find bugs and opportunities for product improvement.

LLM-backed ChatOps is an emerging application of large language models through a chat platform (primarily Slack) that allows engineers to build, deploy and operate software via natural language. This has the potential to streamline engineering workflows by enhancing the discoverability and user-friendliness of platform services. At the time of writing, two early examples are PromptOps and Kubiya. However, considering the finesse needed for production environments, organizations should thoroughly evaluate these tools before allowing them anywhere near production.

LLM-powered autonomous agents are evolving beyond single agents and static multi-agent systems with the emergence of frameworks like Autogen and CrewAI. These frameworks allow users to define agents with specific roles, assign tasks and enable agents to collaborate on completing those tasks through delegation or conversation. Similar to single-agent systems that emerged earlier, such as AutoGPT, individual agents can break down tasks, utilize preconfigured tools and request human input. Although still in the early stages of development, this area is developing rapidly and holds exciting potential for exploration.

Generative AI (GenAI) and large language models (LLMs) can help developers both write and understand code. In practical application, this is so far mostly limited to smaller code snippets, but more products and technology developments are emerging for using GenAI to understand legacy codebases. This is particularly useful in the case of legacy codebases that aren’t well-documented or where the documentation is outdated or misleading. For example, Driver AI or bloop use RAG approaches that combine language intelligence and code search with LLMs to help users find their way around a codebase. Emerging models with larger and larger context windows will also help to make these techniques more viable for sizable codebases. Another promising application of GenAI for legacy code is in the space of mainframe modernization, where bottlenecks often form around reverse engineers who need to understand the existing codebase and turn that understanding into requirements for the modernization project. Using GenAI to assist those reverse engineers can help them get their work done faster.

Zoom recently open-sourced its Vulnerability Impact Scoring System, or VISS. This system is mainly focused on vulnerability scoring that prioritizes actual demonstrated security measures. VISS differs from the Common Vulnerability Scoring System (CVSS) by not focusing on worst-case scenarios and attempting to more objectively measure the impact of vulnerabilities from a defender's perspective. To this aim, VISS provides a web-based UI to calculate the vulnerability score based on several parameters — categorized into platform, infrastructure and data groups — including the impact on the platform, the number of tenants impacted, data impact and more. Although we don't have too much practical experience with this specific tool yet, we think this kind of priority-tailored assessment approach based on industry and context is worth practicing.

While we applaud a focus on automated testing, we continue to see numerous organizations over-invested in what we believe to be ineffective broad integration tests. As the term "integration test" is ambiguous, we've taken the broad classification from Martin Fowler's bliki entry on the subject which indicates a test that requires live versions of all run-time dependencies. Such a test is obviously expensive, because it requires a full-featured test environment with all the necessary infrastructure, data and services. Managing the right versions of all those dependencies requires significant coordination overhead, which tends to slow down release cycles. Finally, the tests themselves are often fragile and unhelpful. For example, it takes effort to determine if a test failed because of the new code, mismatched version dependencies or the environment, and the error message rarely helps pinpoint the source of the error. Those criticisms don't mean that we take issue with automated "black box" integration testing in general, but we find a more helpful approach is one that balances the need for confidence with release frequency. This can be done in two stages by first validating the behavior of the system under test assuming a certain set of responses from run-time dependencies, and then validating those assumptions. The first stage uses service virtualization to create test doubles of run-time dependencies and validates the behavior of the system under test. This simplifies test data management concerns and allows for deterministic tests. The second stage uses contract tests to validate those environmental assumptions with real dependencies.

In the rush to leverage the latest in AI, many organizations are quickly adopting large language models (LLMs) for a variety of applications, from content generation to complex decision-making processes. The allure of LLMs is undeniable; they offer a seemingly effortless solution to complex problems, and developers can often create such a solution quickly and without needing years of deep machine learning experience. It can be tempting to roll out an LLM-based solution as soon as it’s more or less working and then move on. Although these LLM-based proofs of value are useful, we advise teams to look carefully at what the technology is being used for and to consider whether an LLM is actually the right end-stage solution. Many problems that an LLM can solve — such as sentiment analysis or content classification — can be solved more cheaply and easily using traditional natural language processing (NLP). Analyzing what the LLM is doing and then analyzing other potential solutions not only mitigates the risks associated with overenthusiastic LLM use but also promotes a more nuanced understanding and application of AI technologies.

As organizations are looking for ways to make large language models (LLMs) work in the context of their product, domain or organizational knowledge, we're seeing a rush to fine-tune LLMs. While fine-tuning an LLM can be a powerful tool to gain more task-specificity for a use case, in many cases it’s not needed. One of the most common cases of a misguided rush to fine-tuning is about making an LLM-backed application aware of specific knowledge and facts or an organization's codebases. In the vast majority of these cases, using a form of retrieval-augmented generation (RAG) offers a better solution and a better cost-benefit ratio. Fine-tuning requires considerable computational resources and expertise and introduces even more challenges around sensitive and proprietary data than RAG. There is also a risk of underfitting, when you don't have enough data available for fine-tuning, or, less frequently, overfitting, when you have too much data and are therefore not hitting the right balance of task specificity that you need. Look closely at these trade-offs and consider the alternatives before you rush to fine-tune an LLM for your use case.

With the adoption of frameworks like Next.js and htmx, we’re seeing more usage of server-side rendering (SSR). As a browser technology, it's not trivial to use web components on the server. Frameworks have sprung up to make this easier, sometimes even using a browser engine, but the complexity is still there. Our developers find themselves needing workarounds and extra effort to order front-end components and server-side components. Worse than the developer experience is the user experience: page load performance is impacted when custom web components have to be loaded and hydrated in the browser, and even with pre-rendering and careful tweaking of the component, a "flash of unstyled content" or some layout shifting is all but unavoidable. As mentioned in the previous Radar, one of our teams had to move their design system away from the web components-based Stencil because of these issues. Recently, we received reports from another team that they ended up replacing server-side–generated components with browser-side components because of the development complexity. We caution against the use of web components for SSR web apps, even if supported by frameworks.