Критериите за оценка са теория за добра работа

Отговор за върната поръчка изглежда готов за изпращане: граматически правилен, любезен и кратък. В този илюстративен случай автоматизирана оценка му дава пълен брой точки. Асистентът обаче казва на клиента, че парите са възстановени, въпреки че никой не е проверил платежната система.

Грешката не е в слаб изказ. Тя е в слабо определение на добра работа.

В демонстрация за оценяване от включените източници екип изгражда оценки за агент, който пише софтуерна документация. Интересният момент е когато човекът, който познава работата, описва какво означава качество и инструмент превръща описанието в критерии. После ниска оценка поражда правилното съмнение: може би агентът има нужда от поправка, а може би оценяването.

Критериите са теория за задачата. Тествайте теорията.

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

Екипите често започват с лесни за оценяване измерения: яснота, тон, структура, пълнота. Те са полезни. Рядко са достатъчни.

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

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

Първата проверка може да е малка. Не може да е мъглява.

1. Собственик на задачата

   добри, лоши и спорни случаи

   обосновава
2. Точни проверки идентичност · разрешение · целева система

   кодът налага фактите

   обосновава
3. Смислови критерии

   моделът оценява само нуждаещото се от тълкуване

   обосновава
4. Преглед на разногласията

   поправка на етикети и критерии

Проверка	По-подходящ отговорник	Защо
Съществува задължително разрешение	Код и авторитетни записи	Фактът е точен и има последствия
ID в целевата система съвпада с идентичността в източника	Код и тестов запис	Модел не трябва да гадае идентификатор
Отговорът отговаря на въпроса на клиента	Проверени от човек критерии, евентуално модел	Смисълът изисква тълкуване
Тонът подхожда на ситуацията	Проверени от човек критерии, евентуално модел	Съществува повече от една приемлива форма

Нашето ръководство за внедряване на AI в съществуващи процеси очертава същата граница между смислова преценка и точни проверки при автоматизацията. Увереността на модела не се превръща в разрешение.

Оценката наследява слепите петна на критериите

Възражението е справедливо: „Човек не може да проверява всяко изпълнение на агент. Нужен ни е оценител, който работи в голям мащаб“. Да. Въпросът е какво точно мащабира оценителят.

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

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

Разглеждайте разногласията, не само средното съвпадение. Ако оценителят допусне отговор, който ръководител на поддръжката е отхвърлил, попитайте кой липсващ критерий го обяснява. Ако двама експерти не са съгласни, запазете и двете оценки и намерете правилото, което тълкуват различно. Не заличавайте спора със средна стойност.

Подборът на случаи е толкова важен, колкото формулировката на критерия. Набор от рутинни успехи може да направи оценителя да изглежда надежден, докато трудните случаи остават недокоснати. Включете непълни записи, противоречиви инструкции и случаи, в които правилният отговор е да се спре и попита. Дръжте отделен набор случаи, по които авторите на критериите не са настройвали оценката, така че промяна, подобряваща познатите примери, да се докаже и другаде. Когато бизнес правилото се промени, обновете и етикетите, и очакваните резултати; замразен тестов набор може да награждава вчерашната политика.

Дръжте резултата свързан с оценката

Критериите за агент по синхронизация трябва да следват клиентския резултат. Променен ли е правилният контакт? Спазено ли е съгласието? Може ли неуспешен запис да се изпълни повторно, без да се повтаря действие с последици?

Ръководството за конектора към Brevo обяснява защо успешното API извикване може да съществува едновременно с липсващ атрибут. Оценка, която проверява само дали агентът е извикал крайната точка, пропуска резултата. Оценка само на целевата система може да пропусне забранен път, който случайно е дал правилна стойност. И двете имат значение, когато пътят носи риск.

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

Цената е експертно време предварително. Ползата е, че всяка следваща оценка има смисъл, който някой може да защити.

Таблото може да показва оценка. Само критериите казват какво сте броили.