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

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

Проектирование бенчмарка для нового домена — это системный процесс, начинающийся с привлечения domain-экспертов (врачей, юристов) для построения таксономии задач (типов вопросов, сценариев). Затем генерируются синтетические задания с помощью LLM, которые проходят экспертную валидацию, и формируется human baseline (оценка человека). Финальный бенчмарк включает набор метрик (точность, полнота, faithfulness, безопасность) и учитывает специфику домена — например, в медицине критична безопасность, в юриспруденции — ссылки на нормативные акты.

1. Зачем нужен специализированный бенчмарк для нового домена

Универсальные бенчмарки (например, MMLU, Natural Questions) не отражают реальных потребностей узких доменов. В медицине и юриспруденции:

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

Бенчмарк позволяет объективно оценить, насколько RAG-система (или агент) справляется с задачами домена до выхода в продакшн.

2. Этап 1: Привлечение domain-экспертов и построение таксономии задач

Domain-эксперты — это специалисты с практическим опытом в предметной области (врачи, юристы, фармацевты). Их роль:

• Определить таксономию задач — иерархию типов вопросов и сценариев, которые система должна обрабатывать.
• Выделить критические сценарии (например, «острый инфаркт миокарда» в медицине или «составление искового заявления» в юриспруденции).
• Указать границы компетенции — что система не должна отвечать (например, постановка диагноза без осмотра).

Пример таксономии для медицины:

Для юриспруденции таксономия может включать: «Консультация по договорам», «Трудовые споры», «Налоговое право», «Процессуальные сроки» и т.д.

3. Этап 2: Генерация тестовых заданий (LLM + проверка экспертами)

На основе таксономии создаётся набор вопросов и ожидаемых ответов. Используется синтетическая генерация с помощью LLM (например, GPT-4, Claude) с последующей экспертной валидацией.

Процесс

1. Prompt engineering — эксперты пишут шаблоны промптов для каждого типа задач. Например:

   Сгенерируй 10 вопросов по теме "Диагностика сахарного диабета" для врачей общей практики. 
   Вопросы должны быть разной сложности: от базовых (определение) до сложных (дифференциальная диагностика).
   Для каждого вопроса укажи правильный ответ и ссылку на источник (клинические рекомендации).
   

2. Генерация — LLM создаёт черновик заданий. Важно контролировать разнообразие (чтобы не было дубликатов) и реалистичность (вопросы должны отражать реальные запросы пользователей).

3. Экспертная проверка — domain-эксперты оценивают каждое задание по критериям:

   • Корректность ответа.
   • Соответствие текущим стандартам (например, устаревшие лекарства недопустимы).
   • Отсутствие двусмысленности.
   • Наличие правильной ссылки на источник.

4. Итеративное улучшение — задания, не прошедшие проверку, отправляются на доработку (изменение промпта или ручное редактирование).

Пример кода для генерации (Python + OpenAI API):

import openai

def generate_questions(domain, topic, num=10):
    prompt = f"""
    Ты — эксперт в области {domain}. Сгенерируй {num} вопросов по теме "{topic}" для оценки RAG-системы.
    Каждый вопрос должен быть в формате JSON:
    {{"question": "...", "answer": "...", "source": "..."}}
    Вопросы должны быть разного уровня сложности.
    """
    response = openai.ChatCompletion.create(
        model="gpt-4",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.7
    )
    return response.choices[0].message.content

4. Этап 3: Human baseline (оценка человека)

baseline|Human baseline — это эталонные ответы, подготовленные экспертами. Он нужен для:

• Сравнения качества системы с человеческим уровнем.
• Калибровки метрик (например, если человек отвечает с точностью 95%, то система должна стремиться к этому уровню).
• Выявления сложных случаев, где даже эксперты расходятся во мнениях (тогда задание помечается как «спорное» и исключается из бенчмарка или оценивается отдельно).

Процесс

• Каждое задание даётся 2–3 экспертам независимо.
• Ответы сравниваются, вычисляется inter-annotator agreement (согласованность между экспертами) с помощью метрики Cohen's kappa или Fleiss' kappa.
• Задания с низкой согласованностью (kappa < 0.6) пересматриваются или удаляются.

5. Этап 4: Выбор метрик оценки

Метрики должны отражать как качество retrieval, так и качество генерации, а также доменные требования.

Для агентных сценариев (Agentic RAG) добавляются метрики Tool Use Accuracy (правильность вызова внешних инструментов) и Step Completion (доля успешно завершённых многошаговых задач).

6. Специфика домена: медицина

В медицинском бенчмарке особое внимание уделяется:

• Безопасности — ответы не должны содержать опасных рекомендаций. Вводится метрика Harmfulness Score (оценка вреда), которая вычисляется экспертами или через специальный LLM-классификатор.
• Актуальности — медицинские знания быстро устаревают. Бенчмарк должен регулярно обновляться (например, раз в квартал).
• Мультиязычности — если система работает с русскоязычными пациентами, нужны вопросы на русском с учётом локальных клинических рекомендаций.
• Конфиденциальности — тестовые задания не должны содержать реальные данные пациентов (используются синтетические кейсы).

Пример задания

Вопрос: Пациент 55 лет с жалобами на боль в груди, одышку, ЭКГ показывает подъём ST в отведениях V1-V4. 
Какой диагноз наиболее вероятен? Какие неотложные действия?
Ожидаемый ответ: Острый инфаркт миокарда передней стенки. Необходимо: 
1) Аспирин 300 мг разжевать, 2) Нитроглицерин сублингвально (при САД > 100), 
3) Вызвать скорую, 4) ЭКГ в динамике.
Источник: Клинические рекомендации Минздрава РФ по ОКС, 2023.

7. Специфика домена: юриспруденция

В юридическом бенчмарке акценты смещаются:

• Точность цитирования — каждый ответ должен ссылаться на конкретную статью закона, кодекса или судебную практику. Метрика Citation Accuracy становится основной.
• Консистентность — ответы на схожие вопросы не должны противоречить друг другу (особенно важно для договорного права).
• Учёт юрисдикции — бенчмарк должен явно указывать правовую систему (РФ, США, ЕС) и не смешивать нормы разных стран.
• Обработка неоднозначности — многие юридические вопросы не имеют однозначного ответа (зависит от обстоятельств). В бенчмарк включаются задания с «правильным ответом — анализом вариантов».

Пример задания

Вопрос: Работник написал заявление об увольнении по собственному желанию, но через 3 дня передумал. 
Может ли он отозвать заявление? Каков срок?
Ожидаемый ответ: Да, может отозвать заявление до истечения срока предупреждения (2 недели), 
если на его место ещё не приглашён другой работник в порядке перевода (ст. 80 ТК РФ).
Источник: Трудовой кодекс РФ, ст. 80.

8. Инструменты и фреймворки для построения бенчмарка

• LangSmith / LangFuse — позволяют логировать запросы к RAG-системе и вручную размечать правильные ответы, создавая датасет для бенчмарка.
• RAGAS — библиотека для автоматической оценки RAG, но её метрики нужно адаптировать под домен (например, заменить общий faithfulness на медицинский).
• OpenAI Evals — фреймворк для создания кастомных бенчмарков с поддержкой LLM-судей.
• Human-in-the-loop платформы (Label Studio, Prodigy) — для разметки данных экспертами.

9. Вызовы и лучшие практики

Вызовы

• Стоимость — привлечение domain-экспертов дорого (особенно в медицине). Решение: использовать краудсорсинг с верификацией (например, платформа Sama).
• Устаревание — бенчмарк нужно обновлять. Лучшая практика: версионировать бенчмарк и автоматически перезапускать тесты при обновлении базы знаний.
• Перекос (bias) — синтетические данные могут не покрывать редкие, но важные случаи. Решение: добавлять «крайние случаи» (edge cases) вручную.

Лучшие практики

• Начинать с малого (50–100 заданий) и расширять по мере валидации.
• Использовать stratified sampling — равномерно покрывать все категории таксономии.
• Включать adversarial examples — вопросы, на которые система склонна галлюцинировать (например, «Какое лекарство от COVID-19 самое эффективное?» — ответ должен ссылаться на отсутствие доказательств).
• Публиковать бенчмарк открыто (если позволяет конфиденциальность) для воспроизводимости.

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

Задача Разработать минимальный бенчмарк для оценки RAG-системы в домене «Семейное право РФ» (алименты, развод, опека).

Инструменты Python, OpenAI API, LangChain, Label Studio (или просто CSV).

Шаги:

1. Привлечь 1–2 юристов (можно через фриланс-биржи) для составления таксономии из 5 категорий (например, «Развод», «Алименты», «Опека», «Имущество», «Брачный договор»).
2. Сгенерировать 30 вопросов с помощью GPT-4, используя промпты с указанием статей Семейного кодекса РФ.
3. Провести экспертную проверку — юристы корректируют ответы и ссылки.
4. Собрать human baseline — каждый вопрос решается двумя юристами, вычисляется согласованность.
5. Реализовать простую RAG-систему (векторная БД FAISS + эмбеддинги + GPT-3.5-turbo) с загруженными текстами Семейного кодекса.
6. Прогнать бенчмарк — вычислить accuracy, faithfulness (через LLM-судью), citation accuracy.
7. Оформить отчёт — сравнить результаты системы с human baseline.

Ожидаемый результат Набор из 30 заданий с gold standard, скрипт для автоматического прогона, метрики (например, accuracy 0.75, faithfulness 0.85, citation accuracy 0.60). Выявить слабые места (например, система плохо цитирует конкретные статьи).

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

Навигация

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