Надвор од промптовите: Дизајнирајте софтвер од кој вештачката интелигенција навистина ќе учи
Тим може да му даде на асистент со вештачка интелигенција внимателно составено барање, а сепак да види како тој не успева да го реши истиот тикет за поддршка следната недела. Одговорот можеби бил корисен, човечката корекција можеби била прецизна, а разговорот можеби дури и е зачуван некаде. Ништо од тоа не гарантира дека софтверот следниот пат ќе се однесува поинаку.
Тој јаз е архитектонски проблем. Апликацијата не учи само затоа што моделот одговара или затоа што базата на податоци зачувува транскрипт. Таа учи кога корисните докази можат да го променат идното однесување преку намерно осмислен пат што може да се тестира. За програмерите кои вградуваат вештачка интелигенција во производи и работни текови, тој пат заслужува исто толку внимание колку и барањето до моделот.
Одлучете што значи „учи“ во вашиот систем
Учењето може да се случува на неколку нивоа, а секое од нив носи различни трошоци и ризици. Систем за пребарување може да му стави на располагање на моделот новоодобрен документ без да го промени самиот модел. Апликацијата може да запамети претпочитање на корисникот и да го вклучи во подоцнежните барања. Тимот може да ги измени инструкциите, алатките или правилата за насочување откако ќе ги разгледа неуспесите. Во некои случаи, може да користи внимателно избрани примери за дополнително да го дообучи моделот.
Овие механизми не се заемно заменливи. Додавањето коригирана политика во база на знаење може да поправи застарен одговор, но нема нужно да го научи агентот да побара информации што недостигаат пред да преземе дејство. Дополнителното дообучување може да влијае врз начинот на одговарање, но не гарантира дека моделот ја знае најновата политика или дека ја следи во секој случај.
Почнете со утврдување на однесувањето што сакате да го промените. „Користете ја тековната политика за поврат на средства кога им одговарате на клиентите“ упатува на авторитативен извор што може да се ажурира. „Избегнувајте да извршите поврат на средства кога сметката не може да се потврди“ бара контролен механизам во работниот тек. „Пишувајте резимеа во форматот што го претпочита клиентот“ може да бара зачувано претпочитање. Соодветниот механизам за учење произлегува од конкретниот неуспех.
Создајте пат од повратните информации до однесувањето
Замислете асистент што подготвува нацрт-одговори за тим за поддршка. Агент уредува нацрт затоа што асистентот навел стар рок за откажување. Ако измената остане во затворениот тикет, следниот нацрт може да ја повтори грешката. Корисен пат за повратни информации ја бележи корекцијата, го утврдува изворот на проблемот и обезбедува одобрено ажурирање во материјалот што асистентот може да го пребарува.
За тој пат се потребни јасно распределени одговорности. Специјалист за производот може да ја провери политиката, додека инженер проверува дали системот за пребарување го презема изменетиот документ. Пред објавувањето, тимот може да му постави репрезентативни прашања на ажурираниот систем и да ги провери и одговорот и доказите што ги користел.
Осмислете ги записите за повратни информации така што ќе го зачуваат контекстот без стандардно да собираат сè. Во зависност од задачата, корисните полиња може да ги вклучуваат првичното барање, нацртот, човечката корекција, причината за корекцијата, верзијата на релевантниот извор и информација дали корекцијата е одобрена. Отстранете ги или ограничете ги чувствителните информации таму каде што не се потребни за подобрување.
Повратните информации се доказ, но не се автоматски вистина. Корисникот може да претпочита пократок одговор, погрешно да разбере некоја политика или намерно да се обиде да манипулира со системот. Правете разлика меѓу претпочитање, предложена фактичка корекција и овластена промена на правило. За секое од нив може да биде потребен различен начин на преглед и зачувување.
Направете ја меморијата конкретна и проверлива
Меморијата е привлечна затоа што прави асистентот да се повторува помалку. Таа е и место каде што мала грешка може да опстои. Ако асистентот од еден избрзан разговор заклучи дека корисникот секогаш сака куси одговори, таа претпоставка може незабележливо да ја влоши идната работа.
Одредете им на зачуваните информации цел и опсег. Одобрените конвенции за пишување код на тимот припаѓаат во заедничките насоки за проектот; форматот на одговор што го претпочита поединец припаѓа во неговите лични поставки. Привремен детал за инцидент може да биде корисен за една задача, а да доведе до погрешен заклучок еден месец подоцна.
За секој вид меморија, одлучете кој може да ја создава, кој може да ја менува, кога истекува и како може да се прегледа или избрише. Кога некој запис во меморијата влијае врз одговор или дејство, зачувајте доволно податоци за неговото потекло за да може да се пронајде изворот. Така ќе може да се поправи погрешен запис без да се погодува во кој разговор настанал.
Поставете алатки и правила околу моделот
Моделот може да предложи дејство; околниот софтвер треба да утврди дали тоа дејство е дозволено. Во работен тек за трошоци, на пример, асистентот може да извлече податоци од фискална сметка и да подготви барање за надоместување. Апликацијата може да ги провери задолжителните полиња, да ги провери дозволите на подносителот и да побара соодветно одобрение пред исплатата.
Ова разграничување е важно за учењето. Коригиран пример може да го подобри извлекувањето податоци, а ажурираните насоки можат да му помогнат на асистентот да обработи необична сметка. Ниту едното ниту другото не треба да биде единствената заштита од неовластена исплата. Поставете ги ограничувањата за дејства со значајни последици во системи што ги спроведуваат, со јасни пораки за грешка што асистентот може да ги искористи за да се справи со проблемот или да побара помош.
За работните текови на агентите, дефинирајте што се случува кога некоја алатка ќе откаже, ќе врати нецелосни податоци или ќе даде двосмислен резултат. Повторен обид може да биде разумен при привремен неуспех во читањето. Слепото повторување на плаќање или испраќање порака може да предизвика дупликати, освен ако операцијата не е осмислена безбедно да обработува повторени барања. Кога исходот е неизвесен, работниот тек треба да го провери статусот или да го проследи проблемот на повисоко ниво, наместо да претпостави успех.
Оценувајте го целиот циклус, а не само одговорот
Уверлив одговор не е доказ дека системот се подобрил. Одржувајте мал збир случаи засновани на вистински обрасци на неуспех, со соодветно постапување со чувствителните податоци. Вклучете вообичаени барања, двосмислени барања, застарени информации, спротивставени извори и обиди за активирање дејства без потребното овластување.
Оценувајте го однесувањето што е важно за секој случај. Дали асистентот ја пронајде тековната политика? Дали укажа на информациите што недостигаат? Дали апликацијата блокираше неовластено дејство? Дали корекцијата го подобри целниот случај без да предизвика влошување на друго место? Човечкиот преглед и понатаму е вреден за квалитети што тешко се опфаќаат со едноставна проверка, како на пример дали одговорот е јасен и дали содржи соодветни огради.
Водете верзии на елементите што влијаат врз однесувањето: барањата до моделот, релевантната конфигурација, алатките, случаите за оценување и изворите на знаење, каде што е изводливо. Воведувајте ги значајните промени контролирано, следете ги нивните ефекти и обезбедете начин да ги вратите на претходната состојба. Систем што може да прима повратни информации, но не може да објасни или да поништи штетна промена, има циклус на подобрување без кочница.
Дајте му на софтверот начин да станува помудар
Најкорисните системи со вештачка интелигенција не зависат од совршена инструкција напишана уште првиот ден. Тие оставаат простор за корекции, ги насочуваат на вистинското место и проверуваат дали даваат подобар исход. Понекогаш резултатот е подобро барање до моделот. Исто толку често, тоа е коригиран документ, појасна граница на овластувањата или работен тек што знае кога да запре.
Размислувајте подалеку од она што моделот може да го каже во една интеракција. Создадете начини на кои луѓето ќе можат да ги забележуваат грешките, да одобруваат промени и да го проверуваат следниот резултат. Така софтверот стекнува способност да се подобрува.