Приклади питань — Домен 4
29 питань у банку для цього домену · показано 8
Домен 4Сценарій 51 / 8
Команда хоче зменшити витрати на API. Зараз real-time виклики живлять два воркфлоу: (1) блокуючий pre-merge check, який має завершитись до merge, і (2) звіт по tech debt, що генерується вночі для ранкового перегляду. Менеджер пропонує перевести обидва на Message Batches API заради 50% економії. Як оцінити?
AПеревести на batch лише нічні звіти по tech debt, а блокуючі pre-merge checks свідомо лишити на real-time
BПеревести обидва воркфлоу на batch і відстежувати готовність кожного результату через status polling
CЛишити обидва воркфлоу на real-time, щоб уникнути проблем із кореляцією й порядком результатів
DПеревести обидва на batch, додавши timeout-fallback на real-time для запізнілих результатів
✓ Правильна відповідь: A — Batches API дає 50% економії, але час обробки — до 24 годин без гарантії latency. Це неприйнятно для блокуючого pre-merge check, який має завершитись до merge, але ідеально для нічних звітів, що читають уранці. Переведення обох на batch покладається на «зазвичай швидше» — неприйнятно для блокуючого кроку. Побоювання про порядок результатів хибне: відповіді корелюються через custom_id. Timeout-fallback на real-time — зайва складність, що не усуває ризику для блокуючого кроку.
Домен 4Сценарій 52 / 8
PR змінює 14 файлів у модулі обліку. Single-pass рев'ю всіх файлів разом дає непослідовний результат: десь детальний фідбек, десь поверхневий, очевидні баги пропущені, а інколи фідбек суперечливий — патерн позначено проблемним в одному файлі й схвалено ідентичний код в іншому. Як перебудувати рев'ю?
AРозбити на сфокусовані проходи: окремий аналіз кожного файлу й integration-прохід по крос-файлах
BВимагати від розробників розбивати великі PR на групи по 3–4 файли ще до запуску авто-рев'ю в CI
CПерейти на модель із більшим контекстним вікном, щоб умістити всі 14 файлів разом за один прохід
DЗробити три незалежні проходи й флагати лише ті проблеми, що з'явились мінімум у двох із них тут
✓ Правильна відповідь: A — Корінь проблеми — attention dilution при обробці багатьох файлів разом: глибина уваги розмивається, тому фідбек нерівний і суперечливий. Розбиття на per-file проходи дає рівну глибину для кожного файлу, а окремий integration-прохід ловить крос-файлові потоки даних. Перекладання поділу PR на розробників перекладає тягар на людей і не лікує причину. Більше контекстне вікно — хибне уявлення: більший контекст не означає кращу увагу до кожного файлу. Три проходи з порогом «мінімум у двох» придушують реальні баги, які ловляться лише в одному з проходів.
Домен 4Сценарій 53 / 8
Ваш промпт каже «перевір, що коментарі точні», і це дає багато false positives. Як переформулювати критерій, щоб підвищити точність?
AДати явний категоріальний критерій: флагати коментар, лише коли заявлена в ньому поведінка суперечить коду
BДодати загальну настанову бути консервативним і повідомляти лише про high-confidence знахідки в коментарях
CПросити модель саму оцінювати власну впевненість і фільтрувати знахідки нижче певного порогу
DЗбільшити max_tokens, щоб модель мала більше простору ретельніше перевіряти кожен коментар
✓ Правильна відповідь: A — Явний категоріальний критерій — флагати лише коли заявлена в коментарі поведінка прямо суперечить фактичній поведінці коду — дає моделі чітку межу рішення й різко знижує false positives. Розмиті заклики бути консервативним чи повідомляти лише high-confidence не задають, що саме звітувати, тож precision не зростає. Самооцінка впевненості погано калібрована й не замінює конкретного критерію. Збільшення max_tokens не стосується точності класифікації — воно лише дає більше місця під вивід.
Домен 4Сценарій 54 / 8
Менеджер пропонує знизити false positives, додавши в промпт «звітуй лише про high-confidence проблеми» та «будь обережним». Чому це слабке рішення?
AРозмиті заклики бути консервативним не дають precision; потрібні категоріальні критерії
BЦе сильне й цілком достатнє рішення, саме так і варто формулювати інструкції для рев'ю
CПроблема лише в слові обережним, тож достатньо замінити його на суворішим і все запрацює
DДостатньо знизити temperature до нуля, і тоді кількість false positives помітно зменшиться
✓ Правильна відповідь: A — Розмиті заклики до обережності чи впевненості не підвищують precision. Дієве — специфічні категоріальні критерії: що саме звітувати (баги, security-проблеми) і що пропускати (дрібний стиль). Заміна окремих слів чи нульова temperature суті завдання не змінюють.
Домен 4Сценарій 55 / 8
Та сама Claude-сесія, що згенерувала код, гірше знаходить у ньому власні тонкі помилки, навіть з інструкцією «перевір себе» чи extended thinking. Який підхід ефективніший?
AДругий незалежний інстанс Claude без reasoning-контексту генерації для свіжого рев'ю коду
BДодати в той самий промпт інструкцію уважно перевірити власний згенерований код щонайменше двічі
CУвімкнути extended thinking у тій самій сесії, щоб модель глибше проаналізувала власні рішення
DПідняти temperature на етапі самоперевірки, щоб модель розглянула альтернативні трактування коду
✓ Правильна відповідь: A — Модель зберігає reasoning-контекст генерації й менш схильна сумніватись у власних рішеннях у межах тієї самої сесії. Незалежний review-інстанс підходить до коду «свіжим поглядом» без цього контексту й ефективніше ловить тонкі помилки. Інструкція перевірити себе двічі лишається в тому ж контексті й не усуває упередженості. Extended thinking у тій самій сесії поглиблює міркування на тому ж reasoning-сліді. Підняття temperature додає варіативності, але не дає незалежної точки зору.
Домен 4Сценарій 56 / 8
Детальні інструкції все одно дають непослідовний формат фідбеку рев'ю. Який прийом найкраще дає консистентний, actionable формат?
AFew-shot приклади бажаного формату виводу рев'ю: location, issue, severity, suggested fix
BЩе детальніша прозова специфікація бажаного формату з повним переліком обов'язкових полів виводу
CПросити модель самостійно вигадувати зручну для неї структуру виводу під кожен окремий прохід
DЗбільшити кількість проходів рев'ю, щоб формат поступово стабілізувався між повторними запусками
✓ Правильна відповідь: A — Few-shot приклади — найдієвіший спосіб домогтися консистентного, actionable формату (location, issue, severity, suggested fix), коли самих текстових інструкцій недостатньо: модель узагальнює показаний патерн. Детальніша проза вже не спрацювала за умовою й не дає стабільності. Свобода вибору формату для моделі прямо суперечить меті консистентності. Більше проходів рев'ю не стосується формату — вони лише повторюють ту саму нестабільність.
Домен 4Сценарій 57 / 8
Ви ганяєте документи через Batches API (обробка до 24 год) і маєте дотриматись SLA 30 годин. Як спланувати подачу батчів?
AПодавати батчі у вікнах близько 4 годин, щоб гарантувати дотримання SLA
BПодати все одним великим батчем раз на добу й сподіватись, що обробка встигне вчасно
CПерейти на синхронний API, бо batch-обробка не підходить для жодних SLA-обмежень
DПодавати кожен документ окремим мінібатчем щохвилини протягом доби
✓ Правильна відповідь: A — Частоту подачі рахують від SLA-обмежень: при обробці до 24 годин і цілі 30 годин вікна подачі близько 4 годин залишають достатній запас і гарантують дотримання SLA. Один великий батч раз на добу ризикує не вкластися у вікно, бо сама обробка може зайняти всі 24 години. Повна відмова від batch на користь синхронного API втрачає економію коштів, яку дає пакетна обробка. Подача по одному документу окремими батчами неефективна за накладними витратами й нічого не виграє за часом.
Домен 4Сценарій 58 / 8
Одна категорія перевірок дає стільки false positives, що розробники втрачають довіру навіть до точних категорій. Який прагматичний крок?
AТимчасово вимкнути категорію з високим FP, паралельно покращуючи її промпт
BЛишити все як є, оскільки довіра розробників відновиться сама собою з часом
CЗнизити загальну кількість усіх знахідок наполовину незалежно від категорії
DВидалити всі категорії перевірок, окрім перевірки стилю коду
✓ Правильна відповідь: A — Високий рівень false positives в одній категорії підриває довіру навіть до точних категорій. Прагматично — тимчасово вимкнути проблемну категорію, відновити довіру й паралельно доопрацьовувати її промпт для зниження хибних спрацювань. Бездіяльність не усуває причину й довіра не повернеться сама. Сліпе скорочення всіх знахідок наполовину ріже й справжні баги. Лишання тільки перевірки стилю викидає цінні категорії й не вирішує проблему адресно.