Изграждане на AI Chatbot Analytics с пестене на данни: събития, извадки и съхранение

Аналитиката на AI чатбота трябва да показва дали посетителите получават подходящи отговори, кога разговорите се провалят и в кой момент трябва да се включи човешки екип. За тази цел обаче компаниите не е необходимо автоматично да съхраняват целия разговор. Често са достатъчни ясно дефинирани събития, обобщени показатели и малка, контролирана извадка за редакционна проверка на качеството.

Концепцията за измерване с пестене на данни затова не започва с възможно най-голям склад за данни, а с конкретни решения: Кой показатель на какъв въпрос отговаря? Коя информация е наистина необходима за това? Кой има право да я вижда и кога се изтрива? Това ръководство описва практична структура за уебсайт, съпорт и продуктови екипи. То не замества индивидуалната правна консултация.

Започнете с решения, а не със сурови протоколи

Много проекти за аналитика първоначално събират всичко и едва по-късно мислят кои анализи са полезни. При чатботовете този подход е особено рискован: свободният текст може да съдържа имена, имейл адреси, номера на поръчки, здравни данни или друга информация, която посетителят въвежда доброволно или по погрешка. Дори ако полето за въвеждане не изисква такива данни, те могат да се появят в разговора.

Затова първо дефинирайте бизнес въпросите. Искате ли да знаете дали ботът е разрешил даден проблем? Тогава се нуждаете от събитие за резултат и ясна дефиниция на „разрешен“. Ако трябва да се провери качеството на рутирането, често са достатъчни разпознатият клас на намерението (intent), целевият маршрут и действителният изход. Статията Тестване на AI Chatbot Routing показва как такива резултати могат да бъдат проверени спрямо очакваните пътища.

Общият регламент относно защитата на данните (GDPR) посочва в член 5, наред с другото, ограничението на целите, свеждането на данните до минимум и ограничението на съхранението. За аналитиката това не означава, че изобщо не могат да се обработват данни. То означава, че целта, обхватът и продължителността трябва да бъдат обосновани и ограничени до необходимия минимум. Правното основание, задълженията за информиране и, ако е приложимо, съгласието трябва да бъдат проверени за конкретното приложение.

Проектиране на олекотена таксономия на събитията

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

Възможен основен набор включва:

• conversation_started за започнат диалог без текст на съобщението,
• answer_delivered с общ клас на темата и езиков код,
• source_opened за щракване върху предоставен източник,
• fallback_triggered с контролирана категория на грешката,
• handoff_offered и handoff_accepted за прехвърлянето,
• feedback_submitted с ограничена скала за оценка.

Към всяко събитие принадлежат само атрибутите, които са необходими за анализ: времеви прозорец, локал (locale), категория на темата, статус на резултата, версия на бота или състояние на знанията. Свободният текст, пълните IP адреси, токените за достъп, сесийните бисквитки и директните данни за контакт не принадлежат по подразбиране към аналитично събитие. OWASP също препоръчва за дневниците на приложенията (logs) да се премахват, маскират или по друг начин да се защитават идентификаторите на сесии, токените, чувствителните лични данни и тайните.

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

Обобщените събития и пълната история на разговорите имат различни цели. Събитията са подходящи за трендове, фунии и сравнения. Съдържанието на разговора може да помогне при редакционния анализ на грешките, но съдържа значително повече контекст и следователно повече потенциално лична информация. Двата вида данни не трябва автоматично да имат едни и същи права за достъп, срокове за съхранение или експорти.

Практичната архитектура работи на три нива:

1. Показатели: обобщени стойности като процент на решение, дял на fallback или приемане на handoff.
2. Събития: псевдонимни записи с ограничени атрибути за времеви и технически анализи.
3. Качествени извадки: избрани разговори за контролиран преглед, по възможност с автоматична и ръчна редакция на директни идентификатори.

Това разделение улеснява прилагането на различни срокове за изтриване и роли. Например, дашборд за маркетинга не трябва да има достъп до съдържанието на разговорите, ако той анализира само обобщено постигане на целите. Как да дефинирате показателите подробно, описва ръководството KPI за AI чатбот.

Псевдонимизацията не е анонимизация

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

Използвайте стабилни идентификатори само когато целта на анализа наистина го изисква. За дневен процент на fallback обикновено не е необходим потребителски ID, който да може да се разпознава с седмици. Ако са необходими свързани технически събития, може да е достатъчен краткотраен, случаен идентификатор на разговора. Съхранявайте таблиците за съпоставяне отделно, ограничете достъпа и документирайте кога даден идентификатор се ротира или изтрива.

Рамката за поверителност NIST Privacy Framework описва „disassociated processing“ (несвързана обработка) като подход за ограничаване на наблюдаемостта, свързаността и идентификацията. На практика това може да означава замяна на атрибути с категории, използване на локална предварителна обработка или изпращане само на вече обобщени стойности към централната система.

Проверка на качеството с контролирана извадка (sampling)

За качествената проверка не всеки разговор е еднакво важен. Случайната извадка осигурява по-неутрален поглед върху ежедневието, докато базираната на риск извадка целенасочено обхваща случаи на грешки. Комбинирайте двата подхода, вместо да четете само изключително лоши или изключително дълги разговори.

Разумният план за преглед може да съдържа следните групи за даден период от време:

• малка случайна извадка от изглеждащи като успешни отговори,
• случаи на fallback и unanswered въпроси,
• предлагани и приети прехвърляния към човек (human handoff),
• отговори по чувствителни или критични за бизнеса теми,
• открояващи се отклонения между отделните езици (locales), устройства или нива на знания.

Дефинирайте преди осигуряването на достъп кои роли имат право да виждат разговорите, кои полета се маскират и как проверяващите документират нередности. Свободните коментари в инструментите за преглед самите те могат да съдържат лични данни; за това също са необходими ясни правила. Прегледът трябва да води до конкретна мярка, например коригиран източник, нов тестов въпрос или коригирано правило за handoff.

Планиране на съхранението според нивото на данните

Единният срок за изтриване за всички аналитични данни е удобен, но рядко е прецизен. Определете срокове за всяко ниво на данни и цел. Суровото съдържание за краткосрочен анализ на грешки може да бъде изтрито значително по-рано от месечните, неперсонални обобщения. Протоколите, свързани със сигурността, от своя страна могат да подлежат на различни изискваня в сравнение с продуктовата аналитика.

Документирайте за всеки набор от данни:

• целта и отговорната роля,
• съдържащите се полета и възможните идентификатори,
• мястото на съхранение и упълномощените получатели,
• срока, началната точка на срока и механизма за изтриване,
• третирането на резервни копия (backups), експорти и изведени копия.

OWASP посочва, че данните от регистрационните файлове (logs) не трябва нито да се унищожават преди необходимия период, нито да се съхраняват след него. Конкретната продължителност зависи от правни, договорни, свързани със сигурността и оперативни изисквания. Затова концепцията за изтриване трябва да бъде тествана технически: наистина ли се премахват записите, изчезват ли от търсещите индекси и взети ли са предвид временните експорти?

Защита на достъпите, експортите и непредвидените ситуации

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

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

Освен това тествайте срив в регистрирането на данни. Чатботът не трябва неконтролирано да записва чувствителни данни в резервен лог файл, ако аналитичната система е недостъпна. Определете кои минимални събития за сигурност трябва да се запазят и кое измерване на продукта може временно да бъде отменено.

Сравнения между локали (locales) без погрешни изводи

Многоезичната аналитика е полезна, когато термините и знаменателите остават последователни. Не сравнявайте само абсолютния брой случаи. По-високият брой прехвърляния (handoffs) може да се дължи на повече трафик, различно работно време за поддръжка или съзнателно по-предпазлив диалог. Използвайте проценти с ясно дефиниран знаменател и документирайте разликите в рутирането, базата знания и предлаганите канали за контакт.

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

Чеклист за AI Chatbot Analytics с пестене на данни

• Всеки показатель е свързан с конкретно решение и отговорно лице.
• Събитията по подразбиране не съдържат текст на съобщението и директни идентификатори.
• Показателите, събитията и качествените извадки са технически и организационно разделени.
• Псевдонимните идентификатори са краткотрайни или обосновани; ключовете се защитават отделно.
• Извадките (sampling) комбинират случайни случаи с групи за грешки, базирани на риска.
• Ролите, маскирането и резултатите от прегледа са задължително дефинирани.
• Сроковете за съхранение и изтриване важат и за експорти, резервни копия и търсещи индекси.
• Сравненията между езиците (locales) използват последователни дефиниции и подходящи знаменатели.
• Сривовете, манипулациите и неоторизираният експорт се тестват редовно.

Допълнителен анализ относно правните основания, задълженията за информиране и обработката на данни предлага статията AI чатбот и GDPR. Възложете проверката на конкретното изпълнение на съответните експерти по защита на данните и правни въпроси.

Източници

• Европейска комисия: Принципи на Общия регламент относно защитата на данните (GDPR)
• Европейски комитет по защита на данните: Насоки за псевдонимизацията
• NIST Privacy Framework: Guidelines and Tools
• OWASP Logging Cheat Sheet

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