Разработчик self-hosted ИИ-стека на Dify, Milvus и локальных LLM представил русскоязычный сплиттер для RAG, который использует вывод индексов границ вместо генерации текста чанков. Модель обучена на базе T-lite-it-2.1 с LoRA и выдаёт метки для байт-в-байт нарезки исходных документов.

Проблема, которую решает сплиттер, связана с токенизацией русского текста. Многие модели кодируют кириллицу неэффективно: на живых замерах токенайзер Llama-2 давал 3,17 токена на слово против 1,74 у T-lite. Для RAG это означает, что при фиксированном контекстном бюджете вмещается меньше реального текста, либо растёт стоимость обработки. Вторая проблема — таблицы. Семантические сплиттеры, режущие по cosine-сдвигу темы, не получают сигнала от строк таблицы и отрывают шапку от тела, что делает чанки бесполезными.

ТокенайзерТокеновТок/словоVs T-lite
T-lite-it-2.1731.74
Qwen2.5-7B1142.71×1.56
Llama-2-7B1333.17×1.82

Ключевое отличие от существующих решений — архитектура вывода. Исходный датский context-aware-splitter-1b переписывал текст каждого чанка, что дорого (примерно в 10 раз больше токенов) и приводило к байт-рассинхрону с оригиналом. Новый сплиттер возвращает только список индексов границ и ключевую тему, а хост режет оригинальный документ строго по этим индексам. Это даёт три практических плюса: lossless-нарезку (чанки совпадают с исходником байт-в-байт), дешёвый вывод (35–40 токенов JSON) и целостность таблиц, если upstream-парсер корректно выделил структуру.

Вывод дешевле: около 35–40 токенов JSON на документ вместо переписывания 10-кратного объёма.

Обучение проводилось методом bf16-LoRA через Unsloth на RTX 5090 (Blackwell). Разметка была задистиллирована от self-hosted DeepSeek-V4-Flash. За 2 эпохи и 2122 шага модель достигла boundary-F1 @±1 = 0,821 по teacher-agreement с метками учителя. Однако автор подчёркивает, что это метрика согласованности с разметкой, а не качества RAG — downstream-метрики (hit-rate, faithfulness) пока не оценивались.

Деплой выполнен в формате GGUF Q5_K_M (около 5,9 ГБ) на AMD Strix Halo с помощью llama.cpp Vulkan. На тестовом документе из 9 юнитов время обработки составило около 1,2 с при 40 ток/с генерации и 947 ток/с prompt eval. Код, README и planning-файлы опубликованы в открытом доступе, что позволяет сообществу проверить и доработать подход.