Модели растут, а галлюцинации остаются: цена больших LLM

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

Дальше — о том, что реально изменилось в новом поколении моделей, где заканчивается прогресс и как считать деньги, прежде чем встраивать модель в продукт.

Что стало лучше на самом деле

Три вещи двигаются вперёд ощутимо, и их стоит отделять от маркетинга.

• Цена за токен. Провайдеры конкурируют ценой агрессивно: у большинства крупных API есть уровни от «дешёвой быстрой» до «дорогой умной» модели, и разница между ними — десятки раз. Точные цифры смотрите в прайсах провайдеров, они меняются ежеквартально.
• Длина контекста. Окна в 100–200 тысяч токенов и больше стали нормой. Это позволяет закидывать в запрос целый документ вместо нарезки на куски.
• Инструменты и вызов функций. Модель умеет вернуть структурированный JSON и вызвать внешнюю функцию — это превращает её из чат-бота в компонент пайплайна.

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

Длинный контекст не равно память

Отдельный миф — что большое окно контекста заменяет базу знаний. На практике модели хуже находят факт, спрятанный в середине длинного документа, чем в начале или конце. Это явление называют «потерей в середине»¹. Поэтому «загрузить всю документацию в промпт» работает хуже, чем аккуратный поиск по базе и подстановка только нужных фрагментов.

Где прогресс упирается в стену

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

Модель не знает, что она не знает. Уверенность в ответе и его правильность — это две независимые величины, и вторую приходится проверять внешними средствами.

Галлюцинации

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

Стоимость на масштабе

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

Приватность и данные

Отправляя данные в облачный API, вы передаёте их третьей стороне. Условия обработки у провайдеров разные: одни не используют данные API для обучения по умолчанию, другие требуют явного отключения. Читайте data processing addendum до интеграции, а не после инцидента.

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

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

Практический чек-лист перед внедрением

1. Опишите задачу как измеримую метрику — точность, доля правильных ответов на тестовом наборе, а не «стало лучше».
2. Соберите тестовый датасет из 50–200 реальных примеров с эталонными ответами.
3. Прогоните две-три модели разного ценового уровня и сравните качество к цене.
4. Для фактических задач добавьте retrieval и требование цитировать источник.
5. Заложите слой проверки: валидацию JSON, фильтры, а для критичных решений — человека в контуре.
6. Проверьте условия обработки данных провайдера и требования вашего регулятора.

Открытые модели против облачных API

Открытые веса (self-hosted) дают контроль над данными и предсказуемую стоимость инфраструктуры, но требуют своих GPU и инженеров. Облачный API снимает эксплуатацию, но привязывает к ценам и политике провайдера. Для стартапа на старте почти всегда дешевле API; для компании с постоянной высокой нагрузкой и требованиями по данным собственный хостинг открытой модели окупается.

¹ Retrieval (RAG, retrieval-augmented generation) — подход, при котором перед ответом система ищет релевантные фрагменты в базе и подставляет их в запрос, чтобы модель опиралась на проверяемые источники, а не только на память из обучения.