Откриване на пропуски в знанията на AI чатбот: Систематично затваряне на неотговорените въпроси

Уебсайт чатботът може да отговаря надеждно само ако получава подходяща, одобрена и лесна за откриване информация. На практика обаче пропуските в знанията рядко се появяват под формата на подреден доклад. Те се крият в сигурни резервни отговори (fallback), повторни уточняващи въпроси, излишни прехвърляния към оператор или отговори, които звучат правдоподобно, но нямат надежден източник. Ето защо всеки, който гледа само броя на неотговорените въпроси, вижда само част от проблема.

Ето защо ефективният процес съчетава оперативни данни, редакционен преглед и тестове. Целта не е всяка необичайна формулация да се копира веднага в базата знания. Целта е да се идентифицират повторно възникващите информационни нужди, да се установи тяхната причина и да се одобряват само онези отговори, за които може да се поеме професионална отговорност. Това ръководство показва практически работен процес за екипите по поддръжка, съдържание и продукти.

Какво представлява пропускът в знанията на AI чатбот?

Пропуск в знанията съществува тогава, когато на уместен потребителски въпрос в предвидената област на приложение не може да се отговори надеждно с одобрено твърдение. Това може да означава, че информацията напълно липсва. По-често тя съществува, но е остаряла, твърде обща, езиково неподходяща, не може да се обхожда (crawl) или не се открива при извличането (retrieval). Противоречивите източници също представляват пропуск: в този случай чатботът разполага с твърде много двусмислено, а не с твърде малко знание.

Понятието не бива да се отъждествява с всяка ситуация на No-Match. Google документира за Dialogflow CX вградени събития No-Match, когато въведените данни не съответстват на нито един Intent. Microsoft посочва в анализите на Copilot Studio „unrecognized utterances“ – т.е. изрази, които не задействат отделна тема. Такива сигнали са полезни отправни точки, но все още не доказват, че е необходимо ново съдържание. Може би въпросът е бил извън обхвата (scope), изразът е бил двусмислен или съществуващият източник просто не е бил намерен.

Кои сигнали принадлежат към анализа на пропуските?

Сигурни резервни отговори (fallbacks) и неотговорени въпроси

Най-ясната следа е отговор от сорта на „Нямам надеждна информация по този въпрос“. Този сигурен резервен отговор (fallback) е за предпочитане пред измислено твърдение, но трябва да се регистрира като събитие за проверка. При това от значение е не само точният формулиран въпрос, но и езикът, засегнатата страница, часът, избраният обхват и последвалият ход на разговора. Личните или поверителните данни не бива да попадат нефилтрирани в редакционна система.

Ниска степен на сигурност и слаба база от източници

Дори даден предоставен отговор може да разкрие пропуск в знанията. Примери за това са липсващи източници, резултат от извличане (retrieval) с ниско ниво на съответствие, множество противоречиви резултати или отговор, който покрива само част от въпроса. Техническата стойност за увереност (confidence score) сама по себе си не е достатъчна за оценка: праговете варират според модела, системата и риска. Решаващо е дали екипът може да проследи и одобри твърдението въз основа на авторитетен източник.

Повторни уточнения, прекъсвания и прехвърляния (handoffs)

Когато потребителите преформулират един и същ въпрос, питат неколкократно или веднага след това поискат връзка с човек, първият отговор може да не е отговорил на нуждата им. Това важи и за необичайно голям брой прекъсвания след определена тема. Такива диалози трябва да се анализират в съответния контекст. Прехвърлянето към оператор (handoff) може да бъде правилното решение, например при индивидуални казуси, жалби или чувствителни данни. То не е автоматично грешка в съдържанието.

Разлики в локализацията (locale) и каналите

Даден отговор на немски може да работи отлично, докато френският вариант липсва или използва наименование на продукт по различен начин. По същия начин въпросите на страницата с цените може да са формулирани различно от тези в центъра за помощ. Ето защо клъстерите трябва да подлежат на проверка поне по език/локализация (locale) и по контекст на употреба. В противен случай глобалното обобщение може да скрие ясно локализиран пропуск.

От суровия сигнал до приоритетния баклог за съдържание

Олекотеният работен процес пречи на екипа да събира транскрипти хаотично или да надценява отделни наблюдения. Следните седем стъпки могат да се изпълняват безпроблемно всяка седмица или по-често при по-голям обем.

1. Дефиниране на записването: Определете кои събития се считат за кандидати: сигурен резервен отговор, липса на надежден източник, повторен въпрос, негативна обратна връзка, излишно прехвърляне или съобщено грешно твърдение. Документирайте и кои данни съзнателно не се съхраняват.
2. Почистване на съдържанието: Премахнете или маскирайте личните данни, номерата на поръчки, данните за контакт и свободния текст, които не са необходими за анализа. Статията за икономичния анализ на данни за чатботове показва как събитията, извадките (sampling) и съхранението могат да се планират отделно.
3. Нормализиране на въпросите: Обединете формулировките с еднакво значение, без да губите важни разлики. „Колко време имам за връщане?“ и „Кава е срокът за връщане?“ вероятно принадлежат към един клъстер; „Мога ли да върна персонализирана стока?“ може да изисква отделно правило.
4. Класифициране на причината: Разграничете липсващо съдържание, остарял източник, проблем с извличането или структурата, неясни правила, пропуск в локализацията, нарочно изключен обхват и необходимост от човешко решение. Тази диагноза определя последващото действие.
5. Определяне на приоритет: Оценете честотата, въздействието върху потребителя, бизнес значението и риска. Рядка забележка относно критично за сигурността ограничение може да бъде по-важна от често задаван въпрос за общи разговори (small talk). Формулата трябва да е разбираема и проверяема за вашата компания, а не математически сложна.
6. Възлагане на отговорност за източниците: Всеки планиран отговор се нуждае от авторитетен източник и човек или роля, имащ правото да одобри съдържанието му. Ако и двете липсват, записът остава отворен; езиковият модел няма право да измисля правилата. Подходящ оперативен модел е описан в ръководството за управление на съдържанието (Content Governance) за AI чатботове.
7. Създаване на тест за приемане: Запазете представителни въпроси, очаквани ключови послания, допустими източници и очакваното поведение извън обхвата. След всяка промяна се проверява дали пропускът е отстранен и дали съществуващите отговори остават стабилни.

Кои полета са необходими за добър запис в баклога?

Тикет със заглавие „Чатботът не знае срока за връщане“ е твърде повърхностен. Той лесно води до текст, който макар и да отговаря на примерния въпрос, не отчита вариации, изключения или отговорности. Запис, готов за обработка, съдържа най-малко:

• неутрална тема на клъстера и от две до пет анонимизирани примерни въпроса,
• локализация (locale), контекст на страницата и засегнат потребителски път,
• наблюдавано поведение и желано поведение,
• клас на причината и обоснован приоритет,
• авторитетен URL адрес на източника или статус „Липсва източник“,
• собственик отговорник по темата, роля за преглед и краен срок,
• дата на валидност, известни изключения и желано поведение при прехвърляне (handoff),
• тестови казуси и измерими критерии за приемане.

По този начин от дадено наблюдение в чата се създава редакционна работна единица. Същевременно остава видимо дали проблемът наистина може да бъде решен чрез съдържание. Например техническа грешка при извличането (retrieval) трябва да се насочи към екипа за търсене или платформата, а неизяснено правило за връщане – към съответния бизнес отдел.

Практически пример: Правилно разрешаване на въпроси относно връщането

Да предположим, че потребителите многократно питат за връщане на персонализирани продукти. Чатботът понякога съобщава общия срок, понякога несигурно изключение, а понякога прехвърля към екипа по поддръжка. Екипът не бива да извежда ново правило от досегашните отговори. Първо се изяснява коя одобрена политика се прилага, за кои държави и продуктови групи важи и кога е необходима индивидуална проверка.

След това се създава структуриран източник с общо правило, ясно посочени изключения, обхват на валидност и критерий за ескалация. Тестовите казуси покриват директни въпроси, разговорни варианти, друг език/локализация (locale) и граничен случай, който съзнателно не може да бъде автоматизиран. За граничния случай се очаква прозрачно прехвърляне към човек (Human Handoff) – а не принудителен отговор за самообслужване.

Защо повечето съдържание не означава автоматично по-добро качество

Честа грешка е опитът да се отговори на всеки клъстер с нов въпрос и отговор (FAQ). Това може да създаде дубликати, противоречия и по-лоши резултати при извличането. Преди да създадете ново съдържание, проверете дали съществуваща страница трябва да бъде допълнена, по-добре структурирана или премахната от обхвата на обхождане (crawl scope). Процесът за поддържане на актуална база знания помага при избора на източници, честотата на обхождане и контрола на остарялото съдържание.

Ръководството за дизайн на Google посочва, че безборното добавяне на потребителски формулировки като данни за обучение или тестване без проверка може да доведе до нежелан Intent-Bias. Едва анализът на причината определя дали дадена формулировка трябва да бъде добавена, съществуваща формулировка – изчистена, или грешно конкуриращ се Intent – коригиран.

Затваряне на цикъла с регресионни тестове

Пропускът не се счита за отстранен само с публикуването на нов текст. Той се счита за отстранен тогава, когато представителните въпроси в предвидения контекст показват очакваното поведение. Google описва тестови казуси с очаквания на ниво разговор или реплика (turn) и сравнение с т.нар. Golden Case. За уебсайт чатботове този принцип може да се приложи независимо от модела: документират се въпросът, очакваното ключово послание, позволеният източник, необходимият handoff и забранените твърдения.

Малък, поддържан набор от тестове е много по-ценен от голяма, непроверена колекция. Включете потвърдените пропуски в съществуващия набор Golden Set и изпълнявайте съответните казуси отново след промени в съдържанието, промпта, модела или извличането (retrieval). Подробното ръководство за измерване на качеството на отговорите на AI чатбота задълбочава този работен процес за преглед.

Кои показатели (KPI) показват напредък?

Не следете просто глобалната честота на резервни отговори (fallback rate). Значително по-полезен е малък пакет от показатели: отворени приоритетни клъстери, време за бизнес изясняване, дял на записите в баклога с авторитетен източник, преминали регресионни тестове и повторно появяващи се пропуски след одобрение. Сегментирайте резултатите по локализация (locale) и основен потребителски път, без да анализирате малки групи толкова детайлно, че лицата да станат индиректно разпознаваеми.

Microsoft посочва неразпознатите изрази и темите с нисък процент на разрешаване като възможни сигнали за оптимизация. NIST подчертава в AI Risk Management Framework необходимостта от непрекъснат мониторинг, документирани тестови комплекти, обратна връзка и наблюдение на поведението при работа. Оттук следва едно важно правило: показателите трябва да подпомагат вземането на решения, но не и да заменят експертната проверка на даден източник на отговор.

Седмичен чеклист за екипите по поддръжка и съдържание

• Записване на новите кандидати с минимизиране на данните и филтриране на явните злоупотреби.
• Групиране на въпросите с еднакво значение в клъстери за всяка локализация (locale) и допълване на съществуващите клъстери.
• Потвърждаване на причината, въздействието и риска за най-важните клъстери.
• Търсене на съществуващи източници, маркиране на противоречия и изясняване на отговорните лица.
• Публикуване само на одобрени промени; ясно поддържане на обхвата (scope) и прехвърлянето (handoff).
• Изпълнение на представителни тестови казуси и документиране на резултатите.
• След няколко дни употреба – проверка дали клъстерът се появява отново или просто е променил формата си.

Заключение: Пропуските в знанията са редакционен затворен цикъл

Неотговорените въпроси стават ценни едва тогава, когато екипът ги разглежда не като отделни чат логове, а като проверяеми сигнали. Записване, изчистване, групиране, определяне на причината, приоритезиране, одобряване на източника и тестване: този затворен цикъл свързва реалността в поддръжката със стабилна база знания. Той не премахва всяко прехвърляне към оператор и съзнателно не отговаря автоматично на всеки въпрос. В замяна на това прави видимо къде чатботът може да помага надеждно – и къде поставянето на ясна граница осигурява по-добро потребителско изживяване.

Източници

• Microsoft Learn: Измерване и подобряване на производителността на агента с KPI и анализи
• Google Cloud: Dialogflow CX State handlers и No-Match събития
• Google Cloud: Общи най-добри практики за дизайн на агенти
• Google Cloud: Dialogflow CX Тестови казуси (Test cases)
• NIST AIRC: Ядро на рамката за управление на риска от изкуствен интелект (AI Risk Management Framework Core)