Токенизация русского текста: где незаметно растёт счёт

Почему счёт растёт даже на коротких текстах

Счёт за LLM редко зависит от того, сколько строк вы видите на экране. Он зависит от того, как модель режет текст на токены. Поэтому два абзаца иногда стоят дешевле, чем один короткий фрагмент договора с реквизитами и таблицей.

Неприятный сюрприз часто появляется там, где текст выглядит обычным. Для человека строка с ФИО, ИНН, КПП, номером договора и датой кажется компактной. Для модели это набор слов, чисел, знаков, сокращений и разделителей, которые быстро разрастаются в заметный объём.

Расход идёт в обе стороны. Вы платите за входной текст, который отправили в модель, и за ответ, который она вернула. Если в запросе уже много токенов, а потом вы просите "подробно разобрать каждый пункт", стоимость растёт ещё раз - уже на стороне ответа.

Чаще всего бюджет съедают не "умные" части запроса, а служебный шум:

• длинные ФИО и должности;
• юридические формулировки с повторами и уточнениями;
• реквизиты, номера счетов, даты и коды;
• таблицы из Excel с колонками, пустыми ячейками и дублями.

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

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

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

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

Как модель режет русский текст на токены

Модель не читает текст словами, как человек. Она разбирает строку на токены - короткие куски, из которых потом собирает смысл. Поэтому символы, слова и токены - не одно и то же.

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

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

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

Разница хорошо видна на трёх типах строк:

• "Оплатите счёт до пятницы" - обычная фраза, токены идут довольно ровно.
• "12.03.2025" - короткая дата, но точки и цифры тоже считаются, и разбиение зависит от модели.
• "ИНН 7701234567, КПП 770101001, р/с 40702810..." - строка с реквизитами часто разлетается на много мелких токенов из-за цифр, слешей, сокращений и знаков.

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

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

Если команда меняет модели через единый OpenAI-совместимый эндпоинт вроде RU LLM, расход лучше проверять на реальном наборе запросов, а не на паре аккуратных примеров. Особенно если в потоке есть договоры, ФИО, реквизиты и выгрузки из ERP. Именно там счёт растёт тихо, но быстро.

Где длинные фамилии съедают бюджет

ФИО в русском часто выглядит коротко для человека, но не для модели. Редкие и длинные слова она режет на большее число частей, чем простую разговорную фразу. Поэтому строка вроде "Александра Константиновна Салтыкова-Щедрина" почти всегда обходится дороже, чем кажется на глаз.

Расход растёт ещё быстрее, если рядом стоят инициалы, должность, адрес и номер документа. "Иванов И.И., главный специалист отдела внутреннего контроля, паспорт 45 09 123456, выдан..." - это уже не одна сущность, а длинная цепочка из слов, сокращений, цифр и знаков. Для токенизатора это много мелких фрагментов, и счёт растёт на каждой строке.

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

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

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

• оставлять одно каноническое написание ФИО без всех падежных вариантов;
• убирать отчество, если задача не зависит от точной идентификации;
• заменять повторяющиеся ФИО на метки вроде "Клиент_17" внутри одного запроса;
• выносить адреса и номера документов в отдельное хранилище, если модель их не анализирует.

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

Почему договорный язык стоит так дорого

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

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

Один и тот же смысл, разная цена

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

Короткая версия:
"Исполнитель оказывает Заказчику консультационные услуги в срок и на условиях договора".

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

Отдельная проблема - длинные определения. Например: "Общество с ограниченной ответственностью 'Альфа Технологии', именуемое в дальнейшем 'Исполнитель'". В договоре это определение может повторяться снова и снова. Для модели повтор не бесплатный.

Больше всего раздувают объём фрагменты, которые можно сократить без потери смысла:

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

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

Разница быстро становится заметной в командах, которые прогоняют договоры через API каждый день. Один и тот же запрос через любой OpenAI-совместимый шлюз будет стоить по числу токенов, а не по "важности" текста. Короткая деловая версия часто даёт такой же результат и заметно меньший счёт.

Что происходит с таблицами и выгрузками

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

Markdown-таблица раздувается особенно быстро. У неё есть служебный шум: |, строка с ---, повторяющиеся пробелы и переносы. CSV выглядит проще, но проблема та же: каждый разделитель, пустое поле и кавычка добавляют текст, который модель должна разобрать. Если в выгрузке 40 столбцов и половина из них пустая, пустота всё равно стоит денег, потому что запятые остаются на месте.

Повтор шапки тоже бьёт по счёту. Excel, BI-отчёты и копирование из нескольких листов часто дублируют заголовки в каждом фрагменте. А если названия столбцов длинные, вроде "Наименование структурного подразделения" или "Дата последнего изменения статуса", вы платите за них снова и снова.

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

Когда лучше дать сводку

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

• описания колонок;
• 10-20 типовых строк;
• агрегатов по суммам, статусам и датам;
• нескольких аномалий или спорных записей.

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

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

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

Как посчитать расход до запуска

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

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

Если вы запускаете сценарий с документами, возьмите не один-два удачных кейса, а выборку из 20-50 реальных запросов. В ней почти всегда всплывают длинные ФИО, куски договоров, вставки из Excel и повторяющиеся служебные поля. Они быстро меняют среднюю картину. Один короткий тест легко покажет 3 тысячи токенов, а реальная медиана окажется ближе к 8 тысячам.

Подсчёт удобно делать так:

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

Запас почти всегда нужен. Если модель обычно отвечает на 700 токенов, разумно считать бюджет так, будто ответ будет в 1200-1500. Если ваш пайплайн делает повторный вызов для проверки, суммарный расход вырастает почти вдвое. То же касается RAG, когда к вопросу добавляются найденные фрагменты.

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

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

Пример: обращение с договором и таблицей

Представьте обычный запрос в поддержку. Клиент пишет: "Проверьте, почему у меня долг по договору" и вставляет ФИО, номер договора, полный кусок из оферты и таблицу платежей за 18 месяцев. С виду текст небольшой. По счёту это уже тяжёлый запрос.

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

Основной объём в таком кейсе дают:

• полное ФИО, особенно с двойной фамилией или отчеством;
• номер договора, даты, суммы и служебные коды;
• договорный текст с повторами вроде "в соответствии с", "на основании", "в случае неисполнения";
• таблица платежей, где каждая строка повторяет одни и те же колонки.

Возьмём условный пример. В исходном запросе есть полное ФИО клиента, номер договора, три абзаца из договора и таблица на 24 строки: дата, сумма, статус, комментарий. Такой ввод легко доходит до 2200-2800 токенов, хотя человек читает его за минуту.

После чистки тот же смысл можно передать намного короче. ФИО часто достаточно свернуть до "клиент Н.", если модели не нужно сравнивать паспортные данные. Вместо полного номера договора можно оставить последние 4-6 символов. Юридический фрагмент лучше не вставлять целиком, а пересказать в одной-двух фразах: "штраф начисляется при просрочке более 10 дней". Таблицу обычно стоит превратить в сводку: 24 платежа, 3 просрочки, последняя успешная оплата 12.02, общая сумма долга 18 400 руб.

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

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

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

Где команды теряют деньги без пользы

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

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

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

Ещё одна тихая утечка - дубли инструкций. Одна и та же фраза нередко живёт сразу в system prompt, в шаблоне запроса и прямо в коде. Для модели это не "одна настройка", а несколько отдельных кусков текста, за каждый из которых вы платите.

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

Обычно хороший эффект дают две вещи: жёсткая чистка входных данных и короткая сводка вместо полного сырого текста. Это скучная работа, но именно она чаще всего и убирает лишние расходы.

Короткий чек-лист перед запуском

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

• Посмотрите, сколько раз в запросе повторяются ФИО, адреса, реквизиты и номера документов. Если один и тот же блок встречается 5-10 раз, модель честно съест его 5-10 раз.
• Проверьте, можно ли заменить таблицу короткой сводкой. Вместо 200 строк отгрузок часто хватает 4-5 чисел: период, сумма, число просрочек, самый крупный платёж, последний статус.
• Уберите договорный язык, который не влияет на вывод. Длинные преамбулы, ссылки на внутренние регламенты и повторяющиеся оговорки часто занимают больше места, чем сам вопрос к модели.
• Измерьте расход на реальных данных, а не на одном красивом примере. Один тестовый договор на две страницы ничего не покажет, если в работе пойдут сканы, приложения и таблицы из Excel.
• Задайте лимит на длину ответа заранее. Иначе команда сокращает вход, а модель возвращает полстраницы пересказа и снова тратит лишние токены.

Быстрый тест выглядит просто. Возьмите 20-30 реальных документов, прогоните их в двух версиях: как есть и после чистки. Сравните не только качество ответа, но и общий расход на вход и выход. Иногда текст становится короче на 30%, а ответ почти не меняется.

Если вы отправляете запросы через OpenAI-совместимый шлюз вроде RU LLM, такой замер удобно делать на том же коде и с теми же SDK, которые потом пойдут в работу. Это помогает увидеть реальную стоимость до запуска, а не после первого счёта.

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

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

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

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

Рабочая схема обычно сводится к четырём шагам:

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

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

Если у проекта есть требования по data residency и 152-ФЗ, архитектуру лучше выбрать заранее. В таком случае удобно сразу проверить OpenAI-совместимый эндпоинт, который не требует менять SDK, код и промпты. У RU LLM для этого есть российская обработка, хранение логов и бэкапов в РФ, маскирование PII и встроенные аудит-трейлы.

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