Експертиза · Індивідуальні моделі AI
Робота має чотири частини: ми вимірюємо кандидатні моделі на ваших даних, обираємо між конфігурацією, пошуком у документах і тонким налаштуванням, перевіряємо права на використання даних, а потім ставимо споживання під бюджет на ключ. Ми ще не тренували жодної моделі в продакшені, і говоримо це до того, як ви запитаєте.
Вже збудованоЧастина вимірювання й експлуатації побудована й працює, збережені результати: власний стенд, який порівняв вісім систем розпізнавання мовлення на тих самих 200 румунських висловлюваннях, з довірчим інтервалом і попарними різницями, плюс розкладка голосової латентності на шість сегментів, що підсумовуються до загального часу з відхиленням менше за мілісекунду. Частина експлуатації — це власний gateway із 44 налаштованими моделями, ключами на проєкт зі списком дозволених моделей і бюджетом, та щоденна консолідація споживання за користувач × ключ × модель. Та частина, якої ми НЕ робили, — власне тонке налаштування — так і написана: пайплайн підготовлено й пораховано, але він ніколи не запускався на GPU. Сервіс лишається «доставленим», бо робота, яку ми продаємо, — це інформований вибір і експлуатація, а не навчання.
Більшості проєктів «індивідуальної моделі» не потрібна навчена модель. Їм потрібна правильна модель, з правильною інструкцією, поверх правильних даних, із вартістю за виклик, яку хтось відстежує. Робота починається з питання, яке мало хто ставить: як виглядає успіх, як саме виміряний, на якому наборі випадків? Без цієї відповіді будь-яке порівняння моделей — це розмова про смаки.
Ми міряємо самі, а не беремо цифри постачальників. Коли нам потрібно було знати, що найкраще розпізнає румунську мову в усному мовленні, ми запустили вісім систем на тих самих 200 висловлюваннях, з тим самим нормалізатором, з довірчим інтервалом через bootstrap і з парними різницями. Результати були незручні: система, яку ми використовували в продакшені, мала 26,26% частки помилки на слово, а маленька модель із 110 мільйонів параметрів, запущена на процесорі, мала 6,83%. Ми оприлюднили і неприємну частину — за точністю в румунській мові ми значно програємо комерційним постачальникам.
Друга частина роботи — вибір між трьома шляхами, які часто плутають: налаштування моделі (інструкція, інструменти, параметри), пошук у ваших документах і fine-tuning. Порядок, у якому ми їх пробуємо, — не вподобання, а економія: перші два можна повернути назад за післяобід, третій потребує даних, прав, GPU і вимірювання до та після. Ми рекомендуємо fine-tuning лише тоді, коли маємо доказ, що перших двох недостатньо.
Третя частина, яка лишається після запуску: вартість за виклик. Моделі проходять через власний gateway, де кожен ключ має білий список моделей, бюджет і період. Споживання консолідується щодня за користувачем, ключем і моделлю, а це означає, що запитання «чому цього місяця виріс рахунок» має відповідь по рядках, а не за припущеннями.
Що входить
Набір випадків із вашої реальності, числовий критерій і метод нормалізації, зафіксовані письмово. Для мовлення ми використовуємо частку помилки на слово з власним нормалізатором; для текстових відповідей — відповідність схемі плюс перевірку здорового глузду плюс схожість із еталонною відповіддю. Без цього кроку решту роботи ніхто не зможе перевірити.
Ті самі висловлювання, та сама машина, по одному завантаженому моделю за раз, кожен у власному процесі. Ми звітуємо про довірчий інтервал через bootstrap і парні різниці, а не лише про середнє — бо дві моделі можуть мати різні середні й усе одно бути статистично рівними. У нас був саме такий випадок: дві системи з 66 із 66 парних порівнянь, тобто рівність, хоча таблиця середніх підказувала переможця.
У голосовому маршруті ми виміряли шість сегментів окремо — рішення щодо черги мовлення, розпізнавання мовлення, гейт, час до першого тексту моделі, перший блок синтезу, чергу й транспорт. Перевірка, яка має значення: сума шести дає загальний час до першого звуку з відхиленням менш ніж одна мілісекунда на кожній валідній репліці. Звідти видно, де проблема: у виміряному випадку 68,7% часу становило очікування першого тексту від моделі, а не розпізнавання мовлення, яке займало 2,9%.
Пошук у документах реалізовано і він працює: гібридний пошук, 70% семантики і 30% збігу слів, поріг схожості 0,70, п’ять фрагментів на запит, з журналом на кожен запит, що зберігає оцінки та часи. Fine-tuning ми пропонуємо лише з доказом, що перших двох недостатньо — і з бюджетом та правами на столі до цього, а не після.
Це не формальність, це те, що зупиняє проєкти. Корпус із 1.746 годин румунської мови, який ми брали до уваги, виявився ліцензованим для некомерційного використання — отже, непридатним для комерційної моделі. Набір із 270.946 прикладів мав код під дозвільною ліцензією, але дані — без жодної задекларованої ліцензії. А політика використання одного голосового постачальника прямо забороняє навчання моделі на її виході. Кожне джерело перевіряємо на його власній сторінці, а не за тим, що написано в статті.
Власний gateway із 44 налаштованими моделями, кожна з вартістю за токен і лімітом контексту в конфігурації. Ключ проєкту має білий список моделей, бюджет і період, і його можна ротувати зі збереженням історії. Споживання щодня консолідується за користувач × ключ × модель. Маршрутизація використовує стратегію «найменш зайнятий», дві повторні спроби та максимальний час 120 секунд.
Моделі типу міркування генерують внутрішні кроки, які платформа відстеження вартості не бачить, але постачальник їх тарифікує. Практичний наслідок: брутто-бюджет, встановлений на ключ, має бути меншим за бажану межу, поділену на фактор міркування. Якщо не зробити цю корекцію, ключ виглядає в межах бюджету, а рахунок — ні.
У нас функціональний локальний ланцюг: розпізнавання мовлення з моделлю на 0,6 мільярда параметрів на процесорі та синтез голосу з моделлю на 99 мільйонів параметрів, теж локально. У продукті для моніторингу радіо транскрипція виконується локально, а варіант через gateway існує паралельно — отже, порівняння між локальним і розміщеним зроблене, а не припущене. З машини виходить текст, а не аудіо.
Щотижневий регресійний набір на фіксованих випадках, який порівнює відповідність схемі, проходить тест на здоровий глузд і вимірює схожість із еталонними відповідями. Модель, яка змінюється під вами — і змінюється — видно в таблиці, а не в скаргах клієнтів.
Як це виглядає
Випадки беруться з вашої реальності, а не з загального тестового набору. Фіксуються числовий критерій, метод нормалізації та поріг, від якого результат є прийнятним. Постачаємо: набір випадків, письмовий критерій і скрипт, який його обчислює.
Кандидатні моделі запускаються на однакових даних, з довірчим інтервалом. Постачаємо: таблицю з усіма протестованими системами, включно з відхиленими та причиною, плюс точну команду для відтворення. Модель, яку ми відхилили для румунської, мала 99,69% рівень помилки, бо зсувалася в італійську — румунська не була серед її задекларованих мов. Той результат є в таблиці.
Налаштування, пошук у документах або тонке доопрацювання — з причиною, вартістю та тим, що втрачається при виборі. Постачаємо: обґрунтоване рішення, плюс вимір, що його підтримує. Якщо рекомендація — «нічого не навчаємо», ми так само прямо це й пишемо.
Ключ проєкту видається з бюджетом, періодом і списком дозволених моделей, із застосованою корекцією для token-ів міркування. Постачаємо: ключ, панель споживання та поріг, від якого хтось отримує сповіщення.
Ті самі випадки, той самий критерій, за моделлю з продакшну. Постачаємо: порівняння до/після і список змін із причиною кожної. Рекурентний регресійний банк ловить зміни в поведінці моделі постачальника.
Дані
Запитання, які ставить кожен, у кого є відповідальний за захист даних, — поставлені тут раніше, ніж їх поставить він.
Випадок
Ситуація
У нас працювала система розпізнавання мовлення для румунської, і було відкрите питання: це найкраща доступна чи лише перша, яку ми інтегрували? Не було жодного власного вимірювання, лише опубліковані постачальниками цифри, виміряні на інших мовах і інших наборах.
Що ми збудували
Ми побудували банк: 200 румунських висловів із публічного набору, та сама зернина для відбору, 35,1 хвилини аудіо, той самий нормалізатор для всіх систем, довірчий інтервал через bootstrap, відмінності, обчислені попарно. Вісім систем, кожна завантажена окремо, у власному процесі, на одній машині. Ми записали в звіті і конфігурацію машини, і точну команду відтворення.
Що вийшло
Система з продакшну мала 26,26% частки помилки на слово. Модель на 110 мільйонів параметрів, запущена на процесорі разом із мовною моделлю, мала 6,83%. Дуже високо оцінена модель показала 99,69%, бо з’їжджала в італійську — румунська не входила до списку заявлених мов. А дві системи, які за середнім значенням здавалися різними, статистично зрівнялися в попарному порівнянні. Ми опублікували всю таблицю, включно з рядком, що суперечив нашому вибору.
Чого цей випадок не каже
Вимірювання було зроблено на публічному наборі для читання, а не на реальних телефонних розмовах із шумом і накладаннями. Хороший результат на цьому наборі не гарантує такого самого результату по телефону. Тому для клієнта банк відтворюється на його записах — інакше ми вимірюємо не те, що його цікавить.
Питання
Ні. Жодна модель, налаштована тонко або навчена нами, не працює в продакшені, і в наших репозиторіях немає жодного збереженого контрольного пункту. Що в нас є: конвеєр навчання, прописаний аж до точної команди запуску машини з GPU, бюджет, обчислений за трьома сценаріями, підготовлені дані та перевірені ліцензії — і письмовий список того, що треба вирішити перед першим запуском. Ми воліємо сказати це, ніж продавати компетенцію, яку не застосовували.
Бо робота, яка дає результат у більшості випадків, — не навчання. Це знати, яка модель виконує задачу на ваших даних, із якою затримкою та за якою ціною за виклик — і це потребує вимірювання, яке майже ніхто не робить. Один приклад із нашої роботи: одне хибне значення за замовчуванням у конфігурації моделі (штраф за повторення, встановлений на 1,2 замість 1,0) коштувало 4,3 відсоткових пункти помилки. Не знадобилося навчання, а лише вимірювання.
Починайте з пошуку в документах, майже завжди. Це зворотно, оновлюється зміною одного файла й може показувати джерело відповіді. Тонке налаштування змінює поведінку моделі так, що це не можна оглянути, потребує розмічених даних, прав на використання та вимірювання до і після. Ми рекомендуємо тонке налаштування, коли маємо доказ, що перший варіант не підходить — наприклад, коли ми показали, що офлайн-модель не стає потоковою моделлю лише через конфігурацію: звуження вікна уваги без перенавчання підвищило помилку з 8,81% до 22,26%, а потім до 48,95%.
Ні, і жоден чесний постачальник не може, бо точність залежить від ваших даних. Ми гарантуємо метод: вимірюємо на ваших кейсах, показуємо інтервал довіри й кажемо, коли різниця між двома варіантами статистично незначуща. У нас був випадок, коли опублікований авторами моделі результат не відтворився в нас — вони звітували про 20,70%, ми виміряли 26,68% на тій самій моделі. Ми написали, що не знаємо чому, замість того щоб обрати зручну цифру.
Це залежить від обраного шляху, і це рішення, а не випадковість. Через gateway запит потрапляє до постачальника моделі. Якщо це неприйнятно, у нас функціонально працює локальний ланцюжок: розпізнавання мовлення та синтез голосу виконуються на вашій машині, звідки з машини виходить лише текст, ніколи не аудіо. В продукті для радіомоніторингу локальна транскрипція й транскрипція через gateway реалізовані обидві, тож компроміс між ними ми можемо показати цифрами.
Таке буває. Тому робота включає регресійний банк на фіксованих кейсах, що запускається періодично й порівнює відповідність схемі, проходить тест здорового глузду та вимірює подібність до еталонних відповідей. І тому інтеграція йде через gateway: модель змінюється з одного поля, а не через переписування коду.
Ключ проєкту має білий список моделей, бюджет і період, і його можна ротацією змінювати, зберігаючи історію. Споживання зводиться щодня по користувачу, ключу й моделі. Одна пастка, яку ми виправляємо одразу: моделі міркування генерують внутрішні кроки, яких система відстеження не бачить, але постачальник їх виставляє в рахунок — отже, грубий бюджет на ключі встановлюють нижчим за бажаний ліміт, поділений на фактор міркування. Хто не робить корекцію, бачить ключ у бюджеті й рахунок понад.
Бо «публічні» і «придатні для комерційного використання» — різні речі, а різницю виявляють пізно й дорого. Три приклади з наших перевірок: великий корпус румунської мови, ліцензований некомерційно, отже виключений для комерційного продукту; набір із сотень тисяч прикладів коду з дозволеною ліцензією, але даними без жодної заявленої ліцензії; і політика використання одного постачальника голосу, яка прямо забороняє навчання моделі на його виході. Перевірка робиться на сторінці джерела, а не на тому, що повторює стаття.
Не навчає сьогодні фундаментальні моделі й не обіцяє власну модель у продакшені. Не гарантує відсотки покращення. Не порівнює модель із конкурентом на основі цифр, опублікованих конкурентом — якщо ми самі не запускали порівняння, ми кажемо, що це цифра, заявлена ними, а не виміряна нами.
26 з них — це код і файли з наших репозиторіїв. Ми не публікуємо їхні назви чи номери рядків: разом, на одній сторінці, це надто точно описало б, як побудовані системи, які належать не лише нам. Ми проходимо їх разом із вами, у репозиторії, за запитом — перевірка залишається можливою, просто вона відбувається в розмові.
Розкажіть про свій процес. Разом визначимо, що варто збудувати, що можна підключити і як перевіримо результат.