Делегирование комплексных операционных процессов нейросетям — обработка договоров, аудит веб-форм или сведение аналитики — регулярно упирается в барьер разовых промптов. Обычный запрос перекладывает контроль качества на человека: модель генерирует правдоподобный черновик с пропусками, а специалист вынужден построчно вычитывать результат.
Режим Human-in-the-Loop («человек в контуре») сохраняет зависимость от человеческого фактора, утомляет команду и снижает эффект автоматизации. Альтернативой выступает архитектура Loop (замкнутый автономный цикл): агент берет на себя функции контроля качества, сверяет собранный массив со спецификацией, ведет журнал дефектов и повторяет проходы до устранения расхождений.
Анатомия архитектуры Loop: почему разовый промпт ломается на комплексных задачах
Главное отличие циклической постановки от классического промптинга — разделение роли исполнителя и контролера. Разовый запрос вида «собери сводку по контрактам» формулирует действие, но не задает критерии завершенности. В итоге модель опирается на статистическую вероятность токенов и прекращает генерацию в произвольный момент.
В архитектуре Loop процесс строится по инженерному паттерну Evaluator–Optimizer (генератор и оценщик), описанному в исследованиях Anthropic и OpenAI: один модуль создает черновик, а второй оценивает его по спецификации и формирует список замечаний для следующего прохода. Схема включает пять элементов:
- Массив входных данных: изолированная папка с исходными файлами и реестром документов.
- Целевая схема артефакта: структурированный файл вывода с фиксированными колонками (
summary.csv). - Файл спецификации (
задание.md): перечень правил приемки, стандартов форматирования и допустимых значений. - Журнал проходов (
журнал.md): динамический лог, куда агент записывает число оставшихся дефектов и правки. - Реестр исключений (
exceptions.md): список спорных или нечитаемых позиций для внимания человека.
Подготовка данных и экономика токенов: почему Markdown эффективнее офисных форматов
Исходные файлы DOCX, XLSX или тяжелые PDF содержат служебную разметку и стили. При передаче таких файлов в контекст модель тратит лимит токенов на разбор технического шума, повышая стоимость вызовов API и риск потери связей.
Конвертация документов в чистый Markdown решает три задачи:
- Экономия контекста: модель оперирует смысловым текстом и таблицами, сохраняя место для инструкций.
- Однородность структуры: агент быстрее сопоставляет разнородные контракты единого стандарта.
- Точность извлечения: снижается риск пропуска пунктов из-за сложной верстки.
При подготовке данных важно составить реестр файлов: имя документа, идентификатор, тип и доступность. Проверка «обработано 30 договоров» имеет смысл только при подтверждении наличия 30 исходников. Значение «нет данных» подтверждает, что агент проверил нужный раздел и зафиксировал отсутствие информации, а не пропустил поле.
Практический сценарий: сквозной разбор 30 договоров с поставщиками
Рассмотрим операционную задачу: компании требуется структурировать архив из 30 контрактов с поставщиками, выделив суммы, сроки действия и условия пролонгации.
Шаг 1. Формирование структуры и спецификации
В рабочей директории создаются шаблон таблицы сводка.csv со столбцами document_id, counterparty, amount, currency, start_date, end_date, renewal_status, special_terms, evidence_location и файл задание.md.
В файле задание.md фиксируются критерии приемки:
- Таблица содержит ровно 30 строк без дублирования.
- Суммы нормализуются с разделением числового значения и валюты.
- Даты приводятся к формату YYYY-MM-DD; при относительном сроке («12 месяцев») агент вычисляет дату окончания.
- Поле пролонгации заполняется прямой цитатой с указанием пункта договора.
- Неясные условия переносятся в реестр исключений.
Шаг 2. Итеративный процесс выполнения
Агент запускает работу и фиксирует динамику в журнал.md:
- Проход 1 (Черновая сборка): Модель считывает файлы, заполняет 30 строк и запускает самопроверку. Результат: «заполнено 24 строки; в 4 договорах даты окончания не указаны прямо; в 2 контрактах суммы вынесены в приложения; 1 файл — скан без текста».
- Проход 2 (Целевая доработка): Агент обращается точечно к проблемным позициям: извлекает суммы из приложений, рассчитывает даты по срокам действия и отмечает скан маркером
требует проверки. - Проход 3 (Финальная сверка): Проверка фиксирует «не закрыто: 0». Обязательные поля заполнены, спорные пункты вынесены в
exceptions.md. Агент завершает цикл.
Сравнение подходов: Human-in-the-Loop против автономного цикла
| Параметр оценки | Ручной контроль (Human-in-the-Loop) | Автономный цикл (Autonomous Loop) |
|---|---|---|
| Роль человека | Построчная проверка черновиков | Формулирование критериев и разбор исключений |
| Критерии готовности | Неявные ожидания в голове сотрудника | Формализованная спецификация и проверки |
| Скорость выполнения | Зависит от графика специалиста | Высокая: итерации выполняются за минуты |
| Влияние усталости | Риск пропустить ошибку на 20–30 документе | Нулевое: проверка одинаково строга ко всем строкам |
| Стоимость процесса | Высокие затраты рабочего времени | Оптимальная: оплачиваются только вызовы API |
Автономный цикл переводит руководителя из роли рутинного корректора в позицию архитектора системы, освобождая время для содержательных решений.
Прикладные сценарии: от тестирования лид-форм до контентного аудита
Архитектура циклов применяется далеко за пределами документооборота:
- Сквозной аудит лидогенерации: Перед запуском рекламы агент может протестировать лид-формы: отправить тестовые заявки, проверить валидацию телефонов, подтвердить получение HTTP-ответа сервера, зафиксировать запись в CRM и проверить доставку транзакционного письма. При сбое агент повторяет тест и формирует отчет, предотвращая потерю рекламного бюджета.
- Редакционный аудит и Tone of Voice: При подготовке публикаций агент сверяет текст с редполитикой: проверяет отсутствие стоп-слов, корректность UTM-меток, наличие первоисточников и соответствие структуры формату.
- Сверка аналитики: При сведении отчетов агент агрегирует выписки, а модуль проверки пересчитывает итоговые суммы с помощью детерминированных скриптов, исключая арифметические ошибки модели.
Защита от бесконечных циклов, перерасхода токенов и рисков безопасности
Автономность требует инженерных ограничений. Без правильной конфигурации агент может зациклиться, если вводные данные противоречивы, а критерий приемки недостижим.
Для безопасной эксплуатации действуют четыре правила:
- Ограничение глубины итераций (
max_iterations): Обязательный параметр в коде или промпте. Для большинства задач достаточно 3–5 проходов. Если за 5 итераций дефекты не устранены, цикл останавливается с сохранением лога и уведомлением оператора. - Принцип наименьших привилегий (Least Privilege): Как подчеркивается в документации OpenAI Codex и Anthropic Claude Code, среда агента должна быть изолирована директорией проекта, без прямого доступа к внешним сетям и боевым базам данных.
- Разделение генерации и детерминированной проверки: Модуль контроля качества должен опираться на программные скрипты, регулярные выражения и схемы валидации там, где проверяются числа или форматы дат.
- Зоны ответственности человека: Финансовые транзакции, согласование юридических рисков и отправка персональных данных всегда требуют финальной подписи ответственного лица.
Чеклист внедрения: 5 шагов развертывания проекта в Loop-архитектуре
Чтобы внедрить автономный цикл проверки в процессы компании, выполните следующие шаги:
- Шаг 1. Сформируйте изолированную папку проекта: Разместите исходные материалы, конвертируйте текстовые документы в Markdown и составьте реестр входящих файлов.
- Шаг 2. Спроектируйте целевую структуру вывода: Создайте шаблон итогового файла (таблицу CSV или схему JSON) с четким списком обязательных полей.
- Шаг 3. Напишите спецификацию (
задание.md): Опишите правила приемки на языке измеримых критериев (форматы дат, нормализация чисел, маркеры отсутствия данных, цитаты-обоснования). - Шаг 4. Настройте журнал и лимит итераций: Создайте файл
журнал.mdдля фиксации проходов и задайте лимитmax_iterations = 3..5. - Шаг 5. Проведите пилотный прогон и аудит исключений: Запустите агента, проверьте логи в журнале и оцените качество заполнения реестра исключений. После калибровки передайте процесс в регулярную эксплуатацию.