Habr AI a montré comment préparer une entrée structurée pour un agent AI plutôt qu’un cahier des charges brut

На Habr AI вышел подробный разбор того, что именно нужно подавать AI-агенту на вход, если задача — проверять технические требования, а не просто пересказывать их. Главная идея: вместо целого ТЗ агент получает набор атомарных требований в виде JSON-паспортов.

Почему одного ТЗ мало

Автор статьи начинает с проблемы, знакомой почти всем, кто пытался отдавать нейросети большой документ целиком. Когда модель получает многостраничное ТЗ без предварительной подготовки, она теряет фокус, смешивает требования из разных разделов и даёт слишком общие замечания. В итоге система может заметить отдельные неточности, но ей трудно объяснить, какой именно пункт плох, почему он плох и что с ним нужно исправить.

Поэтому документ сначала режется на отдельные требования: одно действие, одно правило или одно ограничение на каждый фрагмент. Чтобы при таком дроблении не потерять контекст, к каждому элементу добавляются поля вроде `parent_section` и `parent_object`, а логически связанные пункты помечаются как `linked`. Это важно, если несколько требований должны проверяться вместе: например, когда система обязана отправлять уведомление и на почту, и в Telegram, а не только в один канал из двух.

Паспорт требования

Следующий шаг — превратить человеческую формулировку в набор признаков, с которыми уже может работать классификатор. В этой схеме LLM не выступает финальным судьёй и не пытается «понять всё». Её роль намного уже: она вытаскивает из текста структурированные сигналы и складывает их в JSON.

Такой подход даёт контроль: признаки можно проверить, сравнить и при необходимости поправить постобработкой. Как формулирует автор, > «агент работает не с текстом, а с такими структурами». В статье описаны шесть базовых признаков, на которых держится этот паспорт.

Вместо абстрактной оценки качества модель ищет конкретные сигналы: числа, размытые слова, исключения, границы и явных участников сценария. На практике такой паспорт превращает фразу вроде «пользователь должен гибко настраивать отчёт» в понятный набор флажков, по которым сразу видно, чего именно не хватает требованию. Именно эта интерпретируемость отличает схему от попытки просто попросить модель оценить текст целиком.

`has_numbers` — есть ли в требовании числа, лимиты, даты и другие конкретные параметры `stopword_score` — насколько формулировка размыта из-за слов вроде «гибко», «удобно» или «быстро» `has_negative_keywords` — описаны ли исключения и ошибки `boundary_conditions_mentioned` — указаны ли пустые значения, максимумы, минимумы или другие границы * `actor_count` — сколько участников явно фигурирует в требовании Сами признаки извлекаются через JSON mode и few-shot примеры, чтобы модель не расползалась по формату. Если LLM всё же пропускает что-то очевидное, например цифры в тексте, это добивается постобработкой через регулярные выражения. Дальше вступает в дело дерево решений: оно получает числовые признаки и присваивает требованию метку вроде `ok`, `unverifiable`, `no_negative`, `no_boundary` или `ambiguity`.

Для обучения автор разметила 90 ТЗ, разбила их на 270 требований и получила около 82% accuracy на тестовой выборке.

Критик и масштаб На этом пайплайн не заканчивается.

Даже хороший классификатор видит только одно требование за раз, а значит легко пропускает противоречия между разделами. Для таких случаев используется отдельный агент-критик, который получает весь текст ТЗ, список JSON-паспортов и предсказанные метки. Его задача — не переоценивать каждую фразу заново, а смотреть на документ сверху и искать конфликты, пробелы в правах доступа и ошибки в маппинге интеграций.

Такой критик, например, может заметить, что в одном месте поле «Склад» обязательно, а в другом допускается пустое значение. Чтобы схема работала не только на коротких примерах, требования обрабатываются параллельно через `ThreadPoolExecutor`, а локальные модели запускаются в Ollama. Автор пишет, что на обычном игровом ПК система спокойно выдерживает 4–6 параллельных запросов без заметной деградации, а на пакете из сотни требований это даёт ускорение примерно в 3–4 раза.

Связанные требования при этом остаются в одном потоке, чтобы не ломать порядок и общий контекст проверки.

Что это значит

Разбор на Habr AI хорошо показывает, куда движется практическая разработка AI-агентов: от попыток «скормить модели всё сразу» к узким, контролируемым пайплайнам с явными признаками, локальными моделями и отдельным уровнем арбитража. Если команда хочет строить прикладного агента для аналитики, QA или работы с документацией, ей придётся думать не только о выборе модели, но и о том, как устроены входные данные, разметка и финальная проверка результата.