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