Публичные бенчмарки LLM дают ориентиры по общему уровню моделей, но не отвечают на вопрос, как они ведут себя в конкретной задаче. А прикладные сценарии чувствительны к деталям: формату входных данных, структуре ответа, требованиям к точности. В этих условиях различия между моделями становятся более заметными.
-
Даже у близких по классу моделей небольшие различия в архитектуре и обучении дают заметный разброс в качестве ответов.
-
Качество моделей сильно зависит от типа задачи — одни лучше следуют инструкциям, другие лучше формулируют текст, третьи реже галлюцинируют.
-
Одна и та же модель может быть сильной в reasoning-задачах и значительно слабее в саммаризации или QA.
В этой статье расскажем, как оценивали открытые модели для создания саммари записей встреч и поделимся метриками, которые отражают полезность результата для бизнес-процессов заказчика.
Содержание
Что мы сделали
Наш заказчик, компания 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 под конкретные продуктовые сценарии заказчика.
Если вам важно понять, как модели работают именно в вашем кейсе и какие из них оптимальны с точки зрения качества и инфраструктуры, давайте обсудим подход и подберем решение.
Больше кейсов — по ссылке.
Автор: JDTapp
