Все материалы
AIгайдстарт

LLM: что это — токены, контекст и температура на примерах

LLM — большая языковая модель, которая строит ответ из токенов. Объясняем контекст, температуру и границы расчётов на реальном примере аналитика.

КейсПрактика25 сентября 2026 г.17 мин
Содержание статьи

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

LLM — что это простыми словами

LLM, или большая языковая модель, — система, которая обрабатывает текст небольшими единицами, токенами, и генерирует ответ по последовательности этих единиц. Она умеет переписывать, объяснять, классифицировать и создавать код. Это не таблица с готовыми ответами: даже если результат похож на справку, модель может ошибиться в факте или расчёте.

В работе аналитика LLM полезна как помощник для черновика SQL, Python, документации метрики и резюме. Надёжный результат получается, когда она создаёт проверяемое действие: запрос к базе, код или ссылку на документ. Если модель сразу пишет «выручка равна…» по длинному CSV, перед вами текстовый прогноз, а не обязательно посчитанная сумма.

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

Что отвечает за какую часть работы
СлойЧто делаетКак проверять
LLMПредлагает текст, код и планЧитать и сопоставлять с задачей
ТокенизаторПреобразует текст в последовательность единицСчитать для конкретной модели
База или PythonВыполняет арифметику по даннымСверять контрольные итоги
ИсточникПодтверждает факт или определениеОткрывать документ и дату

Как получается ответ: от запроса к следующему токену

Представьте, что вы начали фразу «Выручка за день составила…». Языковая модель выбирает следующий фрагмент с учётом уже увиденного текста и своей подготовки, затем повторяет выбор много раз. Она может воспроизвести структуру аналитического отчёта, потому что видела множество похожих конструкций. Это объясняет и силу, и ограничение: гладкость фразы не свидетельствует о выполненной сумме.

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

Для пользователя важнее вопрос о пути исполнения: получила ли модель исходный файл, переписала ли его в сообщение, запускала ли программу, видите ли вы код? Одинаковый интерфейс чата может скрывать разные механизмы. В одном случае сумма — догадка по тексту; в другом её посчитал интерпретатор.

Что такое токены в нейросети

Токен — элемент последовательности, с которой работает модель. Он может соответствовать целому частому слову, части слова, знаку, пробелу вместе со словом или фрагменту числа. Деление зависит от конкретного токенизатора. Поэтому правило «один токен равен одному слову» ненадёжно, особенно для русского текста, чисел, кода и таблиц.

Токены нужны не только разработчику API. Ими измеряют размер контекста, длину ответа и часто использование сервиса. Но для практической оценки не стоит умножать число слов на средний коэффициент и выдавать его как точный результат. Возьмите тот токенизатор, который соответствует выбранной модели или её семейству, и измерьте свой реальный фрагмент.

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

Русская и английская фраза: реальный подсчёт tiktoken

Мы запустили библиотеку tiktoken версии 0.12.0 с кодировкой o200k_base. Фраза «Выручка рейсов за август» заняла 7 токенов, а «Flight revenue in August» — 4. Это две разные фразы с близким смыслом, поэтому сравнение показывает пример влияния языка и токенизатора, а не точный коэффициент цены перевода.

Та же кодировка разбила CSV из эксперимента с 548 рейсами, 22 707 символами, на 12 927 токенов. Это число относится к файлу как к тексту; фактический запрос сервиса может включать дополнительную разметку и инструменты, а при загрузке файла сервис может обрабатывать его иначе. Для оценки предельного контекста и стоимости API считайте полный запрос выбранным способом, а не только видимый кусок текста.

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

pythonВоспроизводимый подсчёт токенов, tiktoken 0.12.0
import tiktoken
from pathlib import Path
enc = tiktoken.get_encoding('o200k_base')
for text in ['Выручка рейсов за август', 'Flight revenue in August']:
    print(text, len(enc.encode(text)))
csv = Path('day.csv').read_text()
print(len(csv), len(enc.encode(csv)))
# Результат: 7; 4; 22707 символов и 12927 токенов

Почему русский текст иногда занимает больше токенов

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

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

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

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

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

Длинное окно не значит, что модель одинаково надёжно использует каждый фрагмент. Важное определение метрики может потеряться среди десятков страниц, а старое сообщение — вытесниться интерфейсом или обработчиком запроса. Уточните, что именно отправляется в модель, особенно когда чат «помнит» предыдущие разговоры. Память продукта и контекст текущего вызова — разные вещи.

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

Пример из эксперимента: 548 строк не стали суммой

В нашем исследовании CSV за 5 августа 2026 года содержал 548 строк и около 23 тысяч символов. Эталонная выручка — 438 406 200 ₽, медиана выручки рейса — 209 750 ₽. Когда четыре модели OpenAI получили таблицу текстом и отвечали без выполнения кода, ни одна ни в одном из двенадцати ответов не назвала точную сумму. Ответы лежали между 106 млн и 2,04 млрд ₽.

Не стоит объяснять эти ошибки только недостатком контекстного окна. Таблица помещалась в запрос эксперимента. Проблема в другом: чтобы посчитать сумму, нужно точно пройти по всем 548 строкам, правильно прочитать значения и сложить их. Языковая генерация не обещает такой процедуры. В отдельном режиме, где модель писала SQL, а база выполняла запрос, общая доля верных решений оказалась 91%. При выполнении Python по загруженному файлу — 99 верных ответов из 108.

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

Что происходит, когда данных слишком много

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

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

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

Температура нейросети: что меняет настройка

Температура влияет на случайность выбора следующего токена при генерации. В документации OpenAI для API более высокие значения описаны как дающие более случайный ответ, более низкие — как более сфокусированный и предсказуемый. Для SQL, где нужен устойчивый черновик и меньше вариантов формулировок, низкая температура может быть разумной настройкой — если выбранная модель вообще поддерживает её.

Не превращайте это в обещание «поставьте ноль, и ошибок не будет». Даже повторяемый ответ может использовать неверный JOIN или несуществующий столбец. Параметр влияет на выбор текста, а не проверяет бизнес-смысл. А у ряда reasoning-моделей пользовательский параметр температуры не принимается при некоторых режимах: документация OpenAI прямо перечисляет неподдерживаемые сочетания.

Работая через чат, вы часто вообще не видите эту настройку. Не имитируйте её промптом «температура 0»: это обычный текст, а не установка параметра API. Лучше сделайте проверяемой саму задачу — источник, формат и тест результата.

Почему LLM — не калькулятор

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

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

База данных тоже не «знает бизнес» без правил. Она точно выполнит неверно составленный запрос. Поэтому итоговое доверие требует двух уровней: вычисление должно быть выполнено, а логика расчёта должна соответствовать определению метрики.

Почему LLM — не база знаний

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

Если нужен ответ «что написано в договоре» или «как у нас определяют активного пользователя», подключите проверенный источник. Поиск по документам, или RAG, может доставить релевантный фрагмент в контекст. Но ссылку всё равно надо открыть: найденный фрагмент может относиться к старой версии или другой команде.

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

Инструменты меняют не модель, а путь проверки

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

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

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

LLM для аналитика: рабочий маршрут

Возьмите вопрос менеджера: «Как изменилась выручка по аэропортам?» Сначала уточните метрику: валовая или чистая выручка, по дате вылета или оплаты, какие статусы входят. Затем найдите таблицы и их зерно. Попросите модель предложить SQL с перечисленными предположениями, выполните его в базе и сохраните результат.

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

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

Четыре типичные ошибки при работе с LLM

Первая — приравнивать слова к токенам. Из-за этого рассчитывают контекст неверно и теряют часть источника. Меряйте токенизатором конкретный запрос.

Вторая — считать большое контекстное окно гарантией точного анализа. Файл помещается, но модель выдаёт правдоподобную сумму без выполнения арифметики. Для чисел нужен код.

Третья — снижать температуру как «исправление» SQL. Ответ может стать стабильнее, но неверный JOIN останется. Нужны схема, кардинальность и контрольный итог.

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

Чек-лист перед ответом по данным

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

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

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

Чем токены в тексте отличаются от строк в таблице

В CSV строка — запись о рейсе, а токен — фрагмент текстового представления файла. Между ними нет постоянного отношения. Одна строка с короткими кодами аэропортов может занимать меньше токенов, чем строка с длинными названиями и комментариями. Поэтому число рейсов не переводится в размер контекста умножением на один коэффициент.

В нашем файле 548 строк данных и 12 927 токенов при o200k_base. Деление даёт среднее по конкретному тексту, но оно не будет честным прогнозом для другой выгрузки. В JSON повторяются имена ключей, в Markdown добавляется разметка, а в табличном изображении действует другой путь обработки. Если лимит важен, измеряйте именно ту форму, которая уйдёт в модель.

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

Что писать, когда контекст ограничен

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

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

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

Что температура не меняет в работе с данными

Температуру иногда воспринимают как ручку «точность». На самом деле она меняет выбор следующего токена из возможных продолжений. Более стабильная формулировка может облегчить сравнение повторных ответов, но не исправляет отсутствие колонки, неверное определение «оплаченного заказа» или размножение строк после JOIN.

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

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

Как отличать знание модели от данных инструмента

При ответе ассистента спросите: «откуда именно взялось это число?» Возможны три варианта. Оно было прямо передано в запросе; получено через инструмент; или создано моделью как текст. Первый вариант требует проверки источника входных данных, второй — журнала вызова, третий — независимого вычисления до использования.

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

Для командной работы зафиксируйте это в отчёте: строка «источник: запрос к таблице рейсов, выполнен 26 сентября» даёт читателю опору. Строка «источник: ChatGPT» лишь называет автора текста и не объясняет, как получена цифра.

Частые вопросы

Что означает LLM простыми словами? Большая языковая модель строит ответ из токенов с учётом полученного контекста. Она может писать код и объяснять текст, но сама по себе не служит источником точных расчётов.

Что такое токены в нейросети? Это элементы, на которые токенизатор делит текст. Они не обязаны совпадать со словами: одно слово может занимать несколько токенов.

Что такое контекстное окно LLM? Это ограничение на объём информации, доступной модели при конкретном ответе. В него входят не только ваш вопрос, но и инструкции, история и данные.

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

Почему модель ошибается в сумме таблицы? Генерация текста не равна точному проходу по строкам. Для суммы выполняйте SQL или Python и сверяйте итог.

Куда перейти после определения

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

Для следующего шага возьмите готовый шаблон промпта для аналитика и заставьте его вернуть код, допущения и тесты. Если ваша работа связана с SQL, учебная база «Авиаперевозки» в тренажёре позволит проверить результат на реальном выполнении запроса.

Продолжить чтение
Вся библиотека