Приклади питань — Домен 2
20 питань у банку для цього домену · показано 8
Домен 2Сценарій 11 / 8
Логи показують, що агент часто кличе get_customer на запити про замовлення (напр. «перевір моє замовлення #12345») замість lookup_order. Обидва інструменти мають мінімальні описи («Retrieves customer information» / «Retrieves order details») і приймають схожі формати ідентифікаторів. Який найефективніший перший крок?
AРозширити опис кожного інструмента: очікувані формати входу, приклади запитів, edge cases і чіткі межі застосування
BДодати 5–8 ретельних few-shot прикладів у system prompt, що скеровують order-запити саме на lookup_order
CРеалізувати окремий routing-шар, що парсить ввід і наперед обирає інструмент за ключовими словами
DОб'єднати обидва інструменти в один lookup_entity, що сам визначає потрібний бекенд за вводом
✓ Правильна відповідь: A — Описи інструментів — основний механізм вибору для LLM. За мінімальних описів моделі бракує контексту, щоб розрізнити схожі інструменти; розширення опису форматами входу, прикладами запитів, edge cases і межами застосування б'є прямо в причину. Few-shot приклади додають токени, не усуваючи її. Окремий routing-шар з парсингом ключових слів — over-engineering, що обходить розуміння моделі. Злиття в lookup_entity — валідна, але важча архітектурна зміна, ніж потрібно для «першого кроку».
Домен 2Сценарій 12 / 8
Усі MCP-інструменти повертають при збої однаковий рядок «Operation failed». Через це агент однаково реагує і на таймаут, і на порушення політики, і на невалідний ввід. Як це виправити?
AПовертати структуровані метадані: errorCategory, isRetryable і людиночитний опис
BДодати у system prompt інструкцію завжди автоматично повторювати спробу при збої
CЛогувати помилки на бекенді детальніше, лишивши агенту той самий загальний рядок
DПідвищити timeout усіх інструментів, щоб технічні помилки траплялись помітно рідше
✓ Правильна відповідь: A — Уніфіковані помилки не дають агенту приймати правильні рішення про відновлення. Структуровані метадані — категорія transient/validation/permission, ознака isRetryable і людиночитний опис — дозволяють ретраїти transient-збої, пояснювати business-помилки клієнту й не марнувати спроби на non-retryable. Інструкція завжди ретраїти небезпечно повторює навіть невідновлювані дії. Детальніше логування на бекенді чи вищий timeout не міняють того загального рядка, який бачить сам агент.
Домен 2Сценарій 13 / 8
process_refund відхиляє запит, бо сума перевищує ліміт політики (бізнес-правило, не технічний збій). Що інструмент має повернути, щоб агент відреагував коректно?
AСтруктуровану помилку isError з retriable:false і клієнт-дружнім поясненням причини
BТой самий формат, що й для технічного таймауту, аби агент повторив виклик ще раз
CПорожній успішний результат без позначки помилки, щоб зайвий раз не турбувати клієнта
DГолий HTTP 500 без категорії помилки, прапора retriable чи опису її причини знову
✓ Правильна відповідь: A — Порушення бізнес-правила (перевищення ліміту суми) слід позначати isError з retriable:false і додавати зрозуміле для клієнта пояснення причини відмови — тоді агент комунікує коректно й не марнує спроби на ретраї. Формат таймауту спровокує зайві повтори ідентичного виклику; порожній успіх приховує помилку й вводить агента в оману; голий 500 без метаданих не дає контексту для правильної реакції.
Домен 2Сценарій 14 / 8
Команда поступово дала агенту 18 інструментів. Тепер він почав плутатись у виборі й інколи бере не той інструмент. Який принцип допоможе найбільше?
AЗвузити набір до 4–5 інструментів, релевантних саме ролі цього агента
BДодати ще інструментів-«хелперів», щоб завжди був точний інструмент під кейс
CПерейменувати всі 18 наявних інструментів у коротші й лаконічніші назви
DЗавжди форсувати tool_choice на перший інструмент у списку доступних
✓ Правильна відповідь: A — Завелика кількість інструментів (18 замість 4–5) деградує надійність вибору, бо зростає складність рішення для моделі — звуження набору під конкретну роль агента б'є прямо в причину. Додавання ще інструментів лише погіршує перевантаження; перейменування не міняє їх кількості й складності вибору; форсування першого через tool_choice ламає здатність агента обирати доречний інструмент під контекст.
Домен 2Сценарій 35 / 8
Synthesis-агент часто має перевіряти конкретні факти, повертаючи керування coordinator'у → web-search → знову synthesis (+2–3 round trips, +40% latency). 85% перевірок — прості факт-чеки (дати, імена, статистика), 15% — глибше дослідження. Як зменшити overhead, зберігши надійність?
AДати synthesis-агенту scoped-інструмент verify_fact для простих lookup'ів, а складні лишити через coordinator
BНакопичувати всі потреби верифікації й одним батчем повертати їх coordinator'у вже наприкінці проходу синтезу
CДати synthesis-агенту повний необмежений доступ до всіх web-search інструментів для самостійної перевірки фактів
DWeb-search агент має проактивно кешувати додатковий контекст навколо кожного джерела «про запас» заздалегідь
✓ Правильна відповідь: A — Принцип найменших привілеїв: scoped verify_fact покриває 85% простих факт-чеків (дати, імена, статистика) без round trips, а складні 15% лишаються в наявному патерні координації через coordinator. Батч наприкінці створює блокуючі залежності й затримує синтез. Повний доступ до web-search порушує separation of concerns і провокує misuse. Спекулятивний кеш не передбачить, які саме факти знадобляться, тож не дасть надійної економії.
Домен 2Сценарій 36 / 8
Synthesis-агент час від часу намагається сам робити веб-пошуки й використовує інструменти поза своєю спеціалізацією, псуючи результат. Який принцип розподілу інструментів допоможе?
AОбмежити набір інструментів кожного subagent'а лише тими, що релевантні саме його ролі
BДати всім subagent'ам однаковий повний набір усіх інструментів заради гнучкості всієї системи
CПрибрати в synthesis-агента геть усі інструменти, лишивши йому тільки роботу з текстом
DФорсувати tool_choice synthesis-агента на web-search, щоб уніфікувати його поведінку з рештою
✓ Правильна відповідь: A — Агенти, що мають інструменти поза своєю спеціалізацією, схильні їх неправильно вживати (cross-specialization misuse). Рішення — scoped tool access: давати кожному subagent'у лише ті інструменти, що релевантні його ролі, запобігаючи misuse. Однаковий повний набір усім лише посилює проблему. Повне позбавлення synthesis-агента інструментів зламає його легітимні задачі. Форсування tool_choice на web-search узагалі помилкове, бо нав'язує synthesis-агенту чужу для нього дію.
Домен 2Сценарій 47 / 8
Інженер просить знайти всі місця виклику конкретної функції по кодбазі. Який built-in інструмент обрати?
AGrep — пошук за вмістом файлів: імена функцій і рядки помилок
BGlob — пошук файлів за патерном імені чи розширення по дереву
CRead — послідовно читати кожен файл цілком, шукаючи виклики очима
DBash із інтерактивним редактором для ручного перегляду коду
✓ Правильна відповідь: A — Grep призначений для пошуку за вмістом коду (наприклад, усі виклики функції за іменем, рядки помилок чи import'и). Пошук файлів за патерном імені знаходить лише файли, а не входження тексту в них. Читання кожного файлу цілком читає вміст конкретного файлу, а не шукає по всіх одразу. Інтерактивний редактор через Bash тут недоречний.
Домен 2Сценарій 48 / 8
Потрібно знайти всі тестові файли за патерном **/*.test.tsx по проєкту. Який інструмент пасує?
AGlob — пошук шляхів файлів за патерном імені чи розширення
BGrep — пошук текстових входжень усередині вмісту файлів
CEdit — точкова заміна фрагмента за унікальним текстом-якорем
DWrite — створення нового файлу або повний перезапис наявного
✓ Правильна відповідь: A — Glob знаходить файли за патернами імен (наприклад, **/*.test.tsx). Пошук за вмістом призначений для входжень тексту в коді, а не для перебору шляхів. Точкова заміна за якорем і створення файлу служать для модифікації чи генерації, а не для пошуку.