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