Чотириетапний black-box протокол аудиту, описаний у новому дослідженні на arXiv, дозволяє встановити, яка саме модель відповідає за анонімним API-ендпоінтом — без доступу до ваг, логів чи внутрішньої інфраструктури провайдера. Ідея проста: клієнт бачить лише вхід і вихід API, а всередині може бути будь-що — заявлена флагманська модель або її дешевший замінник, підсунутий без попередження.

Проблема не абстрактна. Провайдери AI-послуг заробляють на різниці між вартістю обчислень і ціною для клієнта, а найдешевший спосіб підвищити маржу — тихо підмінити дорогу модель дешевшою, зберігши стару назву в документації. Для клієнта, який платить за конкретну модель через API, це виглядає ідентично до легітимного сервісу, доки він не порівняє якість відповідей із власним досвідом — а цього часто не робить ніхто.

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

Навіщо взагалі перевіряти, яка модель ховається за API?

Ринок інференсу побудований на довірі до заявленого бренду моделі: клієнт платить за GPT, Claude чи Gemini, очікуючи саме ту якість, продуктивність і поведінку, які асоціюються з цією назвою. Але контракт між провайдером і клієнтом рідко передбачає незалежну перевірку — компанія просто повідомляє назву моделі в документації API, і на цьому довіра закінчується.

Як працює чотириетапний протокол?

За задумом дослідників, аудит проводиться повністю ззовні, у режимі black-box: аудитор надсилає до API послідовність запитів і аналізує лише відповіді, без жодного привілейованого доступу до сервера провайдера. Чотири етапи розділяють задачу на кроки — від збору поведінкових даних моделі до статистичного порівняння з еталонним профілем заявленої моделі.

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

Кому це потрібно на практиці?

Найбільше від такого протоколу виграють компанії, які будують продукт на чужому API і платять за конкретну модель, а не за «якийсь інференс». Якщо провайдер обіцяє топову модель, а по факту роутить частину трафіку на дешевший варіант, це прямо впливає на якість продукту клієнта — і на гроші, які клієнт переплачує за неотриману якість.

Схожа логіка незалежної перевірки без сліпої довіри до звіту вже застосовується і в оцінці впевненості самих відповідей LLM — наприклад, графовий метод BiG-SURE ловить непевні відповіді моделі так само зовнішнім аналізом виходу, без доступу до внутрішньої архітектури.

Висновок AiiN: що робити з цим зараз?

Наша теза: доки ринок LLM-інференсу лишається непрозорим щодо реального роутингу запитів, будь-який продукт, критичний до якості відповідей, повинен закладати періодичну незалежну перевірку постачальника — так само, як компанії перевіряють SLA на аптайм. Для AI-білдерів це означає: не покладатися лише на назву моделі в договорі, а тримати невеликий набір еталонних промптів і фіксувати відповіді провайдера в часі, щоб помітити раптову зміну поведінки моделі. Подібні протоколи аудиту, ймовірно, з часом стануть частиною стандартного due diligence при виборі API-постачальника, а не нішевою дослідницькою темою.

Що таке black-box аудит моделі?

Black-box аудит — це перевірка системи виключно через її зовнішній інтерфейс, без доступу до внутрішнього коду, ваг чи інфраструктури. У випадку AI-моделей це означає, що аудитор працює так само, як звичайний клієнт API: надсилає запити й аналізує відповіді, не бачачи, яка модель фактично обробляє запит.

Чи можна обійти такий протокол підміни моделі?

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

Чи стосується це open-source моделей?

Менше — якщо ваги моделі публічно доступні, її можна верифікувати напряму порівнянням контрольних сум чи локальним запуском, і потреба в black-box аудиті через API відпадає.