Conversa con tus requisitos Mi viaje aplicando IA generativa (LLM) a los requerimientos de software
Conversa con tus requisitos de software aplicando IA generativa a Mi Viaje (LLM)
En la era digital, las grandes empresas se ven afectadas por la falta de comprensión de sus sistemas y procesos heredados. El conocimiento se aísla en silos, disperso entre varios equipos y expertos en la materia. Esta fragmentación contribuye significativamente al crecimiento de la deuda técnica, un asesino silencioso que gradualmente obstaculiza la agilidad y productividad de la organización. En Curiosity Software, hemos pasado los últimos cinco años creando requisitos estructurados (a través de modelos visuales) y conectándonos a cientos de herramientas de DevOps. Creemos que esto nos coloca en una posición increíblemente ventajosa al implementar la Inteligencia Artificial Generativa. Los modelos y artefactos de DevOps pueden actuar como el centro central de acceso a los datos que fluyen a través del panorama de desarrollo de software de una organización.
Como parte de nuestra misión de combatir los desafíos prevalentes de la deuda técnica y la falta de conocimiento, nos embarcamos en un viaje para aplicar Modelos de Lenguaje Grande (LLM) a los requisitos de software y la lógica empresarial. Nuestro objetivo era crear un centro de conocimiento para los requisitos de software de una organización, que se pueda consultar para descubrir conocimiento y pagar la deuda técnica.
Comprendiendo el Terreno de los Modelos de Lenguaje Grande (LLMs)
Antes de discutir nuestras experiencias y conocimientos, pongamos en contexto proporcionando una breve descripción de los Modelos de Lenguaje Grande. Los LLMs, como el GPT-4 de OpenAI, son capaces de comprender y generar lenguaje humano. Aprenden de un vasto corpus de datos, que abarca una amplia gama de temas y estilos de lenguaje.
Estos LLMs trabajan en un modelo de aprendizaje profundo conocido como Transformer, que utiliza capas de mecanismos de autoatención (redes neuronales) para analizar y comprender el contexto dentro de los datos. Durante el entrenamiento, leen innumerables frases y párrafos y hacen predicciones sobre lo que sigue en una oración. Estas predicciones se basan en lo que han leído hasta ahora:
Lo sorprendente de un LLM es su capacidad para generar texto similar al humano. Esto se logra cuando se entrena con un gran corpus de datos y tiene un alto número de parámetros o pesos en el modelo (GPT-4 tiene cientos de miles de millones):
- Ajuste de hiperparámetros mediante entrenamiento basado en la pobla...
- Cómo Carrier predice fallas en HVAC utilizando AWS Glue y Amazon Sa...
- Crea una solución de moderación de contenido basada en IA generativ...
Esta increíble capacidad de responder como un humano se debe no solo a la inteligencia inherente en el algoritmo, sino también al descubrimiento de que el lenguaje humano puede no ser tan intrincado como creíamos inicialmente.
Al exponer una red neuronal a suficientes instancias de lenguaje humano, un LLM puede discernir patrones y responder adecuadamente a las consultas. A medida que aumenta el tamaño y la calidad de los datos en los que se entrena un LLM, su poder crece exponencialmente.
Datos Estructurados Son Esenciales para el Éxito de los LLMs
Para las organizaciones de software en la actualidad, la capacidad de aprovechar los LLMs nunca ha estado tan cerca. Hay modelos especializados increíblemente compactos que pueden ejecutarse en una PC local y que se equiparan al nivel de rendimiento de GPT-3.5.
Sin embargo, la parte más importante de un LLM no es la disponibilidad de herramientas; es los datos en los que se ha entrenado un LLM. Por lo tanto, este también es el principal obstáculo para el uso exitoso de los LLMs, ya que las organizaciones en la actualidad carecen de datos estructurados en el dominio del software.
Los requisitos de software generalmente se almacenan en un formato textual no estructurado y, lo que es peor, a menudo son incompletos, ambiguos y carecen de información. Lo mismo ocurre con los casos de prueba, que a menudo se almacenan como listas de pasos de prueba basados en texto.
Superar este problema de datos estructurados requiere innovación y consideración cuidadosa. Se pueden emplear técnicas como la extracción de información, la comprensión del lenguaje natural y el aprendizaje automático para transformar datos no estructurados en datos estructurados. Este proceso a menudo implica la intervención manual de humanos.
Una solución alternativa para entrenar un LLM no es intentar entrenarlo con datos textuales no estructurados. Su objetivo es crear requisitos estructurados desde el principio o convertir datos no estructurados en requisitos estructurados como intermediario.
Aquí es donde los requisitos modelados pueden potenciar la creación de requisitos listos para la IA para entrenar modelos de lenguaje. Podemos utilizar modelos para estructurar y mejorar los datos existentes, integrando los artefactos existentes de SDLC con modelos en un centro de conocimiento central.
¿Qué es el Modelado para los Requisitos de Software?
La prueba basada en modelos utiliza un modelo de la característica en consideración para generar casos de prueba. Estos modelos suelen representarse como diagramas de flujo visuales, que definen claramente los requisitos de software al representar el comportamiento, funciones u operaciones del sistema.
Al usar estos modelos, se puede reducir la ambigüedad, lo que facilita tanto a los desarrolladores como a los testers la comprensión de los requisitos. Además, el modelado facilita la generación automática de casos de prueba, datos y automatización. Cualquier cambio en los requisitos de software puede reflejarse mediante la modificación de los modelos, lo que lleva a activos de prueba dinámicos y actualizados.
Los diagramas de flujo ofrecen un método visual para presentar procesos complejos de manera simple y comprensible. Muestran cada paso como una caja o símbolo, con flechas entre ellos que muestran el flujo de usuarios y datos a través del proceso. Esto brinda una representación clara y fácil de seguir del proceso, resaltando la secuencia de operaciones y los puntos de toma de decisiones:
Típicamente, una organización que aprovecha las pruebas basadas en modelos creará una biblioteca de modelos reutilizables, que luego se pueden conectar para construir escenarios mucho más completos de principio a fin a gran velocidad. El proceso de componentización permite que el equipo avance mucho más rápido en la creación de sus activos de prueba, pero también reaccione al cambio de manera más eficiente:
Los diagramas de flujo están estructurados para LLMs
Los diagramas de flujo son inherentemente estructurados por naturaleza. Cuando se trata de entrenar Modelos de Lenguaje Grande, los datos estructurados en forma de diagramas de flujo pueden producir resultados extremadamente potentes.
Además, los diagramas de flujo son ideales para la consulta porque son intuitivos y simples de interpretar. El flujo de control y el proceso de toma de decisiones se representan claramente, lo que facilita al modelo predecir los siguientes pasos en el proceso.
La capacidad de inferir relaciones entre los diferentes pasos hace que los diagramas de flujo sean particularmente valiosos tanto para la consulta como para el entrenamiento de LLMs. Aquí hay un ejemplo de cómo utilizar un LLM para consultar un modelo simple. El siguiente modelo representa un proceso de solicitud de una cuenta de estudiante:
Prompt: ¿Qué edad debe tener un estudiante para ser aprobado para una cuenta de estudiante?
Response: 18 años o más.
Prompt: ¿Cómo puede un estudiante ser aprobado para una cuenta de estudiante?
Response: Para ser aprobado para una cuenta de estudiante, un estudiante primero debe ingresar sus datos personales. A esto le seguiría la verificación de su edad para asegurarse de que tenga 18 años o más. Una vez confirmada su edad, el estudiante debe ingresar un comprobante de inscripción para demostrar su condición de estudiante. Si se cumplen todos estos criterios y la solicitud es exitosa, el estudiante será aprobado para una cuenta de estudiante.
Conversando con los Requisitos de Software
Dada la capacidad comprobada de los LLMs para consultar y razonar sobre diagramas de flujo (modelos) y la variedad de conectores que Curiosity ha integrado en herramientas de DevOps, buscamos aplicar LLMs a diagramas de flujo y artefactos de DevOps. Buscamos combinar modelos con datos de diversos artefactos de DevOps, creando un centro de conocimiento central para LLMs.
Hemos aplicado y entrenado LLMs en una variedad de requisitos de software (capturados de JIRA) y modelos almacenados en el espacio de trabajo de Test Modeller de una organización. Para este proyecto, tenemos un proyecto de JIRA con una serie de tareas para una aplicación bancaria, junto con modelos que se han creado para problemas basados en texto. Estos modelos agregan estructura adicional y completan los requisitos, creando los datos necesarios para un LLM:
Aquí hay un ejemplo de ticket:
Si comparas la historia de usuario de “pared de texto” anterior con el requisito visual a continuación, verás cuánto más fácil es comprender la lógica de solicitar una tarjeta de crédito con el diagrama de flujo. Esto se debe a la estructura inherente y la naturaleza visual de un diagrama de flujo.
La colección de diagramas de flujo y tickets de Jira sincronizados en el espacio de trabajo de Test Modeller proporciona un centro de conocimiento para el LLM. Cuando se consulta, el LLM puede aprovechar y razonar sobre la información almacenada en artefactos de SDLC dispersos, como datos almacenados en múltiples tickets de Jira.
Veamos algunos ejemplos de consulta a este centro de conocimiento utilizando un LLM entrenado en los requisitos y modelos de software bancario de ejemplo.
Ejemplo 1: Pregunta simple
Comencemos primero con una pregunta simple en la que esperaríamos que funcione bien. Dime los detalles de un ticket de JIRA, dado su identificador.
Prompt: ¿Cuál es el ticket de JIRA CB-13?
Veremos si esto devuelve un resumen del ticket:
Ejemplo 2: Razonamiento implícito con un modelo
En este ejemplo, iremos un poco más profundo y haremos una pregunta que espera que el LLM comprenda un diagrama de flujo y luego deduzca una respuesta a partir de él. Específicamente sobre el proceso de solicitud de una tarjeta de crédito.
Prompt: ¿Qué puntaje de crédito se requiere para completar una solicitud de tarjeta de crédito?
El LLM ha capturado el diagrama de flujo para el proceso de solicitud de una tarjeta de crédito e interpretado el modelo. Luego ha utilizado esta interpretación para calcular que se requiere un puntaje de crédito de 700 o más.
Ejemplo 3: Razonamiento implícito con modelos y requisitos
Esta indicación requiere que el LLM interrumpa múltiples fuentes de información para responder a la pregunta. Busca un modelo y también el requisito correspondiente.
Indicación: ¿Cuándo puede un cliente solicitar una tarjeta de crédito?
Ejemplo 4: Razonamiento de Múltiples Requisitos
Esta indicación requiere que se comprendan y razonen múltiples requisitos para responder a una consulta de requisitos cruzados. Veremos en la respuesta que se hacen referencia a tres historias de usuario para responder que los productos solo están disponibles si una persona tiene un buen puntaje de crédito.
Indicación: ¿Qué productos puedo solicitar si tengo buen crédito?
Demostración: Uso de LLMs para Consultar Datos de Diagramas de Flujo Estructurados
Mírame sincronizar información de las historias de usuario de Jira en un centro de conocimiento central y ejecutar las consultas utilizadas al escribir este artículo:
Adoptar LLMs para una Mejor Entrega de Software
Curiosity Software está aprovechando los Modelos de Lenguaje Grande (LLMs) como el GPT-4 de OpenAI para comprender y gestionar mejor los requisitos de software y la lógica empresarial, con un enfoque particular en combatir la deuda técnica.
Dado que los LLMs se basan en datos estructurados, las pruebas basadas en modelos son la herramienta perfecta para completar y eliminar la ambigüedad en los datos no estructurados. Los modelos proporcionan una fuente de flujos de negocios estructurados, utilizando diagramas de flujo visuales para representar los requisitos de software, que a su vez brindan claridad. Al mismo tiempo, podemos sincronizar la información de las herramientas y artefactos de DevOps en un centro de conocimiento central.
Este enfoque también permite la generación automática de casos de prueba, datos y automatización. Utilizando estos métodos, Curiosity Software está trabajando activamente en entrenar LLMs en un amplio espectro de requisitos de software capturados de varias herramientas de DevOps, que se modelan en el espacio de trabajo de Test Modeller de una organización. Esto crea un copiloto y paneles de control que brindan explicaciones de todo el ciclo de vida del desarrollo de software cuando se consulta, al tiempo que informan decisiones en torno al riesgo, las versiones, la cobertura de pruebas, el cumplimiento y más:
Incluso podemos generar modelos utilizando la IA generativa, como se describe en mi último artículo. Esto cierra el ciclo de retroalimentación. Un humano puede trabajar con una IA generativa para crear y mejorar iterativamente modelos basados en datos en diagramas de flujo y artefactos más amplios del ciclo de vida del desarrollo de software. Los flujos, a su vez, proporcionan especificaciones precisas para los desarrolladores al generar pruebas para verificar el código que crean.
Los datos resultantes de este diseño de software asistido por IA, las pruebas y el desarrollo se alimentan en nuestro centro de conocimiento central. Esto actualiza el LLM, informa las iteraciones futuras y evita la deuda técnica.
Esta aplicación de IA a los requisitos de software puede ayudar a mejorar la eficiencia y efectividad de los procesos de desarrollo de software, actuar como un centro de conocimiento para los procesos empresariales de una organización y, finalmente, combatir la deuda técnica.
