EduMod-LLM: модульный подход к образовательным QA-системам

МОДУЛЬ 1: Выбор функции (какой источник использовать)
├── qa_retrieval — поиск по прошлым вопросам/ответам
├── textbook_retrieval — поиск по учебнику
├── assignment_retrieval — поиск по заданиям
└── logistics_retrieval — поиск по политикам курса

МОДУЛЬ 2: Поиск (как найти контент)
├── Иерархический — дерево: оглавление → главы → разделы → чанки
└── Векторный — эмбеддинги + семантическая близость

МОДУЛЬ 3: Генерация ответа (какая LLM отвечает)

МОДУЛЬ 4: LLM-оценка (проверка качества)
├── Factuality (1-5) — фактическая точность
├── Relevance (1-5) — релевантность вопросу
└── Style (1-3) — стиль и педагогичность

Это архитектура системы, а не промпт-техника. Пользователь чата может взять только принцип LLM-оценки и структурирования контекста.

Задача: Ты написал черновик ответа клиенту и хочешь проверить качество перед отправкой.

Промпт:

Ты — эксперт по оценке клиентских коммуникаций. 

Оцени этот ответ по трём критериям:
1. Фактическая точность (1-5): верна ли информация?
2. Релевантность (1-5): отвечает ли на вопрос клиента?
3. Тон (1-3): вежливый, профессиональный, без агрессии?

Вопрос клиента:
"Почему заказ задерживается? Обещали доставку 15-го, сегодня 18-е."

Мой черновик ответа:
"Добрый день! Извиняемся за задержку. Ваш заказ был отправлен 16-го числа, текущий статус — в пути. Ожидаемая доставка — 19-20 января. Отслеживание: [ссылка]. Если не придёт до 21-го — напишите, оформим компенсацию."

Выдай оценку в формате:
{"factuality": X, "relevance": X, "style": X}
Затем кратко объясни каждую оценку.

Результат: Модель выдаст числовые оценки по каждому критерию и объяснение. Ты увидишь слабые места до отправки.

Задача: Даёшь Claude длинный документ (договор, регламент, техзадание) и хочешь точный ответ на вопрос.

Промпт:

Вот структура документа (оглавление):

## Оглавление
1. Предмет договора
2. Права и обязанности сторон
   2.1. Права Заказчика
   2.2. Обязанности Исполнителя
3. Сроки и порядок оплаты
4. Ответственность сторон
5. Форс-мажор

---

## Полный текст

[Весь текст договора с теми же заголовками]

---

Вопрос: Какие штрафы предусмотрены за нарушение сроков со стороны Исполнителя?

Результат: Модель сначала определит релевантный раздел (4. Ответственность сторон), затем найдёт конкретный пункт про штрафы. Точность выше, чем если дать «стену текста» без структуры.

LLM-оценка по рубрикам работает потому, что модели хорошо следуют структурированным инструкциям. Когда есть чёткие критерии и шкала, модель не «придумывает» — она сопоставляет текст с критериями. Исследование показало: модели без «reasoning» (DeepSeek-V3) лучше справляются с такой оценкой, чем reasoning-модели. Причина — им не нужно «думать», им нужно сравнивать.

Иерархическая структура помогает потому, что LLM обрабатывает текст последовательно. Оглавление в начале — это «карта» для модели. Она сначала понимает структуру, потом находит нужный раздел. Без структуры модель сканирует весь текст линейно и может пропустить релевантный фрагмент в середине.

Рычаги управления:

• Детализация рубрики — чем конкретнее критерии, тем точнее оценка
• Шкала — 1-5 даёт гранулярность, 1-3 проще для субъективных критериев
• Глубина иерархии — для коротких документов достаточно 2 уровня, для длинных — 3-4

Ты — эксперт по оценке {тип контента}. 

Оцени этот {объект оценки} по критериям:
1. {Критерий 1} ({шкала}): {что измеряет}
2. {Критерий 2} ({шкала}): {что измеряет}
3. {Критерий 3} ({шкала}): {что измеряет}

{Контекст / вопрос}:
{текст}

{Оцениваемый объект}:
{текст}

Выдай оценку в формате:
{"{критерий_1}": X, "{критерий_2}": X, "{критерий_3}": X}
Затем кратко объясни каждую оценку.

Подстановки:

• {тип контента} — «клиентских коммуникаций», «технической документации», «маркетинговых текстов»
• {критерии} — конкретные аспекты качества для твоей задачи
• {шкала} — 1-5 для объективных, 1-3 для субъективных критериев

⚠️ Не для обычного пользователя чата: Основная часть исследования — про построение систем с function calling API, индексацией документов, пайплайнами. Требует кода и инфраструктуры.

⚠️ Узкий контекст: Тестировали на одном курсе по data science в одном университете. Переносимость на другие домены не проверена.

⚠️ Proprietary API: Эксперименты с GPT-4o, GPT-4.1, DeepSeek — результаты могут измениться с обновлением моделей.

Команда из Berkeley и CMU взяла 1000 реальных вопросов студентов с форума EdSTEM курса по data science. Вопросы охватывали 17 недель: от концептуальных («что такое градиентный спуск») до логистических («когда дедлайн»).

Дизайн эксперимента: изолировали каждый модуль и меняли только один компонент. Например, фиксировали retrieval и LLM, меняли только стратегию function calling — и сравнивали результаты.

Валидация LLM-судьи: 180 ответов оценили два эксперта-TA (магистр и PhD с многолетним опытом). Достигли 70-85% согласия между экспертами. Затем сравнили оценки разных LLM с экспертными — DeepSeek-V3 показал 90% совпадение по критерию «фактичность».

Главный сюрприз: иерархический retrieval обогнал топовые embedding-модели из бенчмарка MTEB на ~30%. Структура документа оказалась важнее семантической близости эмбеддингов. Ещё один инсайт: reasoning-модели (DeepSeek-R1, o4-mini) НЕ превзошли обычные LLM в генерации ответов — для образовательного QA важнее следование контексту, чем «глубокое думание».

Работа: EduMod-LLM: A Modular Approach for Designing Flexible and Transparent Educational Assistants

Авторы: Meenakshi Mittal, Rishi Khare, Mihran Miroyan (UC Berkeley), Chancharik Mitra (CMU), Narges Norouzi (UC Berkeley)

Сайт проекта: https://chancharikmitra.github.io/EduMod-LLM-website/