Большие языковые модели: статистика параметров и точности ответов

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

Для enterprise-систем вопрос формулируется иначе. Не «какая LLM умнее», а какая конфигурация выполняет конкретный workload в заданных границах latency, стоимости, privacy и допустимой доли ошибок. Количество параметров нейросетей остаётся значимым признаком. Но это только один параметр в длинной цепочке: архитектура, обучающие данные, post-training, контекст, retrieval, tool use, формат промпта и контур валидации.

Закрытые модели добавляют ещё одно ограничение. OpenAI в техническом отчёте GPT-4 не раскрыла размер модели, объём training compute, состав датасета и метод обучения. Любые точные оценки числа параметров GPT-4 вне заявления разработчика остаются предположениями. Строить архитектурное решение на предположении нельзя.

Масштаб модели не является метрикой качества

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

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

• Capacity. Сколько паттернов способна аппроксимировать архитектура при заданном training regime.
• Training corpus. Объём, качество, языковое распределение и дедупликация данных. Модель может быть крупной, но слабо покрывать домен организации.
• Post-training. Instruction tuning, RLHF, preference optimization, safety alignment. Эти этапы меняют поведение в диалоге сильнее, чем формальный размер базовой модели.
• Inference policy. Temperature, top-p, system prompt, structured output, retries, function calling.
• Product contour. RAG, доступ к корпоративным источникам, ACL, валидаторы, human-in-the-loop, журналирование.

Meta указывает для Llama 3.1 405B 405 млрд параметров, контекст до 128 тыс. токенов и обучение на более чем 15 трлн токенов. Для обучения использовалось более 16 тыс. GPU NVIDIA H100. Это масштабная dense-модель. Но из этих характеристик не следует, что она лучше справится с конкретной операцией: классификацией обращений, извлечением полей из договора, подготовкой SQL или суммаризацией базы знаний.

В прикладном контуре эффективность LLM в задачах измеряется иначе:

• точностью извлечения по размеченной выборке;
• долей ответов с подтверждёнными цитатами из разрешённых источников;
• процентом нарушений JSON schema;
• p50, p95 и p99 latency;
• token cost на завершённую бизнес-операцию;
• долей эскалаций оператору;
• частотой критических ошибок, разделённых по severity.

Если бот отвечает на 94% типовых вопросов, но в 2% случаев уверенно выдумывает условия договора, средняя «точность» не описывает риск. Нужна отдельная метрика для high-impact ошибок и механизм отказа от ответа при недостаточности контекста.

Параметры определяют capacity. Эксплуатационное качество определяет весь pipeline.

Dense и Mixture-of-Experts: одинаковые цифры не означают одинаковую стоимость

Архитектура современных LLM не сводится к линейному росту dense-моделей. На практике различие между dense и Mixture-of-Experts влияет на GPU footprint, throughput, routing и стоимость инференса.

У dense-модели на каждом токене участвует весь набор параметров. У MoE-модели router выбирает часть экспертных блоков. Поэтому следует разделять общее число параметров и активное число параметров на токен.

Mixtral 8x7B — показательный пример. Суммарно модель располагает примерно 47 млрд параметров, но в инференсе на токен задействуется около 13 млрд активных параметров. Называть её просто «47B-моделью» недостаточно. Для планирования compute это создаёт ложную картину.

MoE не является автоматической оптимизацией. Система получает более сложный runtime. Нужно учитывать балансировку экспертов, batch composition, размещение весов в памяти, совместимость с inference engine и фактическую загрузку accelerator pool. На k8s это напрямую влияет на autoscaling: метрика GPU utilization без оценки queue time и p95 latency малоинформативна.

Dense-модель, в свою очередь, не означает неэффективность. Для ограниченного use case компактная instruction-tuned модель с retrieval часто даёт более прогнозируемый результат, чем крупная универсальная LLM без доступа к актуальным данным.

Это особенно заметно в корпоративных системах. Если задача сводится к ответу по внутреннему регламенту, ключевой актив — не число параметров, а точный retrieval, свежий индекс, корректное разбиение документов, metadata filtering и обязательная ссылка ответа на найденный фрагмент. Модель в таком контуре — генератор интерфейса к данным, а не источник истины.

MMLU, HumanEval и GSM8K измеряют разные системы навыков

Сравнение производительности языковых моделей часто сводят к одному числу в презентации. Методологически это неверно.

GPT-4 в техническом отчёте показала 86,4% на MMLU при five-shot evaluation, 67,0% на HumanEval в zero-shot-режиме и 92,0% на GSM8K при five-shot chain-of-thought. Эти результаты нельзя усреднять и нельзя называть общей «точностью GPT-4».

Причина проста: бенчмарки проверяют разные операции.

MMLU включает математику, информатику, историю США, право и другие области. Базовая метрика — exact match для вопроса с вариантами ответа. Это полезный стандартизированный сигнал, но не аналог production workload.

В реальной системе модель получает иной ввод:

• длинные документы с противоречиями;
• сокращения, внутренние коды, табличные данные;
• неполный контекст;
• запросы на русском языке;
• требования не генерировать текст, а вернуть строгое поле в API contract;
• необходимость отказа от ответа, а не выбора наиболее вероятного продолжения.

Поддержка контекста 128 тыс. токенов также не является гарантией работы с длинным документом. Возможность принять input и способность корректно использовать сведения из его середины — разные свойства. Модель может технически обработать файл, но потерять существенное условие в массиве текста, неверно связать две версии документа или приоритизировать повторяющуюся формулировку.

Поэтому тестирование long-context use case должно включать контролируемые задачи: поиск конкретного положения, сопоставление версий, выявление противоречий, извлечение значений из удалённых частей документа. Измеряется не заявленный context window, а recall фактов, precision выводов и деградация метрик при росте длины input.

Отдельный слой — язык. Публичные показатели MMLU преимущественно относятся к англоязычному академическому тесту. Они не подтверждают сопоставимое качество для русскоязычных юридических, финансовых или отраслевых запросов. Если система используется для обучения сотрудников, различие форматов входного материала тоже меняет результат: даже сравнение онлайн, офлайн и гибридного обучения показывает, что режим взаимодействия с контентом влияет на процесс, а не только на формальную программу.

Воспроизводимость важнее маркетингового score

Даже корректный бенчмарк не существует вне методики запуска. Prompt template, few-shot examples, порядок ответов, decoding policy, версия API и способ извлечения финального варианта меняют итоговый score.

Стандартизированные повторные измерения в HELM фиксировали для отдельных моделей расхождение до 5 процентных пунктов между заявленными разработчиком результатами MMLU и независимыми значениями. Это не обязательно признак некорректности исходного отчёта. Чаще это следствие различий в evaluation harness:

• иной формат промпта;
• иная обработка вариантов ответа;
• изменения API или model snapshot;
• ограничения endpoint;
• отличие в правилах normalisation результата.

Для архитектурного комитета это означает одно: vendor benchmark не должен быть gate-критерием закупки. Он допустим как первичный фильтр. Финальное решение принимается по собственному evaluation set, зафиксированному до пилота.

Минимальный набор для такого набора данных:

1. Репрезентативные запросы. Не демонстрационные примеры, а обезличенные операции из production: тикеты, письма, договоры, knowledge base, фрагменты кода.

2. Негативные кейсы. Вопросы без ответа в разрешённых источниках, конфликтующие документы, неполные данные, prompt injection в приложениях.

3. Градация последствий. Ошибка в стиле ответа и ошибка в реквизите платежа не имеют равный вес.

4. Фиксированный runtime. Версия модели, system prompt, temperature, RAG pipeline, chunking, reranker, tool schema.

5. Независимая разметка. Качество оценивает не команда, которая проектировала prompt.

6. Регрессионный прогон. Каждый change в модели, индексе, embedding-модели или orchestration проходит через CI/CD evaluation stage.

Внутренний eval должен храниться как тестовый актив. Сырые запросы — с контролем доступа. Разметка — версионируемая. Метрики — разложенные по языку, типу задачи, источнику данных и критичности. Один общий score скрывает деградации.

Confabulation нельзя устранить масштабированием

NIST определяет confabulation как генерацию и уверенную подачу ошибочного или ложного содержания. Для LLM это не edge case. Модель оптимизирует вероятность последовательности токенов. Она не выполняет встроенную проверку факта по корпоративному реестру, если такая проверка не спроектирована в системе.

Высокий результат на академическом тесте не отменяет этот механизм. Он может снизить частоту отдельных ошибок, но не заменяет evidence layer.

Рабочий контур для high-impact операций строится вокруг ограничений модели:

• RAG с provenance. Ответ разрешён только при наличии релевантных фрагментов. В интерфейсе сохраняется связь утверждения с источником.
• Structured outputs. JSON schema, enum, типы полей и серверная валидация вместо свободного текста в интеграциях.
• Tool-based verification. Даты, статусы, цены, остатки и реквизиты берутся через API, а не из параметров модели.
• Abstention policy. При низком retrieval score, конфликте источников или отсутствии подтверждения система возвращает escalation, а не синтезирует ответ.
• Policy engine вне LLM. Права доступа, лимиты, маршрутизация и approval workflow реализуются детерминированно.
• Observability. Traces по запросу, версии prompt, retrieved chunks, вызовам инструментов, latency и причине отказа.

LLM не должна быть единственной точкой принятия фактического решения.

Есть практическая ошибка: использовать модель для генерации текста и затем просить её же оценить достоверность собственного текста. Такой self-check снижает часть дефектов формата, но не создаёт независимую верификацию. Нужны внешний источник, детерминированное правило или проверка человеком в зависимости от класса риска.

Для контакт-центра допустим один порог. Для кредитного решения, медицинского текста, юридической позиции или изменения платёжных реквизитов — другой. В последнем случае генерация может использоваться только как draft layer. Финальное действие должно проходить через rule engine или approval.

Оптимальный стек определяется не рейтингом модели

Выбор LLM начинается не с leaderboard. Он начинается с границ системы.

Для RAG-ассистента по внутренним знаниям базовый стек обычно включает ingestion pipeline, document normalization, vector index, metadata ACL, retrieval, reranking, генеративную модель, citation formatter, telemetry и evaluation harness. Замена модели без контроля остальных компонентов редко даёт ожидаемый прирост.

Для автоматизации back-office приоритет смещается к function calling, schema compliance, idempotency, очередям, retry policy и audit log. Здесь компактная модель с жёстким tool contract может быть рациональнее крупной модели с дорогим свободным рассуждением.

Для code assistant требуется отдельный контур: sandbox, тесты, dependency scanning, secret detection и обязательный CI gate. Метрика HumanEval сама по себе не характеризует качество кода в монорепозитории, соблюдение архитектурных ограничений и риск vendor lock-in.

Практическое решение фиксируется в виде матрицы.

Большие языковые модели нужно оценивать как компонент распределённой системы. Параметры влияют на capacity. Архитектура влияет на стоимость и latency. Бенчмарки дают ограниченный сигнал. Production-качество появляется только после измерения на собственных данных и после выноса критических проверок за пределы вероятностной модели.

Рациональный выбор не выглядит как покупка максимального числа параметров. Он выглядит как зафиксированный workload, измеримый SLO, контролируемая стоимость токена, воспроизводимый evaluation pipeline и детерминированный контур для всего, что нельзя доверять генерации.