Как детектировать «объяснительно-решенческую декомпозицию»?

Краткий тезис

Объяснительно-решенческая декомпозиция (explanation-decision decoupling) — это ситуация, когда AI-агент генерирует правдоподобное объяснение своих действий, которое не соответствует реальной логике принятия решений. Детектировать её можно через perturbation consistency (устойчивость вывода при изменении нерелевантных деталей входа) и анализ reasoning chain (цепочки рассуждений). Если вывод агента остаётся стабильным при изменении факторов, которые он сам назвал важными, это сигнал о декомпозиции. Методы включают reasoning|контрфактические тесты, анализ внимания и метрики согласованности.

1. Термин: объяснительно-решенческая декомпозиция (explanation-decision decoupling)

Объяснительно-решенческая декомпозиция (или decoupling) — это разрыв между тем, как агент на самом деле принимает решение, и тем, как он это объясняет. В контексте Agentic RAG (архитектура, где LLM-агент планирует, использует инструменты и генерирует ответ) это проявляется, когда агент сначала выдаёт ответ, а затем «задним числом» строит цепочку рассуждений, которая выглядит логично, но не отражает истинные причины.

Почему это проблема

• Подрывает доверие к системе: пользователь думает, что агент «думает», а на деле он просто галлюцинирует объяснение.
• Усложняет отладку: если объяснение не соответствует решению, невозможно понять, почему агент ошибся.
• В RAG|Agentic RAG это особенно опасно, так как агент может ссылаться на документы, которые на самом деле не повлияли на ответ.

Пример: Агент на вопрос «Какая столица Франции?» отвечает «Париж» и пишет: «Я нашёл в документе 1, что столица — Париж». Но на самом деле он просто запомнил факт из предобучения, а документ 1 был про моду. Perturbation-тест: если заменить документ 1 на документ про Лондон, ответ не изменится — это decoupling.

2. Зачем детектировать decoupling в Agentic RAG

В RAG|Agentic RAG агент часто использует chain-of-thought (цепочку рассуждений) и tool calls (вызовы инструментов). Декомпозиция может возникнуть на любом этапе:

• Reasoning step: агент пишет «сначала я ищу документы», но на деле сразу генерирует ответ.
• Tool selection: агент говорит, что использовал поиск, но на самом деле ответил из памяти.
• Attribution: агент приписывает ответ конкретному документу, хотя документ нерелевантен.

Детектирование нужно для:

• Аудита (compliance): в регулируемых областях (медицина, финансы) требуется объяснимость.
• Улучшения агента: если decoupling обнаружен, можно дообучить агента (fine-tuning) или изменить промпт.
• Безопасности: агент может маскировать нежелательное поведение правдоподобными объяснениями.

3. Метод 1: Фиксация вывода и reasoning chain

Первый шаг — собрать reasoning chain (цепочку рассуждений) агента. В современных фреймворках (LangChain, CrewAI) это можно сделать, логируя каждый шаг: мысль, действие, наблюдение.

Как детектировать

• Сравнить conclusion (вывод) с reasoning chain.
• Если в chain есть шаги, которые логически не ведут к выводу (например, агент пишет «я нашёл документ X», но вывод основан на другом факте), это подозрение на decoupling.

Пример кода (Python, LangChain):

from langchain.agents import AgentExecutor, create_react_agent
from langchain import hub

# ... создание агента ...

def detect_decoupling(agent_output):
    reasoning = agent_output["intermediate_steps"]
    conclusion = agent_output["output"]
    # Простейшая проверка: есть ли в reasoning упоминание ключевых слов из conclusion?
    keywords = set(conclusion.lower().split())
    reasoning_text = " ".join([str(step) for step in reasoning])
    overlap = keywords.intersection(set(reasoning_text.lower().split()))
    if len(overlap) < len(keywords) * 0.3:  # менее 30% совпадения
        return True  # возможен decoupling
    return False

Ограничение этот метод поверхностный — агент может использовать синонимы. Нужна более глубокая проверка.

4. Метод 2: Perturbation consistency (основной)

Perturbation consistency — это проверка, меняется ли вывод агента при изменении нерелевантных (по мнению агента) частей входа. Если вывод стабилен, а агент утверждает, что эти части важны, — это decoupling.

Алгоритм

1. Зафиксировать исходный запрос и ответ агента.
2. Извлечь из reasoning chain факторы, которые агент назвал важными (например, «документ 3», «поле 'цена'»).
3. Создать perturbed input — изменить эти факторы на заведомо нерелевантные (например, заменить документ на случайный, изменить числовое значение).
4. Подать perturbed input агенту (с тем же seed, чтобы минимизировать случайность).
5. Сравнить новый вывод с исходным.

Интерпретация

• Если вывод не изменился, а агент в объяснении ссылался на изменённый фактор → decoupling (агент не использовал этот фактор на самом деле).
• Если вывод изменился → скорее всего, агент действительно учитывал фактор (но может быть и случайность).

Пример:

• Исходный запрос: «Какая цена товара A в документе 1?»
• Агент отвечает: «100 рублей, потому что в документе 1 написано 100».
• Perturbation: заменяем документ 1 на документ с ценой 200.
• Новый ответ: «100 рублей» → decoupling (агент не читал документ).

Реализация

import copy

def perturbation_test(agent, query, important_factors, perturb_func):
    original_output = agent.run(query)
    perturbed_query = perturb_func(query, important_factors)
    perturbed_output = agent.run(perturbed_query)
    return original_output == perturbed_output  # True = decoupling

Важно perturbation должна быть минимальной, чтобы не изменить смысл запроса для человека, но достаточной для проверки.

5. Метод 3: Контрфактические тесты (counterfactual reasoning)

Контрфактический тест — это частный случай perturbation, когда мы меняем один фактор на противоположный (например, «документ содержит ответ A» → «документ содержит ответ B»). Если агент продолжает утверждать A, хотя объяснение ссылается на документ, — decoupling.

Пример:

• Запрос: «Какой город является столицей Франции, согласно документу?»
• Агент: «Париж, потому что в документе написано 'Париж — столица'».
• Контрфакт: заменяем документ на «Лондон — столица Великобритании».
• Агент: «Париж» → decoupling.

Метрика counterfactual consistency rate — доля тестов, где вывод изменился после контрфактического изменения. Низкое значение (<0.5) указывает на систематический decoupling.

6. Метод 4: Анализ внимания (attention) и градиентов (saliency)

Для transformer-based агентов можно анализировать attention weights (веса внимания) или saliency maps (карты значимости) — какие токены входа сильнее всего влияют на выход.

Как детектировать decoupling

• Если агент в объяснении указывает на токен X, но attention/saliency показывает, что токен Y (не упомянутый) имеет больший вес, — это decoupling.
• Gradient-based saliency: вычисляем градиент логарифма вероятности ответа по каждому токену входа. Токены с высоким абсолютным градиентом — реально важные.

Инструменты

• Captum (PyTorch) для saliency.
• TransformerLens для анализа attention.

Ограничение требует доступа к внутренностям модели, что не всегда возможно для API-моделей (GPT-4, Claude).

7. Метрики для детектирования decoupling

Целевые значения

• Consistency Score > 0.8 — хорошо (агент действительно использует указанные факторы).
• Decoupling Score < 0.2 — приемлемо.
• Если Decoupling Score > 0.5 — критическая проблема.

8. Инструменты для автоматизации

• LangSmith: позволяет логировать шаги агента, создавать датасеты для perturbation-тестов, запускать их и смотреть метрики.
• MLflow: для экспериментов с разными версиями агента.
• RAGAS: хотя он в основном для RAG, можно адаптировать метрику faithfulness для оценки объяснений.
• SelfCheckGPT: библиотека для проверки согласованности генераций (можно применить к reasoning chain).

Пример интеграции с LangSmith

from langsmith import Client, evaluate

client = Client()
# Создаём датасет с perturbation-примерами
# Запускаем evaluation с кастомной метрикой decoupling

9. Ограничения и сложности

• Случайность LLM: даже при одинаковом seed модель может выдавать разные ответы. Нужно усреднять по нескольким запускам.
• Сложность определения «важных факторов»: агент может назвать много факторов, но не все реально влияют. Нужно автоматически извлекать их из reasoning chain (NLP-парсинг).
• Perturbation может сломать запрос: если изменить слишком много, запрос станет бессмысленным. Нужны умные стратегии (например, замена на синонимы).
• API-модели: для GPT-4 нельзя посмотреть attention, только perturbation.
• Вычислительные затраты: каждый тест требует нескольких запусков агента.

Пет-проект для закрепления

Задача Создать агента, который отвечает на вопросы по документации (например, по Python), и реализовать детектор decoupling.

Инструменты

• LangChain (агент с инструментом поиска по векторной БД).
• ChromaDB / FAISS для хранения документов.
• LangSmith для логирования.
• Python (библиотеки: numpy, random).

Шаги:

1. Собрать 10-20 документов (например, выдержки из документации Python).
2. Создать агента с инструментом retrieve_docs(query).
3. Написать функцию extract_important_factors(reasoning_chain) — извлекает ID документов, на которые ссылается агент.
4. Реализовать perturbation_test: для каждого запроса заменить один из упомянутых документов на случайный.
5. Запустить 50 тестов, посчитать Decoupling Score.
6. Визуализировать: сколько раз агент «обманул» (не изменил ответ).

Ожидаемый результат

• Вы получите численную оценку decoupling для вашего агента.
• Увидите, что простые агенты (без chain-of-thought) имеют более высокий decoupling.
• Сможете улучшить агента, добавив в промпт инструкцию «всегда используй найденные документы».

Связь с другими вопросами

Навигация

• Предыдущий: 174
• Следующий: 176
• Индекс: 00. Индекс разборов