Приклади питань — Домен 5
24 питань у банку для цього домену · показано 8
Домен 5Сценарій 11 / 8
Агент дає лише 55% first-contact resolution при цілі 80%. Логи показують: він ескалює прості кейси (стандартні заміни з фото-доказом), але намагається сам обробляти складні ситуації з винятками з політики. Як найкраще покращити калібрування ескалації?
AДодати у system prompt явні критерії ескалації з few-shot прикладами «коли ескалювати vs вирішувати самостійно»
BПросити агента самооцінювати confidence (1–10) і автоматично маршрутизувати до людини нижче порогу
CРозгорнути окрему classifier-модель на історичних тікетах, що передбачає потребу ескалації
DДодати sentiment-аналіз і ескалювати при перевищенні порогу негативу
✓ Правильна відповідь: A — Корінь проблеми — нечіткі межі рішення; явні критерії з прикладами б'ють прямо в нього і є пропорційним першим кроком. Самооцінка confidence (B) погано калібрована — агент уже впевнений на складних кейсах. C — over-engineering. D вирішує іншу проблему: sentiment не корелює зі складністю кейсу.
Домен 5Сценарій 12 / 8
lookup_order повертає 40+ полів на замовлення, з яких для типового кейсу повернення релевантні лише ~5. У довгих діалогах ці виводи накопичуються й з'їдають контекст. Який підхід найкращий?
AОбрізати verbose-виводи інструмента до релевантних полів ще до того, як вони потраплять у контекст
BЗбільшити max_tokens, щоб модель умістила всі поля
CПеріодично робити progressive summarization усієї історії, включно з виводами замовлень
DВимкнути lookup_order і просити клієнта диктувати деталі замовлення вручну
✓ Правильна відповідь: A — Виводи інструментів накопичуються й споживають токени непропорційно до релевантності. Тримання лише потрібних полів — пряме рішення. Збільшення max_tokens (B) не стосується контексту-вікна. Агресивна сумаризація (C) ризикує втратити числа/дати. D погіршує UX.
Домен 5Сценарій 13 / 8
get_customer повертає кількох клієнтів, що збігаються за наданим іменем. Як агенту коректно вчинити?
AПопросити додатковий ідентифікатор (email, номер замовлення), а не обирати збіг за евристикою
BОбрати найновіший за датою створення акаунт як найімовірніший
CОбрати акаунт з найбільшою кількістю замовлень
DОб'єднати всі збіги в один профіль і продовжити
✓ Правильна відповідь: A — Кілька збігів вимагають уточнення (запиту додаткових ідентифікаторів), а не евристичного вибору, бо помилкова ідентифікація веде до неправильних дій з чужим акаунтом.
Домен 5Сценарій 14 / 8
На початку діалогу клієнт прямо й однозначно вимагає з'єднати його з живим оператором. Як вчинити агенту?
AВиконати ескалацію негайно, без спроби спершу самостійно розслідувати кейс
BСпершу спробувати вирішити питання, і лише якщо не вдасться — ескалювати
CЗапитати причину вимоги й переконати клієнта, що агент впорається
DПідняти confidence-поріг і продовжити автономно
✓ Правильна відповідь: A — Явну вимогу клієнта про людину виконують негайно. Це відрізняється від ситуації, де питання просте — там можна запропонувати вирішити, ескалюючи лише якщо клієнт наполягає.
Домен 5Сценарій 15 / 8
У довгих діалогах ви робите progressive summarization історії. Згодом помічаєте, що агент «забуває» точну суму повернення, дату покупки й обіцянки, дані клієнту. Як це виправити?
AВитягувати транзакційні факти (суми, дати, номери замовлень, статуси) в окремий persistent «case facts» блок, що додається в кожен промпт поза сумаризованою історією
BПовністю відмовитись від сумаризації й завжди слати всю історію
CСумаризувати агресивніше, щоб лишалось більше місця під нові факти
DЗберігати факти лише в системі логування на бекенді
✓ Правильна відповідь: A — Ризик progressive summarization — згортання чисел, відсотків, дат і очікувань клієнта у розмиті формулювання. Рішення — тримати точні транзакційні факти в persistent-блоці поза сумаризованою історією. B нереалістично за токенами; C погіршує проблему; D не доходить до моделі.
Домен 5Сценарій 16 / 8
Клієнт просить price-match під ціну конкурента. Політика описує лише коригування під власні попередні ціни магазину й нічого не каже про конкурентів. Що має зробити агент?
AЕскалювати, бо політика мовчить/неоднозначна щодо саме цього запиту
BВідмовити, бо якщо не написано — значить заборонено
CПогодити price-match, бо явної заборони немає
DСамостійно вигадати розумний відсоток знижки як компроміс
✓ Правильна відповідь: A — Коли політика неоднозначна або мовчить щодо конкретного запиту — це тригер ескалації (policy gap), а не лише складність кейсу. Самостійне рішення (B, C, D) ризикує суперечити майбутній політиці.
Домен 5Сценарій 27 / 8
Під час тривалої сесії дослідження великої кодбази Claude починає давати непослідовні відповіді й посилатися на «типові патерни» замість конкретних класів, знайдених раніше. Як протидіяти цій деградації контексту?
AВести scratchpad-файл із ключовими знахідками й звертатися до нього в наступних питаннях
BПросто перезапустити сесію з нуля при кожному новому питанні
CПідвищити temperature, щоб відповіді стали різноманітнішими
DІгнорувати — це нормальна поведінка для довгих сесій
✓ Правильна відповідь: A — У розширених сесіях контекст деградує (модель «зісковзує» на типові патерни). Scratchpad-файли з ключовими знахідками, на які агент спирається далі, допомагають це компенсувати. Повний рестарт щоразу (B) втрачає прогрес; temperature (C) не стосується; ігнорування (D) лишає проблему.
Домен 5Сценарій 28 / 8
Під час тривалої багатофазної сесії контекст заповнюється багатослівним discovery-виводом, і ви бачите, що місця лишається все менше. Яка вбудована команда допоможе зменшити споживання контексту по ходу?
A/compact — стискає контекст під час сесії
B/reset — повністю очищає й обнуляє все
C/verbose — перемикає рівень деталізації виводу
D/tokens — лише показує лічильник токенів
✓ Правильна відповідь: A — /compact зменшує споживання контексту у розширених сесіях, коли він заповнюється багатослівним discovery. /reset (якби існував) втратив би прогрес; /verbose і /tokens не стискають контекст.