Приклади питань — Домен 1
27 питань у банку для цього домену · показано 8
Домен 1Сценарій 11 / 8
Дані продакшену показують: у 12% випадків агент пропускає get_customer і викликає lookup_order лише за іменем клієнта, що інколи призводить до помилкової ідентифікації акаунта й неправильних повернень. Яка зміна найефективніше вирішить цю проблему надійності?
AДодати programmatic prerequisite, що блокує lookup_order і process_refund до верифікованого customer ID
BПідсилити system prompt вимогою обов'язкової верифікації через get_customer перед операціями із замовленнями
CДодати few-shot приклади, де агент завжди першим викликає get_customer навіть за наявності номера замовлення
DВпровадити routing-класифікатор, що вмикає лише підмножину інструментів під конкретний тип запиту
✓ Правильна відповідь: A — Коли критична бізнес-логіка вимагає певної послідовності (верифікація перед поверненням коштів), programmatic enforcement дає детерміновані гарантії: він блокує lookup_order і process_refund, доки get_customer не поверне верифікований customer ID. Prompt-підходи — підсилення system prompt чи few-shot приклади з пріоритетом get_customer — лишаються ймовірнісними й мають ненульову ймовірність недотримання. Routing-класифікатор вирішує доступність інструментів, а не їх обов'язковий порядок виконання.
Домен 1Сценарій 12 / 8
Політика вимагає, щоб повернення понад $500 НІКОЛИ не виконувались автоматично, а йшли на людину. Зараз ця вимога описана в system prompt, але зрідка порушується. Що дасть детерміновану гарантію?
AHook, що перехоплює виклик process_refund і програмно блокує суми понад $500, віддаючи їх на escalate_to_human
BЧіткіше формулювання в system prompt із капіталізованим жирним NEVER і повтором правила про ліміт у $500
CFew-shot приклади, що демонструють відмову від автоматичних повернень на суми, які перевищують $500
DЗниження temperature моделі, щоб вона суворіше й стабільніше дотримувалась інструкцій system prompt
✓ Правильна відповідь: A — Коли бізнес-правило вимагає гарантованого дотримання на фінансово значущих діях, обирають hook з tool-call interception: він перехоплює вихідний виклик process_refund, блокує суми понад $500 і перенаправляє на escalate_to_human. Prompt-based підходи — капіталізований NEVER, few-shot приклади відмов чи зниження temperature — усі лишаються ймовірнісними й мають ненульовий рівень збоїв, тож не дають детермінованої гарантії на повернення понад поріг.
Домен 1Сценарій 13 / 8
Клієнт пише одним повідомленням одразу про три речі: повернення коштів за пошкоджений товар, зміну адреси доставки та скаргу на затримку. Яка стратегія обробки найкраща?
AДекомпозувати звернення на окремі concern'и, паралельно дослідити кожен на спільному контексті й синтезувати єдину відповідь
BОбробити лише перше питання про повернення коштів, а решту попросити надіслати окремими зверненнями пізніше
CЕскалювати все звернення на живого оператора, бо багатоскладові запити лежать поза межами компетенції агента
DВідповісти загальними формулюваннями без виклику жодних інструментів, щоб не плутати контексти трьох тем
✓ Правильна відповідь: A — Багатоскладові звернення декомпозують на окремі concern'и (повернення, зміна адреси, скарга), досліджують кожен на спільному контексті — за потреби паралельно — і зводять у єдину резолюцію. Обробка лише першого питання губить частину запиту. Ескалація всього на людину зайва, бо кожен item у межах можливостей агента. Загальна відповідь без інструментів не вирішує жодного з конкретних питань клієнта.
Домен 1Сценарій 14 / 8
Різні MCP-інструменти повертають дати в різних форматах: get_customer — Unix timestamp, lookup_order — ISO 8601, а статус — числовим кодом. Це плутає модель при міркуванні. Який механізм найкращий для нормалізації?
APostToolUse hook, що перехоплює виводи інструментів і нормалізує всі формати дат до єдиного вигляду ще до обробки моделлю
BІнструкція в system prompt самостійно конвертувати всі формати дат до єдиного вигляду під час міркування
CОкремий subagent, що перехоплює й переписує кожну відповідь інструмента, приводячи дати до спільного формату
DFew-shot приклади з різними форматами дат (Unix timestamp, ISO 8601, числовий код) і їх правильним трактуванням
✓ Правильна відповідь: A — PostToolUse hook перехоплює результати інструментів і трансформує їх — нормалізує Unix timestamp, ISO 8601 і числові коди статусу до єдиного формату — до обробки моделлю, що дає детерміновану нормалізацію. Інструкція в system prompt і few-shot приклади лишаються ймовірнісними: модель може помилитись у конвертації. Окремий subagent для переписування кожної відповіді інструмента — надлишкова архітектура для суто механічної нормалізації форматів.
Домен 1Сценарій 15 / 8
Ви реалізуєте agentic loop. Що має визначати, продовжувати виконувати інструменти чи завершити й показати фінальну відповідь?
AПоле stop_reason у відповіді API визначає наступний крок циклу виконання
BНаявність будь-якого тексту в assistant-повідомленні як сигнал завершити цикл
CФіксований ліміт ітерацій як основний механізм зупинки роботи агента
DПарсинг natural-language фраз на кшталт «Done» чи «Завершено» у відповіді
✓ Правильна відповідь: A — Керування agentic loop будують на полі stop_reason: значення «tool_use» означає виконати інструмент і продовжити цикл, а «end_turn» — завершити й показати фінальну відповідь. Решта підходів — anti-patterns: перевірка наявності тексту хибна, бо модель часто додає текст разом із tool_use; жорсткий ліміт ітерацій обриває валідну роботу; парсинг natural-language сигналів ненадійний через варіативність формулювань.
Домен 1Сценарій 16 / 8
Колега пропонує завершувати agentic loop, коли модель згенерувала текстову відповідь без виклику інструмента, АБО після 10 ітерацій «про всяк випадок». Чому це проблема?
AЦе anti-patterns: і перевірка тексту, і жорсткий ліміт ітерацій ненадійні
BПроблеми немає — це стандартний рекомендований підхід до зупинки циклу
CПроблема лише в значенні ліміту: з порогом 50 замість 10 підхід стає коректним
DТекст треба парсити регулярками на ключові слова — лише тоді зупинка надійна
✓ Правильна відповідь: A — Перевірка наявності тексту, ліміт ітерацій як основний стоп-механізм і парсинг natural-language — класичні anti-patterns: модель часто додає текст разом із tool_use, а фіксований ліміт обриває валідну роботу. Коректне завершення базують на stop_reason == «end_turn». Зміна порогу ітерацій не усуває хибності самого механізму, а регулярки по ключових словах лишаються крихкими до формулювань.
Домен 1Сценарій 37 / 8
Запустивши систему на темі «вплив AI на креативні індустрії», ви бачите: усі subagent'и відпрацювали успішно, але фінальні звіти охоплюють лише візуальне мистецтво й повністю пропускають музику, письменство та кіно. У логах coordinator'а: він розбив тему на «AI in digital art», «AI in graphic design», «AI in photography». Найімовірніша корінна причина?
AДекомпозиція coordinator'а надто вузька — призначення не покривають усіх доменів самої теми
BSynthesis-агенту бракує інструкцій виявляти прогалини покриття серед отриманих ним знахідок
CЗапити web-search агента надто вузькі, тож їх варто розширити для ширшого охоплення джерел
DDocument-аналіз агент відсіює не-візуальні джерела через надто жорсткі критерії релевантності
✓ Правильна відповідь: A — Логи прямо показують причину: coordinator розклав «креативні індустрії» лише на візуальні підтеми (digital art, graphic design, photography), пропустивши музику, письменство й кіно, тож його призначення не покрили всіх релевантних доменів теми. Subagent'и коректно зробили те, що їм призначили в межах заданого scope. Решта варіантів помилково звинувачують нижчих агентів: брак gap-аналізу в synthesis, вузькість пошукових запитів чи жорсткий фільтр релевантності в document-аналізі — жоден з них не пояснює, чому non-visual домени взагалі не потрапили у призначення.
Домен 1Сценарій 38 / 8
Synthesis-subagent видає звіти так, ніби не бачив знахідок web-search і document-агентів. Coordinator їх викликав, але synthesis «не знає» їхніх результатів. Найімовірніша причина?
ASubagent'и не успадковують контекст автоматично — знахідки треба явно передавати у промпт synthesis-агента
BSynthesis-агенту бракує доступу до інструмента Task, без якого він зовсім не бачить чужих результатів роботи
CКоординатор використовує застарілу версію SDK, що чомусь не прокидає контекст між окремими агентами системи
DПотрібно підвищити max_tokens synthesis-агента, щоб він зміг умістити всі результати решти агентів одразу
✓ Правильна відповідь: A — Subagent'и працюють з ізольованим контекстом і не успадковують історію coordinator'а; знахідки web-search і document-агентів треба явно вкладати у промпт synthesis-агента. Інструмент Task потрібен для спавну subagent'ів, а не для отримання чужих результатів. Версія SDK тут ні до чого — ізоляція контексту є дизайном, а не багом. Підвищення max_tokens впливає лише на довжину виводу, а не на те, чи дані взагалі потрапили у промпт.