Habr AI mostró cómo preparar una entrada estructurada para un agente de AI en lugar de una especificación técnica en bruto

Habr AI publicó un análisis detallado sobre qué exactamente debe alimentarse a un agente de IA cuando la tarea es verificar requisitos técnicos en lugar de simplemente parafrasearlos. La idea principal: en lugar de que el agente reciba un documento de especificación completo, recibe un conjunto de requisitos atómicos en forma de pasaportes JSON.

Por qué una sola especificación no es suficiente

El autor del artículo comienza con un problema familiar para casi todos los que han intentado proporcionar un documento grande a una red neuronal por completo. Cuando un modelo recibe una especificación de varias páginas sin preparación previa, pierde el enfoque, mezcla requisitos de diferentes secciones y proporciona observaciones demasiado generales. Como resultado, el sistema puede notar imprecisiones individuales, pero le cuesta explicar qué punto específico es problemático, por qué lo es y qué se debe corregir.

Por eso, el documento se divide primero en requisitos separados: una acción, una regla o una restricción por fragmento. Para no perder contexto durante esa fragmentación, cada elemento se aumenta con campos como `parent_section` y `parent_object`, y los puntos lógicamente relacionados se marcan como `linked`. Esto importa cuando varios requisitos deben verificarse juntos: por ejemplo, cuando el sistema debe enviar una notificación tanto por correo electrónico como por Telegram, no solo a través de un canal.

Pasaporte de requisito

El siguiente paso es convertir el lenguaje humano en un conjunto de características con las que un clasificador pueda trabajar. En este esquema, el LLM no actúa como juez final y no intenta "entenderlo todo." Su papel es mucho más estrecho: extrae señales estructuradas del texto y las recoge en JSON. Este enfoque proporciona control: las características se pueden verificar, comparar y corregir en el postprocesamiento si es necesario. Como formula el autor:

"el agente trabaja no con texto, sino con tales estructuras."

El artículo describe seis características básicas que sustentan este pasaporte. En lugar de una evaluación de calidad abstracta, el modelo busca señales específicas: números, palabras vagas, excepciones, límites y participantes explícitos del escenario. En la práctica, tal pasaporte transforma una frase como "el usuario debe configurar el informe de manera flexible" en un conjunto comprensible de banderas que muestra inmediatamente qué le falta al requisito. Esta interpretabilidad es precisamente lo que distingue el esquema de simplemente pedirle a un modelo que evalúe el texto en su totalidad.

• `has_numbers` — si el requisito contiene números, límites, fechas y otros parámetros específicos
• `stopword_score` — cuán vaga es la formulación debido a palabras como "flexible," "cómodo" o "rápido"
• `has_negative_keywords` — si se describen excepciones y errores
• `boundary_conditions_mentioned` — si se especifican valores vacíos, máximos, mínimos u otros límites
• `actor_count` — cuántos participantes se mencionan explícitamente en el requisito

Las características mismas se extraen a través del modo JSON y ejemplos few-shot para mantener el modelo dentro del formato. Si el LLM aún pierde algo obvio, como números en el texto, esto se refuerza en el postprocesamiento mediante expresiones regulares. A continuación viene un árbol de decisión: recibe características numéricas y asigna al requisito una etiqueta como `ok`, `unverifiable`, `no_negative`, `no_boundary` o `ambiguity`. Para el entrenamiento, el autor etiquetó 90 especificaciones, las dividió en 270 requisitos y logró aproximadamente 82% de precisión en el conjunto de pruebas.

Crítico y escala

El pipeline no termina ahí. Incluso un clasificador bueno ve solo un requisito a la vez, lo que significa que puede fácilmente perder contradicciones entre secciones. Para tales casos, se utiliza un agente crítico separado, que recibe el texto completo de la especificación, la lista de pasaportes JSON y las etiquetas predichas.

Su tarea no es reevaluar cada frase desde cero, sino ver el documento desde arriba y buscar conflictos, brechas en los derechos de acceso y errores en el mapeo de integraciones. Tal crítico podría, por ejemplo, notar que en un lugar el campo "Almacén" es obligatorio, mientras que en otro se permite un valor vacío. Para que el esquema funcione no solo en ejemplos cortos, los requisitos se procesan en paralelo a través de `ThreadPoolExecutor`, y los modelos locales se ejecutan en Ollama.

El autor señala que en una PC de juegos típica, el sistema maneja cómodamente 4–6 solicitudes paralelas sin degradación notable, y en un lote de cien requisitos, esto proporciona una aceleración de aproximadamente 3–4 veces. Los requisitos relacionados permanecen en un único thread para mantener el orden y el contexto general de verificación.

Qué significa

El análisis en Habr AI muestra claramente hacia dónde se dirige el desarrollo práctico de agentes de IA: de intentos de "alimentar el modelo con todo a la vez" a pipelines estrechos y controlados con características explícitas, modelos locales y una capa separada de arbitraje. Si un equipo quiere construir un agente práctico para análisis, QA o trabajo con documentación, tendrá que pensar no solo en elegir un modelo, sino también en cómo se estructuran los datos de entrada, el etiquetado y la verificación final del resultado.