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

Ошибка выбора стоит дорого. Не только в деньгах за токены. Хуже — в архитектурном долге: модель встроили в процесс, вокруг нее написали интеграции, настроили роли, права, логирование, RAG, мониторинг. Через два месяца выяснилось, что задержка ответа непригодна для контакт-центра, контекстное окно не держит нужный корпус документов, а данные нельзя отправлять во внешний API по требованиям ИБ. Это не проблема модели. Это ошибка спецификации.

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

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

Рынок предлагает удобную ловушку: GPT-4o, Claude 3.5, Gemini 1.5, Llama 3, Mistral. Список быстро стареет. Архитектурные вопросы — нет.

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

1. Тип ввода. Короткие вопросы, длинные документы, таблицы, переписка, код, аудио-транскрипты, мультимодальные данные.

2. Тип ответа. Свободный текст, JSON для следующего сервиса, классификация, резюме, извлечение полей, генерация письма, поиск несоответствий.

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

4. Объем контекста. Один тикет — это одно. Пакет договоров с приложениями — другое.

5. Требования к данным. Можно ли отправлять содержимое во внешний API. Нужна ли изоляция в своем контуре.

6. Допустимая ошибка. Для черновика письма ошибка терпима. Для комплаенс-проверки договора — нет.

7. Формат интеграции. API, on-premise, VPC, гибридная схема, локальный inference.

8. Бюджет на эксплуатацию. Не «сколько стоит модель», а сколько стоит миллион запросов в месяц с учетом входных и выходных токенов.

Если этих параметров нет, выбор превращается в спор вкусов. Один участник видел хороший ответ в чате. Другой читал бенчмарк. Третий хочет open source, потому что «безопаснее». Все трое могут ошибаться.

LLM не покупают. Ее встраивают в контур данных, задержек и рисков.

Проприетарный API или open-weights: главный архитектурный разлом

Сейчас практический выбор делится на два класса.

Первый — закрытые модели через API: GPT-4o, Claude 3.5, Gemini 1.5 Pro и аналоги. Провайдер держит веса, инфраструктуру, масштабирование, обновления. Вы отправляете запросы и платите за токены.

Второй — open-weights модели: Llama 3, Mistral и другие решения, которые можно развернуть на собственной или арендованной инфраструктуре. Не надо путать open weights с полной открытостью всего пайплайна обучения. Но для бизнеса важен факт: модель можно запустить в контролируемом контуре.

Для пилота проприетарный API почти всегда быстрее. Для строго регулируемых данных open-weights часто проще защитить перед ИБ. Не потому что они магически безопасны. Потому что их можно разместить там, где уже есть контроль доступа, журналирование, сегментация сети и DLP.

Есть промежуточные варианты: закрытая модель в выделенном облачном контуре, open-weights в managed inference у провайдера, гибридная схема с маршрутизацией запросов. Например, публичные FAQ уходят во внешний API, а договоры и персональные данные обрабатываются внутри.

Отдельно надо учитывать воспроизводимость. API-модель может менять поведение после обновления. Провайдеры обычно дают версии, но не всегда это означает полную стабильность ответов. В open-weights контуре версию можно зафиксировать: модель, tokenizer, параметры inference, системный prompt, RAG-индекс. Это полезно для аудита.

Контекстное окно: не емкость памяти, а лимит рабочего ввода

Контекстное окно — один из самых неправильно понимаемых параметров. Его трактуют как «модель может прочитать много». Формально да. Практически важны три вопроса:

• сколько токенов можно передать в одном запросе;

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

• сколько стоит такой запрос по latency и деньгам.

Диапазон большой: от 8k токенов у легких конфигураций до миллионов токенов у флагманских решений. У Gemini 1.5 Pro заявлено контекстное окно до 2 миллионов токенов. Это сильный параметр для задач, где надо обработать большой корпус за один запрос: длинные документы, наборы файлов, большие стенограммы.

Но большое окно не отменяет архитектуру поиска. Засунуть в prompt весь корпоративный архив — плохой способ строить систему. Дорого. Медленно. Слабый контроль источников. Сложная отладка. В большинстве бизнес-сценариев длинный контекст нужен не вместо RAG, а вместе с ним: RAG отбирает релевантные фрагменты, большое окно позволяет передать больше доказательной базы и соседнего контекста.

Типовые режимы использования:

1. 8k–32k токенов. Короткие диалоги, классификация тикетов, генерация писем, извлечение полей из одного документа.

2. 64k–200k токенов. Анализ нескольких документов, сложные юридические и технические тексты, суммаризация длинных встреч.

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

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

Latency: метрика, которую замечает пользователь

Latency — задержка ответа модели. Для backend-компонента это не косметика, а SLA. Если модель отвечает 8 секунд, пользователь считает интерфейс сломанным. Если агент контакт-центра ждет подсказку 12 секунд, он перестает ею пользоваться. Если workflow должен принять решение до таймаута внешней системы, медленная модель ломает весь процесс.

Latency складывается из нескольких частей:

• сетевой путь до провайдера или inference-кластера;

• очередь на стороне модели;

• время обработки входного контекста;

• генерация выходных токенов;

• постобработка: валидация JSON, вызовы инструментов, запись логов;

• RAG: поиск по векторной базе, reranking, сбор контекста.

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

Нельзя сравнивать latency моделей одним числом из документации. Нужен профиль нагрузки:

Отдельный дефект — нестабильная latency. Среднее значение может быть приемлемым, а p95 и p99 провалены. Для бизнеса важны хвосты распределения. Если 5% запросов зависают на 20 секунд, пользователи запомнят именно их.

Средняя задержка нужна для презентации. p95 нужен для эксплуатации.

Экономика: считать надо не модель, а транзакцию

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

Главная ошибка — считать только один запрос. В реальном сценарии один пользовательский вопрос может породить цепочку:

1. нормализация запроса;

2. поиск в RAG;

3. reranking документов;

4. основной LLM-вызов;

5. проверка ответа;

6. повторный вызов при ошибке формата;

7. запись объяснения или аудиторского следа.

В итоге один «ответ пользователю» превращается в 2–5 LLM-вызовов и несколько обращений к поисковой инфраструктуре. Если есть агентный сценарий с инструментами, множитель выше.

Для грубой оценки нужны четыре числа:

• средний размер входа в токенах;

• средний размер выхода;

• число запросов в месяц;

• коэффициент дополнительных вызовов.

Пример без привязки к конкретному прайсу. Система обрабатывает 500 000 обращений в месяц. На одно обращение уходит 3 000 входных токенов и 700 выходных. Есть проверочный вызов в 30% случаев. RAG добавляет инфраструктурные расходы, но не обязательно LLM-токены, если reranker не LLM-based. Даже при умеренной цене за миллион токенов месячный счет быстро становится заметным. При флагманской модели и длинном контексте — еще быстрее.

У open-weights экономики другая форма. Нет платы провайдеру за каждый токен модели, но появляются:

• GPU или CPU-инфраструктура;

• хранение и доставка модели;

• inference-сервер;

• балансировка;

• мониторинг;

• обновления;

• безопасность;

• команда, которая это обслуживает.

Дешевый open-weights деплой без учета эксплуатации часто оказывается дороже API на малом объеме. На большом объеме и при стабильной нагрузке собственный inference может стать выгоднее. Но это надо считать на конкретных цифрах. Актуальные цены на облачные GPU зависят от региона и провайдера, поэтому универсальной формулы нет.

Практическое правило: для пилота используйте API и собирайте телеметрию токенов. Для промышленного контура сравнивайте API-счет с полной стоимостью владения inference-инфраструктурой. Без телеметрии это гадание.

Безопасность: где реально проходит граница риска

Вопрос «можно ли отправлять данные в LLM» слишком общий. Надо классифицировать данные и маршруты.

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

Минимальная модель угроз для LLM-внедрения должна покрывать:

• утечку чувствительных данных через внешний API;

• сохранение prompt и ответов в логах;

• prompt injection в документах и веб-страницах;

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

• несанкционированный доступ к RAG-индексу;

• подмену документов в базе знаний;

• генерацию вредных команд агентом;

• нарушение прав доступа при поиске по корпоративным данным.

RAG особенно часто делают небезопасно. Берут документы из общего хранилища, индексируют в векторную базу, подключают чат. Потом пользователь с правами стажера получает фрагменты документа финансового директора, потому что поиск не проверяет ACL на уровне чанков. Это не уязвимость модели. Это уязвимость архитектуры.

Для корпоративного RAG нужен контроль доступа до выдачи контекста модели. Не после. Если фрагмент уже попал в prompt, модель может его использовать. Маскирование ответа не решает проблему.

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

Для закрытых API надо смотреть enterprise-условия: используется ли ввод для обучения, где хранятся логи, какие регионы доступны, как устроено удаление данных, есть ли private networking. Для open-weights надо проверять другое: кто имеет доступ к inference-серверу, как патчатся контейнеры, где лежат веса, как защищена векторная база, как логируются запросы.

On-premise не равен безопасно. Внутренний сервис без аутентификации и с полными логами prompt в Elasticsearch — плохой контур. Внешний API с контрактными ограничениями, отключенным обучением на данных и нормальной сегментацией иногда безопаснее самодельного локального стенда. Решает не ярлык, а контроль.

RAG: стандарт для точности, но не лекарство от галлюцинаций

Галлюцинации не исчезают выбором «самой умной» модели. У любой LLM есть риск уверенного неверного ответа. Точные показатели зависят от домена, prompt, данных и методики теста. Обещание «без галлюцинаций» надо считать красным флагом.

Для задач, где нужна проверяемость, используется RAG — Retrieval-Augmented Generation. Модель не отвечает только из параметров. Система сначала ищет релевантные документы, передает их фрагменты в контекст, а модель строит ответ на основе найденного.

Нормальный RAG состоит не из одной векторной базы. Минимальная схема включает:

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

2. Индексацию. Векторный поиск, иногда гибридный поиск с BM25, метаданные, версии документов.

3. Фильтрацию по правам. Пользователь видит только те фрагменты, к которым имеет доступ.

4. Retrieval. Поиск кандидатов по запросу.

5. Reranking. Пересортировка кандидатов более точной моделью или алгоритмом.

6. Сбор контекста. Удаление шума, ограничение токенов, сохранение ссылок на источники внутри системы.

7. Генерацию. LLM отвечает в заданном формате.

8. Проверку. Валидация структуры, проверка цитирования, запрет ответа при недостатке источников.

9. Логирование. Запись запроса, найденных документов, версии индекса и модели для аудита.

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

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

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

Как проводить бенчмарк перед выбором

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

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

Набор тестов надо разделить по классам:

Оценивать надо не только «правильно/неправильно». Нужны метрики:

• точность извлечения полей;

• доля валидных структурированных ответов;

• доля ответов с неподтвержденными утверждениями;

• средняя latency и p95;

• входные и выходные токены;

• стоимость на одну бизнес-транзакцию;

• процент ретраев;

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

• качество отказа при нехватке данных.

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

Важно тестировать не только идеальные документы. Нужны сканы с OCR-ошибками, старые версии шаблонов, неполные тикеты, вложенные таблицы, смешанные языки, кривые имена продуктов. Продакшен не похож на демо.

Размер модели: 7B против флагмана

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

Типовая ошибка — использовать флагман везде. Это дорого и медленно. В нормальной архитектуре несколько моделей работают вместе:

• маленькая модель классифицирует запрос;

• embedding-модель ищет документы;

• reranker сортирует фрагменты;

• флагманская LLM отвечает на сложные вопросы;

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

• локальная модель обрабатывает чувствительные данные.

Такой каскад снижает стоимость и latency. Но добавляет сложность. Нужны маршрутизация, мониторинг и fallback.

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

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

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

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

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

3. Задать SLA. Latency, throughput, доступность, допустимый процент ошибок, требования к аудиту.

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

5. Выбрать 3–5 кандидатов. Например, один флагманский API, один дешевый API, одна open-weights модель, один гибридный вариант.

6. Построить одинаковый пайплайн. Один и тот же RAG, одинаковые prompts, одинаковая валидация. Иначе сравнение нечестное.

7. Измерить качество. По классам тестов, а не общим впечатлением.

8. Измерить latency. Среднее, p95, p99 под параллельной нагрузкой.

9. Посчитать стоимость транзакции. Включая дополнительные вызовы, ретраи, RAG и инфраструктуру.

10. Проверить модель угроз. Prompt injection, ACL, логи, хранение, права инструментов.

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

12. Зафиксировать версию. Модель, параметры, prompts, индексы, зависимости. Без этого нечего расследовать при сбое.

Этот алгоритм не привязан к названию модели. Поэтому переживает смену поколений: GPT-4o, Claude 3.5, Gemini 1.5, Llama 3, новые Mistral-модели и следующие релизы будут меняться. Требования к latency, данным и стоимости останутся.

Где чаще всего ломается внедрение

Первая поломка — отсутствие владельца качества. Команда запускает LLM, но никто не отвечает за эталонные наборы, регрессионные тесты и деградацию после обновления модели.

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

Третья — неограниченный prompt. В систему добавляют инструкции, потом еще инструкции, потом запреты, потом примеры. Prompt разрастается, стоимость растет, latency растет, поведение остается нестабильным. Часть логики надо выносить в код, правила, валидаторы и RAG.

Четвертая — отсутствие наблюдаемости. Нельзя эксплуатировать LLM без логов версии модели, параметров, размера prompt, найденных документов, latency, ошибок формата и стоимости. Иначе каждый инцидент превращается в разговор «вчера работало».

Пятая — вера в одну модель для всего. Для бизнеса почти всегда нужен стек. LLM — один компонент. Рядом находятся поиск, права доступа, очереди, API-шлюз, DLP, мониторинг, хранилище документов, валидаторы.

Ограничения перед финальным решением

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

• Нет универсально лучшей модели. Есть модель, которая подходит под ваш корпус данных, latency, бюджет и требования ИБ.

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

• Open-weights не означает безопасность по умолчанию. Без контроля доступа, логов и патчей локальный деплой остается уязвимостью.

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

• Стоимость токенов — только часть TCO. Ретраи, дополнительные вызовы, RAG, GPU, DevOps и мониторинг входят в расчет.

• Latency надо измерять на p95 и p99. Среднее значение не показывает пользовательскую боль.

• Галлюцинации нельзя обнулить. Их можно снижать RAG, отказом при нехватке данных, валидацией и аудитом.

• Бенчмарк нужен на собственных данных. Публичные рейтинги не знают ваших договоров, тикетов и регламентов.

Финальная позиция жесткая: сначала спецификация, потом модель. Если бизнес не описал данные, задержку, стоимость транзакции, требования безопасности и критерии качества, он не выбирает LLM. Он покупает неопределенность.

Правильный выбор выглядит скучно: таблица сценариев, тестовый корпус, замеры latency, расчет токенов, модель угроз, пилот, регрессионные тесты. Зато после этого большая языковая модель становится управляемым компонентом SaaS-стека, а не дорогой демонстрацией с непредсказуемым поведением.