Уявіть: ви відправляєте один і той самий запит до GPT-4 або Claude, але змінюєте лише порядок варіантів відповіді — і отримуєте принципово різний результат. Звучить як дивний баг, але насправді це системна властивість великих мовних моделей, яку тепер задокументували науково.
За даними arXiv, масштабний аудит чутливості порядку в LLM підтвердив: трансформери не є нейтральними до перестановок вхідних даних. Вони систематично надають перевагу певним позиціям у запиті — і це впливає на якість та відтворюваність відповідей.
Для тих, хто будує продукти на базі LLM, це не абстрактна академічна знахідка. Це системне джерело непередбачуваності у production-системах, яке досі недооцінювали — і якому тепер є кількісне підтвердження.
Чому LLM чутливі до порядку
Архітектура трансформера обробляє вхідний текст через механізм уваги (attention), який, попри позиційне кодування, не забезпечує справжньої інваріантності до перестановок. Ба більше: моделі навчаються на корпусах природної мови, де порядок слів несе семантичне навантаження — і ця «звичка» залишається навіть тоді, коли вона шкодить якості відповіді.
Дослідники зафіксували кілька механізмів, що лежать в основі проблеми:
- Primacy bias — модель надає надмірну вагу першому варіанту відповіді або першому аргументу у запиті.
- Recency bias — у довгих контекстах увага зміщується до останнього фрагмента, попередній матеріал «розмивається».
- Structural anchoring — синтаксична конструкція запиту задає «рамку», яка впливає на те, як модель інтерпретує завдання, ще до розгляду змісту.
Важливо: вразливість не однакова для всіх моделей і типів завдань. Більші моделі демонструють меншу схильність до позиційних упереджень — але не нульову.
Що виміряли дослідники
Аудит охопив кілька типових production-сценаріїв, з якими стикається кожен ML-інженер:
- Multiple-choice завдання, де порядок варіантів A/B/C/D систематично перемішувався між запусками.
- Few-shot приклади з різним розташуванням у контексті — на початку, в середині та наприкінці промпту.
- RAG-запити, де порядок чанків з документів варіювався незалежно від їхньої релевантності.
- Chain-of-thought підказки з різною послідовністю кроків міркування.
Результати виявились суттєвими: на деяких бенчмарках зміна порядку варіантів у multiple-choice знижувала точність моделі на 5–15 відсоткових пунктів. У завданнях на складне розмірковування з багатокроковим контекстом розбіжність сягала ще більших значень. Це означає: якщо ви оцінюєте LLM за одним фіксованим набором промптів — ви, ймовірно, отримуєте зміщені метрики.
Практичні наслідки для AI-білдерів
Ця знахідка безпосередньо впливає на архітектурні рішення при побудові систем на базі LLM. Ось що варто переглянути вже зараз.
Evaluation pipelines: Якщо ви вимірюєте якість моделі на тестових наборах з фіксованим порядком — ваші метрики можуть бути зміщеними. Правильний підхід: запускайте кілька перестановок і усереднюйте результати (permutation averaging). Це особливо критично при A/B тестуванні моделей або порівнянні fine-tuned версій між собою.
Промпт-інженерія:
- У few-shot прикладах розміщуйте найрелевантніший приклад останнім — recency bias у цьому випадку працює на вас.
- У RAG-системах перевіряйте, чи змінюється якість відповіді при різному порядку чанків. Якщо так — додайте логіку ререйтингу або перемішування.
- Для classification завдань уникайте фіксованого порядку міток — або рандомізуйте між запусками, або нейтралізуйте через self-consistency sampling.
Критично надійні продукти: У медичних, юридичних або фінансових застосунках order sensitivity може мати реальні наслідки. Тут доцільно реалізувати multiple-pass inference з різними перестановками та агрегувати відповіді через голосування або ансамблювання моделей.
Погляд AiiN
Це дослідження кількісно підтверджує те, про що досвідчені ML-інженери давно здогадувались на практиці: LLM — не детерміновані довідники, а статистичні машини з позиційними упередженнями. І ці упередження не випадкові — вони структуровані й передбачувані, а отже піддаються управлінню.
Для індустрії це сигнал одразу на двох рівнях. Розробники моделей мають включати аудит order sensitivity до стандартних evaluation протоколів — поруч із accuracy, calibration і robustness. Ті ж, хто будує продукти, мають враховувати цю вразливість при проектуванні промптів і inference-пайплайнів.
Хороша новина: проблема вирішувана. Permutation averaging, self-consistency та уважна організація контексту суттєво зменшують ефект. Погана новина: це додаткові витрати на інференс, які не кожна команда може собі дозволити у production при великих масштабах.
Але знати про проблему — вже половина рішення. Тепер у нас є кількісний аудит, на який можна спиратись при проектуванні надійних AI-систем.
