Как вы проектируете бенчмарк для нового домена (медицина, юриспруденция)?

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

Проектирование бенчмарка для нового домена требует системного подхода: сначала строится таксономия задач (факты, рассуждение, анализ), затем с помощью LLM и экспертов генерируются задания, устанавливается human baseline (качество ответов человека), выбираются метрики (accuracy, F1, expert agreement), обеспечивается статистическая значимость (минимум 500 примеров) и честное сравнение через holdout (20% данных никогда не публикуются). Для доменов с высокой ответственностью (медицина, юриспруденция) критична экспертная валидация и оценка faithfulness (верность фактам).

1. Термин: Бенчмарк (Benchmark)

Бенчмарк — это стандартизированный набор тестовых заданий (вопросов, промптов, сценариев), используемый для объективной оценки качества модели или RAG-системы. В отличие от общих бенчмарков (MMLU, HumanEval), доменный бенчмарк учитывает специфику предметной области: терминологию, типичные ошибки, требования к точности и юридической/медицинской корректности.

Зачем нужен доменный бенчмарк

• Общие бенчмарки не покрывают узкие сценарии (например, интерпретация медицинских анализов или статей закона).
• Позволяет выявить систематические ошибки модели в конкретном домене.
• Служит основой для сравнения разных подходов (RAG, fine-tuning, agentic RAG) в одном контексте.

2. Шаг 1: Таксономия задач (Taxonomy)

Первый этап — определить типы вопросов, которые будут в бенчмарке. Для каждого домена таксономия своя, но можно выделить общие категории:

Для Agentic RAG особенно важны multi-step задачи, так как они проверяют способность агента планировать и использовать инструменты.

Как строить таксономию

• Интервью с экспертами домена (врачи, юристы).
• Анализ реальных запросов пользователей (если есть лог).
• Кластеризация типов вопросов из существующих датасетов (PubMedQA, LegalBench).

3. Шаг 2: Генерация заданий (Task Generation)

После таксономии нужно создать сами задания. Рекомендуется гибридный подход: LLM генерирует черновики, эксперты проверяют и корректируют.

Процесс

1. Подготовка промпта для LLM (например, GPT-4, Claude). Промпт должен содержать:
   • Описание домена и типа задачи.
   • Примеры (few-shot).
   • Требования к формату: вопрос, правильный ответ, контекст (если нужен), эталонный ответ.
2. Генерация — LLM создаёт 2-3x больше заданий, чем нужно (для отбраковки).
3. Экспертная валидация — минимум два эксперта проверяют каждое задание на:
   • Корректность фактов.
   • Однозначность вопроса.
   • Наличие единственного правильного ответа (для закрытых вопросов).
4. Итерация — если много заданий отбраковано, уточняем промпт или добавляем примеры.

Пример промпта для генерации медицинского вопроса (факты):

Ты — медицинский эксперт. Сгенерируй 10 вопросов по фармакологии для оценки RAG-системы.
Формат каждого вопроса:
- Вопрос: ...
- Правильный ответ: ...
- Источник (название документа): ...

Требования:
- Вопросы должны быть фактологическими (дозировки, противопоказания).
- Ответ должен быть однозначным.
- Избегай вопросов, требующих субъективного мнения.

Контроль качества

• Используйте inter-annotator agreement (Cohen's Kappa) для оценки согласованности экспертов.
• Если Kappa < 0.7, пересмотрите инструкции или замените экспертов.

4. Шаг 3: Human Baseline

Human baseline — это производительность человека на том же наборе заданий. Он нужен для:

• Понимания верхней границы качества (человек vs модель).
• Выявления заданий, которые слишком сложны или неоднозначны.

Как измерить

• Привлеките 3-5 экспертов домена.
• Каждый эксперт отвечает на все вопросы (или подмножество).
• Замерьте accuracy (доля правильных ответов) и время ответа.
• Для субъективных задач (анализ, рассуждение) используйте экспертное согласие (majority vote).

Пример: В медицинском бенчмарке MedQA (USMLE) human baseline ~87% accuracy. Если ваша модель показывает 70%, это сигнал к улучшению.

5. Шаг 4: Метрики (Metrics)

Выбор метрик зависит от типа задач. Для доменного бенчмарка используйте комбинацию:

Для Agentic RAG дополнительно:

• Task Success Rate — доля успешно завершённых multi-step сценариев.
• Tool Call Accuracy — правильность вызова инструментов.
• Self-Correction Rate — способность агента исправить ошибку после неудачного шага.

Формула Faithfulness (пример на Python):

def faithfulness_score(generated_answer, retrieved_docs):
    # Используем LLM-судью для проверки каждого утверждения
    prompt = f"""Проверь, подтверждается ли каждое утверждение в ответе документами.
    Ответ: {generated_answer}
    Документы: {retrieved_docs}
    Верни долю подтверждённых утверждений (0.0 - 1.0)."""
    score = llm_judge(prompt)
    return float(score)

6. Шаг 5: Размер выборки (Sample Size)

Для статистической значимости минимальный размер бенчмарка — 500 примеров. Это эмпирическое правило, основанное на центральной предельной теореме: при n ≥ 30 распределение среднего приближается к нормальному, но для надёжного сравнения моделей нужно больше.

Расчёт точности

• Желаемая погрешность (margin of error) — например, ±2%.
• Используйте формулу: n = (Z² * p * (1-p)) / E², где Z = 1.96 (для 95% доверительного интервала), p = ожидаемая accuracy (0.8), E = погрешность (0.02).
• n ≈ (1.96² * 0.8 * 0.2) / 0.02² ≈ 1537. Но 500 — разумный компромисс для старта.

Стратификация убедитесь, что в бенчмарке пропорционально представлены все типы задач из таксономии.

7. Шаг 6: Holdout и тестовый split

Holdout — это часть данных (обычно 20%), которая никогда не публикуется и не используется для настройки моделей. Она остаётся у организатора бенчмарка для финальной оценки.

Зачем

• Предотвращает overfitting (подгонку под публичные данные).
• Обеспечивает честное сравнение разных систем (никто не может «натаскать» модель на тестовые вопросы).

Практика

• Разделите данные: 80% — публичный train/validation, 20% — приватный test.
• Публикуйте только train и validation (с ответами). Test — только для финального ранжирования.
• Для Agentic RAG holdout может включать цепочки multi-step сценариев, чтобы избежать утечки.

8. Учёт специфики Agentic RAG

В контексте Agentic RAG бенчмарк должен оценивать не только качество ответа, но и процесс:

• Планирование — правильная последовательность шагов.
• Использование инструментов — вызов правильного API, базы данных.
• Self-correction — способность перепланировать при ошибке.

Пример метрики для агента

def agent_success_rate(scenario, agent):
    # scenario: список шагов с ожидаемыми действиями
    steps = scenario['steps']
    agent_trace = agent.run(scenario['initial_query'])
    correct_steps = 0
    for expected, actual in zip(steps, agent_trace):
        if expected['action'] == actual['action'] and expected['result'] == actual['result']:
            correct_steps += 1
    return correct_steps / len(steps)

9. Инструменты и фреймворки

10. Пример: Медицинский бенчмарк

Домен Кардиология. Таксономия

• Факты: дозировки, противопоказания.
• Рассуждение: диагностика по симптомам.
• Анализ: сравнение клинических рекомендаций. Генерация LLM + 2 кардиолога. Размер 600 вопросов (200 каждого типа). Human baseline: 85% accuracy (3 эксперта). Метрики: accuracy, F1, faithfulness. Holdout: 120 вопросов.

11. Пример: Юридический бенчмарк

Домен GDPR (General Data Protection Regulation). Таксономия

• Факты: сроки уведомления об утечке.
• Рассуждение: применимость статьи к конкретному случаю.
• Анализ: оценка compliance программы. Генерация LLM + юристы по защите данных. Размер 500 вопросов. Human baseline: 78% accuracy. Метрики: accuracy, expert agreement, faithfulness. Holdout: 100 вопросов.

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

Задача Разработать бенчмарк для оценки RAG-системы в домене юридических вопросов по GDPR.

Инструменты

• Python (pandas, scikit-learn).
• LLM (GPT-4) для генерации черновиков.
• LangSmith для логирования.
• 2 юриста-фрилансера для валидации.

Шаги:

1. Составьте таксономию: 3 типа (факты, рассуждение, анализ), по 50 вопросов каждого типа.
2. Напишите промпт для генерации 200 вопросов (с запасом).
3. Отфильтруйте через юристов: оставьте 150 качественных.
4. Соберите human baseline: попросите юристов ответить на все 150 вопросов.
5. Разделите: 120 публичных, 30 holdout.
6. Реализуйте метрики: accuracy, faithfulness (через LLM-судью), expert agreement.
7. Запустите оценку на простой RAG-системе (например, LangChain + ChromaDB).
8. Ожидаемый результат: accuracy ~70-80%, faithfulness ~0.9, agreement с экспертами ~0.8.

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

Навигация

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