TL;DR
Fault Localization-Guided Repair — подход к исправлению сложных правил и политик, где перед починкой точно определяют какое конкретное правило ломает какой конкретный запрос и почему. Вместо "вот сломанная система, почини" LLM получает структурированный отчёт: "правило №3 явно разрешает запрос X, который должен быть запрещён" или "для запроса Y нет разрешающего правила, поэтому он неявно запрещён".
Когда просишь LLM починить набор правил "в лоб" (даёшь правила + примеры что работает неправильно), модель теряется в поиске причины. У неё нет карты "что именно сломано". Она перебирает гипотезы, может случайно сломать работающие части, тратит итерации на угадывание. Особенно остро с правилами из 5-10+ пунктов, где ошибка может быть в одном слове одного пункта.
Метод вводит три типа ошибок в правилах: (1) явное разрешение того, что должно быть запрещено, (2) явное запрещение того, что должно быть разрешено, (3) неявное запрещение (нет разрешающего правила) того, что должно быть разрешено. Для каждого сломанного запроса определяется тип ошибки и конкретное ответственное правило. LLM получает не "почини вообще", а "правило №2 явно запрещает запрос Z → убери ограничение или добавь исключение". Это превращает угадывание в точечный ремонт.
Схема метода
ШАГ 1: Проверка правил → список запросов, которые классифицируются неправильно
ШАГ 2: Fault Localization → для каждого сломанного запроса:
- Определить тип ошибки (явное разрешение / явный запрет / неявный запрет)
- Найти конкретное правило, ответственное за ошибку
→ Отчёт: "Запрос X: ожидается запрет, получено разрешение, ответственно правило №3"
ШАГ 3: LLM-починка → дать модели:
- Полные правила
- Отчёт fault localization
- Запросы с ожидаемыми результатами
→ Исправленные правила
ШАГ 4: Валидация → проверить починку на всех запросах
- Если все запросы классифицируются верно → готово
- Если нет → повторить с Шага 2 (новая fault localization на основе текущей версии)
Количество итераций: До полной починки или установленного лимита (обычно 3-5 итераций).
Пример применения
Задача: У тебя онлайн-школа по программированию. Есть чат-бот техподдержки с правилами — какие вопросы он решает сам, какие отправляет оператору. Правила сломаны: бот отправляет простые вопросы оператору (перегружает команду), а сложные пытается решить сам (недовольные студенты). Нужно починить правила.
Промпт:
Перед тобой правила работы бота техподдержки онлайн-школы.
ТЕКУЩИЕ ПРАВИЛА:
1. Вопросы про доступ к курсу — решает бот (отправляет инструкцию по входу)
2. Вопросы про оплату и возвраты — оператору
3. Технические проблемы с платформой — бот
4. Вопросы про сертификаты и дипломы — запрещены (нет такой функции)
ТЕСТОВЫЕ ЗАПРОСЫ И ОЖИДАЕМОЕ ПОВЕДЕНИЕ:
✅ Бот должен решить сам:
- "Не могу войти в личный кабинет"
- "Как скачать материалы урока?"
❌ Бот должен отправить оператору:
- "Хочу вернуть деньги за курс"
- "Видео не грузится уже 3 дня, перепробовал всё"
🚫 Бот должен отклонить:
- "Когда получу сертификат?"
ФАКТИЧЕСКОЕ ПОВЕДЕНИЕ (ЧТО ИДЁТ НЕ ТАК):
- "Не могу войти в личный кабинет" → бот решает (✅ правильно)
- "Как скачать материалы урока?" → оператору (❌ должен бот)
- "Хочу вернуть деньги за курс" → оператору (✅ правильно)
- "Видео не грузится уже 3 дня" → бот пытается решить (❌ должен оператору)
- "Когда получу сертификат?" → бот отвечает (❌ должен отклонить)
ЗАДАЧА 1 — FAULT LOCALIZATION:
Для каждого неправильно обработанного запроса определи:
- Тип ошибки: явное разрешение/запрет/неявное (нет правила)
- Какое правило ответственно
- Почему запрос попал не туда
Формат отчёта:
"Запрос: [текст]
Ожидается: [бот/оператор/отклонить]
Получено: [бот/оператор/отклонить]
Тип ошибки: [явное разрешение бота / явный запрет / неявное (нет правила для оператора) / ...]
Ответственное правило: [номер]
Причина: [объяснение]"
ЗАДАЧА 2 — REPAIR:
На основе fault localization исправь правила. Покажи:
- Какие правила меняешь
- Что конкретно меняешь (добавляешь/убираешь/уточняешь)
- Почему это починит конкретные ошибки
Результат:
Модель выдаст двухэтапный ответ:
Этап 1 — Fault Localization Report: Для каждого сломанного запроса — точное указание типа ошибки и ответственного правила. Например: "Запрос про скачивание материалов попал к оператору, потому что нет явного правила для бота → неявный запрет → нужно добавить правило".
Этап 2 — Исправленные правила: Точечные изменения с обоснованием. Например: "Правило 3 слишком широкое ('технические проблемы') — захватывает критичные баги → уточнить 'простые технические вопросы (вход, скачивание)' + добавить правило 'критичные баги (не работает >1 дня) → оператору'".
Получишь рабочую версию правил, которую можно протестировать на новых запросах.
Почему это работает
Слабость LLM: Модель плохо работает с обратной цепочкой рассуждений — когда нужно от результата (запрос обработан неправильно) вернуться к причине (конкретное правило сломано). Она видит систему правил как целое, начинает перебирать гипотезы "может быть правило 1 слишком широкое? или правило 3 нужно уточнить?" — теряет фокус, может сломать работающие части.
Сильная сторона LLM: Модель отлично работает с явными структурированными данными — когда вместо "вот сломанная система" даёшь "вот конкретные проблемы → конкретные причины → конкретные правила". Когда карта "запрос→ошибка→правило" нарисована, модель переходит от угадывания к точечному ремонту: "правило №3 разрешает X, который должен быть запрещён → заменить разрешающую часть на более узкую".
Как метод использует это: Fault Localization превращает абстрактную задачу "почини правила" в структурированный набор точечных исправлений. Каждая ошибка получает тип (явное разрешение/запрет/неявное) + адрес (конкретное правило). LLM получает не "найди что сломано и почини", а "вот список 'правило №2 → запрос Y → тип ошибки: явный запрет' — исправь конкретно эти правила". Это как разница между "машина не заводится" и "свечи зажигания в цилиндре 2 и 4 пробиты, заменить".
Рычаги управления:
Глубина fault localization: Можешь попросить LLM только определить ответственные правила (быстро) или дополнительно объяснить ЧТО ИМЕННО в правиле сломано (медленнее, точнее для сложных случаев).
Итеративность: Для простых правил хватит одного прохода починки. Для сложных (10+ правил, зависимости между ними) — запусти 2-3 итерации: чини → проверяй → новая fault localization на оставшихся ошибках → чини снова.
Примеры запросов: Чем больше тестовых запросов дашь (и чем разнообразнее), тем точнее fault localization найдёт проблемы. Но можно начать с 5-7 критичных кейсов — часто этого хватает для 80% починки.
Тип ошибок: Три базовых типа (явное разрешение/запрет/неявный запрет) работают для большинства правил. Можешь добавить свои типы для конкретной задачи (например, "конфликт правил" или "слишком широкая формулировка").
Шаблон промпта
Перед тобой набор правил, которые работают неправильно.
ТЕКУЩИЕ ПРАВИЛА:
{список_правил_пронумерованных}
ТЕСТОВЫЕ ЗАПРОСЫ:
✅ Должны быть разрешены:
{список_запросов_которые_должны_быть_разрешены}
❌ Должны быть запрещены (или переданы дальше):
{список_запросов_которые_должны_быть_запрещены}
ФАКТИЧЕСКОЕ ПОВЕДЕНИЕ:
{для_каждого_запроса: "запрос" → получено [разрешено/запрещено] → ожидалось [разрешено/запрещено]}
---
ЗАДАЧА 1 — FAULT LOCALIZATION:
Для каждого неправильно обработанного запроса определи:
- Тип ошибки:
* Явное разрешение (правило говорит "разрешить", но должно запрещать)
* Явный запрет (правило говорит "запретить", но должно разрешать)
* Неявный запрет (нет правила, которое разрешает)
- Какое конкретное правило ответственно (номер)
- Почему запрос обработан неправильно
Формат отчёта:
"Запрос: [текст]
Ожидается: [разрешить/запретить]
Получено: [разрешить/запретить]
Тип ошибки: [явное разрешение / явный запрет / неявный запрет]
Ответственное правило: [номер]
Причина: [объяснение коротко]"
---
ЗАДАЧА 2 — REPAIR:
Исправь правила на основе fault localization.
Для каждого исправления укажи:
- Какое правило меняешь (номер)
- Что было / что стало
- Какие ошибки из отчёта это исправляет
Параметры для подстановки:
- {список_правил_пронумерованных} — твои текущие правила, пронумерованные для удобства ссылок
- {список_запросов_которые_должны_быть_разрешены} — примеры того, что должно работать
- {список_запросов_которые_должны_быть_запрещены} — примеры того, что не должно работать
- {для_каждого_запроса...} — описание фактического поведения: какие запросы обработаны неправильно
Когда использовать: У тебя есть набор правил (бизнес-процесс, критерии оценки, модерация контента, чек-лист требований) + понимание что работает неправильно. Вместо угадывания "где ошибка" — получаешь точную карту ошибка→правило→причина, потом точечный ремонт.
Ограничения
⚠️ Требуется чёткая спецификация разрешено/запрещено: Метод работает когда ты точно знаешь "этот запрос должен быть разрешён, этот запрещён". Для субъективных критериев (креативность, качество текста) или размытых требований fault localization не даст точной карты.
⚠️ Зависимость от качества тестовых запросов: Fault localization находит только те ошибки, которые проявляются на твоих тестовых запросах. Если не покрыл важный кейс — правило останется сломанным. Нужен репрезентативный набор примеров.
⚠️ Сложность для взаимозависимых правил: Если правила связаны ("правило 3 работает только если сработало правило 1"), fault localization может указать на одно правило, а ломать будет комбинация нескольких. В таких случаях нужны итерации или явное указание LLM "правила могут конфликтовать".
⚠️ Не для создания правил с нуля: Метод чинит существующие правила. Если правил вообще нет — fault localization не от чего оттолкнуться. Начни с базовой версии правил (даже очень простой), потом применяй метод.
Ресурсы
CloudFix: Automated Policy Repair for Cloud Access Control Policies Using Large Language Models
Quacky (инструмент для анализа политик): quantitative policy analyzer для AWS IAM
William Eiers, Bethel Hall, Owen Ungaro (Department of Computer Science, Stevens Institute of Technology)