Системи штучного інтелекту дають непередбачувані результати. Цю проблему неможливо вирішити для систем штучного інтелекту загального призначення (ChatGPT), але її можна вирішити для систем штучного інтелекту, що належать компаніям і мають конкретну мету. Зобов'язання щодо прозорості можна вивести лише з GDPR. Оператори та постачальники систем ШІ повинні виконувати додаткові зобов'язання відповідно до Закону про ШІ.
Вступ
Як зробити систему штучного інтелекту прозорою? Відповідь на це питання для загальних систем штучного інтелекту: ніяк. Це тому, що ці загальні системи, включаючи ChatGPT, працюють на основі нейронних мереж. Як працює ця мережа, добре відомо. Якщо ви напишете формулу, що описує роботу мережі, ніхто не зрозуміє її, не кажучи вже про те, щоб правильно прочитати.
Державна законодавча послуга щодо захисту даних (GDPR) передбачає в статті 5 обов'язок прозорості при обробці персональних даних. Ця вимога застосовується до всіх систем штучного інтелекту, які обробляють персональні дані. Це всі системи, у яких під час навчання або введення користувача (часто через промт) були введені персональні дані. Це є фактичним, який (лише?) відмовився від Hamburgischer Datenschutzbeauftragte в небезпечному вигляді.
У ст. 5 п. 1 ч. д ДЗП вимагається, щоб дані були правдивими, тобто правильними. Це стосується всіх особистих даних у системах КІ. Зокрема, вже на момент inferenz, тобто коли система КІ створює результат, ця законодавча норма повинна бути виконана.
ВидаAI-Регламенту (Акти Інтелектуальної Владнності) знову визначає обов'язки, які особливо повинні виконувати поставники систем КІ. Особливі обов'язки встановлені для високоризикової КІ. Такий тип системи, швидше за все, буде рідкістю у практиці.
Майже всі компанії, які використовують системи КІ, є власниками. Для власників діють набагато менше обов'язків ніж для продавців. Власником вважається підприємство або організація згідно зі ст. 3 п. 4 КІ-VO, якщо воно „використовує систему КІ власною відповідальністю“. Все що виходить за рамки цього відноситься до поняття продавця (ст. 3 п. 3 КІ-VO).
Ідея підвищити прозорість і документацію систем ШІ прийшла до автора на засіданні експертної групи з ШІ Державного комісара із захисту даних Нижньої Саксонії, членом якої є автор. Автор також раніше опублікував книгу про розробку програмного забезпечення на основі тестування.
З одного боку, прозорість – це зовнішня презентація результатів ШІ. Однак чи не важливішою є внутрішня прозорість, тобто для оператора ШІ: як працює ШІ? Які результати він видає?
Підтвердження правильності висновків ШІ
Загалом, неможливо повністю гарантувати, що штучний інтелект витрачає лише правильні кошти. Однак можна наблизитися до цього. Перш ніж зробити пропозицію з цього приводу, наведемо приклад дуже хорошого перекладача DEEPL (з Німеччини!), який сам користується ШІ і, як і будь-яка інша система ШІ, іноді припускається помилок:
До компанії DEEPL звернулися з проханням перекласти текст, що містить грошову суму. Компанія DEEPL переклала €1 050,00 таким чином, що цифру євро було замінено на фунт стерлінгів. Очевидно, що це неправильно. Для тих, хто хоче спробувати самостійно: Це залежить від загального тексту! Це було частково приховано на скріншоті вище, тому що це була напівделікатна інформація. Ви, ймовірно, отримаєте правильний результат, якщо введете тільки останнє речення в DEEPL. Але якщо текст преамбули відрізняється, може виникнути помилка. Це лише один приклад того, як працюють непрозорі системи штучного інтелекту.
Тому помилок не уникнути. Як же все ж таки виконати свій обов'язок щодо прозорості та максимально забезпечити коректність результатів ШІ?
Рішення полягає у використанні тестових випадків.
Тестові кейси – це пари фактичних вхідних даних і цільових результатів. Тестовий кейс складається з фактичних вхідних даних і фактичного результату, який приймається як належний. Очевидно, це навіть враховано в Положенні про штучний інтелект (AI-VO):
Це пов'язано з тим, що ст. 3 № 53 Регламенту AI визначає термін "план випробування в реальних умовах" як "документ, що описує цілі, методологію, географічний, популяційний і часовий масштаб, моніторинг, організацію та проведення випробування в реальних умовах".
Нр. 56 того ж самого статті визначає AI-Компетентність як "умови, знання та розуміння, які дозволяють провайдерам, власникам та зацікавленим особам ураховуючи їхні окремі права та обов'язки згідно з цією директивою використовувати системи AI фахово, а також бути обізнаними щодо можливостей та ризиків AI та можливих шкод, які вони можуть спричинити
За допомогою тестових кейсів оператори (а тим більше провайдери) можуть краще зрозуміти можливості та ризики штучного інтелекту, який вони використовують або пропонують.
А також можуть бути створені Глибокі фейки, згадані в статті 3 КІ-ВО під номером 60. Тут мова йде про «зображення, звук або відео, яке було створене чи змінено за допомогою штучного інтелекту та має подібність до справжніх осіб, речей, місць, установ чи подій і може бути помилково прийнято за справжнє чи правдиве». При роботах з моделями зображень необхідно забезпечити те, щоб вхідні дані, які спрямовані на реальні особи та мають намір їх негативно висвітлювати, були добре розпізнані та зупинені. У будь-якому разі вже за допомогою тестових випадків можна документувати місця, де (ще) знаходяться слабкості системи штучного інтелекту.
Тестові кейси – чудовий засіб документування якості систем штучного інтелекту. Вони також можуть зробити такі системи більш прозорими та висвітлити їхні слабкі місця.
Зобов'язання постачальників систем ШІ, що не становлять високого ризику, оцінювати свою систему, як зазначено в ч. 4 ст. 6 Регламенту про ШІ, також може здійснюватися за допомогою тестових кейсів.
Система управління ризиками, про яку йдеться в ст. 9 (1) Регламенту про АІ, може бути дуже добре підкріплена за допомогою тестових кейсів.
Численні інші положення Закону про ШІ накладають на провайдерів і операторів систем ШІ зобов'язання, які можуть бути підтверджені задокументованими тестовими кейсами. До них належать:
- ч. 1 ст. 11 Регламенту про штучний інтелект: технічна документація системи штучного інтелекту з високим ступенем ризику
- Стаття 17 AI-VO: Управління якістю
- Ст. 53 Регламент ШІ в цілому: Обов'язки постачальників моделей ШІ загального призначення
- Статті 91 і 101 Регламенту про ШІ можуть мати негативні наслідки для провайдерів ШІ, якщо їхня документація виявиться недостатньою.
- Стаття 4 Регламенту про ШІ також вимагає від операторів забезпечити, щоб їхні працівники мали достатній досвід роботи зі штучним інтелектом.
Приклади тестових кейсів
Як виглядає тестовий кейс? Ось приклад мовної моделі, призначеної для відповіді на запитання:
Чи є (питання = вхід)Чи повинен (відповідь = вихід ШІ)Що таке файли cookie? Файли cookie – це записи даних… Чи є файли cookie текстовими файлами?
Вже ці два тестові кейси дають зрозуміти, що прагнення створити універсального чат-бота – не найкраща ідея. Ніхто не зможе написати достатньо тестових кейсів, щоб протестувати всі питання у світі, тобто забезпечити якість.
Тому система ШІ повинна бути адаптована до конкретного випадку використання або спеціалізованої галузі. Це не тільки полегшує виконання зобов'язань, що випливають з Регламенту про штучний інтелект, але й покращує якість результатів. Якість спеціалізованих чат-ботів, наприклад, для будівельної галузі, значно вища, ніж можна досягти за допомогою ChatGPT.
Кількість тестових кейсів має бути достатньо великою. Додаткові тестові кейси можна додавати поступово. Зокрема, якщо відповідь ШІ на запитання користувача була незадовільною, доцільно додати відповідний тестовий кейс. Потім тестовий кейс слугує щонайменше як документація, але краще – як основа для оптимізації системи ШІ та використання тестового кейсу для перевірки успішності оптимізації.
При побудові системи знань (як однієї з багатьох можливих систем штучного інтелекту) існує хитрість, яка дозволяє значно підвищити якість результатів. Так званий RAG-підхід призводить лише до обмеженого успіху і до вершини. Про що йдеться, ми розповімо в наступній статті,
Як можна прогнати тестові кейси?
Після того, як тестові кейси створені, їх потрібно прогнати. Конкретно це означає:
- Визначене "фактичне" з тестового кейсу подається ШІ як вхідні дані.
- ШІ відповідає.
- Відповідь ШІ порівнюється з "мішенню" з тестового кейсу.
Тестові кейси можуть виконуватися автоматично.
Людині залишається лише переглянути результати.
Існує кілька варіантів порівняння результатів роботи ШІ з очікуваним оптимумом з тестового прикладу:
- ШІ-аналіз із порівнянням семантичної схожості
- Аналіз ШІ за допомогою мовної моделі (або декількох!)
- Звичайний аналіз (приклад: "Ні" в завданні та "Так" у висновку ШІ суперечать одне одному)
- Поєднання всіх методів (рекомендовано)
Альтернатива, згадана у другому випадку, – використання декількох мовних моделей одночасно для аналізу результатів тестування – дуже добре працює з моделями з відкритим вихідним кодом. Витрати завжди однакові, а саме нульові (плюс фіксовані операційні витрати на сервер). У разі використання ChatGPT витрати були б досить високими в довгостроковій перспективі.
За допомогою цих методів аналізу тестові кейси можуть бути проаналізовані значною мірою автоматично. Потім людина перевіряє результат і може написати висновок у документації.
Результат
Функціональність систем штучного інтелекту можна задокументувати за допомогою тестових кейсів і таким чином зробити їх прозорими. Звичайно, прозорість також включає в себе інформацію про архітектуру системи штучного інтелекту. Це можна легко зробити, якщо ви самі експлуатуєте штучний інтелект. У випадку зі сторонніми системами, такими як ChatGPT, вам доведеться покладатися на інформацію, надану провайдером (OpenAI або подібними).
Тестові кейси також можна використовувати для перевірки та покращення коректності результатів роботи ШІ.
Таким чином, тестові кейси мають кілька переваг і великих вигод. Вони часто створюються швидко. Завдяки підтримці штучного інтелекту тестові кейси можна навіть створювати автоматично. Таким чином, людина, яка створює тестові кейси, отримує дуже хороший шаблон для тестових кейсів і може виправити їх, витративши на це лише частину ручних зусиль, які інакше були б потрібні.
My name is Klaus Meffert. I have a doctorate in computer science and have been working professionally and practically with information technology for over 30 years. I also work as an expert in IT & data protection. I achieve my results by looking at technology and law. This seems absolutely essential to me when it comes to digital data protection. My company, IT Logic GmbH, also offers consulting and development of optimized and secure AI solutions.
