Клиент прашува зошто не може да се изврши поврат на средствата за една нарачка. Одговорот не се наоѓа во една функција. Тој произлегува од евиденцијата за плаќањата, статусот на исполнување на нарачката, исклучок од политиката и проценката на специјалист за корисничка поддршка кој знае какви ветувања дала компанијата.

Тоа е деловна логика: правилата, одлуките и исклучоците што го претвораат софтверот во функционално деловно работење. Асистент со вештачка интелигенција може да им помогне на луѓето да се снајдат во таа логика, но само ако тимот преземе одговорност за она што асистентот го учи, што може да прави и како се проверуваат неговите одговори.

Деловната логика е повеќе од код

Програмерите често ги среќаваат деловните правила во форма на услови: за нарачка може да се изврши поврат на средствата ако исполнува одредени критериуми. Во практика, вистинското правило може да зависи и од договор, регионално барање, неодамнешна промена на политиката или исклучок што никогаш не бил внесен во апликацијата.

Разгледајте бизнис што работи со претплати. Претплатничкиот план на клиентот, датумот на наплата и статусот на сметката може да се зачувани во софтверот. Причината зошто одреден клиент добива дополнителен рок може да се наоѓа во белешка од корисничката поддршка. Во меѓувреме, документот со политиката може да го опишува вообичаениот случај, но да не кажува ништо за оспорена наплата.

Вештачка интелигенција што може да ги прочита сите овие материјали не е автоматски доверлива. Може да наиде на спротивставени верзии, да превиди важен услов или да примени правило на погрешен клиент. Давањето пристап до информации е почеток на преземањето одговорност за системот, а не негов крај.

Дефинирајте што треба да знае и да прави вештачката интелигенција

Започнете со тесно дефинирана одлука или работен процес. „Да им помогне на агентите за корисничка поддршка да објаснат дали се исполнети условите за поврат на средствата“ е полесно да се осмисли и процени отколку „да го разбере нашиот бизнис“. Потесно дефинираната цел овозможува да се утврдат потребните информации, луѓето одговорни за нив и цената на евентуална грешка.

Раздвојте три вида знаење:

• Стабилни дефиниции: Што значат поимите како „исполнета нарачка“, „активна претплата“ или „работен ден“ во овој контекст.
• Тековни факти: Статусот на нарачката, историјата на плаќања и политиката што се применува во конкретниот случај.
• Овластување за одлучување: Кои правила смее да ги применува системот и за кои исклучоци е потребна човечка проценка.

Оваа разлика го обликува дизајнот. Стабилните дефиниции може да се одржуваат како референтен материјал. Тековните факти треба да доаѓаат од системи што можат да обезбедат ажурни информации. Овластувањето за одлучување треба да биде дел од јасно дефиниран работен процес, со дозволи и преглед соодветни на последиците.

На пример, асистентот може да ги сумира фактите и да му предложи на агентот проценка дали се исполнети условите за поврат на средствата. Самото извршување на повратот е посебна постапка. Корисното објаснување треба да ги наведе политиката и фактите врз кои се темели предлогот и да укаже на информации што недостигаат или се спротивставени. Ако статусот на нарачката не може да се добие, асистентот треба да го каже тоа, наместо да ја пополни празнината со веродостојна претпоставка.

Доделете одговорност за знаењето

Многу тимови откриваат дека нивниот најголем проблем со вештачката интелигенција всушност е проблем со одговорноста. Постои политика, но никој не знае која верзија е меродавна. Некое поле има познато име, но финансиите и оперативниот тим го користат на различни начини. Одредено правило било воведено пред години, а првичната причина за него е заборавена.

Доделете одговорно лице или тим за секој важен извор на деловна логика. Тоа лице или тим треба да може да објасни што опфаќа изворот, да одобрува промени и да помага при разрешување на противречности. Одговорноста не значи дека едно лице мора да го напише секој документ. Таа значи дека постои јасен начин да се добие одговор кога системот ќе открие нешто нејасно.

Поврзете го одржувањето на знаењето со работата што го менува. Кога производниот тим ќе го промени рокот за поврат на средствата, поврзаната политика, примерите и проверките треба да се разгледаат како дел од истата промена. Во спротивно, апликацијата и асистентот може постепено да се разминат, иако и двата изгледаат како да работат.

За тимовите што работат на далечина, писмено забележаните одлуки се особено важни. Забележете ги правилото, неговиот опсег, неколку репрезентативни примери и причината за секој позначаен исклучок. Краток запис за одлуката што редовно се одржува е покорисен од долг документ во кој никој нема доверба. Овозможете им на тимовите за корисничка поддршка, производ, операции и развој лесно да пријават одговор што изгледа погрешен.

Тестирајте ги одлуките, а не само течно срочените одговори

Уверлив одговор сепак може да биде неточен. Проценувајте го асистентот со случаи што ја одразуваат работата што луѓето навистина ја извршуваат, вклучувајќи вообичаени барања, гранични услови, податоци што недостигаат и исклучоци.

За примерот со повратот на средствата, мала група случаи за проверка може да опфати нарачка што ги исполнува условите, нарачка што не ги исполнува, исклучок од политиката и случај во кој податоците за исполнувањето на нарачката не се достапни. За секој случај, дефинирајте што мора да содржи добар одговор: точна проценка кога фактите ја поддржуваат, соодветно образложение и соодветно барање за човечки преглед кога фактите не овозможуваат таква проценка.

Луѓето одговорни за правилата нека ги разгледуваат неуспесите заедно со програмерите. Дали изворот бил погрешен, дали релевантните информации биле недостапни или асистентот погрешно ги протолкувал? За овие пропусти се потребни различни решенија. Следете ги со текот на времето и повторно тестирајте ги репрезентативните случаи кога ќе се променат политиките, изворите на податоци или конфигурацијата на асистентот.

Проверете го и процесот околу одговорот. Ако некој извор е недостапен, дали корисникот може да го забележи тоа? Ако агентот исправи препорака, дали постои начин исправката да се забележи за понатамошен преглед? Ако асистентот може да покрене дејство, дали дозволите, потврдата и записите за тоа што се случило се соодветни за тоа дејство? Доверливоста на системот зависи и од неговото однесување кога вообичаениот тек ќе потфрли.

Луѓето нека ја задржат контролата врз процесот на учење

„Го учи вашиот бизнис“ не треба да значи дека секој разговор незабележливо ја менува политиката на компанијата. Повратните информации се вредни, но треба да се протолкуваат. Исправката од агент за корисничка поддршка може да открие изоставен исклучок, еднократно излегување во пресрет или недоразбирање. Тоа се различни работи и не можат да се третираат како ист факт.

Воспоставете начин повратните информации да стигнат до одговорното лице или тим. Разгледувајте ги повторливите проблеми, ажурирајте го релевантниот извор или работен процес и тестирајте ја промената пред да почнете да се потпирате на неа. Така секојдневната употреба станува дисциплиниран процес на подобрување, а одговорноста за правилата се зачувува.

Започнете со помош при која луѓето можат да го проверат образложението и да ги откријат грешките. Проширувајте ги одговорностите на асистентот дури кога тимот ќе разбере на кои начини може да потфрли и ќе има докази дека околниот работен процес може да се справи со тоа. Целта не е да се отстрани расудувањето од деловното работење. Целта е полесно да се пронајде, објасни и примени добро расудување.

Највредниот систем со вештачка интелигенција можеби е оној што го поттикнува тимот да ги разјасни правилата на кои се потпирал со години. Кога одговорноста е јасна, знаењето има свое место, а неизвесноста е видлива, асистентот може да станува покорисен како што се менува бизнисот. Без таа основа, може само да станува посамоуверен во што и да наиде.