Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Табличная предобученная модель научилась подстраиваться под новую таблицу по размеченным строкам, не меняя свои параметры. В нерецензированном препринте Ant Group и независимого исследователя все числа получили сами авторы; RefineICL обошла TabPFN-3 на 31,4 пункта в рейтинге Elo, который сводит попарные результаты на наборах данных. Архитектура ставит под вопрос обязательный расширенный полносвязный блок FFN после механизма внимания: для похожего продукта теперь разумно проверить более компактный контекстный стек.
Как метки меняют представление таблицы
Табличная модель получает отдельную задачу при каждом вызове. Ей передают опорные строки с признаками и метками, а затем строки без меток, для которых нужен прогноз. Параметры модели остаются прежними, поэтому правило для текущей таблицы приходится строить внутри прямого прохода.
Авторы предлагают считать опорные строки не статичной памятью, а изменяемой частью вычисления. Модель оценивает, насколько хорошо каждую размеченную строку можно распознать по остальным, не позволяя строке голосовать за саму себя. Если рядом оказываются объекты другого класса, внутреннее представление получает поправку, которая лучше разделяет классы.
Эту поправку переносят на строку без метки по сходству с опорными примерами. Механизм внимания решает, откуда читать информацию, а зависящий от текущего состояния вентиль задаёт силу поправки для каждого измерения. Остаточная связь прибавляет результат к представлению, после чего следующий блок повторяет вычисление уже с обновлёнными опорными строками.
Такое устройство объясняет, почему отдельная расширенная FFN может оказаться лишней. Нелинейность возникает при умножении результата внимания на вентиль, а не в большом полносвязном блоке после него. Линейные проекции при этом остаются: речь идёт не об архитектуре без матричных операций, а об отказе от отдельного расширения представления.
До контекстного стека RefineICL отдельно кодирует числовые значения, категории и пропуски, выбирает существенные взаимодействия признаков и сжимает строку в вектор фиксированной ширины. Часть информации о признаках сохраняется в типизированной памяти и возвращается на промежуточных слоях, чтобы сжатие строки не уничтожило полезные связи.
Обновлённые опорные строки улучшают следующий прогноз
Модель проверяли на публичных наборах для табличной классификации AMLB29, CC18, Grinsztajn, TabZilla и TabArena. Эксперименты охватывают модели среднего масштаба и сравнение с другими табличными моделями, которые получают размеченный контекст без дообучения под конкретный набор. Результат TabArena относится к отдельному продолжению обучения, выбранному с учётом этого бенчмарка, а не только к базовой контрольной точке.
Главный эксперимент вмешивается во внутреннее вычисление модели. Выход промежуточного блока для прогнозируемой строки сохраняли, но обновление опорных строк отменяли, после чего запускали оставшиеся блоки. Во всех 72 эпизодах итоговая перекрёстная энтропия выросла в среднем на 0,051, а точность снизилась на 1,44 процентного пункта. Значит, промежуточный блок не просто сразу улучшает прогноз: он готовит размеченный контекст для последующих блоков.
Другой тест переставлял результаты внимания и значения вентилей между прогнозируемыми строками. Сами векторы сохранялись, но попадали не к тем получателям, и качество падало. Это подтверждает вторую часть механизма: модель не извлекает одну общую поправку для всей таблицы, а рассчитывает её отдельно для каждой строки.
В контролируемом сравнении варианты с FFN и без неё получили одинаковую ширину, глубину и бюджет в 100 тысяч обновлений. Расширенный блок не дал устойчивого выигрыша на проверочных данных, а в самой глубокой конфигурации увеличил пиковое потребление памяти при прогнозе на 60,2%. Этот результат относится к фиксированному бюджету обучения и не доказывает, что FFN бесполезна при любом масштабе.
Когда FFN стоит убрать из прототипа
Работа меняет планы команд, которые строят единую модель для множества небольших и средних таблиц, передают ей размеченные строки прямо в запросе и не хотят дообучать параметры для каждого клиента. Для такого режима обновление опорных представлений становится отдельным архитектурным кандидатом, а FFN — проверяемой опцией, а не обязательной частью каждого блока.
Практический прототип стоит сравнивать с текущей архитектурой при одинаковом числе опорных строк и одинаковой ширине представлений. Измерять нужно не только качество, но и пиковую память при рабочих размерах контекста: именно здесь отказ от расширения дал ясный выигрыш. В работе не приведены замеры задержки на целевом оборудовании, поэтому вывод о стоимости обслуживания придётся получать отдельно.
Полностью менять производственный стек по этому препринту рано. Сначала имеет смысл воспроизвести два вмешательства на собственных задачах: отменить промежуточное обновление опорных строк и переставить поправки между прогнозируемыми строками. Если качество почти не изменится, продукт, вероятно, использует другой механизм и перенос RefineICL не окупит усложнение.
Если же вмешательства заметно ухудшат результат, можно тестировать контекстный стек без расширенной FFN. Тогда работа даёт не только новую модель для сравнения, но и конкретный способ выяснить, действительно ли система строит правило текущей таблицы внутри представлений.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
