Перейти к содержанию
Публикация AiManual

Позиционное кодирование и структура абзацев: как трансформер воспринимает иерархию текста

Стандартное позиционное кодирование видит только порядок токенов, а не абзацы. Разбираем эксперимент с hRoPE: fake-merge, fake-split, контроль со случайными мет

Коротко

Что будет в материале

  1. 01

    Почему стандартное позиционное кодирование не видит абзацы

  2. 02

    Что такое hRoPE: иерархическое роторное позиционное кодирование

  3. 03

    Эксперимент с fake-merge и fake-split: как измерили внимание между абзацами

  4. 04

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

Стандартное позиционное кодирование в трансформерах описывает позицию токена одним числом: его индексом в порядке чтения. Иерархию текста, где документ состоит из абзацев, абзац из предложений, а предложение из токенов, такая схема не кодирует. Автор статьи на Towards Data Science проверил именно это расхождение: он построил hRoPE, иерархическое роторное позиционное кодирование, в котором индекс абзаца, индекс предложения и индекс токена вращают независимые блоки размерностей, и посмотрел, меняется ли внимание между абзацами, когда координату абзаца можно двигать отдельно от всего остального.

Результат короткий: cross-paragraph attention сжимается относительно baseline с совпадающим расстоянием между токенами, причём в каждом корпусе. Но само сжатие не доказывает, что модель опирается на настоящую структуру. Архитектурно идентичный канал со случайными метками, согласованными по плотности, тоже сжимает внимание, только слабее. Диагностическим оказывается другой показатель - глубина сжатия: у реальной структуры она больше и зависит от корпуса, у контроля не зависит.

Эксперимент ограничен моделями на 8 слоёв и 512 размерностей и тремя корпусами, поэтому переносить выводы на продакшн-модели рано. Ниже разбор по шагам: как устроены RoPE и ALiBi, зачем понадобилась сепарабельность координат, что показали интервенции fake-merge и fake-split, чем помог тест с перемешиванием абзацев и какие ограничения у всего этого есть.

Почему стандартное позиционное кодирование не видит абзацы

Стандартные позиционные кодирования представляют позицию как одномерную координату в порядке чтения, но порядок чтения сам по себе не определяет иерархическую структуру текста (arXiv 2609.23551). Модель видит поток токенов, а не дерево.

Что кодирует RoPE и ALiBi

RoPE вращает каждую пару каналов на угол, пропорциональный индексу токена в порядке чтения. ALiBi добавляет смещение, пропорциональное этому же индексу (Your LLM Has a Curved Space of Paragraphs). Механика разная: одно вращает представление, другое складывает его с bias. Общее одно: на вход идёт единственное число, индекс токена. Ни абзац, ни предложение не представлены в этой схеме как отдельные величины.

Иерархия текста против линейного порядка

Для читателя текст устроен как дерево: документ ⊃ абзац ⊃ предложение ⊃ токен. При n токенах одна и та же последовательность допускает 2^(n-1) сегментаций на абзацы (Your LLM Has a Curved Space of Paragraphs). Все эти варианты содержат одинаковые токены в одинаковом порядке, и стандартная модель различит их только по служебным символам, если те вообще попали в разбиение.

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

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

Что такое hRoPE: иерархическое роторное позиционное кодирование

hRoPE представляет индексы абзаца, предложения и токена как отдельные каналы (arXiv 2609.23551). Каждый уровень вращает свой блок размерностей, и блоки не взаимодействуют. На практике это значит, что индекс абзаца не размазывается по тем же размерностям, что индекс предложения и индекс токена.

Независимые каналы для абзаца, предложения и токена

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

Сепарабельность и координата абзаца p1

Ключевое свойство hRoPE - сепарабельность. Можно изменить координату абзаца токена, сохранив неизменными его индекс предложения, индекс токена и всю последовательность токенов (Your LLM Has a Curved Space of Paragraphs). Без этого свойства интервенции над структурой были бы невозможны: любое движение координаты абзаца тянуло бы за собой остальные уровни, и эффект нельзя было бы приписать именно границе абзаца. Важная оговорка: hRoPE - исследовательская конструкция автора эксперимента, а не стандарт индустрии.

Эксперимент с fake-merge и fake-split: как измерили внимание между абзацами

Процедура выглядит так. Последовательность токенов фиксируется, затем выполняется интервенция на координату абзаца p1, после чего измеряется cross-paragraph attention. Оценщик подобран так, чтобы быть точным по расстоянию между токенами.

Почему важно фиксировать токены и расстояние

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

Что показали fake-merge и fake-split

Fake-merge - удаление реальной границы абзаца, fake-split - вставка фиктивной. Логика зеркальная: если модель действительно использует координату абзаца, эти две операции должны тянуть внимание в противоположные стороны. Так и выходит. Удаление реальной границы снижает cross-paragraph attention, вставка фиктивной - повышает. Внимание сжимается относительно baseline с совпадающим расстоянием между токенами в каждом корпусе.

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

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

Что такое контроль, согласованный по плотности

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

Глубина сжатия как воспроизводимый сигнал

Ответ даёт глубина сжатия, а не его локация. У реальной структуры глубина больше, и она зависит от корпуса. У контроля глубина от корпуса не зависит (arXiv 2609.23551). Это центральный вывод эксперимента, и он слабее, чем выглядит на первый взгляд: сравнение идёт между двумя слабыми эффектами, а не между «работает» и «не работает».

Тест с перемешиванием абзацев: причинная связь

Наблюдение корреляции и причинная связь - разные вещи, поэтому автор добавил тест с перемешиванием абзацев. Абзацы переставляются, и глубина сжатия должна отреагировать, если связь причинная. У hRoPE глубина меняется во всех корпусах. У случайного контроля - ни в одном.

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

Что определяет глубину сжатия: открытый вопрос

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

Три конструкта: лексическая устойчивость, длина абзаца, эмбеддинговая когерентность

Лексическая устойчивость (lexical persistence) описывает, насколько слова возвращаются в пределах абзаца. Длина абзаца (paragraph length) - простая геометрия разбиения. Эмбеддинговая когерентность (embedding-based coherence) измеряет смысловую близость соседних фрагментов. Ни один из трёх конструктов не воспроизводит межкорпусный порядок глубины полностью. Ближе всего к этому эмбеддинговая когерентность, но и она не даёт точного совпадения.

Почему OpenWebText выбивается

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

Ограничения эксперимента: что нельзя переносить на большие модели

Список ограничений короткий и жёсткий. Модели в эксперименте имеют 8 слоёв и 512 размерностей. Корпусов три. OpenWebText не показывает разрыва по глубине. Что именно в корпусе определяет глубину сжатия, остаётся открытым вопросом.

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

Что это значит на практике: RAG, чанкинг и структура документа

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

Почему это важно для RAG и длинного контекста

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

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

Куда смотреть дальше

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

Подписаться на канал