Истинската работа предстои
Семинарът за подсказки, който започна твърде късно
Семинарът беше заплануван, за да подобри подсказките. Така беше озаглавен в календара, с весела малка иконка на вълшебна пръчица, за която някой после съжали. Група мениджъри, анализатори, оператори и инженери седяха около маса с общ документ. Текущата подсказка беше на екрана. Тя караше езиковия модел да преглежда заявките на клиенти, да определя правилната политика, да изготвя отговор и да отбелязва риска. Беше учтива, структурирана и много по-дълга, отколкото някой искаше да признае. Но не беше основният проблем.
Първият тестов случай беше клиент, който искаше изключение след закъсняла доставка. Моделът даде приличен отговор. После някой от оперативния отдел каза, че изходната политика на екрана вече не е тази, която екипът използва в петък, защото временно правило за превозвача беше удължавано два пъти, но никога не беше влято в основната страница с политики. Някой от правния отдел каза, че изключения над определена сума изискват одобрение, но прагът зависеше от продуктовата категория. Финансистите попитаха къде се записват кредитите за добра воля. Поддръжката каза, че тонът на модела е наред, но клиентът ще се обади отново, защото отговорът не споменаваше липсващото събитие за проследяване. Подсказката си стоеше там, изглеждайки невинно.
Нито един от тези проблеми нямаше да бъде решен с по-добър инструктивен параграф. Моделът не можеше да заключи коя страница с политики е авторитетна. Не можеше да знае, че временно правило е станало оперативна реалност. Не можеше да реши кой има право на одобрение. Не можеше да види, че липсващото събитие за проследяване е истинската причина за следващия контакт. От подсказката се искаше да компенсира неясна работа. Това е често срещана грешка. Хората идват при подсказката с кошница от процесна двусмисленост и искат от модела да бъде елегантен по въпроса.
Истинската работа е преди подсказката. Това е работата по назоваване на задачата, определяне на границите, избор на източници, установяване на правомощия, подготовка на примери, решаване на пътищата за провал, оформяне на изхода, измерване на качеството и правене на корекцията възможна. Подсказките имат значение. Лоша подсказка може да направи добрата настройка тромава. Но красива подсказка върху неясна операция е просто добре написано объркване. Моделът може да звучи по-добре. Работата няма да стане по-безопасна, по-евтина или по-разбираема случайно.
Подсказката не е карта на процеса
Една подкана може да каже на модела как да се държи в даден контекст. Тя не може да създаде контекста, ако организацията не го е направила. Може да поиска краткост, структура, скромност и цитиране. Може да опише роля. Може да зададе формат. Може да предупреди модела да не гадае. Това е полезно. Но е дребно в сравнение с процесните въпроси, които определят дали една AI система помага или просто говори уверено около работата.
Каква е задачата. Класификация, извличане, обобщаване, изготвяне на чернова, маршрутизиране, препоръчване, проверка или действие. Коя част е автоматизирана. Коя част остава за човека. Какво състояние се променя, ако резултатът бъде приет. Кого засяга. Кои записи се докосват. Коя политика се прилага. Какво доказателство е задължително. Какво се случва, когато доказателство липсва. Кои грешки са допустими. Кои грешки причиняват вреда. Тези въпроси определят формата на системата. Подкана, която не стъпва върху ясни отговори, се превръща в учтиво предположение с табелка с име.
Много неуспешни AI пилотни проекти започват с подкана, защото подканата е най-видимата дръжка. Усеща се като творческа и непосредствена. Можеш да я редактираш в среща. Можеш да изпробваш нова версия, преди кафето да изстине. Проектирането на процеси е по-бавно. Почистването на данни е по-бавно. Картографирането на правомощия е по-бавно. Изграждането на набор за оценка е по-бавно. За съжаление, бавно не означава незадължително. Пропуснатите части преди подканата се завръщат по-късно като халюцинации, преработка, недоверие, изключения от политиката и голяма електронна таблица, наречена проблеми.
По-добрата последователност не е бляскава. Запиши работата. Премини през реални случаи. Идентифицирай изходните системи. Отбележи кои полета решават резултата. Раздели правилата от преценката. Реши къде влизат хората. Определи договорите за изхода. Изгради примери. Съгласувай отказа. Тествай с хората, които ще живеят с резултата. Едва тогава подканата се превръща в полезен лост. Преди това тя е декоративен волан на бюро.
Задачата се нуждае от граница, достатъчно ясна за тестване
AI работата често започва с твърде големи глаголи. Помощ при обслужване на клиенти. Подкрепа при правен преглед. Подобряване на планирането. Подпомагане на снабдяването. По-умно отчитане. Това са амбиции, не задачи. Модел не може да бъде оценяван спрямо амбиция. Може да бъде оценяван спрямо задача с входове, изходи, ограничения, критерии за успех и пътища за провал. По-тясното описание може да изглежда по-малко вълнуващо. То е и първият момент, в който работата става изградима.
Острата граница на задачата казва какво системата може да вижда и какво може да променя. Казва дали моделът чете изходен материал, генерира чернова, извлича структурирани полета, препоръчва действие или извиква инструмент. Казва кои изходи са окончателни, кои са със съвещателен характер и кои трябва да бъдат прегледани. Казва какво системата отказва. Казва кога моделът трябва да поиска повече доказателства, вместо да завърши отговора. Казва какво е извън обхвата, защото извън обхвата е мястото, където амбициозните пилотни проекти се превръщат в доклади за инциденти.
Границите правят оценката възможна. Ако задачата е да се изготви отговор, използвайки тези източници и тази политика, качеството може да бъде тествано. Ако задачата е да се подобри качеството на услугата с AI, всеки резултат може да бъде обяснен като напредък от някой с достатъчно слайдове. Границата също така защитава потребителите от случайна ескалация. Инструмент, който започва с изготвяне на чернова, може да придобие бутон за изпращане. Класификатор може да стане маршрутизатор. Маршрутизатор може да стане решение. Без посочена граница, това отклонение изглежда като внедряване. С граница, то се превръща в заявка за промяна.
Границата трябва да бъде написана на оперативен език, а не само на технически. Ръководителят на поддръжката трябва да я разбира. Юридическият отдел трябва да я разбира. Собственикът на данните трябва да я разбира. Инженерът трябва да може да я тества. Ако границата съществува само в подканата, тя е крехка. Подканите са важни, но те не са нормативни политически документи. Те по-скоро приличат на инструкции към изключително талантлив временен служител, който никога не е виждал организационната схема.
Източниците не са купчина документи
Много екипи откриват по време на работата с подкани, че не знаят кои източници са авторитетни. Имат страници с политики, PDF файлове, инструкции по имейл, обучителни материали, остарели ръководства, чат съобщения, макроси за билети, електронни таблици и паметта на оператор, когото всички търсят, защото тя знае как всъщност работят нещата. След това от модела се иска да отговаря от базата знания. Кои знания. Коя база. Тази фраза може да прикрива огромни количества липсваща информация.
Подготовката на източници не е бляскава, затова често закъснява. Тя включва решаване кой документ има предимство, когато източниците си противоречат, как се проверява актуалността, как временните правила изтичат, как се представят изключенията, как поверителният материал се изключва, как версиите на източниците се запазват и как идентификаторите за цитиране оцеляват в отговора на модела. Това не е бюрокрация. Това е разликата между извличане и ровене.
Изкуственият интелект прави дисциплината около източниците още по-важна, защото моделът може да накара слабите практики да изглеждат приемливи. Той може да слепва фрагменти в плавна проза. Може да заглажда противоречия. Може да произведе правдоподобен отговор от остарял материал. Резултат от търсене с видими празнини изглежда непълен. Генериран отговор със същите празнини може да изглежда пълен. Колкото по-добра е прозата, толкова по-важен е произходът. Увереността не трябва да бъде позволено да прикрива слаба верига от източници.
Добрата подготовка на източници също намалява сложността на подканите. Подкана, пълна с предупреждения за противоречащи си политики, остарели документи, липсващи полета и специални изключения, често е симптом на пренебрегване нагоре по веригата. Ако слоят за извличане вече филтрира по авторитет и актуалност, подканата може да бъде по-кратка. Ако източникът носи структурирани метаданни, моделът не трябва да ги извежда от заглавията на параграфите. Ако изключенията са представени като правила, моделът не трябва да се превръща в детектив с ограничения на токените. Най-доброто подобрение на подканата понякога е по-добър индекс.
Примерите са малки части от управлението
Примерите обикновено се възприемат като помощни средства за обучение, но те са също и управление. Добрият пример показва какво означава качество в дадена ситуация. Той показва как организацията се справя с несигурността, липсващите доказателства, противоречивите политики, чувствителния тон, ескалацията и отказа. Той показва на модела и на екипа как изглежда добрият отговор, но също и как изглежда добрият не-отговор. Това е важно, защото много сериозни системи се провалят, като отговарят, когато трябва да направят пауза.
Изграждането на примери налага решения, които абстрактните дискусии избягват. Вземете двадесет реални случая. Отбележете правилния резултат. Отбележете приемливите алтернативи. Отбележете неприемливите преки пътища. Обяснете защо. Включете гранични случаи, които са накарали опитни служители да се поколебаят. Включете и обикновени случаи, защото системите, които тренират само върху драма, научават лоши обноски. Помолете експертите по темата да не са съгласни и запишете разногласието. Това е по-бавно, отколкото да помолите модела да бъде внимателен. Също така създава общ език за внимателност.
Примерите трябва да включват отрицателни случаи. Не е намерен източник. Конфликт на източници. Потребителят няма правомощия. Заявка извън предназначението. Клиентът иска нещо, което звучи просто, но задейства политика. Моделът трябва да се научи кога да откаже, да ескалира, да попита или да върне структурирана несигурност. Ако примерите показват само успешни отговори, подканата ще клони към завършеност. Завършеността не винаги е успех. Понякога най-добрият отговор е недостатъчно доказателства, което е трудно да се отпразнува в демонстрация, но е полезно в работеща система.
Примерите са също и началото на оценяването. Те могат да станат тестови модули, регресионни случаи, обучение за оценители и мониторингови проби. Когато възникне инцидент, коригиран случай може да стане нов пример. Това дава на системата памет. Без примери промените в подканите се превръщат в промени на настроението. Някой казва, че отговорът звучи по-добре. Друг казва, че звучи по-зле. Моделът се усмихва посредством всичко това, необезпокоен от доказателства.
Формата на изхода е оперативно решение
Дискусиите за подкани често отделят твърде много време на тон и твърде малко на формата на изхода. Тонът има значение, особено в комуникацията с клиенти или обществеността. Но формата на изхода решава дали отговорът може да бъде проверен, насочен, съхранен, одобрен, оспорен или използван от друга система. Един абзац може да е приятен. Структуриран изход може да е оперативен. Сериозната работа с ИИ често изисква и двете: четим проза за хората и полета, които машините могат да проверят.
Формата на изхода включва задължителни полета, позовавания на източници, увереност или несигурност, причини за отказ, флагове за ескалация, засегнати записи, предложени действия и състояние на човешко одобрение. В нея е посочено дали моделът може да остави поле празно. Посочено е дали трябва да цитира идентификатор на политика. Посочено е дали може да измисля категории или трябва да избира от контролиран списък. Посочено е какво се случва, когато входът е двусмислен. Тези избори не са козметика на подканата. Те са дизайн на работния процес.
Структурираният изход също държи модела в неговата рамка. Ако системата изисква отделно поле за доказателства, необоснованите твърдения стават видими. Ако изисква тип действие от разрешен списък, творческото използване на инструменти става по-трудно. Ако изисква несигурността да бъде изрична, проверяващите могат да извършват триаж. Ако изисква причина за отказ, блокираните случаи могат да бъдат анализирани. Подканата може да изисква тези неща, но заобикалящата система трябва да ги валидира. Да поискаш учтиво не е контрол. Това е предложение с форматиране.
Има и човешка страна. Хората се нуждаят от изход, който отговаря на техния работен ритъм. На юрист може да му трябват клаузи от източника и бележки за риска. На агент в поддръжката може да му трябва чернова, готова за клиента, плюс вътрешни кодове за причина. На плановик може да му трябва препоръка за маршрут и ограничението, което я е наложило. На мениджър може да му трябват обобщени причини, а не индивидуална проза. Ако формата на изхода пренебрегва потребителя, подканата може да е технически правилна и оперативно дразнеща. Това е често постижение, но не и полезно.
Авторитетът не може да се подразбира от услужливостта
Услужливият модел вдъхва доверие. Това е добре, докато услужливостта не бъде сбъркана с авторитет. Ако моделът изготвя отговор, кой може да го изпрати. Ако препоръчва възстановяване на сума, кой може да го одобри. Ако класифицира риск, кой може да действа въз основа на класификацията. Ако извлича поле, кой го коригира. Ако не може да намери доказателства, кой решава дали да продължи. Тези въпроси трябва да бъдат отговорени преди подканата, защото подканата не може да предостави институционален авторитет.
Дизайнът на авторитета включва роли, прагове, опашки за преглед, права за отмяна, пътища за ескалация и одитни записи. Той разграничава предложението от решението. Разграничава автоматизираното решение от човешкото решение, подкрепено от автоматизация. Посочва кога човек трябва да види материал от източника, а не само проза на модела. Посочва кога извикването на инструмент е разрешено и кога е блокирано. Посочва кой носи отговорност за вреда, забавяне, корекция и комуникация. Моделът може да помага в рамките на този дизайн. Той не трябва да бъде самият дизайн.
Това е особено важно, когато ИИ се добавя към съществуващи работни процеси. Съществуващият авторитет може да е неформален. Старши служител одобрява изключения, защото всички знаят да го питат. Ръководител на екип тълкува политиката, защото е виждал граничните случаи. Електронна таблица съдържа временно правило, защото системата не може. Когато ИИ навлезе, неформалният авторитет става крехък. Моделът може да мащабира старата двусмисленост по-бързо, отколкото хората могат да я забележат. Работата преди подканата е да направи авторитета достатъчно изричен, така че мащабирането да не мащабира просто объркването.
Струва си да се каже, че авторитетът не е враг на скоростта. Ясният авторитет често ускорява работата, защото хората знаят какво може да се движи без дебат, какво трябва да спре и кой може да решава. Неясният авторитет изглежда гъвкав, докато не срещне обем. Тогава всеки труден случай се превръща в малка конституционна криза с чат нишки като съдебна практика. Това не е препоръчителна правна система.
Оценяването не е проверка на усещане
Много итерации по подкани се оценяват на усет. Тази версия звучи по-добре. Онази е по-кратка. Тази е по-малко настойчива. Тези преценки могат да са полезни, но не са достатъчни. Работата с изкуствен интелект изисква оценка, която следва задачата. Дали моделът е използвал правилния източник. Дали е пропуснал задължителни полета. Дали е отказал, когато доказателствата липсват. Дали е ескалирал случаите с висок риск. Дали е запазил идентификаторите на политиките. Дали хората са го презаписвали. Дали клиентите са задавали по-малко последващи въпроси. Дали по-надолу по веригата екипите са виждали по-малко преработки.
Оценката трябва да включва обичайни случаи, крайни случаи, противникови случаи, остарели източници, липсващи данни, противоречиви политики и примери за приемлив отказ. Тя трябва да е възпроизводима. Трябва да разграничава повреда в модела от повреда в източника, повреда в подканата, повреда в интерфейса и повреда в процеса. В противен случай всеки проблем се превръща в проблем на подканата, защото подканата е частта, която всеки вижда. Видимата част не винаги е виновната част. Това важи както за софтуера, така и за срещите.
Оценката също така решава кога да се спре. Без тестов набор и критерии за пускане, работата по подкани може да продължи вечно, защото езикът винаги може да се подобрява. Винаги ще има друго прилагателно, друга инструкция, друг пример, друга корекция на форматирането. Въпросът не е дали подканата е съвършена. Въпросът е дали системата изпълнява задачата в рамките на договорените граници за риск, разходи и качество. Съвършенството е лош ръководител на пускането. То не носи пейджър.
Работата след подканата започва преди пускането
Пътищата за корекция трябва да се проектират преди първият потребител на продукцията да съобщи за проблем. Как потребителят отбелязва грешен отговор. Къде отива този сигнал. Кой го преглежда. Дали източникът се променя. Дали банката с примери се променя. Дали подканата се променя. Дали правило се променя. Дали праг се променя. Дали човек получава обратна връзка. Дали коригираният случай става регресионен тест. Ако корекцията не е проектирана, обратната връзка се превръща в купчина. Купчините са мястото, където ученето отива на дълга дрямка.
Наблюдението също трябва да се реши преди пускането. Следете не само латентността и разходите, но и нивата на отказ, нивата на липсващи източници, причините за презаписване, натоварването от ескалации, преработките по-надолу по веригата, темите на оплакванията, остарелите цитирания и промените в състава на задачите. Качеството на отговорите на модела е само една част от оперативното качество. Една система може да отговаря добре и въпреки това да насочва твърде много работа към хора. Може да отговаря бързо и въпреки това да увеличава корекциите. Може да намалява заявките и въпреки това да създава по-трудни заявки. Наблюдението трябва да вижда работата, а не само токените.
Работата преди писането на подкани всъщност никога не свършва. Появяват се нови политики. Променят се изходните системи. Потребителите откриват преки пътища. Моделът се променя. Бизнесът се променя. Подкана, която е работела през май, може да е грешна през септември, защото работата се е изместила под нея. Това не означава, че всичко е крехко. Означава, че операциите с ИИ се нуждаят от отговорност. Някой трябва да поддържа дефиницията на задачата, източниците, примерите, оценяването, правомощията и поправките. В противен случай подканата се превръща във вкаменелост с отлична граматика.
Урокът
Истинската работа е преди подканата, защото подканата е видимият ръб на по-голяма операционна система. Моделът се нуждае от задача, която може да изпълни, източници, на които може да се довери, граници, които не може да прекрачи, резултати, които могат да се проверят, примери, които кодират преценка, правомощия, които казват на хората и инструментите какво им е позволено, и оценяване, което може да различи подобрението от по-красивата проза. Без това подканата носи отговорности, които не може да изпълни.
Този възглед не омаловажава подканите. Той ги прави по-ценни. Подкана в подготвена операция може да бъде кратка, ясна, проверима и поддържаема. Тя може да фокусира модела, вместо да компенсира неяснотата. Може да се развива с примери и доказателства. Може да се променя с увереност, защото екипът знае какво означава добро. Това е по-добре от мистицизма около подканите, който най-често води до по-дълги подкани и по-тихи съмнения.
Преди да попитате как да подканите модела, попитайте каква работа организацията вече е свършила за модела. Наименувана ли е задачата. Авторитетни ли са източниците. Отбелязани ли са примерите. Структуриран ли е резултатът. Изрични ли са правомощията. Безопасен ли е провалът. Реално ли е оценяването. Проектирана ли е поправката. Ако отговорите са слаби, започнете оттам. Най-полезната подкана в стаята може да е онази, която кара всички да признаят, че подканата не е мястото, откъдето започва работата.