Экспертиза · Индивидуальные AI-модели
Работа состоит из четырёх частей: мы измеряем кандидаты-модели на ваших данных, выбираем между конфигурацией, поиском в документах и тонкой настройкой, проверяем права на использование данных, затем держим потребление в рамках бюджета по ключу. Мы пока не обучали ни одну модель в продакшене, и говорим это до того, как вы спросите.
Уже построеноЧасть измерения и эксплуатации построена и работает, с сохранёнными результатами: собственный испытательный стенд, который сравнил восемь систем распознавания речи на одних и тех же 200 румынских высказываниях, с доверительным интервалом и парными различиями, плюс разложение голосовой задержки на шесть сегментов, которые в сумме дают общий итог с отклонением менее одной миллисекунды. Часть эксплуатации — это собственный gateway с 44 настроенными моделями, ключами по проектам со списком разрешённых моделей и бюджетом, и ежедневной консолидацией потребления по пользователь × ключ × модель. Часть, которую мы НЕ сделали, — собственная тонкая настройка — написана как есть: конвейер подготовлен и оценён по стоимости, но никогда не запускался на GPU. Сервис остаётся «доставленным», потому что работа, которую мы продаём, — это информированный выбор и эксплуатация, а не обучение.
Большинству проектов «индивидуальной модели» не нужна обученная модель. Им нужна правильная модель, с правильной инструкцией, поверх правильных данных, с стоимостью за вызов, которую кто-то отслеживает. Работа начинается с вопроса, который мало кто задаёт: как выглядит успех, как он измеряется и на каком наборе случаев? Без этого ответа любое сравнение моделей — это разговор о вкусах.
Мы измеряем сами, а не берём цифры поставщиков. Когда нам нужно было понять, что лучше всего распознаёт разговорный румынский, мы запустили восемь систем на одних и тех же 200 высказываниях, с одним и тем же нормализатором, с доверительным интервалом через bootstrap и с попарно рассчитанными различиями. Результаты были неутешительными: система, которую мы использовали в production, имела 26,26% Word Error Rate, а маленькая модель с 110 миллионами параметров, запущенная на процессоре, — 6,83%. Мы опубликовали и неприятную часть — по точности на румынском мы сильно уступаем коммерческим поставщикам.
Вторая часть работы — выбор между тремя путями, которые часто путают: настройка модели (инструкция, инструменты, параметры), поиск по вашим документам и тонкая настройка. Порядок, в котором мы их пробуем, — не предпочтение, а экономика: первые два обратимы за один день, третий требует данных, прав, GPU и измерения до и после. Мы рекомендуем тонкую настройку только когда есть доказательство, что первые два не подходят.
Третья часть, которая остаётся после запуска: стоимость за вызов. Модели проходят через собственный gateway, где у каждого ключа есть белый список моделей, бюджет и период. Потребление ежедневно консолидируется по пользователю, ключу и модели, а значит вопрос «почему вырос счёт в этом месяце» имеет ответ по строкам, а не по предположениям.
Что входит
Набор случаев из вашей реальности, числовой критерий и метод нормализации, зафиксированные письменно. Для речи мы используем Word Error Rate с собственным нормализатором; для текстовых ответов — соответствие схеме плюс проверка на здравый смысл плюс сходство с эталонным ответом. Без этого шага остальная работа не может быть проверена никем.
Одни и те же высказывания, одна и та же машина, по одной модели за раз, каждая в своём процессе. Мы публикуем доверительный интервал через bootstrap и попарные различия, а не только среднее — потому что две модели могут иметь разные средние и всё же быть статистически равны. У нас был именно такой случай: две системы при 66 из 66 попарных сравнений, то есть ничья, хотя таблица средних подсказывала победителя.
В одном голосовом маршруте мы измерили шесть сегментов отдельно — решение о туре, распознавание речи, gateway, время до первого текста модели, первый блок синтеза, очередь и транспорт. Важная проверка: сумма этих шести даёт общее время до первого звука с отклонением менее одной миллисекунды на каждый валидный тур. Оттуда видно, где проблема: в измеренном случае 68,7% времени уходило на ожидание первого текста от модели, а не на распознавание речи, которое занимало 2,9%.
Поиск по документам реализован и работает: гибридный поиск, 70% семантики и 30% совпадения слов, порог сходства 0,70, пять фрагментов на вопрос, с журналом по каждому запросу, который сохраняет оценки и времена. Тонкую настройку мы предлагаем только при наличии доказательства, что первые два варианта не подходят — и с бюджетом и правами на столе заранее, а не потом.
Это не формальность, это то, что останавливает проекты. Корпус из 1.746 часов румынского языка, который мы рассматривали, оказался лицензирован только для некоммерческого использования — значит, непригоден для коммерческой модели. Набор из 270.946 примеров имел код под разрешительной лицензией, но данные — без какой-либо заявленной лицензии. А политика использования одного поставщика голоса прямо запрещает обучение модели на его выходных данных. Каждый источник проверяется на собственной странице, а не по тому, что написано в статье.
Собственный gateway с 44 настроенными моделями, каждая с ценой за token и лимитом контекста в конфигурации. Ключ проекта имеет белый список моделей, бюджет и период, и его можно ротировать, сохраняя историю. Потребление консолидируется ежедневно по пользователю × ключ × модель. Маршрутизация использует стратегию «наименее загруженный», две повторные попытки и максимальное время 120 секунд.
Модели типа рассуждения производят внутренние шаги, которые платформа отслеживания стоимости не видит, но провайдер их выставляет к оплате. Практическое следствие: брутто-бюджет, заданный на ключ, должен быть меньше желаемого потолка, деленного на фактор рассуждения. Если не сделать эту корректировку, ключ выглядит уложившимся в бюджет, а счет — нет.
У нас есть рабочая локальная цепочка: распознавание речи с моделью на 0,6 миллиарда параметров на процессоре и синтез речи с моделью на 99 миллионов параметров, тоже локально. В продукте для мониторинга радио транскрипция выполняется локально, а версия через gateway существует параллельно — значит, сравнение между локальным и размещенным сделано, а не предполагается. С машины уходит текст, а не аудио.
Еженедельный регрессионный набор на фиксированных случаях, который сравнивает соответствие схеме, проходит тест на здравый смысл и измеряет сходство с эталонными ответами. Модель, которая меняется под вами — и меняется — видна в таблице, а не в жалобах клиентов.
Как это выглядит
Случаи берутся из вашей реальности, а не из общего тестового набора. Фиксируются числовой критерий, метод нормализации и порог, с которого результат считается приемлемым. Мы передаем: набор случаев, записанный критерий и скрипт, который его вычисляет.
Модели-кандидаты запускаются на идентичных данных, с доверительным интервалом. Поставляем: таблицу со всеми протестированными системами, включая отклоненные и причину, плюс точную команду для воспроизведения. Модель, которую мы отклонили для румынского языка, имела 99,69% частоту ошибок, потому что съезжала в итальянский — румынский не входил в список ее заявленных языков. Этот результат есть в таблице.
Настройка, поиск в документах или тонкая подстройка — с причиной, стоимостью и тем, что теряется при выборе. Мы передаем: обоснованное решение, плюс измерение, которое его поддерживает. Если рекомендация — «ничего не обучаем», мы пишем это так же явно.
Ключ проекта выпускается с бюджетом, периодом и списком разрешенных моделей, с примененной корректировкой для токенов рассуждения. Мы передаем: ключ, панель потребления и порог, с которого кто-то получает alert.
Те же случаи, тот же критерий, на модели из продакшена. Поставляем: сравнение до/после и список изменений с причиной каждого. Регулярный регрессионный стенд ловит изменения поведения модели поставщика.
Данные
Вопросы, которые задаёт всякий, у кого есть ответственный за защиту данных, — заданы здесь раньше, чем их задаст он.
Случай
Ситуация
У нас была работающая система распознавания речи для румынского языка, и открытый вопрос: это лучшая доступная система или просто первая, которую мы интегрировали? Не было ни одной собственной измерительной базы, только опубликованные поставщиками цифры, измеренные на других языках и других наборах.
Что мы построили
Мы построили бэнчмарк: 200 румынских высказываний из публичного набора, одна и та же семя для отбора, 35,1 минуты аудио, один и тот же нормализатор для всех систем, доверительный интервал через bootstrap, различия, рассчитанные по парам. Восемь систем, каждая загружалась отдельно, в собственном процессе, на одной и той же машине. В отчёте мы указали и конфигурацию машины, и точную команду воспроизведения.
Что получилось
Система в продакшене имела 26,26% rate of error per word. Модель с 110 миллионами параметров, запущенная на процессоре вместе с языковой моделью рядом, имела 6,83%. Очень хвалёная модель показала 99,69%, потому что она съезжала на итальянский — румынский не был среди её заявленных языков. А две системы, которые по среднему казались разными, оказались статистически равны при попарном сравнении. Мы опубликовали всю таблицу, включая строку, которая противоречила нашему выбору.
Чего этот случай не говорит
Измерение было проведено на публичном наборе для чтения, а не на реальных телефонных разговорах с шумом и наложениями. Хороший результат на этом наборе не гарантирует тот же результат по телефону. Поэтому для клиента бэнчмарк перестраивается на его записях — иначе мы измеряем не то, что его интересует.
Вопросы
Нет. Ни одна дообученная или обученная нами модель не работает в production, и в наших репозиториях нет ни одной сохранённой контрольной точки. Что у нас есть: обучающий конвейер, написанный до точной команды запуска GPU-машины, бюджет, рассчитанный по трём сценариям, подготовленные данные и проверенные лицензии — и письменный список того, что нужно решить до первого запуска. Мы предпочитаем говорить это, чем продавать компетенцию, которую не применяли.
Потому что работа, которая даёт результат в большинстве случаев, — не обучение. Это понимание, какая модель справляется с вашими данными, с какой задержкой и по какой цене за запрос — а это требует измерения, которое почти никто не делает. Один пример из нашей работы: одно неверное значение по умолчанию в конфигурации модели (штраф за повторения, установленный на 1,2 вместо 1,0) стоило 4,3 процентных пункта ошибки. Понадобилось не обучение, а измерение.
Начинайте с поиска по документам, почти всегда. Это обратимо, обновляется заменой одного файла и может показывать источник ответа. Дообучение меняет поведение модели так, что это нельзя инспектировать, требует размеченных данных, прав на использование и измерения до и после. Мы рекомендуем дообучение, когда есть доказательство, что первый вариант не подходит — например, когда мы показали, что офлайн-модель не становится потоковой моделью только за счёт конфигурации: при сужении окна внимания без переобучения ошибка выросла с 8,81% до 22,26%, а затем до 48,95%.
Нет, и ни один честный поставщик не может этого гарантировать, потому что точность зависит от ваших данных. Мы гарантируем метод: измеряем на ваших случаях, показываем доверительный интервал и говорим, когда разница между двумя вариантами статистически незначима. У нас был случай, когда опубликованный авторами модели результат не воспроизвёлся у нас — они указывали 20,70%, мы измерили 26,68% на той же модели. Мы написали, что не знаем почему, вместо того чтобы выбрать удобную цифру.
Это зависит от выбранного пути, и это решение, а не случайность. Через gateway запрос попадает к поставщику модели. Если это неприемлемо, у нас полностью работает локальная цепочка: распознавание речи и синтез речи, запущенные на вашей машине, где с машины уходит только текст, никогда не аудио. В продукте для мониторинга радио локальная транскрипция и транскрипция через gateway реализованы обе, поэтому компромисс между ними мы можем показать цифрами.
Это происходит. Поэтому работа включает регрессионный стенд на фиксированных случаях, запускаемый периодически, который сравнивает соответствие схеме, проходит тест на здравый смысл и измеряет сходство с эталонными ответами. И поэтому интеграция проходит через gateway: модель меняется из одного поля, а не переписыванием кода.
У проектного ключа есть белый список моделей, бюджет и период, и его можно ротировать, сохраняя историю. Потребление сводится ежедневно по пользователю, ключу и модели. Одна ловушка, которую мы исправляем с самого начала: модели рассуждения создают внутренние шаги, которые система учёта не видит, но поставщик их выставляет в счёт — поэтому грубый бюджет по ключу задаётся ниже желаемого лимита, делённого на фактор рассуждения. Кто не делает эту поправку, видит ключ в бюджете и счёт сверху.
Потому что «публичные» и «разрешённые для коммерческого использования» — разные вещи, и разница обнаруживается поздно и дорого. Три примера из наших проверок: крупный корпус румынского языка, лицензированный некоммерчески, поэтому исключён для коммерческого продукта; набор из сотен тысяч примеров кода с разрешительной лицензией, но с данными без какой-либо заявленной лицензии; и политика использования одного поставщика голоса, которая прямо запрещает обучение модели на его выходе. Проверка делается на странице источника, а не по тому, что повторяет статья.
Сегодня не обучает фундаментальные модели и не обещает собственную модель в production. Не гарантирует проценты улучшения. Не сравнивает модель с конкурентами на основе опубликованных конкурентами цифр — если мы не запускали сравнение сами, мы говорим, что это заявленная ими цифра, а не измеренная нами.
26 из них — код и файлы из наших репозиториев. Мы не публикуем их название и строку: вместе, на одной странице, они слишком точно описали бы, как устроены системы, которые принадлежат не только нам. Мы разбираем их вместе с тобой, в репозитории, по запросу — проверка остаётся возможной, просто она проходит в разговоре.
Расскажите о своём процессе. Вместе определим, что стоит построить, что можно подключить и как проверим результат.