Приклади питань — Домен 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, але ідеально для нічних звітів. B покладається на «зазвичай швидше» — неприйнятно для блокуючого; C — хибне уявлення (результати корелюються через custom_id); D — зайва складність.
Домен 4Сценарій 52 / 8
PR змінює 14 файлів у модулі обліку. Single-pass рев'ю всіх файлів разом дає непослідовний результат: десь детальний фідбек, десь поверхневий, очевидні баги пропущені, а інколи фідбек суперечливий — патерн позначено проблемним в одному файлі й схвалено ідентичний код в іншому. Як перебудувати рев'ю?
AРозбити на сфокусовані проходи: аналіз кожного файлу окремо на локальні проблеми, потім окремий integration-прохід по крос-файлових потоках даних
BВимагати від розробників ділити великі PR на 3–4 файли перед авто-рев'ю
CПерейти на модель із більшим контекстним вікном, щоб умістити всі 14 файлів за раз
DЗробити три незалежні проходи й флагати лише ті проблеми, що з'явились мінімум у двох
✓ Правильна відповідь: A — Корінь — attention dilution при обробці багатьох файлів разом. Розбиття на per-file проходи + окремий integration-прохід дає рівну глибину й ловить крос-файлові проблеми. B перекладає тягар на людей; C — хибне уявлення (більший контекст ≠ краща увага); D придушує реальні баги, які ловляться лише інколи.
Домен 4Сценарій 53 / 8
Ваш промпт каже «перевір, що коментарі точні», і це дає багато false positives. Як переформулювати критерій, щоб підвищити точність?
AДати явний критерій: «флагати коментар, лише коли заявлена в ньому поведінка суперечить фактичній поведінці коду»
BДодати «будь консервативним і повідомляй лише high-confidence знахідки»
CПросити модель самій оцінювати впевненість і фільтрувати за нею
DЗбільшити max_tokens, щоб модель ретельніше перевіряла
✓ Правильна відповідь: A — Явні категоріальні критерії («флагати, лише коли заявлене суперечить реальній поведінці») працюють краще за розмиті інструкції. Загальні «будь консервативним / лише high-confidence» (B, C) не підвищують точність так, як конкретні критерії; max_tokens (D) не про це.
Домен 4Сценарій 54 / 8
Менеджер пропонує знизити false positives, додавши в промпт «звітуй лише про high-confidence проблеми» та «будь обережним». Чому це слабке рішення?
AЗагальні інструкції на кшталт «будь консервативним» чи «лише high-confidence» не підвищують precision; потрібні конкретні категоріальні критерії, що визначають, які проблеми звітувати, а які пропускати
BЦе сильне рішення — саме так і треба робити
CПроблема лише в слові «обережним»; досить замінити його на «суворим»
DДостатньо знизити temperature до нуля
✓ Правильна відповідь: A — Розмиті заклики до обережності/впевненості не покращують precision. Дієве — специфічні категоріальні критерії: що саме звітувати (баги, security) і що пропускати (дрібний стиль). Заміна слів (C) чи temperature (D) суті не міняють.
Домен 4Сценарій 55 / 8
Та сама Claude-сесія, що згенерувала код, гірше знаходить у ньому власні тонкі помилки, навіть з інструкцією «перевір себе» чи extended thinking. Який підхід ефективніший?
AВикористати другий незалежний інстанс Claude (без reasoning-контексту генерації) для рев'ю коду
BДодати в той самий промпт інструкцію «уважно перевір власний код двічі»
CУвімкнути extended thinking у тій самій сесії
DПідняти temperature на етапі самоперевірки
✓ Правильна відповідь: A — Модель зберігає reasoning-контекст генерації й менш схильна сумніватись у власних рішеннях у тій самій сесії. Незалежний review-інстанс без цього контексту ефективніше ловить тонкі проблеми, ніж self-review інструкції (B), extended thinking (C) чи temperature (D).
Домен 4Сценарій 56 / 8
Детальні інструкції все одно дають непослідовний формат фідбеку рев'ю. Який прийом найкраще дає консистентний, actionable формат?
AFew-shot приклади, що демонструють бажаний формат виводу (location, issue, severity, suggested fix)
BЩе детальніша прозова специфікація формату
CПросити модель саму вигадати формат щоразу
DЗбільшити кількість проходів рев'ю
✓ Правильна відповідь: A — Few-shot приклади — найдієвіший спосіб домогтися консистентного, actionable формату (location/issue/severity/fix), коли самих інструкцій недостатньо. Більше прози (B) чи свобода формату (C) не дають стабільності; більше проходів (D) не про формат.
Домен 4Сценарій 57 / 8
Ви ганяєте документи через Batches API (обробка до 24 год) і маєте дотриматись SLA 30 годин. Як спланувати подачу батчів?
AПодавати батчі у вікнах ~4 години, щоб гарантувати 30-годинний SLA з урахуванням до 24 год обробки
BПодати все одним батчем раз на добу й сподіватись, що встигне
CПерейти на синхронний API, бо batch не підходить для жодних SLA
DПодавати по одному документу окремими батчами щохвилини
✓ Правильна відповідь: A — Частоту подачі рахують від SLA-обмежень: при обробці до 24 год і цілі 30 год вікна подачі ~4 год гарантують дотримання. Один батч на добу (B) ризикує не вкластися; повна відмова від batch (C) втрачає економію; по одному документу (D) неефективно.
Домен 4Сценарій 58 / 8
Одна категорія перевірок дає стільки false positives, що розробники втрачають довіру навіть до точних категорій. Який прагматичний крок?
AТимчасово вимкнути високо-FP категорію, щоб відновити довіру, паралельно покращуючи промпт для неї
BЛишити все як є — довіра відновиться сама
CЗнизити загальну кількість усіх знахідок наполовину
DВидалити всі категорії, крім стилю
✓ Правильна відповідь: A — Високий рівень FP у категорії підриває довіру й до точних категорій. Прагматично — тимчасово вимкнути проблемну категорію, відновити довіру й паралельно доопрацьовувати промпт. Бездіяльність (B), сліпе скорочення (C) чи лишання лише стилю (D) не розв'язують проблему адресно.