|
Professor Seleznov
|
Публичные бенчмарки LLM дают ориентиры по общему уровню моделей, но не отвечают на вопрос, как они ведут себя в конкретной задаче. А прикладные сценарии чувствительны к деталям: формату входных данных, структуре ответа, требованиям к точности. В этих условиях различия между моделями становятся более заметными.
В этой статье расскажем, как оценивали открытые модели для создания саммари записей встреч и поделимся метриками, которые отражают полезность результата для бизнес-процессов заказчика.
Содержание
Что мы сделали
Наш заказчик, компания FollowUP, создаёт сервис для автоматического протоколирования и анализа рабочих встреч. Команде разработчиков Doubletapp нужно было разработать систему, которая позволяет сравнивать open-source LLMв рамках конкретной бизнес-задачи — генерации саммари.
Как это работает
Мы заменили универсальные бенчмарки на прикладную систему оценки, заточенную под корпоративные данные.
Оценка качества строится по двум направлениям:
Полнота саммари
Для каждой транскрипции автоматически формируется набор контрольных вопросов:
- какие задачи обсуждались,
- какие решения были приняты,
- какие договорённости зафиксированы.
Далее проверяется, насколько саммари покрывает эти вопросы.
Так мы измеряем прикладную полезность текста — можно ли из него восстанавливать содержание встречи.
Достоверность
Из саммари выделяются ключевые утверждения и сопоставляются с исходной транскрипцией.
Это позволяет:
- фиксировать галлюцинации,
- проверять фактическую точность,
- контролировать риск искажения договорённостей.
Изначально рассматривались готовые решения оценки (включая RAGAS), но они оказались недостаточно точными в генерации вопросов именно под контекст деловых коммуникаций.
Поэтому мы разработали собственную методику — она учитывает специфику разговорных данных, лучше отражает бизнес-смысл встречи и даёт стабильную сравнимость моделей.
Как это устроено технически
Под капотом — повторяемый процесс из четырёх шагов:
- Берем набор транскрипций, собранных из различных открытых источников.
- Прогоняем через них тестируемую модель и получаем саммари. В одной и той же системе сравниваем и локальные открытые модели (Qwen, Mistral, Llama, Gemma), и коммерческие API (GPT-5, GPT-4.1) — для нас это просто разные источники саммари.
- По каждой транскрипции отдельно более сильная модель-судья (GPT-4.1 на момент работы) готовит набор контрольных вопросов и отдельно разбирает саммари на список утверждений.
- Считаем по каждой модели две метрики — полноту и достоверность — и сводим в общую таблицу.
Ниже рассмотрим, как именно получить полноту и достоверность в нашей задаче.
Полнота (Recall)
Мы оцениваем полноту по конкретным разделам, которые важны в протоколе встречи. Проанализировав реальные запросы клиента к моделям, мы выделили четыре таких раздела:
- задачи (что и кому поручено),
- решения (что зафиксировано),
- участники (кто был и в каких ролях),
- отложенные вопросы (что вынесено за рамки встречи).
Под каждый раздел у нас свой шаблон промпта. По нему сильная LLM генерирует Yes/No-вопросы, в которых корректный ответ для качественного саммари — «Да».
Например:
Упоминается ли в саммари, что Андрей должен провести онбординг для Елены по использованию бота для рассылок?
Затем вторая LLM смотрит на саммари и отвечает по каждому вопросу: Yes / No / Partially. Recall считается как (Yes + 0.5 · Partially) / N. Частичный ответ важен — на практике саммари часто упоминает задачу, но теряет ответственного или срок, и это полезно отличать от полного пропуска.
Достоверность (Precision)
Здесь обратная процедура. LLM-судья разбивает саммари, полученное от проверяемой модели, на список отдельных утверждений, и каждое утверждение сверяется с исходной транскрипцией: 1 — подтверждается, 0 — не подтверждается. Precision = доля подтверждённых утверждений, то есть прямое измерение доли галлюцинаций.
Пример отказа из реального прогона.
Утверждение саммари: «Предложения и рекомендации: внедрение программного обеспечения для отслеживания финансовых потоков, изучение опыта других инвесторов в аналогичных проектах».
Вердикт: 0. «В расшифровке обсуждалось внедрение софта, но не упоминалось изучение опыта других инвесторов».
Что показал прогон на 432 встречах:
| Модель |
Параметров, B |
Квантование, бит |
Recall |
Precision |
F1 |
| GPT-4.1 |
— |
— |
0.655 |
0.966 |
0.781 |
| Qwen2.5-72B-Instruct GPTQ-Int4 |
72 |
4 |
0.479 |
0.947 |
0.637 |
| Mistral-Small-3.1-24B-Instruct-2503 |
24 |
16 |
0.438 |
0.894 |
0.588 |
| Mistral-Small-3.1-24B Q8 (GGUF) |
24 |
8 |
0.429 |
0.921 |
0.585 |
| Mistral-Small-3.1-24B Q4_K_M (GGUF) |
24 |
4 |
0.424 |
0.917 |
0.580 |
| GPT-4o |
— |
— |
0.378 |
0.934 |
0.538 |
| Qwen2.5-32B-Instruct GPTQ-Int8 |
32 |
8 |
0.373 |
0.899 |
0.527 |
| Qwen2.5-32B-Instruct GPTQ-Int4 |
32 |
4 |
0.351 |
0.912 |
0.507 |
| gemma-3-27b-it qat-q4_0 (GGUF) |
27 |
4 |
0.338 |
0.845 |
0.483 |
| Qwen2.5-7B-Instruct GPTQ-Int4 |
7 |
4 |
0.301 |
0.836 |
0.443 |
| Llama-3.3-70B-Instruct Q4_K_M |
70 |
4 |
0.245 |
0.874 |
0.383 |
Результаты проприетарных моделей (GPT-4.1, GPT-4o) приведены здесь для сравнения и калибровки шкалы — основная задача проекта была выбрать опенсорс-модель, которую можно развернуть у клиента в контуре.
Несколько наблюдений, которые без такой системы оценки увидеть было бы нечем:
- Размер сам по себе ничего не гарантирует. Llama-3.3-70B на этой задаче проигрывает по recall даже Qwen-7B — то есть «выбрать модель пожирнее» не работает.
- Квантование почти не съедает качество в семействе Mistral-Small-3.1: переход с FP16 на Q8 и далее на Q4 даёт разницу в третьем знаке. Практический вывод: 24B-модель в Q4_K_M помещается на одну консьюмерскую 4090 и при этом сохраняет precision 0.917.
- Лучший открытый вариант — Qwen2.5-72B-Int4 — догоняет еще актуальную на момент исследования GPT-4o по precision (0.947 против 0.934) и заметно обгоняет по recall (0.479 против 0.378), укладываясь при этом в 2×A100 40GB.
- Цифры подтверждают адекватность методики. Внутри одного семейства метрики снижаются плавно и предсказуемо при уменьшении размера и битности (Qwen 72B → 32B → 7B; Mistral Q8 → Q4). Это тот результат, который и должен получиться, если система оценки действительно измеряет качество, а не шум — то есть бенчмарку можно доверять и для сравнения моделей из разных семейств.
Результат
Вместо разового сравнения моделей бизнес получил систему, которая позволяет:
- регулярно сравнивать open-source LLM между собой,
- выбирать модель под конкретную задачу,
- снижать риск внедрения модели с скрытыми проблемами качества,
- встроить оценку качества прямо в процесс развития продукта.
В Doubletapp мы проектируем и внедряем системы оценки LLM под конкретные продуктовые сценарии заказчика.
Если вам важно понять, как модели работают именно в вашем кейсе и какие из них оптимальны с точки зрения качества и инфраструктуры, давайте обсудим подход и подберем решение.
Больше кейсов — по ссылке.
-Источник
|
