Как работают verifier models для agentic RAG и зачем они нужны?

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

Verifier model (верификатор) — это компактная модель (например, BERT или LLM до 1B параметров), которая проверяет корректность действий или финального ответа RAG|agentic RAG-системы. В отличие от дорогой генеративной LLM, верификатор работает быстро и дёшево, выступая фильтром качества. Он позволяет агенту повторять неудачные шаги или эскалировать сложные случаи человеку, повышая надёжность и безопасность системы.

1. Термин: Verifier model (верификатор)

Verifier model — это модель, обученная или настроенная на бинарную классификацию (корректно/некорректно) или оценку качества (score) для выходов LLM или промежуточных шагов агента. В контексте RAG|agentic RAG верификатор применяется на двух уровнях:

• Step verifier — проверяет каждый шаг агента (например, выбор инструмента, формулировку запроса к поиску, извлечение факта).
• End verifier — оценивает финальный ответ перед показом пользователю.

Ключевое свойство — лёгкость: модель должна быть на порядок меньше основной LLM, чтобы не создавать задержек.

2. Зачем нужны verifier models в agentic RAG?

Agentic RAG — это система, где LLM-агент самостоятельно планирует цепочку действий: поиск документов, чтение, синтез, уточнение запроса. Без верификатора агент может:

• выдать галлюцинацию (факты, не подтверждённые документами);
• зациклиться на непродуктивных шагах;
• пропустить критическую информацию.

Verifier решает эти проблемы:

Кроме того, верификатор снижает стоимость: вместо повторного вызова большой LLM для самопроверки (self-consistency, LLM-as-a-judge) используется маленькая модель.

3. Типы verifier models: Step verifier vs End verifier

3.1 Step verifier

Проверяет каждый шаг агента в реальном времени. Примеры проверок:

• «Является ли сформулированный поисковый запрос релевантным исходному вопросу?»
• «Содержит ли retrieved-документ хотя бы один факт, относящийся к текущему подзапросу?»
• «Не повторяет ли агент одно и то же действие?»

Если step verifier даёт низкую оценку (< порога), агент может:

• переформулировать запрос;
• выбрать другой инструмент;
• запросить уточнение у пользователя.

3.2 End verifier

Оценивает финальный ответ целиком. Критерии:

• Faithfulness (фактическая точность) — каждый факт ответа должен быть выведен из retrieved-документов.
• Answer relevance (релевантность ответа) — ответ прямо отвечает на вопрос пользователя.
• Completeness (полнота) — не упущены ли важные аспекты.

Если end verifier бракует ответ, агент может:

• выполнить дополнительный поиск;
• перегенерировать ответ с другим промптом;
• передать запрос человеку (human-in-the-loop).

4. Как обучать verifier model?

Обычно верификатор обучается на размеченных данных: пары (вход, действие/ответ) с меткой «корректно» (1) или «некорректно» (0). Источники данных:

• Синтетическая генерация: берём корректные трассы агента и намеренно вносим ошибки (замена фактов, пропуск шагов, нерелевантные документы).
• Аннотация человеком: эксперты размечают реальные логи агента.
• Distillation из большой LLM: используем сильную LLM (GPT-4, Claude) как judge, чтобы разметить данные для маленькой модели.

Архитектура верификатора:

• BERT-based классификатор: берём [CLS] токен, добавляем линейный слой (2 класса). Быстро, хорошо для коротких текстов.
• Маленькая LLM (0.5B–1B): fine-tune с head для классификации или генерации оценки (например, «score: 0.85»). Гибче, может обрабатывать длинные контексты.

Пример fine-tuning BERT для step verifier:

from transformers import BertTokenizer, BertForSequenceClassification, Trainer, TrainingArguments

tokenizer = BertTokenizer.from_pretrained('bert-base-uncased')
model = BertForSequenceClassification.from_pretrained('bert-base-uncased', num_labels=2)

# Пример данных: (вопрос, действие агента) -> метка
train_texts = [
    ("Какая столица Франции?", "Поиск: столица Франции"),  # корректно -> 1
    ("Какая столица Франции?", "Поиск: население Парижа"), # некорректно -> 0
]
train_labels = [1, 0]

# Токенизация, Trainer, обучение...

5. Архитектура verifier: маленькая LLM, BERT, классификатор

Сравнение подходов:

Для step verifier обычно достаточно BERT (512 токенов покрывает шаг). Для end verifier, где контекст может быть длиннее (весь диалог + retrieved документы), лучше использовать маленькую LLM с поддержкой длинного контекста.

6. Интеграция verifier в пайплайн агента

Типичный цикл agentic RAG с verifier:

1. Планирование: агент получает вопрос, генерирует план шагов.
2. Шаг 1: агент выполняет действие (например, поиск).
3. Step verifier оценивает действие:
   • Если score > порога → продолжаем.
   • Если score < порога → агент корректирует действие или переходит к альтернативному плану.
4. Шаг 2, 3... — повтор с проверкой.
5. Генерация финального ответа.
6. End verifier оценивает ответ:
   • Если ответ принят → показываем пользователю.
   • Если ответ отклонён → агент запускает цикл улучшения (re-generation, дополнительный поиск) или эскалация человеку.

Код упрощённого цикла:

def agent_loop(question, max_steps=5):
    plan = planner(question)
    context = []
    for step in range(max_steps):
        action = agent.decide(question, context, plan)
        # Step verifier
        score = step_verifier(question, action, context)
        if score < 0.5:
            action = agent.correct_action(question, context, plan)
        result = execute_action(action)
        context.append(result)
    final_answer = generator.generate(question, context)
    # End verifier
    if end_verifier(question, final_answer, context) < 0.7:
        final_answer = agent.regenerate(question, context)
    return final_answer

7. Метрики для оценки verifier

Verifier сам нуждается в оценке. Основные метрики:

Важно: ложноположительные срабатывания (FP) — verifier бракует корректный ответ → лишние шаги, ухудшение UX. Ложноотрицательные (FN) — пропуск ошибки → пользователь видит некорректный ответ. Обычно порог настраивают так, чтобы recall был высоким (найти все ошибки) ценой некоторого количества FP.

8. Trade-offs: скорость vs качество, ложные срабатывания

• Скорость vs качество: BERT работает за миллисекунды, но может пропускать сложные логические ошибки. LLM-verifier (1B) точнее, но добавляет 100–500 мс к каждому шагу.
• Порог срабатывания: низкий порог → много ложных тревог (агент перепроверяет корректные шаги), высокий порог → пропуск ошибок. Оптимальный порог подбирается на валидационном датасете.
• Стоимость: даже маленькая LLM-verifier умножает затраты на количество шагов. Для production часто используют BERT или DistilBERT, а LLM-verifier только для end-проверки.

9. Пример кода: простой verifier на основе BERT

Допустим, мы хотим проверять, что retrieved-документ релевантен вопросу (step verifier для поиска).

from transformers import pipeline

# Загружаем предобученный BERT для NLI (Natural Language Inference)
# Модель типа "cross-encoder" для релевантности
verifier = pipeline("text-classification", model="cross-encoder/ms-marco-MiniLM-L-6-v2")

def step_verifier(question, retrieved_doc):
    # Модель возвращает score релевантности (0..1)
    result = verifier(f"{question} [SEP] {retrieved_doc}")
    score = result[0]['score'] if result[0]['label'] == 'RELEVANT' else 1 - result[0]['score']
    return score

# Пример
question = "Столица Франции"
doc = "Париж — столица Франции."
print(step_verifier(question, doc))  # ~0.98

Этот верификатор можно встроить в агента: если score < 0.3, документ нерелевантен — нужно переформулировать запрос.

10. Альтернативы verifier models

• Self-consistency: генерировать несколько ответов LLM и проверять согласованность. Дорого, но не требует отдельной модели.
• LLM-as-a-judge: использовать ту же или другую большую LLM для оценки (например, GPT-4 как judge). Точнее, но медленно и дорого.
• Reward model (из RLHF): обучена предсказывать предпочтения человека. Может использоваться как verifier, но обычно требует много данных.
• Rule-based проверки: регулярные выражения, проверка наличия ключевых слов, фактчекинг по базе знаний. Быстро, но негибко.

Verifier models занимают нишу между rule-based (дёшево, но грубо) и LLM-as-a-judge (дорого, но точно). Они оптимальны для production agentic RAG, где важны скорость и стоимость.

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

Задача: Реализовать agentic RAG для ответов на вопросы по документации Python, используя step verifier на основе BERT для проверки релевантности поисковых запросов.

Инструменты:

• LangChain или собственный агент на Python
• FAISS + sentence-transformers для retrieval
• BERT (cross-encoder/ms-marco-MiniLM) как verifier
• Streamlit для UI

Шаги:

1. Загрузите документацию Python (например, python-docs.txt), разбейте на чанки, создайте векторную БД.
2. Реализуйте агента, который по вопросу генерирует поисковый запрос, ищет чанки, синтезирует ответ.
3. Добавьте step verifier: после каждого поиска проверяйте, что хотя бы один из top-3 чанков релевантен вопросу (score > 0.5). Если нет — агент переформулирует запрос.
4. Добавьте end verifier: проверяйте faithfulness финального ответа (например, используя BERT NLI между ответом и чанками).
5. Сравните качество ответов с verifier и без него на 20 тестовых вопросах.

Ожидаемый результат: Вы увидите, что verifier снижает количество галлюцинаций (faithfulness повышается на 15–20%) и уменьшает число шагов агента за счёт раннего прерывания нерелевантных поисков.

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

Навигация

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