Почему MMLU и другие бенчмарки знаний не работают для моделей с инструментами
MMLU и аналогичные тесты оценивают энциклопедические знания модели, её способность вспомнить правильный вариант из четырёх предложенных. Этот подход принципиально не подходит для моделей, работающих в связке с внешним окружением. Когда перед вами стоит задача построить агента, который ищет информацию в базе данных или вызывает API, способность ответить на вопрос по истории Древнего Рима без доступа к поиску становится не преимуществом, а источником ошибок.
Проблема в том, что модели, натренированные проходить MMLU на высокие баллы, обучены выдавать ответ в любых обстоятельствах. Столкнувшись с запросом о текущем курсе валют, такая модель сгенерирует правдоподобное число вместо вызова API биржи. Правдоподобное, но ложное. Именно это поведение заставило автора оригинального исследования отказаться от оценки MoE-моделей по критерию «знания» и полностью переключиться на замер способности модели вызывать инструменты.
Для компактных моделей вроде Ling-3.0-flash этот разрыв особенно заметен. Модель на 5B параметров физически не может вместить все факты мира, и это её преимущество: она не пытается «знать всё», вместо этого она должна научиться распознавать момент, когда нужен внешний инструмент. Классические бенчмарки здесь не просто бесполезны, они дезориентируют при отборе моделей для реальных пайплайнов.
Связка модели с инструментами требует оценки принципиально иного навыка: не извлечения факта из весов, а мета-когнитивного решения о том, что факта в весах нет и его нужно получить извне. Это разница между библиотекарем, который помнит все книги наизусть, и библиотекарем, который точно знает, в каком каталоге искать.
Инструментальная точность как новая метрика: тестируем Ling-3.0-flash
Автор предложил альтернативу: инструментальную точность (tool accuracy). Метрика замеряет долю случаев, когда модель корректно определила необходимость вызова внешнего инструмента и правильно его вызвала, вместо того чтобы сгенерировать ответ из весов. Для замеров использовалась Ling-3.0-flash, гибридная MoE-модель с 5B активных параметров, доступная через OpenRouter. Мы детально разбирали её архитектуру в обзоре AntLing-3.0-flash.
Методика тестирования строится на сценариях, где модель не должна давать ответ из памяти. Она получает промпт, описывающий доступные инструменты, и запрос, требующий обращения к одному из них. Успехом считается вызов правильного инструмента с корректными параметрами. Генерация любого текстового ответа вместо вызова засчитывается как провал, даже если ответ фактически верен: в production-среде вы не можете полагаться на случайное совпадение.
Примеры сценариев: когда модель должна молчать и вызывать инструмент
Три типовых кейса, на которых проверялась Ling-3.0-flash:
- Запрос к внешним данным. «Какой сейчас курс BTC/USD?» Модель не имеет доступа к актуальным данным в весах. Корректное поведение: вызов функции
get_crypto_price("BTC", "USD"). Некорректное: генерация любого числа. - Вычислительная задача. «Посчитай 12345 * 67890». Модель не должна умножать в уме, даже если для малых чисел это работает. Корректное поведение: вызов
calculate("12345 * 67890"). Некорректное: прямой ответ с риском ошибки на больших числах. - Запрос к внутренней базе знаний. «Найди статус заказа #ORD-98765». Модель не имеет доступа к базе заказов. Корректное поведение: вызов
query_orders("ORD-98765"). Некорректное: «Ваш заказ обрабатывается» без фактической проверки.
На этих сценариях Ling-3.0-flash показала стабильно высокую инструментальную точность. Модель не пыталась угадать курс биткоина или умножить в уме, она корректно инициировала вызов. Это поведение контрастирует с более крупными моделями, которые склонны «помогать» и выдавать ответ даже там, где это не требуется.
Малые модели против больших: почему 5B-модели выигрывают в вызове инструментов
Интуиция подсказывает: чем больше модель, тем она умнее, а значит, и с инструментами должна работать лучше. Практика показывает обратное. Компактные MoE-модели на 5B активных параметров демонстрируют более надёжное поведение в сценариях с вызовом инструментов по нескольким причинам.
Первая причина: меньшая склонность к галлюцинациям. Крупные dense-модели обучены на гигантских корпусах текста и стремятся выдать ответ всегда. Они «знают» так много, что им трудно признать отсутствие знания. Модель на 5B параметров физически не может запомнить все факты, и это вынуждает её полагаться на инструменты, а не на память.
Вторая причина: скорость инференса. Вызов инструмента должен происходить быстро, иначе задержка съедает весь выигрыш от использования малой модели. MoE-архитектура здесь даёт преимущество: при 5B активных параметров модель активирует лишь часть экспертов, что обеспечивает низкую latency.
Третья причина: стоимость дообучения. Малую модель дешевле и быстрее дообучить на специфичные инструменты конкретной компании. Это критично для сценариев, где набор API уникален и требуется тонкая настройка поведения.
Четвёртая причина: управляемость. Компактная модель с меньшей вероятностью проявит нежелательное поведение вроде попытки обойти ограничения инструментов или придумать несуществующий API. Её проще «запереть» в рамках разрешённых вызовов.
Где стратегия даёт сбой: ложная уверенность без вызова инструмента
Стратегия не безупречна. Главный риск, который выявило тестирование, это ложная уверенность. Модель может быть настолько уверена в своём ответе, что не вызывает инструмент даже тогда, когда он необходим. Она не распознала границу своей компетенции и выдала ответ, который оказался неверным.
Механика сбоя выглядит так: модель получает запрос, внутренние логиты показывают высокую уверенность в токенах ответа, и она генерирует текст вместо вызова функции. Пользователь получает быстрый и уверенный, но ошибочный ответ. Это хуже, чем явный отказ: ошибку сложнее заметить, она выглядит убедительно.
Проблема обостряется в доменах, где модель имеет частичные знания. Например, она может помнить курс валюты на момент обучения и выдать его, не проверив актуальность. Или помнить формулу, но ошибиться в вычислениях. Граница между «знаю точно» и «кажется, что знаю» размыта, и модель систематически её пересекает.
Как измерить уверенность модели и предотвратить тихие ошибки
Детектирование ложной уверенности требует инструментов за пределами стандартного инференса. Базовый подход: анализ логитов. Если распределение вероятностей по токенам слишком «острое» (модель выбрала один токен с вероятностью 0.95+), это сигнал потенциальной самоуверенности. Но логиты обманчивы: модель может быть одинаково уверена и в правильном, и в ошибочном ответе.
Более надёжный метод: калибровка уверенности через отдельный слой-пробу. Этот подход мы разбирали в сравнении 9 методов оценки уверенности LLM. Проба считывает скрытые состояния модели и предсказывает вероятность ошибки в сгенерированном ответе. AUROC таких проб достигает 0.79-0.88, что позволяет отсекать значительную часть ложных ответов до того, как они попадут к пользователю.
Третий метод: принудительный порог. Если уверенность модели в любом ответе без вызова инструмента ниже заданного значения, система игнорирует ответ и принудительно маршрутизирует запрос на вызов инструмента или на более мощную модель. Это грубый, но действенный способ предотвратить тихие ошибки ценой небольшого роста задержки.
Обучение отказу от ответа: учим модель говорить «я не знаю»
Радикальное решение проблемы ложной уверенности: явно научить модель отказываться от ответа. Вместо генерации непроверенного утверждения модель должна выдать специальный токен или фразу, сигнализирующую о необходимости вызвать инструмент либо о недостаточности данных.
Реализация требует специального датасета для дообучения. В него включаются пары «запрос - отказ», где модель должна ответить «нужен поиск» или «недостаточно данных» вместо генерации ответа. Ключевая сложность: соблюсти баланс. Слишком агрессивное обучение отказу делает модель бесполезной, она начинает отказываться даже там, где ответ очевиден и корректен. Слишком мягкое - не решает проблему ложной уверенности.
Reinforcement learning здесь показывает лучшие результаты, чем чистое supervised fine-tuning. Модель получает положительное вознаграждение за корректный отказ и отрицательное за ложный ответ, что позволяет ей выработать более тонкое различение ситуаций. Однако RL-обучение требует тщательно спроектированной функции награды, иначе модель найдёт способ максимизировать награду, не решая задачу. Этот класс проблем мы разбирали на примере провала скрытого рассуждения в эксперименте с моделью catmind-1.2b.
Плюсы подхода: радикальное снижение числа ложных ответов, прозрачность для пользователя (он видит, что модель признала ограничение), упрощение отладки пайплайна. Минусы: риск излишней осторожности, рост числа переадресаций на более мощные модели, необходимость поддерживать актуальный датасет отказов.
Практические рекомендации: внедряем инструментальную оценку в ваш пайплайн
Переход от бенчмарков знаний к инструментальной точности требует изменений на нескольких уровнях: выбор модели, настройка промптов, создание тестовых сценариев и мониторинг.
Выбор модели. Ориентируйтесь на MoE-архитектуры с 5-10B активных параметров. Ling-3.0-flash - хорошая отправная точка благодаря гибридному механизму рассуждений и доступности через OpenRouter. Приоритет: способность модели стабильно вызывать инструменты, а не её баллы на MMLU.
Настройка промптов. Системный промпт должен явно описывать доступные инструменты и правила их вызова. Добавьте инструкцию: «Если запрос требует актуальных данных или вычислений, используй соответствующую функцию. Не генерируй ответ из памяти, если не уверен в его точности». Избегайте промптов, поощряющих модель «помогать любой ценой».
Тестовые сценарии. Создайте набор из 50-100 запросов, покрывающих все доступные инструменты и граничные случаи. Включите запросы, где модель должна вызвать инструмент, и запросы, где она может ответить из памяти. Замеряйте инструментальную точность до развёртывания и после каждого обновления модели или промпта.
Мониторинг. Отслеживайте два ключевых показателя в production: долю вызовов инструментов от общего числа запросов и долю пользовательских жалоб на неверные ответы. Резкое падение первой метрики сигнализирует о том, что модель стала излишне самоуверенной. Рост второй - о том, что ложная уверенность приводит к ошибкам.
Интеграция с существующими фреймворками (LangChain, function calling)
Техническая реализация опирается на два основных подхода: нативные function calling API и фреймворки оркестрации.
OpenAI-совместимые function calling API поддерживаются большинством провайдеров, включая OpenRouter для Ling-3.0-flash. Вы описываете функции в JSON Schema, модель возвращает либо текстовый ответ, либо структурированный вызов функции. Этот подход минимален по накладным расходам и не требует внешних библиотек.
LangChain и аналогичные фреймворки добавляют слой маршрутизации. Вы можете настроить правило: если модель вернула ответ с уверенностью ниже порога, запрос автоматически перенаправляется на вызов инструмента или на более мощную модель. Пример конфигурации для связки LangChain + Ling-3.0-flash:
from langchain_openai import ChatOpenAI
from langchain_core.tools import tool
# Описываем инструменты
@tool
def search_knowledge_base(query: str) -> str:
"""Поиск по внутренней базе знаний компании."""
return kb.search(query)
# Инициализируем модель
llm = ChatOpenAI(
model="ling-3.0-flash",
base_url="https://openrouter.ai/api/v1",
api_key="your-key"
)
# Связываем модель с инструментами
llm_with_tools = llm.bind_tools([search_knowledge_base])
# Принудительный вызов инструмента при низкой уверенности
response = llm_with_tools.invoke("Найди статус заказа #ORD-98765")
if response.tool_calls:
result = execute_tool(response.tool_calls[0])
else:
# Если модель не вызвала инструмент, проверяем уверенность
if response.confidence < 0.8:
result = search_knowledge_base.invoke("статус заказа #ORD-98765")Ключевой элемент: проверка уверенности после получения ответа без вызова инструмента. Если модель не инициировала вызов, но её уверенность ниже порога, система принудительно запускает поиск. Это страховочный механизм, который ловит случаи ложной уверенности.
Будущее оценки MoE-моделей: за пределами знаний
Сдвиг парадигмы уже происходит. MMLU и аналогичные бенчмарки создавались для оценки моделей как замкнутых систем, которые должны хранить все знания внутри весов. Модели, работающие в связке с окружением, требуют оценки способности к взаимодействию, а не объёма памяти.
Инструментальная точность станет одной из ключевых метрик при выборе модели для production-агентов. Она лучше коррелирует с реальной полезностью, чем любой бенчмарк знаний. Модель, которая честно вызывает поиск, полезнее модели, которая уверенно выдумывает ответ.
Два направления будут определять развитие области в ближайший год. Первое: методы обучения отказу станут стандартной частью fine-tuning пайплайнов, а не экспериментальной техникой. Второе: метрики в model card начнут включать показатели инструментальной точности и склонности к ложной уверенности. Прозрачность в этих аспектах станет конкурентным преимуществом, подобно тому как сегодня прозрачность safety-метрик отличает ответственных разработчиков. О том, как читать model card с учётом расхождения бенчмарков и реального поведения, мы писали в разборе evaluation awareness.
Сообществу пора пересмотреть критерии отбора моделей. Модель с идеальным MMLU, но не умеющая вовремя вызвать API, это не готовый к production инструмент, а источник риска. Модель с посредственными бенчмарками знаний, но стабильной инструментальной точностью - это рабочий компонент для реальных систем.