Що сталося

Автори прогнали обидві моделі через кілька прикладних сценаріїв. DeepSeek стабільніше дотримувався інструкцій і вихідних схем; GPT-5.5 частіше допускав уникнені відхилення від заданого формату.

У задачі python-log-redactor потрібно було замаскувати чутливі фрагменти в логах одним регулярним виразом із перекривними шаблонами. DeepSeek зібрав єдиний regex; GPT-5.5 розбив роботу на частини — це підвищує ризик пропусків на стиках патернів.

У vendor-delay-update DeepSeek повернув рівно те, що просив промпт. GPT-5.5 додав зайві поля та пояснення, яких не було в специфікації. Для пайплайнів із жорсткою валідацією це ламає інтеграцію.

У messy-orders-to-json обидві моделі спрацювали однаково: валідний JSON без суттєвих відмінностей. На «брудних» даних без жорсткої схеми перевага не проявилася.

Чому це важливо

У продакшені LLM часто виступають як «розумний парсер»: витягнути дані за схемою, згенерувати конфіг, пройти лінтер. Тут важливіша точність, ніж краса тексту. Модель, яка «дописує від себе», створює приховані баги: зайві ключі в JSON, невірні межі regex, розбіжність із Pydantic-схемою.

Для команд, що обирають модель під агентні пайплайни, такі head-to-head тести корисніші маркетингових бенчмарків. Вони показують поведінку на задачах, близьких до реальної розробки.

На практиці

1. Тестуйте моделі на своїх промптах зі схемами, а не лише на загальних рейтингах.
2. Для задач «строго за інструкцією» перевіряйте, чи не додає модель зайві поля.
3. У regex- і парсинг-задачах порівнюйте кількість кроків: один прохід надійніший за кілька.
4. Тримайте автоматичну валідацію виходу (JSON Schema, Pydantic) — модель може помилитися навіть при високому рахунку.
5. На «брудних» даних без жорсткої схеми різниця між топ-моделями може зникнути.

Підсумок

DeepSeek V4 Pro у цьому порівнянні точніший і передбачуваніший на задачах зі суворими інструкціями та схемами. Для генерації «гарного тексту» розрив може бути менш помітним; для інженерних пайплайнів — критичний. Деталі бенчмарку — в оригіналі.