Habr AI explica cómo preparar una entrada estructurada para un agente de IA en lugar de un pliego de requisitos en bruto

Habr AI ha publicado un análisis detallado sobre qué datos conviene darle a un agente de IA cuando su tarea es revisar requisitos técnicos y no simplemente resumirlos. La idea central: en lugar de la especificación completa, el agente recibe un conjunto de requisitos atómicos en forma de pasaportes JSON.

Por qué no basta con la especificación

La autora del artículo parte de un problema que conoce casi cualquiera que haya intentado pasarle a una red neuronal un documento grande de una sola vez. Cuando el modelo recibe una especificación de muchas páginas sin preparación previa, pierde el foco, mezcla requisitos de distintas secciones y hace observaciones demasiado genéricas. Al final, el sistema puede detectar algunas imprecisiones, pero le cuesta explicar qué punto concreto falla, por qué falla y cómo hay que corregirlo.

Por eso el documento se divide primero en requisitos individuales: una acción, una regla o una restricción por fragmento. Para no perder el contexto en esa división, cada elemento incorpora campos como `parent_section` y `parent_object`, y los puntos relacionados lógicamente se marcan como `linked`. Esto es importante cuando varios requisitos deben verificarse juntos: por ejemplo, si el sistema debe enviar una notificación tanto por correo como por Telegram, y no solo por uno de los dos canales.

El pasaporte del requisito

El siguiente paso consiste en convertir la redacción humana en un conjunto de rasgos con los que ya pueda trabajar un clasificador. En este esquema, el LLM no actúa como juez final ni intenta «entenderlo todo». Su papel es mucho más acotado: extrae del texto señales estructuradas y las vuelca en un JSON. Este enfoque da control: los rasgos se pueden verificar, comparar y, si hace falta, corregir mediante posprocesamiento. Como lo formula la autora,

«el agente no trabaja con texto, sino con estas estructuras».

El artículo describe seis rasgos básicos que sostienen este pasaporte. En lugar de una valoración abstracta de la calidad, el modelo busca señales concretas: números, palabras vagas, excepciones, límites y participantes explícitos del escenario. En la práctica, el pasaporte convierte una frase como «el usuario debe poder configurar el informe de forma flexible» en un conjunto claro de indicadores que muestra de inmediato qué le falta al requisito. Esa interpretabilidad es lo que distingue este esquema de pedirle sin más al modelo que evalúe el texto entero.

• `has_numbers` — si el requisito contiene números, límites, fechas u otros parámetros concretos
• `stopword_score` — cuánto se diluye la redacción por palabras como «flexible», «cómodo» o «rápido»
• `has_negative_keywords` — si se describen excepciones y errores
• `boundary_conditions_mentioned` — si se indican valores vacíos, máximos, mínimos u otros límites
• `actor_count` — cuántos participantes aparecen de forma explícita en el requisito

Los rasgos se extraen con JSON mode y ejemplos few-shot para que el modelo no se desvíe del formato. Si aun así el LLM pasa por alto algo evidente, como las cifras del texto, se completa con posprocesamiento mediante expresiones regulares. Después entra en juego un árbol de decisión: recibe los rasgos numéricos y asigna al requisito una etiqueta como `ok`, `unverifiable`, `no_negative`, `no_boundary` o `ambiguity`. Para el entrenamiento, la autora anotó 90 especificaciones, las dividió en 270 requisitos y obtuvo alrededor de un 82% de accuracy en el conjunto de prueba.

El crítico y la escala

El pipeline no termina ahí. Incluso un buen clasificador solo ve un requisito cada vez, así que es fácil que se le escapen contradicciones entre secciones. Para esos casos se usa un agente crítico independiente que recibe el texto completo de la especificación, la lista de pasaportes JSON y las etiquetas predichas. Su tarea no es volver a evaluar cada frase, sino mirar el documento desde arriba y buscar conflictos, huecos en los permisos de acceso y errores en el mapeo de integraciones. Este crítico puede detectar, por ejemplo, que en un sitio el campo «Almacén» es obligatorio y en otro se admite vacío.

Para que el esquema funcione más allá de ejemplos cortos, los requisitos se procesan en paralelo con `ThreadPoolExecutor` y los modelos locales se ejecutan en Ollama. La autora explica que, en un PC gaming normal, el sistema soporta sin problemas entre 4–6 solicitudes paralelas sin una degradación apreciable, y que con un lote de un centenar de requisitos eso supone una aceleración de aproximadamente 3–4 veces. Los requisitos relacionados se mantienen en el mismo hilo para no romper el orden ni el contexto común de la revisión.

Qué significa esto

El análisis de Habr AI muestra bien hacia dónde va el desarrollo práctico de agentes de IA: de intentar «darle al modelo todo de golpe» a pipelines acotados y controlables, con rasgos explícitos, modelos locales y un nivel de arbitraje independiente. Si un equipo quiere construir un agente aplicado para analítica, QA o trabajo con documentación, tendrá que pensar no solo en qué modelo elegir, sino también en cómo se estructuran los datos de entrada, la anotación y la verificación final del resultado.