Аудит AI-системи: де якість відповідей ламається
Найдорожча деградація якості відповідей — та, якої не видно на середніх показниках. Два близькі формулювання одного запитання отримують різні відповіді, і система впевнено видає обидві.
Причина майже завжди комплексна: оновився індекс пошуку, змінився шаблон запиту до моделі, додалося правило фільтрації — і поведінка розійшлася з тим, що було зафіксовано під час запуску.
Рідкісні сценарії дають збій першими й залишаються непоміченими найдовше. Поки аудит AI-системи спирається на усереднену точність по потоку, провали на довгому контексті, змішаних мовах і неоднозначних запитаннях розчиняються в загальній цифрі.
Перевірка AI-рішення має йти за розміткою сценаріїв: окремо рідкісні, окремо частотні, окремо ті, де відповідь не повинна з'являтися взагалі.
Час відповіді та частка відмов зростають повільно, тому їх пропускають. Зростає обсяг індексу, подовжується контекст, додаються повторні звернення до моделі — і запит починає впиратися в граничний час очікування.
Частину таких випадків система закриває ввічливим «не вдалося отримати відповідь», і відмова моделі перестає відрізнятися від відмови інтеграції або блокування правилом безпеки.
Вузькі місця обробки запитів зазвичай розподілені по трьох шарах: підготовка контексту, звернення до моделі, постобробка та перевірки.
Аудит фіксує поведінку системи до змін, знімає еталонний набір запитів з очікуваними відповідями і показує, на якому шарі втрачається якість — у даних, у шаблоні чи в правилах. Далі розбираємо, як це закривається процесом.
Вимірюваний ефект: якість відповідей, швидкість, стійкість
Аудит AI-системи починаємо з базової лінії: еталонний набір реальних запитів із розміченими відповідями, профіль навантаження і список відомих збоїв.
Прогони та розмітку ведемо в LangSmith — історія замірів залишається в замовника, і кожна правка перевіряється проти неї, а не «на око».
Якість відповідей у відсотках
Кілька сотень реальних запитань розмічаємо за класами: правильна відповідь, неповна, вигадка, коректна відмова. Частка коректних рахується по всій вибірці, тому після кожної правки видно її внесок.
Час відповіді під навантаженням
Дивимося 95-й перцентиль, а не середнє: хвіст розподілу і є те, що помічає користувач. Профіль повторює піковий сценарій, тому видно, де виникає черга і що реально знімає затримку — кеш, повторне використання контексту чи менше звернень до моделі.
Стійкість до відмов
Перевіряємо недоступність зовнішньої моделі, обриви з'єднання і неповні дані: чи залишається осмислена відповідь або система йде в порожній екран. Результат аудиту — не окремі правки, а закритий клас відмов.
Навантаження на інфраструктуру
Рахуємо число звернень до моделі на одну відповідь користувача і зростання споживання при подвоєнні трафіку. Так видно, де зайві виклики, а де ресурс справді потрібен.
Передбачуваність після оновлень
Перед кожним релізом — регресійний прогін за еталонним набором: якщо частка коректних відповідей падає нижче зафіксованого порогу, оновлення не виходить. Відкат до попередніх версій промптів і моделей залишається доступним.
Формати аудиту: експрес-перевірка, повний розбір, контроль
Формати аудиту різняться не обсягом звіту, а глибиною вибірки й тим, які ризики вони взагалі здатні зловити.
Прототип і система під трафіком потребують різного: на ранній стадії важливіше перевірити стійкість логіки на малому наборі сценаріїв, в експлуатації — побачити деградацію на реальних даних. Нижче — три режими та їхні обмеження.
Експрес-перевірка займає кілька днів і покриває ключові шляхи: набір контрольних запитів, межі відповідей, поведінку на неповних або суперечливих даних.
Повний розбір додає навантажувальні прогони, розмітку вибірки і перевірку на змагальні входи — його висновків достатньо для рішення про виведення в експлуатацію.
Регулярний моніторинг якості — не разова робота, а контур: метрики знімаються з потоку, відхилення потрапляють у звіт, спірні відповіді йдуть на ручну перевірку.
| Формат | Коли підходить | Обмеження |
|---|---|---|
| Експрес-перевірка | Прототип перед пілотом, зміна моделі або підказок, оцінка чужого рішення | Мала вибірка: рідкісні відмови й системні викривлення на ній не видно |
| Повний розбір | Перед виведенням в експлуатацію, після великої переробки, у регульованому контурі | Потрібні доступи до даних і тестового контуру, зріз актуальний на дату перевірки |
| Регулярний моніторинг якості | Система в експлуатації, потік запитів змінюється, помилка обходиться дорого | Потребує розмітки та власника метрик; знаходить деградацію, але не замінює разовий розбір |
Формати не конкурують: експрес-перевірка доречна на прототипі, повний розбір — перед промисловим запуском, регулярний моніторинг — після. Кожен наступний етап спирається на результати попереднього, а не починається з нуля.
Як будується робота: від постановки задачі до передачі звіту
Аудит починається не з прогонів, а з узгодження критеріїв: яка частка помилок допустима на критичних сценаріях, які відповіді неприйнятні за політикою безпеки, що вважаємо деградацією якості.
Без зафіксованих чисел звіт перетворюється на суперечку про смаки — тому перший етап завжди про домовленості.
- Критерії та межі перевірки. Фіксуємо сценарії, поріг допустимих помилок і класи неприпустимих відповідей. На виході — матриця приймання, за якою приймається результат.
- Збір метрик на поточному стані. Знімаємо затримку відповіді, частку відмов та їхні типи, вартість обробки одного запиту. Це базова лінія, з якою порівнюємо все подальше.
- Схема перевірки. Описуємо, які компоненти ізолюємо, де підміняємо зовнішні джерела, як відтворюємо однакові умови між прогонами.
- Тестовий набір запитів. Збираємо корпус із реальних звернень і межових випадків: порожній ввід, довгий контекст, конфліктні вказівки, спроба обійти заборони.
- Виправлення. Правимо системні інструкції, розмітку документів, пороги відсікання і правила фільтрації. Кожна правка йде з прогоном — ефект видно, а не припускається.
- Контрольний прогін. Той самий набір на новій версії, порівняння з базовою лінією за метриками й класами відмов; розходження розбираємо, поки картина не зійдеться.
- Передача регламентів. Віддаємо схему перевірки, набір тестових запитів, конфігурацію і журнал рішень — за ними систему приймуть і наступного разу, вже без нас.
Кожен етап закінчується артефактом, який можна перевірити: матриця приймання, звіт за метриками, схема, набір запитів. Тому в підсумковому звіті видно не «стало краще», а наскільки і на яких сценаріях.
Пакет документів: карта ризиків, політики доступу, регламенти
Після аудиту в команди замовника залишається не звіт на полицю, а робочий комплект документів: за ним систему можна передати іншому інженеру, пройти зовнішню перевірку і повторити заміри через кілька місяців. Файли живуть у репозиторії поруч із кодом і оновлюються разом із релізом, а не окремим листом.
- Карта ризиків — за кожним сценарієм: як відмова проявляється, який сигнал ловимо першим, хто відповідає і що робить. Пріоритети розставлені за ймовірністю та ціною наслідків, а не за абеткою.
- Опис схеми рішення — які моделі та сервіси задіяні, звідки надходять дані, де проходять межі відповідальності між компонентами і хто власник кожної ділянки.
- Політики доступу та ролі — хто бачить запити й відповіді, хто читає журнали, хто змінює конфігурацію, хто затверджує правки в інструкціях моделі. Права видаються за мінімально необхідним рівнем.
- Набір перевірних запитів — еталонні звернення з очікуваною поведінкою: коректна відповідь, відмова при нестачі даних, відсутність витоку службових інструкцій. Набір покриває основні гілки діалогу і поповнюється після кожного інциденту.
- Регламент перевірки якості — періодичність прогону, порогові значення за точністю та відмовами, хто дивиться результат і в який строк реагує на просідання.
- Регламент реагування — порядок відкату до попередньої конфігурації, фіксація причини, оновлення карти ризиків і перевірного набору за підсумками розбору.
- План розвитку — які сценарії додаємо наступними, за якими метриками зрозуміємо, що пора розширювати контур, і що для цього потрібно від суміжних систем.
Комплект розрахований на те, що далі команда веде систему сама: документи описують не нашу присутність, а їхні процеси.
Кейс: якість відповідей зросла з 61% до 94% за два місяці
Точка відліку
Замовник прийшов із працюючим асистентом по внутрішній базі знань: 39% відповідей не проходили приймання — вигадані посилання, застарілі формулювання, відмова там, де дані були. Спірні випадки йшли на першу лінію, співробітники перевіряли кожну відповідь вручну.
Розбір почали з опорної вибірки: 480 реальних діалогів, розмічених за трьома класами — правильно, частково правильно, вигадка. Без неї будь-яка правка перетворюється на суперечку про смаки, тому першим артефактом став набір еталонних пар «питання — очікувана відповідь».
Що змінили
Вузьке місце знайшлося на пошуку: фрагменти різалися за фіксованою довжиною і розривали таблиці з регламентами, тому модель добудовувала контекст сама.
Перейшли на поділ за структурою документа і переранжування знайденого — частка випадків, коли потрібний фрагмент не потрапив у контекст, упала з 27% до 4%.
Другий контур — контроль: відповідь перевіряється на опору в джерелі та повноту, сумнівні випадки йдуть на рев'ю. Оцінку якості поставили на регулярний прогін у Ragas — метрики рахуються на тій самій вибірці, тому регресія видна одразу після зміни, а не після скарги.
Результат
За два місяці якість відповідей зросла з 61% до 94%, частка відмов скоротилася з 11% до 1,8%. Частка звернень, які асистент закривав сам, піднялася з 48% до 79% — навантаження на першу лінію впало майже вдвічі.
Протокол перевірки та еталонні пари передали разом із рішенням: замовник проганяє їх сам і бачить розходження без нас. Такий контур переживає зміну моделі — метрика залишається точкою опори.
Що робити, якщо рішення вже в експлуатації і його не можна змінювати
Працююча система — це зафіксована поведінка, інтеграції та накопичені дані. Тому аудит починається не з «перепишемо цілком», а з інвентаризації контуру: де вхід, де передобробка, де модель, де постобробка та правила, і який блок дає основний внесок у помилки.
Заміри знімаємо на живому потоці та на еталонній вибірці, яку фіксуємо до початку робіт: без цього порівнювати «до» і «після» нема з чим. Вибірка збирається з рідкісних і спірних випадків, а не лише з типових — інакше метрики зростають, а якість в експлуатації стоїть на місці.
Далі контур розчленовується на блоки, кожен з яких версіонується і замінюється частинами. Нова версія моделі, інший набір ознак, змінена логіка правил перевіряються на копії трафіку, поки попередній шлях обслуговує користувачів. Для кожного блока фіксуємо контракт: поля на вході, гарантії на виході, критерій деградації.
Викатка йде порціями: спочатку тіньовий режим, де запит іде в обидві версії, а розходження розбираються вручну; потім — наростаюча частка трафіку під перемикачем поведінки.
Сервіс не зупиняється, а повернення до попередньої версії спрацьовує автоматично за часткою відмов, затримкою відповіді та зростанням ручних правок оператора.
Паралельно закриваємо те, що заважає змінювати систему безпечно: доступи до моделей і даних, журналювання запитів і версій, відтворюваність прогону на історичних даних.
Підсумок — план з оборотних кроків з вимірюваним результатом: якість на еталонній вибірці, частка автоматичних відповідей, число звернень до оператора.
Часті технічні сумніви: приватність, розмітка, обсяг даних
Сумніви при вході в аудит зазвичай інженерні, а не організаційні: еталонної розмітки немає, дані не можна виносити за контур, а поточна команда зайнята продуктом. Жоден із них не блокує роботу — під кожен є схема перевірки, яка не вимагає зупиняти розробку.
Як оцінювати якість, якщо еталонної розмітки не існує?
Збираємо її на старті: стратифікована підвибірка 300–500 прикладів, подвійна сліпа розмітка і розрахунок частки згоди перевіряльників. При згоді вище 0.8 набір стає опорним, і на ньому рахуються точність, повнота й калібрування відповідей.
Далі розходження розбираються за класами помилок — видно, де модель помиляється системно, а де шум розмітки.
Як перевіряти приватність даних без вивантаження назовні?
Аудит іде у вашому контурі: наші інженери працюють під окремими ролями з правом лише читання, усі звернення до даних фіксуються в журналі доступу, а назовні йдуть агрегати й метрики без вихідних записів.
Якщо вивантаження принципово потрібне, знеособлення виконується на вашій стороні за заздалегідь узгодженими правилами.
Чи може аудит сам призвести до витоку даних через запити?
Перевірки на відновлення навчальних прикладів і на витік через запити виконуємо на синтетичних та знеособлених наборах — вони відтворюють структуру даних, але не їхній вміст. Логи тестових запитів залишаються у вашому сховищі й не покидають периметр. Окремо дивимося, чи не віддає модель фрагменти вхідних документів у відповідях.
Чи вистачить обсягу вибірки і чи не завадимо ми поточній команді?
Обсяг рахуємо від цільової похибки метрики та числа рідкісних класів, а не «що більше, то краще»: для оцінки якості та стабільності зазвичай достатньо підвибірки, що покриває всі сценарії.
Перевірки запускаються в узгоджені вікна навантаження, доступ до даних — лише на читання, релізний цикл команди не зсувається.
Обговоримо задачу: розберемо контур і повернемося з планом робіт
Щоб оцінка строків спиралася на факти, а не на припущення, починаємо з діагностики AI-рішення за тим, що вже є в проєкті. Спеціально готувати нічого не потрібно: достатньо репозиторію з кодом, конфігурацій і опису того, як система працює зараз.
Щоб обговорити задачу предметно, нам корисно побачити:
- опис сценарію: які запити надходять і яка відповідь вважається коректною;
- як влаштований контур — де виклики моделі, де правила, де зовнішні сервіси та сховище;
- журнали запитів і відповідей за період, де поведінка здається нестабільною;
- метрики якості, якщо їх уже рахують: частка правильних відповідей, частка відмов, час відповіді;
- правила доступу та обмеження щодо даних — що не можна виносити за периметр;
- поточні перевірки: автотести, ручні прогони, розбір звернень користувачів;
- обмеження за строками та те, що змінюється в системі найчастіше.
Після розбору ми повертаємося з планом робіт: етапи, порядок перевірок, що закриваємо на кожному кроці і де потрібні рішення з вашого боку. Оцінка строків у ньому прив'язана до обсягу контуру і до критичності шляхів, а не до середніх чисел по ринку.
Опишіть задачу у двох абзацах — повернемося з оцінкою та планом.
