Генеративные модели искусственного интеллекта: критерии выбора

Главная ошибка — начинать с названия модели. GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro, Llama 3.1, Mistral Large 2 — это не варианты из одного ценника. Это разные режимы владения риском. API дает скорость деплоя. On-premise дает контроль. Большое контекстное окно снимает один класс проблем и создает другой: стоимость, латентность, сложность валидации ответа. Бенчмарки полезны, но не заменяют PoC на ваших данных.

Сначала фиксируется задача, потом модель

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

Минимальный набор параметров:

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

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

3. Допустимая ошибка. Для генерации рекламного черновика ошибка стоит дешево. Для ответа клиенту банка — дороже. Для анализа медицинского документа или юридического риска — критично. Генеративная модель не дает 100% отсутствия галлюцинаций. Это свойство класса, а не баг конкретного вендора.

4. Требования к задержке. Интерактивный ассистент должен отвечать быстро. Ночной пакетный анализ договоров может работать дольше. Для простых задач классификации или извлечения сущностей крупная модель часто избыточна. Малая модель дешевле, быстрее и проще контролируется.

5. Контур данных. Можно ли отправлять данные во внешний API. Можно ли хранить промпты у провайдера. Требуется ли Private Cloud. Есть ли ограничения по GDPR, SOC 2, внутренним политикам ИБ.

Модель не выбирают «по интеллекту». Ее выбирают по границе ответственности: где данные, кто видит промпт, сколько стоит ошибка.

Эта спецификация должна появиться до закупки. Иначе компания покупает витрину, а потом пытается прикрутить к ней процесс.

Архитектурный выбор: API против открытых весов

Есть два базовых класса доступа: проприетарные модели через API и модели с открытыми весами. Между ними есть гибриды: managed private deployment, private cloud, выделенные инстансы, корпоративные версии с отдельной политикой хранения данных. Но инженерный выбор все равно упирается в контроль.

Проприетарные API — это GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro и похожие сервисы. Вендор держит инфраструктуру, обновляет модель, управляет масштабированием. Команда интеграции получает endpoint, документацию, лимиты, биллинг за токены.

Модели с открытыми весами — Llama 3.1, Mistral-семейство и другие варианты Open Weights. Их можно развернуть на собственных серверах, в частном облаке или в управляемой инфраструктуре. Появляется контроль над данными и версией модели. Появляются расходы на GPU, MLOps, мониторинг, обновления, безопасность рантайма.

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

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

Не путать open source и open weights

Для бизнеса это не терминологическая придирка. Open source обычно означает доступность исходного кода и права на модификацию по лицензии. Open weights — доступность весов модели на определенных условиях. Лицензия может ограничивать коммерческое использование, масштаб, производные работы, реселл. Перед деплоем нужна проверка лицензии, а не презентация архитектора.

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

Контекстное окно: не память, а размер рабочего буфера

Контекстное окно — один из самых неверно понятых параметров. Его читают как «модель помнит больше». Технически это размер входа и истории, которые модель может учитывать при генерации. Диапазон сегодня широкий: от 8k токенов до 2M+ токенов у моделей класса Gemini 1.5 Pro.

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

Контекстное окно влияет на архитектуру решения:

• 8k–32k токенов. Подходит для коротких диалогов, писем, небольших документов, классификации, генерации черновиков. Дешевле. Проще тестировать.

• 64k–200k токенов. Нормальный диапазон для корпоративных документов, встреч, аналитических отчетов, нескольких связанных файлов. Требует контроля стоимости и качества извлечения.

• 1M–2M+ токенов. Режим для больших массивов: кодовая база, длинные архивы переписки, наборы документов. Удобен для прототипа, но дорог в эксплуатации и сложен в валидации.

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

Большое контекстное окно не заменяет поиск. Оно только увеличивает цену ошибки, если в запрос попал мусор.

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

Бенчмарки: полезны, но не являются спецификацией качества

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

Но корпоративное внедрение ломается не на MMLU. Оно ломается на ваших PDF, кривых сканах, внутренних аббревиатурах, неполных CRM-полях, старом регламенте с правками и промптах пользователей, которые пишут как пишут.

Бенчмарк не отвечает на вопросы:

• выдержит ли модель ваш формат документов;

• будет ли она соблюдать JSON-схему при высокой нагрузке;

• сможет ли отличить действующий регламент от архивного;

• начнет ли она выдумывать отсутствующие поля;

• насколько стабилен ответ при повторном запуске;

• как модель ведет себя на русском языке в вашей терминологии;

• что происходит при prompt injection в загруженном документе.

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

Как построить проверку без самообмана

Методика короткая.

1. Сформировать набор задач. Например: извлечь реквизиты из договора, классифицировать тикет, сгенерировать ответ, найти риск в NDA, написать unit test.

2. Задать эталон. Для каждой задачи нужен ожидаемый результат. Не «ответ выглядит нормально», а конкретные поля, допустимые значения, критерии ошибки.

3. Прогнать несколько моделей. Минимум одна закрытая API-модель, одна модель с открытыми весами, одна более дешевая или малая модель. Иначе нет сравнения экономики.

4. Измерить качество и стоимость. Точность, полнота, процент нарушений формата, средняя задержка, p95 latency, входные и выходные токены.

5. Проверить безопасность. Prompt injection, утечки через логи, обработка персональных данных, поведение при запросе запрещенной информации.

6. Зафиксировать версию. Модель, параметры, системный промпт, температура, инструменты, дата теста. Без этого результат нельзя воспроизвести.

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

Экономика токенов: дешевый запрос быстро становится дорогим процессом

API-модели обычно тарифицируются за 1 миллион входных и выходных токенов. Цены отличаются в десятки раз в зависимости от класса модели. Выходные токены часто дороже входных. Большой контекст увеличивает стоимость даже тогда, когда ответ короткий.

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

Пример расчета без привязки к конкретному прайсу:

На локальном деплое токенов в счете нет. Но есть GPU-часы, амортизация, резервирование, охлаждение, DevOps/MLOps, обновления, observability, безопасность. Если нагрузка малая и нерегулярная, собственная инфраструктура может быть дороже API. Если нагрузка большая, стабильная и данные чувствительные, расчет меняется.

Отдельный пункт — маршрутизация моделей. Не все запросы надо отправлять в самую сильную модель. Нормальная схема использует несколько уровней:

• малые модели для классификации, маршрутизации, извлечения простых сущностей;

• средние модели для типовых текстовых задач;

• сильные модели для сложного reasoning, кода, анализа длинных документов;

• отдельные модели для эмбеддингов и поиска;

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

Такой стек сложнее, чем один API-вызов. Но он снижает стоимость и уменьшает blast radius при ошибке.

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

Безопасность: главный критерий не качество текста

Для ИБ генеративная модель — это новый интерфейс к данным и действиям. Она принимает неструктурированный ввод, интерпретирует команды, может вызывать инструменты, читать документы, писать в системы. Это не чатик. Это программный компонент с вероятностным поведением.

Базовые риски:

1. Утечка данных через провайдера. Нужно проверить, используются ли данные для дообучения по умолчанию, как отключается training usage, где хранятся логи, какой retention period, какие условия DPA. SOC 2 и GDPR — не декоративные аббревиатуры, а входной фильтр для корпоративного контура.

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

3. Избыточные права инструментов. Если агент может читать CRM, отправлять письма и создавать задачи, права должны быть минимальными. Модель не должна получать root-доступ к бизнес-процессу.

4. Непроверенный вывод. SQL, код, команды shell, письма клиентам, финансовые рекомендации — все это требует валидации. Генерация не равна исполнению.

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

6. Supply chain для open weights. Модель, контейнер, inference-сервер, зависимости, драйверы, CUDA-окружение — вся цепочка требует проверки. Уязвимость нулевого дня в компоненте рантайма не спрашивает, локальная у вас модель или облачная.

Архитектурно нужен LLM gateway. Не прямые вызовы из приложений к разным провайдерам, а единая точка контроля: аутентификация, лимиты, маскирование данных, логирование, маршрутизация, redaction, DLP-проверки, сбор метрик, управление промптами. Без шлюза через полгода в компании будет набор неконтролируемых интеграций.

Что фиксировать в архитектурном решении

Нормальная спецификация выбора модели содержит не рекламные преимущества, а ограничения:

Если этих строк нет, решения еще нет. Есть эксперимент.

Выбор по типу задачи

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

Генерация текста и корпоративные ассистенты

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

Для внутренних ассистентов стоит ограничивать свободу:

• отвечать только по найденным источникам;

• показывать идентификаторы документов;

• отказываться при недостатке данных;

• не смешивать политики из разных версий;

• отделять факт из базы знаний от языковой формулировки модели.

Генерация кода

HumanEval полезен как первичный индикатор, но в разработке важнее интеграция с репозиторием, стиль проекта, безопасность, тесты. Модель может написать корректный фрагмент и одновременно внести уязвимость: SQL injection, неправильную обработку секретов, небезопасную десериализацию.

Для кода нужны дополнительные проверки: SAST, dependency scanning, unit tests, review человеком. Автокоммит от агента в main без контроля — плохая архитектура.

Извлечение данных и классификация

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

Изображения и мультимодальность

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

Здесь особенно важна валидация. Модель может не заметить мелкую надпись или неверно интерпретировать деталь. Для контроля качества нужны эталонные наборы изображений, а не субъективная оценка дизайнера.

Практический алгоритм выбора

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

1. Описать бизнес-процесс. Не «внедрить ИИ», а конкретно: кто вызывает модель, какие данные передает, какой результат получает, куда он попадает дальше.

2. Классифицировать данные. Публичные, внутренние, конфиденциальные, персональные, коммерческая тайна. От этого зависит API, private cloud или on-premise.

3. Выбрать 3–5 кандидатов. Включить разные классы: сильную API-модель, более дешевую API-модель, модель с открытыми весами, малую модель для простых задач.

4. Собрать тестовый набор. Реальные документы и запросы. С шумом. С плохими случаями. С эталонными ответами.

5. Провести PoC с метриками. Качество, задержка, стоимость, стабильность формата, безопасность, доля отказов, поведение на атаках.

6. Посчитать экономику процесса. Не стоимость одного запроса. Полную стоимость маршрута: RAG, ретраи, хранение, мониторинг, инфраструктура, поддержка.

7. Проверить комплаенс. SOC 2, GDPR, DPA, регион обработки, retention, использование данных для обучения, права субпроцессоров.

8. Спроектировать LLM gateway. Централизовать доступ, логи, лимиты, маскирование, маршрутизацию, алерты.

9. Запустить ограниченный пилот. Одна команда, один процесс, понятный rollback. Без подключения модели ко всем системам сразу.

10. Зафиксировать эксплуатационные ограничения. Что модель не делает. Когда нужен человек. Какие ответы запрещено исполнять автоматически.

Это не бюрократия. Это защита от неконтролируемого расползания вероятностного компонента по инфраструктуре.

Итоговая позиция

Выбор генеративной модели — архитектурное решение, а не закупка SaaS-подписки. Сильная модель через API может быть правильной. Локальная Llama 3.1 может быть правильной. Mistral Large 2 в private cloud может быть правильной. Малая модель для классификации может быть правильной. Неправильным будет только выбор без спецификации, тестов и границ данных.

Ограничения, которые надо принять до внедрения:

• большая модель не всегда лучше малой;

• большое контекстное окно не заменяет RAG и фильтрацию;

• публичный бенчмарк не заменяет PoC на ваших данных;

• API не безопасен автоматически;

• on-premise не безопасен автоматически;

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

• стоимость считается по процессу, а не по одному запросу;

• модель без LLM gateway быстро становится теневой интеграцией;

• вывод модели нельзя исполнять без валидации там, где цена ошибки высока.

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