У препринті на arXiv, опублікованому в серпні 2026 року під назвою «Beyond a Bag of Features: Set-Level Instability in Sparse Autoencoders», дослідники ставлять під сумнів одне з базових припущень механістичної інтерпретованості: що sparse autoencoder (SAE), навчений повторно з іншим випадковим стартом на тих самих активаціях моделі, відтворює по суті той самий набір інтерпретованих ознак.

SAE давно стали робочим інструментом безпекових команд великих лабораторій. Саме через sparse autoencoder Anthropic у 2024 році знайшла й підсилила ознаку «Golden Gate Bridge» у Claude 3 Sonnet, а OpenAI та DeepMind публікують власні бібліотеки вивчених ознак для аудиту моделей і пошуку небезпечних напрямків поведінки. Вся ця практика стоїть на негласній угоді: якщо ознака з'явилася в одному навчанні SAE, вона є властивістю самої мережі, а не випадковим артефактом ініціалізації ваг.

Нова робота ставить під сумнів саме цю угоду — причому не на рівні окремих ознак, які раніше вже намагалися зіставляти між запусками, а на рівні всього набору одразу. За даними arXiv, конфігурація, взаємні межі та спільне покриття простору активацій набором ознак виявляються значно менш відтворюваними, ніж припускала попередня практика.

У чому різниця між нестабільністю окремої ознаки і нестабільністю набору?

Різниця в одиниці аналізу: попередні перевірки відтворюваності SAE зіставляли ознаки одна-до-одної між запусками навчання, зазвичай через косинусну схожість або угорський алгоритм зіставлення, і рахували частку «виживших» пар. Такий підхід — це погляд на SAE як на «мішок ознак» (bag of features), де кожен елемент оцінюється незалежно від решти.

Set-level погляд ставить інше питання: чи один і той самий набір ознак у цілому однаково розбиває простір активацій моделі на частини? Дві SAE можуть мати майже ідентичний відсоток збіжних окремих ознак і водночас по-різному розподіляти «відповідальність» за ту саму поведінку моделі між рештою ознак — з іншою надлишковістю, іншими межами й іншими комбінаціями, які спільно відтворюють той самий вихід мережі.

Чому набір «розсипається», навіть коли окремі ознаки виглядають стабільними?

Причина — у самій постановці задачі навчання SAE. Оптимізація мінімізує суму похибки реконструкції та штрафу за розрідженість (L1), а ця функція втрат недоопукла й має багато локальних розв'язків з практично однаковим значенням. Різні словники ознак можуть однаково добре стискати й розріджено відтворювати ту саму активацію, просто по-іншому розкладаючи простір на частини.

Додає нестабільності й відомий ефект feature splitting/absorption: одна «груба» ознака в меншому SAE може розпастися на кілька вужчих у більшому або в іншому запуску навчання поглинути сусідню. Коли дивитися на окрему пару ознак, це виглядає як «та сама фіча трохи змістилась». Коли дивитися на набір цілком, це вже інша топологія розкладу — і саме це, за словами авторів роботи, недооцінюють поточні метрики зіставлення один-до-одного.

Кому і навіщо це важливо на практиці?

Це напряму стосується будь-якої команди, що будує продукт або дослідження поверх SAE-ознак, а не лишень авторів фундаментальних робіт з інтерпретованості. Практичні наслідки:

• Steering-вектори та «функції видалення небезпечної поведінки», знайдені через одну SAE, можуть не відтворитися при перенавчанні того самого SAE з іншим сідом — тобто демо на конференції не гарантує стабільності в проді.
• Дашборди на кшталт Neuronpedia чи внутрішні каталоги ознак варто трактувати як знімок одного конкретного запуску навчання, а не як канонічний список «усіх концептів, які знає модель».
• Безпекові аудити, що спираються на «модель не має ознаки X, отже не здатна на Y», ризикують хибним висновком — відсутність ознаки в конкретному SAE не означає її відсутність у мережі.
• Порівняння інтерпретованості між версіями моделі (наприклад, до і після файнтюну) через SAE-ознаки потребує контролю на множинних сідах, інакше різниця в наборі ознак може бути шумом навчання SAE, а не реальною зміною моделі.

Що з цього випливає для індустрії інтерпретованості?

Наша теза в AiiN: індустрія SAE-інтерпретованості вже перейшла зі стадії «цікавого дослідницького інструменту» в стадію «аргумент у звіті з безпеки», але дисципліна вимірювання не встигла за цим переходом. Для звичайної метрики моделі — accuracy, latency, cost — ніхто давно не публікує результат з одного запуску без варіації по сідах. Для SAE-ознак це досі норма: одна навчена автоенкодер-модель, один список фіч, один claim про те, що «модель має концепт X».

Set-level нестабільність, показана в цій роботі, — привід зробити мультисідне навчання й звітування дисперсії набору ознак обов'язковим мінімумом для будь-якого SAE-claim, що йде в safety-звіт чи продуктове рішення, а не опційним додатком у apendix. Команди, які цього не зроблять, ризикують будувати механізми контролю поверх однієї випадкової конфігурації ознак — і дізнатися про крихкість цього фундаменту вже після інциденту, а не до нього.

Чи означає це, що sparse autoencoders взагалі не працюють?

Ні. Реконструкція активацій і якість найпомітніших, найбільш «виражених» ознак лишаються цілком відтворюваними між запусками. Проблема стосується радше повноти й точності набору загалом — особливо рідкісних, тонких або взаємопов'язаних ознак, де SAE має свободу розв'язати задачу по-різному, зберігаючи однакову якість реконструкції.

Як перевірити стабільність власних SAE-ознак перед тим, як на них покладатися?

Перенавчіть SAE щонайменше з двома-трьома різними випадковими сідами на тих самих активаціях і порівнюйте не лише парне зіставлення ознак, а й агрегатні метрики набору: сумарне покриття простору активацій, надлишковість між ознаками, стабільність кластерів, а не тільки середню косинусну схожість найближчих пар.

Чи стосується це лише великих лабораторій на кшталт Anthropic чи OpenAI?

Ні, це стосується будь-кого, хто використовує SAE-based інтерпретованість у своїх продуктах чи дослідженнях — включно з відкритими бібліотеками на кшталт SAELens і власними внутрішніми пайплайнами аудиту моделей. Масштаб лабораторії не захищає від недоопуклості функції втрат SAE.