ISMS Copilot Docs

Тестування та валідація моделей ШІ

ISMS Copilot проводить ретельне внутрішнє тестування перед розгортанням нових моделей ШІ або оновлень моделей. Це гарантує, що платформа підтримує точність аудиторського рівня…

Огляд

ISMS Copilot проводить ретельне внутрішнє тестування перед розгортанням нових моделей ШІ або оновлень моделей. Це гарантує, що платформа підтримує точність аудиторського рівня для рамок відповідності, таких як ISO 27001, SOC 2 та ISO 42001.

У цій статті пояснюється наш робочий процес тестування моделей та стандарти якості, які ми застосовуємо перед тим, як будь-яка модель потрапляє у продакшн.

Робочий процес тестування

Оцінюючи нову модель або варіант моделі, ми дотримуємося такого процесу:

1. Тестування в ізольованій гілці

Ми розгортаємо кандидатну модель у спеціальному середовищі гілки. Це ізолює тестування від продакшн-систем і дозволяє проводити всебічну оцінку без впливу на активних користувачів.

2. Оцінка завдань відповідності

Ми тестуємо модель на основних завданнях відповідності, які відображають реальне використання ISMS Copilot:

  • Відображення рамок – Точне відображення контролю між стандартами (наприклад, ISO 27001 ↔ ISO 42001)
  • Точність посилань на контроль – Правильне цитування контролю Додатка A порівняно з положеннями системи управління
  • Генерація політик – Створення документів, готових до аудиту, з належною структурою та термінологією
  • Аналіз прогалин – Виявлення невідповідностей у завантажених документах

Тестові запити використовують ту саму систему динамічного інжектування знань, що й у продакшні, забезпечуючи реалістичні умови оцінки.

3. Критерії прийняття рішення

Модель повинна відповідати таким вимогам, щоб перейти у продакшн:

  • Відсутність галюцинацій контролю – Жодних вигаданих або неправильно ідентифікованих елементів контролю рамок
  • Структурна точність – Правильне розрізнення між елементами контролю Додатка A та положеннями
  • Визнання помилок – Здатність розпізнавати та виправляти помилки при виклику
  • Покращення продуктивності – Вимірювані покращення (швидкість, ліміти токенів, вартість) без втрати точності

Моделі, які не проходять тести на точність, відхиляються незалежно від переваг у продуктивності. Робота, що стосується аудиту, вимагає надійності понад швидкість.

4. Конвеєр розгортання

Якщо тестування пройшло успішно:

  1. Розгортання у середовищі розробки для розширеної валідації
  2. Моніторинг реальної продуктивності та крайніх випадків
  3. Розгортання у продакшні з можливістю відкату

Якщо тестування не вдалося, ми повертаємося до попередньої моделі та документуємо результати для майбутнього використання.

Реальний приклад: Grok-4-Fast-Reasoning

Цей приклад демонструє наші стандарти тестування в дії.

Контекст тестування

Мета: Оцінити Grok-4-Fast-Reasoning як заміну Grok-4 для вирішення проблем з лімітами токенів та зменшення витрат.

Тестове завдання: Відобразити елементи контролю ISO 27001:2022 на елементи контролю ISO 42001:2023 з точними посиланнями на контроль, наданими в контексті.

Помилка

Модель видала таку помилку відображення:

  • Елемент контролю ISO 42001: A.8.5 Інформація для зацікавлених сторін
  • Grok-4-Fast-Reasoning відобразив на: A.7.4 Комунікація
  • Правильне відображення: Положення 7.4 Комунікація (не Додаток A.7.4)

У ISO 27001:2022 Додаток A.7.4 – це "Фізичний моніторинг безпеки" (спостереження/виявлення у приміщеннях). Модель сплутала нумерацію елементів контролю Додатка A з нумерацією положень системи управління – фундаментальна структурна помилка для роботи з відповідністю.

Помилка у визнанні помилки

Реакція моделі на виправлення викликала не менше занепокоєння:

  1. Попросили виявити помилку → Не визначила помилку
  2. Запитали конкретно про A.7.4 → Надала правильну інформацію, але не визнала помилку у таблиці
  3. Викликали безпосередньо → Заявила "Я не галюциную" і захищала неправильне відображення
  4. Визнала помилку лише після того, як її назвали "нечесною" з цитуванням проблемної таблиці

Рішення

Результат: ❌ Непридатна для продакшну

Обґрунтування:

  • Швидкість була вражаючою, але помилки у посиланнях на контроль є неприпустимими для вихідних даних, що стосуються аудиту
  • Погане визнання помилок може вводити в оману користувачів, які довіряють результатам
  • Може підходити для чернеток, але вимагає людської валідації кожного посилання на контроль

Вжиті заходи: Повернення до Grok-4 для розгортання у продакшні.

Що це означає для користувачів

Користуючись ISMS Copilot, ви отримуєте переваги від моделей, які пройшли ці контрольні точки якості:

  • Точність рамок – Елементи контролю та положення правильно посилаються
  • Надійність – Моделі, які галюцинують або відмовляються виправляти помилки, відхиляються
  • Готовність до аудиту – Вихідні дані протестовані на реальних завданнях відображення відповідності

Хоча ми проводимо ретельне тестування, завжди перевіряйте вихідні дані ШІ за офіційними стандартами перед поданням аудиторам. Дивіться наші рекомендації щодо відповідального використання для найкращих практик.

Пов'язані ресурси

On this page