AI-agent para verificación de especificaciones técnicas: desarrollo, arquitectura, práctica

Creando un agente de IA para auditorías de especificaciones técnicas: Lecciones prácticas

Desarrollar una herramienta de machine learning para revisiones automáticas de especificaciones técnicas (specs) requiere una estrategia clara y conocimiento de los errores comunes. Nuestro experimento práctico demostró que el éxito depende de datos de entrenamiento de alta calidad y una arquitectura híbrida que combina modelos de lenguaje grandes (LLM) con algoritmos tradicionales.

Construyendo el conjunto de datos de entrenamiento

El primer paso, y el más crítico, fue recopilar y etiquetar los datos. Creamos un conjunto representativo de 90 especificaciones técnicas, dividido en tres categorías:

• Especificaciones de alta calidad (30 ejemplos) que avanzaron en el desarrollo con cambios mínimos.
• Especificaciones problemáticas (30 ejemplos) que generaron conflictos, retrabajos y retrasos en los plazos.
• Especificaciones promedio (30 ejemplos) que funcionaron, pero con fallos descubiertos durante el desarrollo.

Cada especificación incluía una revisión detallada del analista que destacaba fortalezas y debilidades. Para aumentar la diversidad, incorporamos specs de diversos autores y proyectos en sectores como retail, manufactura y servicios.

Clasificando errores comunes en especificaciones

Al analizar las especificaciones problemáticas, identificamos issues sistémicos que nuestro agente debía detectar. Categorías clave:

• Solo escenarios positivos. El requisito describe el camino feliz, pero omite manejo de errores, casos límite y excepciones.
• Redacción vaga. Términos subjetivos o difusos como "rápido", "amigable para el usuario" o "flexible" sin métricas medibles.
• Requisitos no testeables. Sin forma clara de crear un caso de prueba definitivo para verificación.
• Conflictos internos. Inconsistencias entre secciones o cláusulas dentro de la misma spec.
• Casos límite ausentes. Sin indicaciones sobre el comportamiento del sistema con entradas extremas o inusuales.

Ejemplos de convertir requisitos no testeables en testeables

Declaraciones vagas típicas y cómo hacerlas concretas:

• Original: "Los usuarios deben personalizar informes de forma flexible."

Concreto: "Los informes ofrecen configuraciones personalizables: rango de fechas (cualquier intervalo), contraparte (selección múltiple). Las configuraciones se guardan por usuario. Incluir opciones de agrupación por contraparte y almacén."

• Original: "El sistema debe manejar grandes volúmenes de datos correctamente."

Concreto: "Cargar 10.000 documentos con un total de 500.000 filas debe completarse en menos de 15 minutos. Uso de memoria limitado a 2 GB."

• Original: "Todos los formularios de pantalla deben seguir un estilo consistente."

Concreto: "En todos los formularios de documentos, los botones 'Guardar' y 'Publicar' están en la esquina superior derecha. Color del botón: verde (R=0, G=128, B=0). Fuente: Arial, 10pt."

Criterios de calidad y arquitectura del agente

Definimos una lista de verificación para evaluar specs, cubriendo objetivos de negocio, completitud de escenarios, claridad, testabilidad, consistencia y viabilidad. Estos formaron la base de los prompts y la lógica del agente.

La solución usa un modelo híbrido que combina Generación Aumentada por Recuperación (RAG) con clasificación por árboles de decisión.

• Componente RAG maneja la búsqueda contextual. Al revisar un nuevo requisito, el agente extrae fragmentos semánticamente similares de la base de conocimiento (90 specs etiquetadas), recordando errores comunes y sus contextos.
• Árboles de decisión categorizan errores usando características estructuradas. El agente LLM primero parsea el texto crudo en características estructuradas (p. ej., JSON), que alimentan al clasificador.

Implementación técnica del análisis

Verificar un requisito sigue estos pasos:

• Extracción de características: Un analizador basado en LLM convierte el texto en un vector de características. Por ejemplo:

* has_numbers: 1 (incluye especificaciones numéricas) o 0.

* has_negative_keywords: 1 (menciona "si", "sino", "error") o 0.

* boundary_conditions_mentioned: 1 (cubre casos límite) o 0.

* stopword_score: peso de marcadores subjetivos ("flexible", "intuitivo").

• Clasificación: El vector de características estructurado va a un modelo de árbol de decisión (p. ej., de Scikit-learn), asignándolo a una categoría de error o marcándolo como sólido.
• Generación de informe: El agente produce un comentario detallado que señala el tipo de problema, su ubicación en el texto y recomendaciones de corrección basadas en analogías de la base de conocimiento.

Esta división — LLM para comprensión semántica y extracción de datos, clasificador para lógica rígida — garantiza transparencia y control.

Lecciones clave

• La calidad de los datos lo es todo. Sin un conjunto representativo y bien etiquetado (al menos docenas de ejemplos), el entrenamiento efectivo es imposible.
• Híbrido supera al LLM puro. Combinar RAG para contexto con árboles de decisión para clasificación precisa da resultados más confiables y explicables.
• Prioriza la testabilidad. Una gran spec permite casos de prueba inequívocos. Todos los requisitos deben ser medibles y específicos.
• Automatiza lo tedioso. El agente no reemplaza a los analistas, sino que actúa como un nuevo par de ojos, detectando sistemáticamente errores comunes para ahorrar tiempo y reducir errores humanos.
• Sigue aprendiendo. Actualiza regularmente la base de conocimiento con nuevas specs y revisiones para mejorar la precisión y adaptarse a tipos de proyectos nuevos.

— Editorial Team