Прибуток:
- Можливість розрізнити, де в робочому процесі машинного навчання (код, дані, документ) штучний інтелект економить час із низьким ризиком, а де такі рішення, як показники/дані/запуск у виробництво, залишаються за людиною відповідно до рівня ризику завдання.
- Можливість застосовувати дисципліну, яка перевіряє кожен результат ШІ, підключаючи його до джерела, повторно запускаючи, вимірюваючи та пропускаючи через інженерний фільтр.
- Здатність придбати звичку не надсилати необроблені конфіденційні та особисті дані до зовнішніх інструментів, використовувати схвалені корпоративними інструменти та вирішувати проблеми безпеки лише в цілях захисту.
Штучний інтелект у машинному навчанні: роль, межі, перевірка та відповідальність
Інженер машинного навчання (інженер ML: професіонал із програмного забезпечення, який розробляє, навчає та переносить моделі, які навчаються на основі даних, у виробництво) сьогодні працює з іншим інструментом штучного інтелекту на кожному кроці своєї роботи. Помічник кодування діє під час написання коду, модель розмови під час дослідження даних і велика модель мови (LLM: нейронна мережа з мільярдами параметрів, яка розуміє та створює текст) під час створення документації. Цей модуль розглядає штучний інтелект як розроблений продукт і щоденний інструмент роботи інженера ML. Він працює шляхом чіткого окреслення меж відповідальності без змішування двох ролей.
У цьому першому розділі ми відповідаємо на основне запитання: де штучний інтелект економить реальний час у розробці машинного навчання, а де ми повинні залишити рішення людям? Відповідь лежить в основі інженерної дисципліни: той, хто робить, швидкий, той, хто перевіряє, відповідальний.
Де штучний інтелект стане в нагоді в інженерії ML?
Проект ML проходить приблизно такі етапи: збір даних, очищення даних, розробка функцій (перетворення необроблених даних у цифрові сигнали, які може зрозуміти модель), навчання моделі, оцінка, розгортання (розгортання: відкриття моделі для реального користувача) і моніторинг. ШІ допомагає на кожній зупинці на цій лінії, але рівень його повноважень різний.
Області з високою винагородою та низьким ризиком: створення скелета коду, складання функції перетворення даних, інтерпретація повідомлень журналу, опис трасування стека, узагальнення приміток до експерименту, написання документації та README, пропозиція тестового випадку. Тут помилки штучного інтелекту коштують дешево; оскільки вихідні дані вже пройдуть тестування та перевірку.
Сфери високого ризику: рішення про те, які дані підуть на навчання, підтвердження того, чи повинна модель запускатися у виробництво, оцінка метрики як «досить хороша», рішення про обробку персональних даних, закриття вразливості системи безпеки як «сміття». Це впливає на гроші, конфіденційність, юридичну відповідальність і довіру користувачів. Штучний інтелект дає пропозиції тут; Рішення приймається компетентним інженером і відповідальною командою.
Порада: перш ніж передати завдання штучному інтелекту, запитайте: «Яка ціна, якщо цей результат буде неправильним, і як легко хтось вловить помилку?» Якщо ціна низька, а захоплення легко, передайте його. Якщо ціна висока або захоплення складно, використовуйте ШІ лише для чернетки, і ви вирішуєте.
Перевірочна дисципліна: три кроки
У розробці ML вихід ШІ ніколи не є «завершеною роботою»; Це чернетка. Проведіть кожен вивід за допомогою цих трьох кроків:
- Підключіть його до джерела. Якщо в моделі вказано число, порогове значення або «найкращий досвід», спирайтеся на офіційну документацію, фактичне значення в кодовій базі або виміряний показник. Тут найчастіше вловлюється «підгонка моделі» (галюцинація: впевнене продукування мовною моделлю нереальної інформації).
- Перезапустіть і виміряйте. Запустіть згенерований код, перерахуйте метрику, яку він виробляє, на вашому власному наборі тестів, перевірте запропонований 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%, чудово», — сказав асистент моделі в чаті. Інженер застосував третій крок (інженерний фільтр) і зрозумів: у цільовому стовпці випадково витік атрибутів (витік даних: модель бачить інформацію, яку вона не повинна бачити під час навчання). Фактична продуктивність була значно нижчою. Скептицизм інженера, а не «чудова» інтерпретація ШІ врятувала роботу.
Випадок 3 - Запобігання порушенню конфіденційності. Команда вставляла журнали виробничих помилок у зовнішню модель і говорила «виправте цю помилку». У журналах були ідентифікаційні номери клієнтів. Команда створила правило написання невеликого сценарію, який спочатку маскує журнали (роблячи їхні ідентифікаційні номери ***) і надсилаючи їх таким чином. Ризик злому зник, швидкість надання допомоги не змінилася.
Шаблони, які можна копіювати
Завдання: [що робити, одне речення] Контекст: [схема даних, розмір, обмеження; НЕМАЄ ФАКТИЧНИХ особистих даних]Обмеження: [мова/бібліотека, продуктивність, відтворюваність]Показники: [як виміряти успіх]Бажаний результат: [код/опис/список] і чому в цьому форматі
Перегляньте цей код. Оцініть не лише його роботу, але також з точки зору: 1) Граничних випадків (порожній вхід, відсутній стовпець, дуже великі дані) 2) Ризик витоку даних 3) Відтворюваність (початкова частина, версія) Запропонуйте виправлення для кожної знайденої проблеми. Позначте «перевірити», де ви не впевнені. Код: [код]
Інтерпретуйте результат цього показника, але спочатку запитайте: чи цей показник правильний для цієї проблеми? Проблема: [збалансована/незбалансована класифікація, регресія, ранжування...]Повідомлений показник і значення: [напр. accuracy 0.99]Яку метрику ви б порекомендували і чому, і на які ознаки мені слід звернути увагу, щоб змусити мене сумніватися в поточному результаті?
Перевірте, чи є особиста/конфіденційна інформація в даних, які я надам у наступному запиті. Перелічіть поля (ім’я, e-mail, ідентифікаційний номер, телефон, адреса), які необхідно замаскувати в тексті нижче. Текст: [текст]
Таблиця ролей і повноважень
Квест
Роль штучного інтелекту
Власник рішення
Скелет коду / функція перетворення
генератор тяги
Інженер (відгуки)
EDA / резюме даних
прискорювач
Інженер (перевіряє вимірюванням)
Метрична інтерпретація
Пропозиція
інженер
Які дані підуть на навчання?
Пропозиція
Команда + власник даних
Запустити модель у виробництво
Контрольний список нагадування
Відповідальний інженер + команда
Обробка персональних даних
Немає (не використовується)
Юридичний + контролер даних
Поширені помилки
- Використання результату без перевірки. Найпоширеніша і найдорожча помилка. Код або показник, які виглядають добре, не означає, що вони правильні.
- Вставлення необроблених конфіденційних даних в інструмент. Після відправлення його не можна забрати назад.
- Покладаючись на неправильний показник. Несумісні показники, такі як точність незбалансованих даних і RMSE у проблемах ранжирування, вводять в оману.
- Помилково сприймаючи штучний інтелект як особу, яка приймає рішення. Він дає пропозиції; Відповідальність лежить на підписувачі.
- Безконтекстна підказка. Неоднозначні запити, такі як «напишіть модель», створюють результати, які неможливо перевірити.
Підсумовуючи
Штучний інтелект — це як продукт, розроблений інженером ML, так і його щоденний реплікатор. Його значення найвище в задачах з низьким рівнем ризику, які легко перевіряються, наприклад код-дані-документ; Рішення, що стосуються грошей, конфіденційності та безпеки, залишаються за особою. Підключіть кожен вихід до джерела, виміряйте ще раз, пропустіть через інженерний фільтр. Захищайте конфіденційні дані, використовуйте схвалені транспортні засоби, працюйте в охороні лише в оборонних цілях. Ця дисципліна є базовою для всіх наступних підрозділів.
Аплікаційне завдання
Виберіть завдання з власного проекту (наприклад, написати функцію очищення даних). Спочатку напишіть слабку підказку, потім напишіть сильну підказку, використовуючи шаблон у цьому модулі. Візьміть обидва результати, застосуйте триетапну перевірку (посилання на джерело, повторний запуск, інженерний фільтр). Зверніть увагу, яка підказка зберігає скільки хвилин і скільки виправлень.
контрольний список
- [ ] Я визначив рівень ризику (низький/високий) свого завдання.
- [ ] Я не вказав жодних особистих/конфіденційних даних у запиті; Я маскував це або використовував синтетичний зразок.
- [ ] Я підключив вихід до джерела, запустив його знову, відфільтрував його з інженерної точки зору.
- [ ] Я перевірив, чи вибрав правильний показник.
- [ ] Я прийняв важливе рішення (введення в виробництво, обробка даних) сам/з командою, я не залишив це штучному інтелекту.
- [ ] Я використовував автомобіль, затверджений компанією.