Печалби:
- Възможността да се разграничи къде в работния процес на ML (код, данни, документ) изкуственият интелект спестява време с нисък риск и къде решения като показатели / данни / пускане в производство са оставени на човека, в съответствие с нивото на риск на задачата.
- Възможност за прилагане на дисциплина, която проверява всеки AI изход, като го свързва към източника, пуска го повторно, измерва го и го прекарва през инженерен филтър.
- Способност да придобиете навика да не изпращате необработени поверителни и лични данни към външни инструменти, да използвате корпоративно одобрени инструменти и да обработвате проблеми със сигурността само за отбранителни цели.
Изкуствен интелект в машинното обучение: роля, граници, валидиране и отговорност
Инженер по машинно обучение (ML инженер: софтуерен професионалист, който проектира, обучава и въвежда модели, които се учат от данни в производството) днес работи с друг инструмент за изкуствен интелект на всяка стъпка от работата си. Асистентът за кодиране е в сила при писане на код, модел на разговор при изследване на данни и голям езиков модел (LLM: невронна мрежа с милиарди параметри, която разбира и създава текст) при изготвяне на документация. Този модул разглежда изкуствения интелект както като разработен продукт, така и като ежедневен работен инструмент на ML инженер. Той действа, като ясно очертава границите на отговорността, без да смесва двете роли.
В тази първа част отговаряме на основния въпрос: Къде в ML инженерството изкуственият интелект спестява реално време и къде трябва да оставим решението на хората? Отговорът е в основата на инженерната дисциплина: този, който прави, е бърз, този, който проверява, е отговорен.
Къде е полезен изкуственият интелект в ML инженерството?
Един ML проект преминава през приблизително следните линии: събиране на данни, почистване на данни, инженеринг на функции (превеждане на необработени данни в цифрови сигнали, които моделът може да разбере), обучение на модела, оценка, внедряване (разгръщане: отваряне на модела за реалния потребител) и мониторинг. AI помага на всяка спирка по тази линия, но нивото на неговия авторитет варира.
Области с високо възнаграждение и нисък риск: създаване на кодов скелет, изготвяне на функция за трансформиране на данни, интерпретиране на съобщения в регистрационния файл, описание на проследяване на стека, обобщаване на бележки за експерименти, писане на документация и README, предлагане на тестов случай. Тук грешките на изкуствения интелект са евтини; защото изходът вече ще премине през тестване и преглед.
Области с висок риск: вземане на решение какви данни да бъдат обучени, потвърждение дали моделът трябва да бъде пуснат в производство, преценка дали показателят е „достатъчно добър“, решение за обработка на лични данни, затваряне на уязвимост в сигурността като „боклук“. Те засягат парите, поверителността, правната отговорност и доверието на потребителите. Изкуственият интелект дава предложения тук; Решението се взема от компетентния инженер и отговорния екип.
Съвет: Преди да възложите задача на AI, попитайте: „Каква е цената, ако този резултат е грешен и колко лесно някой ще хване грешката?“ Ако цената е ниска и улавянето е лесно, предайте го. Ако цената е висока или улавянето е трудно, използвайте AI само за черновата и вие решавате.
Дисциплина за проверка: три стъпки
В ML инженерството изходът на AI никога не е „завършена работа“; Това е чернова. Изпълнете всеки изход през тези три стъпки:
- Свържете го към източника. Ако моделът посочи число, праг или „най-добра практика“, базирайте го на официална документация, действителна стойност в кодовата база или измерена метрика. Тук най-често се улавя „напасване на модела“ (халюцинация: увереното производство на нереална информация от езиковия модел).
- Рестартирайте и измерете. Стартирайте генерирания код, преизчислете показателя, който произвежда върху вашия собствен набор от тестове, валидирайте предложената SQL заявка върху малка извадка. Кодът, който не работи, е безполезен, дори и да изглежда добре.
- Прекарайте го през инженерен филтър. Резултатът издържа ли на мащаба? Разгледани ли са крайни случаи (празни данни, много голям вход, липсващи полета)? Има ли нарушение на сигурността и поверителността? Само човек, който познава областта, може да направи тази стъпка.
Слаба подкана / Силна подкана
Слаба подкана: „Напишете ми код за обучение на модел.“
Мощна подкана: "Напишете обучителен скрипт за двоична класификация с scikit-learn. Вход: data/train.parquet, целева колона is_churn. Има дисбаланс на класа (положителен процент ~8%), обработете го с class_weight. Използвайте PR-AUC (област под кривата на прецизност-извикване) като показател за оценка, защото точността е подвеждаща за небалансирани данни. Поправете произволно начално число до 42. Тествайте в края на комплекта за отпечатване на код PR-AUC."
Разлика: втората подкана задача съдържа верността на данните, правилната метрика, информация за дисбаланс и изискване за повторяемост. Именно от този контекст изходът е проверим и използваем.
Поверителност и сигурност на данните: първата отговорност на инженера
Инженерът по ML често се докосва до най-чувствителните данни на компанията: записи на клиенти, история на транзакции, здравни или финансови данни, регистрационни файлове на производствени системи. Три правила при даване на данни на инструменти с изкуствен интелект:
- Не изпращайте необработени лични и поверителни данни към външни инструменти. Например, вместо да поставяте имейли на клиенти в подканата, изпратете схемата и фиктивните (синтетични) проби. Използвайте маскиран пример като "ex: ahmet@example.com" вместо реални данни.
- Използвайте корпоративно одобрени превозни средства. Изберете инструменти, които са ясни по договор къде се обработват данните, дали се съхраняват, дали се използват за обучение или не. Обработката на корпоративни данни с личен акаунт е нарушение в повечето компании.
- Политика за минимални данни. Дайте минималния контекст, необходим за решаване на задачата. Не цялата таблица, а съответните 5 колони и схема.
Внимание: приемете, че текстът, който давате на езиков модел, не може да бъде отменен. Не изпращайте необработени лични данни, мислейки си „Ще ги изтрия по-късно“; Рискът е възникнал в момента на изпращането му.
Отбранителна употреба в областта на сигурността
ML инженерите често инсталират системи за сигурност: откриване на измами, класифициране на злонамерен трафик, удостоверяване. В целия този модул ние покриваме проблеми със сигурността само за отбранителни цели: откриване на атака, укрепване на системата, затваряне на уязвимостта. Използването на изкуствен интелект за неоторизиран достъп, изтичане на данни или неоторизирана намеса в нечия друга система е както незаконно, така и против професионалната етика. Когато откриете уязвимост, правилният начин е да я докладвате отговорно и да я коригирате; не експлоатират.
три мини калъфа
Случай 1 – Спестено време. Един ML инженер обикновено би прекарал половин ден, правейки проучвателен анализ на данни (EDA) на набор от данни от 40 колони. Той даде схемата и изхода df.describe() на изкуствения интелект и попита: „Кои колони имат висок процент на отклонение и липсващи стойности, кои трансформации препоръчвате?“ След 20 минути той получи списък с приоритети, който проверява всеки елемент със собствен код. Спестяване: ~3 часа, нисък риск от грешка, тъй като се измерва всяка рекламация.
Случай 2 - Уловена грешка. „Точността на обучението е 99%, страхотно“, каза асистентът в чата на модела. Инженерът приложи третата стъпка (инженерен филтър) и осъзна: в целевата колона случайно изтекоха атрибути (изтичане на данни: моделът вижда информация, която не трябва да вижда при обучение). Действителното представяне беше много по-ниско. Скептицизмът на инженера, а не „страхотната“ интерпретация на AI, спаси работата.
Случай 3 - Предотвратяване на нарушаване на поверителността. Екип поставяше регистрационните файлове за производствени грешки във външен модел и казваше „коригирайте тази грешка“. В дневниците имаше идентификационни номера на клиенти. Екипът създаде правило за писане на малък скрипт, който първо маскира регистрационните файлове (правейки техните идентификационни номера ***) и ги изпраща по този начин. Рискът от нарушение е изчезнал, скоростта на помощ не се е променила.
Копируеми шаблони
Задача: [какво да направя, едно изречение] Контекст: [схема на данните, размер, ограничения; НЯМА ДЕЙСТВИТЕЛНИ лични данни] Ограничения: [език/библиотека, производителност, възпроизводимост] Показатели: [как да се измери успехът] Желан резултат: [код/описание/списък] и защо в този формат
Вижте този код. Оценете не само, че работи, но и по отношение на: 1) Гранични случаи (празен вход, липсваща колона, много големи данни) 2) Риск от изтичане на данни 3) Възпроизводимост (начална стойност, версия) Предложете корекции за всеки проблем, който намерите. Маркирайте „потвърдете“, където не сте сигурни. Код: [код]
Интерпретирайте резултата от тази метрика, но първо попитайте: тази метрика правилна ли е за този проблем? Проблем: [балансирана/небалансирана класификация, регресия, класиране...]Отчетена метрика и стойност: [напр. точност 0,99] Кой показател бихте препоръчали и защо, и какви признаци трябва да търся, за да ме накарат да се съмнявам в текущия резултат?
Проверете дали има лична/поверителна информация в данните, които ще дам на следната подкана. Избройте полетата (име, имейл, личен номер, телефон, адрес), които трябва да бъдат маскирани в текста по-долу. Текст: [текст]
Таблица с роли и правомощия
Мисия
Ролята на изкуствения интелект
Собственик на решението
Скелет на код / функция за трансформация
генератор на чернова
Инженер (отзиви)
EDA / обобщение на данните
ускорител
Инженер (проверява чрез измерване)
Метрична интерпретация
Предложение
инженер
Какви данни ще влязат в обучението?
Предложение
Екип + собственик на данни
Поставете модела в производство
Напомняне за контролен списък
Отговорен инженер + екип
Обработка на лични данни
Няма (не се използва)
Правни + администратор на данни
Често срещани грешки
- Използване на изхода без валидиране. Най-честата и най-скъпа грешка. Код или показател, който изглежда добре, не означава, че е правилен.
- Поставяне на необработени поверителни данни в инструмента. Веднъж изпратено, не може да бъде взето обратно.
- Разчитане на грешен показател. Несъвместими показатели като точност при небалансирани данни и RMSE при проблеми с класирането са подвеждащи.
- Погрешно възприемане на изкуствения интелект като човек, който взема решения. Той дава предложения; Отговорността е на подписалия.
- Подкана без контекст. Двусмислените заявки като „напишете модел“ водят до непроверим резултат.
В обобщение
Изкуственият интелект е както продуктът, разработен от ML инженера, така и неговият ежедневен репликатор. Стойността му е най-висока при задачи с нисък риск, лесно проверени като код-данни-документ; Решенията, засягащи парите, поверителността и сигурността, остават за лицето. Свържете всеки изход към източника, измерете отново, преминете през инженерния филтър. Защитете поверителни данни, използвайте одобрени превозни средства, работете в охраната само за отбранителни цели. Тази дисциплина е основа за всички следващи звена.
Задача за приложение
Изберете задача от вашия собствен проект (напр. писане на функция за почистване на данни). Първо напишете слаба подкана, след това напишете силна подкана, като използвате шаблона в този модул. Вземете и двата изхода, приложете проверка в три стъпки (връзка към източника, повторение, инженерен филтър). Обърнете внимание коя подкана спестява колко минути и колко корекции.
контролен списък
- [ ] Определих нивото на риск (ниско/високо) на моята задача.
- [ ] Не съм въвел действителни лични/поверителни данни в подканата; Маскирах го или използвах синтетична проба.
- [ ] Свързах изхода към източника, пуснах го отново, филтрирах го от инженерна гледна точка.
- [ ] Проверих дали съм избрал правилния показател.
- [ ] Взех критичното решение (пускане в производство, обработка на данни) сам/с екипа, не го оставих на изкуствения интелект.
- [ ] Използвах корпоративно одобрено превозно средство.