Создавајте софтвер што станува незаменлив учител на ВИ
ВИ ќе учи од многу повеќе од документи. Ќе учи од софтверот што луѓето го користат за да донесуваат одлуки, да завршуваат работа, да решаваат исклучоци и да разберат како изгледа „доброто“ во одредена област.
Тоа создава невообичаено важна можност за продуктовите тимови. Најтрајниот софтвер можеби нема само да автоматизира работен тек или да прикажува информации. Може да стане средината што го доловува експертското расудување во облик што системите со ВИ можат да го користат: структурирани одлуки, исправки, одобрувања, објаснувања и исходи.
Целта не е да се изгради поле за разговор покрај секоја база на податоци. Целта е да се изградат производи што ја прават експертизата разбирлива.
Корисниот софтвер создава висококвалитетни сигнали
Секој производ генерира податоци, но не сите податоци ја учат ВИ на нешто вредно. Низа кликови може да покаже активност. Ретко ја објаснува намерата. Завршена задача може да покаже исход. Можеби нема да открие зошто е избрана една опција наместо друга.
Најсилните производи создаваат сигнали како природна последица од тоа што им помагаат на луѓето да работат. Разгледајте алатка за преглед на барања. Ако бележи само „одобрено“ или „одбиено“, има слаб сигнал за обучување. Ако му овозможува на експерт да ја класифицира причината, да ги наведе релевантните докази, да означи неизвесност и да испрати случај на ескалација, производот сега доловува концизен запис за професионално расудување.
Тоа е покорисно за клиентот денес и покорисно за идната помош од ВИ утре.
При проценување на функција, техничките лидери треба да постават поинаков сет прашања:
- Каква одлука му помага оваа функција на човек да донесе?
- Кои докази ги разгледал?
- Може ли производот да ги долови исправките без да создава дополнителна непотребна работа?
- Можеме ли да разликуваме увереност од сигурност?
- Дали конечниот исход ќе ни каже дали одлуката била исправна?
Овие прашања водат до подобар софтвер дури и ако со години не се обучи ниту еден модел. Тие го принудуваат тимот да го разбере работниот тек на клиентот, наместо да го третира како низа екрани.
Дизајнирајте ја повратната јамка пред да додадете интелигенција
Тимовите често почнуваат со способност на модел: сумирај ги овие записи, класифицирај ги овие тикети, состави го овој одговор. Тоа може да создаде впечатлива демонстрација, но не мора нужно да создаде сигурен производ.
Поодржлива почетна точка е повратната јамка. Дефинирајте го предложеното дејство, точката на човечка проверка, механизмот за исправка и мерливиот исход. Потоа одлучете каде ВИ може да го намали напорот без да ја замагли одговорноста.
Направете ја проверката дел од работата, а не излез во итен случај
Доброто искуство со проверка е конкретно. „Дали овој одговор беше корисен?“ е лесно да се имплементира, но е слаб како повратна информација. Бара од зафатена личност да претвори сложено расудување во нејасна оценка.
Наместо тоа, понудете исправки што одговараат на работата. Специјалист за поддршка може да означи предложен одговор како неточен, нецелосен, премногу самоуверен или несоодветен по тон. Безбедносен аналитичар може да означи предупредување како безопасно, сомнително или како такво што бара ескалација. Регрутер може да исправи предложено совпаѓање на вештини и да ги посочи доказите што ја промениле одлуката.
Интерфејсот треба да ја прави правилната исправка полесна од почнување одново. Ако исправката на излез од ВИ трае подолго од рачното извршување на работата, луѓето ќе го заобиколат системот. Производот ги губи и усвојувањето и сигналот потребен за подобрување.
Зачувајте го контекстот зад исправката
Исправка без контекст може да доведе во заблуда. Да претпоставиме дека корисник менува предложен датум на испорака. Дали првичниот предлог бил погрешен затоа што залихите не биле достапни, затоа што клиентот имал посебен договор или затоа што изворните записи биле застарени?
Доловете го најмало корисно објаснување. Тоа може да биде код за причина, поврзан запис, избрана политика или незадолжителна кратка белешка. Целта не е исцрпно надгледување на вработените. Доволен е контекст што ќе направи грешката да биде разбирлива, проверлива и потенцијално спречлива.
Вградете граници на сопственост во производот
Како што софтверот станува поспособен, сопственоста мора да стане појасна. Предлог од ВИ може да биде вреден без да биде овластен за дејствување. Мешањето на овие две состојби е неуспех во дизајнот на производот, а не само детал од имплементацијата.
Користете експлицитни состојби за работни текови со значајни последици: нацрт, предложено, прегледано, одобрено, извршено и поништено. Точните имиња се помалку важни од јасноста. Корисниците треба да можат да кажат што направил системот, што одобрил човек и што сè уште чека.
Ова исто така им дава на инженерските тимови практична архитектура. Содржината генерирана од ВИ може да остане предлог сè додека не премине деловно правило или граница на човечко одобрување. Записите за ревизија можат да го доловат опсегот на влезот, добиената препорака, дејството на проверувачот и сите конечни измени.
draft -> suggested -> reviewed -> approved -> executed
| |
v v
discarded revised
Не на секоја функција ѝ е потребно ова ниво на формалност. Предлог за правопис и ослободување плаќање носат различен ризик. Дисциплината е границата да биде пропорционална на последицата.
На оддалечените тимови им е потребно заедничко продуктово расудување
Дистрибуираните тимови можат да градат одлични производи овозможени од ВИ, но не можат да се потпрат на појаснување во ходник кога моделот се однесува неочекувано. Намерата на производот мора да биде видлива во самата работа.
Концизен запис за одлука често е повреден од долга спецификација. За секој значаен работен тек со ВИ, документирајте ја целта на корисникот, дозволените влезови, неприфатливите исходи, одговорноста за проверка, резервното однесување и начинот на кој ќе се проценува квалитетот. Чувајте го блиску до имплементацијата и ревидирајте го кога производот се менува.
Ова им помага на инженерите да носат исправни локални одлуки. Исто така ги усогласува продукт менаџерите, дизајнерите, тимовите за поддршка и стручњаците за доменот околу истото прашање: што треба да се случи кога системот е несигурен?
Одговорот ретко треба да биде „погодувај посамоуверено“. Понекогаш најдоброто искуство е да се прикажат доказите, да се побара појаснување, да се насочи работата кон специјалист или да се одбие преземање дејство.
Одржливата испорака е подобра од театар со ВИ
Постои притисок брзо да се објави интелигенција. Тој притисок може да создаде кревки функции изградени околу впечатливи излези наместо сигурни исходи. Одржливиот пристап објавува во тесен опсег, ја мери реалната употреба и го подобрува работниот тек околу моделот исто толку колку и самиот модел.
Почнете со ограничена задача што има јасен сопственик и повратно дејство. Набљудувајте каде корисниците прифаќаат, уредуваат, одбиваат или игнорираат предлози. Истражете ги шемите пред да прогласите успех. Високата стапка на прифаќање може да укажува на квалитет, но може и да значи дека луѓето не го проверуваат излезот. Ниската стапка на прифаќање може да открие лош интерфејс, а не слаб модел.
Техничките лидери треба да заштитат време за оваа јамка на учење. Евидентирањето, случаите за евалуација, алатките за проверка и справувањето со неуспеси се продуктова работа. Тие не се завршни детали што се додаваат откако ќе биде испорачана „функцијата со ВИ“.
Учете го системот со почитување на експертот
Најдобрите производи со ВИ не ги поставуваат експертите како привремени пречки на патот кон автоматизацијата. Тие го третираат експертското расудување како највредното средство на производот.
Изградете софтвер што им помага на луѓето сега да вршат значајна работа. Направете ги одлуките видливи, исправките лесни, сопственоста експлицитна и исходите следливи. Со текот на времето, тие избори создаваат систем што може да помага поинтелигентно затоа што научил од вистинска работа извршена со грижа.
Тоа е подлабоката можност: не софтвер што ги заменува луѓето кои ја познаваат работата, туку софтвер што станува достоен да учи од нив.