Каталог моделей внутри компании: статусы и правила

Почему команды выбирают модель вслепую

Обычно причина простая: команда берет то, что уже под рукой. У кого-то остался старый пример кода с одной моделью, кто-то видел ее в демо, кто-то копирует настройку из соседнего сервиса. Когда сроки сжаты, мало кто сравнивает цену, задержку, ограничения по данным и качество на своей задаче.

Проблема всплывает не сразу. Один разработчик подключает дорогую модель для простой классификации обращений. Другой отправляет чувствительные данные туда, где это запрещают внутренние правила. Третий строит фичу на экспериментальной версии, а после очередного обновления получает другой стиль ответов и другой уровень ошибок.

Если общих правил нет, каждая команда собирает свой набор интеграций. Названия похожи, версии путаются, причины выбора никто не записывает. Через пару месяцев уже трудно ответить на базовые вопросы: какую модель можно давать в продакшен, кто за нее отвечает, что делать при падении качества и чем ее заменить.

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

Обычный список доступных моделей тут не помогает. Он отвечает только на вопрос "что у нас вообще есть". Для работы нужны другие ответы: для чего модель подходит, какие данные в нее можно отправлять, разрешена ли она для продакшена и кто принимает решение об исключениях.

Это особенно заметно, когда через один шлюз доступны десятки и сотни моделей. Например, если компания работает через AI Router, технически подключить новую модель легко. Но без статусов, правил доступа и понятного жизненного цикла команды все равно будут выбирать по памяти, привычке или чужому совету.

Проблема не в количестве моделей. Проблема в отсутствии общего правила: эту модель берем для такого сценария, эту тестируем, а эту не трогаем.

Что должно быть в карточке модели

Если у модели нет нормальной карточки, люди начинают выбирать по слухам: "эта вроде умнее", "та дешевле", "эту уже кто-то пробовал". Для внутреннего каталога этого достаточно, чтобы получить лишние траты, спорные решения по данным и путаницу в продакшене.

Хорошая карточка отвечает на рабочие вопросы за минуту. Человек открывает запись и сразу понимает, для чего модель подходит, кому писать, сколько это стоит и какие данные в нее можно отправлять.

В карточке стоит держать пять обязательных блоков.

Во-первых, понятное имя и одно назначение. Лучше написать "Qwen 3 для черновиков ответов поддержки", чем оставить только технический идентификатор. Если назначений несколько, сотрудники начнут трактовать карточку по-своему.

Во-вторых, владелец и живой контакт. Лучше указывать команду или роль, а не одного человека. Формат вроде "Платформа ML, канал #llm-help" переживет отпуск, увольнение и смену проекта.

В-третьих, явные рамки применения. Разрешенные сценарии нужно перечислить прямо: суммаризация звонков, классификация обращений, генерация черновиков писем. Запреты тоже лучше писать без намеков: не использовать для финального юридического текста, не отправлять персональные данные, не применять для решений без проверки человеком.

В-четвертых, простые цифры. Не всем нужен подробный прайс в токенах. Часто хватает трех строк: средняя стоимость типового запроса, обычная задержка и лимит по контексту или количеству запросов.

В-пятых, правила по данным и хранению. Здесь нельзя отделаться общими словами. Нужно прямо указать, можно ли передавать персональные данные, где хранятся логи, есть ли маскирование полей и подходит ли модель для данных, которые должны оставаться внутри Казахстана.

Полезно добавить короткий пример. Например: "Подходит для классификации обращений клиентов. Не подходит для медицинских рекомендаций. Средняя задержка 1,8 секунды. Ввод с ИИН запрещен без маскирования". Такой формат снимает половину вопросов еще до пилота.

Если компания работает через единый шлюз, часть полей можно подтягивать автоматически. В случае AI Router это могут быть аудит-логи, rate limits на уровне ключа, правила по маскированию PII и сценарии, где данные должны оставаться внутри страны. Но сама карточка нужна не для отчета. Она нужна, чтобы люди выбирали модель без догадок.

Какие статусы нужны

Статусы нужны не ради бюрократии. Они показывают, где и при каких условиях модель можно использовать.

Одна и та же модель может хорошо писать текст, но плохо извлекать поля из договора или срываться там, где нужен строгий JSON. Поэтому статус должен отвечать не на вопрос "модель хорошая или плохая", а на вопрос "можно ли брать ее для этой работы".

Для большинства компаний хватает пяти статусов:

• Черновик - модель только подключили и проверяют базовое поведение, лимиты и стоимость.
• Пилот - модель дали одной команде или одному сценарию на ограниченный срок.
• Разрешена для продакшена - модель можно использовать в боевых процессах в четко заданных рамках.
• Под наблюдением - по качеству, задержке или стабильности появились жалобы, новые подключения лучше остановить.
• На выводе - для модели уже выбрали дату отключения и замену.

У каждого статуса должны быть простые правила перехода. Кто переводит модель дальше, какие тесты он смотрит, сколько длится пилот, сколько жалоб достаточно для статуса "под наблюдением" и кто утверждает вывод из эксплуатации. Если этого нет, статусы быстро становятся формальностью.

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

Когда компания использует единый шлюз к разным провайдерам, такие статусы особенно полезны. Подключить новую модель технически просто. Намного сложнее потом собрать последствия, если каждая команда выбрала ее по-своему.

Как разделить доступ к моделям

Если все сотрудники видят один и тот же список моделей и могут пользоваться им без ограничений, каталог быстро теряет смысл. Одна команда берет дорогую модель для простой задачи, другая случайно отправляет чувствительные данные в неподходящий сервис. Ограничения доступа нужны, чтобы люди выбирали из своего безопасного набора, а не из полного списка.

Полный обзор обычно нужен платформенной команде, архитекторам, ИБ и тем, кто отвечает за закупку и риски. Остальным хватает витрины из одобренных моделей для их класса задач: чат, классификация, поиск, суммаризация, код.

На практике ролей немного. Платформенная команда видит весь каталог, меняет статусы и лимиты. Продуктовые команды и ML-инженеры видят разрешенные модели и могут запускать пилоты в своих проектах. ИБ и владелец данных согласуют работу с персональными, финансовыми и медицинскими данными. Владелец сервиса или CTO открывает доступ в продакшен после проверки цены, качества и риска.

Пилот без отдельного согласования можно разрешать только в понятных границах. Данные должны быть тестовыми, обезличенными или заранее замаскированными. У модели должен быть статус, который разрешает пилот, а у команды - лимит по бюджету и скорости запросов.

С продакшеном правила лучше делать жестче. Доступ открывает не тот, кто нашел удачную модель в сравнении, а тот, кто отвечает за сервис и последствия ошибок. Чаще всего это два согласования: владелец сервиса подтверждает бизнес-риск, ИБ подтверждает режим данных. Если запросы содержат чувствительные данные, лучше добавить решение владельца данных или комплаенса.

Исключения тоже нужны, но только с датой окончания. Иначе временное решение живет годами, и никто уже не помнит, зачем его открывали. В заявке на исключение обычно достаточно указать, какая модель нужна, для какой задачи, какие данные пойдут в запрос, кто отвечает за эксперимент, когда доступ закроется и как команда откатится назад, если что-то пойдет не так.

Если доступ к моделям идет через единый API-шлюз, такие правила проще закрепить технически. В AI Router для этого можно использовать разные ключи, rate limits, аудит-логи, маскирование PII и отдельные политики для локально размещенных моделей, когда данные должны оставаться внутри страны.

Как вести модель по жизненному циклу

Жизненный цикл нужен, чтобы новая модель проходила один и тот же путь, а не попадала в каталог после пары удачных запросов. Если путь не задан, команды спорят уже после запуска.

Обычно заявку на новую модель подает владелец сценария: продуктовая команда, ML-инженер или техлид. Он должен зафиксировать не только название модели, но и саму задачу, примеры запросов, допустимую цену, требования к задержке и ограничения по данным. Для банка, телекома или медсервиса этого уже хватает, чтобы быстро отсечь половину вариантов.

Сам путь можно сделать коротким: на рассмотрении, проверка, пилот, продакшен, архив. Это не то же самое, что рабочий статус из каталога. Этапы жизненного цикла показывают, где находится заявка и что команда уже успела проверить.

На этапе проверки платформа, безопасность и владелец сценария смотрят на конкретные вещи: куда уходят данные, есть ли маскирование PII, можно ли вести аудит, как модель держит нужный язык, формат и длину ответа, сколько стоит типовой запрос. Для компаний в Казахстане сюда часто добавляют требования по хранению данных внутри страны и соблюдение локальных правил по AI.

В пилот модель стоит переводить только после короткого теста на реальных примерах. Часто хватает 30-50 запросов по одному сценарию, чтобы увидеть повторяющиеся сбои: модель ломает формат, отвечает слишком долго, не держит инструкцию или выходит за бюджет. Пилот лучше ограничить одной командой и одним доступом. Иначе сырой вариант быстро расползется по всей компании.

В продакшен модель попадает, когда она прошла тесты, уложилась в цену и хотя бы несколько недель ведет себя стабильно. У нее должен быть владелец - человек или команда, которые следят за качеством, обновлениями провайдера и жалобами пользователей. Если владельца нет, статус продакшена давать рано.

Откат тоже должен быть нормальной частью процесса. Если после обновления модель стала отвечать хуже, выросла стоимость, сломался нужный формат или провайдер стал нестабилен, ее можно вернуть из продакшена в пилот или сразу перевести под наблюдение. Это не провал, а обычная рабочая мера.

Из каталога модель лучше убирать, когда у нее нет владельца, по ней нет спроса, провайдер прекратил поддержку или в компании уже есть более удачная замена. Самая частая ошибка - оставлять такие записи "на всякий случай". Через несколько месяцев никто уже не понимает, можно ли их использовать.

Как запустить каталог по шагам

Каталог не нужно строить месяцами. Первый рабочий вариант можно собрать за несколько дней, если начать не со списка модных моделей, а с реальных задач команд.

Сначала соберите 5-10 сценариев, где модель уже нужна или появится в ближайший месяц. Например, поддержка отвечает на обращения, юристы проверяют шаблоны договоров, аналитики делают выжимки из длинных отчетов. Когда задачи названы прямо, каталог перестает быть абстрактной таблицей.

После этого задайте 3-4 критерия выбора. Обычно хватает таких вопросов: модель хорошо пишет по-русски или по-казахски, держит нужный объем текста, укладывается в допустимую цену и отвечает достаточно быстро для сценария. Если критериев слишком много, команды снова начнут выбирать на глаз.

Дальше нужен короткий цикл:

• взять по одной задаче от каждой команды,
• сравнить для нее 2-3 модели,
• прогнать одинаковые примеры,
• назначить владельца и дату пересмотра.

Сравнение тоже не стоит усложнять. Для первого прохода хватит трех полей: насколько ответ полезен, сколько стоит типовой запрос и сколько секунд ждет пользователь. Если одна модель отвечает всего на 5% лучше, но стоит в четыре раза дороже, в широкий доступ ее лучше не пускать.

Небольшой пример хорошо показывает логику. Допустим, службе поддержки нужен LLM для ответов на частые вопросы. Команда берет три модели, прогоняет двадцать реальных диалогов и сравнивает цену, ошибки и среднюю задержку. Одна модель отвечает лучше всех, но иногда выходит за лимит по времени. В каталоге ей можно дать статус "разрешена для офлайн-задач", а для чата оставить другой вариант.

Если у компании уже есть единый шлюз вроде AI Router, запуск идет быстрее: модель можно менять без переписывания кода, а сравнение цены и задержки собирать в одном месте. Но даже без этого принцип остается тем же: одна задача, короткий тест, понятный статус.

Пример для одной рабочей задачи

Представьте саппорт банка. Команда хочет быстрее отвечать на частые вопросы: где посмотреть лимит по карте, почему перевод еще не дошел, как сменить номер телефона в приложении. Если правила не задать заранее, операторы начнут брать первую попавшуюся модель. Для клиентского сервиса это плохой путь.

Для такой задачи лучше сразу разделить роли моделей. Дешевая модель готовит черновик ответа по базе знаний, FAQ и внутренним инструкциям. Она помогает сэкономить время, но не пишет клиенту напрямую.

Для внешнего ответа банк оставляет только модели со статусом вроде "одобрена для внешних ответов". Такие модели уже проверили на тон, точность формулировок и соблюдение банковских ограничений. Если модель пишет быстро, но часто додумывает детали, ей не стоит давать этот статус, даже если она заметно дешевле.

Доступ тоже лучше развести по уровням. Черновая модель работает только со статьями базы знаний и обезличенными примерами. Модель для клиентского ответа получает только нужные поля из CRM. Модели без отдельного допуска не видят ФИО, номера документов и историю операций. Для чувствительных данных банк может оставить только локально размещенные модели или включить маскирование PII.

Сам процесс выглядит просто. Оператор получает вопрос клиента. Первая модель предлагает черновик: короткий ответ и список шагов. Вторая модель из одобренного набора переписывает текст в нужном тоне, или оператор отправляет ответ после проверки. Так команда не платит дорогой модели за каждый промежуточный шаг.

Через месяц правила пересматривают по фактам, а не по впечатлениям. Смотрят на стоимость одного диалога, долю ручных правок, число ошибок и жалоб, среднее время ответа. Если дешевая модель экономит деньги, но оператор переписывает половину текста, ее статус снижают. Если одобренная модель держит качество и остается в рамках политики, ей дают больше сценариев.

В этот момент каталог перестает быть списком названий. Он начинает подсказывать, какую модель брать для черновика, какую - для клиента, а какую - вообще нельзя использовать для банковских данных.

Частые ошибки

Каталог быстро теряет смысл, если его делают как витрину, а не как рабочий справочник. Даже при одном шлюзе путаница никуда не исчезает: у команды перед глазами десятки моделей, и люди выбирают ту, которую уже где-то видели.

Самая частая проблема - лишняя сложность. Если у модели семь или восемь статусов, сотрудники перестают их различать. В жизни обычно хватает понятных состояний: черновик, пилот, разрешена, под наблюдением и на выводе.

Не меньше вреда приносит общий доступ для всех. Модель для внутреннего поиска по базе знаний и модель для обработки клиентских данных нельзя открывать одинаково. У поддержки, аналитиков и ML-команды разные задачи и разный риск. Если это не учесть, одна команда начнет решать чувствительные задачи неподходящей моделью, а другая увязнет в лишних согласованиях.

Чаще всего каталог ломают одни и те же промахи:

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

Особенно опасно, когда в карточке нет раздела "не использовать для". Если прямого запрета нет, сотрудники сами додумывают границы. В итоге одна и та же модель попадает и в генерацию черновиков, и в задачи с персональными данными, хотя для второго сценария она не подходит.

Проверить качество каталога легко. Откройте любую карточку и задайте пять вопросов: кто владелец, кому можно доступ, когда следующий пересмотр, для каких задач модель разрешена и когда ее уберут из каталога. Если хотя бы на два вопроса карточка не отвечает, каталог уже ведет команды наугад.

Короткий список проверок

Перед публикацией модели в каталог достаточно быстро пройтись по пяти пунктам:

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

Хороший признак - когда новый сотрудник без помощи коллег понимает, почему одна модель открыта всем, а другая доступна только для пилота. Плохой признак - когда ответы лежат в чатах, а карточка пустая или устарела.

Для компаний с жесткими требованиями по данным этот список особенно полезен. Если платформа уже показывает ограничения по типам данных, аудит-логи и лимиты на уровне ключа, эти поля лучше вынести в карточку модели, а не прятать в настройках.

Если хотя бы один пункт не заполнен, модель лучше не публиковать как доступную по умолчанию. Исправлять последствия почти всегда дольше, чем один раз аккуратно заполнить карточку.

Что делать дальше

Не пытайтесь собрать каталог за один заход. Для старта хватит 10-15 моделей, которые команды уже используют или запрашивают чаще всего. Этого достаточно, чтобы проверить правила на живых задачах и не утонуть в таблицах и ручной работе.

Сразу зафиксируйте один формат карточки и один набор статусов. Если у одной команды статус называется "можно в прод", а у другой "проверено", каталог быстро расползется.

Хороший первый шаг выглядит так: выбрать небольшой набор моделей для 2-3 частых сценариев, назначить владельца каталога и владельцев по направлениям, собрать доступ, аудит и лимиты в одном контуре, а через 30 дней провести короткую ревизию. Уже через месяц обычно видно, какие карточки никто не открывает, какие статусы путают и где команды все равно обходят каталог.

Если доступ к моделям живет в одном месте, управлять им проще. Администратор сразу видит, кто вызывает модель, сколько токенов тратит команда, где выходят за лимит и какие запросы требуют аудита.

Когда источников много, единый шлюз действительно помогает. Например, AI Router на airouter.kz дает доступ к разным моделям через один OpenAI-совместимый эндпоинт, а еще позволяет держать аудит-логи, rate limits на уровне ключа, маскирование PII и сценарии с хранением данных внутри Казахстана. Для каталога это удобно не само по себе, а потому что правила можно закрепить не только в документе, но и в самой инфраструктуре.

Даже этого уже достаточно, чтобы каталог стал рабочим инструментом, а не еще одной таблицей со списком моделей.