Как спроектировать агента, который может самоисправляться (self-correction)?

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

Self-correction (самоисправление) — это способность AI-агента обнаруживать и исправлять ошибки в собственном ответе без вмешательства человека. Ключевая идея — ввести второго агента (критика), который проверяет выход первого и даёт обратную связь для итеративного улучшения. Проектирование такого агента требует продумать архитектуру «исполнитель-критик», механизм обратной связи, критерии остановки и баланс между качеством и вычислительными затратами.

1. Термин: Self-correction (самоисправление)

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

Зачем нужно self-correction

• Снижение галлюцинаций (hallucinations)
• Повышение фактической точности (factual accuracy)
• Улучшение релевантности ответа запросу
• Возможность исправить ошибки, не перезапуская весь пайплайн

2. Базовая архитектура: агент-исполнитель + агент-критик

Самая распространённая архитектура — два компонента:

Взаимодействие

1. Исполнитель получает запрос и контекст → генерирует ответ.
2. Критик получает запрос, контекст и ответ → выдаёт оценку и список проблем.
3. Если критика обнаружила ошибки → исполнитель перегенерирует ответ с учётом фидбека.
4. Цикл повторяется до 1–3 раз или пока ответ не пройдёт проверку.

3. Механизм обратной связи: как критик передаёт feedback

Критик должен выдавать структурированный фидбек, который исполнитель может интерпретировать. Пример формата:

{
  "is_correct": false,
  "issues": [
    {"type": "factual_error", "description": "Утверждение X не подтверждается документами", "suggestion": "Заменить на Y"},
    {"type": "missing_info", "description": "Не упомянут важный аспект Z", "suggestion": "Добавить абзац про Z"}
  ],
  "score": 0.6
}

Варианты передачи

• Текстовый фидбек — критик пишет естественным языком, что не так.
• Структурированный (JSON) — легче парсить, можно передавать в system prompt исполнителя.
• Дискретные метки — только «исправить»/«принять», без деталей (менее эффективно).

4. Итеративный процесс: количество итераций и условия остановки

Сколько итераций Обычно 1–3. Больше — растёт latency и стоимость, а улучшение насыщается.

Условия остановки

• Критик поставил оценку выше порога (например, score > 0.9)
• Критик не нашёл ошибок (is_correct: true)
• Достигнуто максимальное число итераций
• Ответ не изменился после предыдущей итерации (зацикливание)

Пример цикла на Python (псевдокод):

def self_correcting_agent(query, context, max_iterations=3):
    answer = actor(query, context)
    for i in range(max_iterations):
        feedback = critic(query, context, answer)
        if feedback["is_correct"]:
            break
        answer = actor(query, context, feedback=feedback)
    return answer

5. Типы проверок, выполняемых критиком

Критик может проверять разные аспекты:

6. Реализация критика: промпт-инжиниринг, fine-tuning, внешние инструменты

Промпт-инжиниринг — самый простой способ. Пример промпта критика:

Ты — критик. Проверь ответ на следующие критерии:
1. Все ли утверждения подтверждаются документами?
2. Полно ли ответ покрывает вопрос?
3. Нет ли противоречий?
Выдай JSON с полями "is_correct", "issues" (массив объектов с type, description, suggestion).

Fine-tuning — если нужно повысить точность критика под конкретную предметную область. Обучаем LLM на парах (ответ, размеченные ошибки).

Внешние инструменты — критик может вызывать поиск, калькулятор, базу знаний для верификации фактов. Например, если агент утверждает «население Москвы 12 млн», критик может сделать запрос к API и сверить.

7. Примеры фреймворков и подходов

8. Ограничения и компромиссы

9. Метрики оценки self-correction

Чтобы понять, работает ли self-correction, нужны метрики:

• Improvement rate — доля запросов, где после коррекции ответ стал лучше (по оценке человека или автоматической метрике).
• Correction accuracy — доля исправлений, которые действительно улучшили ответ.
• Average iterations — среднее число итераций на запрос.
• Cost per query — среднее количество токенов на один запрос.
• Latency p95 — 95-й перцентиль времени ответа.

10. Сравнение с другими подходами

11. Практические рекомендации по проектированию

1. Начинайте с простого — сначала реализуйте однопроходную генерацию, затем добавьте критика.
2. Используйте лёгкую модель для критика — например, GPT-4o-mini или локальную Llama 3.1 8B.
3. Дайте критику доступ к контексту — он должен видеть те же документы, что и исполнитель.
4. Структурируйте фидбек — JSON с типом ошибки и предложением по исправлению.
5. Ограничьте итерации — 2–3 обычно достаточно, больше — перерасход.
6. Логируйте все итерации — для анализа и отладки.
7. Тестируйте на бенчмарках — например, на наборе вопросов с известными правильными ответами.

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

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

Инструменты

• Python, OpenAI API (или другая LLM)
• LangChain / LangGraph для построения графа
• FAISS или Chroma для векторного поиска

Шаги:

1. Загрузите документацию (например, несколько страниц из Python docs) и разбейте на чанки.
2. Создайте векторное хранилище и реализуйте retrieval.
3. Напишите два промпта: actor_prompt (генерирует ответ на основе контекста) и critic_prompt (проверяет ответ на фактические ошибки, сравнивая с контекстом).
4. Реализуйте цикл: actor → critic → (если ошибки) actor с фидбеком → до 3 итераций.
5. Оцените improvement rate на 20 вопросах (сравните ответы до и после коррекции вручную).

Ожидаемый результат Вы увидите, что после self-correction ответы становятся точнее, хотя latency возрастает в 2–3 раза. Вы сможете настроить порог и число итераций.

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

Навигация

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