TL;DR
DRILS — конвейер из нескольких запросов к LLM, который по запросу на изменение находит в длинном техническом задании все пункты, которые придётся переписать вслед за правкой. Сначала каждый пункт «причёсывают» (раскрывают местоимения, добавляют справку из самого документа), потом два независимых аналитика-модели предлагают списки затронутых пунктов, а третья модель-судья собирает из них итоговый список с объяснением по каждому пункту.
Главная находка: при анализе влияния правок обычная схема «дай модели весь документ и спроси, что затронуто» даёт кучу ложных тревог. Аналитик тонет в проверке пунктов, которые на самом деле не связаны с правкой. Метод режет именно это: перед анализом пункты становятся самодостаточными (всё понятно без соседей), а модели дополнительно получают карту зависимостей между пунктами, чтобы цепочки последствий не терялись.
Суть метода: (1) очистить и обогатить каждый пункт; (2) разбить документ на смысловые группы, чтобы всё влезало в запрос; (3) два аналитика независимо дают список затронутых пунктов с причиной, местом правки и уверенностью; (4) судья выбирает итог. В чате для небольшого документа достаточно первых двух шагов и «судьи».
Схема метода
ШАГ 1 (очистка): пункт + 5 предыдущих → убрать неоднозначные «он/система/это» → пункт без двусмысленностей
(обогащение): сводки разделов документа → 3 самых близких → справка 3-5 строк по пункту
ШАГ 2: сгруппировать обогащённые пункты по смыслу (чтобы группа влезла в запрос)
ШАГ 3: для каждой группы два аналитика отдельно → список затронутых пунктов + причина + где править + уверенность
(на входе: пункты группы, запрос на изменение, граф зависимостей)
ШАГ 4: судья читает оба списка → итоговый список + причина по каждому пункту
Шаги 1-4 в статье — отдельные запросы к разным моделям; первый шаг сам состоит из трёх малых запросов.
Пример применения
⚠️ Метод для длинных документов, где пункты ссылаются друг на друга (ТЗ, регламенты, договоры, условия тарифов). Для короткого списка из десятка требований он избыточен.
Задача: продуктовый менеджер доставки «Самокат»-подобного сервиса добавляет в ТЗ мобильного приложения оплату через СБП. Нужно найти все пункты ТЗ, которые теперь придётся менять: возвраты, чеки, акции, статусы заказа, поддержка.
Промпт для аналитика (после того, как пункты очищены и дополнены справкой):
Ты аналитик изменений в требованиях. Тебе даны запрос на изменение, группа пунктов ТЗ и список зависимостей между пунктами в формате «пункт А зависит от пункта Б».
Найди все пункты группы, которые придётся изменить из-за этого запроса. Учитывай не только прямое влияние, но и цепочки: если изменён пункт X, а пункт Y зависит от X, проверь и Y.
Для каждого затронутого пункта укажи:
- Пункт: <номер и текст>
- Причина: <почему затронут>
- Где менять: <какая часть формулировки>
- Уверенность: <0-100>
Если пункт не затронут, не включай его в ответ.
Запрос на изменение: Добавить оплату заказа через СБП.
Пункты группы: {пункты}
Зависимости: {зависимости}
Результат: модель выдаст список из нескольких пунктов, к каждому причина, место правки и уверенность. Если запустить это дважды в разных чатах, а потом попросить третью модель выбрать итог из двух списков, ложных пунктов в итоге будет меньше.
Почему это работает
Слабость модели. Два типа ошибок: (1) в длинном контексте нужные детали теряются, особенно в середине; (2) пункт вроде «система должна уведомить пользователя» непонятен без соседей, и модель гадает, о какой «системе» идёт речь. Результат: пропущенные цепочки последствий и лишние «затронутые» пункты.
Сильная сторона. Модель хорошо переписывает отдельный пункт, подставляя нужного героя вместо «он/система», и хорошо сжимает раздел документа в короткую сводку. Она также неплохо сверяет два списка и выбирает лучший.
Как метод это использует. Сначала по маленьким кускам делается «понятный» пункт, потом короткая справка из документа добавляется только по теме этого пункта (в статье берут три самых близких раздела, а не всё подряд). Два независимых аналитика дают разнообразие мнений, а судья отсекает слабые. Граф зависимостей подсказывает, где искать цепочку, чтобы модели не приходилось угадывать.
Рычаги: - Число соседних пунктов для очистки (в статье пять) → больше для документов, где ссылки дальние. - Сколько разделов брать в справку (в статье три) → меньше, чтобы убрать шум; больше, чтобы не терять факты. - Формат справки. Список коротких предложений вместо абзацев: авторы заметили, что модель так даёт точные самостоятельные факты. - Поле «уверенность» → сделай порог для судьи: пункты с низкой уверенностью проверять в первую очередь.
Шаблон промпта
Это три запроса из статьи (переведены), сохранена их структура.
1. Раскрытие неоднозначностей
Ниже перечислены ранее определённые пункты. Используй их как контекст, чтобы раскрыть неоднозначные ссылки в текущем пункте. Замени неоднозначные ссылки (например, местоимения или расплывчатые именные группы) на явные, если их можно определить по предыдущим пунктам. Если неоднозначностей нет, верни текущий пункт без изменений.
Предыдущие пункты: {5_предыдущих_пунктов}
Текущий пункт: {пункт}
Формат ответа:
- Обоснование: <текст>
- Пункт без неоднозначностей: <текст>
2. Сжатие раздела
Сократи следующий текст, сохранив ключевую информацию, понятия и знания предметной области:
Текст: {раздел}
3. Обогащение пункта справкой
Тебе даны несколько разделов документа, отобранных по близости к пункту. Для пункта найди и выпиши информацию из этих разделов, которая его обогащает: добавляет контекст предметной области, поясняет объекты и ссылки, снимает неоднозначность, объясняет связанные функции или ограничения, добавляет недостающие сведения. Включай только то, что прямо относится к пункту, без домыслов и посторонних подробностей.
Разделы: {три_раздела}
Пункт: {пункт}
Формат ответа: маркированный список из отдельных предложений
Для аналитиков и судьи в доступной части статьи готовых текстов нет, ниже их заготовка по описанию (мой пересказ): аналитик получает группу пунктов, запрос на изменение и граф зависимостей и выдаёт для каждого пункта причину, место правки и уверенность; судья получает оба списка и выдаёт итоговый список с причиной по каждому пункту.
Что подставлять: {5_предыдущих_пунктов} — пять пунктов выше по документу; {раздел} — раздел документа; {три_раздела} — три самые близкие по теме сводки; {пункт} — одно требование.
🚀 Быстрый старт — вставь в чат:
Вот шаблон трёхшагового разбора документа для поиска затронутых пунктов. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что у тебя за документ, как разбит на пункты, есть ли ссылки между пунктами и какое изменение ты хочешь проверить. Это нужно, чтобы правильно подставить соседние пункты для раскрытия ссылок и собрать список зависимостей.
Ограничения
⚠️ Только автомобильные требования. Проверка шла на трёх наборах требований из автомобильной области, размеченных вручную. Для договоров, ТЗ интернет-магазина или регламентов результат не проверялся.
⚠️ Нужен граф зависимостей. В статье он входит в метод, и именно он дал самый заметный и стабильный вклад. Если зависимости между пунктами никто не записал, придётся сначала составить их (отдельная работа).
⚠️ Нужен конвейер. Много запросов подряд, группировка по смыслу и отбор близких разделов в статье делаются программой. В чате это возможно вручную только для небольшого документа.
⚠️ Часть деталей недоступна. В переданном тексте обрывается описание группировки, а промпты аналитиков и судьи, и разбор влияния отдельных частей метода дан только в кратком виде из введения.
⚠️ Не замена эксперту. Метод даёт список для проверки человеком: он выше по точности, но не абсолютно.
Как исследовали
Авторы (Оттавский университет вместе с инженерами General Motors) собрали три набора данных из автомобильных требований, где эксперты вручную разметили, какие пункты затрагивает каждое изменение. Свой метод сравнили с четырьмя современными подходами из разных групп: через зависимости, через модели, через языковые приёмы и через LLM. Самым сильным соперником оказался ProReFiCIA, тоже на LLM.
Итог: в среднем полнота около 87%, точность около 76%, мера F1 около 81%, а у ближайшего конкурента F1 было около 55%. Главный выигрыш пришёлся на точность: у конкурента точность около 41%, у DRILS около 76%, то есть в два раза меньше ложных тревог, которые аналитику надо разбирать руками. Метод при этом дешевле.
Затем «выключали» части метода по одной. Все вспомогательные данные (причина, место правки, уверенность, очистка, обогащение, группировка, граф) по отдельности помогли, а вместе подняли среднюю полноту с 71% до 87%. Самый сильный и стабильный вклад дал граф зависимостей: с ним F1 вырос примерно с 77% до 81%. Вывод для практики: структурированная подсказка о связях между пунктами работает лучше, чем «ещё больше контекста».
Адаптации и экстраполяции
🔧 Техника: добавить «судью с критиком» → меньше пропусков
После судьи запусти отдельный запрос: «Найди пункты, которые судья мог пропустить. Для каждого укажи, почему он может быть затронут». Это моя вариация, в статье не проверялась.
🔧 Техника: перенести на договор → какие пункты затронет правка
Вместо пунктов ТЗ бери пункты договора поставки, а вместо графа зависимостей составь список «пункт А ссылается на пункт Б» (например, «штраф по п. 7.2 зависит от срока по п. 3.1»). Это также моя вариация.
Ресурсы
DRILS: Dependency-based Requirement Change Impact Analysis Using LLMs (ACM, 2026). Авторы: Romina Etezadi, Ikram Darif, Lionel Briand (University of Ottawa; Lero Centre, University of Limerick), Ramesh S, Prakash Peranandam (General Motors). Сравнивали с ProReFiCIA; для первого шага использовали llama3.1-70b. Авторы публикуют три размеченных набора данных.