Модель «поглупела» не обязательно из-за замены: 6 распространённых причин странных результатов при вызове API и 3 шага для их диагностики

Примечание автора: если модель «поглупела», это не обязательно значит, что её подменили. Отталкиваясь от недавнего исследования Anthropic FlashProve о доказательстве корректности инференса, мы разберём факторы, влияющие на результат вызова API, и составим порядок их проверки — от настроек клиента до серверной части.

«На сайте модель решила задачу, а через API на ней застряла», «В этом месяце модель явно поглупела» — подобные жалобы слышал почти каждый разработчик, который подключает большие языковые модели через API. Первая мысль у многих: не заменили ли модель на сервере?

Недавно Anthropic представила исследовательский прототип с открытым исходным кодом FlashProve. Он использует криптографические доказательства, чтобы проверить, действительно ли ответ получен с помощью заданного набора весов. Так впервые появилась возможность математически проверить, не была ли модель подменена.

Но на этом проблема «поглупевшей» модели не заканчивается. Как отмечается в исследовании, даже если подлинность весов подтверждена, на результат всё равно влияют системный промпт, политики безопасности, усечение контекста, извлечённые данные, способ квантования и параметры декодирования. Опыт команды Kimi также показывает, что немалая часть аномальных результатов бенчмарков связана с неправильным использованием параметров декодирования.

Что вы узнаете: в конце статьи у вас будет список проверок на случай, если модель начнёт работать хуже. Вы поймёте, что можно проверить самостоятельно, где понадобится помощь провайдера и почему «задать модели несколько вопросов, чтобы определить её» — ненадёжный способ.

Модель стала хуже: краткий обзор

Для начала разберёмся, с чего началось обсуждение. Поводом стало исследование Anthropic о «доказуемом инференсе», а главный вопрос сообщества — кто виноват, когда модель начинает работать хуже.

Как FlashProve доказывает, что модель — это именно она

FlashProve работает в два этапа. Сначала провайдер создаёт для весов модели криптографическое «обязательство» — своеобразный отпечаток, который однозначно фиксирует веса, не раскрывая их. Затем для заданных входных и выходных данных провайдер формирует доказательство. Получив обязательство, промпт, ответ и файл доказательства, пользователь может на своём компьютере проверить, что ответ действительно вычислен с использованием зафиксированных весов.

Доказательство с нулевым разглашением гарантирует, что проверяющий не получит доступ к весам и промежуточным результатам вычислений и не увидит, какие эксперты вызывались на каждом слое модели MoE. Это гораздо надёжнее, чем просить модель представиться: название модели в ответе больше не служит удостоверением личности — проверяется вычислительная связь между ответом и весами.

Anthropic провела эксперимент с Llama 4 Maverick, чьи 4-битные веса открыты. Это модель со смесью экспертов, в которой около 400 млрд параметров, а при обработке каждого токена активируются около 17 млрд. Вот основные результаты:

Почему модель может «поглупеть», даже если её веса проверены

У FlashProve есть важное предварительное условие: пользователь должен заранее знать, какому коммитменту соответствует «подлинная модель». Если поставщик может лишь доказать, что ответ получен от выбранной им модели, но пользователь не может убедиться, что это именно та модель, за которую он заплатил, доказательство всё равно не решает проблему идентификации. В идеале разработчик модели или доверенная организация должны публично опубликовать коммитмент, а пользователь — проверять его по этому отпечатку.

Но главное — неизменность весов не означает, что сервис тоже не изменился. Доказательство, привязанное к весам, само по себе не отвечает на вопросы, изменился ли системный промпт, не был ли обрезан контекст и остались ли прежними параметры декодирования. Поэтому жалобы на то, что модель «поглупела», возникают снова и снова: часто это результат изменений сразу на нескольких этапах.

6 распространённых причин, почему модель «поглупела»

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

Ошибки в параметрах декодирования: причину того, что модель «поглупела», легко упустить

Команда Kimi поделилась показательным наблюдением, когда рассказывала о Kimi Vendor Verifier. После выхода K2 Thinking разработчики получили немало сообщений от сообщества о странных результатах тестов. Расследование показало, что значительная часть проблем была связана с неправильным использованием параметров декодирования. После этого команда ограничила значения соответствующих параметров в режиме Thinking и проверила, правильно ли возвращается содержимое рассуждений.

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

Неполный контекст: модель «забывает» и кажется менее умной

Другая частая причина — контекст. Если в многоходовом диалоге передать только последнюю реплику, модель, конечно, не «вспомнит» предыдущие. Если история сообщений в рабочем процессе превышает контекстное окно модели, при обрезке нередко первыми пропадают системные инструкции. В результате модель вдруг перестаёт соблюдать заданный формат. Кроме того, слишком маленькое значение max_tokens обрывает ответ на полуслове — создаётся впечатление, что модель просто остановилась на середине.

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

Модель стала работать хуже: проверка в 3 шага

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

1. Сначала проверьте настройки на своей стороне: название model, параметры декодирования, max_tokens, системный промпт, полный список сообщений и содержимое, полученное через RAG.
2. Затем проведите сравнительный тест: зафиксируйте параметры и промпт, сравните результаты с ответами через официальный канал или описанием в официальной документации. Запустите тест несколько раз, чтобы оценить распределение результатов, а не судить по одному ответу.
3. В последнюю очередь проверьте сторону сервиса: если настройки на вашей стороне верны, а различия стабильно воспроизводятся, обратитесь к поставщику сервиса с записями запросов и результатами тестов.

Минимальный пример: воспроизводимый вызов с фиксированными параметрами

Для начала лучше явно указать все параметры, не полагаясь на значения по умолчанию, а также вывести причину завершения и расход токенов:

import openai

client = openai.OpenAI(api_key="YOUR_API_KEY", base_url="https://api.apiyi.com/v1")

resp = client.chat.completions.create(
    model="gpt-4o-mini",  # Укажите модель, которую проверяете
    messages=[{"role": "user", "content": "用三句话解释什么是零知识证明"}],
    temperature=0, max_tokens=800,
)
print(resp.choices[0].finish_reason, resp.usage)
print(resp.choices[0].message.content)

Если finish_reason равен length, значит, ответ был обрезан из-за ограничения max_tokens. В этом случае неполный ответ связан не с тем, что модель стала хуже, а с настройкой параметров. Количество входных токенов в usage поможет проверить, действительно ли контекст был передан целиком.

import json
import openai
from collections import Counter

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # Для смены модели достаточно изменить параметр model
)

# Явно указываем все параметры, не полагаясь на значения по умолчанию
PARAMS = {
    "temperature": 0.2,   # Для рассуждающих моделей используйте значение, рекомендованное в официальной документации
    "top_p": 1.0,
    "max_tokens": 2000,
}

TEST_CASES = [
    {"id": "math", "prompt": "一个数加上它的一半等于 45，这个数是多少？只给出数字。", "expect": "30"},
    {"id": "format", "prompt": "用 JSON 输出三种水果名称，键名为 fruits。", "expect": "fruits"},
]

def run_case(model: str, case: dict, rounds: int = 5) -> dict:
    """Запускает один тест несколько раз и подсчитывает долю успешных ответов, число обрезанных ответов и расход токенов"""
    hits, finish = 0, Counter()
    prompt_tokens = []
    for _ in range(rounds):
        resp = client.chat.completions.create(
            model=model,
            messages=[
                {"role": "system", "content": "你是严谨的助手，按要求作答。"},
                {"role": "user", "content": case["prompt"]},
            ],
            **PARAMS,
        )
        content = resp.choices[0].message.content or ""
        finish[resp.choices[0].finish_reason] += 1
        prompt_tokens.append(resp.usage.prompt_tokens)
        if case["expect"] in content:
            hits += 1
    return {
        "case": case["id"],
        "hit_rate": hits / rounds,
        "finish_reasons": dict(finish),
        "prompt_tokens": sorted(set(prompt_tokens)),
    }

if __name__ == "__main__":
    model = "gpt-4o-mini"  # Укажите модель, которую проверяете
    report = [run_case(model, c) for c in TEST_CASES]
    print(json.dumps({"model": model, "params": PARAMS, "report": report},
                     ensure_ascii=False, indent=2))

Суть скрипта не в самих тестовых заданиях, а в трёх вещах: все параметры фиксируются и выводятся в отчёте; каждый тест запускается несколько раз для оценки доли успешных ответов; значения finish_reason и prompt_tokens записываются, чтобы исключить обрезание ответа и проблемы с контекстом. Только после проверки этих трёх пунктов имеет смысл обсуждать, не изменилось ли что-то на стороне сервера.

🚀 Совет по диагностике: APIYI apiyi.com использует интерфейс, совместимый с OpenAI, поэтому для переключения модели достаточно изменить параметр model. Это позволяет сравнивать несколько моделей с помощью одного набора тестовых скриптов. Платформа предоставляет журналы вызовов и статистику использования: по ним можно проверить расход ресурсов и токенов и оценить, был ли контекст передан целиком. Какие именно поля отображаются в журналах, уточняйте в консоли платформы.

Что пользователь может проверить сам, а где нужна помощь провайдера

При обращении к провайдеру приложите примеры запросов с фиксированными параметрами, статистику нескольких запусков и результаты для сравнения. Так разобраться в проблеме будет гораздо проще. По одной фразе «модель поглупела» найти причину сложно.

Почему нельзя судить об ухудшении модели по ответам на несколько вопросов

В сообществе популярен такой способ проверки: задать модели вопрос, ответ на который известен только новой версии. Если она не справилась, значит, «модель подменили». Проблема в том, что отдельный ответ зависит от случайности. Ошибка может быть случайной, а её причиной также могут стать другие параметры, недостаток контекста или особенности внутренней маршрутизации у провайдера. Но вывод во всех случаях делают один: «Это не та модель, которая мне нужна».

Исследовательский проект Стэнфордского университета Model Equality Testing предлагает более строгий подход. Учёные протестировали 31 коммерческий API-эндпоинт для четырёх моделей Llama 2024 года и обнаружили, что у 11 из них распределение ответов статистически отличалось от эталонного распределения модели с весами, опубликованными Meta. Обратите внимание: исследователи сравнивали именно распределения ответов, а не правильность ответа на один-два вопроса.

Разработчикам стоит взять на вооружение этот статистический подход: искать устойчивые различия с помощью фиксированных параметров, нескольких тестовых случаев и многократных запусков. Именно поэтому скрипт для сравнения выше использует «долю успешных ответов», а не результат одной попытки.

Как влияет ощущение, что модель «поглупела»

Влияние на разработчиков

• Начинайте проверку со своего запроса: если качество ответов ухудшилось, сначала проверьте тело запроса. Неверные параметры и отсутствие контекста — самые простые и частые причины.
• Задавайте параметры явно: в продакшене не полагайтесь на значения по умолчанию. Параметры моделей с рассуждением настраивайте по официальной документации и храните под контролем версий.
• Создайте набор регрессионных тестов: регулярно запускайте фиксированные сценарии. Если модель «поглупеет», у вас будут данные, а не только субъективные ощущения.
• Сохраняйте логи вызовов: параметры запроса, расход токенов и причина завершения помогут при общении с поставщиком сервиса.

Влияние на отрасль

• От субъективных ощущений — к доказательствам: FlashProve показывает, что идентичность весов можно проверять. В будущем производители моделей, организации, занимающиеся оценкой, и регуляторы смогут таким образом подтверждать, какая модель используется в сервисе.
• Требования к прозрачности станут шире: помимо весов, следующим предметом обсуждения может стать соответствие системных промптов, стратегий декодирования и конфигураций развёртывания.
• До широкого применения ещё далеко: получение доказательства обходится примерно в несколько десятков раз дороже обычного инференса. Кроме того, нужны поддержка более длинного контекста и надёжный механизм публикации обязательств. Поэтому в ближайшее время метод вряд ли охватит повседневные вызовы моделей.

Частые вопросы FAQ

Модель стала работать хуже: главное о диагностике

• Ухудшение работы модели не обязательно означает её подмену: на результат также влияют системный промпт, контекст, параметры декодирования и другие настройки.
• Ошибки в параметрах встречаются часто: команда Kimi подтвердила, что значительная часть аномальных результатов тестов связана с неправильными параметрами декодирования.
• Проверяйте всё поэтапно: сначала настройки на стороне клиента, затем результаты сравнительных тестов и только после этого — возможные проблемы на стороне сервиса.
• Один вопрос не показателен: нужно сравнивать распределение результатов нескольких запусков, а не судить по одному-двум ответам.
• Проверка весов имеет ограничения: FlashProve подтверждает только идентичность весов и не выявляет изменения настроек на уровне продукта.
• Используйте единые инструменты тестирования: для сравнения можно воспользоваться совместимым интерфейсом и логами APIYI apiyi.com.

Итоги

Раньше споры о том, стала ли модель работать хуже, в основном строились на скриншотах и личных ощущениях. FlashProve от Anthropic предлагает способ проверить, не подменили ли модель. Но при этом инструмент напоминает: помимо весов, на результат влияет целый слой настроек.

1. Сначала проверьте свою сторону: параметры декодирования, max_tokens, список сообщений и содержимое, полученное через RAG, — самые простые и недорогие отправные точки.
2. Затем проведите сравнение: сопоставьте результаты с официальной версией при фиксированных параметрах, на нескольких сценариях и в нескольких запусках. Опирайтесь на данные, а не на ощущения.
3. Наконец, свяжитесь с провайдером: убедившись, что на стороне клиента всё в порядке, передайте ему записи запросов и статистику, чтобы найти проблему на стороне сервиса.

Рекомендуем включить сравнительный скрипт из этой статьи в регулярные регрессионные тесты. Через APIYI apiyi.com можно быстро проверить работу нескольких моделей с помощью одного и того же кода: платформа предоставляет бесплатный лимит для тестирования и единый интерфейс, совместимый с OpenAI.

📚 Источники

1. 36氪 / APPSO — разбор исследования Anthropic о проверяемом инференсе: принципы работы FlashProve, данные экспериментов и обсуждение причин «снижения интеллекта» моделей
2. Ссылка: 36kr.com/p/4056019887510401

3. Описание: основной источник фактов и данных для статьи, включая сведения о Kimi Vendor Verifier и Model Equality Testing

4. Anthropic Research — Provable Inference: официальная страница исследования FlashProve

5. Ссылка: anthropic.com/research/provable-inference
6. Описание: здесь можно найти технический отчёт, открытый исходный код и формальные доказательства

Автор: техническая команда APIYI
Технические вопросы: если у вас возникли проблемы при выяснении причин необычных результатов вызова модели, свяжитесь с нами через главную страницу сайта APIYI apiyi.com. Подробнее о подключении — в документации на docs.apiyi.com.

Читайте также

• Устранение обрывов соединения с API изображений: 5 распространённых причин и способов решения при генерации изображений через границу: Разберём 5 распространённых причин обрыва соединения с API изображений — настройки тайм-аута, прокси-шлюз, международные каналы связи, стратегию повторных попыток и среду выполнения, — чтобы вы могли надёжно получать результаты при генерации изображений через границу.