"Пример из теста на работу с кодом в новом reasoning бенчмарке Как я уже говорил раньше, вторая версия моего бенчмарка не только сильнее нагружает современные модели, но и позволяет раскрыть исходники некоторых тестов. Вот пример простого теста на понимание кода: Which specs would fail, if I add a new feature: after authorizing any transaction larger than 3000, the system automatically blocks the card due to “Large Transaction Risk.” We do not add new event type, just extend the existing command handler. Source code: __Кстати, обратим внимание, что я вопрос ставлю до исходников файла. Это мне портит кэш, зато позволяет в среднем облегчить жизнь моделям и повысить качество на несколько процентов.__ Файл-исходник к этой задаче во вложении в первом комментарии. Там очень простой event-driven aggregate состояний для кредитной карточки вместе со спецификациями на желаемое поведение. В реальности, кстати, такая логика на порядки сложнее. Скажем, Claude Sonnet 3.5 отвечает на вопрос так: ``` { ""short_thought_steps"": [ ""1. New feature: block card if transaction > 3000"", ""2. This affects authorize_transaction command"", ""3. Current specs that test large transactions:"", ""4. 'authorize_transaction_success' tests 2000 amount - would pass"", ""5. But any spec testing transactions > 3000 would fail"", ""6. Looking for specs with large transactions..."" ], ""failing_spec_names"": [ ""authorize_transaction_success"" ] } ``` Кстати, смотрим внимательно, на 4-м шаге LLM-ка мыслила правильно, но потом что-то у нее пошло не так. А вот o1 отвечает на этот вопрос с подвохом правильно: ``` { ""short_thought_steps"": [ ""Check specs that authorizeTransaction with amounts > 3000"", ""No spec has an authorization > 3000"", ""Hence no test scenario triggers the new block logic"", ""No spec fails"" ], ""failing_spec_names"": [] } ``` Кстати, еще на этот вопрос отвечают правильно только o3-mini и microsoft phi-4 (из моделей, которые добавлены в бенчмарк на данном этапе). Ваш, @llm_under_hood 🤗"