Как вы предотвращаете tool overuse (когда агент вызывает API даже когда не нужно)?

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

Tool overuse — это ситуация, когда AI-агент избыточно вызывает внешние инструменты (API, функции, базы данных), даже когда ответ можно дать на основе собственных знаний или контекста. Это ведёт к росту затрат, задержек и риску ошибок. Предотвращение требует комбинации методов: cost penalty в reward-функции, prompt engineering, tool selection learning (дообучение), rate limiting и human-in-the-loop. Ключевая идея — агент должен «думать, прежде чем вызывать».

1. Термин: Tool overuse (избыточное использование инструментов)

Что это Поведение агента, при котором он вызывает API или функции в ситуациях, где это не нужно: например, запрашивает погоду для очевидного ответа «сегодня солнечно» или вызывает поиск для вопроса «сколько будет 2+2».

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

• Финансовые затраты каждый call|вызов API (например, к GPT-4 или внешнему сервису) стоит денег.
• Латентность: вызов инструмента добавляет 1–5 секунд к времени ответа.
• Риск ошибок инструмент может вернуть некорректные данные или упасть.
• Износ ресурсов серверные мощности тратятся впустую.

Термин «Tool overuse» — это частный случай over-reliance on tools, когда агент теряет способность рассуждать без внешней подпорки.

2. Cost penalty (штраф за вызовы)

Что это: Добавление отрицательного штрафа в reward-функцию агента за каждый вызов инструмента. Используется при обучении с подкреплением (RLHF, PPO) или при настройке через Reinforcement Learning from AI Feedback (RLAIF).

Как работает

• Reward = (качество ответа) - (cost_penalty * количество вызовов)
• Чем больше вызовов, тем ниже итоговый reward.
• Модель учится балансировать: вызывать инструмент только когда выгода от вызова превышает штраф.

Пример кода (псевдо-логика):

def compute_reward(response_quality: float, tool_calls: int, penalty_per_call: float = 0.1) -> float:
    return response_quality - (penalty_per_call * tool_calls)

Термин «Reward-функция» — это математическая функция, которая оценивает действие агента: чем выше значение, тем лучше.

Плюсы автоматически учит агента экономить вызовы. Минусы требует этапа обучения (RLHF), сложно настроить penalty (слишком высокий — агент перестанет вызывать даже нужные инструменты).

3. Prompt engineering (инженерия промптов)

Что это: Прямое указание в системном промпте агенту, когда следует вызывать инструменты, а когда — нет.

Пример промпта

Ты — полезный ассистент. У тебя есть доступ к инструментам: search_web, get_weather, calculate.
Вызывай инструмент ТОЛЬКО если:
1. Тебе не хватает знаний для ответа (например, актуальные данные).
2. Запрос требует вычислений, которые ты не можешь выполнить в уме.
3. Ты не уверен в факте и можешь его проверить.
НЕ вызывай инструмент для простых вопросов (например, «сколько будет 2+2», «какой сегодня день»), если ответ очевиден.

Термин «Системный промпт» — это начальная инструкция, которая задаёт поведение модели на всю сессию.

Эффективность работает для сильных моделей (GPT-4, Claude 3), но слабые модели могут игнорировать инструкции. Плюсы не требует обучения, быстро внедряется. Минусы не гарантирует соблюдения, агент может «забыть» инструкцию в длинном диалоге.

4. Tool selection learning (обучение выбору инструментов)

Что это: Дообучение (fine-tuning) модели на датасете примеров, где размечено, когда вызывать инструмент, а когда — нет.

Процесс

1. Собрать датасет: для каждого запроса указать, нужен ли вызов инструмента (бинарная метка) или какой инструмент выбрать.
2. Дообучить модель (например, LoRA на LLM) предсказывать эту метку.
3. На инференсе модель сначала решает, нужен ли вызов, и только потом генерирует аргументы.

Термин «Fine-tuning» — это дообучение предобученной модели на небольшом размеченном датасете для улучшения на конкретной задаче.

Пример датасета

Плюсы модель учится на примерах, поведение стабильно. Минусы требует размеченных данных и вычислительных ресурсов.

5. Rate limiting (ограничение частоты вызовов)

Что это: Установка жёсткого лимита на количество вызовов инструментов за одну сессию или за единицу времени.

Реализация

• Максимум 5 вызовов на диалог.
• Максимум 10 вызовов в минуту.
• После превышения лимита агент должен отвечать без инструментов.

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

class RateLimiter:
    def __init__(self, max_calls: int = 5):
        self.max_calls = max_calls
        self.call_count = 0

    def can_call(self) -> bool:
        return self.call_count < self.max_calls

    def record_call(self):
        self.call_count += 1

# Использование в агенте
limiter = RateLimiter(max_calls=3)
if limiter.can_call():
    result = call_tool("search_web", query)
    limiter.record_call()
else:
    result = "Извините, лимит вызовов исчерпан. Отвечаю на основе знаний."

Термин «Rate limiting» — это механизм контроля частоты запросов, чтобы предотвратить перегрузку системы.

Плюсы простота, гарантированное ограничение. Минусы может заблокировать нужные вызовы, если лимит слишком мал.

6. Human-in-the-loop (человек в цикле)

Что это: При подозрительном поведении (например, агент вызывает инструмент для очевидного вопроса) система запрашивает подтверждение у человека.

Реализация

• Агент генерирует намерение вызвать инструмент.
• Система проверяет: если запрос простой (по эвристике или ML-классификатору), то запрашивает подтверждение.
• Человек одобряет или отклоняет вызов.

Термин «Human-in-the-loop» (HITL) — это подход, при котором человек участвует в процессе принятия решений AI-системы.

Плюсы максимальная точность, предотвращение ошибок. Минусы замедляет ответ, требует человеческих ресурсов.

7. Мониторинг и алерты (observability)

Что это: Постоянный мониторинг поведения агента в production с автоматическими алертами при аномалиях.

Метрики для отслеживания

• Tool call rate среднее количество вызовов на запрос.
• Tool success rate доля успешных вызовов.
• Cost per session стоимость вызовов за сессию.
• False positive rate: доля вызовов, которые не привели к улучшению ответа.

Пример алерта

alert:
  name: high_tool_call_rate
  condition: avg_tool_calls_per_query > 3.0
  duration: 5m
  action: notify_team, reduce_rate_limit

Термин «Observability» — это способность понимать внутреннее состояние системы по внешним данным (логи, метрики, трейсы).

Плюсы позволяет быстро заметить проблему и отреагировать. Минусы требует инфраструктуры мониторинга.

8. Архитектурные паттерны для снижения tool overuse

8.1. Two-stage routing (двухэтапная маршрутизация)

• Первый этап лёгкий классификатор (например, BERT или правило) решает, нужен ли инструмент.
• Второй этап если нужен — вызывается LLM с инструментами, если нет — отвечает быстрая модель (например, distilled LLM).

Плюсы экономит вызовы дорогих инструментов. Минусы добавляет latency на классификацию.

8.2. Self-reflection (саморефлексия)

• Агент после генерации ответа проверяет: «Мог ли я ответить без вызова инструмента?»
• Если да — штраф в reward или логирование.

Термин «Self-reflection» — это механизм, при котором модель анализирует собственные действия и учится на ошибках.

9. Комплексный подход (рекомендация)

Лучшая стратегия — комбинировать методы:

1. Prompt engineering — быстрый старт.
2. Rate limiting — гарантированный барьер.
3. Cost penalty — если есть возможность RLHF.
4. Мониторинг — чтобы видеть реальное поведение.
5. Human-in-the-loop — для критических сценариев.

Пример pipeline

def agent_pipeline(query: str) -> str:
    # 1. Проверка rate limit
    if not rate_limiter.can_call():
        return generate_without_tools(query)
    
    # 2. Классификация: нужен ли инструмент?
    if not tool_need_classifier(query):
        return generate_without_tools(query)
    
    # 3. Генерация с инструментом
    result = generate_with_tools(query)
    
    # 4. Пост-проверка (self-reflection)
    if not was_tool_necessary(query, result):
        log_overuse(query)
        # Можно уменьшить reward в будущем
    
    return result

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

Задача Создать AI-агента для ответов на вопросы о погоде, который штрафует себя за избыточные вызовы API погоды.

Инструменты

• Python, LangChain, OpenAI API (или локальная модель через Ollama)
• FastAPI для демонстрации
• SQLite для логирования

Шаги:

1. Определить два инструмента: get_weather(city) и get_time(city).
2. Написать системный промпт с инструкцией не вызывать инструменты для очевидных вопросов.
3. Реализовать rate limiter (макс 3 вызова на сессию).
4. Добавить cost penalty: в логах считать «стоимость» каждого вызова (например, 0.01$ за вызов).
5. Собрать датасет из 50 примеров (запрос + метка «нужен инструмент»).
6. Дообучить небольшой классификатор (например, DistilBERT) предсказывать метку.
7. Интегрировать классификатор в pipeline: если классификатор говорит «не нужно», агент отвечает без вызова.
8. Запустить A/B тест: сравнить количество вызовов с классификатором и без.

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

• Агент вызывает API погоды только для вопросов вроде «Какая погода в Токио завтра?», но не для «Сколько времени в Париже?» (если время можно вычислить из контекста).
• Количество вызовов снижается на 40–60% без потери качества ответов.
• Логи показывают, какие запросы были «ложными срабатываниями».

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

Навигация

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