Публичные бенчмарки 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 под конкретные продуктовые сценарии заказчика.
Если вам важно понять, как модели работают именно в вашем кейсе и какие из них оптимальны с точки зрения качества и инфраструктуры, давайте обсудим подход и подберем решение.
Больше кейсов — по ссылке.
