Gemini Decision и обычная LLM-классификация: в чём разница и что выбрать

Короткий ответ

11 ноября 2026 года Google выпустила Gemini Decision (идентификатор модели gemini-decision-1) и вместе с ней Decisions API. Это не ещё одна, более крупная языковая модель. Это модель, которая только выносит решения и никогда не пишет ответ: вы отправляете один входной материал и до 1000 вопросов, а она за один проход возвращает вероятность и уверенность по каждому вопросу, не порождая ни одного выходного токена.

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

Официальная цена: $0.10 за миллион входных токенов, выход не тарифицируется.

gemini-decision-1 пока нет в TeamoRouter. Она работает через отдельный эндпоинт /v1beta/decisions, поэтому просто сменить имя модели в нашем существующем API не получится. Здесь — о том, как решить, нужна ли она вам, и чем два подхода отличаются.

Что именно делает Gemini Decision

Из официальной документации (11 ноября 2026):

Три типа вопросов:

• Да/нет: калиброванная вероятность от 0.01 до 0.99 плюс уверенность.
• Один вариант из списка: от 2 до 255 вариантов; возвращает лучший вариант, вероятности по каждому и уверенность.
• Оценка по шкале: от 2 до 255 упорядоченных уровней; возвращает взвешенное по вероятностям ожидаемое значение, вероятности по уровням и уверенность.

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

Как выглядит классификация через обычную LLM

Привычный подход: написать промпт и потребовать от модели структурированный вердикт по JSON-схеме.

from openai import OpenAI
import json

client = OpenAI(base_url="https://api.teamorouter.com/v1", api_key="ваш ключ TeamoRouter")

schema = {
    "type": "object",
    "properties": {
        "is_damaged": {"type": "boolean"},
        "category": {"type": "string", "enum": ["delivery", "refund", "product", "other"]},
        "reason": {"type": "string"},
    },
    "required": ["is_damaged", "category", "reason"],
}

resp = client.chat.completions.create(
    model="gemini-4-argon",
    messages=[{
        "role": "user",
        "content": "Классифицируй сообщение в поддержку: синяя кружка, заказанная в понедельник, пришла в среду разбитой.",
    }],
    response_format={"type": "json_schema", "json_schema": {"name": "ticket", "schema": schema}},
)
print(json.loads(resp.choices[0].message.content))

Это работает и это гибко: модель может вернуть reason, провести несколько оценок за один вызов и сама решить сначала извлечь сущности, а потом классифицировать. Но есть три структурные издержки:

1. Каждый вопрос порождает выходные токены. Десять вопросов — десять ответов, тысяча — тысяча. Считается по цене выхода, поэтому стоимость растёт вместе с числом вопросов.
2. Вероятности не калиброваны. «Уверена на 90%» обычно нельзя взять порогом без прогона по размеченной выборке — или приходится вовсе отказаться от вероятностей и смотреть только на метку.
3. Задержка растёт с числом вопросов. Каждый новый вопрос добавляет время генерации, и на пакетах в тысячи строк это заметно.

Прямое сравнение

Так что же выбрать

Решайте по характеру работы, а не по тому, что новее.

Где выигрывает обычная LLM

• Проверки, где нужна причина. Риски, модерация, тикеты поддержки: человеку на ревью нужно понимать, почему так. Decision даёт вероятность, а не объяснение.
• Многошаговые задачи. Прочитать PDF, извлечь сумму, сверить с лимитом, выбрать маршрут согласования. Именно такую цепочку Decision не делает.
• Случаи, где нужен уточняющий вопрос. Пользователь высказался расплывчато, и перед классификацией надо переспросить.
• Классификация, которая запускает ответ. Метка порождает текст: «отнесли к возвратам → пишем инструкцию по возврату».

Где выигрывает Gemini Decision

• Пакетные проверки правил. Один договор, счёт или диалог против 30 правил комплаенса, каждое — вопрос да/нет. Обычной модели нужно 30 запросов и 30 оплаченных ответов; Decision — один запрос и одна оплата входа.
• Оценка кандидатов по рубрике. Отранжировать 200 резюме по пяти измерениям или оценить пачку ответов по четырёхуровневой шкале качества. Вопрос с оценкой сразу возвращает взвешенное по вероятностям ожидаемое значение, без ручных пересчётов.
• Классификация живого медиа с низкой задержкой. Стримы, звонки, кадры видео: десятки миллисекунд без задержки на генерацию. Нулевые выходные токены здесь решают.
• Высоконагруженная классификация с жёстким порогом. Сотни тысяч запросов в день, маршрутизация по калиброванной вероятности ниже 0.8, без чтения каждого человеком.

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

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

Практический способ решить

Возьмите свою текущую задачу классификации и ответьте на три вопроса:

1. Нужен ли по каждому вопросу письменный ответ? Да → обычная модель. Нет → дальше.
2. Сколько вопросов на один вход? Один-два → обычной модели хватает, новый эндпоинт не нужен. Десятки и сотни → преимущество Decision в цене становится заметным.
3. Будете ли вы использовать вероятность как порог? Да → калиброванные вероятности годятся сразу. Нет → преимущество калибровки не используется.

Только если все три ответа указывают на Decision, стоит подключать новый эндпоинт.

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

Gemini Decision — это версия Gemini 4? Нет. gemini-decision-1 — отдельный идентификатор модели для Decisions API, её нельзя вызвать через :generateContent.

Может ли она заменить Gemini 4 Carbon? Нет. Carbon рассуждает и генерирует, Decision только выносит решение. Это совершенно разные задачи.

Как она возвращает результат без выходных токенов? Ответ получается из распределения вероятностей, вычисленного за один проход prefill, а не генерацией токен за токеном. Отсюда вероятности и отсутствие текста.

Когда появится в TeamoRouter? Пока нет. Нужен новый эндпоинт /v1beta/decisions, одной смены имени модели недостаточно. После подключения появится на странице цен.

Повторный вход тарифицируется снова? Да. Кэша контекста нет, одинаковый вход в разных запросах каждый раз считается полностью. Либо задавайте все вопросы в одном запросе, либо дедуплицируйте у себя.

Что ещё почитать

• Gemini 4 Carbon API: тоже новая модель Google, но для рассуждений и генерации
• Gemini 4 Argon API: первая модель семейства Gemini 4, там же примеры структурированного вывода
• Qwen 3.8 Flash или Max: практический пример выбора модели классификации по цене и точности