ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Реализовать delegation by exception

1. Цель задачи

Спроектировать и реализовать механизм delegation by exception в AI-агенте, который позволяет агенту автономно решать до 95% поступающих задач, а оставшиеся 5% (сложные или неоднозначные) передавать человеку-оператору. Агент должен уметь оценивать собственную уверенность в решении и принимать решение о делегировании на основе пороговых значений, истории успешности и динамического анализа.

Ключевой результат Работающий пайплайн, в котором не менее 95% тестовых задач решаются без вмешательства человека, а оставшиеся корректно направляются оператору с контекстом и предложенным решением.

2. Исходные данные

Если нет реального инструмента — симулируем:

1. Взять 200 задач из открытого датасета (например, GSM8K для математики, HotpotQA для multi-hop reasoning).
2. Разделить задачи на «лёгкие» (требуют 1–2 шага) и «сложные» (требуют >2 шагов, неоднозначные).
3. Реализовать простого агента, который пытается решить задачу, а если confidence_score < порога — отправляет в очередь на делегирование.
4. Для имитации оператора написать скрипт, который принимает делегированные задачи и выводит их в консоль (или сохраняет в файл).

3. Технологический стек

4. Этапы выполнения

Этап 1: Подготовка данных и базового агента (2–3 часа)

Действия

1. Скачать или сгенерировать датасет задач

   • Использовать 200–500 вопросов из GSM8K или HotpotQA.
   • Вручную пометить 10% как «сложные» (критерий: требуют >2 шагов или внешних данных).
   • Сохранить в data/tasks.json формата:

     [
       {"id": 1, "question": "...", "expected_answer": "...", "difficulty": "easy"},
       {"id": 2, "question": "...", "expected_answer": "...", "difficulty": "hard"}
     ]
     

2. Реализовать базового агента

   • Использовать LangChain с ChatOpenAI и инструментом PythonREPL (для вычислений).
   • Агент должен для каждой задачи:
     a. Получить вопрос.
     b. Сгенерировать цепочку рассуждений (ReAct).
     c. Получить финальный ответ.
   • Запустить на всех задачах, записать результаты (без делегирования) в logs/baseline.json.

3. Добавить метрику уверенности

   • Использовать logprobs ответа (среднее по токенам) или отдельный LLM-запрос:
     «Оцени от 0 до 1, насколько ты уверен в этом ответе. Ответь только числом.»
   • Нормализовать значение от 0 до 1.

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

• Файл data/tasks.json с задачами.
• Базовый агент, решающий все задачи (даже неверно).
• Лог baseline.json с полями task_id, answer, confidence, is_correct.
• Метрика: процент правильных ответов без делегирования (обычно <70% на сложных).

Этап 2: Разработка механизма «delegation by exception» (3–4 часа)

Действия

1. Определить правила делегирования

   • Если confidence < порога C_low (например, 0.3) → делегировать сразу.
   • Если confidence между C_low и C_high (0.3–0.7) → проверить через «вторичный критерий» (например, эвристики: длина ответа, количество шагов, повторяющиеся попытки).
   • Если confidence > C_high (0.7) → принять ответ и вернуть.

2. Реализовать класс DelegationManager

   • Метод should_delegate(response: AgentResponse) -> bool.
   • Использует не только уверенность, но и историю: если похожий запрос уже делегировался → делегировать снова.
   • Хранит счётчик делегированных задач. Обновляет пороги динамически (например, если процент делегирования > 5%, повысить C_low).

   class DelegationManager:
       def __init__(self, target_delegation_rate=0.05, confidence_threshold=0.7):
           self.target = target_delegation_rate
           self.threshold = confidence_threshold
           self.total = 0
           self.delegated = 0
   
       def should_delegate(self, confidence, context):
           # Простейшая логика
           if confidence < self.threshold:
               return True
           # динамическая корректировка порога (simplified)
           if self.total > 50 and self.delegated / self.total > self.target * 1.5:
               self.threshold *= 0.95  # снижаем порог, чтобы делегировать меньше
           return False
   

3. Создать очередь делегирования

   • Использовать asyncio.Queue или SQLite-таблицу delegations.
   • Для каждой делегированной задачи сохранять: task_id, question, agent_answer, confidence, timestamp, status (ожидает/решён/отклонён).

4. Интегрировать с агентом

   • Агент сначала генерирует ответ и confidence.
   • Если DelegationManager.should_delegate возвращает True → отправить задачу в очередь, вернуть пользователю {"status": "delegated", "message": "Задача передана оператору"}.
   • Иначе вернуть ответ агента.

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

• Реализованный DelegationManager с динамическими порогами.
• Очередь делегирования (SQLite).
• Интеграция с агентом: при запуске на всех задачах процент делегирования ≤ 10% (можно настроить).

Этап 3: Разработка интерфейса оператора (2–3 часа)

Действия

1. Спроектировать минимальный веб-интерфейс на Streamlit

   • Страница «Delegated Tasks»:
     • Таблица со столбцами: ID, вопрос, предложенный ответ, уверенность, время.
     • Кнопки «Принять ответ» (тогда ответ считается правильным) и «Отклонить и ответить вручную» (оператор пишет свой ответ).
     • Фильтр по статусу.
   • Страница «Metrics»:
     • Доля делегирования, средняя уверенность, количество решённых автономно.

2. Реализовать REST API (FastAPI) для взаимодействия с очередью

   • GET /api/delegations?status=pending
   • POST /api/delegations/{id}/resolve с телом {"accepted": true/false, "operator_answer": "..."}
   • GET /api/metrics (общее количество, делегировано, решено, процент).

3. Подключить Telegram-бота (опционально)

   • Бот присылает уведомление при новой делегированной задаче.
   • Оператор может ответить текстом, и ответ сохраняется в БД.

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

• Запущенный Streamlit-дашборд (или FastAPI-сервер).
• Возможность просмотреть все делегированные задачи и принять/отклонить.
• Логирование действий оператора.

Этап 4: Настройка порогов и достижение целевого показателя 95% (2–3 часа)

Действия

1. Определить baseline

   • Запустить агента с начальными порогами (C_low=0.3, C_high=0.7).
   • Посчитать процент автономно решённых и процент правильных среди них.

2. Подобрать оптимальные пороги через перебор

   • Для каждого порога от 0.1 до 0.9 с шагом 0.1 выполнить симуляцию на всех задачах.
   • Построить кривую «доля делегирования vs точность».
   • Выбрать порог, при котором доля делегирования ≤ 5%, а точность автономных решений максимальна.

3. Реализовать адаптивный механизм

   • Агент каждую неделю (или каждые 100 задач) пересчитывает порог на основе истории.
   • Использовать offline-анализ: если за последние 100 задач точность ≤ 90%, а делегирование > 5% → снизить порог.

4. Провести финальный прогон

   • Запустить агента на всех 500 задачах с подобранными порогами.
   • Зафиксировать метрики в final_report.json.

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

• Отчёт final_report.json с метриками:

  {
    "total_tasks": 500,
    "autonomous_solved": 476,
    "delegated": 24,
    "autonomous_accuracy": 0.97,
    "delegation_rate": 0.048,
    "operator_accuracy": 1.0
  }
  

• Выполнено условие: автономно решено ≥ 95% задач, точность автономной работы ≥ 90%.

Этап 5: Тестирование, документирование и демонстрация (1 час)

Действия

1. Написать unit-тесты для DelegationManager

   • Проверить, что при confidence=0.1 делегирование True, при confidence=0.9 False.
   • Проверить динамическую корректировку порога.

2. Написать интеграционные тесты

   • Смоделировать 20 задач, проверить, что делегируется не более 1 (5%).

3. Подготовить демонстрацию

   • Запустить агента на 10–20 тестовых задачах, показать лог автономных и делегированных.
   • Показать интерфейс оператора, принять одну задачу.

4. Задокументировать архитектуру

   • Краткое описание в README.md: как запустить, как настроить пороги, схема данных.

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

• Все тесты проходят.
• README с инструкцией.
• Демо-видео или живой запуск.

5. Критерии приемки (Definition of Done)

• Датасет задач размечен на лёгкие и сложные (≥ 200 задач).
• Агент корректно запускается и решает задачи без сбоев.
• Механизм делегирования основан на уверенности и/или дополнительных эвристиках.
• Очередь делегирования сохраняется в SQLite, доступна через API.
• Интерфейс оператора позволяет просматривать и разрешать задачи.
• Финальный прогон показал делегирование ≤ 5% при точности автономных решений ≥ 90%.
• Unit- и интеграционные тесты покрывают основные сценарии.
• README содержит инструкцию по запуску и настройке.
• Все логи и метрики сохраняются и доступны для анализа.

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

Основной артефакт

• Репозиторий с кодом, включая:
  • agent.py — базовый агент.
  • delegation_manager.py — класс делегирования.
  • app.py — FastAPI / Streamlit интерфейс.
  • tests/ — тесты.
  • data/ — датасет.
  • logs/ — результаты прогонов.

Содержимое финального отчёта

• final_report.json со статистикой.
• metrics.png (если строили график).

Дополнительные результаты

• Настроенный Telegram-бот для уведомлений.
• Документация по динамической калибровке порога.

7. Возможные сложности и их решение

8. Бюджет времени (оценка)

Примечание: Для первого раза закладывайте +30% на отладку и изучение инструментов.

9. Связанные вопросы из базы знаний

10. Чек-лист самопроверки

• Я подготовил датасет и разметил сложные и лёгкие задачи.
• Агент умеет решать задачи и возвращать confidence score.
• Логика делегирования проверена на синтетических данных.
• Интерфейс оператора работает и отображает очередь.
• Финальный прогон показал делегирование ≤ 5% и точность ≥ 90%.
• Я написал unit-тесты для DelegationManager.
• README содержит инструкцию по запуску.
• Все артефакты сохранены в репозитории.
• Я проверил, что делегированные задачи не теряются.
• Решение воспроизводимо на чистом окружении (requirements.txt / pyproject.toml).