Есть особый тип совещания, который случается в каждой команде, строящей продукты поверх передовых LLM. Кто‑то делится последней таблицей лидеров бенчмарков. Кто‑то другой отмечает, что рейтинги с прошлого месяца перемешались. Третий замечает, что модель, которую команда сейчас использует, опустилась на две позиции по какой‑то метрике, о существовании которой три недели назад никто даже не слышал. К концу встречи никто не уверен, стоит ли мигрировать, и разговор снова переносят на следующий квартал.
Проблема этого совещания не в людях. Проблема в том, что бенчмарки измеряют синтетические задания, а ваш продукт — не синтетическое задание. Таблица лидеров говорит, как модель выступает на MMLU, на SWE-bench Verified, на GPQA Diamond — тестах, спроектированных исследователями так, чтобы их можно было измерять поперёк моделей. Ни один из этих тестов не похож на подсказки, которые ваше приложение реально отправляет в продакшене. Ни один из них не отражает, как модель справляется с определённым типом «грязного», доменно‑специфического входа, который генерируют ваши пользователи.
Этот текст проводит именно то упражнение, на которое бенчмарки не способны. Три конкретные подсказки, рассчитанные на отправку в GPT-5.5, Claude Sonnet 4.6 и Gemini 3.1 Pro через одну и ту же конечную точку, совместимую с OpenAI, с одинаковыми настройками температуры и без дополнительных инструкций. Подсказки охватывают три категории, которые затрагивают большинство продакшен‑нагрузок: структурированное извлечение из «грязного» документа, планирование с упором на рассуждения и генерация кода с ограничениями. Ниже приведены поведенческие паттерны, которые команды стабильно отмечают при таком сравнении — именно то, что вы сами увидите, если запустите эти подсказки у себя.
В таблицах лидеров эти три модели отличаются в пределах 0,8 процентного пункта на SWE-bench Verified. На практике они ведут себя очень по‑разному. Выбор между ними — не о том, кто выше по бенчмаркам, а о том, чья поведенческая модель соответствует вашей нагрузке.
Что измеряют бенчмарки и что они упускают
Бенчмарки существуют потому, что без них нельзя. Провайдерам моделей нужны стандартизированные тесты, чтобы заявлять о возможностях; исследователям — чтобы публиковать сравнения; остальным — чтобы иметь хоть какую‑то объективную отправную точку для оценки моделей. Они полезны. И при этом неполны в аспектах, важных для продакшена.
Стоит явно назвать три ограничения, потому что каждое проявится в примерах подсказок ниже.
- Бенчмарки измеряют изолированные способности, а не поведенческие паттерны. SWE-bench Verified говорит, может ли модель решать определённый тип GitHub‑issues. Он не говорит, склонна ли модель переусложнять простые задачи, задаёт ли уточняющие вопросы при неоднозначной постановке или выдаёт ли сразу вывод, строго соответствующий запрошенной структуре. Именно это вы будете наблюдать ежедневно в продакшене.
- Бенчмарки подстраивают под себя. Когда релиз модели крупно демонстрирует её результат на конкретном бенчмарке, это сигнал, что модель хотя бы частично оптимизировали под него. Реальная производительность и показанная на бенчмарке могут расходиться — иногда существенно — как только модель выходит за условия, для которых бенчмарк разрабатывался.
- Бенчмарки агрегируют. Разница в 0,8 процентного пункта в SWE-bench Verified может скрывать, что Модель A куда лучше в одной категории задач и хуже в другой, тогда как Модель B ровнее по всем категориям. Агрегация схлопывает информацию, которая нужна вам для решения.
Упражнение ниже спроектировано так, чтобы вывести на поверхность именно ту информацию, которую бенчмарки агрегированием скрывают. Цель не назвать победителя, а показать вопросы, которые вы должны задавать, когда будете запускать то же упражнение на своих подсказках.
Настройка
Три подсказки, выбранные потому, что они соответствуют категориям, с которыми сталкивается большинство продакшен‑нагрузок. Настройка: каждая подсказка отправляется всем трём моделям с идентичными параметрами (температура 0.3, без переопределения системной подсказки, формат ответа по умолчанию), доступ через единую конечную точку, совместимую с OpenAI, чтобы сравнение было «яблоко к яблоку» — без SDK‑особенностей конкретного провайдера, различных отображений параметров и риска того, что одна модель получит «особое отношение» из‑за того, как сформирован запрос.
Сами подсказки ниже — в блоках кода, которые вы можете скопировать и запустить. Поведенческие описания после каждой — это паттерны, которые команды стабильно отмечают при таких сравнениях, задокументированные в ряде сторонних исследований в 2026 году, и именно то, что вы сможете увидеть сами, запустив эти подсказки у себя. Смысл — запустить самим; статья даёт рамку и стартовые подсказки.
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["COMET_API_KEY"], # or replace with your API key
base_url="https://api.cometapi.com/v1", # one endpoint, multiple models
)
MODELS = [
"gpt-5.5",
"claude-sonnet-4-6",
"gemini-3.1-pro",
]
def run_comparison(prompt: str, temperature: float = 0.3) -> dict[str, str]:
"""
Send the same prompt to all three models and return their responses.
"""
responses = {}
for model in MODELS:
result = client.chat.completions.create(
model=model,
messages=[
{
"role": "user",
"content": prompt,
}
],
temperature=temperature,
)
responses[model] = result.choices[0].message.content
return responses
# Example usage
if __name__ == "__main__":
prompt = "Summarise the key risks in this contract."
outputs = run_comparison(prompt)
for model, response in outputs.items():
print(f"\n--- {model} ---")
print(response)
Подсказка 1: Структурированное извлечение из «грязного» документа
Это «рабочая лошадка» половины LLM‑функций, выпущенных в 2026 году. Взять неструктурированный вход — письмо, тикет в поддержку, расшифровку встречи, отсканированную форму — и извлечь конкретные поля в структурированный объект. Подсказка ниже просит каждую модель извлечь семь полей из намеренно «грязного» письма в поддержку, содержащего частичную информацию, конфликтующие сигналы и одно поле, которого в источнике вообще нет.
Подсказка
You are processing customer support emails. Extract the followingseven fields from the email below into a JSON object with exactlythese keys: - customer_name (string)- order_id (string)- issue_type (one of: "shipping", "product_quality", "billing", "returns", "other")- urgency (one of: "low", "medium", "high")- requested_action (string)- affected_product (string)- escalation_history (any prior contact about this issue, if mentioned)
Email:---Hi there, I'm writing about order #FT-2289334 from last Tuesday. The Cascadehiking boots I received are NOT the size 11 I ordered — they'reclearly size 10 (I can see the label inside). I have a guided trekbooked in 5 days and I genuinely don't know what to do. I've beena customer for years and this is the first time something likethis has happened. Can you sort this out urgently? I'd prefer a same-day exchange ifat all possible. I'm in Manchester. Margaret W.--- Return only the JSON object. No commentary, no markdown code fences.
На что смотреть
Три вещи. Во‑первых, соблюдает ли модель запрошенную JSON‑схему без выдумывания лишнего. Во‑вторых, как модель обрабатывает поле, которого нет в источнике (escalation_history — клиент не упоминает прежние обращения по этому вопросу): признаёт отсутствие или правдоподобно додумывает? В‑третьих, добавляет ли модель комментарии вне JSON, из‑за чего потребуется постобработка для удаления «обёртки». Поле urgency тоже интересно: «5 дней» — это не «сейчас же», но клиент явно нервничает, что оставляет простор для трактовки.
Что команды стабильно отмечают
GPT-5.5. Обычно с первой попытки выдаёт чистый JSON. Соблюдение схемы отличное: все запрошенные поля присутствуют, формат парсится без предобработки. Для отсутствующих полей GPT-5.5 склонен возвращать явный null. Как правило, не оборачивает JSON в блоки кода Markdown и не добавляет пояснительный текст, что упрощает дальнейший разбор. В неоднозначных оценках вроде приоритета здесь GPT-5.5 более консервативен, чем два других — там, где Claude и Gemini могут поставить «high» на основе эмоционального тона, GPT-5.5 заякоривается на конкретном окне в 5 дней и выбирает «medium».
Claude Sonnet 4.6. Тоже выдаёт чистый JSON и, как правило, самый точный из трёх в следовании схеме. Там, где GPT-5.5 оставляет отсутствующее поле как null, Claude часто добавляет незапрошенные поля, помечающие проблемы качества данных — «notes» или «data_quality_notes», которых не просили, но в них действительно полезные замечания. Это полезно для ручной проверки, но ломает пайплайн, если ваш парсер строго следует схеме. Регулярный паттерн Claude: высокое качество, но иногда более основательно, чем попросили, так что нужны явные инструкции, чтобы ограничить.
Gemini 3.1 Pro. Как правило, выдаёт самый экономичный вывод из трёх. Все запрошенные поля, без лишних, без окружающего текста. Следование схеме — ровно как просили. Одна особенность: для отсутствующих полей Gemini чаще возвращает пустую строку, а не null. Строгие JSON‑парсеры, различающие это, «споткнутся», более либеральные — нет. Поведение достаточно стабильно, чтобы считать это предпочтением модели, а не артефактом.
Что это говорит вам
Все три модели умеют структурированно извлекать. Различия — в поведенческих деталях вокруг запрошенной схемы. Если ваш downstream строго следует схеме и расценивает лишние поля как ошибки, безопаснее Gemini 3.1 Pro и GPT-5.5. Если вы хотите, чтобы модель сама поднимала вопросы качества данных, не будучи об этом просимой, Claude Sonnet 4.6 полезнее. Ничего из этого не видно в бенчмарках.
Подсказка 2: Планирование с упором на рассуждения
Эта подсказка просит спланировать многошаговое исследование: исследовательский вопрос с тремя неявными ограничениями, которые аккуратная модель должна выявить до составления последовательности работ. Тип задачи, который агентное приложение делегировало бы LLM как этап планирования до вызова каких‑либо инструментов.
Подсказка
I'm trying to answer this research question for my team: "Is our customer churn rate higher among users who haven't usedfeature X in the last 30 days?" Produce a plan for how to investigate this. The plan should:- Identify the steps required- Sequence them with dependencies- Be actionable for a data analyst on my team Return the plan in clear, structured form.
Неявные ограничения, за которыми стоит следить: в вопросе не определено, что такое «churn» (закрытие аккаунта? отсутствие логинов? отсутствие покупок?), не указано, как учитывать мешающие факторы (пользователи с низкой вовлечённостью уходят по множеству причин, не связанных с feature X), и не задана базовая группа сравнения. Аккуратный планировщик должен поднять все три пункта до разбиения на шаги.
На что смотреть
Действительно ли модель продумывает проблему или выдаёт правдоподобную на вид последовательность, которая разваливается при внимательном рассмотрении. Выявляет ли неявные ограничения без подсказки. И корректны ли зависимости между шагами — план, который выглядит нормально, но «шаг 3 зависит от результата шага 5», бесполезен на практике.
Что команды стабильно отмечают
GPT-5.5. Обычно даёт наиболее операционно применимый план. Ход рассуждений виден — GPT-5.5 перечисляет свои допущения о неявных ограничениях (определение оттока, контрольная группа, мешающие факторы) перед тем, как изложить шаги, — что упрощает выявление расхождений с ожидаемой трактовкой. Зависимости шагов надёжно отмечены и подписаны. Часто добавляет раздел о том, какие шаги можно распараллелить — это не просили, но польза реальная. В таких задачах проявляется обучение GPT-5.5 на использовании инструментов и агентном поведении — планирование ориентировано на последующее исполнение.
Claude Sonnet 4.6. Как правило, даёт самый вдумчивый план — буквально. Claude часто поднимает соображения, которые другие две модели не отмечают. В таком вопросе Claude, скорее всего, укажет на методологическую проблему «корреляция vs причинность», заметит, что «не пользовался feature X» может быть симптомом оттока, а не причиной, и явно назовёт ограничения, не сформулированные в явном виде, но которые аккуратный аналитик должен заметить. Минус: план может быть длиннее, чем надо, а отдельные шаги — переусложнены относительно задачи. Паттерн согласуется с поведением Claude в целом — забота экспертного уровня, иногда больше, чем требуется.
Gemini 3.1 Pro. Обычно выдаёт план с самой чистой структурой и самыми понятными зависимостями. Качество рассуждений высокое — Gemini уверенно выявляет неявные ограничения, декомпозирует задачу в защитимую последовательность и даёт пошаговые инструкции, которые можно выполнять. Недостаток: план может восприниматься несколько механическим. Он делает работу, но не выводит методологические тонкости, которые поднимает Claude, и не добавляет инсайды по распараллеливанию, как GPT-5.5. Это соответствует общему паттерну Gemini — силён в качестве рассуждений, более «ремесленный» в сопутствующих суждениях.
Что это говорит вам
Качество рассуждений в этой задаче у всех трёх моделей высокое. Различия — в том, что модель добавляет сверх прямого запроса. GPT-5.5 добавляет операционную прагматику (распараллеливание, подсказки по исполнению). Claude добавляет экспертную тщательность (методология, крайние случаи, статистические нюансы). Gemini добавляет ясность и экономность. Ни один из вариантов не «неправильный». Подходит то, что соответствует тому, чего вы ожидаете от модели после выполнения самого запроса.
Подсказка 3: Генерация кода с конкретными ограничениями
Эта подсказка просит реализовать небольшую, но не‑тривиальную функцию: Python‑функцию, принимающую список событий с временными метками и возвращающую самый длинный разрыв между соседними событиями, обрабатывая четыре крайних случая. Ограничения заданы явно; намерение — проверить генерацию кода при ограничениях, а не потолок способностей — каждую модель на это хватит. Различается то, как они соблюдают ограничения.
Подсказка
Write a Python function that takes a list of timestamped events andreturns the longest gap (in seconds) between consecutive events. Requirements:- Function signature: longest_gap(events: list[datetime]) -> float- Handle these edge cases: 1. Empty list (return 0.0 or raise — your choice, but be consistent) 2. Single event 3. Duplicate timestamps 4. Unsorted input- Use only the standard library- Include type hints- Return just the function. No tests or usage examples.
На что смотреть
Обрабатывает ли модель все четыре крайних случая или молча опускает часть. Насколько точны подсказки типов — конкретные или шаблонные. Выбирает ли реализацию на основе защитимого алгоритма (сортировка, затем проход) или что‑то экзотическое. И соблюдает ли модель запрет «без тестов, без примеров использования» в конце подсказки — это тот тип поздней инструкции, который модели с сильным следованием инструкциям соблюдают, а слабые — тихо нарушают.
Что команды стабильно отмечают
GPT-5.5. Как правило, пишет наиболее тщательно проработанный код. Все четыре крайних случая обработаны явными ветвлениями, подсказки типов точные (часто включая Optional или Union для вариантов возврата в крайних случаях), и docstring с примерами вызовов. Реализация обычно выбирает очевидный алгоритм — сортировка, проход, отслеживание максимального разрыва — и он корректен. Стоит знать: GPT-5.5 часто включает юнит‑тесты или примеры использования, даже если просили вернуть только функцию. Это издержка операционно‑прагматичных моделей — они добавляют то, что, по их мнению, вам пригодится, даже если вы об этом не просили.
Claude Sonnet 4.6. Чаще всего выдаёт самый читаемый код. Функция лаконична, крайние случаи обработаны чистым паттерном защитных проверок в начале, подсказки типов точные и минимальные. Claude часто добавляет вдумчивый комментарий, объясняющий дискуссионное решение, оставленное подсказкой на усмотрение — например, для дубликатов меток времени считать их разрыв нулевым и объяснить почему; это обоснованный выбор, которого подсказка не требовала. Claude надёжнее соблюдает запрет «без тестов», чем GPT-5.5. Сама функция — самая сопровождаемая из трёх. Это согласуется с репутацией Claude по качеству кода: чисто, идиоматично, по‑экспертному.
Gemini 3.1 Pro. Как правило, выдаёт самый экономичный код из трёх. Функция корректна, крайние случаи обработаны, реализация — самая короткая. Docstring обычно в одну строку. Подсказки типов присутствуют и точны. Решение Gemini редко включает тесты или обширные комментарии и не переусложняет — что ровно и запрошено. Для разработчика, которому нужна рабочая функция и который добавит тесты отдельно, это самый прямой путь. Для того, кто хочет, чтобы модель сделала и «окружающую» работу, другие две модели добавляют больше (даже если вы их об этом не просили).
Что это говорит вам
Все три модели способны написать эту функцию. Поведенческая разница — в том, сколько «окружающей» работы каждая делает сверх прямого запроса и насколько строго соблюдает явные запреты «не добавлять X». GPT-5.5 склоняется к основательности, даже если в подсказке от неё отказались. Claude — к мастерству (читабельный код, вдумчивые комментарии по дискуссионным решениям). Gemini — к экономии (делать ровно то, что просили, и не больше). Для агентных пайплайнов, где вывод модели попадает прямо в продакшен‑кодовую базу, нужное поведение зависит от того, чего ожидает ваш процесс ревью и насколько строго вы требуете соблюдения отрицательных инструкций.
Возникающие паттерны
В трёх примерах выше из сравнений и отчётов разработчиков, опубликованных в 2026 году, вырисовываются три стабильных поведенческих паттерна. Это не заявления о возможностях — каждая модель справляется с каждой задачей на высоком уровне. Это тенденции, которые видны только тогда, когда команды наблюдают, как одна и та же модель обрабатывает десятки подсказок. Запустите подсказки выше в своей системе — увидите то же самое; статья даёт рамку и стартовые подсказки, чтобы вы понимали, на что смотреть.
| Model | Поведенческая тенденция | Лучше всего подходит, когда… |
|---|---|---|
| GPT-5.5 | Операционно‑прагматичный. Добавляет подсказки к исполнению, защитный код и вывод, удобный для последующей обработки. Силен в задачах с агентным и tool-use уклоном. | Ваше приложение конвейерит вывод модели в дальнейшее исполнение — агенты, рабочие процессы или пайплайны, где следующий шаг автоматизирован. |
| Claude Sonnet 4.6 | Забота уровня эксперта. Поднимает соображения сверх прямого запроса, затрагивает этику и методологию, производит очень читаемый код. | В вашем приложении человек ревьюит вывод модели — генерация контента, код‑ревью, аналитика, где важны мастерство и тщательность. |
| Gemini 3.1 Pro | Экономичный и прямой. Делает ровно то, что попросили, ни больше. Самое строгое следование схеме и наименьшие затраты токенов при той же работе. | У приложения строгие требования к выходу, предсказуемая стоимость — приоритет, или вы хотите, чтобы модель была точным инструментом, а не вдумчивым соавтором. |
Важная оговорка. Эти паттерны — тенденции, а не правила. Любую модель можно направить к любому из этих поведений правильной подсказкой: достаточно детальная системная подсказка заставит Gemini добавить тесты, сдержит Claude до «минимального» вывода или попросит GPT-5.5 пропустить юнит‑тесты. Важно то, что модель делает по умолчанию, до «руления» подсказкой. Именно с этим поведением вы живёте в продакшене, если специально не контр‑подсказываете.
Как протестировать на своей нагрузке
Упражнение выше воспроизводимо для любой нагрузки — и его стоит провести. Бенчмарк‑оценки полезны как первый фильтр, но поведенческие паттерны, важные именно для вашего приложения, видны только тогда, когда вы смотрите, как модели обрабатывают ваши конкретные подсказки.
Практическое руководство по запуску упражнения на вашем трафике:
- Выберите три репрезентативные категории подсказок. Не три случайных примера — три категории, охватывающие вашу нагрузку. Большинство продакшен‑систем можно разложить на несколько типов подсказок (извлечение, классификация, генерация, рассуждения, код, суммаризация). Выберите категории, на которые приходится основная часть трафика.
- Подберите 20–30 примеров на категорию. По возможности из реального трафика. Анонимизируйте, где нужно. Важно, чтобы подсказки были похожи на те, что ваше приложение реально видит, а не на вопросы из бенчмарков. Двадцать примеров на категорию достаточно, чтобы увидеть паттерны; тридцать — чтобы быть уверенными.
- Прогоните их через одну конечную точку для всех моделей. Агрегирующая конечная точка, совместимая с OpenAI, делает это радикально быстрее, чем гонять каждую модель через её SDK. Код в начале статьи — вся настройка. Одна и та же температура, те же параметры, та же подсказка — различия на выходе и будут различиями моделей.
- Сначала оценка качественная, потом количественная. Сначала просто посмотрите на ответы. Поведенческие паттерны обычно становятся очевидны в пределах первого десятка подсказок. Когда у вас появится гипотеза о поведении каждой модели на вашей нагрузке, можно строить рубрику для оценивания — но гипотеза рождается из наблюдения, а не из заранее заготовленного шаблона.
- Обращайте внимание на то, что модель добавляет. В бенчмарках вопрос — получает ли модель «правильный ответ». Поведенческий вопрос — что ещё модель делает. Добавляет ли тесты? Объясняет ли ход рассуждений? Поднимает ли риски? Выводит ли лишние поля, о которых вы не просили? Здесь и живут различия между моделями.
- Выберите модель, соответствующую вашему последующему процессу. Если downstream автоматизирован, вам нужна модель, чьё поведение по умолчанию даёт чистый, парсабельный вывод. Если downstream — ручное ревью, вам нужна модель, которая по умолчанию добавляет те суждения, которые важны ревьюеру. Правильный выбор зависит от того, что следует после модели.
Заключение
Выбор между GPT-5.5, Claude Sonnet 4.6 и Gemini 3.1 Pro — не о том, какая модель «лучшая». Он о том, какая модель соответствует форме вашей нагрузки — а этой формы бенчмарки не видят. Упражнение выше воспроизводимо за один день, если у вас готовы подсказки; ценность в том, что вы перестаёте гадать и начинаете наблюдать.
Для команд, которые запускают упражнение сами: самый простой сетап — единая конечная точка, совместимая с OpenAI, которая даёт доступ ко всем трём моделям под одной учётной записью. CometAPI — один из вариантов: вы направляете существующий OpenAI SDK на другой base URL, и параметр модели становится переменной.
Бенчмарки говорят, что модель может делать. Поведенческие паттерны говорят, что модель будет делать по умолчанию на ваших подсказках. Первый ответ опубликован. Второй нужно наблюдать. Двадцать подсказок на категорию, один день — и у вас будет ответ, которого не даст ни одна таблица лидеров.
Готовы к надёжной интеграции? Загляните на CometAPI и документация API — единый доступ к Claude Fable 5 и другим передовым моделям, единый биллинг и отказоустойчивость уровня enterprise. Регистрируйтесь сегодня и начинайте с щедрыми кредитами для новых пользователей — ваш следующий прорывной проект уже ждёт.