Карточка модели для внутреннего каталога: нужные поля

Почему без карточки модели команда путается

Когда у модели нет нормальной карточки, каждая команда смотрит на нее по-своему. Финансы видят цену за токены и считают, что этого достаточно. Разработчик берет модель с лучшим качеством ответов, а потом выясняется, что для чата она слишком медленная: пользователь ждет 2-3 секунды, а не 12.

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

Карточка модели нужна как общая точка опоры. Она снимает лишние вопросы до запуска, а не после первой жалобы от бизнеса или службы безопасности.

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

Обычно ошибки повторяются по одному сценарию:

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

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

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

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

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

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

Сразу стоит показать:

• название модели и провайдера в одной строке
• версию модели или дату проверки конфигурации
• владельца карточки
• короткое описание задач
• дату последней проверки

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

С версией та же история. Даже небольшое обновление может поменять ответы, формат JSON и задержку. Если у модели нет явного version id, ставьте дату, когда команда проверила конкретную конфигурацию.

Владелец карточки тоже должен быть конкретным. Лучше указать роль или человека, а не абстрактный отдел. Формулировка вроде "ML platform" или "Иван Петров, search team" сразу показывает, кто обновит запись после смены тарифа или лимитов.

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

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

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

Как описать язык и ограничения

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

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

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

Лимит контекста тоже лучше переводить на человеческий язык. Число в токенах оставьте, но рядом дайте ориентир: "32k токенов, примерно 20-25 страниц русского текста" или "хватает на 40 коротких сообщений в чате". Иначе люди видят красивую цифру и загружают в модель договор, стенограмму звонка и таблицу в одном запросе, а потом удивляются, почему ответ стал хуже.

Ограничения удобно делить на три группы: данные, темы и типы задач.

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

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

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

Как показать цену и задержку

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

Цену лучше держать в одной строке. Сразу пишите стоимость входных и выходных токенов в одном формате, чтобы не приходилось сверять несколько мест в карточке. Например: "Input - 0,8 руб. за 1 млн токенов, Output - 3,2 руб. за 1 млн токенов". Если кэш считается отдельно, добавьте это там же, а не в примечании мелким шрифтом.

С задержкой работает тот же принцип. Среднее значение полезно, но его мало. Команда должна видеть и p95, потому что именно он показывает, сколько пользователь ждет в плохие, но вполне обычные моменты. Если написать только "в среднем 1,8 с", легко пропустить, что p95 уходит, например, в 6,4 с.

Хорошая короткая запись выглядит так:

• Цена: Input - 0,8 руб./1 млн, Output - 3,2 руб./1 млн
• Задержка: средняя - 1,8 с, p95 - 6,4 с
• Лимиты: 120 RPM, 200000 TPM
• Кэш и повторы: cache hit тарифицируется по отдельной ставке, повтор после таймаута оплачивается только при успешном ответе
• Дата замера: 12.04.2026

Лимиты по RPM и TPM держите рядом с ценой и задержкой. Дешевая модель с узким лимитом нередко проигрывает более дорогой, если у вас много одновременных запросов. Для поддержки это видно сразу: на бумаге цена низкая, а в реальной нагрузке растет очередь и оператор ждет дольше, чем планировалось.

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

И еще одна простая вещь: без даты все эти цифры быстро теряют смысл. Тарифы и лимиты меняются часто. Карточка без даты замера выглядит заполненной, но для выбора модели почти бесполезна.

Как зафиксировать правила логирования и допуск

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

Сначала укажите, что именно попадает в лог. Формулировки "логирование включено" недостаточно. Нужен точный состав: текст запроса, system prompt, ответ модели, имя продукта, user ID, тип данных, токены, ошибки, вложения, IP-адрес или только технические метки без содержимого. Если какие-то поля не пишутся, это тоже надо указать прямо.

Отдельной строкой зафиксируйте маскирование персональных данных. Напишите, какие данные вы скрываете до записи: ФИО, телефон, почту, номер договора, паспортные реквизиты. Укажите и способ замены: полное удаление, частичная маска или хеш.

После этого добавьте еще четыре простых поля:

• где лежат логи
• сколько дней они хранятся
• у кого есть доступ
• что происходит после истечения срока хранения

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

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

Финальное одобрение тоже должно иметь владельца. Обычно это владелец продукта вместе с ИБ или DPO. В карточке нужна одна конкретная роль, которая ставит последний статус допуска. Иначе решение зависает между командами, а модель уходит в прод без явного разрешения.

Как заполнить карточку с нуля

Не пытайтесь сразу сделать идеальную карточку. Сначала соберите сухие факты, чтобы запись помогала выбирать модель без длинных созвонов и переписок.

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

Рабочая последовательность обычно такая:

1. Возьмите данные из трех источников: API, договоров с провайдерами и своих замеров на тестовом трафике.
2. Заполните обязательные поля фактами, без оценок вроде "быстрая" или "дешевая".
3. Проверьте цену и задержку на своих запросах, а не только по паспорту модели.
4. Назначьте владельца карточки и дату пересмотра.

На первом проходе хватит обязательного минимума: название модели, версия, язык, лимиты, цена за входные и выходные токены, средняя задержка, правила логирования, статус допуска и владелец карточки. Лучше писать числа и четкие статусы: p50 и p95 по задержке, лимит контекста, стоимость на 1 млн токенов, разрешено ли передавать персональные данные.

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

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

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

Где команды чаще ошибаются

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

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

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

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

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

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

С правилами логирования часто тоже все смешивают в одну строку. Пишут "логирование разрешено", хотя для dev, stage и prod правила почти всегда разные. В тестовой среде команда может хранить больше технических данных, а в проде обязана маскировать PII, сокращать срок хранения и вести аудит отдельно.

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

Хорошее правило тут простое: любой новый version id, новый маршрут или новый режим логирования должен сбрасывать статус допуска до повторной проверки. Иначе карточка быстро превращается в архив, а не в рабочий инструмент.

Пример карточки для чат-бота поддержки

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

Подойдет такой шаблон:

Название: Support FAQ RU
Сценарий: ответы на частые вопросы и простые формы
Язык: русский
Формат ответа: короткий, 2-4 предложения, без длинных объяснений
Ограничения: не решает спорные кейсы, не дает юридические и финансовые советы, переводит сложные обращения на оператора
Цена: приоритет низкой стоимости на 1000-10000 однотипных запросов в день
Средняя задержка: 1.8 с
Пики задержки: допустимы, если не ломают SLA первой линии
Логирование: хранить только тексты после маскирования PII
Статус допуска: разрешено для FAQ и простых форм, запрещено для претензий, KYC и платежных сценариев
Лимиты: 25 запросов в минуту на один сервис
Дата пересмотра: через 2 недели после пилота
Ответственный: команда поддержки + владелец каталога

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

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

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

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

Быстрая проверка перед публикацией

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

Проверка за 2 минуты

• У карточки есть владелец. Должно быть понятно, кто обновляет цену, кто решает вопрос по допуску и кто отвечает за инциденты.
• Цена и задержка привязаны к дате измерения. Цифры без даты почти бесполезны.
• Ограничения написаны простыми словами. Не "есть нюансы с инструментами", а "плохо держит длинный диалог" или "не подходит для персональных данных".
• Правила логирования согласованы с безопасностью. Должно быть ясно, что именно попадает в логи, как долго это хранится, маскируются ли персональные данные и кто имеет доступ.
• Статус допуска понятен без звонка автору. Формулировка вроде "можно в прод" слишком расплывчата. Лучше писать прямо: "только тест", "прод без ПДн", "прод с ПДн", "запрещено для внешних данных".

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

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

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

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

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

На практике хватает трех правил:

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

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

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

Если каталог моделей проходит через RU LLM, часть фактов проще держать в одном месте: маршрут до модели, тарифы провайдера, логи запросов, маскирование PII и хранение данных в РФ. Это не заменяет внутренние замеры, но заметно снижает количество ручных ошибок и расхождений между каталогом и продом.

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