TL;DR
FilingLoop — это агентная схема для проверки и доработки больших комплексных документов, где работа разделена между двумя изолированными ролями (Рецензент и Составитель), независимым Оценщиком и Редактором навыков, который обновляет инструкции ролей после каждого пакета задач. Вместо того чтобы просить одну модель «найти и исправить все проблемы» в общем чате, система раскладывает замечания на атомарные требования, проверяет их фактическое внесение в итоговый текст и переносит успешные приёмы проверки в следующие кейсы.
Когда один агент или аналитик проверяет сложный многостраничный отчёт, возникают три типичных сбоя: модель пропускает неочевидные умолчания (например, компания пишет «выручка выросла за счёт высокого спроса», не раскрывая конкретные драйверы), путает обещание исправить с реальной правкой в тексте и закрывает составное замечание частично, ответив только на один пункт из трёх. Причина проста: в длинном диалоге размывается связь между исходным замечанием, запрошенными фактами и тем, какая именно строчка изменилась в финальной редакции документа.
Метод решает это за счёт жёсткого разделения ролей и поштучной верификации требований. Рецензент ищет пробелы с привязкой к источникам, Составитель запрашивает недостающие факты и вносит точечные замены в черновик, а отдельный Оценщик в три этапа сверяет каждое элементарное требование с финальным файлом и передаёт разбор ошибок Редактору навыков, который дописывает обобщённые правила в Markdown-инструкции обеих ролей для будущих документов.
Схема метода
ВНУТРИ ОДНОГО КЕЙСА (отдельные вызовы с изолированной историей ролей):
ШАГ 1 (Рецензент): Аудит комплекта документов → список замечаний с цитатами и ID
ШАГ 2 (Составитель): Запрос недостающих фактов + точечные замены (исходный фрагмент → новый фрагмент + ID замечания) → обновлённый черновик и официальный ответ
ШАГ 3 (Повторный раунд): Рецензент проверяет обновлённый черновик и ответы → закрывает выполненные пункты или возвращает на доработку
НЕЗАВИСИМАЯ ПРОВЕРКА И ЭВОЛЮЦИЯ (отдельные запросы после фиксации результата):
ШАГ 4 (Оценщик): Сопоставление замечаний (Matching) → Поштучная проверка требований в финальном файле (Fulfillment) → Аудит фактов на выдумки и противоречия (Audit) → JSON-отчёт
ШАГ 5 (Редактор навыков): Разбор JSON-отчёта по пакету задач → обновление Markdown-инструкций Рецензента и Составителя без упоминания конкретных компаний
Пример применения
Задача: Подготовка инвестиционного меморандума и презентации для привлечения раунда в российский B2B SaaS-сервис складской аналитики (выручка 180 млн рублей в год, клиенты на Ozon и Wildberries). Нужно выловить голословные утверждения до отправки документа инвесткомитету фонда.
Промпт:
Проведём двухролевой аудит и доработку инвестиционного меморандума по методу FilingLoop. Выполняй шаги последовательно.
Черновик меморандума:
«Раздел 2. Финансовые результаты. За 2025 год выручка компании выросла на 65% и составила 180 млн руб. Рост обусловлен высоким спросом со стороны селлеров маркетплейсов и запуском нового модуля нейросетевого прогнозирования остатков. Отток клиентов (Churn) снизился до минимальных значений, а юнит-экономика вышла в уверенный плюс во втором полугодии».
Доступные внутренние факты компании (база фактов):
1. Из 71 млн руб. прироста выручки 52 млн руб. принесло повышение тарифов для старых клиентов с апреля 2025 года, а новый модуль прогнозирования дал 9 млн руб.
2. Помесячный отток в деньгах (Gross MRR Churn) снизился с 4,8% до 3,1%, но логотипный отток мелких селлеров вырос с 6% до 8,5%.
3. Положительная юнит-экономика (LTV/CAC = 3,4) достигнута только в сегменте селлеров с оборотом от 5 млн руб./мес; в младшем сегменте CAC окупается 14 месяцев при среднем сроке жизни клиента 9 месяцев.
Роль: Строгий инвестиционный аудитор (Рецензент). У тебя НЕТ доступа к внутренней базе фактов — ты видишь только черновик меморандума.
1. Найди все голословные заявления, нераскрытые причины роста и размытые формулировки.
2. Сформируй список замечаний (C-1, C-2...).
3. Разбей каждое составное замечание на атомарные требования (R-1.1, R-1.2...), указав для каждого: что именно нужно раскрыть и где это должно появиться (правка в самом тексте меморандума или пояснение в сопроводительном письме).
Роль: Юрист и аналитик компании (Составитель).
1. Для каждого требования Рецензента извлеки подтверждённые цифры из блока «Доступные внутренние факты компании».
2. Выдай точечную замену текста черновика в формате:
- ID требования: [R-X.Y]
- Заменяемый фрагмент: «...»
- Новый фрагмент: «...»
Не обещай «уточнить позже» — все обязательные раскрытия должны быть прямо вписаны в новый текст раздела.
Роль: Независимый Оценщик и Редактор навыков.
1. Проверь каждое требование R-X.Y по итоговому тексту меморандума: вынеси вердикт (Выполнено / Не выполнено), приведи точную цитату из новой редакции и проверь, нет ли противоречий с базой фактов или ухудшения исходного текста.
2. Сформулируй по 1 универсальному правилу для Markdown-инструкции Рецензента и Составителя на будущие сделки (без упоминания названия этой компании и её цифр).
Результат: На первом шаге модель в роли Рецензента выделит три замечания (по структуре прироста выручки на 65%, по размытому «минимальному оттоку» и по «уверенному плюсу» юнит-экономики) и разобьёт их на 6 атомарных требований. На втором шаге Составитель подтянет цифры из базы фактов и перепишет абзац меморандума, честно разделив эффект от повышения цен (52 млн руб.) и нового модуля (9 млн руб.), а также разграничив когорты клиентов. На третьем шаге Оценщик сверит итоговый текст с каждым подпунктом R-X.Y, подтвердит отсутствие выдуманных фактов и запишет переносимые правила в копилку навыков (например: требовать декомпозицию роста выручки на ценовой фактор и органический приток новых продуктов).
Почему это работает
Обычная самопроверка («проверь и улучши свой текст») буксует на сложных документах, потому что модель оценивает убедительность тона, а не полноту исполнения. Если в ответе написано «мы учли замечание и раскрыли факторы роста», модель-автор считает задачу решённой, даже если в самом документе по-прежнему осталась вода или исправлен только первый пункт из трёх.
Вторая проблема — при попытке обучить агента на прошлых кейсах в промпт часто попадают конкретные факты предыдущих компаний (названия, даты, специфические метрики). В результате на новом документе агент начинает искать проблемы прошлой компании или подставлять чужие шаблоны туда, где нет подтверждающих данных.
FilingLoop обходит обе ловушки за счёт декомпозиции и фильтрации опыта. Во-первых, каждое замечание дробится на атомарные требования с привязкой к целевому артефакту: обещание в переписке не засчитывается, если требовалось изменить сам документ. Во-вторых, Редактор навыков после пакета задач проходит жёсткую валидацию: он обязан превратить конкретные промахи в абстрактные процедурные правила (как искать пробелы и как сверять правки), отсекая любые идентификаторы компаний и прямые цитаты из эталонов.
Рычаги управления:
- Дробление составных замечаний: требуй нумеровать каждое действие внутри одного комментария (R-1.1, R-1.2) — это не даёт модели закрыть замечание частичной отпиской.
- Разделение черновика и сопроводительного ответа: явно указывай тип результата (правка в тексте документа против пояснение в комментарии), чтобы важные факты не оседали только в чате.
- Фильтр на перенос навыков: при обновлении системного промпта запрещай записывать доменные числа и имена собственные — переносить можно только алгоритм проверки.
Шаблон промпта
Выполни аудит и доработку документа по схеме FilingLoop.
{черновик_документа}
{подтвержденные_факты_и_источники}
ШАГ 1 — РЕЦЕНЗЕНТ (поиск пробелов):
Изучи , не заглядывая в . Найди нераскрытые утверждения, пропущенные причинно-следственные связи и нестыковки.
Для каждого замечания (C-1, C-2...) выпиши атомарные требования (R-1.1, R-1.2...):
- Цитата из , вызывающая вопрос.
- Что конкретно нужно добавить или подтвердить.
- Где должно быть изменение: в самом тексте документа или в пояснении.
ШАГ 2 — СОСТАВИТЕЛЬ (внесение правок по фактам):
Используя только , отработай каждое требование R-X.Y:
- Если фактов в нет — явно зафиксируй ограничение данных, ничего не додумывай.
- Для каждого изменения в документе выдай блок замены:
[ID требования] → [Точная исходная фраза] → [Новая фраза с фактами]
- Собери обновлённую редакцию .
ШАГ 3 — НЕЗАВИСИМЫЙ ОЦЕНЩИК (тройной контроль):
Проверь по каждому требованию R-X.Y:
1. Выполнение (Fulfillment): внесена ли правка в сам текст (обещания не считаются).
2. Аудит фактов (Audit): каждое ли новое утверждение опирается на , нет ли противоречий и не испорчены ли соседние верные абзацы.
3. Обновление навыка (Skill Evolution): сформулируй 1–2 универсальных процедурных правила для Рецензента и Составителя на будущие задачи (без имён собственных и частных фактов этого кейса).
Что подставлять в плейсхолдеры:
- {черновик_документа} — текст отчёта, договора, коммерческого предложения, технического задания или статьи, который нужно проверить.
- {подтвержденные_факты_и_источники} — выгрузки из таблиц, переписка с клиентом, финансовые отчёты или фактура, на которую можно опираться при правке.
🚀 Быстрый старт — вставь в чат:
Вот шаблон метода FilingLoop для перекрёстного аудита и доработки документов. Адаптируй его под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какой документ вы проверяете (отчёт, ТЗ, презентацию), какие исходные данные есть под рукой и по каким стандартам нужно искать пробелы — потому что методу нужно чётко развести проверяемый черновик и базу подтверждающих фактов. Она возьмёт паттерн из шаблона и адаптирует под задачу.
Ограничения
⚠️ Потолок качества при нехватке фактов: Половина всех требований в реальном аудите упирается в недостающие внутренние сведения компании. Если нужных данных нет в базе фактов или агент не умеет формировать точечный запрос на их получение, даже идеальная процедура самопроверки закрывает лишь малую долю замечаний.
⚠️ Риск побочных повреждений текста (Harm): При внесении правок агент-составитель иногда портит соседние корректные формулировки или вставляет утверждения, которые выходят за рамки подтверждённых фактов. Поэтому этап аудита изменений относительно исходника обязателен.
⚠️ Инженерный порог полного цикла: В оригинальном виде система требует кодовой обвязки — изолированных рабочих пространств для двух ролей, контроллера уникальности текстовых замен, шлюза выдачи фактов и пакетного валидатора Markdown-навыков. В одном окне чата воспроизводится только логика ролевой проверки и атомарного чеклиста.
Как исследовали
Команда из Наньянского технологического университета (Сингапур) и HKUST (Гуанчжоу) собрала интерактивный бенчмарк FilingLoop на основе реальных архивов переписки Комиссии по ценным бумагам и биржам США (SEC EDGAR) с мая 2016 по март 2026 года. Из 300 кандидатов отобрали 380 раундов ревью (в основном выход компаний на IPO) по 96 компаниям с медианной длиной документа 111,8 тыс. слов; внутри них разметили 3 012 замечаний регулятора и разбили их на 6 099 атомарных требований. Статистика корпуса сразу вскрыла корень проблемы: в медианной задаче нужно найти 4 разных замечания (в 90-м перцентиле — до 21), причём 62,7% замечаний содержат сразу несколько требований, а 50,5% требуют запроса внутренних фактов компании, которых нет в публичном отчёте. Исследователи сравнили агентов с фиксированными инструкциями (Fixed) и самообучающихся агентов (Evolving), которые после каждого пакета задач обновляли свои Markdown-скилы по отчётам независимого Оценщика без изменения весов модели и без повторного прогона уже оценённых кейсов. Эволюция процедурных навыков подняла долю полностью закрытых требований с 24,28% до 27,96%, а полное разрешение замечаний — с 16,90% до 20,75% при росте общих затрат всего на 5,8%, снизив итоговую стоимость каждого успешно выполненного требования.
Адаптации и экстраполяции
💡 Адаптация для код-ревью и приёмки ТЗ в
CLAUDE.md/AGENTS.md:Принцип разделения Matching → Fulfillment → Audit и накопления навыков отлично ложится в инструкции ИИ-агентам для разработки:
## Правило приёмки правок (протокол FilingLoop) 1. Декомпозиция: перед правкой разбей замечание из PR или задачи на атомарные требования (R-1, R-2...) с указанием целевого файла. 2. Проверка в артефакте: требование считается выполненным ТОЛЬКО если изменение зафиксировано в целевом файле. Объяснение в ответе без изменения кода не засчитывается. 3. Аудит на регрессии: после правки проверь, что все числа/утверждения опираются на логи или тесты, а соседняя логика не повреждена. 4. Эволюция скила: если на ревью всплыла повторяющаяся ошибка, запиши в `.claude/skills/review-checklist.md` общее процедурное правило (без привязки к именам конкретных функций текущего тикета).
Ресурсы
Исследование: FilingLoop: Evaluating and Evolving LLM Agents for Corporate Disclosure Review and Revision Авторы: Wentao Zhang, Yilei Zhao, Guangyan Gan, Lin William Cong (Nanyang Technological University, Singapore), Shuo Sun (The Hong Kong University of Science and Technology, Guangzhou) Источники данных: Архив корпоративной отчётности и писем-комментариев SEC EDGAR (https://www.sec.gov/search-filings/edgar-search-assistance/accessing-edgar-data)