Как работает agent with external tool verification (проверка результатов API)?

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

Agent with external tool verification — это паттерн, при котором агент (LLM с доступом к инструментам) после вызова внешнего API запускает отдельный этап верификации (проверки) полученного результата. Верификатором (verifier) выступает вспомогательный LLM или строгий валидатор, который оценивает соответствие ответа ожиданиям: не пустой, нет ошибок, корректный формат, логическая связность. Если верификация не пройдена, агент может повторить вызов с другими параметрами, переключиться на альтернативный API или запросить уточнение у пользователя. В случае нескольких источников применяется кросс-верификация (cross-verification) — сравнение ответов и выбор консенсусного. Этот подход повышает надёжность агентных систем, снижает влияние «галлюцинаций» API и ошибок внешних сервисов.

1. Термин: Agent with external tool verification

Агент — LLM, который умеет вызывать внешние инструменты (tools): функции, API, базы данных. В контексте RAG агент может обращаться к поисковым движкам, калькуляторам, сервисам погоды и т.д.

Внешняя проверка результатов (external tool verification) — процесс, при котором результат вызова инструмента дополнительно оценивается перед тем, как вернуть пользователю. Верификация может быть реализована как:

• Структурная проверка (формат JSON, не пустой, код ответа HTTP 200) — без LLM.
• Семантическая проверка с помощью LLM-verifier: «Результат осмысленный?», «Не содержит противоречий?».
• Кросс-верификация — ответ из нескольких API сравнивается, выбирается наиболее частый или надёжный.

Термин «Verifier» (верификатор) — компонент, принимающий решение о корректности результата. Часто это отдельный LLM-вызов с меньшим контекстом и чётким промптом.

2. Зачем нужна верификация результатов API

Внешние API могут вернуть:

• Ошибку (timeout, 500, rate limit).
• Пустой ответ или ответ с некорректными данными.
• «Галлюцинации» — если API сам является LLM, он может выдать неверную информацию.
• Неполные данные (например, пропущены поля).

Без верификации агент передаст пользователю мусор. Проверка даёт:

• Надёжность: система не выдает заведомо плохой ответ.
• Возможность восстановления: при ошибке агент может повторить вызов (retry) или использовать fallback.
• Доверие: пользователь реже сталкивается с неработающими сценариями.

3. Базовая схема: агент → API → верификатор → действие

Шаги:

1. Агент получает запрос пользователя.
2. Агент выбирает инструмент (например, API погоды) и формирует параметры (город, дата).
3. Вызов API — отправка HTTP-запроса.
4. Получение ответа — сырой JSON или текст.
5. Верификация — проверка по правилам:
   • Синтаксическая: статус 200, структура JSON валидна.
   • Семантическая: LLM-verifier оценивает, соответствует ли ответ ожидаемой информации.
6. Решение:
   • Успех: ответ передаётся агенту, формируется финальный ответ пользователю.
   • Провал: агент переходит к стратегии обработки ошибки.

Схематично

Пользователь -> Агент -> API -> Ответ -> Verifier (LLM/правила) -> [OK -> Агент -> Пользователь] / [FAIL -> Retry/Fallback]

4. Роль Verifier (LLM) — семантическая проверка

Если простая структурная проверка не покрывает все кейсы, в качестве верификатора используют LLM-verifier. Его промпт содержит:

• Ожидаемый формат ответа.
• Критерии корректности (числовая погода, единицы измерения, не противоречивое описание).
• Инструкцию: вернуть «CORRECT», «INCORRECT» или «UNCERTAIN».

Пример промпта верификатора (упрощённый):

Ты — проверяющий результат API погоды.
Ответ API: {response}
Пользовательский запрос: {user_query}
Проверь: 
1. Содержатся ли поля: температура, влажность, скорость ветра?
2. Значения разумные? (температура -50..+50, влажность 0..100)
3. Нет ли явных ошибок (NaN, null, текст вида "ошибка")?
Ответь одним словом: CORRECT или INCORRECT. Если не уверен — UNCERTAIN.

Верификатор может быть реализован как отдельный LLM-вызов с низкой температурой (0.0–0.2) для минимизации творчества.

5. Стратегии обработки ошибки (fallback)

Когда верификация не пройдена, агент выбирает стратегию:

Важно количество retry должно быть ограничено (обычно 2–3), чтобы избежать бесконечных циклов и перерасхода лимитов API.

6. Кросс-верификация (cross-verification) нескольких источников

Когда в системе доступно несколько API для одной задачи, применяется кросс-верификация:

1. Агент вызывает одновременно или последовательно два (или больше) независимых API.
2. Каждый результат проходит базовую проверку.
3. Результаты сравниваются — если совпадают в пределах погрешности, берётся любой (или среднее).
4. Если расходятся — используется правило большинства (2 из 3) или дополнительный запрос к верификатору LLM, который решает, какой ответ правдоподобнее.
5. Крайний случай — если все источники дают разные ответы и верификатор не уверен, агент сообщает пользователю о неоднозначности и предлагает выбрать.

Пример: погода из двух API

• API A: температура 22°C, ясно.
• API B: температура 21°C, солнечно. → Верификатор: «Совпадают с точностью ±1°C, обе записи корректны». Агент выводит среднее 21.5°C.
• API A: 22°C, API B: 15°C (дождь). → Верификатор: «Расходятся, требуется консенсус». Если есть третий API — он решает. Если нет — агент спрашивает пользователя.

Преимущества кросс-верификации

• Устойчивость к единичным сбоям источника.
• Более высокая достоверность ответа.
• Возможность выявлять систематические ошибки конкретного API.

Недостатки время (множественные вызовы), затраты (каждый вызов стоит денег), сложность в выборе порога согласия.

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

import requests
from openai import OpenAI

client = OpenAI(api_key="...")

def call_weather_api(city: str, api_key: str) -> dict:
    url = f"https://api.openweathermap.org/data/2.5/weather?q={city}&appid={api_key}&units=metric"
    response = requests.get(url)
    data = response.json()
    return data

def verify_result(api_response: dict, user_query: str) -> str:
    prompt = f"""Проверь результат API погоды:
    Ответ: {api_response}
    Запрос: {user_query}
    Критерии:
    - есть ли поле 'main.temp' с числом
    - температура от -50 до 50
    - нет ошибок 'cod' != 404
    Ответь CORRECT или INCORRECT."""
    verification = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.0
    )
    return verification.choices[0].message.content.strip()

def agent_with_verification(user_query: str):
    city = extract_city(user_query)  # упрощённо
    max_retries = 2
    for attempt in range(max_retries):
        raw_data = call_weather_api(city, API_KEY)
        status = verify_result(raw_data, user_query)
        if status == "CORRECT":
            return f"Погода в {city}: {raw_data['main']['temp']}°C"
        else:
            # меняем параметры: попробуем другой город или добавим страну
            city += ",RU" if attempt == 0 else ""  
    return "Не удалось получить корректные данные. Попробуйте уточнить запрос."

8. Проблемы и ограничения подхода

• Стоимость: вызов LLM-верификатора увеличивает затраты в 1.5–2x на запрос.
• Задержка: дополнительный round-trip к LLM или повторный вызов API увеличивает время ответа.
• Ложные срабатывания верификатора: LLM-verifier может ошибочно отклонить корректный ответ или принять некорректный (особенно при плохо написанном промпте).
• Сложность настройки порогов: как определить, что ответ «достаточно хорош»? В кросс-верификации — какую разницу считать критической?
• Зависимость от надёжности verifier: если верификатор сам «галлюцинирует», вся схема рушится (нужно тестировать на золотом датасете).

Как снижать риски

• Использовать дешёвые модели-верификаторы (GPT-4o-mini, Llama 3.1 8B).
• Кешировать результаты проверки для частых запросов.
• Внедрить логирование и мониторинг: фиксировать, сколько раз верификация повлияла на итоговый ответ.

9. Сравнение с другими подходами верификации

Agent with external tool verification занимает промежуточную позицию: он дороже rule-based, но дешевле ансамбля, и при этом решает проблему семантической невалидности.

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

Задача Разработать агента, который по запросу пользователя находит погоду и проверяет результат через два независимых API (OpenWeather и WeatherAPI) с LLM-верификатором.

Инструменты

• Python, requests, openai или local модель через Ollama (llama3.1:8b).
• Два API ключа (свободные тарифы).

Шаги:

1. Реализуйте функции вызова каждого API с парсингом JSON.
2. Создайте LLM-верификатор (промпт проверяет наличие температуры, влажности, разумность диапазона).
3. В цикле: вызовите первый API, проверьте. Если INCORRECT — вызовите второй.
4. Если оба INCORRECT — верните сообщение об ошибке пользователю.
5. Если оба CORRECT — сделайте кросс-верификацию: сравните температуры (допуск ±1°C) и при совпадении верните среднюю; при расхождении — запросите у пользователя, какую использовать.
6. Добавьте логирование: записывайте в файл запрос, ответы API, вердикт верификатора.

Ожидаемый результат работает асинхронный (или синхронный) скрипт, который для корректного города возвращает валидированную погоду, а при проблемах — осмысленное сообщение.

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

Навигация

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