Публичные бенчмарки LLM дают ориентиры по общему уровню моделей, но не отвечают на вопрос, как они ведут себя в конкретной задаче. А прикладные сценарии чувствительны к деталям: формату входных данных, структуре ответа, требованиям к точности. В этих условиях различия между моделями становятся более заметными.

• Даже у близких по классу моделей небольшие различия в архитектуре и обучении дают заметный разброс в качестве ответов.

• Качество моделей сильно зависит от типа задачи — одни лучше следуют инструкциям, другие лучше формулируют текст, третьи реже галлюцинируют.

• Одна и та же модель может быть сильной в reasoning-задачах и значительно слабее в саммаризации или QA.

В этой статье расскажем, как оценивали открытые модели для создания саммари записей встреч и поделимся метриками, которые отражают полезность результата для бизнес-процессов заказчика.

Содержание

• Что мы сделали

• Как это работает

• Как это устроено технически

• Результат

Что мы сделали

Наш заказчик, компания FollowUP, создаёт сервис для автоматического протоколирования и анализа рабочих встреч. Команде разработчиков Doubletapp нужно было разработать систему, которая позволяет сравнивать open-source LLM в рамках конкретной бизнес-задачи — генерации саммари.

Как это работает

Мы заменили универсальные бенчмарки на прикладную систему оценки, заточенную под корпоративные данные.

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

Полнота саммари

Для каждой транскрипции автоматически формируется набор контрольных вопросов:

• какие задачи обсуждались,

• какие решения были приняты,

• какие договорённости зафиксированы.

Далее проверяется, насколько саммари покрывает эти вопросы.
Так мы измеряем прикладную полезность текста — можно ли из него восстанавливать содержание встречи.

Достоверность

Из саммари выделяются ключевые утверждения и сопоставляются с исходной транскрипцией.

Это позволяет:

• фиксировать галлюцинации,

• проверять фактическую точность,

• контролировать риск искажения договорённостей.

Изначально рассматривались готовые решения оценки (включая RAGAS), но они оказались недостаточно точными в генерации вопросов именно под контекст деловых коммуникаций.

Поэтому мы разработали собственную методику — она учитывает специфику разговорных данных, лучше отражает бизнес-смысл встречи и даёт стабильную сравнимость моделей.

Как это устроено технически

Под капотом — повторяемый процесс из четырёх шагов:

1. Берем набор транскрипций, собранных из различных открытых источников.

2. Прогоняем через них тестируемую модель и получаем саммари. В одной и той же системе сравниваем и локальные открытые модели (Qwen, Mistral, Llama, Gemma), и коммерческие API (GPT-5, GPT-4.1) — для нас это просто разные источники саммари.

3. По каждой транскрипции отдельно более сильная модель-судья (GPT-4.1 на момент работы) готовит набор контрольных вопросов и отдельно разбирает саммари на список утверждений.

4. Считаем по каждой модели две метрики — полноту и достоверность — и сводим в общую таблицу.

Ниже рассмотрим, как именно получить полноту и достоверность в нашей задаче.

Полнота (Recall)

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

• задачи (что и кому поручено),

• решения (что зафиксировано),

• участники (кто был и в каких ролях),

• отложенные вопросы (что вынесено за рамки встречи).

Под каждый раздел у нас свой шаблон промпта. По нему сильная LLM генерирует Yes/No-вопросы, в которых корректный ответ для качественного саммари — «Да».

Например:
Упоминается ли в саммари, что Андрей должен провести онбординг для Елены по использованию бота для рассылок?

Затем вторая LLM смотрит на саммари и отвечает по каждому вопросу: Yes / No / Partially. Recall считается как (Yes + 0.5 · Partially) / N. Частичный ответ важен — на практике саммари часто упоминает задачу, но теряет ответственного или срок, и это полезно отличать от полного пропуска.

Достоверность (Precision) 

Здесь обратная процедура. LLM-судья разбивает саммари, полученное от проверяемой модели, на список отдельных утверждений, и каждое утверждение сверяется с исходной транскрипцией: 1 — подтверждается, 0 — не подтверждается. Precision = доля подтверждённых утверждений, то есть прямое измерение доли галлюцинаций.

Пример отказа из реального прогона.
Утверждение саммари: «Предложения и рекомендации: внедрение программного обеспечения для отслеживания финансовых потоков, изучение опыта других инвесторов в аналогичных проектах».
Вердикт: 0. «В расшифровке обсуждалось внедрение софта, но не упоминалось изучение опыта других инвесторов».

Что показал прогон на 432 встречах:

Результаты проприетарных моделей (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 под конкретные продуктовые сценарии заказчика.

Если вам важно понять, как модели работают именно в вашем кейсе и какие из них оптимальны с точки зрения качества и инфраструктуры, давайте обсудим подход и подберем решение.

Больше кейсов — по ссылке.