Компанії, які інвестують у генеративний штучний інтелект, виявляють, що тестування та гарантія якості є двома найважливішими сферами для вдосконалення. InfoWorld описує чотири стратегії для тестування LLM, вбудованих у генеративні програми ШI.
Існує значне занепокоєння навколо використання копайлотів ШІ для зменшення ручної роботи, підвищення продуктивності розробників програмного забезпечення за допомогою генераторів коду та впровадження інновацій із генеративним ШІ. Можливості для бізнесу спонукають багато команд розробників створювати бази знань із векторними базами даних і вбудовувати великі мовні моделі (LLM) у свої програми.
Деякі загальні варіанти використання для створення застосунків із можливостями LLM включають пошук, створення контенту, узагальнення документів, чат-боти та програми підтримки клієнтів. Галузеві приклади включають розробку порталів для пацієнтів у сфері охорони здоров’я, удосконалення робочих процесів молодшого банкіра у сфері фінансових послуг і прокладання шляху до майбутнього заводу у сфері виробництва.
Компанії, які інвестують в LLM, стикаються з деякими початковими перешкодами. Зокрема, з управлінням даними, вибором архітектури LLM, усуненням ризиків безпеки та розробкою плану хмарної інфраструктури.
Більше хвилює те, як організації планують тестувати свої моделі LLM і програми. Ось підбірка нещодавніх новин: одна авіакомпанія повернула гроші, запропоновані чат-ботом, розробники отримують судові позови за порушення авторських прав.
«Тестування моделей LLM вимагає багатогранного підходу, який виходить за межі технічної суворості. Команди повинні брати участь в ітераційному удосконаленні та створювати детальну документацію, щоб запам’ятати процес розробки моделі, методології тестування та показники ефективності. Взаємодія з дослідницьким співтовариством для порівняння й обміну найкращими практиками також є ефективною», – каже Аміт Джейн, співзасновник і головний операційний директор Roadz.
Стратегії тестування для вбудованих LLM
Командам розробників потрібна стратегія тестування LLM. Розглянемо як відправну точку такі практики для тестування LLM, вбудовані у спеціальні програми:
- Створюйте тестові дані для розширення якості програмного забезпечення.
- Автоматизуйте тестування якості та продуктивності моделі.
- Оцініть якість RAG на основі варіанту використання.
- Розробіть показники якості та контрольні показники.
Створюйте тестові дані для розширення якості програмного забезпечення
Більшість команд розробників не створюватимуть узагальнені LLM, а розроблятимуть програми для конкретних кінцевих користувачів і випадків використання. Щоб розробити стратегію тестування, команди повинні розуміти характер користувачів, цілі, робочий процес і контрольні показники якості.
«Першою вимогою для тестування LLM є знання завдання, яке LLM має бути в змозі вирішити. Для цих завдань можна створити тестові набори даних, щоб визначити показники продуктивності LLM. Тоді можна або оптимізувати підказки, або систематично налаштувати модель», – каже Якоб Прахер, технічний директор Mindbreeze.
Наприклад, LLM, розроблена для обслуговування клієнтів, може включати тестовий набір даних про типові проблеми користувача та найкращі відповіді. Інші випадки використання LLM можуть не мати простих засобів для оцінки результатів, але розробники все одно можуть використовувати тестові дані для виконання перевірок.
«Найнадійніший спосіб перевірити LLM – це створити релевантні тестові дані, але проблема полягає у витратах і часі на створення такого набору даних. Як і будь-яке інше програмне забезпечення, LLM-тестування включає модульне, функціональне, регресійне і продуктивне тестування. Крім того, тестування LLM вимагає упередженості, справедливості, безпеки, контролю вмісту й тестування пояснюваності», – каже Кішоре Гадіражу, віцепрезидент із розробки Solix Technologies.
Автоматизуйте тестування якості та продуктивності моделі
Після набору тестових даних команди розробників повинні розглянути кілька підходів до тестування залежно від цілей якості, ризиків і міркувань вартості. Компанії починають переходити на автоматизовані методи оцінки, а не на оцінку людиною через їхню часову та економічну ефективність. Однак вони все одно повинні залучати експертів із домену для ситуацій, коли важливо вловити нюанси, які автоматизовані системи можуть не помітити.
Розробникам і дослідникам даних нелегко знайти правильний баланс між автоматизацією й тестуванням за допомогою людини.
«Ми пропонуємо поєднання автоматизованого порівняльного аналізу для кожного етапу процесу моделювання, а потім поєднання автоматизації та ручної перевірки для наскрізної системи. Для основних випусків застосунків вам майже завжди потрібен останній раунд ручної перевірки тестового набору. Особливо, якщо ви запровадили нові вбудовування, нові моделі або нові підказки, які, як ви очікуєте, підвищать загальний рівень якості, оскільки часто покращення є непомітними або суб’єктивними», – говорить Стівен Хілліон, старший віцепрезидент із даних та ШІ в Astronomer.
Ручне тестування є розумним заходом, поки не буде надійних платформ тестування LLM.
Gadiraju ділиться такими бібліотеками та інструментами для тестування LLM:
- AI Fairness 360 – це набір інструментів з відкритим кодом, який використовується для вивчення, звітування та пом’якшення дискримінації й упередженості в моделях машинного навчання.
- DeepEval – платформа оцінювання LLM з відкритим вихідним кодом, схожа на Pytest, але спеціалізована на модульному тестуванні результатів LLM.
- Baserun – інструмент для налагодження, тестування й ітеративного вдосконалення моделей.
- NVIDIA NeMo-Guardrail – набір інструментів з відкритим вихідним кодом для додавання програмованих обмежень на виходи LLM.
Моніка Роміла, директорка з інструментів обробки даних і середовища виконання в IBM Data and AI, поділилася двома областями тестування для магістерських програм у корпоративних випадках:
- Оцінка якості моделі оцінює якість моделі за допомогою академічних і внутрішніх наборів даних для випадків використання, як-от класифікація, вилучення, узагальнення, генерація та доповнена генерація пошуку (RAG).
- Тестування продуктивності моделі підтверджує затримку моделі (час, що минув для передачі даних) і пропускну здатність (кількість даних, оброблених за певний проміжок часу).
Роміла каже, що тестування продуктивності залежить від двох критичних параметрів: кількості одночасних запитів і кількості згенерованих токенів (фрагментів тексту, які використовує модель):
«Важливо тестувати різні розміри й типи навантаження та порівнювати продуктивність із наявними моделями, щоб побачити, чи потрібні оновлення».
DevOps і хмарні архітектори повинні враховувати вимоги до інфраструктури для проведення продуктивності та навантажувального тестування програм LLM.
«Розгортання інфраструктури тестування для великих мовних моделей передбачає створення надійних обчислювальних ресурсів, рішень для зберігання даних та інфраструктур для тестування. Інструменти автоматизованого забезпечення, такі як Terraform, і системи контролю версій, такі як Git, відіграють ключову роль у відтворюваних розгортаннях та ефективній співпраці, підкреслюючи важливість балансування ресурсів, сховища, стратегій розгортання та інструментів співпраці для надійного тестування LLM», – каже Хезер Сундхайм, керуючий директор із розробки рішень у SADA.
Оцініть якість RAG на основі варіанту використання
Деякі методи підвищення точності LLM включають централізацію контенту, оновлення моделей останніми даними та використання RAG у конвеєрі запитів. RAG є важливими для поєднання потужності LLM із конфіденційною інформацією компанії.
У типовій програмі LLM користувач вводить запит, програма надсилає його LLM, а вона генерує відповідь, яку програма надсилає назад користувачеві. За допомогою RAG програма спочатку надсилає підказку в інформаційну базу даних, наприклад пошукову систему або векторну базу даних, щоб отримати відповідну інформацію, пов’язану із предметом. Програма надсилає підказку та цю контекстну інформацію до LLM, яку використовує для формулювання відповіді. Таким чином, RAG обмежує відповідь LLM релевантною та контекстуальною інформацією.
Використання RAG із LLM зменшує галюцинації та підвищує точність. Однак використання RAG додає новий компонент, який вимагає тестування його релевантності та продуктивності. Типи тестування залежать від того, наскільки легко оцінити відповіді RAG і LLM і наскільки команди розробників можуть використовувати відгуки кінцевих користувачів.
Деон Ніколас, генеральний директор Forethought, поділився трьома різними підходами:
- Золотий стандарт наборів даних або позначених людиною наборів даних правильних відповідей на запити, які слугують еталоном продуктивності моделі.
- Навчання з підкріпленням або тестування моделі в реальних сценаріях, як-от запитання про рівень задоволеності користувача після взаємодії з чат-ботом.
- Змагальні мережі або навчання вторинного LLM для оцінки продуктивності основного, що забезпечує автоматичне оцінювання, не покладаючись при цьому на відгуки людей.
«Кожен метод передбачає компроміси, збалансовуючи людські зусилля та ризик непомічення помилок. Найкращі системи використовують ці методи в системних компонентах, щоб мінімізувати помилки та сприяти надійному розгортанню ШІ», – каже Ніколас.
Розробіть показники якості та контрольні показники
Коли у вас є дані тестування, новий або оновлений LLM і стратегія тестування, наступним кроком є перевірка якості на відповідність заявленим цілям.
«Щоб забезпечити розробку безпечного, захищеного та надійного штучного інтелекту, важливо створити конкретні та вимірювані KPI й встановити певні захисні огородження. Слід враховувати точність, послідовність, швидкість і релевантність у конкретних випадках використання. Розробникам необхідно оцінити всю екосистему LLM та операційну модель у цільовій сфері, щоб переконатися, що вона забезпечує точні, відповідні та вичерпні результати», – каже Атена Рейхані, директор із продуктів ContractPodAi.
Одним з інструментів для навчання є Chatbot Arena – відкрите середовище для порівняння результатів LLM. Він використовує систему рейтингу Elo – алгоритм, який часто використовують для рейтингу гравців у змагальних іграх. Він досить добре працює, коли людина оцінює відповідь від різних алгоритмів або версій LLM.
«Оцінка з боку людини є центральною частиною тестування, особливо під час перевірки LLM на запити, які з’являються. Chatbot Arena є прикладом краудсорсингового тестування. Ці типи досліджень можуть забезпечити важливий цикл зворотного зв’язку для включення відгуків користувачів», – каже Джо Регенсбургер, віцепрезидент із досліджень Immuta.
Роміла з IBM Data and AI поділилася трьома показниками, які слід враховувати залежно від варіанту використання LLM:
- F1 score – це зведена оцінка точності та запам’ятовування, яка застосовується, коли LLM використовуються для класифікації чи прогнозування. Наприклад, LLM клієнтської підтримки можна оцінити за тим, наскільки добре вона рекомендує курс дій.
- RougeL можна використовувати для тестування RAG і LLM для випадків узагальнення, але для цього зазвичай потрібне резюме, створене людиною, щоб порівняти результати.
- sacreBLEU – це один із методів, який спочатку використовувався для перевірки мовних перекладів, а зараз застосовується для кількісної оцінки відповідей LLM разом з іншими методами, такими як TER, ChrF і BERTScore.
Тестування не закінчується після розгортання моделі, тож дослідники даних повинні шукати реакцію кінцевих користувачів, показники продуктивності та інші відгуки, щоб покращити моделі.
«Після розгортання інтеграція результатів з аналітикою поведінки стає надзвичайно важливою, пропонуючи швидкий зворотний зв’язок і чіткішу оцінку продуктивності моделі», – говорить Дастін Пірс, віцепрезидент із розробки та CISO компанії Amplitude.
Компанії, що займаються технологіями штучного інтелекту (Anthropic, Character.ai, Notion і Brex), створюють свій продукт із позначками функцій для спільного тестування програми, повільного впровадження можливостей у великі групи та націлювання експериментів на різні сегменти користувачів.
Незважаючи на те, що існують нові методи перевірки програм LLM, жоден із них не є простим у застосуванні та не забезпечує остаточних результатів. Наразі просто створення програми з інтеграцією RAG і LLM може бути легшою частиною порівняно з роботою, необхідною для її тестування та підтримки вдосконалень.
Читайте також на ProIT: політика OpenAI більше не забороняє використання її технології для військових справ.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!
